에이전트 요청이 9.4배 증가한 뒤 Uber는 어떻게 AI 비용을 안정화했나

Uber의 에이전트 주간 요청량은 2026년 2월부터 8월 중순까지 9.4배 증가했고, 주간 활성 사용자 수도 7배 증가했다. 그럼에도 전체 AI 지출은 4월부터 비교적 안정적이었다. 핵심은 특정 모델의 가격 인하가 아니라, Uber가 모델 선택, 컨텍스트, MCP 도구 호출, 실행 경로와 비용 피드백을 항목별로 개선한 데 있다. 오히려 지속적으로 운영할 수 있는 비용 엔지니어링 체계에 가깝다.

2026년 8월 27일, Uber Engineering은 Running a Software Factory Efficiently at Uber Scale를 발표하며 이 비용 통제 방법을 집중적으로 소개했다.

이번 회고에는 꽤 무거운 맥락이 있다. Axios는 Uber CTO가 4월 회사가 2026년 예정 AI 예산을 이미 소진했다고 밝혔다고 보도했다. 8월 Uber가 공개한 데이터는 다음과 같았다.

• 에이전트 제품의 주간 활성 사용자 수가 2월 대비 7배 증가
• 주간 에이전트 요청량 9.4배 증가
• 전체 AI 지출이 4월부터 비교적 안정적
• 동일한 모델로 고정해 비교했을 때 1,000회 요청당 비용이 피크 대비 약 34% 감소
• 세션당 비용이 6월 피크 대비 52% 감소

같은 기간 Uber 내부에는 이미 3,600개가 넘는 Agent Skill이 쌓여 있었고, 하루 30,000회 이상의 Skill이 실행됐으며, 전체 PR의 70% 이상이 로컬 또는 클라우드 에이전트에 귀속됐다.

여기서 ‘에이전트에 귀속됐다’는 70%의 코드가 사람의 개입 없이 곧바로 프로덕션에 반영됐다는 뜻은 아니다. Uber의 Managed Agent 설명에도 사람의 리뷰와 예외 에스컬레이션 절차가 남아 있다. 이 기준은 ‘에이전트가 이런 변경에 참여했다’고 말하는 데 더 가깝고, ‘에이전트가 이 변경을 완전히 스스로 처리했다’는 뜻이 아니다.

먼저 에이전트 비용을 분해하자

Uber는 에이전트 총지출을 다음과 같은 여섯 변수에 곱한 값으로 설명한다.

总支出
= 用户数
× 每个用户的会话数
× 每次会话的轮次
× 每轮模型请求数
× 每次请求的 Token 数
× 每 Token 价格

이 공식은 Token 단가만 보는 것보다 에이전트의 실제 비용에 훨씬 가깝다.

일반 대화는 보통 한 턴의 입력에 한 번의 모델 호출로 대응한다. 하지만 에이전트는 작업을 계획하고, 코드를 검색하고, 하위 에이전트를 띄우고, 도구를 호출하고, 작업을 폴링하고, 실패를 처리한 뒤 후속 요청에 기존 컨텍스트를 계속 실어 둔다. 사용자는 요청을 한 번만 했을 뿐, 백그라운드에서는 이미 여러 턴이 실행됐을 수 있다.

Uber는 앞의 두 변수가 계속 증가하기를 원한다. 이 두 변수가 도입률과 사용 깊이를 나타내기 때문이다. 최적화는 에이전트가 작업 완수를 위해 추가로 만들어내는 턴, 요청, 컨텍스트와 작업 유형별 모델 가격에 집중한다.

이 변수들은 서로 곱해지는 관계다. 실행 체인에 적용된 작은 변경이 몇 개 겹쳐 쌓이면 총비용이 눈에 띄게 달라질 수 있다.

Cost per Token에서 Cost per Outcome으로

Uber의 지표는 네 단계로 나뉜다.

Uber는 비용 변동을 사용자 증가, 사용 빈도, 입력 토큰과 출력 토큰으로 나누어, 모든 변화를 ‘요즘 더 많이 쓰고 있다’는 한마디로 설명하지 않는다.

모델의 가성비를 판단할 때 성공한 결과가 Token보다 더 나은 분모다. 가격이 싼 모델이 자주 실패해 재시도를 유발하면 성공한 작업 하나의 총비용이 반드시 더 낮은 것은 아니다. 가격이 더 비싼 모델이 위험도가 높은 작업을 안정적으로 끝낼 수 있다면 오히려 더 이득일 수도 있다.

따라서 Uber는 모델을 선택할 때 공개 가격표만 비교하지 않고 작업 완료 비용, 출력 품질과 신뢰성을 함께 살핀다.

실제 작업 Benchmark로 모델 선택하기

