클로드 코드 코드 리뷰 방식, AI가 90% 쓰고 되돌림 40% 줄인 7단계

Claude Code 코드의 약 90%를 Claude가 써요. 앤트로픽은 코드 읽기 대부분을 기계에 넘긴 뒤 6월부터 9월 사이 머지된 PR이 두 배 넘게 늘고, 되돌린 PR 비율은 40% 넘게 줄었다고 밝혔어요.

앤트로픽 Claude Code 팀이 자기 팀의 코드 리뷰 방식을 처음부터 끝까지 공개했어요. 애디 오스마니, 모건 웨스틀리 런트, 칭 왕이 2026년 10월 15일 claude.dev에 「How the Claude Code team does code review」를 올렸어요. 10월 29일 인포큐(InfoQ)가 개발자 반응을 묶어 다시 다뤘고, 11월 3일 오스마니의 새 장문에서도 이 글이 다시 인용되며 관심이 이어지고 있어요.

이 글은 2026년 11월 4일 기준으로 AI가 쓴 코드를 AI와 사람이 어떻게 나눠 검토하는지, 숫자로 무엇이 달라졌는지, 어떤 반론이 나왔는지 정리해요.

코드 90%를 Claude가 쓰는 팀의 숫자

글에 따르면 Claude Code 자체 코드의 약 90%를 Claude가 써요. 앤트로픽 전체 저장소에 하루에 들어가는 변경은 5월 약 2,500건에서 9월 3만 건 이상으로 늘었어요. 사람이 모든 줄을 읽는 방식으로는 감당할 수 없는 양이에요.

팀은 이렇게 적었어요. "리뷰를 없애지는 않았다. 다만 읽는 일 대부분을 기계로 옮겼다." 그 결과 6월부터 9월 사이 머지된 PR(코드 변경 요청)은 두 배 넘게 늘었고, 되돌린 비율은 40% 넘게 줄었어요. AI 리뷰를 시험 도입하자 실질적인 리뷰 의견이 달린 내부 PR 비율도 16%에서 54%로 올랐어요.

코드가 들어가기까지 거치는 7단계

1. PR 전에 Claude가 테스트, 빌드, 문법 검사를 돌리고, 새 맥락의 하위 에이전트가 변경 내용을 다시 봐요.
2. 모든 PR에 AI 리뷰가 붙어요. 여러 에이전트가 버그를 찾고, 다른 에이전트들이 그 지적이 맞는지 투표해요.
3. 보안 리뷰를 따로 돌려요. 해결 안 된 지적이 있으면 머지가 막혀요.
4. 필수 자동 검사(CI)가 빨간불이면 머지가 막혀요.
5. 위험도에 따라 사람 승인 수가 달라져요.
6. 머지 대기열, 기능 스위치, 단계적 배포를 거쳐요. 내부에서 먼저 쓰고 일반 사용자에게 넓혀요.
7. 문제가 생기면 배포 없이 기능을 끄고, 어느 단계에서 잡았어야 했는지 돌아봐요.

팀은 "대부분의 변경은 사람이 보기 전에 Claude가 적어도 한 번 리뷰하고 고친 상태"라고 적었어요. 그리고 "모든 지적에는 답해야 한다. 고치거나, 이유를 달고 닫는다"는 규칙을 둬요.

사람 승인은 위험도로 정해요

위험도	예시	필요한 사람 승인
낮음	문서, 문구, 내부 전용 기능, 스위치 뒤의 추가 기능	자동·보안 검사 통과 시 없음
중간	일반 제품 변경, 캐시·자동 업데이트·시스템 프롬프트	1명
높음	가장 위험한 코드, 항상 두 사람이 봐야 하는 경로	2명

위험도는 누가 썼는지가 아니라 무엇을 바꿨는지로 정해요. 팀은 "변경이 등급을 정하지, 작성자가 정하지 않는다"고 적었어요. 또 "에이전트의 승인은 절대 사람의 승인으로 치지 않는다", "변경을 지시한 사람이 그 결과를 책임진다"는 원칙도 밝혔어요.

AI 리뷰가 끝나지 않는 문제도 겪었어요

처음부터 매끄럽지는 않았어요. CLI 쪽 PR 하나는 밤새 50번 넘게 리뷰와 수정을 오갔어요. 조사해 보니 리뷰어가 계속 지적한 것의 약 59%는 첫 리뷰 때부터 있던 코드였어요. 새로 바뀐 부분이 아니라 원래 있던 코드를 붙잡고 있었던 거예요.

그래서 세 번째 라운드가 지나면 리뷰어가 작성자에게 접근 방식을 다시 생각하라고 요청하게 바꿨어요. 이후 한 번의 리뷰와 수정으로 통과하는 비율은 65%에서 78%로 올랐어요. 다섯 번 이상 오가는 PR은 8.9%에서 1.5%로, 통과까지 평균 리뷰 횟수는 2.08회에서 1.32회로 줄었어요.

"전체 구조를 머리에 담을 필요 없다"에 대한 반론

가장 많이 회자된 문장은 이거예요. "팀의 누구도 Claude Code 전체를 머릿속에 담고 있지 않고, 그럴 필요도 없다고 본다." 인포큐가 모은 해커뉴스 반응은 갈렸어요. 한쪽은 큰 장애가 났을 때 디버깅할 사람이 남지 않는다고 걱정했어요. 다른 쪽은 큰 조직에서는 원래 전체를 아는 사람이 없었으니 오히려 나아진 것이라고 봤어요. 보안 인증(SOC 2) 심사에서는 운영 반영 전 사람 두 번째 확인이 필요하다는 지적도 나왔어요.

오스마니는 11월 3일 글에서 이 리뷰 글의 경험칙 하나를 다시 꺼냈어요. "검사가 무엇을 놓칠지 말할 수 없다면, 빠른 승인 대신 제대로 된 리뷰를 요청하라."

그래서 나에게 무엇이 달라지나

Claude Code의 코드 리뷰 기능은 팀(Team)과 엔터프라이즈 요금제에서 정식으로 쓸 수 있어요. 내 컴퓨터에서는 /code-review 명령으로 가벼운 버전을 돌릴 수 있다고 글에 나와요. 작은 팀이라면 이 글의 틀을 그대로 빌려 오는 것만으로도 효과가 있어요. 변경의 위험도를 먼저 나누고, 낮은 위험은 자동 검사에 맡기고, 높은 위험만 사람이 깊게 보는 방식이에요. 다만 AI 승인을 사람 승인으로 세지 않는다는 원칙은 꼭 같이 가져가세요.

자주 묻는 질문

Q. 사람은 이제 코드를 전혀 안 보나요?
A. 아니에요. 위험도 중간은 1명, 높음은 2명이 승인해야 해요. 사람 없이 머지되는 건 낮은 위험 변경뿐이에요.

Q. AI 리뷰를 무한히 돌리면 더 좋아지나요?
A. 팀은 라운드가 늘수록 결과가 나빠지는 경우를 겪었어요. 그래서 세 번째 라운드 뒤에는 방식을 다시 생각하게 했어요.

Q. 되돌린 PR이 줄었다는 건 정확히 몇 건인가요?
A. 글은 건수가 아니라 비율로만 밝혔어요. 6월부터 9월 사이 되돌린 비율이 40% 넘게 줄었다고 적었어요.

출처: How the Claude Code team does code review (claude.dev) · InfoQ · Addy Osmani (X) (2026년 11월 4일 확인)