시니어 엔지니어가 주니어에게 절대 말 안 해주는 코드 리뷰 꿀팁

코드 리뷰가 두려웠던 적이 있습니다. 주니어 시절, 열심히 작성한 코드에 빨간 코멘트가 열 개씩 달리면 기분이 바닥을 쳤습니다. 반대로 시니어가 되어 리뷰어 입장이 되고 나서는 “이걸 어떻게 말해줘야 하지?“를 고민했습니다.

13년 동안 리뷰이와 리뷰어를 반복하면서, 코드 리뷰를 잘한다는 게 단순히 버그를 찾는 기술이 아니라는 걸 알게 됐습니다. 사람을 상대하는 커뮤니케이션이고, 팀 문화를 만드는 행위입니다.

아무도 알려주지 않는 코드 리뷰 실전 노하우를 공유합니다.

리뷰어 입장: 내가 저질렀던 실수들

#

실수 1: “이건 틀렸습니다” 스타일

#

초반에 제가 자주 썼던 코멘트 스타일입니다.

1
2
3

❌ "이렇게 하면 성능이 나쁩니다. 고치세요."
❌ "왜 이렇게 복잡하게 짰나요?"
❌ "이 코드는 이해가 안 됩니다."

모두 틀린 말은 아닙니다. 하지만 받는 사람 입장에서는 공격받는 느낌입니다. 코드를 비판받는 게 아니라 내가 비판받는 것처럼 느낍니다.

같은 의미를 다르게 표현하면 분위기가 완전히 바뀝니다.

1
2
3

✅ "이 부분에서 O(n²) 복잡도가 발생할 수 있는데, HashMap을 쓰면 O(n)으로 줄일 수 있을 것 같아요. 어떻게 생각하시나요?"
✅ "제가 이해를 잘 못 한 걸 수도 있는데, 이 로직이 어떤 케이스를 처리하는 건가요?"
✅ "더 간단하게 표현할 수 있는 방법이 있을 것 같아서요. 이런 방향은 어떨까요?"

질문 형태로, 제안 형태로 코멘트하면 대화가 됩니다. 지시가 아니라 토론이 됩니다.

실수 2: 모든 것을 지적하기

#

PR 하나에 코멘트 30개를 달았던 적이 있습니다. 작은 스타일 문제부터 아키텍처 문제까지 전부 다 지적했습니다.

리뷰이 입장에서는 어디서부터 시작해야 할지 모릅니다. 의욕이 꺾입니다. 다음 PR을 올리기가 두려워집니다.

중요한 것과 사소한 것을 구분해야 합니다.

Blocker: 반드시 수정해야 머지 가능. 보안 취약점, 데이터 손실 가능성, 심각한 버그.

Issue: 수정을 강하게 권장. 성능 문제, 유지보수 어려운 설계.

Suggestion: 선택적 개선. 더 좋은 방법이 있지만 현재도 동작함.

Nit: 완전히 사소한 것. 변수명 오타, 스타일 선호.

1
2
3
4
5
6
7
8
9

[Blocker] SQL 쿼리에 파라미터 바인딩이 없어서 SQL Injection에 취약합니다.
          f"SELECT * FROM users WHERE name='{name}'" → 반드시 수정 필요

[Issue] 이 루프가 DB 쿼리를 N번 실행합니다. N+1 문제가 발생할 수 있어요.
        JOIN이나 prefetch_related로 해결 가능합니다.

[Suggestion] 이 함수가 50줄인데, 3개 함수로 분리하면 테스트하기 편할 것 같아요.

[Nit] typo: `recieve` → `receive`

레벨을 명시하면 리뷰이가 우선순위를 파악하고 효율적으로 처리할 수 있습니다.

실수 3: 칭찬을 안 하기

#

코드 리뷰는 문제를 찾는 것만이 아닙니다. 좋은 코드도 언급해야 합니다.

1
2

✅ "이 에러 처리 패턴 정말 깔끔하네요! 다른 곳에도 적용하면 좋겠어요."
✅ "이 접근법 생각지도 못했는데, 훨씬 간단하네요. 배웠습니다."

칭찬 한 줄이 부정적 코멘트 다섯 개의 무게를 상쇄합니다. 그리고 좋은 패턴이 뭔지 팀이 암묵적으로 학습하게 됩니다.

리뷰이 입장: PR을 잘 올리는 법

#

리뷰를 받는 사람도 할 일이 있습니다. 좋은 PR은 리뷰어의 시간을 아껴줍니다.

PR 크기를 작게 유지하기

#

