Running a Software Factory Efficiently at Uber Scale

3줄 요약

1. 우버의 우다이 키란 메디세티(Distinguished Engineer)가 2026년 8월 27일 사내 “소프트웨어 팩토리"의 비용 운영 방식을 공개했다. 풀 리퀘스트의 70% 이상이 로컬 또는 클라우드 에이전트에서 나오고, 사내에 만들어진 에이전트 스킬은 3,600개를 넘으며 하루 3만 건 이상 실행된다.
2. 지출을 사용자 수 × 사용자당 세션 × 세션당 턴 × 턴당 요청 × 요청당 토큰 × 토큰당 단가의 곱으로 분해하고, 앞의 두 항은 키우고 가운데 세 항만 깎았다. 2월부터 8월까지 주간 활성 사용자는 7배, 주간 에이전트 요청은 9.4배 늘었는데 총지출은 4월 이후 거의 평평하다.
3. 모델을 고정해 자체 최적화 효과만 떼어 보면 요청 1,000건당 비용은 정점 대비 약 34%, 세션당 비용은 6월 정점 대비 52% 내려갔다.

지금 우버에서 벌어지는 일

AI 도구가 소프트웨어 개발 전 단계에 들어가 있다. 숫자로는 이렇다.

주목할 대목은 세션을 여는 주체가 바뀌고 있다는 것이다. 사람이 시작하지 않은 세션의 비중이 계속 커지고 있고, 그 자리를 관리형 에이전트(managed agent)가 채운다. 코드 리뷰, CI 실패 자가 복구, 시각 검증까지 포함한 종단 간 풀 리퀘스트 작성, 온콜 알림 분류, 들어온 버그 디버깅, 각종 코드 유지보수를 에이전트가 맡고 사람은 리뷰와 에스컬레이션에서만 개입한다.

사용량이 7배로 뛰는 동안 총지출은 4월 이후 안정됐다. 그러나 이 그래프만으로는 최적화 성과를 읽을 수 없다. 채택률, 작업 구성, 모델 업그레이드가 동시에 움직이기 때문이다. 그래서 우버는 모델 하나를 고정한 채 2월부터 7월까지를 다시 쟀다.

요청 1,000건당 비용은 정점에서 거의 34% 내려갔고, 세션당 비용은 6월 정점 대비 52% 내려갔다. 세션당 비용 데이터는 5월 말부터 집계됐다.

여섯 항의 곱으로 쓴 비용

우버는 AI 사용을 네 개 층으로 나눈다. 가장 특화된 층에서 가장 범용적인 층까지이고, 위층으로 갈수록 비용과 품질, 모델 선택에 대한 통제력이 커진다. 어느 층에서 돌아가는 세션이든 비용은 다음처럼 분해된다.

여섯 항 각각을 따로 재고 따로 최적화한다. 여기서 중요한 구분이 나온다.

• 앞의 두 항 (사용자 수, 사용자당 세션 수)은 채택과 참여를 뜻한다. 사람이 직접 쓰든 에이전트가 대신 처리하든, 이 둘은 계속 키우고 싶은 값이다.
• 가운데 세 항 (세션당 턴, 턴당 요청, 요청당 토큰)이 최적화 대상이다. 엔지니어가 실제로 요청한 일 위에 에이전트가 자기 편의로 얹는 작업이 여기 들어간다. 우버의 노력은 대부분 이 세 항에 들어간다.
• 마지막 항 (토큰당 단가)은 벤더가 정한다. 우버가 고르는 것은 어느 모델이 어느 작업을 돌리느냐뿐이다.

에이전트가 계획을 더 빨리 세우게 돕고, 원치 않는 턴이나 오류를 줄이고, 입력 토큰을 깎는 장치들이 모두 가운데 세 항을 겨눈다.

무엇을 재는가

주간·월간으로 추적하는 지표 전체를 층별로 공개했다. 단기·장기 계획을 세우는 근거다.

