2005년 11월 27일

소프트웨어 품질 향상에 있어, 가장 가치있는 행위는 '셀프 코드 리뷰'

이것은 필자의 굳은 믿음이다.

나는 1990년대 초반에 주로 백화점, 호텔 등에서 사용되는 POS 소프트웨어 개발을 했었는데, 그것은 금전을 다루는 것이었다. 바코드를 읽어 상품 가격을 조회하고, 그것들을 모아서 고객의 거래액을 계산하고, 집계된 거래 내역을 서버로 전송하고.

사소한 UI 버그가 아니라, 로직 버그가 발생하게 되면 결국 돈 계산이 잘못된다. 필자의 생각에 가장 품질이 중요한 소프트웨어는 사람의 인명과 관계된 것이고(예를 들면, 국방 또는 의료 소프트웨어), 다음이 돈을 다루는 것이라고 생각한다.

나는 돈을 다루는 소프트웨어 개발을 했기 때문에, 언제나 고객에게 인도되는 소프트웨어의 품질에 대해 많은 신경을 썼다. 그리고 당연하게도 1980년대 초반 중학생때 혼자 프로그래밍을 하면서 깨달은 "셀프 코드 리뷰" 기법을 백분 활용하였는데, 놀라운 점은 해당 작업을 마치고 나면 언제나 첫번째 테스트 케이스를 실행시키기도 전에 버그의 90% 이상을 제거할 수 있었다는 점이다. (사실은 100%였던 적이 거의 대부분이다)

셀프 코드 리뷰(self code review, 또는 self code inspection)란 오류를 찾기 위해 자신의 소스 코드를 엄격하게 검사하는 것이다. 쉽게 말해, 자신의 코드를 계속 읽는 것이다. 아주 단순하다.

이것의 가치는 로버트 L. 글래스도 자신의 저서에서 언급한 바 있다. 필자와 동일한 주장을 하는 것을 보고, 무척이나 반가웠던 기억이 난다.

모니터 상에서 계속 코드를 읽는 것에 불과하지만, 이것은 사실 엄청난 집중력을 요하기 때문에 무척 피곤한 작업이기도 하다. 하지만 그러한 집중력이야말로 소프트웨어스러운 것이며, 자신이 만든 코드와의 깊은 교감을 의미한다. 그러한 과정을 거치면 코드에 내재된 문제점들이 대부분 발견되며, 첫번째 테스트 케이스를 실행하기도 전에 거의 완벽한 코드가 완성되는 것이다.

경험이 많지 않는 사람이라면 이것이 무척 신기하게 생각될 수도 있을 것이다. 신기할 거 없다. 자신이 집중하고 애정을 쏟은 만큼 보상받는, 당연한 진리일 뿐이다.

그래서 필자는 어차피 완벽할 수 없는 테스트 케이스보다, 코드를 만든 프로그래머의 집중력과 영성(靈性)을 우선시하는 '셀프 코드 리뷰'를 강력 추천한다. 그리고 셀프 코드 리뷰후 '피어(peer) 코드 리뷰'를 한다면, 그 또한 도움이 될 것이다. 물론 코드 리뷰 후에 테스트 케이스를 실행하는 것은 당연히 필요하다. 코드 리뷰를 통해 걸러지지 않는 버그가 발견될 수도 있고, 또한 코드 리뷰의 성과를 검증해야하지 않는가? ^^

그 중요성에도 불구하고 코드 리뷰가 강조되지 않는 이유는, 벤더가 이것을 제품화할 수 없고 수행 과정이 가시화되기 힘들기 때문이다. 하지만 제대로 해 본다면, 반드시 그것의 가치와 재미를 발견하게 될 것이다.

무엇보다 중요한 것은, 자신이 만든 코드와의 깊은 교감이 아니겠는가.
프로그래머인 당신은 창조자로서 자신의 피조물을 통제할 수 있다. 창조자로서의 권리를 듬뿍 누리기를.

댓글 6개:

익명 :

셀프 코드 리뷰를 하면서 느끼게 되는 쾌감이나 남이 짠 코드를 리뷰를 하면서 버그를 찾아내는 우월감(^^)과 쾌감을 느끼게 되는 이들이 진정 프로그래머로써의 자질과 가능성을 갖고 있다고 믿지만 요즘에 그런점이 많이 아쉽다는 생각이 듭니다.

익명 :

수업시간에 좀 뵙고 싶습니다. ㅋㅋㅋ

익명 :

셀프 코드 리뷰시에는 아무래도 자신의 생각 안에서만 놀게 되지 않나요? 저로서는 유닛테스트를 좀더 많이 하는 것이 낫다고 생각합니다. 아예 TDD 기법을 사용하면 코딩 전에 문제를 파악하는데 큰 도움을 얻을 수도 있구요.

바비(Bobby) :

정답은 없겠지요.

어쨌든 저는 셀프 코드 리뷰를 코드 작성 후 가장 먼저 해야 할 것으로, 또한 가장 우선순위가 있는 것으로 생각하고 있습니다.

이것은 "프로그래머는 창조자로서, 자신의 피조물인 코드를 거의 완전하게 통제할 수 있다. 집중력과 합리적인 사고로서."라는 사상에 기초하고 있지요.

신기한 것은 위의 사상에 동의하면 그러한 결과를 얻을 수 있고, 동의하지 않으면 그러한 결과를 얻지 못한다는 것이죠.

다시한번 말씀드리지만 정답은 없습니다. 철학에 의해 좌우될 뿐.

그리고 단위 테스트는 여전히 유효하고 중요합니다. 어떤 것에 더 관심을 갖느냐는 개발자의 스타일이고 좋은 결과만 얻는다면, 무엇이든 상관이 없다고 생각합니다.

의견 고맙습니다. ^^*

익명 :

글에서 언급하신 "로버트 L. 글래스"의 글은 여태 안 읽어봤는데, 찾아봐야겠습니다.^^

바비(Bobby) :

유명한 서적이죠. 인사이트 출판사에서 번역되어 나와있고, 번역본의 제목은 "소프트웨어 공학의 사실과 오해"입니다.

다음을 참고하세요.

http://book.interpark.com/bookPark/sitemap/BookDisplay.jsp?COMM_001=0000400000&COMM_002=0&GOODS_NO=2325899

정말 통찰력있는 서적이란 바로 이런 것이라고 생각합니다.

댓글 쓰기

댓글을 환영합니다.

스팸으로 인해 모든 댓글은 운영자의 승인 후 등록됩니다. 스팸, 욕설은 등록이 거부됩니다. 구글의 블로그 시스템은 트랙백을 지원하지 않습니다.