Claude Code 팀의 코드 리뷰: 기계가 읽고 사람이 책임진다

claude.dev 블로그에 2026년 10월 15일 실린 “How the Claude Code team does code review”를 정리했다. 글쓴이는 Addy Osmani, Morgan Westlee Lunt, Qing Wang 세 사람이다. Anthropic은 Claude가 Claude Code 코드의 약 90%를 쓴다고 이미 밝힌 적이 있다. 원문은 여기서 질문을 던진다. 이렇게 많이 만들어지는 코드를 어떻게 리뷰하는지, 아직 누군가 코드를 읽기는 하는지, 무언가 깨지면 누가 잡는지를 묻는다.

답의 근거로 원문이 내놓는 수치는 두 가지다. 6월부터 9월까지 Claude Code 코드베이스에 병합된 PR은 2배 넘게 늘었고, 그중 되돌려야 했던 비율은 40% 넘게 줄었다. 원문은 리뷰를 없애서 얻은 결과가 아니라고 강조한다. 코드를 읽는 일 대부분을 기계로 옮기고, 사람의 시간과 주의를 기준으로 과정을 최적화하고, 실수를 빠르고 쉽게 되돌리는 데 크게 투자했다는 것이다. GeekNews에 GN⁺ 글로 올라온 것을 보고 원문을 읽었다.

코드 리뷰가 하던 두 가지 일

에이전트가 코드를 쓰면 변경 수가 빠르게 늘어난다. Anthropic 모노레포에 하루에 반영되는 변경은 올해 5월 약 2,500건에서 9월 3만 건 이상으로 늘었다. Claude Code는 모노레포와 분리된 별도 저장소에 있지만, 마찬가지로 큰 압력을 받고 있다. 이 속도로 출시하면서 사람이 한 줄씩 손으로 리뷰하기는 몹시 어렵고, 사실상 불가능할 수도 있다.

원문은 코드 리뷰가 두 가지 일을 한다고 정리한다. 하나는 출시 전에 문제를 찾아 고치는 일이고, 다른 하나는 팀 안에서 맥락과 코드베이스에 대한 이해를 공유하는 일이다. 글 대부분은 첫 번째 일을 다루고, 두 번째 일은 끝부분에서 다시 다룬다.

글쓴이들은 “사람이 코드를 읽었는가”라는 질문이 부정확한 대리 지표라고 본다. 정말 물어야 할 것은 “이 변경에서 무엇이 잘못될 수 있고, 그것을 잡기에 알맞은 검사는 자동 검사와 사람 중 무엇인가”라는 것이다. 이렇게 묻자 리뷰를 하는 시점도 바뀌었다. 예전의 리뷰는 코드를 쓰고 PR을 연 뒤 동료를 기다리는, 길 끝에 놓인 관문이었다. 지금은 글을 쓰는 동안 계속 돌아가는 맞춤법 검사처럼 리뷰가 상시 실행된다. 대부분의 변경은 사람에게 검토를 요청하기 전에 Claude가 최소 한 번 리뷰하고 고친다. 흔한 실수는 이 단계에서 대부분 걸러지므로, 팀의 주의는 더 높은 수준의 질문과 면밀한 검토에 남겨 둘 수 있다.

아끼려는 것은 사람의 시간이다

원문이 가장 희소한 자원으로 꼽는 것은 사람의 시간과 주의다. 사람만 풀 수 있는 문제에는 사람의 시간을 쓰고, 나머지는 자동 검사가 잡게 하는 것이 목표다. 지금의 변경 속도에서도 사람이 할 일은 여전히 매우 많고, 팀은 거의 매일 새로운 문제를 만난다.

사람의 시간에는 리뷰 비용의 두 쪽이 모두 들어간다. 하나는 사람이 리뷰하는 데 쓰는 시간이고, 다른 하나는 나쁜 코드가 망가뜨린 것을 고치는 데 쓰는 시간이다. 앞의 시간을 줄여도 그만큼 뒤의 시간이 늘어나면 소용이 없다.

그래서 팀은 Claude Code 저장소들(CLI, 데스크톱 앱과 웹 앱, 모바일 앱)에서 대부분의 PR이 사람 최대 1명의 관여로 병합되게 하되, 되돌리기나 사고는 늘지 않게 하는 것을 목표로 삼았다. 그 1명은 작성자 본인이어도 된다. 사람의 시간은 PR당 사람 승인 수의 중앙값과 95백분위수, 사람이 남긴 댓글, PR이 사람을 기다린 시간으로 측정한다. 되돌리기 비율과 사고 비율은 안전 기준(guardrail)으로 둔다. 이 비율이 오른다면 사람의 시간을 아낀 것이 아니라 다른 곳으로 옮긴 것일 뿐이기 때문이다.