가장 아래 행이 이 표의 핵심이다. 비용을 토큰이 아니라 성과로 나눈다. 병합된 풀 리퀘스트 한 건에 얼마, 리뷰 한 건에 얼마 하는 식이다.

토큰당 단가를 고르는 법

단가는 벤더가 정하니 우버가 할 일은 배치다. 모든 관리형 에이전트 층에서 그 작업에 가장 파레토 효율적인 모델을 고른다. 우버가 말하는 파레토 효율은 세 축이다. 완료 작업당 비용, 출력 품질, 모델 신뢰성.

모델 선택 절차는 어느 관리형 에이전트에서나 같다.

1. 그 에이전트가 실제로 한 일로 벤치마크를 만든다.
2. 프론티어 모델이든 오픈웨이트 모델이든 하나의 인터페이스 뒤에서 서비스하는 하네스로 에이전트를 돌린다.
3. 파레토 최적인 쪽으로 옮기고, 계속 옮긴다. 프론티어는 몇 주마다 움직인다.

모든 풀 리퀘스트의 AI 코드 리뷰를 담당하는 uReview가 예시다. 알려진 버그가 있는 실제 풀 리퀘스트로 벤치마크를 만들고 쉬움·중간·어려움으로 등급을 매겼다. 그 버그들을 기준으로 정밀도, 재현율, F1을 채점하고, 리뷰당 비용과 지연, 타임아웃, 노이즈를 함께 본다.

점선이 파레토 프론티어다. 그 아래·왼쪽에 있는 구성은 더 싸거나 더 좋은 무언가에 이미 밀린 것들이다. 모델을 바꾸자 F1이 올라가면서 풀 리퀘스트당 비용이 크게 떨어졌다.

대형 모노레포의 실제 풀 리퀘스트 수천 건으로 만든 Uber SWE Benchmark도 따로 있다. 작업 종류별로 프론티어·오픈웨이트 모델을 돌려, 개발 생애주기 전반의 관리형 에이전트 모델 선택에 쓴다.

서브에이전트 기본값이 가장 크게 움직인다

대화형 인터페이스에서는 토큰 단가가 고정이지만, 모델 사이의 토큰 분포는 조정할 수 있다. 그 분포를 지배하는 기본 설정이 둘이다. 세션 시작 모델과 서브에이전트 모델.

둘 중 서브에이전트 기본값이 가장 강력한 레버로 확인됐고, 그 비중은 계속 커지고 있다. 최신 모델의 다중 에이전트 오케스트레이션 능력이 올라가면서 서브에이전트를 띄우는 세션 비율이 꾸준히 늘었기 때문이다. 서브에이전트는 입력이 명시된 잘 정의된 작업을 하므로 프론티어급 추론이 필요하지 않은 경우가 많다. 그래서 기본값을 더 약하고 싼 모델로 두고 수동 재지정만 허용한다. 주 모델은 작업 분해와 평가를 맡고, 실행은 서브에이전트가 한다.

요청당 토큰을 줄이는 법

턴마다 대화 이력 전체와 프로젝트 컨텍스트, 도구 결과가 다시 전송된다. 요청 하나의 적재량을 줄이면 그 효과가 세션 내내 복리로 쌓인다.

두 개의 기본값

모든 대화형 하네스가 설치 관리, 설정, 인증, 비용 가시성을 위해 통일된 래퍼를 쓴다. 그 래퍼가 강제하는 표준 기본값 둘이 요청당 토큰을 직접 줄인다.

• 컨텍스트 창이 100만인 모델에도 40만 토큰에서 자동 압축을 건다. 이 임계값이 모델 성능과 캐시 버스트·입력 토큰 반복 비용 사이의 균형점이었다. 전사 요청당 입력 토큰이 의미 있게 줄었다.
• 추론 강도 기본값을 Medium으로 둔다. 내부 추론 토큰을 포함한 출력 토큰은 주력 모델에서 입력 토큰 단가의 몇 배로 과금된다. 이 정책은 가장 비싼 토큰 범주를 곧바로 깎는다. 넓은 범주의 작업에서 Medium이 비용과 품질의 좋은 균형이었다.

