AI 에이전트 시대의 코드 리뷰 방식 (Claude Code 팀 사례)

Claude Code 팀이 에이전트가 대량으로 만드는 코드를 어떻게 리뷰하는지 소개하고, 발표자 팀의 경험과 비교합니다. 핵심은 리뷰를 사람이 줄 단위로 읽는 관문이 아니라 자동 검사와 상시 점검으로 바꾸고, 사람의 시간과 주의력은 사람만 풀 수 있는 문제에 쓰는 것입니다.

⏱ 00:00발표자는 에이전트로 빠르게 만드는 방법은 많이 이야기했지만, 그 과정에서 팀이 어떻게 소통하고 코드를 검토하며 무엇을 병합할지에 대한 이야기는 부족했다고 말합니다. Anthropic의 Claude Code 팀처럼 변경량이 사람이 감당하기 어려운 규모로 늘어난 상황에서는 리뷰 방식 자체를 다시 생각해야 한다는 문제 제기입니다.

발표자 팀도 T3 Code에 하루 많게는 800개의 PR이 들어오는 상황을 겪고 있으며, 소규모 팀으로 이를 처리하기가 거의 불가능하다고 말합니다. 그래서 이번 영상은 Claude Code 팀의 리뷰 흐름을 살펴보고 발표자 팀과 비교해 배울 점을 찾는 내용으로 구성됩니다.

⏱ 03:08발표자는 Claude가 Claude Code 자신의 코드 약 90%를 작성한다고 소개합니다. 발표자는 이 수치가 실제로는 더 높을 것이라고 생각했고, 자신의 팀도 몇 달째 직접 코드를 거의 고치지 않는다고 말합니다. 다만 이 비율은 발표 중 확정된 수치가 아니라 대략적인 감각으로 이야기된 것입니다.

Claude Code 팀이 공개한 글에 따르면 6월부터 9월 사이 병합된 PR 수는 두 배 이상 늘었고, 되돌려진(revert) 비율은 40% 넘게 줄었습니다. 발표자는 이 개선이 프로세스 변화만큼 모델 성능 향상에서 온 것으로 보이며, 자기 팀도 새 모델 도입 이후 되돌림 비율이 더 크게 줄었다고 말합니다.

⏱ 05:15Anthropic의 모노레포에서는 하루 병합되는 변경이 5월 2,500건에서 9월 30,000건 이상으로 늘었습니다. 이 속도에서는 한 줄씩 사람이 읽는 리뷰가 어렵거나 불가능하다는 것이 출발점입니다. 발표자는 리뷰의 두 가지 역할을 짚습니다. 하나는 배포 전에 문제를 찾아 고치는 것이고, 다른 하나는 팀 전체가 코드베이스를 함께 이해하도록 맥락을 공유하는 것입니다.

발표자는 두 번째 역할을 가장 과소평가된 부분으로 봅니다. 와이어 프로토콜이나 오케스트레이션 계층처럼 큰 변경이 빠르게 쌓일수록 팀원이 변경 내용을 이해하지 못하는 문제가 생기며, 이를 속도에 맞춰 유지하는 방법을 아직 찾는 중이라고 말합니다.

⏱ 06:43Claude Code 팀은 사람이 코드를 읽었는지 여부가 버그를 막는 좋은 기준이 아니라고 봅니다. 무엇이 잘못될 수 있는지 가장 정확하게 확인하는 수단이 사람인지 자동 검사인지를 판단해야 한다는 관점입니다. 발표자도 이에 동의하면서, 최근 T3 chat과 T3 code에서 생긴 회귀 버그 대부분은 리뷰 중 눈으로 봐서는 잡기 어려웠을 것이라고 말합니다. 그래서 코드를 오래 들여다보는 것보다 다양한 방식으로 분석하고 검증하는 것이 필요하다고 봅니다.

또 리뷰는 이제 PR을 올린 뒤 기다리는 마지막 관문이 아니라, 작성하는 동안 맞춤법 검사처럼 계속 돌아가는 과정이 되었습니다. 발표자는 사람에게 요청되기 전에 에이전트가 최소 한 번은 리뷰하고 고쳐 두어야 하며, 그렇지 않은 PR을 올리는 것은 팀의 시간을 낭비하는 일이라고 강조합니다.

⏱ 09:09발표자는 GPU를 제외하면 지금 가장 희소한 자원이 사람의 시간과 주의력이라고 말합니다. 그래서 사람만 풀 수 있는 문제에 사람의 시간을 쓰고, 나머지 확인은 자동화해야 한다는 것입니다. 발표자는 여기에 시간과 별개로 에너지라는 기준을 더합니다. 같은 시간이라도 지루하고 고통스러운 작업은 사람을 빨리 지치게 하므로, 그런 작업의 에너지 비용을 줄여 사람이 보람 있는 일에 집중하게 하는 것이 중요하다는 주장입니다.

리뷰 비용에는 리뷰하는 시간뿐 아니라 나쁜 코드가 만든 문제를 고치는 시간도 포함됩니다. 또 리뷰 요청과 수정 사이에서 PR이 사람을 기다리는 대기 시간이 길어 실제 배포를 가로막는 주된 병목이라고 지적합니다.

⏱ 10:50Claude Code 팀의 목표는 대부분의 PR이 사람 한 명 정도만 관여하고 병합되면서도 되돌림과 장애가 늘지 않는 것입니다. 이를 측정하기 위해 PR당 사람 승인 수, 사람 코멘트 수, 사람을 기다리는 시간을 추적하고, 되돌림과 장애율은 안전장치로 봅니다. 이 수치들이 오르면 사람의 시간을 줄인 것이 아니라 시간을 다른 곳으로 옮긴 것에 불과하다는 뜻입니다.

일반적인 변경은 엔지니어의 노트북이나 클라우드 세션에서 시작해 여러 단계의 리뷰를 거칩니다. 먼저 테스트, 빌드, 린트 같은 검증이 이루어지고, 필요하면 새 문맥의 두 번째 에이전트가 diff를 다시 검토합니다. 발표자는 복잡한 변경이라면 단순 검사를 넘어 실제로 실행해 보는 검증이 대개 가치가 있으며, UI 작업이라면 브라우저에서 직접 띄워 확인하는 것이 특히 중요하다고 덧붙입니다.