변경 하나가 거치는 일곱 단계

일반적인 변경은 엔지니어의 노트북에서, 또는 Slack에서 실행한 Claude 세션에서 시작해 여러 계층의 코드 리뷰를 거친다. 원문의 그림 A는 작성자의 기기에서 사용자에게 닿기까지의 경로를 위에서 아래로 그렸다. PR 전에 작업을 검증하고, PR마다 필수 CI와 Claude 코드 리뷰, 보안 리뷰를 자동으로 돌린 뒤, 위험도에 따른 승인 단계에서 사람이 판단한다. 그다음 병합 대기열을 지나고, 병합 뒤에는 플래그를 켠 내부 사용, 점진적 릴리스, 지켜보다가 후속 수정을 하거나 되돌리는 단계가 이어진다. 그림의 설명 문구는 “경로 대부분은 자동화되어 있고, 사람의 주의는 위험이 있는 곳으로 간다”이다.

그림 B는 같은 구조를 겹겹이 쌓은 판으로 다시 그렸다. 검증, 필수 CI, AI 리뷰, 보안 리뷰, 사람 승인, 병합 대기열과 플래그라는 검사 계층 여섯 개에 서로 다른 위치로 구멍이 나 있고, 모든 계층의 구멍을 통과한 문제는 맨 아래의 빠른 롤백이 받아 낸다. 각 계층은 어떤 문제는 잡고 어떤 문제는 놓치지만, 모든 계층을 통과하는 문제는 적다는 뜻이다. 본문은 이 여섯 계층에 롤백을 더해 일곱 단계로 나눠 설명한다.

첫 번째 단계는 다른 사람이 보기 전에 작업을 검증하는 것이다. 지금 리뷰의 대부분은 PR이 생기기 전에 일어난다. 팀은 Claude에게 테스트, 빌드, 디자인과 비교할 스크린샷처럼 직접 실행할 수 있는 검증 수단을 주고, 다 됐다고 말하는 대신 실행 결과를 보여 달라고 요청한다. 그다음 하위 에이전트가 새 맥락에서 diff를 리뷰한다. 두 습관 모두 Claude Code 모범 사례 가이드에 나오는 방법이다. 팀원 상당수는 PR을 열기 전에 내부 스킬도 몇 개 실행한다. 하나는 버그를 찾고, 하나는 diff를 단순하게 다듬고, 하나는 동작을 처음부터 끝까지 확인한다. UI 변경은 디자인 지침과도 대조한다.

Claude Code를 만든 Boris Cherny는 Claude에게 작업을 검증할 방법을 주는 일을 좋은 결과를 얻는 데 아마 가장 중요한 요소로 꼽았다. 그는 검증 수단이 최종 결과를 2~3배 낫게 만든다고 추산하면서 이렇게 썼다. “검증은 도메인마다 모습이 다르다. bash 명령 하나를 실행하는 것처럼 단순할 수도 있고, 테스트 묶음을 돌리거나 브라우저나 휴대폰 시뮬레이터에서 앱을 시험하는 것일 수도 있다.”

자동 리뷰어가 같은 지적을 되풀이하면 팀은 원인이 있는 곳을 고친다. 스킬을 고치거나, 린트 규칙을 추가하거나, 다음과 같은 지시 파일을 갱신한다.

CLAUDE.md: 프로젝트가 무엇인지 Claude에게 알려 준다. 기술 스택, 관례, 목표와 비목표를 적는다. 리뷰할 때마다 읽히기 때문에, 큰 코드베이스에서는 짧게 유지하고 다른 문서를 가리키게 한다. 리뷰어는 여기 적힌 관례를 어기는 코드와, 이 파일의 어떤 줄을 낡게 만드는 변경도 지적한다
REVIEW.md: 코드 소유자가 쓰며, 자기 영역에서 무엇이 중요한지 리뷰어에게 알려 준다. 리뷰어가 이 파일을 실제로 따르는지는 따로 검사한다

