AI가 코드의 90%를 작성하면서 Anthropic Claude Code Review가 일상적 인간 검토를 대체하다

회사에 따르면 Claude가 제품 코드의 약 90%를 작성하면서 Anthropic Claude Code review는 낯선 영역에 들어섰다. 2026년 6월부터 9월까지 병합된 pull request는 두 배 이상 늘었다. 그러나 revert가 필요한 비중은 40% 이상 감소한 것으로 알려졌다.

이 조합이 핵심이다. Anthropic은 기계가 작성한 코드가 급증하자 사람이 더 많은 줄을 검사하도록 배정하지 않았다. 대신 대부분의 일상적 읽기 업무를 다른 Claude agent에게 맡기고, 더 큰 위험을 수반하는 변경에만 인간 승인을 남겼다.

이는 단순히 기존 검토를 더 빠르게 수행하는 방식이 아니다. 검토의 의미와 수행 주체, 그리고 책임이 시작되는 지점을 바꾼다. Anthropic은 이제 인간의 주의를 모든 개별 코드 줄이 아니라 위험도를 따라 배분해야 하는 희소한 자원으로 본다.

이 접근법에는 중요한 한계도 있다. 눈에 띄는 성과 수치는 공개된 원시 데이터나 독립적 감사를 거치지 않은 Anthropic 자체 측정치다. 이 프로세스는 광범위한 자동화, 내부 인프라, 단계적 출시, 그리고 자사 모델에 대한 이례적으로 높은 접근성을 바탕으로 한다.

결국의 대결 구도는 Claude와 인간 프로그래머의 경쟁이 아니다. 자동화된 포괄성 대 전면적 인간 검사의 문제다. Anthropic은 계층형 점검, 선별적 승인, 손쉬운 되돌리기가 기계 속도에서 줄 단위로 읽는 방식보다 더 많은 위험을 통제할 수 있다고 본다.

Anthropic Claude Code Review에서 달라진 점

Anthropic은 코드 검토를 단일 인간 관문에서 자동화된 점검, agent 검토자, 선별적 승인, 신속한 rollback으로 이루어진 연속 시스템으로 전환했다.

회사는 10월 15일 엔지니어링 게시물에서 Claude Code review 시스템을 설명했다. 저자인 Addy Osmani, Morgan Westlee Lunt, Qing Wang은 산출량을 중심으로 문제를 제기했다. agent가 사람이 읽을 수 있는 속도보다 빠르게 변경을 생성하면, 전통적인 대기열은 배포 병목이 된다.

Anthropic은 모든 pull request가 사람이 검토하기 전에 Claude 검토를 거친다고 말한다. 검토자는 제안된 변경을 더 넓은 repository 맥락과 pull request에 명시된 의도에 비추어 읽는다. 버그 수정의 경우, 보이는 patch만 확인하는 것이 아니라 근본 원인을 파악하려 한다.

그런 다음 여러 agent가 잠재적 결함을 병렬로 탐색한다. 또 다른 그룹은 각 발견 사항에 투표하며, 충분한 검토자가 동의할 때만 시스템이 이슈를 게시한다. Anthropic은 스타일, 진단 또는 선택적 정리에 한정된 댓글을 제거하는 필터를 시험했다고 밝혔다.

남은 발견 사항에는 심각도 라벨이 부여된다. 개발자 또는 agent는 각 발견 사항을 수정하거나 그 이유와 함께 thread를 닫아야 한다. 별도의 자동화된 보안 검토는 이슈가 해결되지 않은 상태에서는 병합을 막을 수도 있다.

이러한 검토는 기존 안전장치와 함께 작동한다. pull request는 여전히 linting, type check, build, 지원 플랫폼 전반의 test를 거친다. merge queue는 현재 main branch를 기준으로 점검을 다시 실행해, 각각은 유효하지만 상호작용 시 문제가 되는 변경으로 인한 실패를 줄인다.

검토는 pull request가 생기기 전부터 시작된다. Claude는 test, build 또는 시각적 점검을 실행하고 그 결과 증거를 표시한다. 이어서 새로운 맥락을 가진 subagent가 diff를 검사하므로, 작성 agent가 처음의 가정을 그대로 반복할 가능성이 줄어든다.

Anthropic의 이전 coding practices는 작성과 검증 맥락을 분리할 것을 권고했다. 새 workflow는 이 권고를 전체 팀의 운영 체계로 바꾼다.

