Anthropicが 자사 코드베이스의 80% 이상을 Claude가 작성한다고 밝혔다. 이 숫자는 단순히 놀랍다는 반응으로 소비하고 넘어갈 숫자가 아니다. 테크 리드 입장에서 이 수치가 의미하는 것은 하나다. 생성 속도는 이미 인간의 검증 속도를 압도하고 있다.
그렇다면 병목은 어디에 생기는가.
병목은 AI의 속도가 아니라 인간의 이해 속도다
velog에 공개된 '밥풀 프로젝트 AI 워크플로우 개선일지 #5'는 이 문제를 현장에서 직접 겪고 기록한 드문 사례다. 팀은 10일간 AI 기반 개발 워크플로우를 운영하면서 구체적인 병목 지점을 포착했다. 담당자는 자신의 구현을 이해하는 데 시간이 필요했고, 리뷰어는 담당 외 도메인의 코드 흐름을 파악하는 데 더 많은 시간이 걸렸다. AI는 코드를 이미 Merge할 준비가 끝났는데, 사람이 그 코드를 이해하는 속도가 따라가지 못하는 상황이었다.
여기서 중요한 오해를 짚고 넘어가야 한다. "인간의 이해가 병목이다"라는 말은 "그러니까 사람이 코드를 안 읽어도 된다"는 뜻이 아니다. 정반대다. AI가 만든 코드를 이해하지 않은 채 기능을 계속 쌓으면 인지 부채가 쌓인다. 코드는 늘어나지만 왜 이렇게 동작하는지 모르게 되고, 수정할 때마다 다시 AI에게 의존하게 되며, 결국 설계와 검토에 사람이 참여할 수 없게 된다. 이건 속도의 문제가 아니라 팀 역량의 문제다.
리뷰를 빠르게 하는 게 아니라, 이해를 워크플로우로 설계한다
밥풀 팀이 선택한 해법은 리뷰 승인 프로세스를 간소화하거나 리뷰어를 늘리는 운영적 접근이 아니었다. 이해 자체를 워크플로우의 구조적 단계로 만드는 것이었다.
핵심 설계는 세 가지다.
첫째, Explain Diff. AI가 구현한 코드를 파일 목록이 아니라 실행 흐름 순서로 설명한다. PaymentController 수정 → PaymentService 수정 → PaymentRepository 수정이 아니라, 결제 완료 요청 → 내부 Payment와 소유권 확인 → PortOne 결제 검증 → Payment 행 잠금 → 상태와 만료 재검증 → Payment를 PAID로 변경 → Reservation과 Participant 생성처럼 실제 요청이 어떻게 흐르는지를 GitHub PR 본문 Markdown으로 먼저 제공한다. 리뷰어가 파일을 하나씩 열어 호출 관계를 직접 조립하기 전에 전체 그림을 먼저 잡을 수 있게 하는 장치다.
둘째, Human 이해도 질문. 설명을 읽었다고 이해한 것이 아니다. 책을 읽으면서 이해하지 못한 부분을 모르고 지나가듯, PR 설명도 읽기만 하고 넘어갈 수 있다. 밥풀은 퀴즈 단계를 별도로 추가하지 않고, 기존 이슈와 PR 단계에 이미 포함된 Human 이해도 질문을 활용한다. "외부 API 호출을 왜 DB 트랜잭션 밖에서 수행했나요?", "Payment 행을 잠근 뒤 상태와 만료를 왜 다시 확인하나요?" 같은 질문들이다. 핵심 개념, 실제 요청·상태·데이터 흐름, 실패·중복·경계 상황 예측을 담당자가 직접 답변해야 Merge로 이어질 수 있다.
셋째, Flow Lab. V1 구현이 끝나면 전체 흐름을 단계별로 실행할 수 있는 인터랙티브 HTML을 만든다. 결제 준비부터 트랜잭션 Commit까지 각 단계에서 Payment 상태, Reservation 상태, 락 상태, 트랜잭션 범위가 어떻게 변하는지 직접 확인할 수 있다. 중요한 것은 정상 흐름만이 아니라 실패와 한계도 보여준다는 점이다. "현재 자동 환불과 재처리는 지원하지 않으며, V2에서 멱등한 환불·재시도·관리자 재처리를 도입할 것"이라고 명시한다. 기능을 자랑하는 데모가 아니라, 현재 구조의 한계와 다음 버전의 설계 방향을 팀이 함께 이해하는 기술 설명 도구다.
'아이디어→프로토타입' 워크플로우에서 병목은 다른 곳에 있다
동일한 문제를 다른 각도에서 보여주는 사례가 있다. velog에 공개된 'InPlan + Claude Code + Unity 프로토타입' 워크플로우 기록이다.
이 팀은 막연한 게임 아이디어를 실제 Unity 프로토타입까지 연결하는 과정에서 흥미로운 발견을 했다. AI가 처음 생성한 기획 문서는 원했던 방향과 달랐다. 만약 그 문서를 그대로 Claude Code에 전달했다면, 원하지 않는 게임을 어느 정도 구현한 뒤에야 문제를 발견했을 것이다. 생성 속도가 빠를수록, 잘못된 방향으로 달려가는 속도도 빠르다.
이 팀이 설계한 해법도 구조적이었다. 구현 전에 기획 문서를 사람이 검토하고, 잘못된 방향을 실제 개발 전에 발견하고 수정하는 단계를 워크플로우에 명시적으로 넣었다. Claude Code는 이 검토가 끝난 문서를 기준으로 구현했다. "이런 게임을 만들어줘"가 아니라 "이 문서에 정의된 범위와 순서에 따라 구현해줘"였다.
두 사례가 가리키는 방향은 같다. AI의 속도를 제한하는 것이 아니라, 인간이 검토하고 이해하는 단계를 워크플로우의 구조 안에 명시적으로 설계하는 것이다.
테크 리드가 설계해야 할 것
지금 AI-First 워크플로우를 운영하고 있다면, 리뷰 병목의 원인을 진단하는 것부터 시작해야 한다. 승인 규칙이나 시간대 같은 운영 문제인지, 아니면 담당 외 코드의 실행 흐름을 이해하는 비용 자체가 문제인지를 구분해야 한다. 대부분의 경우 후자가 더 깊은 원인이다.
실행 관점에서 지금 당장 적용 가능한 것들을 정리하면 이렇다.
- PR 설명을 파일 목록이 아닌 실행 흐름으로 바꾼다. AI에게 Explain Diff를 PR 본문으로 생성하도록 지시하는 것은 오늘 당장 프롬프트 하나로 적용할 수 있다.
- 이해 확인 질문을 PR 템플릿에 넣는다. 담당자가 자신의 구현에 대한 설계 의도 질문에 답변해야 Merge가 가능하도록 PR 템플릿을 구조화한다.
- 구현 전 문서 검토 단계를 명시적으로 만든다. 기획이나 설계 문서를 AI가 생성하더라도, 사람이 검토하고 승인하는 단계를 건너뛰지 않는다.
- 현재 구조의 한계를 팀이 공유하는 장치를 만든다. Flow Lab처럼 정교한 도구가 아니어도 좋다. PR이나 문서에 "현재 제한사항"과 "다음 버전 개선 방향"을 명시하는 것만으로도 팀의 공유 이해를 높일 수 있다.
전망: 이해 속도를 높이는 도구가 다음 경쟁지점이다
Claude가 코드베이스의 80%를 쓰는 팀에서 엔지니어는 "8배 많은 코드를 Merge"한다고 Anthropic의 자체 보고서는 밝힌다. 이 숫자가 팀 전체로 확산될 때, 리뷰어가 소화해야 할 코드의 양도 8배다. 현재의 리뷰 프로세스가 이 속도를 감당할 수 있는지 냉정하게 봐야 한다.
AI 코딩 도구의 다음 경쟁지점은 코드 생성 속도가 아닐 가능성이 높다. 생성된 코드를 인간이 더 빠르게, 더 정확하게 이해하고 검증할 수 있도록 돕는 도구가 진짜 병목을 해소한다. Explain Diff와 Flow Lab은 그 방향의 초기 설계 패턴이다.
속도를 낮추는 게 아니라, 이해를 설계 안으로 가져오는 것. 그게 지금 테크 리드가 해야 할 일이다.