PR 10개 중 7개를 에이전트가 쓰는 우버 팀에게 배울 것

다만 그 기간, 우버에서는 도입률도 워크로드 구성도 모델도 다 변했습니다. 그래서 회사는 최적화 효과만 분리해 보려고 모델 하나를 고정해 측정했습니다. 모델을 바꾸면 단가와 성능이 함께 달라지니, 같은 모델을 쓴 세션만 골라 비교해야 최적화 조치의 효과가 보이기 때문입니다. 그렇게 본다 해도 2월부터 7월까지 모델 요청 1,000건당 비용은 정점 대비 34%가량, 세션당 비용은 6월 정점 대비 52% 내려갔습니다.

우버도 이 절감치 자체는 자기 환경 고유의 결과라고 선을 긋습니다. 코드베이스와 팀 규모, 에이전트 워크플로에 따라 결과가 달라진다고요. 그러나 실제 작업으로 벤치마크를 만들고 정확도와 비용을 함께 최적화하는 방법론은 보편적으로 적용할 수 있다고 말합니다.

2. 에이전트 ‘공장’을 조직하는 방법

우버는 AI 사용을 가장 특화된 것부터 가장 범용적인 것까지 4개 층으로 나눠 조직합니다. 층이 높을수록 비용·품질·모델 선택에 대한 통제력이 커진다고 하고요. 뒤에 다시 다루겠지만 코드 리뷰처럼 일감이 정해진 매니지드(managed) 에이전트와 엔지니어가 자유롭게 쓰는 인터랙티브 세션을 같은 방식으로 다루지 않는다는 뜻입니다.

아래 층부터 보면 이렇습니다. 맨 아래 층은 엔지니어가 자기 노트북에서 클로드 코드·코덱스 같은 도구를 그대로 쓰는 ‘원시 세션’, 그 위는 여기에 사내 스킬 3,600여 개를 붙인 ‘스킬 세션’입니다. 세 번째 층에는 우버 클라우드에서 어떤 스킬이든 대신 실행해 주는 범용 에이전트, 맨 위 층은 코드 리뷰·PR 생성처럼 일감이 좁게 정해진 특화 매니지드 에이전트입니다. 위로 갈수록 ‘리뷰 1건당 비용’처럼 돈을 일의 단위에 대응시킬 수 있어서 통제력이 커집니다.

우버는 이 공장의 지출을 방정식 하나로 분해합니다. 사용자 수 × 사용자당 세션 수 × 세션당 턴 수 × 턴당 요청 수 × 요청당 토큰 × 토큰당 가격, 이렇게 여섯 항을 곱한 구조죠.

앞의 두 항은 도입과 참여를 나타내므로 오히려 계속 키워야 할 값입니다. 최적화 표적은 가운데 세 항, 즉 세션당 턴 수, 턴당 요청 수, 요청당 토큰이고요. 마지막 항인 토큰당 가격은 벤더가 정하는 값이니 별도로 대응합니다. 우버는 이 세 개 항을 “엔지니어가 실제로 요청한 것 위에 에이전트가 스스로를 위해 수행하는 작업”이라고 표현합니다. 에이전트가 더 빨리 계획하게 하고 불필요한 턴과 오류를 줄이고 입력 토큰을 아끼는 메커니즘을 만드는 데 최적화 노력 대부분이 들어갑니다.

“AI 비용이 너무 비싸다”는 뭉툭한 문제를 이렇게 쪼개 놓으면 각 항마다 따로 재고 따로 고칠 수 있게 됩니다. 이제 나올 레버들은 전부 이 방정식의 특정 항을 겨냥한 것들입니다.

3. 내게 맞춰 만든 벤치마크로 고르는 모델

토큰당 가격은 벤더가 정하는 값이라 손댈 수 없어 보입니다. 그러나 우버는 포기하지 않고, 어느 모델이 어느 워크로드를 돌릴지를 고르는 쪽으로 접근합니다. 기준은 파레토 효율입니다. 한쪽을 포기하지 않고는 다른 쪽을 더 좋게 만들 수 없는 상태를 뜻하는 말인데요. 쉽게 말해 ‘이것보다 싸면서 동시에 더 좋은 대안이 없는 모델’만 후보로 남긴다는 얘기입니다. 우버는 이 효율을 완료 작업당 비용과 산출 품질, 모델 신뢰성 세 가지로 잽니다.

방식 자체는 단순합니다. 그 에이전트의 실제 작업으로 벤치마크를 만듭니다. 그다음 최상위 모델이든 오픈웨이트 모델이든 하나의 인터페이스 뒤에서 돌릴 수 있는 하네스에 에이전트를 태우고, 파레토 최적인 모델로 옮깁니다. 그렇게 계속 옮깁니다. 최고가 몇 주마다 바뀌니까요.