인간 승인은 변경 사항의 분류된 위험도에 따라 달라진다. 저위험 작업은 자동화 및 보안 점검을 통과하면 병합될 수 있다. 예로는 문서, 문구 변경, 내부 기능, feature flag 뒤에 숨겨진 추가 기능이 있다.

일반적인 제품 작업에는 보통 한 명의 승인이 필요하다. caching, system prompt, update mechanism처럼 민감한 영역도 인간의 주의를 받는다. 최고 위험 변경에는 두 명이 필요하며, 특정 보호 경로는 언제나 수동 검토를 유발한다.

분류기는 사람이 썼는지 agent가 썼는지가 아니라 변경 자체를 평가한다. 원래 등급이 지나치게 관대해 보이면 두 번째 분류기가 여전히 인간의 개입을 요구할 수 있다. agent의 승인은 사람에게 할당된 자리를 대신하지 못한다.

이 구분은 중요하다. Anthropic은 인간의 책임을 없애지 않았으며 AI 검토가 소프트웨어를 오류 없이 만든다고 주장하지도 않는다. 대신 일상적 결함 탐지와 아키텍처, 제품 방향, 민감한 시스템, 수용 가능한 위험에 관한 결정을 분리했다.

Claude에게 지시한 사람은 결과에 계속 책임을 진다. 각 승인은 특정 commit에 적용되므로, 이후 변경으로 효력이 사라질 수 있다. Anthropic의 모델에서 위임은 누가 코드를 작성하고 읽는지는 바꾸지만, 누가 결과를 소유하는지는 바꾸지 않는다.

수치는 인간만의 검토가 지속 가능하지 않음을 보여준다

Anthropic이 보고한 지표는 코드 생산량이 전면적 인간 읽기를 중심으로 설계된 어떤 검토 프로세스도 이미 앞질렀음을 시사한다.

회사는 Claude Code repository에서 병합된 pull request가 2026년 6월과 9월 사이 두 배 이상 늘었다고 말한다. 같은 기간 revert가 필요한 비중은 40% 이상 감소했다.

이 수치는 완전한 성과가 아니라 방향을 보여준다. Anthropic은 pull request의 절대 건수, 기존 revert 비율, 최종 revert 비율, 통계적 변동을 공개하지 않았다. 상대적으로 40% 감소했다는 수치는 높은 기준선에서 시작했을 수도, 낮은 기준선에서 시작했을 수도 있다.

90%라는 수치도 신중히 표현해야 한다. Anthropic은 Claude가 Claude Code 코드의 약 90%를 작성한다고 말한다. 그렇다고 모델이 독립적으로 제품 우선순위를 정하거나, 모든 요구사항을 정의하거나, 배포 책임을 진다는 뜻은 아니다.

엔지니어들은 여전히 작업을 지시하고, 증거를 판단하며, 설계상의 절충점을 해결하고, 작업이 존재해야 하는지를 결정한다. 기계 저작 비율은 코드 생성을 측정하지만, 소프트웨어 엔지니어링은 줄을 만들어내는 일보다 훨씬 더 많은 것을 포함한다.

이러한 단서가 있어도 Anthropic은 실제 확장 문제에 직면한다. 별도의 monorepo는 5월 하루 약 2,500건의 병합 변경에서 9월 30,000건 이상으로 늘어난 것으로 알려졌다. 회사는 이 작업량을 처리하기 위해 Scion이라는 내부 source-control 시스템을 구축했다.

Claude Code는 별도 repository를 사용하므로 30,000건의 변경 수치는 제품 팀을 직접 측정하지 않는다. 그럼에도 Anthropic이 설명한 source-control redesign는 개발 인프라를 둘러싼 더 넓은 압박을 보여준다.

Scion과 Claude Code 사례는 동일한 병목을 가리킨다. coding agent가 변경을 지속적으로 만들고, test하고, 수정할 수 있게 되면 코드 작성은 더 이상 처리량을 통제하지 않는다. 검토 대기열, build, 권한, 통합 시스템, 출시 통제가 제한 요인이 된다.

전통적인 코드 검토는 관리 가능한 수의 변경이 사람에게서 나온다는 가정에 기반한다. 다른 사람이 각 diff를 읽고, 수정을 요청하고, 최종 버전을 승인한다. 산출량이 검토자 역량보다 빠르게 늘어나면 이 모델은 무너지기 시작한다.