캐시 TTL을 1시간으로 옮긴 이유

프롬프트 캐싱 전략은 캐시 읽기·쓰기의 경제성에서 나온다. 턴마다 대화 이력 전체가 다시 전송되므로 앞선 컨텍스트를 캐싱하면 같은 값을 반복 지불하지 않고, 이후 읽기는 표준 입력 단가의 0.1배로 떨어진다. 문제는 쓰기 프리미엄이 다르다는 점이다. 5분 캐시 항목은 1.25배, 1시간 항목은 2배다. 그래서 최적 TTL은 턴 사이의 공백 길이에 달려 있다. 선택지는 Anthropic의 5분과 1시간, OpenAI의 30분이다.

엔지니어는 대화형 세션을 5분 넘게 놀려두는 일이 잦다. 그 공백이 접두 캐시를 무효화하면 정가로 컨텍스트를 다시 쌓아야 했다. 그래서 기본 5분에서 1시간으로 옮겼다. 서브에이전트는 짧게 한 가지 작업만 하고 끝나므로 5분 TTL을 그대로 유지한다.

MCP를 셸로 부른다

우버의 모든 MCP 상호작용은 통합 게이트웨이를 지난다. 이 단일 진입점에 내부와 서드파티 SaaS를 합쳐 1,000개가 넘는 MCP 서버가 붙어 있고, 인증과 정책 집행이 한곳에서 이뤄진다.

그런데 표준 MCP는 엔지니어가 그 세션에서 부를지 여부와 무관하게 모든 도구 스키마를 세션에 올린다. 도구 100개 이상을 설치한 경우 초기 프롬프트에 50~70K 토큰의 스키마 부담이 붙고, 그것이 컨텍스트 턴마다 다시 전송됐다.

이 컨텍스트 팽창을 두 가지 장치로 잡았다.

• CLI 도구 해결: MCP를 직접 연결하는 대신 모델이 셸 명령을 실행하게 한다. CLI가 호출 시점에 게이트웨이를 상대로 필요한 도구를 동적으로 찾아 부르므로, 우버 MCP 스키마가 세션 컨텍스트에서 사라진다. 내부 게이트웨이의 1,000개 이상 MCP 도구 전부가 CLI 명령으로 투사된다.
• 도구 검색: 모델이 도구 카탈로그를 검색해 필요한 것만 즉석에서 올린다. 도구 라이브러리가 커져도 선택 정확도가 유지되고, 큰 도구 집합에서 흔한 성능 저하를 막는다.

코드 모드

도구를 셸 명령으로 직접 부르게 되면, 모델은 여러 동작을 한 스크립트 안에 묶을 수 있다. 오가는 말이 많은 도구 프로토콜에서 특히 유리하다. 표준 MCP 흐름에서는 동작마다 별도의 모델 턴이 필요하다. 요청을 내보내고, 날것의 응답을 컨텍스트 창에 올리고, 결과를 순차로 처리한다. SQL 질의 한 건만 해도 요청 제출, 상태 폴링 2~5회, 출력 회수로 나뉜다. 코드 모드는 이 흐름 전체를 자동 파이썬 루프로 접어, 중간 폴링을 모델의 활성 컨텍스트 밖에 둔다.

같은 세션에서 동일한 SQL 질의 5개를 두 경로로 돌려 쟀다.

앞의 세 행이 핵심 발견이다. 응답 크기 한계에 한참 못 미치는 최소 결과 집합에서도 코드 모드가 토큰을 절반 이상 줄인다. 큰 데이터 적재를 우회해서 얻은 이득이 아니라, 스키마 초기화와 다중 턴 폴링, 단계마다 반복되는 추론 같은 불필요한 부담을 없앤 결과다. 대량 작업에서는 N번의 모델 턴이 한 스크립트가 되면서 절감이 90%를 넘는다. 가장 많이 쓰는 MCP 서버용으로 미리 만든 코드 모드 스킬을 25개 이상 배포해, 표준 작업이 기본적으로 가장 싼 경로를 타게 했다.

