AI가 쓴 코드 검토, Claude Code 팀의 다섯 겹 점검과 사람 승인

Claude가 Claude Code 코드의 약 90%를 쓰게 되자 Anthropic은 코드 검토의 질문부터 바꿨습니다. ‘사람이 이 코드를 읽었는가’ 대신 ’무엇이 잘못될 수 있고, 그것을 가장 잘 잡아내는 점검은 무엇인가’를 묻습니다. 그렇게 만든 검토 체계는 다섯 겹입니다. PR(pull request, 작성한 코드 변경을 본 코드에 합쳐 달라는 요청)을 열기 전의 자체 검증, 여러 agent(스스로 판단해 작업을 처리하는 AI)가 함께 보는 자동 검토, 병합을 막는 보안 검토, CI(코드를 올릴 때마다 자동으로 빌드하고 시험하는 체계) 점검, 위험 등급에 따라 0~2명으로 정해지는 사람 승인이 차례로 이어집니다. 그래도 빠져나간 문제는 빠른 되돌리기가 잡습니다. Anthropic에 따르면 6월부터 9월 사이 Claude Code 팀이 병합한 PR은 두 배 넘게 늘었고, 병합 뒤 되돌린 PR의 비율은 40% 넘게 줄었습니다. AI coding agent에게 코드 작성을 맡기는 팀이라면 참고할 만한 설계로 보입니다. 각 단계가 어떻게 돌아가는지, 그리고 그대로 옮기기 전에 따져 볼 점이 무엇인지 정리합니다.

사람이 한 줄씩 읽을 수 없는 속도

Anthropic의 주 저장소인 monorepo(여러 프로젝트의 코드를 한 저장소에 모은 방식)에 하루 병합되는 변경은 2026년 5월 약 2,500건이었습니다. 9월 가장 많았던 날에는 30,401건에 이르렀습니다. 한 사람이 내보내는 변경도 많습니다. Claude Code를 만든 Boris Cherny는 2026년 3월, 터미널 탭 여러 개에 Claude 세션 다섯 개를 나란히 띄워 하루 20~30개의 PR을 내보낸다고 밝힌 바 있습니다. 이 속도라면 사람이 모든 변경을 한 줄씩 읽는 검토는 불가능합니다.

Anthropic은 ’사람이 읽었는가’를 코드의 품질과 안정성을 가늠하기에는 부정확한 대리 지표로 보고 내려놓았습니다. 대신 대부분의 PR이 많아야 사람 한 명만 거쳐 병합되게 하는 것을 목표로 삼았고, 그 한 명은 작성자 본인이어도 됩니다. 다만 되돌린 PR의 비율과 운영 중 장애 발생률을 계속 지켜봅니다. 검토를 줄인 만큼 되돌리기와 장애가 늘면 사람의 시간을 아낀 것이 아니라 검토에서 장애 수습으로 옮겼을 뿐이기 때문입니다.

다섯 겹으로 쌓은 검토

Anthropic은 이 체계를 안전 관리의 스위스 치즈 모델에 빗댑니다. 층마다 잡아내는 문제가 다르고, 모든 층을 빠져나간 문제는 빠른 되돌리기로 수습한다는 생각입니다.

작성 세션에서 먼저 하는 검증

첫 점검은 PR이 생기기도 전에 엔지니어의 Claude 세션 안에서 이뤄집니다. Claude가 직접 테스트를 돌리고 앱을 빌드한 뒤, 화면을 캡처해 디자인 시안과 비교합니다. 이어 앞선 대화 내용을 넘겨받지 않은 새 subagent(주 작업과 따로 움직이는 보조 agent)에게 diff(바뀐 부분)를 검토시킵니다. 코드를 쓴 대화의 맥락에 묶이지 않은 눈으로 한 번 더 보게 하는 셈입니다.

찾는 agent와 투표하는 agent

PR을 열면 Claude Code Review가 자동으로 검토를 시작합니다. 먼저 finder agent 여럿이 동시에 버그 후보를 찾습니다. ‘draft 값이 null일 수 있음’, ‘입력란에서 포커스가 빠질 때 save()가 두 번 실행될 수 있음’, ‘await 누락’, ‘쓰이지 않는 값’ 같은 지적입니다. 이어 voter agent들이 후보마다 실제 문제인지 투표하고, 통과한 것만 댓글로 남깁니다. agent 하나에 맡길 때 생기는 hallucination(AI가 사실이 아닌 내용을 그럴듯하게 지어내는 현상)과 헛지적을 줄이려는 구조입니다.

