코드 리뷰의 종말? 에이전트 시대에 PR을 읽지 말아야 하는 이유

출처: Laurie Voss(Arize AI DevRel 총괄, npm 공동 창업자)의 AI Engineer World's Fair 2026 발표 "The Death of the Code Review" — 원본 영상

에이전트가 만든 diff를 끝까지 읽지도 않고 머지 버튼을 누르면서 찜찜했던 적이 있다면, 이 발표를 한번 볼 만하다. 발표자 본인도 청중 대부분이 그러고 있다고 말한다. 그리고 이 문제를 숫자로 보여 주면서, 해법이 "더 꼼꼼히 읽기"는 아니라고 한다.

코드는 741% 늘었는데 출시는 30%만 늘었다

경제학자 세 명이 GitHub 개발자 10만 명 이상을 추적했다. 자율 에이전트를 켠 사람들은 코드를 741% 더 썼고, 실제로 출시된 소프트웨어는 30% 늘었다. 연구진은 리뷰를 원인으로 꼽는다. 프로덕션으로 가는 길이 여전히 사람을 거치고, 그중에서도 코드 리뷰가 하류 전체를 막고 있다는 것이다.

코드를 만드는 건 이제 싸다. 그 코드를 믿어도 되는지 확인하는 건 여전히 비싸다. 발표자는 Stripe가 5천만 줄짜리 Ruby 코드베이스를 하루 만에 옮긴 일, Bun이 100만 줄 넘는 Zig를 6일 만에 Rust로 바꾼 일을 예로 든다.

더 열심히 읽는다고 해결되지 않는다

"그럼 리뷰를 더 빡세게 하면 되지 않나?" 발표자는 20년 전 Cisco 연구를 꺼낸다. 리뷰 2,500건을 분석했더니, 한 번에 400줄쯤 넘게 읽거나 시간당 450줄보다 빨리 읽으면 결함을 제대로 못 잡았다. 이 속도로 계산하면 에이전트 하나가 만든 1만 줄짜리 PR을 사람이 검토하는 데 사나흘이 걸린다. 요즘은 한 사람이 에이전트를 열두 개씩 돌릴 수 있다. 발표자는 그런 사람은 좀 의심스럽다고 농담하지만, 어쨌든 계산이 안 맞는다. 리뷰만 맡은 사람은 지루해서 금방 지치기도 한다.

테스트를 통과했다고 머지해도 되는 건 아니다

사람이 못 읽으면 테스트에 맡기면 될까. METR이 해 본 결과는 그렇지 않았다. SWE-bench 채점을 통과한 PR을 실제 오픈소스 메인테이너들에게 보여 줬더니, 머지해도 된다고 본 건 절반쯤이었다. 탈락 이유는 정확성이 아니라 코드 품질과, 테스트 바깥의 코드를 조용히 깨뜨리는 변경이었다.

Cognition의 FrontierCode도 같은 얘기를 한다. 동작 정확성, 회귀, 안전성, 범위 규율, 테스트 품질, 유지보수성처럼 리뷰어가 실제로 보는 기준으로 채점했더니, SWE-bench Pro에서 88%를 받은 모델이 가장 어려운 구간에서는 29%였다.

가장 극적인 건 Bun이다. 기존 테스트의 99.8%를 통과했으니 테스트는 제 할 일을 했다. 그런데 이식된 코드에 unsafe 블록이 13,044개 있었다. 비슷한 규모로 사람이 쓴 프로젝트는 73개쯤이라고 한다. unsafe는 메모리를 제대로 다룬다는 걸 증명하지 않고 작성자가 "맞다"고 주장하는 자리다. 테스트는 공개 인터페이스의 동작만 보증하니까, 애초에 확인하도록 설계되지 않은 1만 3천 개의 주장이 검증 없이 남은 셈이다. 여담으로, Zig 코드를 한꺼번에 지우는 PR은 다른 봇이 AI 슬롭이라며 표시했다고 한다.

자동 리뷰어는 이미 돌고 있고, 잘 속는다

발표에 따르면 GitHub Copilot 리뷰어는 GitHub 전체 코드 리뷰의 5건 중 1건 넘게 맡고 있고, CodeRabbit은 PR 1,300만 건 이상을 검토했다. Cursor가 공개한 리뷰어 구조에서는 배울 점이 두 가지 있다.

하나는 오탐이다. 멀쩡한 코드를 나쁘다고 하는 리뷰어는 곧 무시당한다. 그래서 Cursor의 첫 버전은 diff 하나를 여덟 번 리뷰하면서 매번 순서를 섞었다. 순서에 따라 결과가 달라졌기 때문이다. 베이징대 연구진도 같은 발상으로 여러 번 돌려서 의견이 겹치는 지적만 남겼고, 리뷰 품질이 최대 44% 올랐다고 한다.

