코드 리뷰를 받는 쪽의 준비 — PR을 읽기 쉽게 만드는 법
리뷰 품질은 리뷰어보다 PR을 올리는 쪽의 준비에 더 좌우된다. 준비 항목과 크기 기준.
리뷰 품질은 올리는 쪽이 좌우한다
리뷰가 형식적으로 끝나거나("LGTM") 엉뚱한 곳에 집중되는 경우, 원인의 상당 부분은 PR 쪽에 있다. 무엇을 봐야 할지 모르는 상태로 200개 파일을 받으면 누구도 제대로 못 본다.
크기 — 가장 중요한 변수
변경 규모가 커질수록 리뷰 밀도가 떨어진다. 널리 인용되는 기준은 한 PR당 400줄 내외다. 그 이상에서는 발견되는 문제 수가 오히려 줄어든다는 관찰이다.
큰 작업을 나누는 방법:
- 구조 변경과 기능 추가를 분리 — 파일 이동·이름 변경은 별도 PR로
- 의존 순서대로 — 기반 → 사용부 순으로 나눠 올림
- 동작 없는 준비 PR — 인터페이스만 먼저, 구현은 다음에
올리기 전 셀프 리뷰
diff를 스스로 한 번 읽는다. 이 단계에서 걸러지는 것들:
- 디버그용 로그·주석 처리한 코드
- 임시로 넣은 하드코딩 값
- 의도치 않게 포함된 무관한 파일
- 포매터가 건드린 대량 변경
특히 마지막 항목이 흔하다. 포매팅 변경이 섞이면 실제 변경이 묻혀서 리뷰어가 볼 수 없다.
PR 설명에 들어갈 것
```markdown
무엇을
(변경의 요약 한두 줄)
왜
(배경 — 어떤 문제 때문에)
어떻게
(접근 방식과 주요 판단)
확인 방법
(리뷰어가 어떻게 검증할 수 있는지)
봐줬으면 하는 부분
(불확실한 설계 판단, 성능이 걱정되는 지점)
```
마지막 항목이 실질적으로 리뷰 품질을 바꾼다. "여기 방식이 맞는지 모르겠다"고 명시하면 리뷰어가 그 지점에 시간을 쓴다. 명시하지 않으면 전체를 균등하게 훑다가 놓친다.
인라인 코멘트를 스스로 달기
복잡한 부분에는 PR 작성자가 먼저 코멘트를 단다.
```
// 이 부분은 기존 로직과 순서가 반대인데,
// A가 B보다 먼저 초기화돼야 해서 바꿨습니다.
```
리뷰어가 "왜 이렇게 했지?"를 물어보는 왕복 한 번이 줄어든다.
코멘트에 대응하는 방식
동의하지 않는 코멘트를 받았을 때 두 가지 나쁜 대응이 있다.
- 무조건 반영 — 근거 없이 바꾸면 나중에 같은 문제가 반복된다
- 침묵 — 답글 없이 두면 리뷰어는 무시당했다고 느낀다
근거를 적어 답한다.
```
말씀하신 방식도 고려했는데, 이 경우 X 상황에서 순서 보장이
안 되어서 현재 방식을 택했습니다. 다른 방법이 있을까요?
```
논의가 길어지면 PR 밖(회의·메신저)에서 정하고 결론만 남기는 편이 낫다.
반영 후 알리기
수정한 뒤 그냥 두면 리뷰어가 언제 다시 볼지 모른다. 각 코멘트에 "반영했습니다" 답글을 달거나, 전체 요약을 남긴다.
```
- 1번: 반영 (커밋 abc123)
- 2번: 반영하지 않음 — 위 논의 참고
- 3번: 별도 이슈로 분리
```
무엇이 처리됐고 무엇이 남았는지가 한눈에 보이면 재리뷰가 빨라진다.
최종 수정 2026-08-28