Uber는 Managed Agent에도 동일한 모델 선택 절차를 적용한다.

1. 에이전트의 실제 작업에서 Benchmark를 구성한다.
2. 통합 Harness를 통해 서로 다른 모델에서 같은 작업 묶음을 실행한다.
3. 품질, 신뢰성과 완료된 작업당 비용을 비교한다.
4. Pareto Frontier에 놓인 구성을 선택하고 지속적으로 다시 테스트한다.

코드 리뷰 에이전트 uReview의 평가 세트는 알려진 결함이 있는 실제 PR로 구성되고 난이도별로 분류돼 있다. 지표에는 Precision, Recall, F1, 리뷰 1회당 비용, 지연 시간, 타임아웃률과 잡음이 포함된다. Uber는 모델을 전환한 뒤 F1이 향상됐고, 동시에 PR당 리뷰 비용이 크게 감소했다고 밝혔다.

인터랙티브 에이전트에서는 하위 에이전트의 기본 모델이 비용에 가장 큰 영향을 미치는 설정 중 하나다. 메인 에이전트는 목표를 이해하고 작업을 분해하며 결과를 점검한다. 하위 에이전트는 일반적으로 입력이 명확하고 범위가 작은 작업을 수행한다. 이에 Uber는 기본적으로 하위 에이전트에 능력이 더 낮지만 비용도 더 싼 모델을 쓰고, 사람이 직접 변경할 수 있는 선택지도 유지했다.

구분할 필요가 있는 점은 Uber가 이미 워크로드에 따라 모델을 선택하고 있다는 사실이다. 하지만 더 세밀한 동적 모델 라우팅은 향후 계획으로 분류돼 있을 뿐이다. 즉, 이미 구현된 시스템은 아니다.

큰 컨텍스트라고 해서 창을 가득 채워야 하는 것은 아니다

에이전트 요청마다 대화 이력, 프로젝트 컨텍스트와 도구 결과를 다시 실어 보낸다. 컨텍스트가 클수록 이후 각 턴의 반복 비용이 높아진다.

Uber는 인터랙티브 Harness에 두 가지 기본값을 설정했다.

• 모델이 100만 토큰을 지원하더라도 40만 토큰에서 자동 압축을 트리거한다.
• 기본값은 Medium Reasoning Effort이며, 필요할 때만 높인다.

이 기본값들은 세션에 완충 공간을 남겨 준다. 100만 토큰은 사용할 수 있는 상한일 뿐, 정상적인 작업 범위를 의미하지 않는다.

제 Agent Runtime에서는 최소한 세션 턴 수, 컨텍스트 크기, 도구 호출, 하위 에이전트 수, 재시도, 실행 시간과 작업당 비용을 모니터링하겠다. 임계값을 넘으면 컨텍스트를 압축할지, 성능을 낮출지, 작업을 멈출지, 사람에게 넘길지 결정해야 한다. 즉시 종료하는 것은 낭비한 토큰을 실패한 작업으로 바꾸기만 한다.

Prompt Cache의 TTL은 세션 리듬에 맞춰야 한다

에이전트는 시스템 프롬프트, 프로젝트 설명, 과거 대화와 도구 정의를 반복해서 보낸다. Prompt Cache는 반복되는 접두사의 읽기 비용을 낮출 수 있지만, 캐시 쓰기에는 할증료가 붙기 때문에 TTL을 기본값 그대로 쓰면 안 된다.

Uber는 엔지니어가 단말을 5분 넘게 떠났다가 돌아와 작업을 이어갈 때 캐시가 이미 만료되어 전체 접두사를 다시 구성해야 하는 일이 자주 관찰됐다. 이에 인터랙티브 세션의 TTL을 5분에서 1시간으로 늘렸고, 수명이 짧은 하위 에이전트는 여전히 5분을 유지한다.

Uber 원문은 당시 공급자의 캐시 가격 차이도 명시했다. 캐시 적중 시 읽기 비용은 표준 입력 가격의 약 0.1배, 5분 캐시 쓰기는 약 1.25배, 1시간 캐시 쓰기는 약 2배였다. 이 수치들은 공급자에 따라 달라지지만, 재사용할 수 있는 부분은 의사결정 방식이다. 먼저 인접한 턴 사이의 간격 분포를 확인한 다음 TTL을 정하면 된다.

장시간의 사람-에이전트 상호작용에는 일반적으로 더 긴 캐시가 적합하지만, 짧은 작업과 일괄 처리에서는 더 비싼 장기 쓰기 비용을 치를 가치가 없을 수도 있다.

MCP 비용은 도구 실행 중에만 발생하지 않는다

