코드 리뷰 품질은 댓글 수보다 줄어드는 추이로 본다

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

사흘 동안 작업한 뒤 수십 개의 리뷰 댓글이 달렸다면 작성자의 능력보다 팀이 언제 합을 맞췄는지를 먼저 봐야 한다. 새 동료는 큰 작업을 끝낸 다음에야 팀이 전혀 다른 구조를 쓴다는 사실을 알 수 있고, 배포 일정은 이미 가까울 수 있다. 그대로 머지하기도, 촉박하게 다시 만들기도 어렵다.

사흘 뒤 수십 개의 댓글이 달렸다면 합을 너무 늦게 맞춘 것이다

해법은 작업을 더 일찍 보이게 만드는 것이다. 새 동료에게는 작은 일부터 맡기고, 구현이 끝나기 전에 드래프트 PR을 연다. 개념, 테이블 형태나 첫 구현 조각만 있어도 방향을 싸게 바꿀 때 동료가 구체적으로 리뷰할 수 있다. 드래프트는 예상보다 오래 막힌 사람에게도 유용하다. 완성된 PR을 기다리지 않고 진행 중인 작업을 비동기로 보면 일의 크기와 고민 중인 결정을 파악할 수 있다.

기계가 끝낼 댓글은 자동화한다

포매팅, 공백, 린트처럼 결과가 정해진 규칙은 포매터, 검사 도구나 빌드 작업으로 막는다. 사람의 리뷰에서 같은 지적을 반복하는 것은 합을 맞추는 일이 아니라 잡음이다.

사람은 팀의 개념, 시스템 설계, 구현 방식과 로컬 컨벤션을 보는 데 더 가치가 있다. 새 동료에게 이를 꼼꼼히 설명하는 리뷰는 함께 일의 합을 맞추겠다는 신호다. 외부 권위의 이름을 답으로 내세우기보다 이 제품과 팀이 왜 그렇게 선택했는지를 말해야 한다.

개수가 아니라 줄어드는 방향을 본다

새로 합류한 사람이나 막 만들어진 팀에는 댓글이 많은 것이 자연스럽다. 함께 일한 지 1년이 지났는데도 같은 규모와 종류의 이견이 계속된다면 정말 합의가 생겼는지 물어야 한다. 봐야 할 지표는 소프트웨어를 함께 만드는 방식을 배우면서 반복 피드백이 줄어드는가다.

댓글이 적은 이유는 판단이 잘 맞아서일 수도, 아무도 자세히 보지 않아서일 수도 있다. 댓글이 많은 이유도 좋은 교육일 수도, 너무 늦게 도착한 피드백의 비용일 수도 있다. 내용과 추이가 그 차이를 보여준다. 목표는 조용한 PR이 아니라 중요한 차이를 일찍 잡고 지나간 논쟁을 덜 반복하는 팀이다.