리뷰에서 바뀐 것
Claude Code 팀은 Claude Code 코드베이스에 병합된 풀 리퀘스트가 6월부터 9월까지 두 배를 넘었고, revert해야 했던 비율은 40퍼센트를 넘겨 줄었다고 밝힙니다. ClaudeDevs는 이 수치를 2026년 10월 16일에 올렸습니다. 풀 리퀘스트 비교 구간은 6월에서 9월이고, 그 구간의 연도는 적혀 있지 않습니다.
팀은 Anthropic 모노레포의 반영 변경이 올해 5월 하루 약 2,500건에서 9월 하루 30,000건을 넘었다고도 밝힙니다. 이 하루 수치는 모노레포의 것입니다. Claude Code는 그 모노레포와 분리된 자체 저장소에 있고, 팀은 그 저장소도 부담이 크다고 말합니다. 팀은 변경이 이 속도로 나가면 사람이 한 줄씩 보는 리뷰는 극히 어렵고, 때로는 불가능하다고 말합니다. 리뷰에는 여전히 두 가지 일이 있다고 팀은 말합니다. 나가기 전에 문제를 잡는 일과, 코드베이스에 대한 공통의 이해를 만드는 일입니다. 글은 주로 나가기 전에 문제를 잡는 쪽을 따르고, 코드베이스를 함께 이해하는 이야기는 끝부분에서 다시 다룹니다.
팀이 던진다고 말하는 질문은, 이 변경에서 무엇이 잘못될 수 있고 자동 검사와 사람 가운데 어느 검사가 그것을 잡아야 하는가입니다. 리뷰는 예전에는 풀 리퀘스트가 열린 뒤에야 시작됐습니다. 이제는 변경을 쓰는 동안 돌아갑니다. 팀은 사람에게 보기 전에 대부분의 변경이 Claude에게 적어도 한 번은 리뷰되고 고쳐진 상태라고 말합니다.
풀 리퀘스트가 생기기 전에 Claude는 테스트, 빌드, 디자인과 비교한 스크린샷처럼 자신이 실행할 수 있는 검사의 출력을 보여 줘야 합니다. 그다음 변경을 쓴 세션과 분리된, 맥락을 새로 연 서브에이전트가 diff를 리뷰합니다. 팀의 많은 사람은 버그를 찾고, diff를 단순하게 만들고, 동작을 처음부터 끝까지 시험하는 내부 검사도 돌립니다. UI 변경은 디자인 가이드라인과 대조합니다. Claude Code를 만든 Boris Cherny는 Claude에게 자기 작업을 검증할 수단을 주는 일을, 좋은 결과를 위해 아마도 가장 중요한 일이라고 부릅니다. 그는 이렇게 하면 최종 결과가 두 배에서 세 배 좋아진다고 추정합니다. 그가 말하는 검증은 bash 명령, 테스트 스위트, 또는 브라우저나 폰 시뮬레이터 안의 앱입니다. 글은 그 배수를 그의 추정으로 제시합니다.
이어서 모든 풀 리퀘스트는 사람이 보기 전에 저장소 전체와 적힌 의도에 비춰 리뷰됩니다. 버그 수정에서는 리뷰어가 근본 원인을 봅니다. 리서치 프리뷰 당시 팀은, 실질적인 리뷰 코멘트가 달린 내부 풀 리퀘스트 비율이 16퍼센트에서 54퍼센트로 갔다고 말합니다. 이 수치와 함께 프리뷰 날짜나 고객 쪽 비율은 주어지지 않습니다. 1,000줄을 넘는 풀 리퀘스트는 대부분 발견 사항이 있고, 작은 풀 리퀘스트는 대부분 지적 없이 돌아옵니다.
팀은 여섯 겹의 검사를 쌓고 그 아래에 롤백을 두며, 이어서 빠른 탐지와 롤백을 일곱 번째 단계로 설명합니다.
- 풀 리퀘스트 전: 에이전트가 실행할 수 있는 검사의 출력을 보여 준 다음, 맥락을 새로 연 서브에이전트가 diff를 읽습니다.
- 풀 리퀘스트에서: Claude가 diff를 저장소와 적힌 의도에 비춰 리뷰합니다.
- 보안 리뷰: 팀 규칙에서는 열려 있는 버그 리뷰 또는 보안 리뷰 발견 사항이 머지를 막습니다.
- CI: 린트, 타입, 테스트, 빌드가 여전히 막습니다.
- 사람 승인: 변경의 위험이 등급을 정합니다. 더 적은 인원은 신뢰하는 작성자만 받고, 그 밖에는 두 번째 사람이 필요합니다.
- 릴리스: 머지 큐, 직원에게 먼저 적용하는 플래그, latest 채널, 그다음 stable.
- 출시 후: 배포 없이 플래그를 끄고, 인시던트 리뷰는 어느 층이 놓친 문제를 잡았어야 했는지 묻습니다.
위험도에 따른 승인과 공개된 제품
Anthropic 자체 Claude Code 저장소에서는 작성자가 아니라 변경이 등급을 정합니다. 분류기가 변경을 읽고 낮음, 중간, 높음 가운데 고릅니다. 두 번째 분류기는 등급만 보면 추가 인원이 필요 없을 때에도 또 한 사람을 요구할 수 있습니다. 소유자가 민감하다고 적어 둔 경로와 CI 워크플로 파일은 무엇이든 여전히 사람이 필요합니다.
표의 더 가벼운 경로는 저장소 신뢰 목록에 있는 작성자, 대개 그 저장소를 맡은 팀만 탑니다. 그 목록은 등급과 별개의 문입니다. 그 밖의 작성자는 두 번째 사람이 필요합니다. 에이전트의 승인은 사람의 승인으로 치지 않습니다. 자동 리뷰는 저위험 변경을 통과시킬 수 있고, 사람을 요구하는 자리는 채우지 못합니다. 에이전트가 쓴 풀 리퀘스트에서는 그 에이전트를 지시한 사람이, 변경을 직접 친 것과 같이, 필수 리뷰어로 계산됩니다. 승인 한 번은 커밋 하나를 덮습니다. 이후의 에이전트 푸시나, 손으로 처리한 머지는 승인을 다시 받아야 합니다.
그 변경을 만들지, 결제와 자동 업데이터와 CI를 어떻게 다룰지, 이 변경이 다른 사람이 따라 할 패턴을 만드는지, 테스트 출력과 발견 사항이 충분한지, 결과를 누가 맡는지는 여전히 사람이 결정합니다. 나가는 모든 변경의 책임은 사람에게 남아 있습니다.
Claude Code용 Code Review는 Team과 Enterprise 플랜에서 정식 제공됩니다. 관리자는 저장소마다 Quick, Standard, Deep을 정합니다. 이것은 리뷰어가 얼마나 세게 보는가의 깊이입니다. 팀이 설명하는 단계는 Deep입니다. 버그 하나를 놓치는 비용이 추가 리뷰 시간보다 클 때 씁니다. /code-review 명령은 더 가벼운 버전을 로컬에서 돌립니다. 팀 글은 가격을 적지 않았고, 로컬 명령을 어느 플랜에서 실행할 수 있는지도 말하지 않습니다.
여러 에이전트가 동시에 버그를 찾습니다. 이어서 별도 그룹이 투표하고, 진짜라고 충분히 동의할 때만 발견 사항이 올라갑니다. 몇 명이 동의해야 하는지는 공개되지 않았습니다. 이 풀 리퀘스트 리뷰어에서는 스타일, 진단, 정리만 다루는 발견 사항이 빠집니다. 팀은 그 필터를 자기 풀 리퀘스트에서 A/B 테스트한 뒤 유지했다고 말합니다. 남은 항목은 Important, Nit, Pre-existing으로 표시됩니다. Pre-existing은 그 풀 리퀘스트가 만들지 않은 버그입니다. 각 발견 사항은 고치거나, 이유를 달아 스레드를 닫습니다. 거짓 양성은 이렇게 걷어 냅니다. 문제를 고치는 이후 커밋은 발견 사항을 스스로 지웁니다.
Claude Code 팀의 규칙에서는 열려 있는 버그 리뷰 또는 보안 리뷰 발견 사항이 머지를 막습니다. 글은 그 차단을 원하는 독자에게 오픈소스 security review GitHub Action과 /security-review를 가리킵니다. Team과 Enterprise 플랜의 Code Review는 발견 사항을 올리고 승인은 사람에게 남깁니다. 이 제품이 팀의 머지 차단을 켜 주지는 않습니다. Anthropic 자체 저장소에서는 소유자가 어떤 저위험 변경을 자동 검사만으로 머지할지 정하고, 팀은 그 선이 계속 움직인다고 말합니다. 이 선택은 누가 더 가벼운 경로를 받는지를 정하는 신뢰 작성자 목록과 따로 있습니다.
로컬 명령에 대해 Claude Code 변경 기록은, 조정된 리뷰 설정이 없는 모델(Opus 5.5와 Sonnet 5.5를 포함)에서 medium effort의 /code-review가 정리 사항과 CLAUDE.md 관례 지적도 보고한다고 적습니다. 풀 리퀘스트 리뷰어에서는 스타일, 진단, 정리만 있는 발견 사항이 빠집니다.
| 위험 | 예 | 사람 승인 |
|---|---|---|
| 낮음 | 문서, 문구, 내부 전용 기능, 플래그 뒤의 추가 변경 | 자동 리뷰와 보안 검사가 통과하면 필수 없음 |
| 중간 | 일반적인 제품 변경과, 캐시, 자동 업데이터, 시스템 프롬프트 같은 민감한 영역의 변경 | 한 사람 |
| 높음 | 위험이 가장 높은 코드와, 항상 두 사람이 필요한 소수의 경로 | 두 사람 |
같은 흐름을 써 보는 방법
풀 리퀘스트 전에 팀은, 짧은 CLAUDE.md에 적어 둔 에이전트 실행 검사와 포매터·린터를 돌리는 훅을 독자에게 가리킵니다. 로컬 /code-review와 /security-review, 또는 맥락을 새로 연 서브에이전트도 가리킵니다. CLAUDE.md에는 스택, 관례, 목표, 목표가 아닌 것이 들어갑니다. 모든 리뷰가 이 파일을 읽으므로 팀은 짧게 유지합니다. 코드 소유자가 쓰는 REVIEW.md는 그 영역에서 실패가 어떤 모습인지 적고, 사소한 지적의 상한을 두고, 건너뛸 경로를 나열하고, 근거로 파일과 줄을 요구하고, 남은 수정 건수로 시작하는 요약을 요구합니다. 같은 지적이 계속 돌아오면 팀은 그 수정을 스킬, 린트 규칙, 또는 그 파일들 가운데 하나로 옮깁니다.
각 풀 리퀘스트에서는 린트, 타입 검사, 테스트, 빌드가 여전히 막습니다. 템플릿은 Testing, Risk, How to revert를 묻습니다. Claude가 그 절을 초안으로 쓸 수 있습니다. 변경을 요청한 사람이 확인합니다. 세 라운드가 지나면 리뷰어는 작성자에게 접근을 다시 생각하라고 묻습니다. 이후 패스는 새 diff를 리뷰합니다. 작성자에게는 버그의 한 부류를 고치라고 요청하고, 이미 올라간 발견 사항은 반복하지 않으며, 리뷰 에이전트는 기존 코드 위에서도 밤마다 돌아갑니다. 내부 풀 리퀘스트를 그린 팀 차트 캡션은, 그 수렴 변경 이후 풀 리퀘스트당 리뷰 라운드가 줄었다고 말합니다. 캡션에는 횟수가 없습니다.
승인은 변경에서 등급을 적고, 더 가벼운 경로는 신뢰하는 작성자에게 두며, 봇이 필수 사람 자리를 채우지 못하게 합니다. CODEOWNERS와 브랜치 보호로 인증, 결제, CI, 릴리스 워크플로, 인스톨러는 항상 사람이 필요하게 둡니다. 보증할 수 없는 새 커밋이 오면 그 승인을 무효로 합니다.
이들의 릴리스 경로는 머지 큐를 씁니다. 큐는 변경을 적용한 main에 대해 모든 검사를 다시 돌리므로, 따로 통과한 풀 리퀘스트 둘이 합쳐져 깨진 main이 되지는 않습니다. 새 동작은 대개 플래그 뒤에서 직원에게 먼저 나갑니다. 공개 릴리스는 latest 채널이 먼저이고 stable 채널이 뒤를 따릅니다. stable이 latest를 얼마나 늦게 따르는지는 공개되지 않았습니다. 플래그는 배포 없이 꺼집니다. 과거의 인시던트 풀 리퀘스트, fix-forward, revert는 그 코드를 아는 엔지니어가 확인하고, 리뷰어는 그 집합에 대해 매일 돌아갑니다. 그 매일 실행의 점수는 공개되지 않았습니다.
아직 목표로 남아 있는 것
목표는 Claude Code 저장소, 즉 CLI, 데스크톱과 웹 앱, 모바일 앱의 풀 리퀘스트 대부분이 많아야 한 사람, 그 사람이 작성자일 수 있는 상태로 머지되고, revert와 인시던트는 늘지 않는 것입니다. 글은 목표를 적습니다. 목표를 이뤘다고는 말하지 않습니다. 6월에서 9월의 근거는 규모와 revert 비율입니다.
사람 시간은 풀 리퀘스트당 승인 횟수의 중앙값과 95퍼센타일, 사람 코멘트, 풀 리퀘스트가 사람을 기다리는 시간으로 잽니다. revert 비율과 인시던트 비율이 가드레일입니다. 이 비율이 오르면 팀은 시간이 줄어든 것이 아니라 옮겨진 것이라고 말합니다. 그 중앙값, 코멘트 수, 대기 시간은 공개되지 않았습니다.
Claude가 Claude Code 코드의 약 90퍼센트를 작성한다는 문장은 팀이 전에도 말했다고 하는 문장입니다. 이 글에는 그 비율의 집계 방법이 없습니다.
revert나 인시던트 수치가 움직이면 승인을 조이는 서킷 브레이커는 아직 없습니다. 팀의 엔지니어들은 사람 승인 없는 머지로 더 많은 코드가 넘어가기 전에 이것을 원합니다. 출시일은 주어지지 않습니다. 나쁜 머지를 알아차리는 일은 여전히 작성자, 주간 온콜 로테이션, revert 및 인시던트 대시보드에 달려 있습니다. 인시던트 리뷰는 어느 층이 그 문제를 잡았어야 했는지 묻습니다.
CLI 풀 리퀘스트 하나는 작성자가 멈추기까지 하룻밤 사이에 리뷰와 수정을 50라운드 넘게 거쳤습니다. 팀은 이것을, 에이전트 작성자와 에이전트 리뷰어가 서로를 계속 바쁘게 한 한 사례로 말합니다. 사람은 사소한 지적을 몇 초 만에 넘길 수 있습니다. 에이전트는 그것을 고치고, 그러면 커밋이 하나 더 생기고 리뷰 라운드도 하나 더 생깁니다. 팀은 리뷰어가 계속 집어낸 대상을 git blame으로 보니 약 59퍼센트는 첫 패스부터 있던 코드였고, 리뷰어가 새 버그를 찾는 일은 드물었으며 라운드마다 오래된 것을 조금 더 찾았다고 말합니다. 글은 그 59퍼센트의 표본 크기를 주지 않습니다.
팀은 그 잡음을 사람이 코멘트를 어떻게 다루는지로 잽니다. 각 코멘트는 풀 리퀘스트에서의 반응으로 나뉩니다. 고쳤다, 틀렸다고 했다, 의도한 것이라고 했다, 또는 중요하지 않은 것으로 치워 두었다입니다. 리뷰어는 팀이 깨끗하다고 아는 풀 리퀘스트에도 돌아가고, 팀은 누군가에게 해로운 변경을 만들게 했을 보고를 얼마나 자주 하는지를 셉니다. 적어 둔 우선순위는 진짜 버그를 먼저 잡고, 리뷰 라운드를 줄이는 일을 다음에 두는 것입니다.
공통의 이해에는 정식 절차가 없습니다. 코드베이스의 한 조각이 필요한 사람은 Claude에게 그 조각의 설명을 요청하고, 어떤 사람은 Claude에게 그것을 가르쳐 주는 작은 산출물을 만들게 합니다. 팀은 열린 Slack 채널이 만들어지는 동안의 작업을 보여 준다고 말합니다. 작거나 중간 크기의 변경에서는 그것을 반영한 사람이 보통 나중의 실패를 고칩니다. 이들이 이름 붙인 안전장치는 작은 diff, 플래그, revert, 단계적 릴리스, 빠른 내부 사용입니다. 에이전트 때문에 시작 비용이 낮아지므로, 글은 팀원이 스레드 초반에 방향을 물어야 하고 풀 리퀘스트를 닫는 일은 보통이라고 말합니다.
출처
함께 본 출처
자료 및 작성 기준
이 글은 2026년 10월 16일 ClaudeDevs 게시물과, 같은 날 확인한 링크 글 claude.dev의 How the Claude Code team does code review, 그리고 조정된 리뷰 설정이 없는 모델(Opus 5.5와 Sonnet 5.5를 포함)에서 medium effort의 /code-review가 정리 사항과 CLAUDE.md 관례 지적도 보고한다는 Claude Code 변경 기록의 메모에 근거합니다. 팀 글은 가격을 적지 않았고, 로컬 명령을 어느 플랜에서 실행할 수 있는지도 말하지 않습니다. security review 설치 절차, best-practices 가이드, 별도의 Code Review 발표, 그 이후 변경 기록 항목은 다루지 않습니다. 차트 캡션은 수렴 변경 이후 내부 리뷰 라운드가 줄었다고 말하며 횟수는 주지 않습니다. 매일 도는 인시던트 평가는 공개된 점수 없이 설명됩니다.