코드 리뷰와 결재 서류를 비교하는 글은 많지 않다. 코드 리뷰는 특별한 무엇처럼 설명한다. 정말 다를까.
용어 비교
코드 리뷰와 결재 서류 관련 용어를 살펴보자
| 코드 리뷰 | 결재 서류 | |
| 작성 내용 | 코드 | 문서 |
| 작성자 | 개발팀원 누구나 | 부하 직원 |
| 검토자 | 개발팀원 누구나 | 상사 |
| 승인 요청 방법 | 코드 병합 요청(PR, Pull Request) 통해서 | 결재 서류를 통해서 |
| 승인 주체 | 개발팀원 누구나 | 상사 |
차이점은?
결재는 상하관계가 명확하지만 코드 리뷰는 상대적으로 상하관계의 영향을 덜 받는다. 결재는 부하 직원이 상관한테 요청하는 단방향이지만, 코드 리뷰는 팀원이 다른 팀원이나 팀장에게, 팀장이 개발팀원들에게 리뷰를 요청하는 쌍방향이다. 물론 코드 리뷰에서도 당연히 상하관계 영향이 있다. 팀원이 CTO나 팀장의 리뷰를 더 반영하게 된다. 여기까지 보면 코드 리뷰는 결재 서류와 다르다.
개발조직의 관료화와 코드 리뷰의 결재 서류화
개발조직의 규모가 커질수록 관료화된다. 관료제가 나쁜 것은 아니다. 큰 규모의 조직에는 필수적이다. 관료화될수록 코드 리뷰는 결재 서류에 가까워진다. 코드 오류로 인한 장애 책임을 개발팀 책임자가 짊어질 수밖에 없기 때문이다. 책임자는 승인에 신중해질 수밖에 없고 팀원들의 승인을 얻었어도 책임자 승인 없이는 코드는 반영되지 못한다. 책임자는 대부분 상사이니 결재 서류 처리 방식과 같아진다.
큰 개발조직에서 코드 리뷰는 결재 서류
작은 개발조직에서는 상호리뷰가 주를 이루니 작성자 판단에 따라 리뷰를 일부만 반영하거나 할 수 있다. 하지만 큰 개발조직에서는 결재 서류라고 생각하는 게 좋다. 팀장의 리뷰는 반드시! 반영해야 한다. 팀장의 리뷰가 치명적 오류를 안고 있다면 당연히 보고해야 한다. 그렇지 않고 결과에 큰 차이가 없다면 바로 반영하는 게 좋다. 팀장은 회의도 많고 바쁘다. 결과에 차이가 없는 안건으로 토론하면 승인이 늦어져 다음 작업까지 대기시간만 길어진다. 또 팀장 입장에서 팀원이 자신의 리뷰를 무시한다고 느껴 본인 평판이 안 좋아질 수도 있다. 중요한 사안이라면 토론하되 그렇지 않다면 빠르게 반영하자.
팀장은 잡지나 신문의 편집장
개발자는 프로그래밍 언어로 글을 쓰는 것과 같다. 애플리케이션 등 최종 생산물을 여러사람이 나눠서 작성하고 있는 것이다. 그런 차원에서 전체적으로 생산물의 품질을 관리하고 책임지는 사람이 필요하다. 잡지나 신문의 편집장처럼 공동 저작물의 최종 승인자가 바로 팀장이라고 이해하면 편하다. 잡지 기사를 쓰지만 편집장의 승인을 얻지 못한 기사는 잡지에 실리지 못한다. 코드를 작성하지만 승인을 얻지 못하면 애플리케이션에 포함되지 못한다.