원문은 좋은 REVIEW.md의 조건도 적었다. 좋은 파일은 짧다. 그 저장소에서 실패가 어떤 모습인지 적는데, 문서라면 “거짓말을 한다”, 설정이라면 “잘못된 곳으로 보낸다”는 식이다. 사소한 지적의 개수에 상한을 두고, 건너뛸 경로를 나열하고, 이름만 보고 추측하는 대신 파일과 줄 번호를 증거로 요구한다. 요약은 발견 건수로 시작하고, 고칠 것이 없으면 없다고 분명히 말하게 한다.

모든 PR에 AI 리뷰와 보안 리뷰를 붙인다

두 번째 단계는 모든 PR에 붙는 AI 리뷰다. 모든 PR은 사람이 보기 전에 Claude 리뷰를 받는다. 리뷰어는 저장소 전체와 PR에 적힌 의도를 놓고 diff를 읽으며, 이 변경이 문제를 해결하는지, 시스템에 맞는지, 다른 것을 망가뜨리지 않는지 묻는다. 버그 수정이라면 근본 원인을 찾는다. 공개 버전인 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 중 하나로 표시된다. 그래서 그 PR이 만들지 않은 기존 버그가 작성자의 잘못처럼 보이지 않는다.

모든 지적에는 응답해야 한다. 지적대로 고치거나, 이유를 적고 스레드를 해결 처리해야 한다. 밤사이 에이전트가 수정을 맡는 경우도 많아서, 작성자가 돌아와 보면 PR이 이미 한 차례 더 리뷰를 거친 상태이기도 하다.

세 번째 단계는 병합을 막을 수 있는 보안 리뷰다. 보안은 별도의 자동 리뷰를 받는다. 버그 리뷰나 보안 리뷰에서 나온 지적이 하나라도 열려 있으면 PR을 병합할 수 없다. 고치거나 짧은 이유를 적고 스레드를 닫아야 하며, 오탐도 이 방식으로 정리한다. 뒤의 커밋이 문제를 고치면 해당 지적은 저절로 해소된다. 오픈소스로 공개된 보안 리뷰 GitHub Action이나 /security-review 명령으로 같은 구성을 만들 수 있고, 설정 방법은 Claude Code의 자동 보안 리뷰 안내에 있다.

네 번째 단계는 병합을 막는 자동 검사다. 린트, 타입 검사, 모든 플랫폼에서 도는 테스트, 빌드처럼 흔히 쓰는 검사이고, 원문은 이 변경량에 맞춰 CI를 확장한 방법을 다른 글에서 다뤘다고 덧붙인다. 일반적인 CLI PR도 사람이 보기 전에 수십 개의 검사를 거칠 수 있다. PR 템플릿은 변경을 어떻게 테스트했고 어떻게 되돌리는지 묻는다. 이 칸은 Claude가 채울 수 있지만, 최종 확인은 변경을 요청한 사람이 한다.

승인 인원은 위험도가 정한다

다섯 번째 단계는 위험도에 맞춘 사람 승인이다. 문서 수정과 자동 업데이트 기능의 변경은 위험이 다르므로 리뷰도 다르게 받는다.

위험도	예시	필요한 사람 승인
낮음	문서, 문구, 내부 전용 기능, 플래그 뒤에 둔 추가 변경	자동 리뷰와 보안 검사를 통과하면 필요 없음
중간	일반적인 제품 변경, 그리고 캐시·자동 업데이트·시스템 프롬프트 같은 민감한 영역의 변경	1명
높음	가장 위험한 코드, 그리고 항상 2명이 필요한 소수의 경로	2명

이 표에는 조건이 붙는다. 가벼운 승인 경로는 저장소의 신뢰 목록에 있는 작성자에게만 열리며, 대개 그 저장소를 소유한 팀이 여기에 든다. 그 밖의 작성자는 두 번째 사람의 승인을 받아야 한다.

위험 등급은 작성자가 아니라 변경이 정한다. 분류기 하나가 변경을 읽고 위험 등급을 고르고, 두 번째 분류기는 등급상 필요 없더라도 이 변경에 사람이 한 명 더 필요한지 따로 묻는다. 소유자가 민감하다고 지정한 경로와 모든 CI 워크플로 파일처럼 항상 사람이 필요한 경로도 있다.

에이전트의 승인은 사람의 승인으로 치지 않는다. 자동 리뷰는 저위험 변경을 통과시킬 수는 있지만, 사람이 필요한 자리를 채울 수는 없다. 그리고 변경을 지시한 사람이 그 변경을 책임진다. 에이전트가 쓴 PR에서는 에이전트에게 지시한 사람이 필수 리뷰어 중 한 명으로 계산되며, 그 사람이 코드를 직접 입력한 경우와 똑같이 다룬다.

