13년 차 엔지니어가 말하는 코드 리뷰 문화 만들기

코드 리뷰에 대한 기억이 두 가지 있다.

하나는 주니어 때 PR을 올렸다가 시니어로부터 30개의 코멘트를 받은 날이다. 대부분 “이렇게 하면 안 됨"이라는 단정적 표현이었고, 이유 설명은 없었다. 이틀 동안 PR을 수정했는데 결국 “그냥 내가 다시 짤게요"로 끝났다. 그날 이후 한동안 PR 올리는 게 두려웠다.

또 하나는 같은 시기 다른 팀의 시니어 엔지니어가 내 코드에 남긴 코멘트다. “이 방식도 동작하는데, 이렇게 바꾸면 나중에 테스트 짜기가 훨씬 쉬워질 거예요. 어떻게 생각하세요?” — 질문 형태였다. 그 코멘트 하나가 의존성 주입 패턴을 이해하는 계기가 됐다.

코드 리뷰는 같은 도구인데 전혀 다른 결과를 만든다.

코드 리뷰가 망가지는 이유

#

대부분의 팀에서 코드 리뷰가 제대로 안 되는 원인을 정리하면 크게 세 가지다.

1. 권력 불균형

#

“시니어가 주니어의 코드를 검열하는 것"이라는 프레임이 팀에 자리잡으면 리뷰는 위계 관계가 된다. PR을 올리는 행위 자체가 “내 무지를 들킬 수 있는” 위험한 일이 된다. 이렇게 되면:

• 주니어는 PR 크기를 키운다. 어차피 지적받을 거 한 번에 몰아서 올리겠다는 심리
• 리뷰어는 지엽적인 스타일 문제에 집중한다. 실질적인 로직 검증은 어렵고 스타일은 지적하기 쉬우니까
• 승인이 빨리 나오는 PR만 올리게 된다. 불확실한 설계는 아예 혼자 결정해버린다

2. 리뷰 타이밍 문제

#

PR을 올리고 3일이 지나도 리뷰가 안 달린다. 리뷰어는 다른 급한 일에 치여있고, 작성자는 다음 작업을 시작했는데 갑자기 3일 전 코드로 돌아가야 한다. 컨텍스트를 다시 불러오는 비용이 발생하고, 빨리 끝내고 싶어서 리뷰 코멘트를 대충 처리하게 된다.

3. 목적 불명확

#

“버그를 잡는 것”, “코드 품질을 높이는 것”, “지식 공유”… 팀마다 코드 리뷰의 목적이 다르고, 심지어 같은 팀 내에서도 사람마다 다르게 생각한다. 명시적으로 합의되지 않은 목적은 충돌을 만든다.

문화를 바꾸는 구체적인 방법

#

PR 크기 제한 — 규칙이 아니라 이유 설명하기

#

“400줄 이하로 PR 올리세요"라고 규칙으로 정하면 반발한다. 대신 이유를 설명한다:

“PR이 800줄이 넘으면 리뷰어가 집중력을 잃어서 실제 버그를 놓친다는 연구 결과가 있어요. 우리가 코드 리뷰에서 진짜 얻고 싶은 건 스타일 피드백이 아니라 논리 검증이잖아요.”

이유를 이해한 사람은 스스로 PR을 나눈다. 이유를 모르는 사람은 규칙을 우회한다.

기능이 커서 어쩔 수 없이 PR이 클 때는 Draft PR을 먼저 올려서 설계 방향을 먼저 논의한다. 코드가 다 짜진 후에 방향이 틀렸다고 하면 양쪽 다 고통스럽다.

코멘트 레벨링 시스템

#

구글, 네이버 등 여러 회사에서 쓰는 코멘트 레벨 시스템이다:

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

[blocking] 반드시 수정해야 머지 가능한 문제
- 버그, 보안 취약점, 설계 결함

[nit] 사소한 스타일 취향 차이
- 변수명 선호도, 공백 등
- 수정 여부는 작성자 판단

[question] 이해 안 되는 부분 질문
- "이 부분이 왜 이렇게 구현됐는지 물어봐도 될까요?"

[suggestion] 더 나을 수 있는 방향 제안
- 강제 아님, 논의 시작점

[praise] 잘 된 부분 칭찬
- 좋은 구조, 영리한 해결책

이 시스템의 핵심은 [nit]의 역할이다. 작성자는 [nit] 코멘트를 모두 반영할 의무가 없다. 리뷰어의 취향을 반영할 의무도 없다. 이렇게 되면 리뷰어도 사소한 것들을 눈치 없이 지적할 수 있고, 작성자도 중요한 것과 사소한 것을 구분할 수 있다.

24시간 리뷰 응답 SLA

#

리뷰 요청이 오면 24시간 이내 초기 응답을 원칙으로 정한다. 전체 리뷰를 완료하라는 게 아니라 “내일까지 볼게요” 또는 “당장 못 보면 이 사람한테 부탁할게요"라는 응답이라도 하는 것이다.

