# (요약) Uber 규모에서 효율적으로 소프트웨어 팩토리 운영하기 ## **소개** 1. Uber는 소프트웨어 개발 전 단계에 AI 도구를 내재화했음. 2. 전체 풀 리퀘스트(pull request)의 70% 이상이 로컬 또는 클라우드 에이전트에 귀속됨. 3. 엔지니어들은 소프트웨어 개발 수명 주기(SDLC) 전반에 걸쳐 3,600개 이상의 에이전트 스킬(agent skill)을 구축했음. 4. 에이전트 스킬은 하루 3만 회 이상 실행됨. 5. Uber는 AI Engineer 2026 콘퍼런스에서 소프트웨어 팩토리(Software Factory) 비전과 수명 주기 전반의 구성 요소 및 관리형 에이전트를 공개했음. 6. 자동화된 관리형 에이전트가 인간 대신 시작하는 세션 비중이 증가 중임. 7. 관리형 에이전트는 코드 리뷰, CI 실패 자가 복구, 시각 검증을 포함한 E2E 풀 리퀘스트 완료, 온콜 알림 분류, 유입 버그 디버깅, 코드 유지보수 등을 수행함. 8. 이 과정에서 인간 검토와 에스컬레이션을 함께 적용함. 9. 2026년 2월부터 8월까지 모든 직원(엔지니어·비엔지니어)의 에이전트 도구 주간 활성 사용자 수는 7배 증가했음. 10. 같은 기간 주간 에이전트 요청 수는 9.4배 증가했음. 11. 전반적 최적화로 전체 AI 지출은 4월 이후 비교적 안정화됨. 12. [그림 1](https://cn-geo1.uber.com/image-proc/resize/udam/format=auto/srcb64=aHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9kZGExMDZkMy0wNDM5LTQyN2ItYjc4MC1jMzk5ZGM4NWM3YzgucG5n)은 2026년 2월~8월 중순의 주간 활성 사용자, 에이전트 요청, 비용 추이를 나타냄. 13. 그림 1의 사용자 수는 도구 간 중복을 제거한 수치임. 14. 도입률, 작업 부하 구성, 모델 업그레이드가 지속적으로 변화하므로 자체 최적화 효과를 분리하려면 하나의 모델을 고정해야 함. 15. 모델 업그레이드와 모델 계열 변경마다 동작 특성이 달라지기 때문임. 16. Uber는 2월부터 7월까지 모델을 고정해 분석했음. 17. 모델 요청 1,000건당 비용은 정점 대비 약 34% 감소했음. 18. 세션당 비용은 6월 정점 대비 52% 감소했음. 19. [그림 2](https://cn-geo1.uber.com/image-proc/resize/udam/format=auto/srcb64=aHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9iMjVkMTc1Zi04MjFiLTRiYTYtYTE0OS0xNGU1Yzk1YTI1Y2IucG5n)은 모델을 고정했을 때의 비용 최적화 효과를 보여줌. 20. 그림 2의 세션당 비용 데이터는 5월 말부터 시작됨. 21. 이 글은 소프트웨어 팩토리를 구성하는 에이전트 세션의 4개 계층, 비용 방정식, 항별 측정 방식, 계층별 최적화 방법을 다룸. 22. 가격 및 벤더 지표는 공개 정보를 기반으로 함. 23. 비용 효율성 개선은 표준 티어 가격 체계 안에서 Uber 내부 작업 부하를 더 지능적으로 라우팅해 달성함. 24. 구체적 비용 절감 폭은 코드베이스, 팀 규모, 에이전트 워크플로에 따라 달라질 수 있음. 25. 실제 작업을 벤치마킹하고 정확도와 비용을 함께 최적화하는 방법론은 보편적으로 적용 가능함. ### **소프트웨어 팩토리와 비용 방정식** #### **에이전트 사용의 4개 계층** 26. Uber는 AI 사용을 가장 특수한 계층부터 가장 일반적인 계층까지 4개 계층으로 구성함. 27. 계층이 높을수록 비용, 품질, 모델 선택에 대한 통제력이 커짐. 28. [그림 3](https://cn-geo1.uber.com/image-proc/crop/smartcrop/udam/format=auto/width=2400/height=1596/srcb64=aHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy82ZjZhMmY5ZC04ZTcwLTQ1YTgtOTYzNy05ZmZhMTE4YWEyM2IucG5n)은 에이전트 세션이 실행되는 4개 계층을 나타냄. #### **비용 방정식** 29. 에이전트 세션 비용은 계층과 무관하게 독립적으로 측정·최적화 가능한 항으로 분해 가능함. 30. 총지출은 사용자 수 × 사용자당 세션 수 × 세션당 턴 수 × 턴당 요청 수 × 요청당 토큰 수 × 토큰당 가격으로 구성됨. 31. [그림 4](https://cn-geo1.uber.com/image-proc/crop/smartcrop/udam/format=auto/width=2280/height=654/srcb64=aHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9jYWY5MWU3ZC0wODVkLTQwMTQtOTE4Zi1hZmVmN2Y3YjI5OWIucG5n)은 총지출을 곱셈 관계인 6개 항으로 분해한 방정식을 보여줌. 32. 첫 두 항은 도입 및 참여를 의미함. 33. 사용자 수와 사용자당 세션 수는 대화형 사용 여부나 에이전트 대행 여부와 무관하게 전체 사용자 기반에서 늘려야 하는 지표임. 34. 가운데 세 항은 최적화 기회를 제공함. 35. 가운데 세 항은 엔지니어가 실제로 요청한 작업 외에 에이전트가 자체적으로 수행하는 작업을 의미함. 36. Uber의 최적화 노력 대부분은 이 영역에 집중됨. 37. 주요 최적화 대상은 에이전트 계획 시간 단축, 불필요한 턴과 오류 감소, 입력 토큰 최적화 등임. ### **측정 방법** 38. Uber는 단기·장기 예측과 계획을 위해 다음 지표를 매주 및 매월 추적함. 39. 포트폴리오(portfolio) 지표는 총 귀속 비용, 고유 귀속 사용자 수, 도구·에이전트별 비용·사용자·지출 비중으로 구성됨. 40. 포트폴리오 지표는 비용이 어디로 가는지와 어떤 도구가 변화를 일으켰는지를 보여줌. 41. 도구별 단위 경제성(unit economics) 지표는 사용자당 비용, 사용자당 요청 수, 요청 1,000건당 비용으로 구성됨. 42. 도구별 단위 경제성 지표는 요청당 입력·출력·전체 토큰 수, 토큰 100만 개당 비용도 포함함. 43. 도구별 단위 경제성 지표는 세션 1,000건당 비용, 활성 세션 시간당 비용, 프롬프트 캐시 적중률도 포함함. 44. 도구별 단위 경제성은 도구 자체가 저렴해지는지 또는 단순히 사용량 구성이 이동하는지를 판단하게 함. 45. 모델 경제성(model economics)은 모든 모델의 비용과 비용 비중을 측정함. 46. 모델 경제성은 요청 수와 요청 비중, 요청 1,000건당 비용, 토큰 100만 개당 비용을 측정함. 47. 모델 경제성은 동일하거나 다른 토큰당 가격에서 어떤 모델 출시가 실제 청구 비용을 변화시켰는지 보여줌. 48. 동인 분해(driver decomposition)는 비용 변화를 사용자 수 기반 도입, 사용자당 요청 수 기반 참여, 요청당 입력 토큰 기반 입력 작업 부하, 요청당 출력 토큰 기반 출력 작업 부하로 순차 분해함. 49. 동인 분해는 설명되지 않은 잔차 없이 비용 변동 원인을 정확히 제시함. 50. 관리형 에이전트 성과 지표는 병합된 풀 리퀘스트당 비용, 리뷰당 비용, 알림당 비용, 정리 작업당 비용 같은 결과 단위 비용을 포함함. 51. 관리형 에이전트 성과 지표는 리버트율(revert rate), F1, 평균 복구 시간(MTTR) 같은 품질 신호를 포함함. 52. 관리형 에이전트 성과 지표는 반영된 변경 사항, 게시된 리뷰, 분류된 알림 같은 처리량도 포함함. 53. 관리형 에이전트 성과 지표는 단위 가치당 비용이 낮아지는지와 모델 마이그레이션 중 품질이 유지되는지를 평가함. ### **최적화 레버** 54. 비용 방정식의 각 부분을 최적화하기 위해 여러 레버를 사용함. 55. 일부 레버는 비용 방정식의 여러 항에 동시에 영향을 줌. 56. 토큰당 가격은 벤치마크 기반 파레토 최적(Pareto-optimal) 모델 선택으로 최적화함. 57. 모델 기본값은 초기 세션 모델과 서브에이전트 모델 선택으로 최적화함. 58. 요청당 토큰 수는 기본 40만 토큰 컨텍스트 상한과 기본 중간 추론 노력(Medium reasoning effort)으로 최적화함. 59. 요청당 토큰 수는 프롬프트 캐싱(prompt caching), 도구 검색, CLI로 해결되는 MCP 호출, 코드 모드(code-mode) 도구 호출 일괄 처리, 게이트웨이 라우팅 SaaS MCP로도 최적화함. 60. 턴당 요청 수는 그래프 기반 컨텍스트로 최적화함. 61. 지속적 스킬 최적화도 적용함. 62. 가시성과 교육은 상태 표시줄의 실시간 비용 카운터, 가시성 및 지출 티어, 세션 분석 대시보드로 강화함. ### **토큰당 가격 최적화** 63. 토큰 가격은 벤더가 설정함. 64. Uber는 각 작업 부하에 어떤 모델을 실행할지 선택함. 65. 모든 관리형 에이전트 계층에서 작업 부하별로 가장 파레토 효율적인 모델을 선택함. 66. Uber에서 파레토 효율성은 완료 작업당 비용, 출력 품질, 모델 신뢰성을 의미함. #### **벤치마크 기반 모델 선택** 67. 모든 관리형 에이전트의 모델 선택은 동일한 4단계로 진행됨. 68. 첫 단계는 에이전트의 실제 작업으로 벤치마크를 구축하는 것임. 69. 둘째 단계는 프런티어 모델(frontier model)과 오픈 웨이트(open-weight) 모델을 하나의 인터페이스 뒤에서 제공하는 하니스(harness)로 에이전트를 실행하는 것임. 70. 셋째 단계는 파레토 최적 모델로 이동하고 지속적으로 다시 이동하는 것임. 71. 모델 프런티어는 몇 주마다 변화함. 72. Uber는 관리형 에이전트 집계 인사이트를 활용해 작업 부하 성능을 지속적으로 개선함. 73. Uber는 다양한 모델 라우팅 전략을 시험하고 배포함. 74. uReview는 모든 풀 리퀘스트의 AI 코드 리뷰를 처리함. 75. Uber는 실제 버그가 알려진 풀 리퀘스트를 기반으로 uReview 벤치마크를 구축했음. 76. 해당 풀 리퀘스트는 쉬움·중간·어려움으로 등급화됨. 77. uReview는 버그 대비 정밀도(precision), 재현율(recall), F1을 측정함. 78. uReview는 리뷰당 비용, 지연시간, 타임아웃, 노이즈도 측정함. 79. 모델 전환은 F1을 개선하면서 풀 리퀘스트당 비용을 크게 낮췄음. 80. [그림 5](https://cn-geo1.uber.com/image-proc/resize/udam/format=auto/srcb64=aHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9hM2I2OGQ3OS00ZDFmLTQ3ZDUtOTUyNC01YzBjNDA0YmRiZDIucG5n)은 uReview의 10개 모델 구성별 리뷰당 비용과 F1 점수를 비교함. 81. 그림 5의 점선은 파레토 프런티어를 의미함. 82. 점선의 아래·왼쪽에 있는 구성은 더 저렴하거나 더 우수한 다른 구성에 의해 지배됨. 83. Uber는 대규모 모노레포(monorepo)의 실제 풀 리퀘스트 수천 건을 사용한 Uber SWE Benchmark도 보유함. 84. Uber SWE Benchmark는 작업 유형별로 프런티어 모델과 오픈 웨이트 모델을 실행함. 85. Uber는 이 벤치마크로 모든 SDLC 관리형 에이전트의 모델 선택을 결정함. #### **기본 모델 선택** 86. 대화형 인터페이스에서 토큰 단가는 고정됨. 87. 대화형 인터페이스에서는 모델 간 토큰 배분을 전략적으로 관리할 수 있음. 88. 토큰 배분은 초기 세션 모델과 서브에이전트 모델이라는 두 기본 설정의 영향을 주로 받음. 89. 서브에이전트 기본 설정은 가장 큰 영향력을 가진 레버임. 90. 최신 모델 능력이 더 효과적인 다중 에이전트 오케스트레이션을 가능하게 하면서 서브에이전트를 시작하는 세션 비율은 지속적으로 증가함. 91. 서브에이전트는 명시된 입력을 바탕으로 잘 정의된 작업을 수행함. 92. 서브에이전트 작업은 프런티어 수준 추론이 필요 없는 경우가 많음. 93. Uber는 서브에이전트를 더 약하지만 비용 효율적인 모델로 기본 설정함. 94. 사용자는 수동으로 모델을 재정의할 수 있음. 95. 주 모델은 작업 분해와 평가를 수행함. 96. 서브에이전트는 실제 작업을 실행함. ### **요청당 토큰 수 최적화** 97. 모든 턴은 전체 대화 기록, 프로젝트 컨텍스트, 도구 결과를 다시 전송함. 98. 요청당 페이로드를 줄이는 모든 조치는 세션 전체에 누적 효과를 냄. #### **기본값** 99. 모든 대화형 하니스는 설치 관리, 구성, 인증, 비용 가시성을 위한 통합 래퍼(wrapper)를 사용함. 100. 두 가지 표준 기본 구성이 요청당 토큰 소비를 직접 줄임. 101. 첫 기본값은 100만 토큰 컨텍스트 윈도 모델에서도 40만 토큰에 자동 압축(compaction)을 실행하는 것임. 102. 40만 토큰 임계값은 모델 성능과 캐시 버스트 및 반복 입력 토큰 비용 간 균형을 맞춤. 103. 측정 결과는 전체 환경의 요청당 입력 토큰 수가 유의미하게 감소했음을 보여줌. 104. 둘째 기본값은 추론 노력을 중간(Medium)으로 설정하는 것임. 105. 내부 추론 토큰을 포함한 출력 토큰은 주 모델에서 입력 토큰 요율의 배수로 과금됨. 106. 이 정책 변경은 최고 비용 토큰 범주의 지출을 직접 낮춤. 107. 광범위한 작업 범주에서 중간 추론은 비용과 품질의 적절한 균형을 제공함. #### **프롬프트 캐싱 전략** 108. 프롬프트 캐싱 전략은 제공업체의 프롬프트 캐시 읽기·쓰기 경제성에 기반함. 109. 각 턴이 전체 대화 기록을 재전송하므로 이전 컨텍스트를 캐싱하면 전체 비용을 반복 지불하지 않아도 됨. 110. 후속 캐시 읽기 비용은 표준 입력 토큰 요율의 0.1배임. 111. 캐시 쓰기 프리미엄은 TTL(Time-to-Live)에 따라 다름. 112. 5분 캐시 항목은 표준 입력 토큰 요율의 1.25배임. 113. 1시간 캐시 항목은 표준 입력 토큰 요율의 2배임. 114. 최적 TTL은 턴 사이의 유휴 간격에 따라 결정됨. 115. Anthropic®은 5분 및 1시간 TTL을 제공함. 116. OpenAI®는 30분 TTL을 제공함. 117. [그림 6](https://cn-geo1.uber.com/image-proc/resize/udam/format=auto/srcb64=aHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9mNjEzNDE2MC02YmViLTQyNzItOGQ4OC0yYmVlNzkyZDA0MDMucG5n)은 메인 스레드와 서브에이전트 시나리오에서 5턴 기준 5분·1시간 TTL의 비용을 비교함. 118. 엔지니어는 대화형 세션을 5분 이상 유휴 상태로 두는 경우가 많음. 119. Uber는 기본 5분 TTL에서 1시간 TTL로 전환했음. 120. 이전에는 빈번한 유휴 간격이 접두사 캐시(prefix cache)를 무효화해 전체 가격의 컨텍스트 재구축을 유발했음. 121. 서브에이전트는 단일 단기 작업에 집중하므로 5분 캐시 TTL을 유지함. #### **셸을 통한 MCP 도구 실행** 122. Uber의 모든 MCP(Model Context Protocol) 상호작용은 통합 게이트웨이를 거침. 123. 이 단일 진입점은 내부 및 제3자 SaaS MCP를 포함한 1,000개 이상의 MCP 서버를 포괄함. 124. 통합 게이트웨이는 인증과 정책 집행을 중앙화함. 125. 표준 MCP는 엔지니어가 해당 세션에서 호출하지 않을 도구까지 포함해 모든 도구 스키마를 세션에 직접 적재함. 126. 도구 100개 이상을 설치하면 초기 프롬프트에 약 5만~7만 토큰의 스키마 오버헤드가 추가됨. 127. 이 스키마 오버헤드는 모든 컨텍스트 턴에서 다시 전송됨. 128. [그림 7](https://cn-geo1.uber.com/image-proc/resize/udam/format=auto/srcb64=aHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy83MWJkMGZiYi0yNDk0LTRmOTItYjE5NC02MTBlM2E5NDA3YmYucG5n)은 동일 도구에 접근하는 3가지 방식에서 세션 시작 시 에이전트가 지닌 토큰량을 비교함. 129. 개별 서버 설치는 약 5만~7만 토큰을 사용함. 130. 도구 검색과 CLI 사용은 초기 토큰 사용량을 거의 0으로 만듦. 131. Uber는 컨텍스트 비대화를 해결하기 위해 두 가지 보완적 최적화 메커니즘을 도입했음. 132. 첫 메커니즘은 CLI 도구 해결(CLI tool resolution)임. 133. CLI 도구 해결은 모델이 셸 명령을 실행하게 해 직접 MCP 통합을 대체함. 134. CLI는 호출 시점에 필요한 도구를 게이트웨이에서 동적으로 해결하고 호출함. 135. CLI 도구 해결은 세션 컨텍스트에서 Uber MCP 스키마를 제거함. 136. 내부 MCP 게이트웨이의 1,000개 이상 MCP 도구는 CLI 명령으로 노출됨. 137. 둘째 메커니즘은 도구 검색(tool search)임. 138. 도구 검색은 모델이 도구 카탈로그를 검색하고 필요한 도구만 온디맨드로 적재하게 함. 139. 도구 검색은 수천 개 도구로 확장 가능함. 140. 도구 검색은 도구 정의 토큰 사용량을 줄이고 도구 라이브러리가 커져도 높은 선택 정확도를 유지함. 141. 도구 검색은 대규모 도구 집합에서 발생하는 성능 저하를 방지함. #### **코드 모드** 142. 도구가 셸 명령으로 함수를 직접 호출하면 모델은 단일 스크립트 안에서 여러 작업을 일괄 처리할 수 있음. 143. 이러한 일괄 처리는 대화량이 많은 도구 프로토콜에서 특히 유리함. 144. 표준 MCP 워크플로에서는 각 작업마다 모델이 요청을 생성하는 별도 턴이 필요함. 145. 표준 MCP 워크플로에서는 원시 응답을 컨텍스트 윈도에 적재하고 결과를 순차 처리해야 함. 146. 단일 SQL 쿼리도 요청 제출, 2~5회 상태 폴링, 출력 회수가 필요함. 147. 코드 모드는 이 흐름 전체를 자동화된 Python 루프로 처리함. 148. 코드 모드는 중간 폴링 결과를 모델의 활성 컨텍스트에서 제외함. 149. [그림 8](https://cn-geo1.uber.com/image-proc/resize/udam/format=auto/srcb64=aHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy8zMThiN2YyYy0zOGQ2LTQxNWYtYWViMy0xODU5Zjk2NWM1NzMucG5n)은 동일한 웨어하우스 쿼리를 MCP 방식과 코드 모드 방식으로 비교함. 150. 그림 8의 왼쪽에서는 모델이 폴링 루프에 참여하고 모든 응답이 컨텍스트에 들어감. 151. 그림 8의 오른쪽에서는 루프가 하위 프로세스에서 실행되고 요약만 모델로 반환됨. 152. Uber는 동일 세션에서 동일한 SQL 쿼리 5개를 두 경로로 실행해 측정했음. 153. `SELECT 1` 1행 결과는 LLM 도구 사용 903토큰, 코드 모드 402토큰으로 55% 절감됨. 154. `COUNT(*)` 1행 결과는 LLM 도구 사용 954토큰, 코드 모드 403토큰으로 58% 절감됨. 155. `GROUP BY LIMIT 20` 20행 결과는 LLM 도구 사용 1,600토큰, 코드 모드 457토큰으로 71% 절감됨. 156. `SHOW COLUMNS` 175행 결과는 LLM 도구 사용 2,200토큰, 코드 모드 900토큰으로 59% 절감됨. 157. 와이드 테이블 `SELECT *` 50행 결과는 LLM 도구 사용 1,431,594토큰, 코드 모드 900토큰으로 거의 100% 절감됨. 158. 쿼리당 토큰 수는 동일한 Claude Code 세션에서 측정됨. 159. 처음 3개 행은 응답 크기 제한보다 훨씬 작은 최소 결과 집합에서도 코드 모드가 토큰 사용량을 50% 이상 낮춘다는 사실을 보여줌. 160. 효율성은 대규모 데이터 페이로드를 우회해서가 아니라 스키마 초기화, 다중 턴 폴링, 중복된 단계별 추론을 제거해서 발생함. 161. 대량 워크플로에서는 기존 N회 모델 턴이 하나의 스크립트가 되므로 효과가 누적됨. 162. 대량 워크플로의 절감률은 90%를 초과함. 163. Uber는 가장 많이 접근하는 MCP 서버를 위해 사전 구축 코드 모드 스킬 25개 이상을 배포했음. 164. 이를 통해 표준 워크플로가 가장 비용 효율적인 경로를 기본으로 사용하게 함. #### **SaaS MCP** 165. 제3자 소프트웨어 관리는 내부 서버보다 훨씬 어려웠음. 166. 벤더는 고객별 사용 방식을 예측할 수 없으므로 전체 제품 기능을 노출하는 MCP 서버를 설계함. 167. 한 워크스페이스 제품군은 단일 서버에 49개 도구를 묶고 약 2만2천 토큰의 스키마를 요구함. 168. 메시징 및 프로젝트 추적 벤더는 각각 34개와 46개 도구를 제공함. 169. 벤더 서버 2~3개를 적재하면 사용자가 프롬프트를 입력하기 전부터 에이전트가 편집 대상 파일보다 큰 스키마 오버헤드를 지닐 수 있음. 170. Uber는 내부 MCP와 동일한 방식으로 SaaS MCP 서버를 MCP 게이트웨이를 통해 라우팅함. 171. Uber는 모든 SaaS MCP를 모든 에이전트 인터페이스에서 호출 가능한 CLI로도 노출함. 172. Uber는 서버별 일반 워크플로를 캡슐화하기 위해 코드 모드 플러그인 안에 전용 스킬을 작성함. 173. 이 방식은 다수 SaaS 벤더 전반에서 효율적인 에이전트 워크플로를 가능하게 함. 174. [그림 9](https://cn-geo1.uber.com/image-proc/resize/udam/format=auto/srcb64=aHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy84NjlhNTcxMi0zNmZiLTQwMmItYWQ5ZS03MWFlNmE2MTA1Y2YucG5n)은 단일 셸 명령이 MCP 게이트웨이를 통해 워크스페이스, 프로젝트, 메시징, 디자인 등 여러 SaaS 도구에 접근하는 구조를 보여줌. ### **턴당 요청 수 최적화** 175. 근거가 없는 에이전트는 저렴하게 실패하지 않고 느리게 실패함. 176. 근거가 없는 에이전트는 한 곳을 더 찾으려고 확장되는 컨텍스트 윈도를 반복 전송함. 177. 더 풍부한 정보를 선행 제공하는 방식이 탐색 오버헤드를 줄이는 가장 강력한 레버임. #### **컨텍스트 엔지니어링** 178. Uber의 코드베이스와 데이터 생태계는 수억 줄의 코드와 수천 개 테이블로 구성됨. 179. 에이전트는 코드 생성보다 정보 탐색에 대부분의 턴을 사용함. 180. Uber는 이를 해결하기 위해 AI Context Graph를 구축했음. 181. AI Context Graph는 86개 노드와 117개 엣지 유형에 걸쳐 2,400만 노드 및 8,000만 엣지를 포함하는 통합 네트워크임. 182. AI Context Graph는 서비스, 엔지니어링 팀, 인시던트 로그, 풀 리퀘스트, 아키텍처 설계 문서, 배포, 데이터세트, 과거 테이블 사용 쿼리를 포함한 30개 이상 내부 시스템의 데이터를 통합함. 183. 모든 에이전트는 AI Context Graph를 자연어로 질의할 수 있음. 184. [그림 10](https://cn-geo1.uber.com/image-proc/resize/udam/format=auto/srcb64=aHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy8xYzZjNzM3MS1hNGU0LTQ3ZGQtOTQ5Ni0zMTViZWEyYmYxMDIucG5n)은 동일 모델과 동일 프롬프트에서 그래프 기반 근거 제공 여부에 따른 실행 경로를 비교함. 185. 그래프 기반 에이전트는 과거 사용 이력을 질의해 50명 이상 분석가가 사용한 특정 테이블을 식별했음. 186. 그래프 기반 에이전트는 38초 만에 정답을 제공했음. 187. 근거 없는 에이전트는 해당 테이블을 볼 수 없었음. 188. 근거 없는 에이전트는 서비스 코드를 검사하고 서브에이전트 2개를 생성하며 오류 3개를 겪는 데 20분이 걸렸음. 189. 근거 없는 에이전트는 결국 데이터세트를 질의할 수 없다고 잘못 결론지었음. ### **가시성 및 교육** 190. 이 영역의 핵심 레버는 엔지니어와 에이전트가 더 빨리 수렴하게 하는 가시성과 피드백 루프임. #### **상태 표시줄** 191. Uber는 하니스 상태 표시줄에 실시간 비용 카운터를 배치했음. 192. 이 카운터는 하니스별 실시간 지출과 사용자별 모든 하니스의 지출을 추적함. 193. [그림 11](https://cn-geo1.uber.com/image-proc/resize/udam/format=auto/srcb64=aHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9lMDg3OGU0ZC01NWI0LTQ2MjAtYmI5Zi1jZmM5OTc3MTg1NmMucG5n)은 세션 분석기와 효율성 가이드를 함께 제공하는 상태 표시줄을 보여줌. #### **가시성 및 지출 티어** 194. Uber는 엄격한 상한을 부과하는 대신 실시간 지출 추적과 자동 알림을 구현했음. 195. 상태 표시줄 실시간 카운터는 실행 중인 세션 비용을 항상 터미널에 표시함. 196. 하니스 풀(harness pool)은 도구별 예산이 아닌 모든 대화형 하니스에 공유되는 하나의 티어임. 197. 관리형 에이전트에는 별도 티어를 적용함. 198. Slack 알림은 예상 지출의 50%, 80%, 100% 시점에 전송됨. 199. Slack 알림은 엔지니어가 계획을 세울 시간을 제공함. 200. 티어 상향은 관리자 승인으로 처리되며 빠르게 반영됨. 201. 비용 확인 스킬(cost check skill)과 팁은 온디맨드 비용 분석 및 상태 표시줄 코칭을 제공함. 202. 이러한 장치는 엔지니어가 작업 투자수익률(ROI)을 독립적으로 평가하면서 통제 불능 지출을 줄이게 함. #### **세션 분석 대시보드** 203. 상태 표시줄은 세션 총지출을 보여주지만 비용 동인이나 실행 가능한 효율화 단계는 보여주지 못함. 204. 일반 가이드는 상위 원칙을 제공하지만 개별 개발자 워크플로를 평가할 수 없음. 205. 세션 분석 대시보드는 세션 아티팩트를 직접 검사해 이 격차를 해소함. 206. 세션 분석 대시보드는 런타임에 직접 내장되어 별도 설정이나 옵트인이 필요 없음. 207. 사용자가 비용 대시보드(cost dashboard) 스킬을 실행하면 모든 하니스에서 사용하는 로컬 및 원격 클라우드 샌드박스의 모든 세션 추적을 분석함. 208. 대시보드는 집계 지표만 생성하지 않음. 209. 대시보드는 세션 전반의 16가지 개별 안티패턴을 식별함. 210. 각 안티패턴에는 금전적 영향과 맞춤형 개선 방안이 함께 제시됨. 211. 하위 최적 모델 라우팅의 예시는 Sonnet으로 충분한 단순 다중 턴 세션을 Opus에서 실행하는 것임. 212. 컨텍스트 윈도 비대화의 예시는 40KB 응답 같은 대형 MCP 페이로드가 컨텍스트에 남아 이후 턴에서 반복 과금되는 것임. 213. 캐시 만료 비효율의 예시는 장시간 중단 후 세션을 재개해 만료된 프롬프트 캐시가 전체 가격의 접두사 재구축을 강제하는 것임. 214. 프롬프트 초기화 오버헤드의 예시는 사용자 입력 전에 시스템 지시문과 도구 정의 10만 토큰을 미리 적재하는 것임. 215. [그림 12](https://cn-geo1.uber.com/image-proc/resize/udam/format=auto/srcb64=aHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9kNGNhYWMzYy1hOWNkLTRiYzItYmQyNS0wN2M2NDY1NThjZmYucG5n)은 총지출 4,162.07달러, 433개 세션, 95% 캐시 적중률, 캐시 미스 비용 1,097.82달러, 절감액 1,213.87달러를 포함한 세션 비용 대시보드를 보여줌. ### **향후 계획** 216. Uber는 관리형 에이전트 집단을 확장 중임. 217. 신규 에이전트마다 목표 결과 지표를 설정하고 평가 벤치마크를 구성하며 파레토 최적 모델을 식별하는 일관된 로드맵을 따름. 218. 이 체계적 접근은 SDLC의 각 단계를 팩토리 성숙도 모델의 더 높은 단계로 끌어올리는 것을 목표로 함. 219. Uber는 동적 모델 라우팅(Dynamic Model Routing)을 확대 중임. 220. Uber는 다양한 프로그래밍 언어, 코드 저장소, 에이전트 모달리티 전반으로 벤치마크 범위를 확장 중임. 221. 모델 능력은 크게 다르므로 효과적인 모델 라우팅은 포괄적 평가에 크게 의존함. 222. Uber는 더 많은 자율 에이전트에서 컨텍스트 그래프 질의 기능을 활용하도록 통합을 심화 중임. 223. Uber는 세션 분석을 실시간 개발자 안내로 발전시키고 있음. 224. Uber는 주기적 배치 기반 안티패턴 탐지에서 지속적 추적 모니터링으로 전환하려 함. 225. Uber는 엔지니어에게 개인화된 실시간 효율성 권고를 직접 제공하려 함. 226. Uber는 에이전트 스킬 실행에서 불편 요소(papercut)를 자동 기록하고 수집한 추적 데이터에서 스킬 업데이트를 자동 생성하는 방식을 개발 중임. ## **결론** 227. 증가하는 AI 코딩 비용을 관리하고 억제하는 일은 해결 가능한 엔지니어링 과제임. 228. Uber는 단가 인하나 도구 성능 하향에만 의존하지 않았음. 229. Uber는 가치가 전혀 없는 낭비 토큰 소비를 제거하는 데 집중했음. 230. 그 결과 사용량을 7배 확장하면서 모든 지표의 단위 비용을 줄였음. 231. 동시에 출력 품질을 개선하거나 유지했음. 232. 핵심 전략 변화는 대화형 개발자 워크플로에서 완전 관리형 에이전트로 이동하는 것임. 233. SDLC 작업 부하를 관리형 환경으로 옮기면 모델 라우팅, 실행 하니스, 운영 지출을 완전히 통제할 수 있음. 234. 전용 평가 벤치마크와 파레토 효율적 모델을 결합한 특수 관리형 에이전트 집단 최적화가 핵심임. 235. 이는 수천 명 엔지니어의 개별 터미널 세션을 최적화하는 방식보다 본질적으로 비용 효율적이고 확장 가능함. ### **감사의 말** 236. 이 성과는 Uber 규모의 소프트웨어 팩토리를 구현할 가장 효율적인 구성 요소를 만들고 모든 토큰 지출의 ROI를 확보하려는 다수 엔지니어의 공동 노력임. 237. 핵심 기여자는 Abhishek Bhatia, Adam Huda, Aditya Patel, Alok Srivastava, Ameya Ketkar, Anil Purohit, Atakan Kandemir, Ben Chou, Brandon Barker, Danielle Yim, Deepanshu Mehndiratta, Gaurav Gill, Israel Marban, Jason Varbedian, Karen Xu, Lei Shi, Mager Mager, Meghana Somasundara, Peng Liu, Preet Inder, Qiushen Wang, Rush Tehrani, Shesh Patel, Shiven Tripathi, Shubham Gupta, Stas Khalup, Ting Chen, Tse-Shi Wang, Ty Smith, Vikram Hullukunte, Viv Keswani, Weiqiang Wang, Will Bond임. 238. 리더십 기여자는 Johannes Gehrke, Mattie Toia, Sumanth Sukumar, Praveen Neppalli Naga임. 239. 표지 사진 출처는 Himer Romana임. 240. Anthropic®은 Anthropic PBC의 등록상표임. 241. Claude Code™ 및 Claude®는 Anthropic PBC의 상표임. 242. OpenAI® 및 그 로고는 OpenAI®의 등록상표임.