Claude Code 팀은 코드 리뷰를 어떻게 하는가 - 사람의 시간을 아끼는 다층 리뷰 체계
목차
- 개요
- 코드 리뷰의 목적 재정의
- 계층별 리뷰 체계
- 리뷰어를 개선하는 방법
- 사람이 여전히 관여하는 영역
- 팀 전체의 컨텍스트 공유
- 올린 사람이 책임진다
- 도입 체크리스트
- 커뮤니티 반응
- 결론
- Reference
개요
Claude Code의 코드는 약 90%를 Claude가 작성합니다. 이 정도의 물량이라면 코드는 어떻게 리뷰하는지, 아직도 누군가 코드를 읽는지, 무언가 깨지면 누가 잡아내는지 같은 질문이 자연스럽게 따라옵니다. Addy Osmani, Morgan Westlee Lunt, Qing Wang이 2026년 10월 15일 claude.dev 블로그에 공개한 글은 Claude Code 팀이 이 질문에 어떻게 답하고 있는지를 정리합니다.
6월부터 9월 사이 Claude Code 코드베이스에 머지된 PR 수는 두 배 이상으로 늘었고, 같은 기간 revert가 필요했던 PR의 비율은 40% 넘게 줄었습니다. 팀은 리뷰를 없앤 것이 아니라, 대부분의 “읽기” 작업을 기계로 옮기고, 사람의 시간과 주의력을 기준으로 최적화했으며, 실수를 빠르게 되돌릴 수 있도록 투자했습니다.
코드 리뷰의 목적 재정의
Anthropic 모노레포에 하루 동안 반영되는 변경 수는 5월 약 2,500건에서 9월 30,000건 이상으로 늘었습니다. Claude Code는 별도 저장소에 있지만 비슷한 압박을 받고 있으며, 사람이 한 줄씩 수동으로 리뷰하는 방식은 사실상 불가능에 가까워졌습니다.
글은 코드 리뷰가 두 가지 역할을 한다고 정리합니다.
- 문제를 배포 전에 찾아 고친다
- 팀 전체에 공유된 컨텍스트와 코드베이스 이해를 쌓는다
글의 대부분은 첫 번째 역할에 초점을 맞추고, 두 번째 역할은 후반부에서 다룹니다.
“사람이 코드를 읽었는가?”라는 질문은 사실 “이 변경으로 무엇이 잘못될 수 있고, 그것을 잡아내기에 적합한 검사는 자동화와 사람 중 무엇인가?”라는 질문의 부정확한 대리 지표라는 것이 팀의 관점입니다. 그래서 리뷰는 마지막 관문이 아니라, 글을 쓰는 동안 계속 동작하는 맞춤법 검사처럼 지속적으로 실행됩니다. 대부분의 변경은 사람이 보기 전에 Claude가 최소 한 번 리뷰하고 수정합니다.
희소 자원은 사람의 시간과 주의력
목표는 사람만 풀 수 있는 문제에 사람의 시간을 남겨두고, 나머지는 자동 검사가 잡도록 하는 것입니다. 사람의 시간에는 두 가지 비용이 있습니다. 리뷰에 쓰는 시간과, 나쁜 코드가 망가뜨린 것을 고치는 데 쓰는 시간입니다. 첫 번째를 줄였는데 두 번째로 다시 나타난다면 의미가 없습니다.
Claude Code 저장소들(CLI, 데스크톱·웹 앱, 모바일 앱)의 목표는 대부분의 PR이 최대 한 명의 사람만 관여한 상태로 머지되는 것이며, 그 한 명은 작성자 본인일 수도 있습니다. 단, revert나 인시던트가 늘어나서는 안 됩니다.
| 구분 | 지표 |
|---|---|
| 추적 지표 | PR당 사람 승인 수(중앙값, 95번째 백분위수) |
| 추적 지표 | 사람이 남긴 코멘트 수 |
| 추적 지표 | PR이 사람을 기다리는 시간 |
| 가드레일 지표 | revert 비율, 인시던트 비율 |
가드레일 지표가 오르면 시간을 절약한 것이 아니라 다른 곳으로 옮긴 것에 불과하다고 판단합니다.
변경 사항의 일생
하나의 변경은 다음 단계를 거칩니다.
| 단계 | 내용 |
|---|---|
| PR 이전 | Claude가 테스트, 빌드, 린터를 실행하고, 두 번째 에이전트가 새로운 컨텍스트에서 diff를 리뷰 |
| 필수 CI | lint, 타입, 플랫폼별 테스트, 빌드·패키징. 실패 시 머지 차단 |
| Claude 코드 리뷰 | 여러 에이전트가 병렬로 버그를 찾고, 검증자가 각 발견 사항에 투표하며, 살아남은 항목을 심각도순으로 정렬 |
| 보안 리뷰 | 별도의 검사. 두 리뷰 중 하나라도 열린 발견 사항이 있으면 머지 차단 |
| 위험도 기반 승인 | 분류기가 사람 승인 0명, 1명, 2명 중 등급을 결정. 일부 경로는 항상 사람이 필요 |
| 머지 큐 | 최신 main에 변경을 적용한 상태로 검사를 다시 실행 |
| 플래그 | 새 동작은 플래그 뒤에서 사내 사용자에게 먼저 제공 |
| 점진적 릴리스 | latest 채널이 먼저, stable 채널이 뒤따름 |
| 관찰과 대응 | 작성자와 온콜이 관찰하고, 플래그를 빠르게 끄거나 깨진 빌드를 revert |
계층별 리뷰 체계
글은 검증, 필수 CI, AI 리뷰, 보안 리뷰, 사람 승인, 머지 큐와 플래그의 여섯 계층 아래에 빠른 롤백이 깔린 구조를 제시합니다. 각 계층은 어떤 문제는 잡고 어떤 문제는 놓치지만, 모든 계층을 통과하는 문제는 드뭅니다.
1. PR 이전의 자체 검증
Claude에게 실행 가능한 무언가(테스트, 빌드, 디자인과 비교할 스크린샷)를 주고, 완료했다고 말하는 대신 출력을 보여달라고 요청합니다. 그리고 서브에이전트가 새로운 컨텍스트에서 diff를 리뷰합니다. 두 습관 모두 Claude Code 모범 사례 가이드에서 나온 것입니다.
PR을 열기 전에는 내부 스킬들이 실행됩니다. 하나는 버그를 찾고, 하나는 diff를 단순화하며, 하나는 end-to-end 동작을 확인합니다. UI 변경은 디자인 가이드라인과 대조합니다.
Claude Code를 만든 Boris Cherny는 검증을 “아마도 가장 중요한 것”이라고 부르며, 검증이 결과를 2~3배 좋게 만든다고 추정합니다. 그는 검증이 도메인마다 다르며, bash 명령 하나를 실행하는 것일 수도, 테스트 스위트를 돌리는 것일 수도, 브라우저나 폰 시뮬레이터에서 앱을 테스트하는 것일 수도 있다고 설명합니다.
자동 리뷰어가 같은 지적을 반복한다면 근원에서 고칩니다. 스킬을 고치거나, lint 규칙을 추가하거나, 지침 파일에 반영하는 방식입니다.
| 파일 | 역할 |
|---|---|
| CLAUDE.md | 프로젝트의 스택, 컨벤션, 목표, 비목표를 기술. 모든 리뷰가 이 파일을 로드하므로 짧게 유지하고 다른 문서로 링크. 리뷰어는 컨벤션 위반과 오래된 내용을 지적 |
| REVIEW.md | 코드 오너가 자신의 영역에서 무엇이 중요한지 작성. 팀은 리뷰어가 실제로 이를 따르는지 확인 |
좋은 REVIEW.md는 다음 특징을 가집니다.
- 해당 저장소에서 실패가 어떤 모습인지 명시합니다(문서라면 “거짓을 말한다”, 설정이라면 “잘못 라우팅한다”)
- nit 개수에 상한을 둡니다
- 건너뛸 경로를 나열합니다
- 이름만 보고 추측하지 말고 파일과 라인을 근거로 제시하도록 요구합니다
- 요약은 발견 개수로 시작하고, 고칠 것이 없으면 그렇다고 분명히 말하도록 요구합니다
2. 모든 PR에 대한 AI 리뷰
모든 PR은 사람이 보기 전에 Claude 리뷰를 받습니다. 리뷰는 diff를 저장소 전체 및 PR이 밝힌 의도와 대조해 읽고, 변경이 문제를 해결하는지, 시스템에 맞는지, 다른 무언가를 깨뜨리지 않는지를 묻습니다. 버그 수정의 경우 근본 원인을 찾습니다.
이 기능은 Code Review for Claude Code라는 제품으로 Team과 Enterprise 플랜에서 정식 제공되며, /code-review로 더 가벼운 버전을 로컬에서 실행할 수 있습니다. 리서치 프리뷰 단계에서 실질적인 리뷰 코멘트를 받은 사내 PR의 비율은 16%에서 54%로 올랐습니다. 1,000줄이 넘는 PR은 대부분 발견 사항이 있고, 작은 PR은 대부분 깨끗하게 돌아옵니다.
관리자는 저장소별로 Quick, Standard, Deep 중 하나를 설정합니다. Deep은 버그 하나를 놓치는 비용이 추가 리뷰 시간보다 큰 곳에서 가치가 있습니다.
검증 파이프라인은 다음과 같이 동작합니다.
- 여러 에이전트가 동시에 버그를 찾는다
- 별도의 그룹이 각 발견 사항에 투표한다
- 충분한 투표자가 실제 문제라고 동의한 경우에만 게시한다
스타일, 진단, 정리 성격의 발견 사항은 제외되며, 이 필터들은 도입 전에 사내 PR에서 A/B 테스트를 거쳤습니다. 결과는 심각도순으로 정렬된 인라인 코멘트로 나오며, 각각 Important, Nit, Pre-existing 중 하나로 태그됩니다. Pre-existing 태그는 PR이 만든 것이 아닌 버그를 작성자 탓으로 돌리지 않기 위한 것입니다.
모든 발견 사항에는 반드시 응답해야 합니다. 고치거나, 이유를 남기고 스레드를 해결 처리합니다. 에이전트가 밤사이 수정을 처리하는 경우도 많습니다.
3. 머지를 막을 수 있는 보안 리뷰
별도의 자동 보안 리뷰가 실행됩니다. 버그 리뷰나 보안 리뷰의 발견 사항이 하나라도 열려 있으면 PR은 머지될 수 없습니다. 발견 사항을 해소하려면 고치거나, 짧은 이유와 함께 스레드를 닫으면 되며, 이것이 오탐을 기각하는 방법입니다. 이후 커밋이 문제를 고치면 발견 사항은 자동으로 해소됩니다.
보안 리뷰는 오픈소스 security review GitHub Action 또는 /security-review 명령으로 사용할 수 있습니다.
4. 차단형 자동 검사
lint, 타입 검사, 모든 플랫폼에서의 테스트, 빌드가 실행됩니다. 일반적인 CLI PR 하나는 사람이 보기 전에 수십 개의 검사를 거칩니다.
PR 템플릿은 변경을 어떻게 테스트했는지와 어떻게 되돌릴 수 있는지를 묻습니다. 이 항목은 Claude가 채울 수 있지만, 요청한 사람이 최종 확인합니다.
5. 위험도 기반 사람 승인
| 위험도 | 예시 | 사람 승인 |
|---|---|---|
| Low | 문서, 문구, 사내 전용 기능, 플래그 뒤의 추가적 변경 | 자동 리뷰와 보안 검사가 통과하면 불필요 |
| Medium | 일반적인 제품 변경, 캐싱·자동 업데이트·시스템 프롬프트 같은 민감 영역의 변경 | 1명 |
| High | 가장 위험한 코드, 항상 2명이 필요한 소수의 경로 | 2명 |
등급을 결정하는 규칙은 다음과 같습니다.
- 등급은 작성자가 아니라 변경이 결정합니다. 분류기가 변경을 읽고 등급을 매기며, 두 번째 분류기가 등급과 무관하게 이 변경에 사람이 필요한지를 다시 묻습니다
- 오너가 민감하다고 지정한 경로와 모든 CI 워크플로 파일은 항상 사람이 필요합니다
- 더 가벼운 경로는 신뢰된 작성자(대부분 해당 영역을 소유한 팀)에게만 허용됩니다. 그 외에는 승인하는 사람이 한 명 더 필요합니다
- 에이전트의 승인은 절대 사람의 승인으로 계산되지 않습니다. 자동 리뷰는 low 위험 변경을 통과시킬 수는 있지만 필수 사람 승인 자리를 채울 수는 없습니다
- 에이전트가 작성한 PR을 요청한 사람은 직접 코드를 타이핑한 것과 마찬가지로 필수 리뷰어로 간주됩니다
- 승인은 특정 커밋 하나에만 적용됩니다. 에이전트의 push나 수동 머지 충돌 해결처럼 시스템이 보증할 수 없는 새 커밋이 생기면 다시 승인을 받아야 합니다
6. 머지 큐, 플래그, 점진적 릴리스
머지 큐는 변경을 적용한 main을 대상으로 모든 검사를 다시 실행합니다. 따라서 각각은 통과하는 두 PR이 합쳐져 main을 깨뜨리는 일이 생기지 않습니다.
새 동작은 보통 플래그 뒤에서 Anthropic 직원에게 먼저 배포됩니다. 사내의 많은 사용량 덕분에 사용자가 보기 전에 회귀가 드러나는 경우가 많습니다. 공개 릴리스는 latest 채널에 먼저 나가고, stable 채널이 그 뒤를 따릅니다.
7. 빠른 탐지와 롤백
플래그는 배포 없이 끌 수 있습니다. Claude Code에는 주간 온콜 로테이션이 있으며, 인시던트 리뷰에서는 어떤 계층이 그 문제를 잡았어야 했는지를 묻습니다. 탐지는 작성자와 온콜, 그리고 revert·인시던트 대시보드에 의존합니다.
아직 만들지 못한 것도 있습니다. revert나 인시던트 수치가 움직이면 승인 기준을 자동으로 강화하는 서킷 브레이커로, 엔지니어들은 더 많은 코드가 사람 없는 머지로 넘어가기 전에 이것이 필요하다고 봅니다.
한 동료는 속도를 늦추면 오류율이 내려가는 주된 이유가 모든 일을 덜 하기 때문이라고 지적했습니다. 팀은 느려지기보다 문제를 알아채고 고치는 속도를 높이는 쪽을 택했습니다.
리뷰어를 개선하는 방법
인시던트를 평가셋으로
팀은 인시던트를 일으킨 과거 PR들을 fix-forward, revert와 함께 수집했습니다. 해당 코드를 잘 아는 엔지니어들이 각 버그가 실제로 존재했는지와 위치를 확인했습니다. 리뷰어는 이 평가셋에 대해 매일 실행됩니다.
개선 루프는 다음과 같습니다.
- 인시던트 또는 revert가 발생한다
- 전문가가 확인한 케이스로 만든다
- 평가셋에 추가한다
- 리뷰어(프롬프트, 도구, 모델)를 변경한다
- 매일 평가를 실행해 모든 케이스에 대해 점수를 매긴다
- 점수가 오르면 유지하고, 그렇지 않으면 다음 변경에서 제외한다
노이즈 측정과 수렴 문제
노이즈는 두 가지 방식으로 측정합니다.
- 리뷰어 코멘트를 작성자의 응답에 따라 분류합니다(수정함, 틀렸다고 함, 의도된 것이라고 함, 중요하지 않다고 판단함)
- 깨끗한 것으로 알려진 PR에 리뷰어를 실행해, 해로운 변경으로 이어질 만한 지적을 얼마나 자주 하는지 셉니다
명문화된 우선순위는 “실제 버그를 잡는 것이 첫째, 리뷰 라운드를 줄이는 것이 둘째”입니다.
에이전트가 작성자일 때 노이즈의 비용은 더 큽니다. 사람은 nit 하나를 몇 초 만에 넘기지만, 에이전트는 커밋을 하나 더 만들고 리뷰 라운드를 한 번 더 유발합니다. 에이전트 작성자와 에이전트 리뷰어는 무한히 루프를 돌 수 있으며, 실제로 한 CLI PR은 작성자가 멈출 때까지 밤사이 50라운드 넘게 진행되었습니다.
git blame 분석 결과, 리뷰어가 계속 지적한 내용의 약 59%는 첫 번째 패스부터 이미 존재하던 코드였습니다. 라운드마다 오래된 버그를 몇 개씩 더 찾았을 뿐, 새로운 버그는 거의 없었습니다. 팀은 여러 라운드를 기본값처럼 받아들여 왔지만, 이는 위험한 변경에서만 가치가 있고 모든 PR에 필요한 것은 아니었습니다.
이에 따라 다음과 같이 바꿨습니다.
- 라운드 상한: 세 라운드가 지나면 리뷰어가 작성자에게 접근 방식을 재고하도록 요청합니다
- 처음 몇 번의 패스 이후에는 diff만 다시 리뷰합니다
- 버그의 클래스를 지적해, 작성자가 한 줄이 아니라 모든 사례를 고치도록 합니다
- 이미 게시된 발견 사항은 반복하지 않습니다
팀은 이제 recall과 함께 통과까지의 라운드 수를 추적합니다. 또한 리뷰 에이전트를 매일 밤 기존 코드에 대해 실행해, 오래된 버그가 다른 곳에서 드러나기 전에 잡아냅니다.
| 지표(사내 PR) | 이전 | 이후 |
|---|---|---|
| 한 번의 리뷰·수정 라운드 후 통과 | 65% | 78% |
| 5라운드 이상 필요 | 8.9% | 1.5% |
| 통과까지 평균 리뷰 횟수 | 2.08 | 1.32 |
사람이 여전히 관여하는 영역
일상적인 실수 하나 때문에 시니어 엔지니어를 깊은 작업에서 끌어내는 비용은 자동 리뷰보다 큽니다. 그래서 사람의 일은 다음 영역으로 옮겨갑니다.
| 영역 | 내용 |
|---|---|
| 이것을 만들어야 하는가 | 방향, 취향, 범위. 리뷰 병목을 해결했다고 본 한 팀도 “이걸 해야 하나?”를 묻기 위해 팀 외부의 변경은 계속 리뷰 |
| 위험한 코드 | 결제, 자동 업데이트, CI 워크플로 |
| 아키텍처 | 다른 사람들이 따라 할 구조 |
| 증거 읽기 | 테스트 출력, 실행한 명령과 결과, 스크린샷, 리뷰어의 발견 사항. 검사가 무엇을 놓칠지 말할 수 없다면 빠른 승인 대신 실제 리뷰를 요청 |
| 결과에 대한 책임 | 누가 타이핑했든 배포된 모든 변경에는 책임지는 사람이 있음 |
팀 전체의 컨텍스트 공유
코드 리뷰의 두 번째 역할은 코드베이스에 대한 이해를 퍼뜨리는 것입니다. 기계가 대부분을 읽는다면 사람은 코드를 어떻게 배우는가라는 질문이 남습니다.
이를 위한 공식 프로세스는 없습니다. Claude Code 전체의 멘탈 모델을 가진 사람은 없으며, 팀은 누구도 그럴 필요가 없다고 봅니다. 대신 필요한 부분에 딱 맞는 설명서를 Claude에게 요청합니다. 예를 들어 “Claude Code는 managed settings를 어떻게 가져오는가?” 같은 질문이며, 몇 분이면 끝나고 현재 코드를 반영합니다. 일부 엔지니어는 해당 코드 영역을 자신이 선호하는 방식으로 가르쳐주는 작은 시각적 artifact를 Claude에게 만들게 합니다.
사소한 diff를 한 줄씩 읽는 것으로는 배우는 것이 적지만, 곧 수정할 모듈에 대한 설명서는 많은 것을 알려줍니다. 공개 Slack 채널도 도움이 되며, 다른 사람이 무엇을 만들고 있는지 만드는 과정에서 볼 수 있습니다.
올린 사람이 책임진다
팀의 규범은 “You land it, you own it”입니다. 작은 또는 중간 크기의 변경을 반영했는데 무언가 깨지면, 보통은 반영한 사람이 고칩니다. 이 규범이 동작하는 조건은 다음과 같습니다.
- 변경이 작아서 리뷰, 디버깅, revert가 쉽습니다
- 플래그, revert, 단계적 릴리스로 대부분의 실수를 몇 분 안에 되돌릴 수 있습니다
- 영향 범위가 기준을 정합니다. 비용이 큰 코드에는 더 많은 사람과 검사가 붙습니다
- 텔레메트리와 사내 사용으로 회귀가 빠르게 드러납니다
- 비난이 아닙니다. 소유자가 가장 많은 컨텍스트를 가지고 있을 뿐이며, 인시던트 리뷰는 시스템을 살핍니다
소유권은 공개 채널을 통해 공유되며, 누구나 작업을 보고, 이어받고, Claude에게 빈틈을 맡길 수 있습니다.
에이전트 덕분에 작업을 시작하는 비용이 낮아졌기 때문에, 반영되지 말아야 할 작업도 생깁니다. 보통 누군가 이유를 묻거나, 이전 결정을 언급하거나, 더 단순한 방법을 제안하면 작성자가 PR을 닫거나 다시 구성합니다. 값싸게 생성된 코드를 닫는 것은 손실로 느껴지지 않습니다. 대안은 완성된 PR에 차단 코멘트로 남기기보다 스레드 초반에 제시하는 것이 좋습니다.
도입 체크리스트
글은 이 프로세스를 도입하려는 팀을 위한 체크리스트로 마무리됩니다.
| 단계 | 할 일 |
|---|---|
| PR 이전 | 에이전트에게 실행 가능한 검사를 주고 짧은 CLAUDE.md에 나열, 포매터와 린터를 실행하는 hook 추가 |
| PR 이전 | 로컬에서 /code-review와 /security-review 실행, 또는 새 컨텍스트의 서브에이전트 리뷰 |
| PR 이전 | REVIEW.md를 추가하고 반복되는 리뷰 코멘트를 옮김 |
| 모든 PR | CI 필수화, PR 템플릿에 Testing, Risk, How to revert 항목 추가 |
| 모든 PR | AI 리뷰어(Code Review for Claude Code 또는 Claude Code GitHub Action)를 저장소 하나에 붙이고 몇 주간 REVIEW.md를 조정한 뒤 확대 |
| 모든 PR | 자동 보안 리뷰를 추가하고, 머지 전 모든 리뷰 스레드 해결을 필수화 |
| 모든 PR | 리뷰 강도를 위험도에 맞춤(일상 변경은 Quick, 놓친 버그의 비용이 큰 곳은 Deep) |
| 모든 PR | 리뷰 라운드에 상한을 두고, 처음 몇 번 이후에는 새 diff만 다시 리뷰 |
| 승인 | 작성자가 아닌 변경 기준의 위험 등급을 문서화. 엄격하게 시작해 근거가 쌓이면 완화 |
| 승인 | 더 가벼운 승인 경로는 신뢰된 작성자에게만 유지 |
| 승인 | CODEOWNERS와 branch protection으로 인증, 결제, CI·릴리스 워크플로, 설치 프로그램은 항상 사람이 필요하게 설정 |
| 승인 | 봇의 승인이 필수 사람 승인을 대체하지 못하게 하고, 새 커밋이 오면 승인을 무효화 |
| 머지 이후 | 머지 큐, 기능 플래그, 사내 우선 사용, 단계적 릴리스, 원스텝 롤백 사용 |
| 머지 이후 | 인시던트와 revert를 평가셋으로 만들고, 프롬프트·도구·모델이 바뀔 때마다 리뷰어 재채점 |
| 머지 이후 | 사람의 시간을 측정하고, revert와 인시던트 비율을 가드레일로 사용 |
커뮤니티 반응
이 글에 대해서는 우려와 비판적 시각이 적지 않게 나왔습니다.
- 이 워크플로가 불필요한 변경 churn을 만들어내며, AI 주도로 PR 물량을 늘리는 방식 자체가 의문스럽다는 의견이 있었습니다
- LLM이 코드를 설명해주는 방식은 진짜 지식이 아니라 검색에 가깝고, 결국 누구도 시스템의 인과 모델을 머릿속에 갖지 못하게 될 수 있다는 우려가 나왔습니다. 사람이 컴퓨터의 도구가 되는 상황을 가리키는 “reverse centaur”라는 표현도 인용되었습니다
- PR 크기나 자동 생성 변경의 비율을 모르는 상태에서 PR 수만으로는 의미가 적다는 지적과 함께, 과거 개발자를 평가하던 코드량 지표로 AI를 평가하는 아이러니를 짚는 의견도 있었습니다
- low 위험인 문서 변경이 사람 리뷰 없이 머지된다는 점에 대해, LLM이 쓴 문서는 아무도 읽지 않는다며 의문을 제기한 의견이 있었습니다
- 독립적 리뷰와 내부자 위협을 요구하는 SOC2 같은 컴플라이언스 요건과 어떻게 맞출 수 있는지 묻는 질문이 있었고, 엄격한 감사인은 만족시키기 어려울 것이라는 답이 달렸습니다
- AI 벤더는 토큰 소비를 늘리는 데서 이익을 얻는다는 지적이 있었습니다
- 사람은 시간을 두고 컨텍스트를 쌓으며 변경을 이해하는데, 이 과정이 가볍게 다뤄졌다는 의견과 함께, 결국 에이전트가 “문제 없음”이라고 하면 사람 리뷰어가 형식적으로 승인하게 될 것이라는 예상도 있었습니다
- 비슷한 에이전트 워크플로를 조직 전체에 이미 적용했다며, Anthropic에게서는 더 정교한 파이프라인을 기대했다는 반응도 있었습니다
결론
Code Review 제품 발표에서도 밝혔듯이 PR 승인은 여전히 사람의 판단이며, 제품은 승인이 아니라 발견 사항을 게시합니다. 다만 Anthropic의 자체 저장소는 한 걸음 더 나아가, 어떤 low 위험 변경이 자동 검사만으로 머지될지를 오너가 결정할 수 있게 했고, 그 경계는 계속 움직이고 있습니다.
리뷰가 무언가를 놓쳤을 때 팀은 모델이 무엇을 보지 못했는지를 묻고, 그 수정을 CLAUDE.md, 스킬, 또는 새 검사에 반영합니다. 목표는 변경당 사람의 시간을 줄이면서 revert는 이전보다 늘리지 않는 것입니다. 핵심은 “사람이 코드를 읽었는가”라는 대리 지표에서 벗어나, 각 위험을 가장 적합한 계층이 잡도록 설계하고 그 결과를 revert와 인시던트로 검증하는 데 있습니다.