코드 리뷰는 작성자가 아닌 사람이 변경을 읽고 합칠지 판단하는 과정이다. 버그를 잡는 일 말고도, 팀 모두가 코드베이스를 알게 하고(집단 코드 소유) 설계 판단과 관례를 자연스럽게 퍼뜨리는 통로가 된다. 여러 사람이 모두 놓쳐야만 결함이 새어 나가게 만드는 장치이기도 하다 → 함께 자라기 (책 개요)
기준: 완벽이 아니라 나아졌는가
Google 엔지니어링 가이드의 기준은 "완벽하지 않아도 코드베이스 전체 건강을 확실히 낫게 하면 승인한다"이다. 가이드가 꼽는 검토 항목은 아래와 같고, 가이드는 그중 전체 설계를 가장 중요하게 본다.
- 설계: 이 변경이 여기 있는 게 맞나, 지금 필요한가
- 동작: 의도대로 되나, 경계 조건·동시성은
- 복잡도: 다음 사람이 쉽게 읽고 고칠 수 있나
- 테스트, 이름, 주석, 스타일
스타일처럼 기계가 잡을 수 있는 것은 린터·포매터와 CI(Continuous Integration)에 맡기고, 사람은 1~3번에 집중한다.
잘 굴러가게 하는 습관
- 작게 올린다: 변경이 작을수록 리뷰가 빠르고 꼼꼼해진다. 리팩터링과 기능 변경은 나눈다
- 맥락을 준다: PR(Pull Request) 설명에 왜·무엇을·어떻게 확인했는지 쓴다 → 커밋 메시지와 원자적 커밋
- 댓글의 무게를 표시한다: 꼭 고쳐야 할 것과 취향(
nit:), 질문을 구분한다. 팀이 접두사 규칙(must/should/nit)을 합의해 두면 오해가 줄어든다 - 사람이 아니라 코드에 대해 말한다: "왜 이렇게 했어요?"보다 "여기서 X를 쓰면 Y가 쉬워질 것 같아요". 안전하게 질문할 수 있는 분위기가 먼저다 → 심리적 안전감
- 응답 시간을 정한다: 리뷰 대기가 길면 작업이 쌓여 PR이 커지고, 커진 PR은 다시 늦어진다
팀이 커질 때 합의를 퍼뜨리는 법
구두로 맞춘 약속은 새로 온 사람에게 전해지지 않는다. 합의는 글로 남기고 도구로 강제한다.
- 리뷰 가이드 문서(기준, 댓글 접두사, 응답 시간)를 저장소에 두고 온보딩에서 읽게 한다
- PR 템플릿에 체크리스트를 넣는다
- CODEOWNERS로 영역별 리뷰어를 자동 지정한다
- 오프라인·동기 리뷰(함께 화면 보기)는 큰 설계 변경이나 신규 입사자 온보딩에 쓰고, 그 자리의 결론을 다시 문서에 반영한다
AI가 만든 변경을 리뷰할 때 생기는 질문은 AI 시대 변경에 대한 책임 질문에 따로 정리했다.
출처: Google Engineering Practices — The Standard of Code Review · Google Engineering Practices — Small CLs