변하지 않아도 되는 코드는 죽은 코드 뿐이다.

내가 병특을 시작했던 회사에서 있었던 일이다.

그 회사는 그냥 흔한 SI 회사였는데 덕분에 코드 퀄리티는 크게 보장할 수 없었다. 정말이지 많은 것이 나를 괴롭혔지만, 그중에서 나를 가장 괴롭혔던 건 옛날에 작성되어 관리 안 되는 코드들이었다. 그 회사는 SI 회사답게 유지보수라는 명목으로 몇 년 전에 팔았던 프로젝트의 유지보수라는 이름으로 고정 수익을 벌고 있었는데, 그중에서 가장 심한 건 10년 전에 작성되었던 프로젝트도 있었다.

그 날도 여전히 그 코드에 괴롭힘당하고 있었다. 내가 괴로워하고 있으니 당시 내 사수였던 개발자 J가 와서 한마디 해줬었다.

너무 그러지 마. 이거 그래도 네 학교 선배 K가 병특할때 짰던 코드야. 조금씩 변경된 부분이 있지만 대부분 네 선배가 짠 거야.

위로의 말이었는지, 괴로워하는 거 티 내지 말라는 의미였는지 나는 모른다. 내가 아는 것은 그저 이게 내가 퇴사를 결심하게 된 계기가 되었다는 것이다. 어째서 저 말이 그렇게 내 마음을 흔드는 말이 되었을까?

당시에 K가 퇴사한 건 거의 10년 가까이 된 일이었다. 즉, 저 코드는 작성된 지 거의 10년이 된 코드라는 것이다. 거기에 유지 보수하면서 추가된 기능 외에 큰 틀은 전혀 건드리지 않았었다는 것이다. 뭐 J는 10년이 지날 만큼 안정적으로 작성된 코드라고 말하고 싶었을지도 모르겠다. 하지만 10년을 변하지 않은 코드가 좋은 코드일 리가 없다.

지난 10년간 프로그래밍 도구는 많은 발전이 있었다. 단적으로 생각해봐서 2003년에 visual studio 6.0으로 코드를 작성하는 것과 2013년에 visual studio 2013으로 코드를 작성하는 것을 생각해보자. 아무도 2013 대신 6.0을 선택할 사람은 없을 것이다. 10년이라는 시간은 이 정도의 발전을 가지고 왔다. 도구뿐이 아니다. 개발 방법론, 설계법, 분석법 모든 측면에서 지난 10년간 많은 발전이 있었다. 즉, 10년 전에 좋은 코드였다고 하더라도 지금 기준에서 좋은 코드라는 보장은 할 수 없다.

당시 그 회사는 코드의 이력관리를 전혀 안 했기 때문에¹⁾ 당시 K가 작성한 코드가 어떤 코드였는지 알 수 없었다. 하지만 내가 보고 있던 코드는 10년 전 기준으로도 좋은 코드였을 거라고 말할 수 없는 그런 코드였다. 개발에서 가장 중시하는 abstraction이나 flexibility를 전혀 고려하지 않고 전역변수들로 가득 차 있던 그런 코드를 아직 수정하지 않고 있던 회사를 도저히 믿을 수 없었다.

심지어 그 당시 코드는 10년간 전혀 변경이 없던 코드도 아니었다. 앞에서도 말했듯이 당시에 유지 보수라는 명목으로 계약하고 꾸준히 이것저것 기능들을 추가했었다. 글 불구하고 코드스멜들을 전혀 제거하지 않았다는 것은 더더욱 그 회사를 믿지 못하는 계기가 되었다.

---

1) 난 21세기에 이메일로 패치도 아닌 코드 전체를 주고받으며 작업하게 될 거라고는 상상도 못 했다.