▲ 찾는 agent와 투표하는 agent

같은 실수가 여러 PR에서 되풀이되면 PR마다 따로 고치지 않습니다. linter(코드의 규칙 위반을 자동으로 찾는 도구) 규칙이나 CLAUDE.md(Claude Code가 작업을 시작할 때 읽는 프로젝트 지침 파일)의 지시를 더해 원인을 없앱니다. 예를 들어 Claude가 지금의 날짜 함수 대신 옛 도우미 함수 legacyFormatDate를 거듭 쓴다면, 그 함수를 막는 ESLint 규칙을 만들고 CLAUDE.md에도 규칙을 적는 식입니다.

코드를 맡은 담당자는 REVIEW.md 파일도 따로 씁니다. 디렉터리마다 어떤 모습이 실패인지, 무엇은 검토하지 않고 건너뛸지를 검토 agent에게 알려 주는 파일입니다.

• 문서 디렉터리: 문서가 실제 동작과 다르게 말하는 것이 실패입니다. README는 autoSave 설정이 기본으로 켜져 있다고 하는데 설정 코드에서는 꺼져 있는 경우가 그렇습니다.
• 설정 디렉터리: 연결 대상을 잘못 잡는 것이 실패입니다. 데이터베이스 주소가 staging(배포 전 시험 환경) 대신 production(실제 서비스 환경)을 가리키는 경우입니다.
• 건너뛸 파일: 자동으로 생성된 클라이언트 파일처럼 검토할 필요가 없는 파일을 적어 둡니다.

병합을 막는 보안 검토와 CI 점검

세 번째 층인 자동 보안 검토는 취약점을 하나라도 찾으면 병합을 막습니다. 막힌 PR은 commit(코드 변경을 저장소에 기록하는 단위)으로 문제를 고치거나, 오탐(false positive)이라고 까닭을 적어 표시해야 병합할 수 있습니다. 예를 들어 ’쿼리에 이스케이프하지 않은 입력이 들어간다’는 지적이 열려 있는 동안 그 PR은 병합되지 않습니다.

네 번째 층은 CI의 표준 점검입니다. 여기에 PR 양식이 더해져, 작성자는 무엇으로 시험했는지와 문제가 생기면 어떻게 되돌릴지를 PR에 적어야 합니다.

사람 승인 수는 위험 등급이 정한다

다섯 번째 층에서 비로소 사람의 승인이 등장합니다. 몇 명이 승인해야 하는지는 작성자의 판단이 아니라 자동 위험 분류로 정합니다. feature flag(코드를 배포해 둔 채 기능을 켜고 끄는 스위치) 뒤에 둔 코드는 문서 변경과 함께 낮은 등급에 들어갑니다.

PR마다 위험 등급은 AI 분류기가 매기고, 이와 독립된 또 하나의 분류기가 사람의 확인이 정말 필요한지 한 번 더 판단합니다.

▲ 위험 등급별 사람 승인 수

검토 agent도 매일 채점받는다

자동 검토가 믿을 만하려면 검토 agent의 정확도부터 관리해야 합니다. Anthropic은 운영 중에 생긴 장애와 되돌린 PR을 평가 사례로 바꿉니다. 해당 분야 엔지니어가 사례를 확인해 평가 세트에 더하고, 검토 agent는 매일 이 세트의 모든 사례로 채점받습니다. prompt(AI에 주는 지시문), 도구, 모델을 바꾸자는 제안은 전체 점수가 오를 때만 받아들입니다.

잡아낸 버그 수만으로 채점하면 함정이 생깁니다. 검토 agent가 모든 줄에 지적을 다는 쪽으로 기울기 때문입니다. 그래서 Anthropic은 작성자가 지적에 어떻게 반응했는지도 지표로 삼아 쓸모없는 지적, 곧 노이즈를 재고 점수에서 깎습니다.

agent끼리 검토하다 생긴 끝없는 반복

작성자와 검토자가 모두 agent이면 지적과 수정이 끝없이 되풀이될 수 있습니다. 실제로 내부 CLI(명령줄에서 쓰는 도구)의 한 PR은 밤사이 50번 넘게 검토와 수정을 오갔고, 결국 엔지니어가 끼어들어 멈췄습니다. 반복된 차례의 지적을 분석해 보니 약 59%는 최근 수정이 만든 새 결함이 아니라 첫 검토 때부터 있던 코드를 겨냥했습니다. 검토가 끝나지 않은 까닭은 새 버그보다 이미 있던 코드에 대한 지적이 차례마다 다시 나온 데 있었던 셈입니다.

