ONEDEV

Claude Code 팀이 AI가 만든 코드를 검토하는 6단계 자동화 흐름

Hacker News15일 전

Anthropic의 Claude Code 팀이 자사 코드베이스에서 코드 리뷰를 어떻게 운영하는지 공개했다. 전제는 명확하다. Claude Code의 코드 약 90%는 Claude가 직접 작성한다. 이 볼륨에서 사람이 모든 diff를 줄 단위로 읽는 것은 사실상 불가능하다. 팀이 택한 방향은 리뷰를 없애는 것이 아니라, 읽는 일 대부분을 기계로 옮기고 사람의 시간과 주의를 위험이 큰 지점에만 배분하는 것이다.

성과 지표부터 눈에 띈다. 6월에서 9월 사이 Claude Code 저장소에 병합된 풀 리퀘스트 수는 두 배 이상 늘었는데, 되돌려야 했던 변경의 비율은 40% 넘게 줄었다. 같은 기간 Anthropic 모노레포에 하루에 들어오는 변경은 5월 약 2,500건에서 9월 30,000건을 넘어섰다. Claude Code는 별도 저장소를 쓰지만 압박은 비슷하다.

팀이 세운 목표는 CLI, 데스크톱·웹, 모바일 앱 저장소의 대부분 PR이 최대 한 명의 사람만 거치고 병합되되, 리버트나 인시던트가 늘지 않는 것이다. 사람 시간은 PR당 사람 승인 수(중앙값과 95퍼센타일), 사람이 남긴 코멘트 수, PR이 사람을 기다린 시간으로 측정한다. 리버트율과 인시던트율은 안전선 역할을 한다. 이 수치가 오르면 사람 시간을 아낀 게 아니라 다른 곳으로 옮긴 것뿐이라고 본다.

리뷰는 PR이 열리기 전부터 시작된다. Claude에게 테스트, 빌드, 디자인과 비교할 스크린샷처럼 실행 가능한 검증 수단을 주고, 완료했다고 말하는 대신 출력을 보여주게 한다. 이어 서브에이전트가 새 컨텍스트로 diff를 다시 본다. 버그 탐색, diff 단순화, 엔드투엔드 동작 확인을 담당하는 내부 스킬도 돌리고, UI 변경은 디자인 가이드라인과 대조한다. Claude Code를 만든 Boris Cherny는 검증 수단을 주는 것이 좋은 결과를 얻는 데 가장 중요한 요소이며 결과를 두세 배 끌어올린다고 본다.

같은 지적이 반복되면 리뷰어를 탓하는 대신 원천을 고친다. 스킬이나 린트 규칙, 그리고 CLAUDE.md와 REVIEW.md 같은 지침 파일을 갱신한다. CLAUDE.md는 프로젝트의 스택과 관례, 목표와 비목표를 담고 모든 리뷰가 이를 읽기 때문에 큰 코드베이스에서는 짧게 유지하고 나머지는 다른 문서로 연결한다. REVIEW.md는 코드 오너가 작성하며, 해당 영역에서 실패란 어떤 모습인지 정의하고 사소한 지적에 상한을 두며 건너뛸 경로를 나열한다. 이름만 보고 추측하지 말고 파일과 줄 번호를 근거로 대라는 요구도 들어간다.

모든 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을 병합할 수 없고, 고치거나 짧은 사유로 스레드를 닫아 오탐을 해소한다. 이후 커밋이 문제를 해결하면 지적은 자동으로 풀린다. 같은 구성을 오픈소스 security review GitHub Action이나 /security-review 명령으로 적용할 수 있다. 그 아래에는 린트, 타입 검사, 전 플랫폼 테스트, 빌드가 깔린다. CLI PR 하나가 사람이 보기도 전에 수십 개 검사를 통과해야 하는 식이다.

실무적으로 달라지는 지점은 리뷰의 위치다. 예전에는 코드를 다 쓰고 PR을 연 뒤 동료를 기다리는 마지막 관문이었지만, 이제는 글을 쓰는 동안 돌아가는 맞춤법 검사기에 가깝다. 사람이 개입하기 전에 Claude가 이미 한 차례 이상 검토하고 고친 상태이므로, 팀의 주의는 반복적인 실수 대신 상위 수준의 판단과 새로운 문제에 쓰인다.

다만 이 수치는 Claude Code 팀이 자체 저장소와 Anthropic 모노레포에서 측정한 값이며, 팀이 직접 운영하는 파이프라인과 내부 스킬에 기반한다. 리뷰를 제거한 것이 아니라 읽는 주체를 기계로 옮기고, 실수를 빠르고 쉽게 되돌릴 수 있게 만드는 데 투자한 결과라는 점도 전제로 깔려 있다.