Claude Code 팀의 코드 리뷰 방식

AI 요약

Anthropic은 에이전트가 작성하는 코드가 늘면서 사람이 모든 변경을 줄 단위로 읽는 방식이 어려워졌다고 설명합니다. 이들은 코드 리뷰의 목표를 사람이 코드를 읽었는지가 아니라, 변경에서 무엇이 잘못될 수 있고 어떤 검사가 이를 잡아야 하는지로 다시 잡았습니다. 대부분의 변경은 PR을 열기 전부터 Claude가 테스트, 빌드, 화면 캡처 같은 결과를 확인하고 새 문맥을 받은 하위 에이전트가 diff를 검토합니다. 반복해서 발견되는 문제는 리뷰 지침, lint 규칙, 프로젝트 설명 파일을 고쳐 원인부터 줄입니다.

자동 리뷰와 위험도별 승인

모든 PR은 사람이 보기 전에 Claude의 리뷰를 거칩니다. 여러 에이전트가 버그 후보를 찾고 별도 에이전트들이 후보를 검증해 일정 수 이상 동의한 내용만 댓글로 남깁니다. 스타일이나 정리 관련 지적은 걸러내고, 남은 지적은 심각도와 함께 표시합니다. 작성자는 각 지적을 수정하거나 이유를 적고 닫아야 합니다. 보안 리뷰도 별도로 실행하며 미해결 지적이 있으면 병합하지 않습니다.

변경 내용에 따라 승인 인원도 달라집니다. 문서나 내부 기능, 기능 플래그 뒤에 추가하는 변경은 자동 검사와 보안 검사 통과 후 사람 승인이 필요하지 않을 수 있습니다. 일반 제품 변경이나 캐시, 자동 업데이트처럼 민감한 영역은 한 명, 고위험 코드와 일부 지정 경로는 두 명이 승인해야 합니다. 변경을 분류하는 도구가 위험도를 정하고 다른 분류기가 추가 검토가 필요한지 판단합니다. 이 경로는 신뢰 목록에 오른 작성자에게만 적용되며 에이전트 승인은 사람 승인으로 계산하지 않습니다. 에이전트에게 작업을 맡긴 사람도 작성자와 같은 책임을 집니다.

되돌림을 안전망으로 삼는 운영

팀은 PR마다 사람의 승인 수, 댓글 수, 사람이 검토하기까지 걸린 시간을 측정합니다. 되돌림과 장애 발생률은 안전 기준으로 삼습니다. 6월부터 9월까지 Claude Code 저장소의 병합 PR은 두 배 넘게 늘었고 되돌린 비율은 40% 넘게 줄었다고 합니다. 별도로 Anthropic 모노레포에 하루 들어오는 변경은 5월 약 2,500건에서 9월 30,000건 이상으로 늘었습니다. 이 수치는 Claude Code 저장소만의 변경량은 아닙니다.

에이전트가 작성자와 리뷰어를 함께 맡으면 수정과 재검토가 끝없이 반복될 수 있습니다. 실제로 한 CLI PR은 리뷰와 수정이 50회 넘게 이어졌습니다. 팀은 리뷰어가 첫 검토 때부터 있던 코드를 뒤늦게 계속 지적하는 문제를 확인했고, 재검토 횟수를 측정하며 검토가 수렴하도록 방식을 바꿨습니다. 과거 장애를 일으킨 PR과 수정본도 평가 자료로 모아 리뷰어를 매일 점검합니다. 이미 문제가 없다고 아는 PR에 잘못된 지적을 하는지도 확인합니다.

검사만으로 모든 문제를 막지는 못하므로 기능 플래그, 온콜, 장애 검토와 병합 큐도 사용합니다. 플래그를 배포 없이 끌 수 있고 병합 큐는 변경을 main에 적용한 상태로 검사를 다시 실행합니다. 팀은 되돌림이나 장애가 늘면 승인 기준을 자동으로 강화하는 회로 차단기는 아직 마련하지 않았다고 밝혔습니다.