가장 중요한 원칙입니다. 변경 파일 20개 이상, diff 1000줄 이상의 PR은 리뷰어가 대충 보게 됩니다. 집중력의 한계가 있습니다.

작은 단위로 쪼개세요. 하나의 PR은 하나의 목적을 가져야 합니다.

1
2
3
4
5
6

❌ feat: 사용자 인증 시스템 전체 구현 (2000줄 변경)

✅ feat: 사용자 회원가입 API 추가 (300줄)
✅ feat: JWT 토큰 발급 로직 추가 (150줄)
✅ feat: 로그인 API 추가 (200줄)
✅ feat: 토큰 갱신 API 추가 (100줄)

PR 설명 잘 쓰기

#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

## 변경 사항
- 사용자 이메일/비밀번호로 JWT 토큰을 발급하는 로그인 API 추가
- bcrypt로 비밀번호 해싱, 토큰 만료 30분

## 테스트 방법
1. `POST /api/auth/login` 호출
2. body: `{"email": "test@example.com", "password": "password123"}`
3. 응답에서 `access_token` 확인

## 스크린샷 / 로그
(Swagger 화면 캡처 첨부)

## 리뷰어에게 특별히 봐주셨으면 하는 부분
- 토큰 만료 시간 설정이 적절한지 의견 부탁드립니다
- 에러 응답 형식이 다른 API와 일관성 있는지 확인 부탁드립니다

리뷰어가 컨텍스트를 파악하는 시간이 크게 줄어듭니다.

코멘트를 방어적으로 받지 않기

#

코멘트를 받으면 바로 “왜 이렇게 했냐면…” 하고 방어하는 사람들이 있습니다. 일단 들으세요.

코멘트에 동의하지 않으면 토론하면 됩니다. 하지만 감정을 배제하고, 기술적인 이유로만 논의합니다.

1
2

✅ "말씀하신 방향도 좋은데, 제가 이렇게 한 이유는 X 케이스를 처리하기 위해서였습니다.
    혹시 그 케이스를 다른 방식으로 처리하는 방법이 있을까요?"

동의하면 빠르게 수정하고 감사 인사를 합니다. 배운 점이 있다고 표현하면 리뷰어도 더 적극적으로 리뷰하게 됩니다.

팀 레벨 코드 리뷰 문화 만들기

#

개인 스킬만큼 중요한 것이 팀 전체의 코드 리뷰 문화입니다.

24시간 응답 규칙

#

코드 리뷰가 며칠씩 방치되면 개발 흐름이 끊깁니다. PR이 올라오면 24시간 이내에 리뷰를 완료하는 팀 규칙을 만들면 좋습니다. 개인이 팀 속도를 결정한다는 책임감을 줍니다.

리뷰 체크리스트 공유

#

팀이 공통으로 확인하는 리뷰 포인트를 정리해두면 리뷰 품질이 균일해집니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

## 코드 리뷰 체크리스트

### 필수 확인
- [ ] 보안: SQL Injection, XSS, 인증 누락 없는가
- [ ] 에러 처리: 예외가 적절히 처리되는가
- [ ] 테스트: 주요 로직에 테스트가 있는가
- [ ] 성능: N+1 쿼리, 불필요한 루프 없는가

### 권장 확인
- [ ] 가독성: 변수/함수명이 의도를 명확히 표현하는가
- [ ] DRY: 중복 코드가 없는가
- [ ] 문서: 복잡한 로직에 주석이 있는가

페어 리뷰 세션

#

복잡한 PR은 텍스트 코멘트보다 화상통화로 같이 보는 것이 훨씬 효율적입니다. 30분 페어 리뷰가 텍스트 코멘트 열 개보다 이해도를 높이는 경우가 많습니다.

코드 리뷰가 바꾸는 것

#

좋은 코드 리뷰 문화가 자리 잡히면 세 가지가 바뀝니다.

코드 품질이 올라갑니다. 당연한 이야기지만, 내 코드를 누군가 볼 거라는 사실만으로도 더 신경 써서 짜게 됩니다.

팀 전체 역량이 균일해집니다. A가 아는 패턴을 B가 리뷰를 통해 배웁니다. 문서화 없이도 지식이 퍼집니다.

심리적 안전감이 생깁니다. “이 코드 틀려도 누군가 잡아줄 것"이라는 믿음. 이게 있어야 개발자가 도전적인 시도를 합니다.

코드 리뷰는 기술이 아니라 문화입니다. 한 명이 잘한다고 되는 게 아닙니다. 팀 전체가 함께 만들어가는 겁니다.