Uber의 통합 MCP Gateway는 1,000개가 넘는 내부 및 외부 MCP Server를 연결해 인증과 정책을 한곳에서 처리한다.

초기에 마주친 문제는 직접 통합 경로가 대량의 도구 스키마를 세션에 미리 적재한다는 점이었다. Uber가 측정한 결과 100개가 넘는 도구를 설치하면 초기 프롬프트가 약 50K에서 70K Token만큼 증가했다. 그 정의들은 이후 턴마다 컨텍스트를 통해 반복해서 전송됐고, 대부분 도구는 한 번도 호출되지 않았음에도 말이다.

이후 Uber는 두 가지 경로를 채택했다.

• CLI 동적 해석: 모델이 통합 CLI를 호출하면 CLI가 실행 시점에 Gateway를 통해 도구를 찾아 호출하며, MCP 스키마는 모델 컨텍스트에 상주하지 않는다.
• Tool Search: 먼저 도구 카탈로그를 검색해 현재 작업에 필요한 정의만 적재한다.

여기서는 ‘기능을 사용할 수 있다’와 ‘스키마가 상주한다’를 구분해야 한다. MCP는 연결과 호출을 담당하고, Harness, CLI 또는 Gateway가 지금 모델에 어떤 도구를 보여줘야 하는지 결정한다.

이 구조는 Skills Over MCP의 점진적 로딩 방식과도 맞물린다. 모델이 먼저 소량의 메타데이터를 보고, 작업이 매칭된 뒤 전체 설명과 리소스를 적재한다.

결정적인 루프를 모델 컨텍스트 밖으로 옮기다

쿼리 제출, 작업 ID 조회, 상태 폴링, 결과 다운로드와 데이터 필터링 같은 단계는 모델이 매번 새로 생각할 필요가 없다. 모든 단계가 모델 턴을 차지하면 폴링 응답이 계속 컨텍스트에 들어가고, 이후 요청도 그 응답들을 반복해서 실어 보내게 된다.

Uber는 Code Mode를 사용해 모델이 스크립트를 생성하게 하고, 하위 프로세스가 폴링, 일괄 처리와 결과 축소를 수행한 뒤 요약만 모델에 반환한다.

Uber는 동일한 SQL 쿼리 5개에 대해 일반 도구 호출과 Code Mode를 각각 테스트했다.

첫 몇 개 쿼리는 결과가 작았음에도 50%를 넘게 절감했다. 즉, 효과를 얻은 이유는 큰 결과를 덜 전송한 데만 있지 않다. 스키마 초기화, 여러 턴의 폴링과 반복적인 단계별 추론을 제거한 데서도 나온다. 일괄 처리 워크플로에서는 Uber가 90%를 넘게 절감했다.

경계도 복잡하지 않다. 페이지네이션, 폴링, 재시도, 형식 변환과 집계는 일반 코드로 처리하기 좋고, 목표 이해, 이상 징후 판단과 결과 평가는 여전히 모델에 맡긴다.

좋은 컨텍스트도 비용을 낮춘다

대규모 코드베이스에서는 에이전트가 코드를 생성하는 데서가 아니라 정보를 찾는 데 많은 시간을 쓴다. 어떤 서비스를 누가 담당하는지, 데이터 테이블이 어디에서 쓰이는지, 장애가 발생했을 때 이전에는 어떻게 처리했는지와 같은 질문에 신뢰할 수 있는 진입점이 없다면 에이전트는 더 많은 파일을 검색하고, 더 많은 하위 에이전트를 띄우고, 점점 커지는 컨텍스트를 반복해서 전송한다.

Uber의 AI Context Graph에는 약 2,400만 개의 노드와 8,000만 개의 간선이 있으며, 서비스, 팀, 사고, PR, 아키텍처 문서, 배포와 데이터셋을 포함한 30개가 넘는 내부 시스템의 데이터를 통합한다.

Uber는 같은 모델로 같은 질문을 테스트했다.

• Context Graph가 있으면 38초 만에 정답을 얻었다.
• Graph가 없으면 20분 동안 실행되며 하위 에이전트 두 개를 띄우고, 세 번이나 오류를 범한 끝에 잘못된 결론을 냈다.

일반 팀은 수천만 노드의 지식 그래프부터 시작할 필요가 없다. 먼저 저장소 인덱스, 서비스 의존성, 코드 소유자, 데이터 테이블 사용처, Runbook, 아키텍처 결정과 검증 명령을 에이전트가 질의할 수 있는 진입점으로 정리하면 의미 없는 검색을 크게 줄일 수 있다.

비용을 엔지니어 눈앞에 드러내다