승인은 특정 커밋 하나에만 유효하다. 에이전트가 푸시한 커밋이나 누군가 손으로 해결한 병합처럼, 시스템이 보증할 수 없는 새 커밋이 들어오면 다시 승인을 받아야 한다.

병합 뒤에는 빨리 발견하고 되돌린다

여섯 번째 단계는 병합 대기열, 플래그, 점진적 릴리스다. 병합 대기열은 변경을 적용한 main에서 모든 검사를 다시 돌린다. 그래서 따로따로 통과한 PR 두 개가 합쳐져 main을 깨뜨리는 일이 생기지 않는다. 새 동작은 보통 플래그 뒤에 두고 Anthropic 직원에게 먼저 내보내는데, 직원들이 워낙 많이 쓰기 때문에 사용자보다 먼저 회귀를 발견하는 경우가 많다. 공개 릴리스는 먼저 latest 채널에 나가고, stable 채널이 그 뒤를 따른다.

마지막 일곱 번째 단계는 빠른 발견과 빠른 롤백이다. 그래도 일부 실수는 빠져나가므로, 마지막 계층은 그 실수를 빨리 잡는 데 집중한다. 플래그는 배포 없이 끌 수 있다. Claude Code 팀은 주간 당직을 돌리고, 사고 회고에서는 어느 계층이 이 문제를 잡았어야 했는지 묻는다.

잘못된 병합을 알아채는 일은 여전히 작성자와 당직자, 되돌리기·사고 대시보드에 달려 있다. 이 수치가 움직일 때 승인 요건을 자동으로 강화하는 회로 차단기(circuit breaker)는 아직 없고, 엔지니어들은 사람 없이 병합되는 코드가 더 늘어나기 전에 이 장치가 생기기를 원한다. 한 동료는 속도를 늦추면 오류율이 낮아지기는 하지만, 그것은 주로 모든 일을 덜 하기 때문이라고 말했다. 팀은 그보다 문제를 알아채고 고치는 속도를 높이는 쪽을 택했다.

리뷰어를 고치는 방법

리뷰 과정 자체도 계속 고쳐 나간다. 우선 모든 사고가 평가 세트(eval)가 된다. 팀은 사고를 일으킨 과거 PR을 후속 수정과 되돌리기 기록까지 함께 모으고, 그 코드를 잘 아는 엔지니어에게 각 버그와 그 위치를 확인받았다. 리뷰어는 매일 이 세트로 평가받는다. 원문의 그림 C는 이 순환을 그렸다. 사고나 되돌리기가 생기면 전문가가 확인한 사례로 세트에 더해진다. 리뷰어의 프롬프트, 도구, 모델을 바꾸면 매일 도는 평가에서 모든 사례를 기준으로 점수를 매기고, 점수가 오르면 변경을 유지하고 그렇지 않으면 버린 뒤 다음 변경으로 넘어간다.

잡음은 사람들이 댓글에 어떻게 반응하는지 보고 측정한다. 버그가 아닌 것을 많이 지적해도 괜찮다면 버그를 더 많이 잡기는 쉽기 때문에, 이를 견제할 지표가 필요하다. 팀은 리뷰어가 남긴 댓글을 PR 담당자의 반응에 따라 네 갈래로 나눈다. 지적대로 고쳤는지, 지적이 틀렸다고 했는지, 의도한 동작이라고 했는지, 중요하지 않다고 판단했는지를 본다. 또 문제가 없다고 알려진 PR에 리뷰어를 돌려서, 누군가 따랐다면 해로운 변경으로 이어졌을 지적이 얼마나 자주 나오는지 센다. 팀이 문서로 정한 우선순위는 실제 버그를 잡는 것이 첫째이고, 리뷰 회차를 줄이는 것이 둘째다.

작성자가 에이전트이면 잡음의 비용은 더 커진다. 사람은 사소한 지적을 몇 초 만에 넘길 수 있지만, 에이전트는 그 지적을 고치고, 그만큼 커밋과 리뷰가 한 번씩 더 생긴다.