Anthropic은 세 가지 장치로 이 문제를 풀었습니다.

• 검토는 세 차례까지: 세 차례가 지나면 작성 agent에게 한발 물러나 접근 방식을 다시 생각하라고 지시합니다.
• 후속 검토는 바뀐 부분만: 첫 검토 뒤의 차례에서는 새로 바뀐 부분만 봅니다.
• 같은 종류의 버그는 한 번에: ‘user 값이 null일 수 있음’ 같은 문제가 api.ts, form.ts, list.ts, menu.ts에 함께 있으면 파일마다 차례를 나눠 지적하지 않고 한꺼번에 알립니다. 작성 agent는 한 commit으로 모두 고칠 수 있습니다.

성과 수치와 비용, 따져 볼 두 가지

성과 수치는 읽는 법에 주의가 필요합니다. 되돌린 PR의 비율이 40% 줄었더라도 같은 기간 PR 수가 두 배가 됐다면, 되돌린 PR의 절대 건수는 계산상 오히려 약 20% 늘어납니다. 두 배에 0.6을 곱하면 1.2배가 되기 때문입니다. 비율만으로 안정성이 좋아졌다고 단정하기는 어렵고, 절대 건수를 함께 봐야 합니다.

비용 구조도 다릅니다. Hacker News에서는 Anthropic이 내부에서 token(AI 모델이 글을 처리하는 단위)을 넉넉히 쓸 수 있기에 token을 많이 먹는 여러 agent 검토를 감당할 수 있다는 지적이 나왔습니다. 모델을 직접 가진 회사라 PR 하나에 모델을 수십 번 부르는 검토도 돌릴 수 있습니다. 반면 외부 고객이 쓰는 Claude Code Review는 검토 한 번에 평균 $15~25가 듭니다. 일반 기업이나 개인 개발자라면 PR이 늘수록 이 비용이 감당하기 어려운 수준이 될 수 있습니다.

사람에게 남는 일과 책임

이 체계에서 엔지니어는 기계가 잘하지 못하는 판단에 집중합니다. 시스템 구조 설계, 근거의 타당성 평가, 그 기능을 만들어야 하는지에 대한 결정, 핵심 코드 검토가 그것입니다.

책임의 원칙도 분명합니다. Anthropic은 ‘You land it, you own it’, 곧 병합한 사람이 그 코드를 책임진다는 문화를 지킵니다. 운영 중 문제가 생기면 그 변경을 병합한 엔지니어가 원인을 찾아 고칩니다. telemetry(운영 중인 소프트웨어의 상태를 자동으로 모으는 기록), 빠른 되돌리기, feature flag가 이 책임을 뒷받침합니다. AI가 코드를 쓰고 검토하는 시간은 줄여 줘도 운영 책임은 온전히 엔지니어에게 남는다는 뜻입니다.

정리: 우리 팀에 옮겨 쓸 다섯 가지

Anthropic의 방식은 ’사람이 읽었는가’라는 질문을 ’위험에 맞는 점검을 거쳤는가’로 바꾼 것으로 볼 수 있습니다. 규모가 같지 않아도 다음은 바로 옮겨 쓸 수 있습니다.

1. CLAUDE.md는 짧게 두고, 되풀이되는 실수는 긴 지시 대신 linter 규칙과 자동 테스트로 막습니다.
2. REVIEW.md를 만들어 디렉터리별 실패 유형과 건너뛸 파일을 검토 agent에게 알려 줍니다.
3. agent끼리의 검토는 세 차례로 제한하고, 이후에는 바뀐 부분만 보며, 같은 종류의 버그는 한 번에 지적하게 합니다.
4. 위험 등급에 따라 사람 승인 수를 정하되, 위험이 크거나 보안에 민감하거나 구조를 바꾸는 PR에서는 봇의 승인을 사람의 승인으로 치지 않습니다.
5. 되돌린 PR은 비율과 절대 건수를 함께 추적하고, 병합한 사람이 그 코드를 끝까지 책임지게 합니다.

자동 검토 도구를 들이기 전에는 PR 한 건당 검토 비용부터 계산해 보는 것이 좋습니다. 사람의 검토를 줄이는 목적은 시간을 아끼는 데 있지, 그 시간을 장애 수습으로 옮기는 데 있지 않습니다.