앤트로픽 사내 저장소에 하루 반영되는 코드 변경은 5월 약 2,500건에서 9월 3만 건 넘게 늘었습니다. 넉 달 만에 12배이고, 하루 24시간으로 나누면 1분에 약 21건입니다(다대구 계산).
그런데 Claude Code 팀은 이 속도에서도 리뷰를 없애지 않았다고 말합니다. 바꾼 건 사람이 읽는 범위입니다. 무엇을 바꿨는지에 따라 사람 승인을 0명, 1명, 2명으로 나눴는데요.
팀이 10월 15일 claude.dev에 올린 ‘How the Claude Code team does code review’와 11월 6일 기준 Code Review 제품 문서를 함께 읽고, 숫자가 실제로 무엇을 뜻하는지 다시 정리했습니다.
1. 90%를 Claude가 쓰는 팀이 먼저 막힌 곳
글은 애디 오스마니, 모건 웨스틀리 런트, 칭 왕이 썼습니다. Claude Code 자체 코드의 약 90%를 Claude가 쓴다고 밝혔고, Claude Code는 사내 모노레포와 따로 떨어진 저장소지만 같은 압박을 받는다고 적었습니다.
사람이 모든 줄을 읽는 방식은 이 양을 감당하지 못했습니다. 팀은 “리뷰를 없애지 않았다. 읽는 일 대부분을 기계로 옮겼다”고 썼습니다.
팀이 결과로 내세운 숫자는 둘입니다. 6월부터 9월 사이 Claude Code의 머지된 PR은 두 배 넘게 늘었고, 되돌린 PR의 비율은 40% 넘게 줄었습니다. 다만 건수는 밝히지 않고 비율만 공개했습니다.
리뷰는 PR을 올리기 전부터 시작됩니다. Claude가 테스트·빌드·린터를 돌려 결과를 보여 주고, 새 맥락에서 띄운 하위 에이전트가 변경 내용을 한 번 더 읽습니다. 보리스 체르니는 Claude에게 스스로 검증할 수단을 주면 결과가 2~3배 좋아진다고 추정했습니다.
2. 사람 승인은 ‘누가 썼나’ 대신 ‘무엇을 바꿨나’로
모든 PR은 필수 자동 검사(CI), Claude 코드 리뷰, 별도 보안 리뷰를 거칩니다. CI가 빨간불이거나 두 리뷰에서 해결되지 않은 지적이 남으면 머지가 막힙니다.
그다음 분류기가 위험도를 매깁니다. 문서·문구·내부 전용 기능·플래그 뒤에 숨긴 추가 기능은 ‘낮음’으로, 자동 검사와 보안 리뷰만 통과하면 사람 승인이 필요 없습니다.
일반 제품 변경과 캐시·자동 업데이트·시스템 프롬프트 같은 민감한 영역은 ‘중간’으로 1명이 승인합니다. 가장 위험한 코드와 항상 두 사람이 봐야 하는 경로는 ‘높음’으로 2명입니다.
원칙도 몇 줄로 정리돼 있습니다. 에이전트의 승인은 절대 사람의 승인으로 치지 않습니다.
에이전트에게 변경을 지시한 사람은 필수 리뷰어가 되고, 승인은 특정 커밋 하나에만 유효합니다. CI 워크플로 파일과 소유 팀이 지정한 민감 영역은 위험도와 상관없이 항상 사람이 봅니다.
머지 뒤에도 층이 있습니다. 새 기능은 플래그 뒤에 숨겨 사내에서 먼저 쓰고, ‘latest’ 채널에 먼저 내보낸 뒤 ‘stable’이 따라갑니다. 문제가 생기면 배포 없이 플래그만 끕니다.
3. 진짜 성과는 리뷰가 끝나게 만든 것
AI 리뷰를 시험 도입하자 실질적인 리뷰 의견이 달린 사내 PR이 16%에서 54%로 약 3.4배가 됐습니다. 1,000줄 넘는 PR은 대부분 지적이 나왔고, 작은 PR은 대부분 깨끗하게 돌아왔다고 합니다.
부작용도 있었습니다. CLI 쪽 PR 하나가 밤새 리뷰와 수정을 50번 넘게 오갔고, 작성자가 직접 멈췄습니다. 리뷰어가 계속 지적한 내용을 git blame으로 추적해 보니 약 59%가 첫 리뷰 때부터 있던 코드였습니다.
지적에는 Important, Nit, Pre-existing 세 가지 표시가 달립니다. 마지막 표시는 이번 변경과 상관없이 원래 있던 문제라는 뜻이라, 아래 59% 문제와 바로 이어집니다.
팀은 세 번째 라운드 뒤에는 리뷰어가 접근 방식을 다시 생각하라고 요청하게 바꿨습니다. 몇 번 돈 뒤에는 바뀐 부분만 다시 보고, 같은 지적을 반복하지 않게 했습니다.
그러자 한 번에 통과하는 PR이 65%에서 78%로 늘었습니다. 다섯 번 이상 오가는 PR은 8.9%에서 1.5%로 약 6분의 1이 됐고, 통과까지 평균 리뷰 횟수는 2.08회에서 1.32회로 약 37% 줄었습니다(다대구 계산).
팀이 지켜보는 지표도 사람 쪽입니다. PR당 사람 승인 수의 중앙값과 95분위, 사람이 남긴 의견 수, PR이 사람을 기다린 시간을 재고, 되돌림과 사고 비율을 안전선으로 둡니다.
저는 루프 개선 숫자가 이 글에서 가장 쓸모 있다고 봅니다. AI 리뷰어를 넣는 건 쉽지만, 언제 멈추게 할지는 대부분의 팀이 아직 정하지 않았기 때문입니다.
4. 내 팀에서 쓰려면 비용 구조부터
앤트로픽은 같은 방식을 Code Review라는 제품으로 팔고 있습니다. Team과 Enterprise 요금제에서 GitHub 저장소에 쓸 수 있고, 저장소마다 Quick, Standard, Deep 세 단계를 고릅니다.
리뷰 1건당 고정 가격은 없습니다. 제품 문서는 리뷰를 요금제 포함 사용량과 별도로 사용 크레딧에서 토큰만큼 차감한다고 적었습니다. 단계, 변경 크기, 주변 코드의 복잡도, 검증할 후보 지적의 수에 따라 값이 달라집니다.
기본 설정에 함정이 있습니다. 저장소를 추가하면 처음엔 ‘푸시할 때마다 리뷰’로 시작하는데, 문서도 이 설정이 가장 많은 리뷰를 돌린다고 적었습니다. 비용은 PR 수에 PR당 푸시 수를 곱해 늘어납니다.
제품판 리뷰는 PR을 승인하거나 막지 않고, 의견과 체크 결과만 남깁니다. 코드를 빌드하거나 실행하지 않고 읽기만 하며, 데이터 무보관(ZDR)이나 HIPAA 설정을 쓰는 조직은 쓸 수 없습니다. 사내처럼 머지를 막는 규칙은 팀이 따로 걸어야 합니다.
문서가 권하는 순서는 이렇습니다. 월 지출 한도를 먼저 걸고, 대표 저장소 몇 곳을 ‘PR 열 때 한 번’이나 수동(@claude review)으로 시험합니다. 관리 화면에 쌓인 저장소별 평균 비용에 한 달 PR 수를 곱하면 예상 지출이 나옵니다.
요금제와 상관없이 쓰는 길도 있습니다. Claude Code 세션에서 /code-review를 실행하면 내 브랜치를 가볍게 리뷰하고, /security-review로 보안만 따로 볼 수 있습니다. 작은 팀이라면 위험도 3단계 표만 빌려 와도 사람의 시간을 어디에 쓸지 정리됩니다.
5. 해커뉴스는 ‘3만 건’에서 멈췄습니다
이 글은 해커뉴스에서 488점, 댓글 481개를 받았습니다. 최상위 댓글 80개 가운데 앞 60개를 다대구가 나눠 보니 ‘토큰 파는 회사의 홍보’라는 불신이 8건으로 가장 많았고, 하루 3만 건이라는 숫자를 의심하거나 놀란 댓글이 7건이었습니다.
Claude Code의 잦은 버그와 바뀌는 화면을 꼬집은 댓글, 되돌림·사고율만 보면 쌓이는 설계 부채를 놓친다는 우려가 각각 5건이었습니다. “우리 조직에도 비슷한 흐름을 만들었다”는 긍정적인 반응은 4건이었습니다.
원문에서 가장 도발적인 문장은 “팀의 누구도 Claude Code 전체를 머릿속에 담고 있지 않고, 그럴 필요도 없다”였습니다. 상장하면 감사인이 금융 데이터를 건드리는 코드에 사람 서명을 요구할 거라는 댓글도 있었습니다. 팀의 답은 필요한 부분의 설명서를 Claude에게 그때그때 쓰게 하는 것입니다.
이 문장이 남긴 질문은 같은 팀의 오스마니가 3주 뒤 따로 풀었습니다. 앞서 다룬 오스마니의 인지적 항복 글이 그 이야기이고, 같은 기간 Claude Code 핵심 인력의 이동은 Claude Code 주역 3명 이동 글에서 다뤘습니다.
본문 그래프 2점은 claude.dev 원문 수치와 해커뉴스 댓글 분류로 다대구가 직접 계산·집계·작성했습니다. 대표 이미지: 앤트로픽 공식 이미지.