리뷰는 수렴해야 한다. 에이전트 작성자와 에이전트 리뷰어는 서로에게 끝없이 일을 만들어 줄 수 있다. 한 CLI PR은 작성자가 멈추기 전까지 하룻밤 사이에 리뷰와 수정을 50회 넘게 반복했다. 리뷰어가 계속 지적한 내용에 git blame을 돌려 보니, 약 59%는 리뷰어가 처음 훑어볼 때부터 있던 코드였다. 리뷰어는 새 버그를 찾는 일이 드물었고, 회차마다 기존 버그를 몇 개씩 더 찾고 있었다.

팀 스스로 상황을 악화시킨 면도 있다. 회차마다 새로운 것이 하나씩 잡히다 보니, 리뷰를 여러 번 돌리는 것을 기본으로 삼는 데 익숙해져 있었다. 위험한 변경이라면 그럴 가치가 있지만 모든 PR에 필요한 것은 아니다. 팀은 이제 재현율(recall)과 함께 통과까지 걸리는 리뷰 회차도 추적하고, 재리뷰 방식을 다음과 같이 바꿨다.

회차 상한: 세 번째 회차가 지나면 리뷰어가 작성자에게 한발 물러서서 접근 방식을 다시 생각해 보라고 요청한다
diff만 재리뷰: 처음 몇 회차가 지나면 새로 바뀐 diff만 다시 리뷰한다
버그 유형 지적: 한 줄이 아니라 버그의 유형을 지적해서, 작성자가 같은 유형의 모든 사례를 고치게 한다
반복 금지: 이미 게시한 지적은 다시 올리지 않는다

이와 별도로 리뷰 에이전트는 매일 밤 기존 코드를 훑어서, 오래된 버그가 다른 곳에서 드러나기 전에 찾아낸다. 원문의 그림 D는 수렴 작업 전후의 내부 PR 수치를 비교한다.

지표	수렴 작업 전	수렴 작업 후
리뷰·수정 1회차 뒤 통과한 PR	65%	78%
5회차 이상 필요한 PR	8.9%	1.5%
통과까지 평균 리뷰 횟수	2.08	1.32

사람에게 남긴 다섯 가지 판단

깊이 몰입해 일하던 시니어 엔지니어를 불러내 흔한 실수를 잡게 하는 비용은 자동 리뷰보다 훨씬 크다. 원문은 Anthropic에서 사람의 일이 모든 diff를 읽는 것에서 기계가 잘하지 못하는 결정으로 옮겨 갔다고 말한다. 그림 E는 자동 검사가 전체를 둘러싸고 돌아가는 가운데, 다섯 지점에서 사람이 판단하는 모습으로 이를 그렸다.

이것을 만들어야 하는가: 방향과 안목, 범위를 판단한다. 리뷰 병목을 해결했다고 선언한 한 팀도 팀 밖에서 들어오는 변경에는 사람 리뷰를 남겨 두었다. 누군가는 “이걸 정말 해야 하나?“라고 물어야 하기 때문이다
위험한 코드: 결제, 자동 업데이트, CI 워크플로 같은 코드를 맡는다
아키텍처: 다른 사람들이 따라 할 패턴이 되는 설계를 판단한다
증거 읽기: 테스트 출력, 실행한 명령과 그 결과, 스크린샷, 리뷰어의 지적을 읽는다. 검사가 무엇을 놓칠지 말할 수 없다면 빠른 승인 대신 제대로 된 리뷰를 요청해야 한다
결과에 대한 책임: 누가 입력했든, 출시되는 모든 변경에는 책임지는 사람이 있다

코드는 누가 알고 있나

코드 리뷰의 두 번째 일은 코드베이스에 대한 이해를 퍼뜨리는 것이었다. 동료의 diff를 읽으면 무엇이 바뀌었고 각 부분이 어떻게 맞물리는지 알게 된다. 그렇다면 기계가 읽기를 대부분 맡을 때 사람은 코드를 어떻게 익히는가.

원문은 이를 위한 공식 절차가 없다고 밝힌다. 팀에서 Claude Code 전체의 멘탈 모델을 머릿속에 온전히 가진 사람은 없고, 그럴 필요도 없다고 본다. 코드베이스의 어떤 부분을 이해하고 싶으면 정확히 그 부분에 대한 설명 자료를 Claude에게 써 달라고 한다. 몇 분이면 끝나고, 지금 있는 그대로의 코드를 반영한다. 원문 그림에 나오는 예시 질문은 “Claude Code는 managed settings를 어떻게 가져오는가?“이다. 한 걸음 더 나아가, 그 부분을 시각화하고 자기가 배우기 좋은 방식으로 가르쳐 주는 작은 artifact를 Claude에게 만들게 하는 사람도 있다.