검토자를 늘린다고 해서 불일치가 완전히 해결되지는 않는다. 숙련된 엔지니어는 부족하며, 끊임없는 검토는 설계 작업, 디버깅, 제품 의사결정을 방해한다. 조직은 검토 인력을 늘리면서도 증가하는 변경 흐름 전반에서 공유된 주의를 잃을 수 있다.

따라서 Anthropic은 생성된 댓글 수 이상을 측정한다. 사람의 pull request당 승인 수, 인간 댓글, 대기 시간, revert, incident를 추적한다. 명시된 목표는 인간 검토 시간을 줄이되 그 시간이 운영 환경 복구로 옮겨가지 않게 하는 것이다.

회사 측은 상용 AI 검토자가 실질적인 댓글을 받는 내부 pull request의 비중을 16%에서 54%로 높였다고도 보고한다. 1,000줄을 넘는 변경 대부분은 발견 사항을 유발하는 반면, 더 작은 변경 대부분은 문제없이 통과하는 것으로 알려졌다.

이 결과만으로 정확성이 입증되지는 않는다. 더 많은 댓글은 더 나은 탐지, 더 많은 잡음, 또는 둘 다를 의미할 수 있다. Anthropic은 개발자가 발견 사항을 수정하는지, 거부하는지, 보고된 동작이 의도된 것이라고 판단하는지를 관찰해 댓글 품질을 평가한다고 말한다.

더 큰 신호는 조직적 변화다. Anthropic은 더 이상 사람이 변경된 모든 줄을 읽는 일을 검토의 결정적 증거로 보지 않는다. 결합된 시스템이 문제를 포착하는지, 주의를 적절히 배분하는지, 운영 환경의 피해를 제한하는지를 측정한다.

이 변화는 coding agent를 배포하는 모든 엔지니어링 조직에 압박을 가한다. agent 산출량이 늘어나는 동안 검토 정책이 고정된 채라면, 대기열은 늘어나고 기대했던 생산성 향상은 사라진다. 팀은 생성을 제한하거나 검증 방식을 재설계해야 한다.

자동화된 포괄성이 전면적 인간 검사에 도전하다

핵심 경쟁은 폭넓은 기계 검토와 모든 의미 있는 변경은 직접적인 인간 읽기를 받아야 한다는 믿음 사이에 있다.

전면적 인간 검사는 직관적인 약속을 제공한다. 자격을 갖춘 엔지니어가 코드를 이해하고 변경을 확인하며, 배포 전에 책임을 수용한다는 것이다. 이 관행은 자동화된 test가 놓치는 가정을 포착하는 동시에 지식을 확산할 수 있다.

그러나 검토가 급하게 이루어지면 이 약속은 약해진다. 대기열이 많은 사람은 추론하는 대신 훑어보거나, 익숙해 보이는 코드를 승인하거나, 동작보다 스타일에 집중할 수 있다. 인간의 서명이 이해를 보장하지는 않는다.

Anthropic의 대안은 여러 전문 계층을 사용한다. 한 agent가 변경을 작성하고, 다른 agent가 새로운 맥락으로 검토하며, 여러 agent가 버그를 찾고, 별도 agent들이 각 발견 사항을 평가한다. 보안 검토, continuous integration, merge check, 단계적 출시, rollback은 서로 다른 실패 양상을 다룬다.

이는 심층 방어와 닮았다. 이후 계층이 앞선 계층이 놓친 것을 포착할 수 있으므로, 어떤 개별 계층도 완벽한 포착률을 가질 필요가 없다. 이후 위험 분류는 더 큰 잠재적 영향을 가진 변경으로 희소한 인간 판단을 유도한다.

이 방식은 Anthropic에 더 넓은 검토 범위도 제공한다. 기계는 동료의 일정이 비기를 기다리지 않고 모든 pull request를 검사할 수 있다. repository 맥락을 검토하고, 문서화된 규칙을 적용하며, 수천 건의 변경에 동일한 점검을 반복할 수 있다.

CLAUDE.md에 저장된 지침은 프로젝트, 규칙, 경계를 설명한다. 별도의 REVIEW.md는 특정 repository에서 어떤 실패가 문제인지 검토자에게 알려준다. code owner는 민감한 경로를 식별하고 관련 없는 경로를 제외할 수 있다.

