코드 리뷰를 하자

코드 리뷰를 시작했던 건 위기감 때문이었다. 어느 날인가, 체크인된 코드를 읽어보는데 이게 웬일. 내가 겪었던 시행착오를 신입 개발자들이 그대로 하고 있었다. 선진이 후학의 디딤돌이 되어줘야 하는데, 부끄러운 일이었다. 그러나 코드 리뷰를 체크인 후에 할 수는 없는 노릇이었다. 자잘한 코드 하나하나까지 리뷰하러 가자니 번거로운 일이고 어쩌면 사람을 믿지 못하는 걸로 보일 수 있겠다는 생각도 들고 말이다. 그래서 수정 규모가 큰 신규 작업에나 리뷰를 했었다. 그러나 리뷰한 결과가 체크인된 코드에 반영되지 않은 경우가 더 많았다. 그렇게 시일만 하루하루 가고 있었다.

 

그런데 최근에 나를 깨우는 계기가 생겼다. 아이스스크럼이란 도구를 보았기 때문이었다. 스크럼을 도와주는 웹 어플리케이션인데, 이걸 기획팀장이 설치한 것이었다. 소프트웨어 엔지니어는 문제를 기술적으로 해결하는 사람이라 생각한다. 그런데 불편한 리뷰를 고집하고 있었다. 즉시 도구를 찾아보았다. 아니나 다를까. 리뷰보드(http://www.reviewboard.org) 란 멋진 툴이 있었다.사전 리뷰가 된다는 굉장한 장점이 있었다. 그러나 이 도구를 까는 데 많은 시행착오를 겪어야했다. 튜토리얼에서 다 설명하지 못하는 작디작은 사항들. 혹시 관심이 있으면 아래 경로에 내가 경험해서 배운 설치 안내를 적어놓았다. 덧붙여 나는 리뷰보드를 한 7번 설치해봤다. 아쉬운 점은, 경량 웹서버인 lightTPD에 설치를 못해본 것이다. 그러나 리뷰보드 설치에 거진 1주일을 보냈기 때문에 이 이상 시도는 후일로 미루는 편이 나아 보였다.

• http://ehei.springnote.com/pages/7496371

이렇게 멋진 도구를 만들어 공개로 배포하는 그들의 정신을 찬양하고 나도 꼭 기여를 하고 싶다는 생각이 든다. 그저 그런 개발자가 되고 싶은 생각 따위는 없다. 더 많은 지식으로 더 많은 기여를 하고 싶다. 웃기는 소리같지만 사회를 아름답게 만들고 싶다. 그러려면 힘이 필요한데, 기술자에게는 지식이 곧 근육이다.

 

리뷰보드의 최초 희생자는 이제 갓 1년이 된 개발자였다. 최근에 신규 기능을 맡아 작업하셨다. 공교롭게도 이 분의 작업을 두번 리뷰했다. 처음에는 리뷰 도구 설치 전이었기 때문에, 자리에 가서 직접 봤다. 여러 문제를 지적했고 수정하기로 하였다. 그리고 다음 날 도구가 설치되었다. 리뷰보드에 올려달라고 요청했다. 업무 시간 후 찬찬히 살펴보았다. 나도 모르게 헉 소리가 나왔다. 수정을 요구한 부분 중 아주 일부만 처리되었고, 대부분은 그대로였다. 게다가 자리에서 보았을 때 보지 못한 버그 들이 속속 보였다. 정말 리뷰 만으로 버그를 선제적으로 해결할 수 있음을 체험한 순간이었다. 수십 건의 리뷰 댓글을 달고, 그 분에게 체크인할 수 없음을 전자우편으로 알렸다. 다음 날 그 분은 이 도구의 위력에 대해 감탄을 하셨다. 시스템... 프로세스... 그러한 것을 생각해보는 계기였다.

 

아직 리뷰 정책을 세우지는 못했다. 어쨌든 화두를 던져 토론을 해볼 생각이다. 내 생각에는 프로그래머가 돌아가면서 리뷰를 해야한다고 본다. 다른 사람의 코드를 보면서 다른 관점을 볼 수 있는 좋은 기회이다. 또한 다른 사람이 리뷰할 것을 생각한다면, 좀더 긴장할 수 밖에 없다. 그 만큼 코드의 품질이 높아지리라 생각한다. 우리는 더 나은 세상을 향해 가야한다. 코드리뷰는 프로그래머에게 그러한 수단 중의 하나라고 믿게 되었다.