원문은 사람의 주의를 잘 쓰는 것이 목표라면 이 방식이 사소한 diff를 한 줄씩 읽는 것보다 낫다고 말한다. 한 줄짜리 문구 변경에서는 배울 것이 거의 없지만, 곧 고칠 모듈에 대한 설명 자료에서는 많은 것을 배운다. 공개 Slack 채널에서 일하는 것을 기본으로 삼는 문화도 도움이 된다. 다른 사람이 무엇을 만들고 있는지 만드는 도중에 볼 수 있기 때문이다.

반영한 사람이 고치고, 방향은 일찍 바꾼다

원문에는 “You land it, you own it”이라는 절이 있다. 작거나 중간 규모의 변경을 반영했는데 무언가 잘못되면, 대개 반영한 사람이 고치는 것이 팀의 규범이다. 이 규범이 나쁘게 흘러가지 않도록 받치는 조건은 다섯 가지다.

작은 변경: 변경이 작아서 리뷰하고, 디버깅하고, 되돌리기 쉽다
되돌릴 수 있음: 플래그, 되돌리기, 단계적 릴리스로 대부분의 실수를 몇 분 안에 원래대로 돌린다
영향 범위에 맞춘 기준: 비싼 코드일수록 더 많은 사람과 검사를 거친다
빠른 발견: 원격 측정과 내부 사용으로 회귀가 빨리 드러난다
비난이 아님: 고치는 일을 맡는 것은 그 사람이 맥락을 가장 많이 알기 때문이고, 사고 회고는 개인이 아니라 시스템을 살핀다

소유권은 함께 나누기도 한다. 팀원 상당수가 공개 채널에서 일하기 때문에, 누구나 다른 사람이 만드는 것을 보고 논의를 이어받거나 빈틈에 Claude를 투입할 수 있다. 코드를 소유하지 않은 사람도 피드백을 준다. 원문은 이런 개방성이 모든 줄에 관문을 두지 않고도 품질을 높게 유지하는 큰 이유라고 설명한다.

에이전트 덕분에 일을 시작하는 비용이 싸졌기 때문에, 반영하지 말아야 할 작업도 생긴다. 보통은 채널에서 누군가 왜 하는지 묻거나, 이전 결정을 짚거나, 더 단순한 방법을 제안하고, 작성자가 PR을 닫거나 다시 짠다. 코드를 빨리 썼으니 PR을 닫아도 손실처럼 느껴지지 않는다. 원문이 꼽는 요령은 다른 방향을 스레드에서 일찍 꺼내는 것이다. 다 만든 PR에 병합을 막는 댓글로 다는 것은 피해야 한다.

도입 체크리스트

원문은 이 과정을 팀에 도입하는 데 필요한 조각 대부분이 이미 나와 있다며, 네 단계로 나눈 목록을 붙였다.

PR을 열기 전에는 다음을 준비한다.

에이전트가 실행할 수 있는 검사를 짧은 CLAUDE.md에 적고, 포매터와 린터를 실행하는 훅을 더한다
로컬에서 /code-review와 /security-review를 실행하거나, 새 맥락의 하위 에이전트에게 리뷰를 맡긴다
REVIEW.md를 만들고, 반복되는 리뷰 지적을 그 파일로 옮긴다

모든 PR에는 다음을 적용한다.

CI를 필수로 하고, PR 템플릿에 “Testing”, “Risk”, “How to revert” 항목을 넣는다
저장소 하나에 AI 리뷰어(Code Review for Claude Code 또는 Claude Code GitHub Action)를 붙이고, 몇 주 동안 REVIEW.md를 다듬은 뒤 범위를 넓힌다
자동 보안 리뷰를 추가하고, 모든 리뷰 스레드가 해결되어야 병합할 수 있게 한다
리뷰에 들이는 노력을 위험에 맞춘다. 일상적인 변경은 빠르게, 놓친 버그가 비싼 곳은 깊게 본다(Code Review의 Quick, Standard, Deep)
리뷰 회차에 상한을 두고, 처음 몇 회차 뒤에는 새 diff만 다시 리뷰한다

승인 정책은 다음과 같이 정한다.

