Uber가 Claude Code에 2026년 AI 예산 전체를 4개월 만에 태웠다. Uber CTO는 엔지니어 1인당 월 500~2,000달러의 API 비용이 발생했고, 결국 예산 편성을 'back to the drawing board'로 되돌렸다고 밝혔다. 커밋된 코드의 70%가 AI에서 나왔고, 엔지니어의 95%가 매월 AI 도구를 쓰고 있다는 수치도 함께 공개됐다. 숫자만 보면 성공적인 AI 도입처럼 보인다. 문제는 그 비용을 누가, 어떻게 통제할지 아무도 설계하지 않았다는 점이다.
이 사례를 단순히 '예산 초과' 실패담으로 읽으면 핵심을 놓친다. Uber의 연간 R&D 지출은 34억 달러다. HN 커뮤니티의 추산대로라면 AI 코딩 도구 비용은 연환산 기준 R&D 전체의 약 1% 수준이다. 절대액으로는 작지 않지만, 규모 대비 감당 불가능한 수준도 아니다. 진짜 문제는 다른 데 있다. 채택 곡선을 예측하지 못한 채 예산이 먼저 확정됐다는 것이다. Claude Code가 2025년 12월 배포된 이후 2026년 2월까지 사용량이 두 배로 늘었고, 4월에 연간 예산이 소진됐다. 지수적으로 성장하는 사용량에 선형적인 예산을 붙인 결과다.
비용이 폭발하는 구조적 원인은 세 가지로 나눌 수 있다. 첫째, 인센티브 미스얼라인먼트다. 회사가 비용을 부담하면 엔지니어는 가장 강력한 모델을 가장 높은 thinking 설정으로 쓴다. 단일 프롬프트에 40달러가 나와도 멈출 이유가 없다. 결과물로 평가받지, 토큰 비용으로 평가받지 않기 때문이다. 둘째, 맥락 창 낭비다. 초급자는 긴 대화를 계속 끌고 가고, 중급자는 하위 에이전트를 병렬로 띄우는 패턴에 중독된다. 500MB짜리 Jupyter 노트북을 Claude가 반복해서 읽게 한 사례처럼, 작업 구조 설계 없이 에이전트를 돌리면 토큰이 기하급수적으로 쌓인다. 셋째, KPI 게임화다. AI 사용이 성과 평가에 반영되면 사람들은 숫자를 맞추기 위해 쓴다. 의미 있는 생산성이 아니라 측정 가능한 AI 사용량을 최적화하기 시작한다.
이 지점에서 Spec-Driven Development(dev.to의 Jeff Reese 아티클)가 비용 통제 구조와 직접 연결된다. Karpathy가 말한 것처럼 "People have to be in charge of this spec"—에이전트에게 일을 맡기기 전에 사람이 먼저 구조를 설계해야 한다. Spec 없이 프롬프트만으로 에이전트를 돌리면 어떤 일이 벌어지는가. 에이전트는 맥락을 잃을 때마다 가정을 만들고, 가정이 쌓일수록 수정 루프가 길어지고, 수정 루프가 길어질수록 토큰이 낭비된다. 스펙이 있으면 에이전트는 질문 대신 실행한다. 수정 대신 정렬한다. 같은 결과물을 더 적은 토큰으로 만든다.
Spec-Driven Development의 4개 레이어를 비용 통제 관점에서 다시 읽으면 의미가 달라진다. Layer 1(스펙)은 에이전트의 추측 비용을 제거한다. Layer 2(워크플로우)는 스펙을 살아있는 컨텍스트로 만들어 세션마다 중복 입력을 줄인다. Layer 3(CLAUDE.md 행동 설정)은 토큰을 낭비하는 잘못된 방향을 사전에 차단한다. Layer 4(훅 기반 기계적 강제)는 규칙이 제안에 머무르지 않고 실제로 실행을 막는다. "모든 규칙이 모든 API 호출에서 토큰을 소비한다"는 통찰도 중요하다. 필요 없는 규칙을 사전에 잔뜩 박아두는 것 자체가 비용이다.
Claude Code 실무 자동화 사례(velog의 kbk456 아티클)는 비용 효율적인 AI 활용이 어떤 모습인지 구체적으로 보여준다. 업무보고 자동화, CloudWatch 로그 1차 필터링, Playwright 기반 QA 검증—세 작업의 공통점은 '에이전트가 명확하게 판정할 수 있는 신호를 사람이 먼저 설계했다'는 것이다. 특히 LMS 화면 QA에서 OCR 방식 대신 DOM 요소 존재 여부나 HTTP 상태 코드 같은 기계적 기준으로 전환한 결정이 핵심이다. AI가 잘 못 보는 영역을 억지로 맡기지 않고, AI가 명확히 판정 가능한 구조를 먼저 설계한 것이다. 이 원칙을 따르면 같은 작업에서 토큰 낭비가 줄고, 재시도 루프가 짧아지고, 결과 신뢰도가 높아진다.
그렇다면 팀은 무엇을 설계해야 하는가. Uber 사례에서 빠진 것을 역으로 추적하면 답이 나온다.
첫째, 예산을 사용량이 아니라 성과에 연동하라. 월 지출 상한을 개인별로 설정하고, 초과분은 정당화 프로세스를 거치게 한다. AWS 비용 알람을 당연하게 설정하듯, AI API 비용도 동일한 관찰성 레이어를 붙여야 한다.
둘째, 토큰 비용이 아니라 작업 구조를 심사하라. 월 10,000달러를 쓰는 엔지니어가 있다면 금액이 아니라 작업 패턴을 들여다봐야 한다. 거대한 단일 대화를 끌고 가는가, 병렬 에이전트를 구조 없이 띄우는가, 스펙 없이 수정 루프를 반복하는가. 이 패턴들이 비용의 원인이다.
셋째, Spec-Driven 워크플로우를 팀 표준으로 만들어라. 개인이 알아서 잘 쓰기를 기대하는 것은 비용 통제가 아니다. 스펙 생성 → 행동 설정 → 훅 강제의 4개 레이어를 팀 레벨에서 템플릿화하고, 온보딩에서부터 이 구조로 시작하게 해야 한다.
HN 커뮤니티의 한 댓글이 핵심을 찌른다. "이게 AWS였다면 모두가 '월 지출 안 봤냐'고 손가락질했을 것이다." 동의한다. AI API 비용은 인프라 비용이다. 인프라 비용을 통제하는 방식으로 관리해야 한다. 그런데 대부분의 팀은 아직 이를 '개발 도구 구독료' 수준으로 인식하고 있다. 그 인식의 차이가 Uber 같은 예산 폭발을 만든다.
AI 도구의 가치 자체는 의심하지 않는다. 채택을 막으면 경쟁에서 뒤처진다. 하지만 구조 없이 열어주면 예산이 먼저 바닥난다. 비용 통제와 생산성 극대화는 상충하지 않는다. 스펙 주도 워크플로우가 두 목표를 동시에 달성하는 구조다. 에이전트는 더 빠르게 움직이고, 팀은 더 적은 토큰으로 더 나은 결과를 얻는다. 지금 팀에게 필요한 것은 더 좋은 AI 도구가 아니라, 지금 가진 도구를 구조적으로 쓰는 설계다.