The Death of the Code Review: What the Data Actually Says — Laurie Voss, Arize AI

한 줄 핵심

AI 에이전트가 코드를 훨씬 더 빨리 만들게 되면서 병목은 생성이 아니라 코드 리뷰로 옮겨갔고, 지금 필요한 해법은 인간 리뷰를 없애는 것이 아니라 리뷰 기준·평가·보호장치를 갖춘 하네스를 재설계하는 것이다.

시간별 요약

1. 0:00
   새로운 병목: 인간 리뷰 AI 에이전트가 코드 생산 속도를 크게 끌어올렸지만 인간의 검토 속도는 그대로여서, 코드 생성보다 리뷰가 전체 개발 흐름을 막는 새로운 병목이 되었다. 핵심 질문은 인간 리뷰를 건너뛸지, 자동화할지, 아니면 오늘 당장 무엇을 바꿔야 할지다.
2. 1:37
   741% 더 많은 코드, 30% 더 많은 소프트웨어 100,000명 이상 GitHub 개발자 데이터를 보면 AI 에이전트를 켠 뒤 코드는 741% 늘었지만 실제 배포된 소프트웨어는 30%만 늘었다. 생산량은 급증했지만 생산된 코드를 믿고 출고하는 과정이 따라가지 못해 리뷰가 병목임이 드러난다.
3. 2:37
   생성은 더 이상 병목이 아니다 Stripe와 Anthropic의 Fable 사례처럼 거대한 코드베이스 이관도 에이전트로 매우 빠르게 끝낼 수 있고, Bun도 대규모 포트를 며칠 만에 처리했다. 지금 문제는 코드를 만들 능력이 아니라, 그 결과를 안심하고 병합할 수 있느냐이다.
4. 3:22
   "더 열심히 리뷰하기"가 실패하는 이유: Cisco 연구 오래된 Cisco 연구는 리뷰어가 한 번에 400줄, 한 시간에 450줄을 넘기면 결함 탐지 효과가 급격히 떨어진다고 보여줬다. 에이전트 PR이 10,000줄 규모가 되면 인간이 제대로 읽는 데 며칠이 걸리므로, 단순히 리뷰 강도를 높이는 방식은 지속 불가능하다.
5. 4:52
   코드를 읽지 않을 것인가? Loops와 OpenAI의 무인 코드 제품 일부는 사람을 루프에서 빼고, 에이전트가 스스로 일하는 루프를 설계해야 한다고 주장한다. OpenAI의 내부 사례는 사람이 수동 작성한 코드 없이도 제품을 만들 수 있음을 보여줬지만, 공개된 범위만으로는 그 방식이 모든 상황에 충분하다고 보기 어렵다.
6. 6:42
   테스트를 통과하면 병합 가능할까? METR의 SWE-bench 연구 테스트 통과를 품질의 대리 지표로 보는 관행을 METR가 직접 검증했는데, 실제 유지보수자 기준으로는 SWE-bench를 통과한 PR도 절반 정도만 병합 가능했다. 테스트는 정답성은 잡아도, 코드 품질과 외부 영향까지는 충분히 보지 못한다.
7. 8:01
   FrontierCode: 88% 대 29% Cognition의 FrontierCode는 유지보수자가 실제로 묻는 '이걸 병합할까?'를 기준으로 만든 벤치마크다. 같은 모델이 SWE-bench에서는 높게 나와도, 인간 리뷰 기준에 가까운 FrontierCode에서는 크게 떨어져 현재 모델이 신뢰할 수준의 병합 판단을 하지 못함을 보여준다.
8. 9:11
   다음 학습 신호로서의 병합 가능성 무엇이 병합 가능한지 정의하고 측정할 수 있으면, 그 기준은 곧 모델 학습 신호가 된다. 컴파일러와 테스트가 이미 무료 검증기로 작동해 모델을 빠르게 발전시켰듯, 앞으로는 유지보수성·범위·안전성까지 학습 대상이 될 가능성이 크다.
9. 11:06
   오늘의 자동화 리뷰: GitHub Copilot과 Cursor GitHub Copilot의 리뷰어는 이미 대규모로 사용되고 있고, Cursor도 다중 패스로 false positive를 줄이며 자동 리뷰를 개선하고 있다. 이 단계의 핵심은 모델을 더 똑똑하게 만드는 것보다, 잘못된 경고를 줄여 인간이 신뢰할 수 있게 만드는 데 있다.
10. 13:16
    리뷰와 수리가 합쳐지고 있다 Cursor 같은 시스템은 리뷰에서 발견한 문제를 바로 수정 패치로 연결하며, 리뷰와 리페어의 경계가 매우 얇아지고 있다. 앞으로는 단순 지적보다 실제 수정까지 이어지는 흐름이 자동 리뷰의 표준이 될 가능성이 높다.
