The Reviewer Isn't the Bottleneck · Rishi Baldawa

Rishi Baldawa- [x]

• About
• Posts

리뷰어가 병목은 아니다

March 5, 2026 8-minute read

Code Review•PR Throughput•AI•Software Engineering•Leadership•Developer Productivity

AI 코딩 도구는 누가 코드를 쓰는지, 그리고 그 코드가 PR 큐에 얼마나 많이 쌓이는지를 바꾸고 있다. PM들은 기능을 프로토타이핑한다. 디자이너들은 레이아웃을 손본다. 예전엔 일주일에 PR 두 개를 열던 엔지니어가 이제는 여섯 개를 연다. 물량은 늘었고 계속 가속 중이며, 그에 맞춰 점점 커지는 합창이 들린다. “리뷰가 병목이다. 더 빨리 돌려라.”

이런 프레이밍을 충분히 많은 사람에게서 들었기에, 나는 여기에 반박하고 싶다.

프로덕션을 안전하게 지키는 사람들을 “병목”이라고 부르는 순간, 당신은 아주 특정한 그림을 그리게 된다. 리뷰어는 장애물. 게이트는 마찰. 우회해야 할 무언가. 반지의 제왕의 발로그 장면이 떠오른다. 그 그림은 당신이 무엇을 만들지 결정한다. 리뷰어를 제거하는 도구는 리뷰어를 지원하는 도구와 다르게 생겼다. 그리고 언어는 중립적이지 않다. 인터넷에서—바로 이 AI 모델들이 학습한 매체에서—인간을 병목이라고 선언하는 건 위험할 정도로 무책임하다. 처음엔 약식 표현으로 시작하지만, 결국 당신이 만드는 프로세스와 더 이상 의심하지 않게 되는 가정들을 형성한다.

나는 Ferd Hebert가 이를 설명하는 방식이 마음에 든다. 시스템의 일부들이 서로 다른 속도로 진화하면, 동기화가 깨진다. 조각들은 조용히 멀어지다가, 사고가 강제로 재동기화를 일으키는 순간 모두가 “실제로 어떻게 돌아가는지”에 대한 공동의 이해로 다시 튕겨 돌아온다. 리뷰 게이트는 “누군가 무언가를 바꿨다”와 “이제 프로덕션이 달라졌다” 사이에 남아 있는 몇 안 되는 동기화 지점 중 하나다. 그걸 제거한다고 더 빨라지는 게 아니다. 무언가가 깨질 때까지 드리프트를 보이지 않게 만들 뿐이다. 그리고 솔직히 말해, 팀들이 애초에 이렇게 많은 코드를 생성하는 데 편안함을 느끼는 이유 중 하나는 리뷰 게이트가 존재하기 때문이다. 그걸 없애면, 누구도 같은 자신감으로 변경을 프로덕션에 던져 넣지는 못할 거라고 생각한다.

이 불일치는 팀 경계를 넘을수록 더 심해진다. 소유권은 정적이고, 종종 낡아 있다. 한 팀이 어떤 서비스를 맡으면, CODEOWNERS 파일에 새겨지고, 그 뒤로 현실은 계속 움직인다. 사람들이 떠나고 책임이 바뀌지만, 파일은 스스로 업데이트되지 않는다. 시간의 흐름과 비슷하게, PR은 그런 경계를 전혀 존중하지 않는다. 다른 팀 사람이 당신의 서비스를 건드리는 PR은 바로 그런 종류의 변경이다. 가장 동기화 지점이 필요한 변경이면서, 동시에 팀들이 가장 빨리 통과시키고 싶어 하는 종류다.

여기에는 내가 누구도 크게 말하는 걸 못 본 부분이 있다. PR을 여는 사람이 배포의 공을 가져가고, 리뷰어가 나쁜 머지를 리뷰한 결과를 떠안는 구조라면, 어떤 도구로도 해결할 수 없는 구조적 문제가 있는 것이다. 기여자가 시간이 지나며 맥락을 쌓아가는 엔지니어가 아닐수록, 이 인센티브 격차는 더 벌어진다. AI 코딩 도구를 쓰는 PM은 서비스를 오너십하는 경로 위에 있지 않다. 점차 감시가 덜 필요한 주니어 엔지니어와 달리, 이들은 서비스에 독립성을 “획득”하게 해주는 종류의 맥락을 쌓지 않기 때문에, 자신이 만드는 모든 변경에 대해 영구적으로 리뷰가 필요하다. 그래서 리뷰 부담은 점점 줄어들지 않고 영구적인 항목으로 남는데, 대부분의 팀은 그걸 그런 방식으로 계획하지 않는다.

