이것은 필자의 굳은 믿음이다.
나는 1990년대 초반에 주로 백화점, 호텔 등에서 사용되는 POS 소프트웨어 개발을 했었는데, 그것은 금전을 다루는 것이었다. 바코드를 읽어 상품 가격을 조회하고, 그것들을 모아서 고객의 거래액을 계산하고, 집계된 거래 내역을 서버로 전송하고.
사소한 UI 버그가 아니라, 로직 버그가 발생하게 되면 결국 돈 계산이 잘못된다. 필자의 생각에 가장 품질이 중요한 소프트웨어는 사람의 인명과 관계된 것이고(예를 들면, 국방 또는 의료 소프트웨어), 다음이 돈을 다루는 것이라고 생각한다.
나는 돈을 다루는 소프트웨어 개발을 했기 때문에, 언제나 고객에게 인도되는 소프트웨어의 품질에 대해 많은 신경을 썼다. 그리고 당연하게도 1980년대 초반 중학생때 혼자 프로그래밍을 하면서 깨달은 "셀프 코드 리뷰" 기법을 백분 활용하였는데, 놀라운 점은 해당 작업을 마치고 나면 언제나 첫번째 테스트 케이스를 실행시키기도 전에 버그의 90% 이상을 제거할 수 있었다는 점이다. (사실은 100%였던 적이 거의 대부분이다)
셀프 코드 리뷰(self code review, 또는 self code inspection)란 오류를 찾기 위해 자신의 소스 코드를 엄격하게 검사하는 것이다. 쉽게 말해, 자신의 코드를 계속 읽는 것이다. 아주 단순하다.
이것의 가치는 로버트 L. 글래스도 자신의 저서에서 언급한 바 있다. 필자와 동일한 주장을 하는 것을 보고, 무척이나 반가웠던 기억이 난다.
모니터 상에서 계속 코드를 읽는 것에 불과하지만, 이것은 사실 엄청난 집중력을 요하기 때문에 무척 피곤한 작업이기도 하다. 하지만 그러한 집중력이야말로 소프트웨어스러운 것이며, 자신이 만든 코드와의 깊은 교감을 의미한다. 그러한 과정을 거치면 코드에 내재된 문제점들이 대부분 발견되며, 첫번째 테스트 케이스를 실행하기도 전에 거의 완벽한 코드가 완성되는 것이다.
경험이 많지 않는 사람이라면 이것이 무척 신기하게 생각될 수도 있을 것이다. 신기할 거 없다. 자신이 집중하고 애정을 쏟은 만큼 보상받는, 당연한 진리일 뿐이다.
그래서 필자는 어차피 완벽할 수 없는 테스트 케이스보다, 코드를 만든 프로그래머의 집중력과 영성(靈性)을 우선시하는 '셀프 코드 리뷰'를 강력 추천한다. 그리고 셀프 코드 리뷰후 '피어(peer) 코드 리뷰'를 한다면, 그 또한 도움이 될 것이다. 물론 코드 리뷰 후에 테스트 케이스를 실행하는 것은 당연히 필요하다. 코드 리뷰를 통해 걸러지지 않는 버그가 발견될 수도 있고, 또한 코드 리뷰의 성과를 검증해야하지 않는가? ^^
그 중요성에도 불구하고 코드 리뷰가 강조되지 않는 이유는, 벤더가 이것을 제품화할 수 없고 수행 과정이 가시화되기 힘들기 때문이다. 하지만 제대로 해 본다면, 반드시 그것의 가치와 재미를 발견하게 될 것이다.
무엇보다 중요한 것은, 자신이 만든 코드와의 깊은 교감이 아니겠는가.
프로그래머인 당신은 창조자로서 자신의 피조물을 통제할 수 있다. 창조자로서의 권리를 듬뿍 누리기를.