검토자가 동일한 실수를 반복해 지적하면 팀은 그 교훈을 상류 단계로 옮길 수 있다. lint rule을 추가하고, instruction file을 개선하고, skill을 수정하거나, 새 자동화 점검을 만들 수 있다. 그러면 검토 피드백은 재사용 가능한 인프라가 된다.

과거 실패는 평가 사례가 된다. Anthropic은 incident, revert, 이후 수정과 관련된 pull request를 수집했다고 말한다. 엔지니어들이 근본 버그를 검증했으며, 이제 검토자는 매일 그 세트를 대상으로 실행된다.

이는 두 사람 사이의 만남으로서의 검토와는 중요한 차이를 보인다. 이 시스템은 개인의 기억에 의존하는 대신 실행 가능한 점검에 교훈을 보존하려 한다. 각 incident는 조직의 미래 탐지 범위를 확장할 수 있다.

그럼에도 인간 검토는 지역적 정확성으로 환원할 수 없는 질문을 계속 다룬다. 엔지니어들은 기능이 존재해야 하는지, 추상화가 해로운 선례를 만들지는 않는지, 증거가 배포를 뒷받침하는지를 결정한다.

이들은 청구, 업데이트 메커니즘, 지속적 통합, 릴리스 워크플로 등 민감한 영역도 점검한다. 코드가 국소적으로는 올바르게 보여도 이러한 변경은 광범위한 영향을 미칠 수 있다.

따라서 이 과정은 모든 측면에서 기계가 더 나은 검토자라고 선언하지 않는다. 기계에는 반복 수행 가능한 읽기 작업을 맡기고, 사람에게는 목적, 아키텍처, 불확실성, 책임이 수반되는 결정을 맡긴다.

이러한 분업은 엔지니어링 역량도 바꾼다. 엔지니어는 의도를 명확히 하고, 제약 조건을 식별하며, 검증을 설계하고, 증거를 해석하고, 에이전트가 잘못된 목표를 최적화했을 때 이를 알아차려야 한다. 코드를 읽는 일은 여전히 유용하지만, 이해에 이르는 유일한 경로는 더 이상 아니다.

Anthropic의 Scion 팀은 관련 사례를 제시했다. 엔지니어들은 Claude가 때때로 국소적 패턴에는 맞지만 비효율적이거나 지나치게 방어적인 설계를 추구했다고 보고했다. 사람은 시스템 수준의 트레이드오프를 이해했기 때문에 그러한 방향을 거부해야 했다.

“human in the loop”라는 표현은 이 역할을 흐릴 수 있다. 기계의 출력을 단지 승인하는 사람은 취약한 안전장치다. 경계를 정하고, 증거를 선택하며, 자동화를 언제 멈춰야 하는지 아는 사람이 실질적인 통제력을 제공한다.

다른 조직이 얻을 교훈은 검토자를 없애는 것이 아니다. 기계적 점검과 판단을 구분하는 것이다. 사람이 중대한 결과를 초래하는 결정과 불명확한 증거에 대한 권한을 유지할 때 자동화된 검토 범위는 가치를 발휘한다.

Claude Code 리뷰가 끝없는 에이전트 루프를 피하는 방법

Anthropic은 검토 프로세스가 명시적으로 수렴하도록 설계되지 않으면 AI 작성자와 AI 검토자가 무한한 작업을 만들어낼 수 있음을 발견했다.

검토가 많다고 자동으로 더 좋은 것은 아니다. Anthropic은 한 Claude Code 풀 리퀘스트가 하룻밤 사이 50회가 넘는 검토 및 수정 라운드를 거쳤다고 설명한다. 결국 작성자가 그 루프를 멈췄다.

검토자는 매번 새로운 치명적 결함을 발견한 것이 아니었다. Anthropic은 버전 기록을 이용해 반복된 지적 사항을 분석했고, 약 59%가 첫 번째 검토 당시 이미 존재하던 코드와 관련됐음을 확인했다.

에이전트는 새 수정 사항만 평가하는 대신 계속해서 기존의 추가 문제를 찾아냈다. 각 코멘트는 또 다른 수정, 커밋, 검토를 촉발했다. 시스템은 허용 가능한 최종 상태를 향해 효율적으로 나아가지 못한 채 계속 작동했다.

이 실패는 AI 코드 리뷰 특유의 위험을 보여준다. 사람은 가치가 낮은 제안을 몇 초 만에 기각할 수 있다. 반면 작성 에이전트는 그 제안을 실행하는 경향이 있어, 검토 에이전트에 더 많은 검토 대상을 제공하는 또 다른 diff를 만들어낸다.