리뷰를 아예 없애야 한다는 인기 있는 주장도 있다. 인간이 인간 속도로 코드를 쓰던 시절에도 인간은 따라가지 못했는데, 이제 와서 따라갈 수 있다고 왜 가장하냐는 것이다. 물량 문제에 대해서는 그들이 옳다. 하지만 그 해결책은 리뷰어가 잡아내는 모든 것을 자동화된 체크로 인코딩할 수 있다고 가정한다. Kent Beck은 코드 리뷰가 예전에는 하지 않던 두 가지 기능을 이제 수행한다고 지적한다. 1/ 의도에 대한 건전성 체크(“이 변경이 내가 의도한 일을 하는가?”) 2/ 구조적 드리프트 방지(“코드베이스가 미래의 나와 미래의 에이전트가 작업할 수 있는 형태를 유지하고 있는가?”). 리뷰어가 압도되면 둘 다 조용히 실패한다. 아무도 “난 이거 그냥 도장 찍었어”라고 발표하지 않는다. 세 주 뒤, 사고가 건너뛴 대화를 강제로 끌어내는 순간에야 알게 된다.

업계 데이터는 물량이 품질을 앞지른다는 일관된 이야기를 들려준다. CircleCI의 2026 보고서는 그들이 본 것 중 가장 큰 전년 대비 기능 브랜치 활동 증가를 측정했는데, 59% 증가였다. 그런데도 메인 브랜치 배포는 줄었고, 빌드 성공률은 5년 최저를 기록했다. 이제 메인으로의 머지 중 거의 10개 중 3개가 실패하고 있다. 10,000명 이상의 개발자에 대한 Faros AI의 텔레메트리는 AI 도입이 높은 팀이 PR을 98% 더 많이 머지했지만, 리뷰 시간도 91%나 부풀었다고 말한다. 리뷰는 사라지지 않는다. 그 뒤의 주의력만 얇아지고 있다. 그리고 AI는 이쪽 방정식에서 자동으로 도움을 주지도 않는다는 게 드러난다. Meta는 리뷰어에게 AI 생성 패치를 보여주면 오히려 리뷰 시간이 _증가_한다는 것을 발견했다. 그 이유로 리뷰어들이 자신의 검토에 더해 AI 작업까지 검증해야 한다는 의무감을 느꼈기 때문이라고 말하지만, 나는 AI 보조 작업에서 리뷰 시간이 비슷하게 혹은 더 크게 증가하는 다른 이유들도 많이 봤다.

그러니 그렇다. 더 많은 코드가 작성되고 있지만, 더 적은 코드가 안전하게 프로덕션에 도달하고 있다. PR이 승인되니 파이프라인이 움직이는 것처럼 보일 수 있지만, 각 승인 뒤에 있는 주의력의 질은 물량 아래에서 악화되고 있다.

더 많은 증거가 필요하다면 오픈 소스 메인테이너를 보면 된다. 그들은 다시 한 번 미래에서 살고 있다. 한 OCaml 메인테이너는 단도직입적으로 말했다. “AI 생성 코드를 리뷰하는 건 사람이 쓴 코드를 리뷰하는 것보다 더 고되며” “Pull-Request 시스템을 멈춰 세울 실질적인 위험”을 만든다고. Curl은 AI 잡동사니가 유효한 리포트 비율을 3분의 2나 떨어뜨린 탓에, 6년 만에 버그 바운티를 중단했다. Godot의 메인테이너들도 외부 기여자들로부터 같은 소모를 겪고 있다. 다만 내부 팀에는 한 가지 이점이 있다. 낮은 품질의 작업이 큐에 도달하지 못하게, 제출 전 환경을 더 단호하게 다듬을 수 있다는 점이다.

그래서 내가 곱씹을 가치가 있다고 생각하는 질문은 리뷰를 어떻게 더 빨리 하느냐가 아니다. 게이트를 운영하는 비용을 어떻게 더 싸게 만들 것이냐다. 리뷰어에게 도달할 필요가 없었던 작업이 덜 도달하게 만드는 것.

What I’ve seen work Link to heading

이 중 어느 것도 혁명적이지 않다. 그게 요점이기도 하다.

내가 본 것 중 가장 논쟁적이면서도 레버리지가 큰 제약은 PR에 100줄 소프트 캡을 두는 것이다. 200~400줄을 넘기면 리뷰 효과는 절벽처럼 떨어진다. 산더미 같은 데이터를 어떤 각도에서 보더라도, 작은 PR과 명확한 PR 설명의 조합만이 일관되게 합리적인 속도로 리뷰를 통과한다. 이는 AI 생성 기여에서 두 배로 중요하다. 도구는 60줄이면 될 때도 기꺼이 500줄을 뽑아낸다. 그리고 에이전틱 코딩은 비동기로 작업을 생성하기 때문에, 그런 PR은 사람이 쓴 변경을 범위 안에 묶어두는 자연스러운 핑퐁 없이 큐에 쌓이는 경향이 있다. AI가 작성한 PR을 다른 기준의 별도 클래스처럼 취급하는 순간, 낮은 기준이 이긴다. 누가 썼든, 무엇이 썼든 모든 리뷰를 동일하게 다뤄라.

