속도가 12배 오르면 리뷰 구조가 먼저 무너진다
AI 코딩 에이전트를 도입하고 나서 팀 속도는 빨라졌는데 PR 대기열이 오히려 늘어났다면, 문제는 에이전트가 아니라 리뷰 구조다.
Anthropic의 모노레포에서 하루에 병합되는 변경 수는 올해 5월 약 2,500건에서 9월에는 3만 건을 넘었다. 코드를 쓰는 속도가 이만큼 빨라지면, 인간이 줄을 서서 PR을 읽는 방식은 구조적으로 버티지 못한다. 리뷰어 한 명이 읽을 수 있는 코드의 양은 에이전트가 생성하는 양과 아무 관계가 없기 때문이다.
이 상황에서 많은 팀이 선택하는 실수는 두 가지다. 리뷰 기준을 낮추거나, 리뷰어를 늘리거나. 전자는 리버트 비용이 뒤늦게 올라오고, 후자는 병목이 옆으로 이동할 뿐이다.
실제로 작동하는 방향은 다르다. '누가 읽었느냐'가 아니라 '이 변경에서 무엇이 잘못될 수 있고, 그것을 잡는 가장 적합한 검증은 기계인가 사람인가'를 묻는 구조로 바꾸는 것이다.
코드 리뷰가 실제로 하는 두 가지 일
코드 리뷰에는 서로 다른 두 기능이 있다. 문제를 배포 전에 잡는 것, 그리고 팀 전체가 코드베이스를 함께 이해하는 맥락을 만드는 것이다.
AI 에이전트 환경에서 첫 번째 기능은 상당 부분 자동화가 가능하다. 두 번째는 그렇지 않다. 이 구분을 명확히 하지 않으면, 자동화를 도입한 뒤 팀의 코드 이해 수준이 조용히 내려앉는다. PR이 빠르게 병합되는데 아무도 왜 그 코드가 그렇게 생겼는지 설명하지 못하게 되는 것이다.
이 글은 첫 번째 기능, 즉 문제를 배포 전에 잡는 구조에 집중한다.
검증 레이어를 쌓는 방식: 게이트가 아니라 층
기존 코드 리뷰를 '게이트'로 보면, 자동화는 그 게이트를 대체하는 것처럼 보인다. 하지만 실제로 효과적인 구조는 단일 게이트 대신 여러 층의 검증을 연속으로 배치하는 방식이다.
각 층은 서로 다른 종류의 문제를 잡고, 한 층을 통과한 문제를 다음 층이 잡는다. 어느 하나도 완벽하지 않지만, 레이어 전체를 통과하는 문제는 훨씬 줄어든다. 그마저도 빠져나간 것은 빠른 롤백이 감당한다.
이 구조에서 인간 리뷰어는 모든 층에 배치되지 않는다. 기계가 맥락을 오해할 가능성이 있거나, 실수했을 때 복구 비용이 큰 지점에만 집중한다.
에이전트가 작업을 마치기 전에 스스로 검증하게 한다. 코드를 쓰고 '완료됐다'고 보고하는 것이 아니라, 직접 테스트를 실행하거나 빌드 결과를 확인하거나 스크린샷을 비교하는 방식으로 작업 결과를 증명하게 하는 것이다. Claude Code 팀에서 이 방식을 설계한 Boris Cherny는 에이전트에게 검증 수단을 주는 것이 결과 품질을 두세 배 높인다고 밝혔다. 이 단계를 제대로 설계하면 PR이 열리기 전에 이미 한 번의 검증 루프가 돌아간 상태가 된다.
모든 PR에 AI 리뷰를 자동 실행한다. 이 리뷰는 diff와 PR의 의도, 전체 코드베이스의 맥락을 함께 읽고 판단한다. 단순한 스타일 오류가 아니라 '이 변경이 다른 곳을 의도치 않게 깨뜨리는가', '버그 수정이라면 근본 원인을 해결했는가'를 묻는다.
이때 중요한 설계 포인트가 하나 있다. AI 리뷰 결과를 단일 판단으로 내놓는 것이 아니라, 여러 에이전트가 동시에 검토하고 그 결과에 투표해서 일정 수 이상 동의한 것만 실제 의견으로 올리는 방식이다. 스타일이나 진단, 정리 수준의 지적은 걸러낸다. 허위 경보가 줄고, 인간이 실제로 읽어야 할 코멘트의 신호 대 잡음비가 올라간다.
보안 리뷰는 별도 레이어로 분리하고 블로킹 조건으로 설정한다. 보안 관련 발견은 해소되기 전까지 병합을 막는다. 수정하거나, 명시적 이유와 함께 허위 경보임을 기록하거나 둘 중 하나를 선택해야 한다. 이 기록은 나중에 같은 패턴이 반복될 때 대응 속도를 높이는 데 쓰인다.
자동화 판단의 품질을 결정하는 문서 두 종류
레이어 구조를 설계할 때 간과되기 쉬운 부분이 있다. AI 리뷰어가 프로젝트의 맥락을 얼마나 정확하게 이해하느냐가 결과의 질을 결정한다는 점이다.
하나는 프로젝트 전체의 스택, 관례, 목표, 그리고 하지 말아야 하는 것을 명시한 파일이다(Claude Code 팀은 이를 CLAUDE.md로 관리한다). 모든 자동 리뷰가 이 파일을 읽고 시작한다. 짧을수록 좋다. 길어지면 에이전트가 중요한 부분을 희석한다.
다른 하나는 리포지터리별로 코드 소유자가 직접 쓰는 리뷰 가이드다(REVIEW.md에 해당한다). 좋은 파일의 공통점은 구체적이라는 것이다. '이 영역에서 실패는 어떤 형태로 나타나는가'를 명시하고, 건너뛰어도 되는 경로를 열거하며, 스타일 지적의 수를 제한하고, 소견을 낼 때 파일명과 줄 번호를 근거로 요구한다.
이 문서들을 잘 관리하면 AI 리뷰어가 같은 종류의 오류를 반복 지적하는 상황을 줄일 수 있다. 반복되는 지적은 리뷰 가이드를 업데이트하거나 린트 규칙을 추가하거나 에이전트의 작업 지침을 수정하라는 신호로 읽어야 한다.
인간이 남아야 하는 지점과 조기 이탈 신호
자동화가 충분히 작동한다면, 대부분의 PR은 저자 본인만 승인하고 병합할 수 있어야 한다. 이 상태를 목표로 설계하되, PR당 인간 개입 횟수와 리버트율을 동시에 추적해야 한다.
PR당 리뷰 코멘트 수, 승인을 기다리는 대기 시간, 사람이 직접 승인한 비율을 측정한다. 그리고 리버트율과 인시던트 발생 빈도를 함께 본다. 인간 개입이 줄었는데 리버트가 늘었다면, 자동화가 속도를 확보한 것이 아니라 품질 비용을 배포 후로 이연시킨 것이다. 두 지표가 함께 개선될 때만 구조가 작동하고 있다고 볼 수 있다.
인간 리뷰어가 여전히 직접 봐야 하는 지점은 몇 가지로 좁혀진다. 아키텍처 방향이 바뀌는 변경, 보안 경계를 다시 그리는 결정, 기존 계약이나 외부 시스템과의 인터페이스 변경처럼 자동화가 맥락을 잘못 읽었을 때 복구 비용이 높은 경우다. 그 외 루틴한 변경에 인간을 배치하는 것은 희소한 자원을 낮은 위험에 쓰는 셈이다.
'빠른 롤백'은 선택이 아니라 구조의 전제 조건이다
레이어 검증을 아무리 잘 쌓아도, 모든 문제를 배포 전에 잡을 수는 없다. 이 사실을 전제로 설계에 포함시키지 않으면 속도와 안정성을 동시에 확보하기 어렵다.
빠른 롤백에 투자한다는 것은 배포 후 이상을 감지하는 속도, 그리고 감지하고 나서 이전 상태로 돌아가는 데 걸리는 시간을 줄이는 작업이다. 이 두 숫자가 크면, 레이어 검증이 잡지 못한 문제가 사용자에게 노출되는 시간이 길어진다.
따라서 AI 에이전트 도입과 함께 배포 파이프라인에서 롤백 경로를 단순하게 유지하는 것, 모니터링 경보가 실제로 빠르게 울리는지 주기적으로 확인하는 것, 롤백 훈련을 루틴으로 가져가는 것은 별도의 후속 과제가 아니라 에이전트 도입 설계 안에 포함돼야 한다. 속도를 올리는 데 투자하는 만큼, 잘못됐을 때 얼마나 빨리 돌아올 수 있는지에도 같은 수준의 설계가 필요하다.
자동화를 얹기 전에 먼저 확인할 것들
AI 코딩 에이전트를 도입하거나 확장하려는 팀이라면, 리뷰 자동화를 설계하기 전에 아래 질문에 답해보는 것이 순서다.
현재 PR이 병합되기까지 사람이 기다리는 시간이 얼마나 되는가. 리버트가 발생했을 때 원인을 추적하는 데 얼마나 걸리는가. 코드 소유자들이 자기 영역의 '전형적인 실패 패턴'을 말로 설명할 수 있는가. 롤백에 걸리는 평균 시간이 현재 측정되고 있는가.
이 질문에 답하기 어렵다면, 자동화 레이어를 얹기 전에 이 숫자들을 먼저 만들어 두는 것이 낫다. 개선 여부를 판단하는 기준선 없이 구조를 바꾸면, 나아지고 있는지 나빠지고 있는지 알 수 없다.