벤더 MCP가 더 어려웠다

서드파티 소프트웨어가 내부 서버보다 훨씬 까다로웠다. 벤더는 고객이 어떻게 쓸지 예측할 수 없으니 제품 기능 전체를 노출하도록 MCP 서버를 설계한다. 어느 워크스페이스 제품군은 도구 49개를 서버 하나에 묶어 약 22K 토큰의 스키마를 요구하고, 메시징과 프로젝트 추적 벤더는 각각 34개와 46개를 실어 보낸다. 벤더 서버 두세 개를 올리면, 사용자가 프롬프트를 입력하기도 전에 에이전트가 편집 중인 파일보다 무거운 스키마를 지고 있게 된다.

해법은 내부 MCP와 같았다. SaaS MCP 서버도 게이트웨이를 지나게 하고, 전부 CLI로 노출해 어느 에이전트 표면에서든 부를 수 있게 했다. 서버마다 코드 모드 플러그인 안에 전용 스킬을 만들어 흔한 작업 흐름을 감쌌다.

턴당 요청을 줄이는 법

접지되지 않은 에이전트는 싸게 실패하지 않고 느리게 실패한다. 한 곳만 더 찾아보려고 커지는 컨텍스트 창을 반복해서 보낸다. 이 탐색 부담을 줄이는 가장 강력한 레버는 처음부터 더 풍부한 정보를 주는 것이다.

수억 줄의 코드와 수천 개의 테이블을 가진 우버에서, 에이전트는 대부분의 턴을 코드 생성이 아니라 정보 위치 찾기에 쓴다. 그래서 AI 컨텍스트 그래프를 만들었다. 노드 2,400만 개와 엣지 8,000만 개, 노드 종류 86가지와 엣지 종류 117가지로 이뤄진 단일 네트워크다. 서비스, 엔지니어링 팀, 장애 로그, 풀 리퀘스트, 아키텍처 설계 문서, 배포, 데이터셋, 과거 테이블 사용 질의를 포함해 30개 이상의 내부 시스템 데이터를 통합했고, 어느 에이전트든 자연어로 질의할 수 있다.

같은 모델에 같은 프롬프트를 주고 접지 여부만 달리한 결과다. 접지된 에이전트는 과거 사용 이력을 질의해 애널리스트 50명 이상이 쓰는 특정 테이블을 찾아 38초에 답했다. 접지되지 않은 에이전트는 그 테이블을 보지 못한 채 20분 9초 동안 서비스 코드를 훑고 서브에이전트 2개를 띄우고 오류 3번을 만난 뒤, 그 데이터셋은 질의할 수 없다는 틀린 결론에 도달했다.

보이게 만든다

여기의 레버는 가시성과 피드백 루프다. 엔지니어와 에이전트가 더 빨리 수렴하게 돕는다.

하네스 상태 표시줄에 실시간 비용 계기를 넣었다. 하네스별 지출과 사용자별 전체 하네스 합계가 항상 보인다. 엄격한 상한을 씌우는 대신 실시간 추적과 자동 알림을 택했다.

• 상태 표시줄 실시간 계기로 진행 중인 세션 비용이 터미널에 늘 노출된다.
• 하네스 풀은 도구별 예산이 아니라 모든 대화형 하네스에 걸친 공유 등급 하나로 둔다. 관리형 에이전트는 별도 등급을 쓴다.
• 예상 지출의 50·80·100% 시점에 슬랙 알림이 가서 엔지니어가 계획을 세울 시간을 준다.
• 등급 상향은 관리자 승인으로 빠르게 전파된다.
• 비용 확인 스킬과 팁이 필요할 때 비용 내역을 보여주고 상태 표시줄에서 실시간으로 안내한다.