위험 등급을 문서로 정하되 작성자가 아니라 변경을 기준으로 삼는다. 엄격하게 시작하고, 근거가 쌓이면 완화한다
가벼운 승인 경로는 신뢰하는 작성자에게만 허용한다
CODEOWNERS와 브랜치 보호를 써서 인증, 결제, CI·릴리스 워크플로, 설치 프로그램에는 항상 사람이 필요하게 한다
봇의 승인이 필수 사람 승인을 대신하지 못하게 하고, 새 커밋이 들어오면 기존 승인을 무효로 한다

병합과 그 이후에는 다음을 갖춘다.

병합 대기열, 기능 플래그, 내부 우선 사용, 단계적 릴리스, 한 번에 되돌리는 롤백을 쓴다
사고와 되돌리기를 평가 세트로 만들고, 리뷰어의 프롬프트·도구·모델이 바뀔 때마다 다시 점수를 매긴다
사람의 시간을 측정하고, 되돌리기 비율과 사고 비율을 안전 기준으로 삼는다

토론에서 나온 이야기

GeekNews 글은 원문 요약 뒤에 HN 토론(2026-10-19 확인 기준 470점, 댓글 468개)에서 나온 주요 의견을 정리해 두었다. 아래는 그 정리를 다시 의역한 것이다.

이해는 누구에게 남는가: GN⁺ 정리에서 가장 길게 다룬 주제다. 누구도 풀지 못하는 치명적 버그가 생겼을 때 차근차근 디버깅할 인과 모델이 누구의 머릿속에도 없다는 점이 소프트웨어 신뢰 모델의 근본적인 변화라는 지적이 나왔다. Claude가 언제든 필요한 부분을 찾아 이해한다는 전제가 무너지면 복구할 길이 없다는 것이다. 다만 대형 레거시 시스템도 그해 유지보수를 맡은 사람에게 기대고 있으니 어느 정도 비슷하다는 단서도 붙었다. 필요할 때마다 LLM에게 요약을 받는 것은 지식이 아니라 검색이라는 비판, 테스트라도 읽지 않으면 코드가 해서는 안 될 일을 하지 않는다고 확신할 수 없다는 의견, 변경을 이해하려고 받는 설명조차 그 변경을 리뷰하고 승인한 바로 그 시스템에서 나온다는 지적도 있었다
하루 3만 건과 PR 수 지표: 사람이 하루 PR 3만 개를 따라갈 수는 없다는 반응과 함께, PR 개수만으로는 아무것도 판단할 수 없다는 지적이 나왔다. 번역 문자열이나 설정처럼 자주 바뀌는 항목이 많으면 수치가 몇 자릿수씩 달라지고, PR 크기도 알 수 없다는 것이다. 예전에 코드 줄 수로 개발자를 평가하던 관리자를 비웃었는데, 이제 같은 숫자로 AI를 평가하고 있다는 자조도 있었다
저위험 변경의 무검토 병합: 문서와 문구를 저위험으로 분류해 사람 검토 없이 병합하는 것을 두고, LLM이 쓴 문서를 아무도 읽지 않는 것은 납득하기 어렵다는 비판이 나왔다
규정 준수와 내부자 위협: SOC 2 심사에서 운영 환경에 들어가는 모든 코드가 다른 사람 최소 한 명의 검토를 받아야 한다는 요건을 받았다는 사람이, 작성자 본인일 수도 있는 사람 1명만으로 병합하는 방식이 어떻게 승인되었는지, 악의적인 내부자는 무엇으로 막는지 물었다. 같은 요건을 적용받는다는 다른 사람은 이 방식이 규정에 맞지 않을 것이라고 보면서도, 감사가 꽤 느슨하다고 덧붙였다
AI가 쓴 글이라는 의혹: 원문의 문체가 Claude 특유의 문체라는 지적이 여럿 나왔고, AI 판정 도구의 결과를 근거로 든 댓글도 있었다. 반대로 하루 대부분을 기계와 함께 일하다 보면 그 말투가 사람에게 옮을 수 있으니 직원이 직접 썼을 수도 있다는 의견도 있었다
토큰 비용: 막대한 적자를 내는 AI 회사가 토큰을 최대한 쓰는 방식을 소개하는 글이니, 모델 사용 비용을 따져야 하는 쪽의 관점에서도 읽어야 한다는 의견이 나왔다. 여기에는 Anthropic이 지난 두 분기 동안 흑자였다는 반박이 붙었다
제조 공정의 검사 방식: 대량생산 공정에서 카메라와 자동화 시스템이 고속으로 불량품을 걸러 내고 사람은 통계적으로 뽑은 표본을 자세히 보는 것처럼, 코드 리뷰도 자동 검사와 표본 검사를 결합하는 쪽으로 갈 수 있다는 비유가 나왔다. 여기에는 그것은 검토라기보다 지휘와 감독에 가깝다는 답이 달렸다