사람이 맡는 일과 코드 이해

팀은 사람이 모든 diff를 읽는 대신 기계가 놓치기 쉬운 판단과 높은 위험의 변경에 시간을 쓰려 합니다. 코드 리뷰가 팀의 코드 이해를 돕는 역할도 한다는 점은 인정하지만, 모든 구성원이 전체 시스템을 머릿속에 담을 필요는 없다고 설명합니다. 특정 모듈을 이해해야 할 때 Claude에게 해당 부분의 설명이나 시각 자료를 만들게 합니다. 변경을 일찍 공유하는 Slack 채널도 팀의 지식 교환에 쓰입니다.

Hacker News 반응

• @crooked-v — GitHub 저장소에 이슈가 5,000개나 쌓인 이유가 설명되는군요. 그중 약 3분의 1은 이전 동작이 무작위로 회귀한 문제 같습니다.
• @mixtureoftakes — 하루에 변경 3만 건이 병합된다고요? 아니요, 그럴 리가 없습니다. 무슨 일이 벌어지는지 이해하려고 합니다.
  • @sp4cec0wb0y — 코드가 더 많이 나온다고 성공을 뜻하는 지표는 아닙니다. Goodhart의 법칙을 떠올려야 합니다.
• @vavkamil — 보안 리뷰 지적을 짧은 이유만 적고 오탐으로 닫을 수 있다면, 그 절차가 저위험 오탐에만 적용되길 바랍니다. 심각한 지적을 오탐으로 닫을 때는 보안 담당자의 검토가 필요합니다. 링크된 오픈소스 보안 리뷰도 프롬프트 인젝션 공격에 대비해 강화되지 않았다고 README에 적혀 있습니다.
• @dylanhouli — 저는 여전히 줄 단위 리뷰를 멈추지 못합니다. 중복 코드와 불필요한 구조, 지나치게 복잡한 설계를 너무 많이 발견해서 그렇게 하지 않으면 무책임하다고 느낍니다.
  • @benoau — 그래서 저는 GitHub Copilot 자동 완성을 좋아합니다. 코드가 나타나는 동안 곁에서 방향을 잡고 확인할 수 있습니다.
• @RGS1811 — 코드에 익숙해지는 일이 수동 리뷰 능력과 어떻게 직접 연결되지 않나요? Claude가 설명을 써 주더라도 복잡한 diff를 자신 있게 평가할 수 있게 되지는 않습니다. 이미 검토하고 승인한 시스템에 같은 시스템이 만든 설명을 바탕으로 판단하게 됩니다.
• @ativzzz — 목표는 장애와 되돌림을 줄이면서 사람의 시간을 아끼는 것처럼 보입니다. 되돌림과 장애를 측정 대상으로 삼고 나면 그 수치가 목표가 되는 Goodhart의 법칙 문제는 없을까요?
• @grey-area — 하루 3만 건의 변경이 들어온다면 의미 있는 리뷰가 가능할까요?
  • @fipar — 제조업의 표본 검사는 같은 제품을 반복 생산할 때 효과를 냅니다. 코드는 매번 서로 다른 산출물입니다. 코드 리뷰는 테스트만으로 확인하기 어려운 설계의 유지 가능성이나 백도어도 살핍니다.
• @rddbs — 에이전트가 만든 코드를 자동으로 리뷰하는 방법이 아니라, 사람이 늘어난 PR을 따라가기 위해 어떤 도구와 기법을 쓰는지 궁금합니다. 동료의 기여를 계속 파악하고 싶지만 따라가기가 어렵습니다.
  • @pokstad — 에이전트를 첫 검토에 쓰면 사람이 나서기 전에 기여자에게 빠르게 피드백을 줄 수 있습니다. 사람 리뷰를 대체하기보다 보완합니다. 에이전트가 놓친 내용을 리뷰 지침에 반영하면 됩니다.

원문: Anthropic / 번역·요약: Trawling