Anthropic은 수렴 제어 장치를 도입했다. 세 번의 라운드가 지나면 검토자는 작성자에게 접근 방식을 재고하도록 요청한다. 이후 단계에서는 전체 변경 사항을 반복적으로 탐색하는 대신 새 diff에 집중한다.

검토자는 관련 결함 전체 범주도 한 번에 보고한다. 이를 통해 작성자는 연속된 라운드에서 유사한 코멘트를 받는 대신 모든 사례를 수정할 수 있다. 이전에 게시된 지적 사항은 다시 나타나서는 안 된다.

Anthropic은 이러한 변경이 내부 검토 주기를 개선했다고 말한다. 한 번의 검토 및 수정 라운드 후 통과하는 풀 리퀘스트의 비율은 65%에서 78%로 상승한 것으로 보고됐다.

다섯 번 이상 라운드가 필요한 풀 리퀘스트의 비율은 8.9%에서 1.5%로 떨어진 것으로 보고됐다. 통과 전 평균 검토 횟수는 2.08회에서 1.32회로 감소했다. 이 지표들은 여전히 회사 자체 보고 수치이지만, 많은 에이전트 워크플로가 간과하는 운영상 문제를 다룬다.

자동화된 노동은 급여가 없다고 해서 무료가 아니므로 수렴은 중요하다. 추가 라운드마다 모델 용량을 소비하고, 변경을 지연시키며, 더 많은 코드를 만들고, 이후 점검이 검사해야 할 자료를 늘린다.

검토자가 가상의 위협에 과도하게 반응할 때도 같은 문제가 나타난다. Anthropic은 적대적 검토가 근시안적으로 변해 과도한 검증이나 복잡성을 부추길 수 있다고 말한다. 가능한 실패를 발견하도록 최적화된 시스템은 새로운 유지보수 비용을 초래할 수 있다.

위험 기반 검토 깊이는 하나의 통제 수단을 제공한다. Anthropic의 정식 출시된 Code Review service는 일반 리포지터리와 중요 리포지터리에 서로 다른 검토 수준을 지원한다. 회사는 이제 대부분의 검토가 6분에서 10분 안에 끝난다고 말한다.

하지만 더 빠른 검토자가 근본적인 거버넌스 문제를 해결하지는 않는다. 팀은 여전히 어떤 지적이 중요한지, 어떤 경로에 더 깊은 점검이 필요한지, 몇 번의 주기가 허용 가능한지를 결정해야 한다.

검토 지침도 숨은 정책 계층이 될 수 있다. CLAUDE.md, REVIEW.md, 또는 분류 프롬프트에 취약한 가정이 담겨 있다면 에이전트는 리포지터리 전반에 걸쳐 그 가정을 일관되게 적용할 수 있다.

일관성은 규칙이 올바를 때만 도움이 된다. 팀은 검토자를 안내하는 지침에 대해 책임자, 버전 관리, 평가 사례, 검토 체계를 갖춰야 한다. 그렇지 않으면 자동화가 사람이 알아차리기 전에 잘못된 정책을 더 빠르게 확산시킬 수 있다.

이 지점에서 공유된 엔지니어링 맥락이 중요해진다. 에이전트를 도입하는 조직은 아키텍처 결정, 장애 교훈, 폐기된 접근 방식에 대한 지속적인 기록이 필요하다. 검색 가능한 engineering knowledge base는 하나의 검토 스레드를 넘어 그 맥락을 보존하는 데 도움이 될 수 있다.

Anthropic의 프로세스가 작동하는 이유는 검토자를 측정이 필요한 시스템으로 다루기 때문이다. 정확도, 노이즈, 라운드, 장애, 개발자 반응을 추적한다. 이러한 피드백 루프 없이 AI 검토자를 설치하는 것은 눈에 보이는 도구만 복제하고 운영 모델은 놓치는 일이 될 것이다.

Anthropic의 결과가 아직 입증하지 못한 것

가장 강한 주장은 여전히 자체 보고에 기반하며, Anthropic은 다른 인프라, 예산, 장애 허용 수준을 가진 팀에도 결과가 적용된다는 점을 보여주지 못했다.

