코드 리뷰 룰을 3번 바꾸면서 배운 것

팀이 작으면 코드 리뷰가 형식적으로 흐르기 쉽다. “사실상 혼자 짜고 혼자 머지”가 되거나, 반대로 완벽주의적 리뷰로 PR 이 일주일씩 쌓인다. 우리는 두 극단을 모두 겪으면서 규칙을 세 번 고쳤다.

1버전: 규칙 없이 시작

초기에는 별도 규칙 없이 그냥 서로 PR 을 만들고 봐줬다. 세 명이라 빠르게 맥락을 공유할 수 있었고, 처음 몇 달은 잘 돌아가는 것처럼 보였다.

문제는 마감이 다가오면 리뷰가 생략됐다는 것이다. “긴급하니까 자체 머지”가 반복되면서 리뷰 없이 배포된 코드가 나중에 버그로 돌아왔다. 리뷰가 습관이 아니라 여유가 있을 때 하는 부수 작업으로 자리잡은 결과였다.

2버전: 엄격한 규칙

반성하고 규칙을 빡빡하게 만들었다. 모든 PR 은 최소 1명 승인 필수, 리뷰 체크리스트 항목 다섯 가지, 테스트 커버리지 미달 PR 은 머지 차단.

두 달 만에 문제가 드러났다. PR 이 쌓이기 시작했다. 리뷰어가 체크리스트를 다 채우려다 보니 리뷰 한 건에 30~40분이 걸렸고, 세 명 중 한 명이 바쁘면 PR 큐가 멈췄다. 게다가 형식적인 체크리스트 항목들은 실제 버그를 잡는 데 거의 도움이 안 됐다.

3버전: 지금 쓰는 방식

지금의 규칙은 두 가지다.

첫째, 승인 없이는 머지 안 한다. 이것만큼은 유지했다. 단 승인 기준을 낮췄다. “이 코드가 배포돼도 괜찮은가?”를 판단하는 것이지, “내가 이렇게 짰을까?”가 아니다.

둘째, 리뷰어는 하나만 의견을 낸다. 모든 팀원이 한꺼번에 코멘트를 달면 작성자가 어디서부터 응답해야 할지 혼란스럽다. 주 리뷰어 한 명이 코어 피드백을 내고, 나머지는 Optional 로 한두 줄 이내 코멘트만 달 수 있다.

규칙을 바꾸면서 배운 것

규칙이 효과적인지는 “따르는 사람이 편한가”로 판단해야 한다는 것을 알았다. 작성자와 리뷰어 모두 부담이 낮을수록 규칙이 꾸준히 지켜진다. 무거운 프로세스는 위기가 오면 제일 먼저 건너뛰게 된다.

또 리뷰의 목적이 “찾기”가 아니라 “공유”에 가깝다는 것도 중요한 깨달음이다. 버그를 잡는 것만큼이나 팀원이 서로 코드베이스를 파악하는 것이 리뷰의 실질적인 가치다. 그 관점에서 보면 30분짜리 꼼꼼한 리뷰 한 번보다 5분짜리 빠른 리뷰 여섯 번이 팀 전체에 더 유익할 수 있다.

— by mings