읽고 남는 것

원문은 마지막 절에서 공개 제품과 내부 운영의 경계를 직접 밝힌다. Code Review를 발표할 때 PR 승인은 여전히 사람이 내리는 결정이고, 제품은 승인이 아니라 지적만 게시한다고 했다. 하지만 팀의 내부 저장소는 그보다 더 나아가, 어떤 저위험 변경을 자동 검사만으로 병합할지 소유자가 정하게 하고 있으며, 그 경계는 계속 움직이고 있다고 적었다. 리뷰가 무언가를 놓치면 모델 앞에 무엇이 없었는지 묻고, 그 답을 CLAUDE.md나 스킬, 새 검사에 넣는다. 목표는 변경당 사람의 시간을 줄이면서 되돌리기는 예전보다 늘리지 않는 것이라고 정리한다.

읽으면서 가장 눈에 띈 것은 무엇을 측정하는지였다. 리뷰에 든 시간만 줄이려 했다면, 그 시간이 사고를 수습하는 시간으로 옮겨 가는 것을 놓치기 쉬웠을 것이다. 원문은 사람의 시간을 리뷰와 수습 두 쪽으로 보고, 되돌리기와 사고 비율을 안전 기준으로 묶어 두었다. 리뷰어를 평가할 때도 재현율만 보지 않는다. 댓글에 대한 사람의 반응과 깨끗한 PR에서 나온 해로운 지적, 통과까지 걸린 리뷰 회차를 함께 본다. 하룻밤에 50회 넘게 돈 PR과 git blame의 59%라는 수치는, 에이전트끼리 주고받는 리뷰에는 상한과 수렴 조건이 따로 필요하다는 것을 보여 준다.

한계도 원문에 적혀 있다. 지표가 나빠질 때 승인 요건을 자동으로 조이는 회로 차단기가 아직 없고, 엔지니어들도 사람 없이 병합되는 코드가 늘어나기 전에 그 장치를 원한다. 사람 없이 병합하는 범위를 넓히는 일이, 문제가 생겼을 때 그 범위를 자동으로 좁히는 장치보다 앞서 있다는 뜻이다. 또 원문이 성과로 내놓은 수치는 병합 PR이 2배 넘게 늘고 되돌린 비율이 40% 넘게 줄었다는 상대적인 변화뿐이고, 절대 건수나 PR당 사람 승인 수가 실제로 어떻게 바뀌었는지는 나오지 않는다. HN에서는 “하루 PR 3만 개”라는 말이 오갔지만, 원문에서 3만 건 이상은 Anthropic 모노레포에 하루에 반영되는 변경 수이고, Claude Code는 그 모노레포와 분리된 저장소에 있다. PR 수 지표를 의심하는 댓글이 나온 것도, 이런 숫자가 무엇을 세는지 글에서 바로 드러나지 않기 때문일 것이다.

다른 팀이 가져다 쓸 만한 것은 특정 도구보다 규칙 쪽으로 보인다. 위험 등급은 작성자가 아니라 변경으로 정하고 엄격하게 시작한다. 에이전트의 승인은 사람의 자리를 채우지 못하게 하고, 승인은 커밋 단위로 묶는다. 리뷰어가 같은 지적을 반복하면 REVIEW.md와 린트 규칙으로 원인을 옮기고, 리뷰 회차에는 상한을 둔다. 이 규칙들은 하루 변경이 수만 건에 이르지 않는 팀에서도 그대로 적용할 수 있다.

원문: How the Claude Code team does code review (claude.dev Blog, 2026-10-15. 글쓴이는 Addy Osmani, Morgan Westlee Lunt, Qing Wang 세 사람이고, 원문은 리뷰를 맡아 준 Emma Webb, Michael Segner, Amie Rotherham에게 감사를 전한다. GeekNews 글은 GN⁺ 등록 글이고, 2026-10-19에 확인했을 때 댓글은 HN 의견을 정리한 1개였다. Hacker News 토론의 점수와 댓글 수도 2026-10-19에 확인한 값이다. 원문의 그림은 라이선스 표기가 없어 싣지 않고 본문에서 말로 설명했다. 그림 D의 수치와 그림 속 예시 질문은 그림에 들어 있는 텍스트에서 가져왔다)