코드 개선을 생각한다

내가 속한 프로젝트는 상당한 이력을 갖고 있다. 여느 프로젝트처럼 각양각색의 프로그래머들이 코드를 만졌다. 코딩 규칙은 없고, 딱히 정해진 업무 영역도 없다. 문서를 요구하지도 않는다. 사문화된 코드도 많다. 좋게 말하자면 참으로 자유롭다. 무엇보다 보는 코드가 많으니 그만큼 배운다. 나쁜 쪽은 이해가 부족한 상태에서 작업을 하는 경우가 많다는 것이다. 내역이 없으니 더 그렇다. 소스 관리 도구에 등록할 때마다 작업 사항을 기록하기는 한다. 그러나 큰 그림을 그리기에는 부족하다. 오로지 소스에만 의존해야 한다.

이렇다보니 소스 개선은 대단한 주의를 필요로 한다. 내가 읽은 책들은 문제를 덮지 말고 환부를 도려내야한다고 강조한다. 그러다보면 호미로 막을 일이 가래가 필요해지기도 한다. 진정으로 고민된다. 사소한 문제를 수정하느냐 위험 요소만 증가하는 건 아닐까? 모든 일이 그렇듯 잘되는 것 표가 나지 않는다. 허나 문제가 생기면 그렇지 않다.

나는 대체로 가래를 택하고는 한다. 같은 문제를 또 만나기 싫어서이기도 하고, 그렇게 함으로써 파생된 다른 문제를 종종 발견했기 때문이다. 그렇게 고친 코드로 인해 최근 심각한 문제를 접했다. 특정 시점에서 게임이 진행되지 않았다. 골치 아픈 버그일수록 서비스 시점에 드러나는 경향이 있는 것 같다. 나는 그날 반차 상태였는데, 다른 팀원들이 대신 수습하느냐 고생을 했다. 마침내 밤 10시에 출근할 생각을 했다. 다행히 그 즈음 버그가 수정이 되었다. 웃기게도 나는 내가 그날 쉰 것이 다행인지 불행인지 생각해봤다.

이런 걸 생각하면 코드 개선이란 대체 어느 시점에 해야하는지 고민된다. 개발 단계? 그럴 여유가 있을까. 서비스 단계? 고객을 상대로 테스트를 할 것인가. 최악보다는 차악이 나을 것이다. 이런 일을 겪었지만, 내 생각에 코드 개선은 꼭 필요하고 그 시점은 최소한 개발 단계는 아니라고 생각한다. 적정 체중 유지가 건강에 필수적이듯, 코드 복잡도도 적정한 수준을 유지해야한다고 미든ㄴ다. 그러려면 코드를 쳐내고 정리해야한다. 단일 진입점을 확보하려면 더욱 그렇다.

피할 수 없다면 잘할 방법을 찾는 것이 순리일 것이다. 이번 작업에서 내가 무얼 소홀히 했나 되새겨봤다. 바로 테스트였다. 상황을 낙관적으로 바라보고 소홀히 했다. 의심쩍인 구석을 '설마...'라는 단어로 덮었다. 한두 시간의 테스트를 소홀히 해서 여러 사람의 시간을 훨씬 뺏었다.

최근에는 무엇보다 테스트가 중시되는 추세이다. 이 과정을 자동화하는 것도 중요시 하고 있다. 내부 사정으로 인해 유닛 테스트같은 솔루션을 도입하기는 어려워보인다. 일단 나의 영향력이 좀 작으니까. 일단 테스트 시나리오를 작성해서 다양한 각도에서 문제를 점검할 수 있도록 해야겠다. 합리적인 의심. 이 단어를 머리에 넣어놓자.