첫 번째 불확실성은 측정에 관한 것이다. Anthropic은 병합된 풀 리퀘스트가 두 배 이상 늘었고 되돌리기 비율은 40% 넘게 감소했다고 보고했다. 그러나 기초 데이터셋, 절대 비율, 또는 장애 심각도 분포는 공개하지 않았다.

되돌리기 비율의 하락은 중요한 결과를 가린 채 긍정적으로 보일 수 있다. 팀은 되돌리는 대신 정방향으로 수정하거나, 기능 플래그를 비활성화하거나, 그런 이름이 붙지 않는 회귀를 감수할 수 있다. 되돌리기는 유용하지만 불완전한 지표다.

장애율은 또 다른 안전장치를 제공하지만, 공개 게시물은 상세한 장애 추이를 제공하지 않는다. 심각도와 노출 데이터가 없으면 외부인은 이 프로세스가 위험을 줄였는지, 아니면 실패 처리 방식을 바꿨는지 판단할 수 없다.

90% 작성 비율도 비슷한 모호성을 안고 있다. 이 수치가 생성된 줄 수, 승인된 줄 수, 커밋, 혹은 다른 단위를 세는지 명시하지 않는다. 또한 최종 코드에 이르기 전 사람의 프롬프팅, 편집, 반복 작업이 얼마나 있었는지도 드러내지 않는다.

Anthropic의 환경은 이 방법에 유난히 유리하다. 회사는 모델을 통제하고, 병렬 검토자에 상당한 컴퓨팅 자원을 투입할 수 있으며, 에이전트 생성 워크로드를 중심으로 내부 인프라를 개발한다.

직원들 역시 공개 출시 전에 Claude Code를 직접 사용한다. 새 기능은 내부 배포, 최신 채널, 그리고 안정 채널을 거칠 수 있다. 기능 플래그를 사용하면 전체 배포 없이도 동작을 비활성화할 수 있다.

의료, 금융, 산업 또는 안전 필수 시스템을 운영하는 팀은 다른 요구 사항에 직면할 수 있다. 빠른 롤백으로 모든 결과를 되돌릴 수는 없다. 결함 있는 데이터 마이그레이션, 권한 변경 또는 외부 작업은 되돌릴 수 없는 피해를 낳을 수 있다.

Anthropic은 잘못된 병합의 탐지가 여전히 작성자, 온콜 엔지니어, 텔레메트리, 대시보드에 의존한다고 인정한다. 되돌리기나 장애가 증가할 때 승인 요건을 높이는 자동 회로 차단기는 아직 갖추지 못했다.

이 공백이 중요한 이유는 위험 분류가 오래될 수 있기 때문이다. 저위험으로 분류된 변경도 숨은 의존성과 상호작용할 수 있다. 개별적으로는 안전한 변경들의 연속도 위험한 결합 상태를 만들어낼 수 있다.

보안은 또 다른 우려를 제기한다. Anthropic은 자동화된 보안 검토를 사용하지만, 자체 위험 자료는 사람의 감독이 여전히 필요한 이유를 보여준다. sabotage assessment는 모델 모니터링을 완전한 보장이 아니라 발전 중인 통제로 설명한다.

커뮤니티 반응은 비용과 이해에 관한 더 넓은 의문을 제기했다. 일부 개발자는 Anthropic이 다른 곳에서는 경제성이 없을 검토 패턴을 유지할 수 있다고 주장한다. 또 다른 이들은 diff를 읽는 사람이 줄어들면 코드베이스에 대한 집단적 지식이 약화될 수 있다고 우려한다.

Anthropic은 Claude Code 팀의 누구도 제품 전체에 대한 완전한 정신 모델을 유지하지 않는다고 공개적으로 말한다. 대신 엔지니어들은 필요할 때 Claude에게 관련 서브시스템을 설명해 달라고 요청한다.

이 접근 방식은 설명을 최신 상태로 유지할 수 있지만, 의존성을 만든다. 생성된 설명이 어떤 상호작용을 놓치면 엔지니어는 불완전한 지도를 바탕으로 결정을 내릴 수 있다. 같은 모델 계열은 검토하는 코드에 내재된 가정을 반복할 수도 있다.

교차 모델 검토는 추가적인 다양성을 제공할 수 있지만, 정확도를 자동으로 높이지는 않는다. 서로 다른 시스템도 학습 패턴을 공유하거나, 관련 없는 이유로 실패할 수 있다. 중요한 특성은 단지 다른 모델 이름이 아니라 독립적인 증거다.