모든 PR의 AI 코드 리뷰를 맡는 uReview가 좋은 예입니다. 알려진 버그가 있는 실제 PR들로 벤치마크를 만들어 난이도를 easy·medium·hard로 나누고 그 버그를 얼마나 잡아내는지 정밀도(지적한 것 중 진짜 버그의 비율), 재현율(전체 버그 중 잡아낸 비율), F1(둘을 하나로 합친 점수)로 채점합니다. 리뷰당 비용과 지연시간, 타임아웃, 노이즈(버그가 아닌데 지적하는 잘못된 리뷰)도 같이 재고요.

공개된 그래프 기준으로 우버는 모델을 갈아타며 F1을 끌어올리는 동시에 PR당 비용을 크게 줄였습니다. 대형 모노레포의 실제 PR 수천 건으로 만든 ‘우버 SWE 벤치마크’도 따로 운영하면서 모든 SDLC(소프트웨어 개발 수명 주기) 매니지드 에이전트의 모델 선정에 썼다고 합니다.

사람이 직접 모델을 고르는 인터랙티브 세션에서는 토큰 단가가 고정이지만 어떤 모델에 토큰이 흘러가는지, 그 분배는 관리할 수 있습니다. 이 분배를 좌우하는 기본 설정이 둘 있는데 초기 세션 모델과 서브에이전트 모델입니다.

그중 서브에이전트 기본값이 가장 효과가 큰 레버로 판명됐다고 해요. 모델이 좋아질수록 멀티에이전트 오케스트레이션이 잘 굴러가서 서브에이전트를 띄우는 세션 비율이 꾸준히 느는 만큼 이 레버의 중요도도 계속 커지고 있고요. 서브에이전트가 받는 일은 보통 입력이 분명하며 잘 정의된 작업이라 프론티어급 추론이 필요 없는 경우가 많습니다. 그래서 필요하면 수동으로 바꿀 길은 열어 두되 기본값을 더 싸고 가벼운 모델로 잡았습니다. 주 모델이 작업을 쪼개고 평가하고 서브에이전트가 실행하는 분업이죠.

4. 진짜 낭비는 매 턴 다시 보내는 것들로부터

에이전트와 나누는 대화는 매 턴, 즉 질문과 응답이 한 번 오갈 때마다 전체 대화 이력과 프로젝트 컨텍스트, 도구 결과를 다시 전송합니다. 그래서 요청 하나의 페이로드를 줄이는 조치는 그 한 번으로 끝나지 않고 세션 전체에 복리로 쌓입니다. 우버가 손댄 레버 여럿이 이 반복 전송분을 겨냥합니다.

우선, 하네스 기본값부터 두 개를 표준화했습니다. 하나는 40만 토큰에 도달하면 자동으로 컴팩션(대화 이력 압축)을 트리거하는 것. 컨텍스트 윈도가 100만 토큰인 모델이라도 예외가 아닙니다. 모델 성능과 반복 입력 토큰 비용 사이의 균형점이 그 언저리라는 판단 때문입니다. 실제로 플릿(운영 중인 에이전트 전체) 단위로 요청당 입력 토큰이 의미 있게 줄었다고 하고요. 다른 하나는 추론 강도 기본값을 Medium으로 두는 것입니다. 내부 추론을 포함한 출력 토큰은 입력의 몇 배 요율로 과금되는 최고 비용 카테고리거든요.

프롬프트 캐시 TTL(캐시 유지 시간)도 사용 패턴에 맞춰 조정했습니다. 앞선 컨텍스트를 캐싱해 두면, 그러니까 같은 내용을 다시 보낼 때 벤더 서버가 저장해 둔 것을 재사용하게 하면, 이후 읽기는 표준 입력 요율의 0.1배로 떨어집니다.

그런데 엔지니어들은 인터랙티브 세션을 5분 이상 놀리는 일이 잦았고요. 이 유휴 공백이 캐시를 무효화해 비싼 전액 컨텍스트 재구축을 강제하고 있었죠. 그래서 우버는 인터랙티브 세션을 1시간 캐시로 전환합니다. 다만 캐시에 써넣는 비용은 1시간짜리가 5분짜리보다 비쌉니다. 따라서 애초에 짧은 작업만 맡아 공백이 길어질 일 없는 서브에이전트는 기존 5분 TTL을 그대로 뒀고요.