다른 하나는 모델에게 의심하라고 직접 말해야 했다는 점이다. Cursor가 리뷰어를 다시 만들 때, 모델은 "괜찮아 보이니 그냥 내보내자" 쪽으로 기울었다고 한다. 사람 리뷰어와 똑같다. 그래서 코드를 기본적으로 믿지 말고 뭔가 잘못됐다고 가정하라는 취지로 지시해야 했다는 게 발표자의 전언이다.

약점도 분명하다. 무해해 보이는 커밋 메시지로 포장한 취약한 코드가 자율 리뷰 에이전트를 88% 속였고, 같은 시도가 사람 리뷰어에게는 35%만 통했다는 연구가 소개된다. 자신 있게 포장된 나쁜 코드는 에이전트가 제일 잘 만드는 코드이기도 하다. 게다가 이 리뷰어들의 성공 지표는 전부 "사람이 내 지적을 받아들였나"다. 코드도 리뷰도 자동인데, 그 리뷰를 다시 사람이 보는 구조인 셈이다.

사람을 뺀 사례를 뜯어 보면

OpenAI는 엔지니어 3명이 직접 코드를 쓰지 않고 약 100만 줄짜리 내부 제품을 만들었다고 공개했다. Anthropic의 Nicholas Carlini는 에이전트 16개로 Rust C 컴파일러를 밑바닥부터 만들어, 약 2,000개 세션에 걸쳐 Linux 커널을 컴파일하게 했다.

그런데 자세히 보면 리뷰는 사라지지 않았다. OpenAI는 에이전트가 다른 에이전트의 리뷰를 다시 리뷰하게 했고, 한동안은 매주 금요일마다 사람이 AI 슬롭을 손으로 치웠다. 감당이 안 되자 슬롭을 찾는 에이전트를 따로 학습시켰다. Carlini 쪽은 코드를 승인한 사람이 없었지만, 정답을 확인하는 테스트 하네스와 피드백 시스템은 전부 사람이 만들었다. 발표자 표현으로는 사람이 루프 "안"에는 없어도 루프 "위"에는 있었다. 리뷰가 없어진 게 아니라 사람이 만든 시스템 쪽으로 옮겨 간 것이다.

반대 증언도 있다. Dexter Horthy는 6개월 동안 코드를 리뷰하지 말라고 하고 다니다가 올해 3월 무대에서 말을 거뒀다. 실제 시스템에서 해 보니 큰 부분을 뜯어내고 다시 만들어야 했다고 한다. 투자자 Sarah Guo는 이유를 이렇게 설명한다. 테스트 통과는 그 변경이 옳은 변경인지, 이 모듈에 기대는 외부 사용자나 주인 모를 크론 잡이 있는지 알려 주지 않는다.

그래서 뭘 하라는 건가

발표자의 결론은 PR 리뷰를 그만하라는 것이다. 2026년에 PR을 리뷰하는 건 맞는 추상화 수준이 아니라고 한다. 사람이 빠지라는 얘기는 아니다. 사람의 판단을 한 층 위, 즉 리뷰 시스템을 만들고 조율하는 쪽에 쓰라는 얘기다. 발표 내용을 실무 항목으로 옮기면 이렇다.

• 에이전트가 올린 PR 중 400줄 넘는 게 얼마나 되는지, 리뷰에 시간이 얼마나 걸리는지부터 재 본다.
• 자동 리뷰어를 쓴다면 오탐부터 잡는다. 여러 번 돌려서 겹치는 지적만 남기고, 프롬프트에 "기본은 의심"을 넣는다.
• 테스트 통과만으로 머지하지 않는다. unsafe 같은 증명 없는 주장, 외부 의존성, 크론 잡처럼 테스트가 못 보는 영역은 규칙과 eval로 따로 적어 둔다.
• 리뷰어를 직접 속여 본다. 무해해 보이는 커밋 메시지나 프롬프트 인젝션에 넘어가는지 정기적으로 시험하고, 그 리뷰 시스템을 누가 책임지는지 정해 둔다.
• 정확성을 싸게 확인할 수 없는 곳, 영향 범위가 큰 곳, 보안에 민감한 곳, 누군가 이름을 걸어야 하는 곳에는 사람 체크포인트를 남긴다.
• 배포한 뒤에는 트레이스와 로그를 마지막 리뷰어로 둔다.

발표는 이런 말로 끝난다. 앞으로 잘하는 팀은 코드를 제일 많이 만드는 팀이 아니라, 자기가 출시한 걸 왜 믿는지 증거로 말할 수 있는 팀이라는 것이다. PR을 읽는 시간 대신 "좋은 코드"의 기준과 회사 맥락, 도메인 지식을 리뷰 하네스에 코드화하는 데 시간을 쓰라는 게 발표자의 권고다.

이 글은 Laurie Voss의 발표 내용을 정리하고 풀어 쓴 것이다. 인용된 수치와 사례는 발표자의 주장이며, 원 연구와는 대조하지 않았다.