이게 없으면 PR이 쌓인다. PR이 쌓이면 사람들이 점점 더 큰 PR을 올린다. 악순환이 시작된다.

응답 SLA를 지키려면 팀 캘린더에 리뷰 타임을 고정하는 것도 방법이다. 오전 10시 30분, 점심 후, 이런 식으로 하루 두 번 리뷰를 몰아서 하면 딥 워크를 방해하지 않으면서도 SLA를 지킬 수 있다.

칭찬을 코드 리뷰에 넣기

#

이게 어색하게 느껴지는 팀이 많다. 한국 개발 문화에서 특히 그렇다. 하지만 [praise] 코멘트는 팀 문화를 바꾸는 데 생각보다 강력하다.

“이 에러 핸들링 방식 정말 깔끔하네요. 나도 이 패턴 써야겠어요” 같은 코멘트는 작성자의 사기를 높이는 것뿐 아니라 팀 전체에 좋은 패턴을 알리는 효과가 있다. 나쁜 코드를 찾아내는 것만이 리뷰의 목적이 아님을 보여주는 것이기도 하다.

AI 시대의 코드 리뷰

#

2026년에는 코드 리뷰 자체가 바뀌고 있다. Cursor나 Copilot으로 생성된 코드가 PR에 올라오는 게 일상화됐다. 이 변화가 리뷰에 미치는 영향:

긍정적: AI가 생성한 코드는 기본적인 패턴은 잘 지키는 경우가 많아서 표면적인 품질은 높다. 리뷰어가 사소한 스타일에 시간을 덜 쓰게 된다.

부정적: AI 코드는 프로젝트 특유의 컨텍스트를 모른다. 이 모듈이 왜 이런 구조를 가지는지, 과거에 이 방향을 시도했다가 왜 포기했는지 — 이런 히스토리를 AI는 모른다. 리뷰어가 “왜 이 접근법을 선택했는지"를 더 깊이 물어봐야 한다.

그래서 AI 시대에 오히려 중요해지는 코드 리뷰 능력이 있다: 의도 파악이다. 코드 자체가 아니라 “이 PR이 해결하려는 문제가 무엇이고, 이 접근법이 최선인가"를 보는 것. 이건 AI가 자동으로 대신할 수 없는 부분이다.

시니어 엔지니어의 코드 리뷰 원칙

#

13년을 돌아보며 내가 지키려는 원칙들:

1. 코드를 비판하되 사람을 비판하지 않는다

“이 코드는 메모리 누수 가능성이 있어요"와 “이렇게 짜면 어떡해요” 중 하나만 가능하다. 전자는 문제를 가리키고, 후자는 사람을 가리킨다.

2. 이유 없는 변경 요청은 안 한다

“저는 이 방식이 더 좋아요"는 리뷰 코멘트가 아니다. “이렇게 바꾸면 다음과 같은 이유로 나중에 X 상황에서 유리합니다"가 되어야 한다. 이유를 설명하지 못하면 내가 그냥 취향 강요를 하는 것일 수 있다.

3. 모르면 질문한다

시니어라도 모르는 게 있다. 코드를 보다가 왜 이렇게 했는지 이해 안 되면 “이 부분이 왜 이런 방식인지 설명해주실 수 있어요?“라고 질문한다. 내가 틀렸을 수도 있고, 작성자가 설명하면서 스스로 문제를 발견할 수도 있다.

4. 작성자의 맥락을 이해하려 한다

야근을 하면서 짠 코드와 여유 있게 짠 코드는 다르다. 마감 압박이 있었는지, 이 부분이 실험적인 시도인지, 이미 기술 부채를 인식하고 있는지 — 컨텍스트를 알면 리뷰의 방향이 달라진다. 코드 작성자에게 상황을 물어보는 것도 리뷰의 일부다.

코드 리뷰 문화 측정하기

#

문화가 잘 되고 있는지 측정하는 지표들:

• 평균 PR 크기: 줄어들면 건강해지고 있는 것
• 리뷰 응답 시간: 24시간 이내 비율이 높을수록 좋음
• PR 생존 시간: 오픈에서 머지까지의 시간이 짧을수록 좋음
• 리뷰 없이 셀프 머지 비율: 낮을수록 리뷰 문화가 정착된 것
• 신입 팀원의 첫 PR 경험: 입사 후 첫 PR에 대한 인상을 주기적으로 물어본다

마지막 것이 가장 중요하다. 신입이 첫 PR을 올리고 어떤 경험을 하는지가 그 팀의 리뷰 문화의 진짜 수준이다.

코드 리뷰는 버그 잡는 도구가 아니라 팀이 함께 성장하는 의식(ritual)이다. 그 의식이 잘 작동하는 팀은 개인이 성장하고, 개인이 성장하는 팀은 오래 지속된다.