Uber는 4개월 만에 AI 코딩 예산을 모두 소진했습니다. 대신 똑똑한 팀들은 무엇을 할까요?

AI 코딩 비용이 이제 모두의 문제가 되었습니다. 지난 2주 동안에만 다음과 같은 일이 발생했습니다:

• Uber는 2026년 Claude Code 예산을 4월까지 모두 소진하여 직원당 월 $1,500로 한도를 설정했습니다.
• Gartner는 기술 리더의 23%가 현재 AI 코딩 토큰(tokens) 비용으로만 개발자 1인당 월 $200~$500를 지출하고 있다고 보고했습니다.
• GitHub는 Copilot을 사용량 기반 과금(usage-based billing) 방식으로 전환하여, 예측 가능했던 좌석당 $19의 비용을 무제한적인 크레딧 소모로 바꾸어 놓았습니다.
• **Ramp의 AI 인덱스(AI Index)**에 따르면 상위 1% 기업은 직원 1인당 월 $7,500를 AI에 지출하고 있으며, 이는 1인당 연간 $90,000에 달하며 한 달 만에 14.1% 증가한 수치입니다.

패턴은 명확합니다. 에이전트 워크플로우(agentic workflows)는 그 어떤 고정 예산이 예상했던 것보다 더 빠르게 토큰을 소모합니다. 그리고 단일 벤더 종속(single-vendor lock-in)은 상황을 더 악화시킵니다. 출력 토큰 100만 개당 $75인 Opus 4.8이 유일한 옵션일 때, 낭비되는 모든 사고 루프(thinking loop)는 매우 값비쌉니다.

진짜 문제: 모든 작업에 최고의 모델이 필요한 것은 아니다

올해 초 저의 AI 코딩 지출이 월 $10,000에 도달하는 것을 지켜보며 배운 점은 다음과 같습니다.

저는 _모든 것_을 Claude Opus로 보내고 있었습니다. 코드 계획(Code planning)? Opus. 단위 테스트(unit tests) 작성? Opus. 설정 파일(config file) 포맷팅? Opus. 세 개의 파일에 걸친 변수 이름 변경? Opus.

이것은 가구를 옮기기 위해 수석 건축가를 고용하는 것과 같습니다. 작업은 완료되지만, 엄청난 과잉 지불을 하고 있는 것입니다.

실제로 사용량을 프로파일링(profile)했을 때, 내역은 다음과 같았습니다:

• **작업의 약 15%**는 진정으로 최첨단 추론(frontier reasoning) 능력이 필요했습니다 (복잡한 아키텍처 결정, 미묘한 버그 진단, 까다로운 의존성이 포함된 다중 파일 리팩토링).
• **작업의 약 25%**는 탄탄한 중간 단계(mid-tier) 역량이 필요했습니다 (명확한 사양에 따른 기능 구현, 의미 있는 테스트 작성, 코드 리뷰).
• **작업의 약 60%**는 기계적인 작업이었습니다 (포맷팅, 이름 변경, 보일러플레이트(boilerplate) 생성, 단순 파일 작업, 문서 업데이트).

그 60%의 작업은 Haiku, Gemini Flash, 또는 심지어 로컬 모델(local model)이 동일하게 처리할 수 있는 일임에도 불구하고 최첨단 급(frontier-tier) 토큰을 태우고 있었습니다.

작업 수준 라우팅(Task-Level Routing): 60-70%를 절약하는 지루하지만 확실한 해결책

개념은 간단합니다. 모든 요청을 하나의 모델로 라우팅(Routing)하는 대신, 각 작업을 분류하여 이를 잘 처리할 수 있는 가장 저렴한 모델로 보내는 것입니다.

기획 단계 (Planning phase) → 프론티어 모델 (Frontier model) (Opus, GPT-5). 이 단계는 추론의 깊이(Reasoning depth)가 중요합니다. 명세서에서 놓친 예외 케이스(Edge cases)를 잡아낼 수 있는 모델이 필요합니다.

구현 (Implementation) → 미드 티어 모델 (Mid-tier model) (Sonnet, GPT-4.1). 명확한 계획이 주어지면, 대부분의 코드 생성은 최대치의 지능을 필요로 하지 않습니다. 대신 신뢰할 수 있는 지시 이행(Instruction-following) 능력이 필요합니다.

테스트, 포맷팅, 문서화 (Tests, formatting, docs) → 빠르고 저렴한 모델 (Fast/cheap model) (Haiku, Flash, Gemini 2.5). 이러한 작업들은 객관적으로 검증 가능한 출력을 가집니다. 테스트가 통과하거나 통과하지 않거나 둘 중 하나입니다. assertEqual을 수행하는 데 IQ 200의 지능은 필요하지 않습니다.

