AI 에이전트가 사람보다 많은 코드를 쏟아내면서, 회사들은 리뷰를 없애는 대신 사람이 리뷰를 리뷰하는 방식이나 위험도 기준 분기로 리뷰 자체를 다시 짜고 있다.
지난 3년 동안 깃허브에 올라온 PR(Pull Request) 수는 다섯 배로 늘었다. 증가 속도는 2025년 말부터 다시 붙어, 그 뒤로 PR과 커밋 수가 거의 두 배로 더 뛰었다. 사람이 손으로 짜던 코드를 AI 에이전트가 대신 쓰기 시작하면서 벌어진 일이다.
문제는 그 다음이다. 코드가 만들어지는 속도가 리뷰하는 속도를 앞지르면서, 리뷰 프로세스 자체를 어떻게 바꿔야 하는지가 CTO와 엔지니어링 리더들 사이에서 반복되는 질문이 됐다. The Pragmatic Engineer의 Gergely Orosz가 여러 회사를 취재해 정리한 대응은 크게 두 갈래다.
리뷰를 리뷰하는 사람들
가장 흔한 방식은 모든 PR에 AI 리뷰 단계를 끼워 넣는 것이다. CodeRabbit, Gitar, Greptile, GitHub Copilot Code Review, Qodo, Claude Code Review, Ellipsis 같은 벤더가 PR을 훑어 코멘트를 남기면, 개발자는 코드가 아니라 그 코멘트를 검토한다. Anthropic이 만드는 오픈소스 프로젝트 Bun은 CodeRabbit·GitHub Code Review·Claude Code Review 세 개를 한꺼번에 돌린다.
노이즈가 걸림돌이다. 시리즈 C 단계 여행 스타트업 WeTravel은 AI 리뷰가 만들어내는 코멘트가 너무 많아 도입을 미뤘고, 2026년 6월 다시 평가했을 때도 개선은 있었지만 채택할 정도는 아니었다. 반대로 Uber는 uReview라는 자체 파이프라인으로 이 문제에 대응했다. 봇이 쏟아낸 코멘트에 점수를 매겨 확신도가 낮은 것을 버리고, 남은 코멘트를 병합·분류해 중요하지 않은 것을 한 번 더 걸러낸 뒤에야 개발자에게 보여준다.
그가 쓰는 방식은 에이전트가 먼저 적대적으로 리뷰하고, 사람이 스코프를 결정하고, 다시 에이전트가 피드백을 반영하는 순환이다. 90%는 에이전트가 처리하고, 사람은 스코프 결정과 종료 판단 같은 결정적 지점에만 개입한다.
위험도로 나누기
또 다른 축은 변경의 "블라스트 레이디어스"(영향 범위)로 리뷰 여부를 가른다. 위험도가 낮은 변경은 AI만 통과하면 바로 배포하고, 위험도가 높은 변경만 사람이 리뷰한다. Orosz가 직접 확인한 바로는 Anthropic과 OpenAI 모두 이 방식을 쓴다. Anthropic의 Jarred Sumner에 따르면 지금은 위험도가 낮은 변경도 결국 사람이 병합하지만, 그 역할마저 다른 Claude 인스턴스에게 넘기는 것이 목표다.
기사는 이 두 접근 외에도 구현이 아닌 계획·테스트·스키마만 보는 방식, PR 자체를 작게 쪼개는 방식, 여전히 모든 코드를 손으로 읽는 방식까지 소개한다. 다만 리뷰를 완전히 없앤 사례는 드물다고 짚는다 — 그렇게 한다는 이야기는 많아도, 실제로 확인된 곳은 몇몇 AI 스타트업 정도다. 글은 이 질문에 하나의 정답은 없다고 결론짓는다.