상태 표시줄은 세션 총액을 보여주지만 무엇이 비용을 만들었는지, 무엇을 고쳐야 하는지는 알려주지 않는다. 세션 분석 대시보드가 그 자리를 메운다. 런타임에 내장돼 설정도 옵트인도 필요 없고, 비용 대시보드 스킬을 실행하면 사용자가 쓰는 모든 하네스의 로컬·원격 샌드박스 세션 추적을 전부 분석한다. 총계 하나를 내놓는 대신, 세션에서 16가지 반패턴을 찾아내 각각에 금액 영향과 구체적 조치를 붙인다.

다음에 하려는 것

• 관리형 에이전트 함대를 늘린다. 새 에이전트마다 같은 순서를 밟는다. 목표 성과 지표를 정하고, 평가 벤치마크를 모으고, 파레토 최적 모델을 찾는다.
• 동적 모델 배치. 프로그래밍 언어와 코드 저장소, 에이전트 양식 전반으로 벤치마크 범위를 넓힌다. 모델 능력의 편차가 크기 때문에 배치는 평가의 폭에 달려 있다.
• 컨텍스트 그래프 통합을 깊게. 더 많은 자율 에이전트가 그래프를 질의할 수 있게 한다.
• 세션 분석을 실시간 안내로. 반패턴을 주기적으로 일괄 검출하는 방식에서 연속 추적 감시로 옮겨, 개인화된 효율 권고를 엔지니어에게 실시간으로 전달한다.
• 스킬 자동 개선. 에이전트 스킬 실행에서 나온 잔소리거리를 기록하고, 모인 추적으로 스킬 갱신안을 자동 생성한다.

가장 의외였던 것은

코드 모드 표의 첫 세 행이었다. SELECT 1 한 줄을 부르는 데 903토큰이 들고, 같은 일을 스크립트로 접으면 402토큰이 든다. 결과는 1행이다. 오가는 데이터가 아니라 부르는 방식 자체가 비용의 대부분이었다는 뜻이다.

이 관찰이 글 전체의 논지와 이어진다. 우버는 단가를 깎거나 도구를 하향 조정해서 비용을 줄이지 않았다. 가치를 만들지 않는 토큰을 골라 없앴다. 스키마 초기화, 폴링 왕복, 놀고 있는 동안 만료된 캐시, 물어보지도 않은 도구 100개의 정의처럼 사람이 요청한 일과 무관하게 붙는 것들이다. 비용 등식의 앞 두 항을 키우고 가운데 세 항만 깎는다는 원칙이 여기서 온다.

한 가지 더 눈에 남는 것은 결론의 방향이다. 우버는 개인의 터미널 세션 수천 개를 최적화하는 대신, 전용 벤치마크와 파레토 최적 모델을 짝지은 특화 관리형 에이전트 함대를 최적화하는 쪽이 본질적으로 더 싸고 더 잘 늘어난다고 말한다. 개발 생애주기의 작업을 관리형 환경으로 옮기면 모델 배치와 실행 하네스, 운영 지출을 온전히 통제할 수 있다는 것이다. 비용 문제를 사용자 교육의 문제가 아니라 아키텍처의 문제로 다시 놓은 셈이다.

출처

Uday Kiran Medisetty (Distinguished Engineer, Uber), “Running a Software Factory Efficiently at Uber Scale”, Uber Blog, 2026년 8월 27일. 원문: https://www.uber.com/us/en/blog/efficient-software-factory/ Uber Engineering의 X 게시: https://x.com/UberEng/status/2093444169037762840

원문의 가격·벤더 지표는 모두 공개된 정보에 기반하며, 비용 효율 개선은 표준 등급 가격 안에서 우버 내부 작업을 더 지능적으로 배치해 얻은 것이라고 밝히고 있다. 구체적인 절감폭은 코드베이스와 팀 규모, 에이전트 작업 흐름에 따라 달라진다.

본문 도표는 모두 원문에서 인용했다. Anthropic®은 Anthropic PBC의 등록 상표이며, Claude Code™와 Claude®는 Anthropic PBC의 상표다. OpenAI®와 그 로고는 OpenAI®의 등록 상표다.