"코드를 짜는 것은 병목이 아니다. 병목은 항상 리뷰였다." — Hacker News, 2025
개발자로 일하다 보면 가끔 이런 팀원을 만난다.
본인 업무가 바쁘다는 이유로 다른 팀원의 PR을 일주일 넘게 방치하는 사람. 그러다가 다음 주가 돼서야 PR을 열어보고, 로직에 대해 뒤늦은 질문을 던진다. 그 사이 머지되지 못한 PR을 base로 새로운 PR이 생겨나고, 또 그 PR을 기반으로 한 PR이 줄줄이 대기한다. 개발팀의 PR 스택이 자꾸 쌓여간다.
이 상황을 겪어본 사람이라면 안다. 그 답답함이 단순한 불편 수준이 아니라는 걸.
숫자로 보는 PR 리뷰 지연의 비용
팀 내에서의 감정적 불만을 떠나, 숫자로 보면 이 문제는 더욱 명확해진다.
소프트웨어 엔지니어링 메트릭 분석 회사 LinearB가 약 100만 개의 PR을 분석한 결과, PR은 평균 4.4일을 리뷰 대기 상태로 보낸다. 전통적인 팀에서 44%의 개발팀이 느린 코드 리뷰를 배포 파이프라인의 가장 큰 병목으로 꼽았다. 더 충격적인 수치는 이것이다: 비효율적인 리뷰 문화로 인해 개발자 한 명이 매주 평균 5.8시간을 낭비한다. 대형 기업에서는 67%의 개발자가 PR 승인을 받기까지 일주일 이상 기다린다고 응답했다.
5.8시간. 개발자의 한 주 근무 시간(40시간 기준)의 거의 15%다. 이 시간을 팀원 수만큼 곱해보면, PR 리뷰 지연 하나가 팀 전체에 끼치는 비용이 얼마인지 금세 계산이 나온다.
그리고 이건 순수하게 '기다리는 시간'만의 이야기다. 거기엔 컨텍스트 스위칭 비용, 머지 충돌을 해결하는 시간, 리뷰 대기 중 다른 작업을 진행하다가 다시 PR로 돌아왔을 때 상황을 재파악하는 비용은 포함되지 않는다.
코드를 짜는 것은 병목이 아니다
Hacker News에는 이 주제로 매우 인상적인 쓰레드가 있다. 제목은 "Writing Code Was Never the Bottleneck"이다.
현업 개발자들의 반응은 놀랍도록 일치한다. 코드를 쓰는 것이 문제인 적은 거의 없다. 진짜 병목은 항상 리뷰와 통합에 있었다. AI 코드 생성 도구가 등장하면서 이 불균형이 더 선명하게 드러났다. 주니어 개발자가 LLM의 도움으로 하루 만에 일주일치 코드를 짜내는 시대에, 시니어 개발자의 리뷰 부담은 전례 없이 커졌다.
한 시니어 개발자는 이렇게 표현했다.
"Junior developers can produce code faster than ever, but the effort required to review that code hasn't decreased — in many cases, it's increased."
결국 PR 리뷰는 공유 자원이다. 팀에서 누군가의 리뷰 속도가 느려지면, 그 비용은 해당 팀원에게만 귀속되지 않는다. 리뷰를 기다리는 모든 팀원에게 분산된다.
"바쁘다"는 것은 유효한 면죄부가 아니다
이 글을 쓰는 이유는 특정인을 비난하기 위함이 아니다. 솔직히 말하면, 나 역시 바쁜 시기엔 리뷰를 미룬 적이 있다. 아마 많은 개발자가 그럴 것이다.
그러나 일상적으로, 그리고 팀 내 논의 끝에도 리뷰가 지연된다면, 그건 단순한 업무 부하 문제가 아니다.
이 문제를 팀에 제기했을 때 "연속 알림은 압박감이 심하다"는 이유로 거부당했다는 경험을 들었다. 충분히 이해한다. 슬랙 알림이 5분마다 울리는 건 당연히 싫다. 그런데 그 거부의 이면을 들여다보면, 결국 이런 함의가 숨어 있다:
"내 편의가 팀원들의 생산성 손실보다 중요하다."
이것이 이기적이지 않다고 말할 수 있을까?
다른 팀원들 역시 바쁘다. 본인이 바쁜 만큼, 혹은 그 이상으로. 차이가 있다면 그들은 바쁜 중에도 리뷰를 하고 있다는 것이다.
PR 크기의 문제인가?
흔한 반론이 있다. "PR이 너무 크다." PR 크기를 줄이면 리뷰가 빨라진다는 논리다.
맞는 말이다. 코드 리뷰 분야에서 가장 일관되게 등장하는 조언 중 하나는 PR을 400 LOC 이하로 유지하라는 것이다. 작은 PR은 리뷰가 쉽고, 버그를 잡기도 좋으며, 빠르게 통과된다.
그런데 실무는 조금 다르다. 실제 기능 구현을 하다 보면 단일 커밋 하나로 끝낼 수 있을 만큼 PR을 쪼개기 어려운 경우가 많다. 그리고 이 글에서 언급된 사례의 PR은 이미 충분히 작았다. 그럼에도 리뷰는 느렸다.
PR 크기 최적화는 분명히 도움이 된다. 하지만 그것이 리뷰 지연의 근본 원인에 대한 면죄부가 될 수는 없다.
Hacker News의 시각: 문화의 문제
Hacker News에서 코드 리뷰 지연에 관한 쓰레드를 보면 공통으로 등장하는 주제가 있다. 문화.
기술적인 해법 — PR 크기 제한, 자동화, 스택드 PR — 은 분명히 도움이 된다. 하지만 그것들은 어디까지나 도구다. 도구가 제대로 작동하려면 팀 전체가 리뷰를 '필수 업무'가 아닌 **'팀에 대한 기여'**로 인식하는 문화가 선행되어야 한다.
한 댓글에서 이런 표현이 있었다.
"Management must treat code review as a first class citizen of your team culture. Reviews shouldn't feel like lost productivity."
리뷰가 '손해'처럼 느껴지는 팀이 있다. 리뷰에 시간을 쓰면 내 개발 속도가 줄어든다고 느끼는 것이다. 그러나 이 프레임은 근본적으로 잘못됐다. 팀의 생산성은 개인의 커밋 속도의 합이 아니다. 코드가 얼마나 빠르게, 안정적으로 프로덕션에 반영되는지가 팀의 생산성이다.
내 커밋 속도가 아무리 빨라도 PR이 머지되지 않으면 의미가 없다. 리뷰가 병목이라면, 리뷰를 푸는 것이 곧 팀 전체의 속도를 올리는 일이다.
리뷰는 팀원에 대한 존중이다
IBM의 연구에 따르면 코드 리뷰 단계에서 결함을 잡는 비용은 프로덕션에서 잡는 것보다 10~100배 저렴하다. 리뷰는 버그를 막는 것만이 아니라, 지식을 공유하고 코드베이스의 일관성을 유지하는 행위이기도 하다.
그런데 나는 여기에 한 가지를 더 추가하고 싶다.
리뷰는 팀원에 대한 존중의 표현이다.
내가 작성한 코드에 대해 누군가 시간을 들여 생각해주고 피드백을 준다는 것은, 그 사람이 나의 작업을 진지하게 여긴다는 신호다. 반대로, 리뷰 없이 PR이 수일째 방치된다는 것은 그 개발자에게 이런 메시지를 보내는 셈이다: "네 작업은 내 일정보다 덜 중요해."
의도했든 의도하지 않았든.
그래서 어떻게 해야 하는가
솔직히 말하면, 시스템적인 해법에 앞서 먼저 필요한 것은 인식의 전환이다.
나의 리뷰가 느려지면 팀원의 비용이 늘어난다는 것. 내가 바쁠 때도 팀원들은 바쁘다는 것. PR 스택이 쌓이는 건 팀원의 게으름이 아니라 리뷰 부채가 쌓이는 것이라는 것.
기술적인 조언을 원한다면:
- PR은 가능한 한 작게, 명확한 scope으로 만들어라.
- 하루에 한 번이라도 PR 목록을 확인하는 습관을 가져라.
- 리뷰 코멘트는 blocker / suggestion / nitpick 을 명확히 구분해라.
- 스택드 PR(stacked PR) 패턴을 도입해 의존성 PR이 생기는 구조를 개선해라.
그러나 이 모든 것보다 선행되어야 하는 건, 팀원의 PR이 머지되지 않고 있다는 것을 내 문제로 인식하는 태도다.
마지막으로, 이 글이 불편하게 읽히는 사람이 있다면 그것도 괜찮다. 불편함이 인식의 시작이니까.
좋은 코드는 빠른 리뷰에서 나오고, 빠른 리뷰는 팀원을 존중하는 문화에서 나온다. 오늘 열려 있는 PR 한 번 확인해보는 것부터 시작이다.