그다음이 MCP(Model Context Protocol) 스키마입니다. 우버의 MCP 상호작용은 내부·서드파티 합쳐 1,000개가 넘는 서버를 아우르는 통합 게이트웨이를 거칩니다. 그런데 표준 MCP는 그 세션에서 쓰든 말든 설치된 도구 스키마를 전부 세션에 로드합니다. 도구가 100개를 넘으면 초기 프롬프트에 스키마만 5만~7만 토큰이 얹히고 이게 매 턴 재전송됐다고 해요.

처방은 둘입니다. 하나는 CLI 도구 해석입니다. MCP 직접 통합을 터미널에서 입력하는 셸 커맨드 실행으로 바꿔, 호출 시점에 게이트웨이에서 필요한 도구를 해석하게 하는 방식입니다. 이걸로 1,000개 넘는 MCP 도구 전부를 CLI 커맨드로 투영해 스키마를 컨텍스트에서 들어냈습니다. 다른 하나는 도구 검색으로, 모델이 도구 카탈로그를 검색해 필요한 것만 그때그때 로드하게 했습니다.

여기서 한 발 더 나간 게 코드 모드입니다. 표준 MCP 워크플로는 액션마다 별도의 모델 턴이 필요합니다. 예컨대 SQL 쿼리 하나를 돌리려면 요청을 내고, 작업이 끝났는지 2~5회 되물어 확인(폴링)하며 출력을 회수하는 멀티턴이 되죠. 코드 모드는 이 흐름 전체를 자동화된 파이썬 루프 하나로 흘려보내 폴링을 모델의 활성 컨텍스트 밖에 둡니다.

그 구조 아래에서 같은 SQL 쿼리들을 기존 경로와 새 경로로 각각 돌려 재봤더니 결과셋이 아주 작은 경우에도 토큰이 50% 이상 줄었습니다. 큰 데이터 페이로드를 우회해서가 아니라 스키마 초기화, 멀티턴 폴링, 중복된 단계별 추론 같은 오버헤드가 사라진 덕분이고요. 모델 턴 N번이 스크립트 하나가 되는 대량 워크플로에서는 절감이 90% 이상으로 커집니다. 우버는 많이 쓰는 MCP 서버들에 대해 25개 넘는 코드 모드 스킬을 미리 만들어 배포해 뒀습니다.

외부 업체의 구독형 소프트웨어, 즉 서드파티 SaaS의 MCP는 더 골치였다고 합니다. 벤더는 고객별 사용 패턴을 알 수 없으니 제품 기능 전체를 노출하도록 서버를 설계하거든요. 어느 워크스페이스 스위트는 서버 하나에 도구 49개, 스키마만 약 2만 2,000토큰이고 메시징·프로젝트 트래킹 벤더도 각각 34개, 46개를 실어 보냅니다. 이런 서버 두세 개만 붙이면 사용자가 프롬프트를 입력하기도 전에 에이전트가 편집할 파일보다 많은 스키마를 짊어지는 셈이죠. 우버는 이것들도 똑같이 게이트웨이를 거치게 라우팅하고, CLI로 노출하고, 서버별 공통 워크플로는 전용 스킬로 감쌌습니다.

5. 맥락 없는 에이전트는 느리고 비싸다

그라운딩(grounding)은 에이전트가 답을 지어내지 않도록 회사의 실제 데이터와 맥락, 이를테면 어떤 테이블과 서비스와 문서가 있는지에 발을 딛게 하는 일입니다. 반대로 그라운딩되지 않은 에이전트는 “한 군데만 더 찾아보겠다”며 점점 커지는 컨텍스트 윈도를 반복 전송합니다. 그래서 우버는 더 풍부한 정보를 선제 제공하는 것이 이 탐색 오버헤드를 줄이는 가장 강력한 레버라고 말합니다.

수억 줄의 코드와 수천 개의 테이블로 이뤄진 우버 환경에서 에이전트는 턴 대부분을 코드 생성이 아니라 정보 위치 찾기에 씁니다. 탐색이 가장 큰 낭비를 불러온다는 얘기죠. 이걸 잡으려고 만든 것이 ‘AI 컨텍스트 그래프’입니다. 서비스, 엔지니어링 팀, 인시던트 로그, PR, 아키텍처 설계 문서, 배포, 데이터셋, 과거 테이블 사용 쿼리까지 내부 시스템 30여 개의 데이터를 2,400만 노드와 8,000만 엣지로 엮은 통합 네트워크인데요. 노드 타입만 86가지, 엣지 타입은 117가지에 이르고 어떤 에이전트든 자연어로 질의할 수 있습니다.

