Uber가 2026년 Claude Code 예산을 4월에 소진했다. 남은 8개월을 버티기 위해 직원 1인당 월 $1,500 한도를 씌웠다. 이게 남의 이야기처럼 들린다면, Gartner 데이터를 한 번 더 보자. 테크 리더의 23%가 이미 개발자 1인당 월 $200~500을 AI 코딩 토큰에만 쓰고 있다. GitHub Copilot은 정액제에서 사용량 기반 과금으로 전환했고, Ramp AI Index는 상위 1% 기업의 AI 지출이 직원 1인당 연 $90K에 달한다고 집계했다. 에이전틱 워크플로우는 예상보다 훨씬 빠르게 토큰을 태운다. 문제는 예산이 아니라 구조다.
왜 비용이 폭증하는가: 단일 모델 의존의 함정
dev.to의 한 기고에서 저자는 자신의 월 AI 지출이 $10K에 달했을 때를 회고하며 이렇게 정리했다. "나는 모든 것을 Claude Opus로 보냈다. 설정 파일 포맷팅도, 변수 이름 변경도, 단위 테스트 작성도." 실제로 작업을 분석해보니 프론티어 모델이 정말 필요한 작업은 전체의 15%에 불과했다. 아키텍처 결정, 비선형 버그 진단, 복잡한 다중 파일 리팩터링이 여기에 속한다. 나머지 25%는 중간 티어, 60%는 저가 모델로 충분히 처리 가능한 기계적 작업이었다. 그 60%에 프론티어 토큰을 쏟아붓는 것, 이것이 비용 폭증의 실제 원인이다.
태스크 레벨 라우팅: 지루하지만 효과 있는 유일한 해법
해법은 개념적으로 단순하다. 작업 유형에 따라 모델을 다르게 배정하는 것이다. 기획·설계 단계에는 프론티어 모델(Opus, GPT-5), 명세가 명확한 구현 단계에는 중간 티어(Sonnet, GPT-4.1), 테스트 작성·문서화·포맷팅에는 저가 고속 모델(Haiku, Gemini Flash)을 쓴다. 디버깅은 다시 프론티어로 올린다. 이 라우팅을 실제 적용한 결과 월 지출이 $10K에서 $3K로 줄었다. 산출물 품질과 개발 속도는 그대로였다. 핵심은 세션 단위가 아니라 태스크 단위로 라우팅 결정을 내리는 것이다. 하나의 세션 안에서도 설계는 Opus, 구현은 Sonnet, 테스트는 Haiku가 처리할 수 있다. 다중 벤더를 혼용하는 팀이 단일 벤더에 고착된 팀보다 구조적 비용 우위를 가져가는 이유가 여기에 있다.
비용만이 문제가 아니다: 에이전트가 만드는 의존성 부채
비용 최적화에 집중하다 보면 놓치기 쉬운 리스크가 있다. 에이전트가 조용히 쌓아가는 기술 부채다. Claude Code, Cursor, Copilot에게 의존성 추가를 요청하면 에이전트는 즉시, 자신 있게 패키지를 골라 코드베이스에 삽입한다. 문제는 그 자신감이 훈련 데이터 기억에서 나온다는 것이다. 에이전트는 세 가지를 모른다. 팀 내부에 이미 감사된 라이브러리가 있다는 사실, 방금 선택한 패키지가 6개월 전에 유지보수가 중단됐다는 사실, 지난주에 공급망 취약점 경보가 발령됐다는 사실. USENIX Security 2025 연구(Spracklen et al.)에 따르면 LLM이 생성 코드에서 명명하는 패키지의 19.7%는 존재하지 않는다. Veracode의 2025년 리뷰는 AI 생성 코드의 약 45%가 알려진 보안 취약점을 포함한다고 분석했다. 더 심각한 것은 잘못된 선택이 코드베이스에 기록되는 순간 그 위에 계속 빌드가 올라간다는 점이다. 부채는 이자가 붙는다.
컨텍스트가 결정을 바꾼다: 도구보다 정보 공급 구조
의존성 부채의 근본 원인은 프롬프트가 나빠서가 아니다. 에이전트가 결정을 내리는 시점에 사실 기반 정보가 없기 때문이다. 패키지 선택 실험에서 내부 라이브러리 존재 여부를 단순 정보로 제공했을 때("사용해야 한다"는 지시 없이), 에이전트는 자체 판단으로 핸드롤 구현 대신 내부 패키지를 선택했다. 공급망 취약점 사례에서도 훈련 컷오프 이후 발생한 posthog-node 악성 버전 정보를 주입하자 에이전트의 행동이 바뀌었다. 이는 도구 문제가 아니라 정보 공급 시점과 구조의 문제다.
컨텍스트 비용도 설계 대상이다: grep vs 그래프 실측
936번의 실험 결과(apache/superset 대상, Claude Code 4개 컨텍스트 공급 방식 비교)는 또 다른 설계 변수를 드러낸다. 단순 위치 조회 작업에서는 grep과 구조적 코드 그래프의 정확도 차이가 없었다. 그러나 "이 메서드 시그니처를 바꾸면 어디가 깨지나"처럼 영향 범위를 추적하는 복잡한 작업에서는 결과가 극명하게 갈렸다. grep은 정확도 0.71, 완료율 83%, 비용은 구조적 도구 대비 6~24배. 구조적 그래프 방식은 높은 정확도를 유지하면서 비용을 통제했다. 핵심 시사점은 단순하다. 어떤 작업을 에이전트에게 맡기느냐에 따라 컨텍스트 공급 도구가 달라져야 하고, 이 선택 자체가 비용 구조에 직접 영향을 미친다.
테크 리드가 지금 당장 설계해야 할 세 가지
이 세 가지 데이터 포인트가 함께 가리키는 것은 하나다. 에이전트 도입 속도보다 구조 설계가 먼저여야 한다는 것. 구체적으로 세 가지를 먼저 설계하라.
첫째, 태스크 레벨 라우팅 정책. 프론티어·중간·저가 모델의 역할 경계를 팀 차원에서 명시적으로 정의한다. 처음에는 수동으로 운영하고, 패턴이 보이면 자동화한다.
둘째, 의존성 검증 게이트. 에이전트가 패키지를 선택하는 시점에 라이선스, 유지보수 상태, 최신 취약점 정보를 주입하는 구조를 만든다. 이것은 보안 문제이기 이전에 기술 부채 통제 문제다.
셋째, 컨텍스트 공급 도구 선택 기준. 단순 조회 작업과 영향 범위 분석 작업에 동일한 컨텍스트 도구를 쓰는 것은 비효율이다. 작업 복잡도에 따라 grep과 구조적 그래프를 구분해 쓰는 정책을 사전에 설정한다.
에이전트는 빠르다. 그래서 구조가 없으면 더 빠르게 망가진다.
Uber 사례는 예산 실패가 아니다. 구조 설계 없이 에이전트를 켰을 때 어떤 일이 벌어지는지를 보여주는 사례다. 에이전트는 당신이 설계하지 않은 방향으로도 열심히 달린다. 토큰을 태우고, 검증되지 않은 패키지를 심고, 불필요하게 비싼 컨텍스트를 소비하면서. AI-First 팀 리빌딩에서 속도는 목표가 아니라 결과다. 라우팅, 검증, 컨텍스트 설계—이 세 구조를 먼저 세운 팀이 에이전트의 속도를 실제 생산성으로 전환할 수 있다.