디버그/진단 (Debug/diagnosis) → 다시 프론티어 모델. 명확하지 않은 방식으로 무언가 고장 났을 때는 사용 가능한 최고의 추론 능력이 필요합니다.

이 접근 방식을 구현한 후, 저의 월간 지출은 약 $10,000에서 약 $3,000로 감소했습니다. 출력 품질은 동일합니다. 작업 속도(Velocity)도 동일합니다. 단지 일상적인 작업에 과도한 비용을 지불하는 것을 멈췄을 뿐입니다.

실제로 이를 수행하는 방법

맞춤형 인프라가 필요하지는 않습니다. 실용적인 버전은 다음과 같습니다:

1. 토큰 사용량 감사 (Audit Your Token Usage)

최적화하기 전에 토큰이 어디로 가는지 파악해야 합니다. 일주일 동안 API에 전달되는 실제 프롬프트(Prompt)를 기록해 보세요. 아마 다음과 같은 현상을 발견하게 될 것입니다:

• 컨텍스트 팽창 (Context bloat) (프레임워크가 모든 호출에 전체 상태를 직렬화하여 포함하는 경우)
• 불필요한 사고 루프 (Unnecessary thinking loops) (모델이 사소한 작업에 대해 "추론"하는 경우)
• 호출당 10K 이상의 토큰을 잡아먹는 반복적인 시스템 프롬프트 (System prompts)

2. 작업 카테고리 생성

단순하게 시작하세요. 3단계면 충분합니다:

• Tier 1 (Frontier): 아키텍처, 복잡한 디버깅, 보안 민감 코드
• Tier 2 (Mid): 기능 구현, 테스트 작성, 코드 리뷰
• Tier 3 (Fast): 포맷팅, 문서화, 보일러플레이트 (Boilerplate), 간단한 수정

3. 세션이 아닌 작업에 기반하여 라우팅 (Route Based on the Task, Not the Session)

핵심 통찰: 라우팅(routing)은 세션(session) 단위가 아닌 작업(task) 단위로 이루어져야 합니다. 단일 코딩 세션 내에서도 초기 설계에는 Opus가, 구현에는 Sonnet이, 테스트 코드 작성에는 Haiku가 필요할 수 있으며, 이 모든 과정은 동일한 워크플로(workflow) 내에서 발생합니다.

제가 대화해 본 대부분의 팀은 처음에는 수동 라우팅(직접 모델을 전환하는 방식)으로 시작하여, 패턴이 파악되면 이를 자동화합니다.

4. 모니터링 및 조정 (Monitor and Adjust)

단순히 총 지출액만 보지 말고, 작업당 비용(cost-per-task)을 추적하세요. Tier 3 수준의 작업에 프런티어 모델(frontier model) 토큰 비용이 2달러나 소모되고 있다면, 그것은 라우팅 실패입니다. 반대로 Tier 1 수준의 작업이 저렴한 모델에서 실패한다면, 이 또한 라우팅 실패입니다. 최적의 지점(sweet spot)은 그 중간에 있습니다.

더 큰 그림 (The Bigger Picture)

Ramp의 데이터는 흥미로운 사실을 말해줍니다. AI에 가장 많은 돈을 쓰고 있는 기업들은 위기에 처한 기업들이 아닙니다. 진짜 위기에 처한 기업들은 라우팅 능력이 없는 상태로 단일 벤더(vendor)에 종속된 기업들입니다.

"상위 1%의 기업들은 여러 프런티어 모델과 더 저렴한 모델에 접근할 수 있는 플랫폼들을 섞어서 사용(mix and match)하는 경향이 있습니다." — Ramp AI Index

이는 AI에 돈을 적게 쓰는 것에 관한 문제가 아닙니다. 더 똑똑하게 쓰는 것에 관한 문제입니다. 에이전틱 워크플로(agentic workflows)가 기본값이 되어감에 따라, 지금 작업 단위의 라우팅을 파악하는 팀들은 구조적인 비용 우위를 점하게 될 것입니다.

월 1만 달러 규모의 개발자 AI 비용 시대는 이미 도래했습니다. 문제는 당신이 그 비용을 내고 있는 이유가 정말 필요해서인지, 아니면 어떤 작업에 실제로 비싼 모델이 필요한지 확인하는 수고조차 하지 않았기 때문인지입니다.

저는 지난 1년 동안 AI 코딩 도구로 앱을 구축하며 경제성을 집요하게 추적해 왔습니다. 구체적인 수치를 공유하거나 댓글을 통해 라우팅 전략에 대해 논의하는 것은 언제든 환영입니다.