11. 13:51
    CodeRabbit, Greptile, Graphite와 수용 지표 CodeRabbit, Greptile, Graphite 등은 모두 인간이 제안을 받아들이는 비율을 성공 기준으로 삼는다. 즉 자동 리뷰의 목표는 절대적 정답이 아니라, 인간이 수용할 만큼 정확하고 유용한 판단을 내리는 것이다.
12. 15:00
    인간을 건너뛸 수 있을까? Carlini의 C 컴파일러 Anthropic의 Nicholas Carlini 실험은 16개 에이전트가 C 컴파일러를 만들고 Linux kernel까지 빌드하게 했지만, 그 위의 테스트 하네스와 검증 체계는 인간이 설계했다. 인간을 코드 작성에서 빼는 것은 가능해도, 검증 시스템까지 완전히 빼기는 어렵다.
13. 16:00
    Bun의 Zig-to-Rust 포트와 13,044개의 unsafe 블록 Bun의 대규모 Zig-to-Rust 포트는 테스트 통과율이 매우 높았지만, 세부를 보면 13,044개의 unsafe block이 남아 있었다. 테스트는 외부 행동은 확인할 수 있어도, 내부에 쌓인 수많은 안전성 가정까지 증명해주지는 못한다.
14. 17:30
    OpenAI가 리뷰를 시스템으로 다시 만든 방법 OpenAI는 Codeex가 자신의 변경을 리뷰하고, 더 많은 에이전트가 그 리뷰를 다시 점검하는 구조로 검토를 시스템화했다. 초기에는 인간이 Friday마다 AI slop를 손으로 치웠지만, 결국 그 일도 에이전트가 맡게 되면서 리뷰는 사라진 것이 아니라 계층화되었다.
15. 18:45
    Dex Horthy: "코드를 읽어 주세요" 한때 코드를 읽지 말자고 주장했던 Dex Horthy도 실제 운영 경험 후에는 입장을 바꿔, 코드를 읽어야 한다고 공개적으로 말했다. 실전 시스템에서는 코드 자체를 안 읽는 접근이 오래 버티지 못했고, 큰 부분을 뜯어고치는 결과로 돌아왔다.
16. 19:30
    테스트가 볼 수 없는 맥락 테스트를 통과했다고 해서 변경이 옳다는 뜻은 아니며, 외부 사용자, 숨은 cron job, 모듈의 실제 의존관계 같은 맥락은 테스트 밖에 남아 있다. 결국 코드의 의미는 테스트 결과만으로는 충분히 판별되지 않는다.
17. 19:55
    인간 체크포인트가 남는 자리 인간 검토는 사라지지 않고, 정답을 싸게 확인할 수 없는 영역과 영향 범위가 큰 영역에 남아 있다. 역할도 코드 라인별 독자에서, 리뷰 시스템과 합격 기준을 설계·조정하는 상위 계층으로 이동한다.
18. 20:40
    리뷰어는 누가 리뷰하는가? Prompt injection 자동 리뷰 시스템은 prompt injection 같은 공격에 취약해, 자신이 검토하는 코드에 설득당할 수 있다. 반면 인간 리뷰어는 같은 악성 패턴에 더 강했고, 따라서 리뷰어 자체를 자동화하면 오히려 속기 쉬운 약점을 떠안을 수 있다.
19. 22:04
    프로덕션: 마지막으로 남는 리뷰어 사전 병합 리뷰가 자동화될수록, 실제 프로덕션에서 코드가 어떻게 동작하는지를 보는 운영 환경이 마지막 리뷰어가 된다. 배포 후의 텔레메트리와 실동작 검증이야말로 자동 리뷰의 한계를 보완하는 최종 안전망이다.
20. 22:44
    코드 리뷰는 죽는 것이 아니라 다시 만들어지고 있다 코드 리뷰는 끝난 것이 아니라, 벤치마크·분류기·룰·테스트·평가를 포함한 엔지니어링 시스템으로 재구성되고 있다. 앞으로 이길 팀은 더 많은 코드를 만드는 팀이 아니라, 자신이 배포한 코드를 왜 신뢰하는지 증명할 수 있는 팀이다.
21. 23:29
    오늘 해야 할 일: 리뷰 하네스 만들기 지금 당장 할 일은 PR을 더 열심히 읽는 것이 아니라, 회사 맥락과 도메인 지식을 규칙·평가·검증으로 묶은 리뷰 하네스를 만드는 것이다. 인간의 판단을 상위 레벨의 시스템으로 옮기면, 훨씬 더 큰 규모로 신뢰 가능한 자동화를 만들 수 있다.

실무 인사이트

• PR 단위의 수동 리뷰를 늘리는 대신, 병합 기준과 실패 기준을 명문화한 리뷰 하네스를 먼저 만들면 리뷰 품질과 처리량을 동시에 올릴 수 있다.
• 자동 리뷰를 도입할 때는 정답률보다 false positive와 인간 수용률을 먼저 관리해야 실제 현업에서 버려지지 않는다.
• 테스트 통과만으로는 충분하지 않으므로, 배포 후 관측과 보안 검증까지 포함한 다층 검증 체계를 같이 설계해야 한다.