이러한 질문들이 Anthropic이 보고한 결과를 무효화하는 것은 아니다. 다만 그 결과가 무엇을 입증하는지 제한한다. 회사는 고무적인 방향성 지표를 갖춘 상세한 내부 프로세스를 보여줬을 뿐, 인간 코드 리뷰를 보편적으로 대체할 방법을 제시한 것은 아니다.

이 모델의 유효성을 시험할 세 가지 신호

다음 시험대는 인간의 개입 없는 병합이 확대되고, 검토 제품이 다른 회사에 도달하며, 경쟁사들이 다른 통제를 도입하는 상황에서도 Anthropic이 품질을 유지할 수 있는지다.

첫 번째 신호는 Anthropic 자체의 승인 정책이다. 현재 프로세스는 자동 점검을 통과한 뒤, 선별된 저위험 변경이 별도의 인간 검토자 없이 병합되는 것을 허용한다.

그 경계가 더 많은 제품 코드로 확장되는지 지켜볼 필요가 있다. Anthropic이 엔지니어들이 원하는 회로 차단기를 추가한다면, 자동 에스컬레이션은 더 넓은 배포의 신뢰성을 높일 수 있다. 장애가 증가하거나 더 엄격한 승인으로 되돌아간다면 그 주장은 약화될 것이다.

두 번째 신호는 자동화된 검토를 사용하는 외부 조직의 증거다. Anthropic은 Team 및 Enterprise 고객을 위해 Code Review를 출시했고, 익숙하지 않은 리포지터리와 엔지니어링 문화 전반에서 더 폭넓은 시험을 가능하게 했다.

유용한 지표는 코멘트 수나 검토된 풀 리퀘스트 수가 아닐 것이다. 팀은 승인된 지적 사항, 유출된 결함, 거짓 양성, 검토 지연 시간, 사람의 노력, 프로덕션 장애를 보고해야 한다.

Anthropic 외부에서 비교 가능한 결과가 나온다면 계층형 AI 검토가 확장될 수 있다는 주장이 강화될 것이다. 높은 노이즈, 늘어나는 모델 사용량, 또는 변하지 않는 장애율은 Anthropic의 성공이 내부 환경에 의존한다는 점을 시사할 것이다.

세 번째 신호는 경쟁 구도에서의 대응이다. OpenAI, GitHub, Google, Cursor 및 다른 코딩 에이전트 제공업체는 생성된 코드와 검토자 역량 사이의 같은 불균형에 직면해 있다.

그들의 선택은 위험 기반 검토가 공동의 패턴이 되는지를 보여줄 것이다. 경쟁 시스템은 교차 모델 검토, 더 강력한 샌드박싱, 형식 검증, 리포지터리별 평가, 또는 더 지속적인 인간 승인을 선호할 수 있다.

개발자는 이 논의를 AI가 버그를 찾을 수 있는지 여부로 축소하지 말아야 한다. 실질적인 질문은 완전한 검토 시스템이 주의를 배분하고, 책임성을 유지하며, 모든 계층이 무언가를 놓쳤을 때 안전하게 복구할 수 있는지다.

엔지니어링 리더에게 즉각적인 조치는 측정이다. 승인 정책을 바꾸기 전에 기준 검토 시간, 유출된 결함, 거짓 양성, 되돌리기 비율, 장애 심각도를 설정하라. 그 기준선이 없으면 더 빠른 병합이 비용을 다른 곳으로 옮기면서 개선처럼 보일 수 있다.

팀은 되돌릴 수 있는 변경과 되돌릴 수 없는 변경도 구분해야 합니다. 문서화, 플래그가 적용된 인터페이스 조정, 내부 도구는 인증, 결제, 마이그레이션, 릴리스 인프라와 같은 절차를 요구하지 않습니다.

Anthropic Claude Code의 리뷰 방식은 많은 팀이 곧 마주하게 될 문제에 구체적인 답을 제시합니다. 이는 사람이 모든 줄을 읽었다는 증명으로 보는 대신, 리뷰를 다층적 제어 시스템으로 다룹니다.

회사가 공개한 수치는 그 답을 맹목적으로 따라 하기보다 검증해 볼 가치가 있음을 보여 줍니다. 내일 에이전트가 코드 산출량을 두 배로 늘린다면, 오늘 리뷰어가 모든 내용을 읽지 않아도 안전하다고 판단하게 해 줄 증거는 무엇일까요?