효과를 보여주는 대조 일화도 실려 있습니다. 그라운딩된 에이전트는 과거 사용 이력을 질의해 분석가 50여 명이 쓰는 테이블을 짚어내고 38초 만에 답을 냈습니다. 그라운딩되지 않은 에이전트는 같은 질문을 받고도 그 테이블을 볼 수 없어 서비스 코드를 20분간 뒤지고 서브에이전트 2개를 띄우고 오류를 3번 겪은 끝에 “이 데이터셋은 질의할 수 없다”는 오답을 냈고요.

6. 가시성을 올려 토큰 낭비를 막는 구조

이만큼 최적화에 진심이면 지출 상한도 빡빡하게 걸었을 법한데 우버는 엄격한 상한을 강제하는 대신 실시간 추적과 넛지(강제하는 대신 슬쩍 알려서 행동을 바꾸게 하는 방식)를 골랐습니다.

터미널 상태 줄, 즉 명령창 하단의 정보 표시 줄에는 진행 중인 세션 비용이 실시간 카운터로 항상 떠 있습니다. 예산은 도구별로 쪼개지 않고 모든 인터랙티브 하네스를 아우르는 공유 티어(예산 등급) 하나로 묶었고요. 예상 지출의 50%, 80%, 100%에 닿으면 슬랙 알림이 가서 엔지니어가 계획을 세울 시간을 법니다. 티어를 올려야 하면 매니저 승인으로 빠르게 처리되고, 요청하면 즉시(온디맨드) 비용을 분해해 보여주는 스킬도 있습니다.

상태 줄이 총액을 보여준다면 비용이 왜 나갔는지는 세션 분석 대시보드가 맡습니다. 이 대시보드는 런타임에 내장돼 있어 설정도, 사용자가 직접 켜는 옵트인도 필요 없습니다. 사용자가 쓰는 모든 하네스의 세션 트레이스(세션에서 오간 요청·응답 기록)를 분석해 흔히 저지르는 비효율적인 습관, 즉 안티패턴 16가지를 찾아냅니다. 안티패턴마다 금전적 영향과 표적 처방이 붙는데요. Sonnet으로 충분한 단순 세션을 Opus에서 돌리는 ‘부적절한 모델 라우팅’, 40KB짜리 MCP 응답이 컨텍스트에 남아 턴마다 반복 과금되는 ‘컨텍스트 윈도 비대’ 같은 것들입니다.

폭주 지출은 억제하되 작업의 ROI 판단은 엔지니어에게 맡긴다는 게 우버의 설명입니다. 통제 장치를 늘리는 대신 판단 재료를 주는 설계인 셈이죠.

마치며

여기까지 살펴본 우버 엔지니어링 팀의 에이전트 운영 구조에는 하나하나 깊은 고민의 흔적이 역력합니다. 무작정 사용을 막는 것보다는 AI의 생산성은 최대한 끌어올리되, 시스템으로 낭비를 막은 거죠. 매 턴 다시 전송되는 스키마, 컨텍스트 안에서 돌던 폴링, 답을 찾아 헤매던 탐색 구조. 이처럼 아무 가치도 만들지 않는 토큰을 하나씩 걷어낸 결과입니다. 우버는 치솟는 AI 코딩 비용 역시 풀 수 있는 엔지니어링 문제라고 결론 내립니다.

방향도 분명합니다. 인터랙티브 개발자 워크플로에서 완전 매니지드 에이전트로 무게중심을 옮기는 것. 전용 벤치마크와 파레토 효율 모델을 짝지은 특화 에이전트를 최적화하는 편이 엔지니어 수천 명의 터미널 세션을 하나하나 최적화하는 것보다 확장하기 좋다는 판단입니다. 앞으로는 벤치마크 커버리지를 넓혀 동적 모델 라우팅을 지원하고, 세션 분석도 주기적 배치 탐지에서 실시간 가이드로 진화시키겠다고 합니다.

꼭 우버처럼 큰 팀이 아니어도 에이전트를 쓰는 팀이라면, 아니 개인 그 누구라도 배울 것이 가득합니다. 비용을 방정식으로 쪼개 항목별로 재는 습관, 남들이 좋다는 것 대신 내 업무 벤치마크로 선택하는 모델, 상한으로 막기보다 가시성을 올려 낭비를 막는 태도 같은 것들이요. 에이전트 군단은 어느 회사에서든 앞으로 더 늘어날 겁니다. 그 비용이 점점 무서워지기 시작했다면 우버처럼 일단 방정식부터 쪼개보는 게 어떨까요?

이 글은 AI의 도움을 받아 작성했습니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.