숫자는 매력적이다. 'AI 코드 리뷰로 엔지니어당 하루 30분 절약', '64개 에이전트로 11일 만에 53만 줄 포팅, 비용은 $165K'. 두 숫자 모두 틀리지 않았다. 문제는 이 숫자들이 유통되는 방식이다. 결론만 떼어 공유되는 순간, 숫자 뒤에 있는 설계 비용과 전제 조건이 증발한다. 그리고 팀은 잘못된 기대치를 들고 도구 도입을 시작한다.
세 개의 사례를 같이 해부해보자. 다국적 iOS 팀에 Claude Code를 first-pass 리뷰어로 투입한 워크플로우 리포트, GitHub Actions 기반 웹훅 아키텍처로 구현한 무료 PR 리뷰어, 그리고 Anthropic이 Bun 런타임 전체를 64개 Claude 에이전트로 Rust로 포팅한 사례. 세 사례 모두 '성공 사례'지만, 읽는 방식에 따라 전혀 다른 교훈을 준다.
하루 30분 절약—이 숫자를 어떻게 읽어야 하나
dev.to에 공개된 iOS 팀 사례부터 보자. 저자는 Claude Code를 모든 PR의 first-pass 리뷰어로 투입했다. 핵심 설계는 단일 에이전트가 아니라 차원별 멀티 에이전트 팬아웃이다. 정확성(엣지 케이스, nil 핸들링, 동시성), 일관성(네이밍, 에러 핸들링 관습), 테스트 커버리지, i18n·접근성—각 차원에 별도 에이전트를 배치한다. 각 에이전트는 파일과 라인을 인용하고 구체적인 실패 시나리오를 제시해야만 한다. 실패 시나리오 없는 지적은 드롭된다.
이 규칙 하나가 'AI 코드 리뷰'와 '쓸모없는 AI 코드 리뷰'를 가른다. '가독성 개선을 고려하세요' 같은 노이즈가 사라진다. 저자가 측정한 결과는 몇 달간의 일상 사용 기준으로 엔지니어당 하루 약 30분 절약, 리뷰 사이클 타임 단축, 그리고 인간 리뷰 품질은 유지됐다. 마지막 지표가 중요하다. 기계적 검증을 에이전트에 넘겼는데 인간 리뷰어의 판단 기준이 떨어지지 않았다—이것이 이 워크플로우가 실제로 작동했다는 증거다.
하지만 저자 본인이 가장 후회한다고 밝힌 게 있다. 에이전트 리뷰 통과 시 자동 머지를 먼저 배포한 것이다. 에이전트는 '테스트 통과'라는 근접 지표를 최적화했고, '이 변경이 올바르고 머지할 가치가 있는가'라는 실제 목표는 미스했다. 자동 머지는 철회됐다. 에이전트는 조언하고, 인간이 결정한다. 그리고 또 하나: 배포 전에 기준 지표를 합의하지 않았다. 30분 절약이라는 숫자는 사후에 재구성했다. 저자는 "다시 한다면 첫 번째 에이전트가 돌기 전에, 무엇을 측정하고 어떻게 측정할지 합의하는 것이 스텝 제로였을 것"이라고 명시한다.
'비용 제로' 아키텍처—공짜의 실제 범위
두 번째 사례는 다른 각도에서 같은 문제를 다룬다. GitHub Actions와 FastAPI로 구성한 웹훅 기반 PR 리뷰어—무료 티어 모델을 써서 API 비용 없이 돌린다는 것이 핵심이다. 아키텍처는 단순하다. PR 오픈·푸시 이벤트 → GitHub Actions → diff 추출 → FastAPI 서비스 → 프리 티어 LLM → JSON 파싱 → PR 코멘트 게시. 60줄짜리 서비스 코드가 전부다.
이 사례에서 진짜 작업량은 프롬프트 엔지니어링에 있었다. 초안 1: "이 diff를 리뷰해줘." 결과는 어느 코드에나 통하는 일반적인 조언 단락. 초안 2: 카테고리를 추가했다. 모델이 카테고리를 뒤섞고 존재하지 않는 라인 번호를 만들어냈다. 최종본에서 세 가지를 더했다—명시적 JSON 출력 스키마, 구체적인 카테고리 정의('데이터 손실, 레이스 컨디션'), diff 하드캡(8,000자). 이것이 할루시네이션된 라인 번호를 약 80% 줄였다. 프리 티어 모델은 의도보다 구조를 더 잘 따른다—스키마를 주면 채우고, '꼼꼼하게 해줘'라고 하면 엉뚱한 것에 꼼꼼해진다.
그러나 이 아키텍처가 솔직하게 인정하는 한계가 있다. 경고의 약 30%는 오탐이다. 대형 diff는 컨텍스트 윈도우를 넘겨 앞부분만 리뷰된다. 서버가 콜드 스타트 상태면 액션이 타임아웃된다. 그리고 가장 중요한 경고—규제 대상 코드베이스(PHI, PII, 금융 데이터)에는 쓰지 마라. 코드가 경계 밖으로 나간다. '비용 제로'는 인프라 비용의 이야기고, 설계 비용·보안 경계·오탐 처리 비용은 별도다.
$165K 포팅—숫자의 바닥과 천장
세 번째 사례가 가장 극단적이고, 그래서 가장 많이 오독된다. 2025년 12월 Anthropic이 Bun을 인수했고, 2026년 5월 Jarred Sumner가 64개 Claude 에이전트를 동원해 53만 5,000줄의 Zig 코드베이스를 11일 만에 Rust로 포팅했다. 사전 머지 토큰 비용을 API 가격 기준으로 환산하면 약 $165K.
이 숫자에는 세 개의 수정이 필요하다. 첫째, $165K는 바닥이다. 머지 이후 6주 시점에서 독립 분석가 Tom Lockwood가 저장소를 분석했을 때, 'robobun'(Claude Code의 커밋 아이덴티티)의 오픈 PR은 1,277개에서 2,475개로 증가했고, Buildkite CI는 계속 돌고 있었으며, Anthropic 직원들은 여전히 수정을 작성 중이었다. 하루 약 $10K 소비가 지속된다면 총액은 $800K에 근접한다. Sumner는 머지 전 토큰 비용만 이야기했다. 누가 이것을 '$165K짜리 런타임 재작성'이라고 부를 때, 그는 바닥을 전체인 것처럼 인용하는 것이다.
둘째, 이 비용은 재현 불가능한 조건의 산물이다. Sumner가 사용한 모델은 당시 공개 API로 살 수 없었던 Claude Fable 5 사전 출시 버전이었다. 2026년 5월 기준으로 외부 팀이 공개 API 모델로 같은 결과를 같은 비용에 낼 수 없었다.
셋째, 11일은 무인 자동화가 아니었다. Sumner는 포팅 시작 전 약 3시간을 Claude와 함께 PORTING.md(Zig 패턴 → Rust 패턴 매핑 가이드)와 LIFETIMES.tsv(코드베이스 전체 struct 필드의 메모리 라이프타임 분석) 작성에 썼다. 먼저 3개 파일을 시험 포팅했다. 모든 구현 에이전트 결과물은 별도 컨텍스트 창에서 동작하는 2개의 적대적 리뷰어 에이전트가 검토했다—diff만 보고 코드가 틀렸다고 가정하고 시작하는 에이전트들이다. 병렬 실행 초기에 에이전트들이 서로 git stash와 git reset --hard를 덮어써서 실행이 붕괴됐고, 에이전트별 파일 전용 커밋과 워크트리 샤딩으로 해결했다. Sumner는 11일 내내 루프를 지켜보며 수동으로 개입했다. 이것은 '프롬프트하고 기다린' 11일이 아니라 세계 최고의 코드베이스 전문가가 풀타임으로 감독한 11일이었다.
세 숫자가 공통으로 말하는 것
세 사례를 나란히 놓으면 패턴이 보인다. AI 코드 리뷰 ROI를 실제로 만든 것은 모델 성능이 아니라 세 가지 설계 결정이었다.
1. 찾기 기준을 사전에 정의했다. iOS 팀 사례는 '실패 시나리오 없는 지적은 드롭'이라는 단일 규칙으로 노이즈를 걸렀다. 웹훅 아키텍처는 JSON 스키마와 카테고리 정의로 할루시네이션을 80% 줄였다. Bun 포팅은 PORTING.md와 LIFETIMES.tsv를 코드 한 줄 쓰기 전에 먼저 만들었다.
2. 적대적 검증을 파이프라인에 내장했다. iOS 팀은 에이전트 리뷰를 인간 리뷰 앞에 배치했지만 머지 버튼은 인간이 쥐었다. Bun 포팅은 구현 에이전트마다 2개의 적대적 리뷰어 에이전트를 배치했다. 통과가 완료가 아니다—검증 구조가 별도로 존재해야 한다.
3. 측정 지표를 먼저 정했다. iOS 팀 저자가 가장 후회하는 실수가 이것이다. 30분 절약 숫자를 사후에 재구성했다. Bun의 $165K도 머지 이후 비용을 포함하지 않아 바닥 숫자가 됐다. AI 워크플로우를 켜기 전에 무엇을 측정하고 어떻게 측정할지 합의하는 것—이게 스텝 제로다.
그리고 세 사례 모두가 건드리지 않은 영역이 있다. Bun 포팅 결과물에는 unsafe 블록이 약 13,000개 존재한다. 비교 대상인 손으로 작성한 Rust 프로젝트가 평균 73개인 것에 비하면 180배 수준이다. 테스트 통과는 달성했다. 메모리 안전성 보장은 인간이 지금도 머지 이후에 검증 중이다. AI가 기능적 정확성을 빠르게 달성하는 동안, 구조적 품질 부채는 조용히 쌓인다. 이것이 세 숫자가 말하지 않는 것이다.
팀에 AI 코드 리뷰를 도입하려는 시점에서 물어야 할 질문은 '얼마나 절약되나요?'가 아니다. '우리 팀은 찾기 기준을 사전에 정의할 수 있나?', '검증 구조가 생성 파이프라인 안에 있나?', '배포 전에 측정 지표를 합의했나?'다. 이 세 질문에 답이 없는 상태에서 도입하면, 인상적인 숫자는 만들어지겠지만 그 숫자가 무엇을 측정한 건지 아무도 모르게 된다.