Uber는 터미널 상태 표시줄에 실시간 비용 카운터를 넣어 현재 Harness와 사용자의 모든 Harness에 누적된 비용을 표시하고, 예상 비용의 50%, 80%, 100%에 도달하면 알린다. 인터랙티브 Harness는 하나의 비용 등급을 공유하고, Managed Agent는 별도 등급을 사용한다. 한도를 늘리려면 관리자의 승인이 필요하지만, 승인과 설정 전파는 가볍게 유지했다.

월말 청구서는 팀이 비용을 얼마 썼는지 알려줄 뿐, 비용이 어느 단계에서 발생했는지 설명해 주지는 않는다. Uber의 Session Analysis Dashboard는 로컬과 원격 세션의 Trace를 직접 분석해 16가지 비용 역패턴을 식별하고, 비용에 미치는 영향과 그에 맞는 개선책을 제시한다. 예를 들면 다음과 같다.

• 간단한 작업에 지나치게 강력한 모델을 사용함
• MCP가 반환한 큰 데이터 블록이 컨텍스트에 오래 남아 있음
• 세션을 복구할 때 Prompt Cache가 이미 만료됨
• 사용자가 입력하기 전에 지나치게 많은 시스템 지시와 도구 정의가 미리 적재됨

이렇게 비용 관리는 일상적인 개발 프로세스 안으로 들어왔고, 재무제표에만 머물지 않게 됐다.

Managed Agent는 단위 비용을 계산하기 더 쉽다

글 마지막에서 Uber는 더 많은 소프트웨어 개발 작업을 Managed Agent로 옮기는 것을 이후 방향으로 제시했다.

개방형 터미널 세션은 유연하지만, 플랫폼이 작업 입력, 컨텍스트 규모, 모델 선택, 실행 턴 수와 검증 방식을 통제하기는 어렵다. Managed Agent는 목표, 도구, 모델, 완료 조건, 품질 지표와 사람의 에스컬레이션 경로를 미리 정의할 수 있으므로 성공한 결과 하나당 비용을 계산하기도 쉽다.

Uber가 유지하는 것은 각자 독립적인 Benchmark와 모델 전략을 갖춘 전용 에이전트들의 집합이지, 모든 일을 떠안는 단일 에이전트가 아니다. 플랫폼 팀 입장에서는 수천 명의 엔지니어가 단말에서 사용하는 습관을 하나씩 바로잡는 것보다, 이런 안정적인 워크플로를 최적화하는 편이 관리하기 쉽다.

이 방식을 일반 팀에 맞게 축소한다면 다음 순서로 적용하겠다.

1. 먼저 Trace를 기록한다. 작업 유형, 모델, 입력·출력 토큰, 캐시, 도구 호출, 재시도, 지연 시간, 비용과 결과를 남긴다.
2. 다음으로 예산 가드레일을 추가한다. 턴 수, 컨텍스트, 동시 실행 수, 재시도, 시간과 작업당 비용을 제한한다.
3. 그다음 실행 경로를 정리한다. 컨텍스트 압축, 필요한 도구만 적재, 결과 요약과 스크립트 일괄 처리를 적용한다.
4. 마지막으로 실제 작업 Benchmark를 사용해 모델을 선택하고, 성공한 작업당 비용과 품질을 집계한다.

순서가 중요하다. Trace가 없으면 무엇을 최적화해야 할지 알기 어렵고, 결과 지표가 없으면 모델 라우팅도 단순한 가격 비교로 퇴화하기 쉽다.

이 방법의 가치

Uber의 데이터는 자체 코드베이스, 팀 규모와 공급자 구성에서 나온 것이므로, 다른 회사의 절감 약속으로 그대로 적용할 수는 없다. 더 중요한 가치는 에이전트 비용을 API 청구서의 총액에서 측정 가능한 런타임 문제들로 분해한 데 있다.

사용자 수와 작업량은 계속 증가해도 된다. 줄여야 하는 것은 잘못된 검색, 반복되는 컨텍스트, 호출되지 않은 채 유지되는 도구 스키마, 모델을 동원한 폴링, 무의미한 재시도, 그리고 작업 난이도와 맞지 않는 모델 호출이다.

각 비용을 구체적인 세션에, 각 세션을 구체적인 결과에 연결할 수 있어야 비용 관리에 실행 가능한 수단이 생긴다. 모델 능력은 에이전트를 규모화하기 위한 조건 중 하나일 뿐이며, Runtime은 한 작업에 왜 이만큼 비용이 들었는지도 설명할 수 있어야 한다.

참고자료

• Uber Engineering: Running a Software Factory Efficiently at Uber Scale
• Axios: Uber cuts AI costs even as usage jumps
• Agent Runtime 시리즈 (1): Vercel AI SDK, Pi에서 DeepSeek Harness까지