(여기에서 이야기하는 내용은 4년 반 동안 한국 마이크로소프트 오피스 개발팀에서 겪은 내용을 바탕으로 한 것이다. 마이크로소프트 회사 전체에 대한 이야기가 아님을 강조한다.)

코드 리뷰를 시작하려면 먼저 코드 픽스를 쓴 개발자가 커맨드 라인 명령을 실행하여 리뷰를 보낸다. 명령을 실행하면, 해당 코드를 리뷰 할 To list 와 CC list 을 쓰고 제목과 간단한 코멘트를 쓰게 된다.

관례상 To list 에는 반드시 리뷰를 해줘야 할 리뷰어들을 추가하고, CC 에는 리뷰 진행을 알고자 하는 이와 팀의 메일주소를 추가한다. 그렇게 함으로써, 동료들의 리뷰 참가를 독려한다.

이후 코멘팅은 이메일로 진행된다. 이메일 쓰레드의 시작에는 코드 체인지를 볼 수 있는 링크와 체인지에 대한 설명들이 적혀 있다. 이 링크는 윈도우 파일 공유로 열려 있는 곳을 가리키는데, 그 곳에는 파일의 원본과 변경 본을 압축해놓은 패키지 파일이 있다.

리뷰어 개인 별로 편차가 있으나, 리뷰는 제법 철저하게 이뤄진다. 리뷰어가 지적한 점들에 대해 합당한 대답을 내놓거나 그렇지 않으면 코드를 고쳐야 한다. 이메일로 코멘팅하고 수정하는 과정을 반복하여, 더 이상의 이슈가 없을 때까지 진행한다.

리뷰어가 지적하는 내용은 코딩의 기초에 대한 것일 수도 있고, 해당 코드를 소유하고 있는 팀의 코딩 컨벤션에 대한 것일 때도 있다. 크게는 함수 디자인과 클래스 디자인에 대한 것을 지적 받기도 한다. 요는 이 과정을 통해 코드가 좋아진다는 것을 모두가 믿고 동의하는 것이다.

이메일 기반의 코드리뷰 장점은 단순하고 쉽다는 것이다. 단점은 리뷰 코멘트 자체에 대한 피드백을 주기가 쉽지 않다는 것이고, 따로 손을 쓰지 않으면 리뷰한 내용들이 따로 히스토리로 남지 않기 때문에 팀의 리뷰능력을 향상시키기에는 도움이 크게 되지 못한다.

이메일 기반의 방식은 아주 오랜 기간 사용되어 온 것이고, 언급했던 단점을 극복하고자 여러 가지 툴들이 사내에 개발되어 나와 있기도 하다. 단점들을 보완하고, 코드 체인지를 좀 더 편하게 보기 위해 다양한 기능이 추가 및 개선되었다. 여러 종류의 시도가 있었다.

그러나 마이크로소프트 밖에서는 이런 도구들의 혜택을 볼 수 없다. 다행스럽게도 오프소스로 되어 있는 코드 리뷰 시스템들이 몇 있다. 다음에는 그것들에 대해 알아보고, 그 중에서 구글 코드 리뷰 시스템을 셋업하는 내용을 얘기해보련다.