작은 PR은 그 이후의 모든 것의 경제성을 바꾼다. 리뷰어가 준비되지 않은 PR을 집어 들었다가 되돌려야 한다면, 그건 작성자에게만 왕복이 아니다. 다른 일에 집중할 수 있었던 리뷰어에게도 컨텍스트 스위치다. 다음으로 리뷰될 예정이던 PR의 작성자는 자신의 변경이 큐에 앉아 더 오래 기다리게 된다. 그걸 하루치의 과도하게 크거나 깨진 PR에 대해 곱해보면, 애초에 리뷰어에게 도달하지 말았어야 할 작업에 리뷰어의 용량을 태우면서, 동시에 진행 중인 다른 모든 것에 지연을 추가하게 된다. 해결책은 체크를 통과하지 못한 PR은 건드리지 않는 것이다. 그린이 아니면 아직 당신 문제 아니다. 손대지 않는 준비되지 않은 PR 하나하나가, 실제로 리뷰할 가치가 있는 PR을 위해 보존하는 주의력이다.

프리체크는 PR 작성자가 반대편에서 이 루프를 닫는 데도 도움이 된다. CI와 인간 리뷰어 사이의 암묵적인 분업은, 양쪽이 맥락을 공유하는 엔지니어-대-엔지니어 워크플로를 위해 만들어졌다. 디자이너가 PR을 열고 무언가가 실패하면, 수수께끼 같은 빨간 X는 아무것도 말해주지 않는다. 이걸 잘하는 팀은 CI 출력이나 PR 코멘트를 통해 비개발자 작성자를 올바른 문서나 Slack 채널로 바로 라우팅한다. 그런 안내가 없으면, 깨진 PR은 준비되지 않은 변경을 이해하는 데 시간을 쓰는 리뷰어에게 도달하고, 작성자는 체크에서 받을 수 있었던 피드백을 기다리게 된다. 사람이 보기 전에 잡을 수 있는 건 최대한 잡아라.

그리고 내가 가장 기대하는 닫힌 루프가 있다. 리뷰어 패턴을 CI에 인코딩하는 것이다. 두 팀에 걸친 세 명의 리뷰어가 같은 종류의 이슈를 계속 잡아낸다면, 그건 곧 작성될 체크다. Roblox는 과거 리뷰 코멘트를 채굴해 컨텍스트 인지 체크를 만들고, 반복되는 피드백을 제출 전 게이트로 바꿈으로써 AI 제안 수용률을 두 배로 늘릴 수 있음을 발견했다. 각 사이클은 다음 라운드의 리뷰를 더 가볍게 만든다. 그 투자는 복리로 쌓인다. 이번 달에 추가한 체크 하나가, 다음 달에 리뷰어도 작성자도 놓쳤을 현실의 이슈를 잡아낸다.

이 모든 건, PR을 누가 열었는지와 무관하게 승인하는 팀에 책임이 남아 있을 때만 작동한다. 누가 변경했는지, 어떻게 변경했는지는 중요하지 않다. 누군가 당신 팀이 소유한 무언가를 바꾼다면, 당신이 리뷰하고, 당신이 승인하고, 당신이 결과를 소유한다. 이는 값싸고 보일러플레이트 같은 코드에 대해서는 작성자보다 리뷰어를 더 인정하는 것을 요구하지만, 그 명확성은 비엔지니어 기여자 모델이 작동하게 만든다. PM을 온콜에 세우는 건 처벌적이고 비효율적일 것이다. 어떤 수정이든 실행하려면 여전히 엔지니어가 필요하기 때문이다. 더 나은 길은, 코드베이스에 깊은 맥락을 쌓지 않는 어떤 기여자에게나 하듯 리뷰어의 부담을 줄이는 프리체크에 투자하는 것이다.

좋은 리뷰어가 아는 것을 체계적으로 추출해 CI 속도로 돌릴 수 있느냐는, 나는 진심으로 모르겠다. 체크를 하나 쓸 때마다 사람이 잡아내야 할 것이 하나 줄어든다. 하지만 리뷰어는 버그만 잡지 않는다. 드리프트를 잡고, 의도 불일치를 잡고, 로컬에서는 괜찮아 보이지만 세 서비스 너머에서 문제를 일으키는 아키텍처 결정을 잡는다. 그 중 얼마나 인코딩 가능한지는, 업계가 아직 답하지 못한 열린 질문이라고 생각한다.

사람들은 코드 작성이 병목이라고 생각했다. 이제 그건 빨라졌다. 제약은 맥락, 리뷰 품질, 책임으로 옮겨갔다. 쉽게 압축되지 않는 부분들로.

가능할 때, 당신이 통제할 수 없는 누군가가 리뷰어를 사라지게 만들기로 결정하기 전에, 리뷰어의 일을 더 싸게 만들어라.

© 2026 Rishi Baldawa · Some rights reserved