PR 70퍼센트가 에이전트에서 나온다 - 우버가 토큰 낭비를 지워 7배 확장한 비용 방정식

PR 70퍼센트가 에이전트에서 나온다

TL;DR

• 도입 규모가 먼저 제시된다. AI 도구가 우버의 모든 소프트웨어 개발 단계에 이제 박혀 있고, 풀 리퀘스트의 70퍼센트 넘는 비율이 로컬 또는 클라우드 에이전트에 귀속된다. 엔지니어들은 개발 생애주기 전반에 3,600개가 넘는 에이전트 스킬을 만들었고 하루 3만 회 넘는 스킬 실행이 일어난다.
• 성장과 비용이 갈렸다. 2월부터 8월 중순까지 전 직원의 주간 활성 사용자가 7배, 주간 에이전틱 요청이 9.4배 늘었는데 총 AI 지출은 4월 이후 상대적으로 안정됐다. 모델을 하나로 고정해 자체 최적화 이득만 분리하면 모델 요청 1,000회당 비용이 정점 대비 34퍼센트 가까이, 세션당 비용이 6월 정점 대비 52퍼센트 내려갔다.
• 방법론의 핵심은 분해인데 에이전틱 세션 비용을 서로 곱해지는 여섯 항으로 나눈다. 앞의 두 항은 도입과 참여라서 계속 키우고 싶은 값이고, 가운데 세 항이 최적화 기회인데 엔지니어가 실제로 한 요청 위에 에이전트가 자기 자신을 위해 하는 일이며 여기에 노력의 대부분이 들어간다.
• 가장 인상적인 측정은 코드모드다. 똑같은 SQL 5개를 두 경로로 돌려 토큰을 셌더니 넓은 테이블 SELECT가 1,431,594 대 900이었다. 응답 크기 제한을 한참 밑도는 최소 결과 집합에서도 절반 넘게 줄었고, 절약은 큰 데이터를 우회해서가 아니라 스키마 초기화와 다중 턴 폴링, 중복된 단계별 추론을 제거해서 생긴다.
• 결론이 전략 전환으로 정리되는데 상호작용형 개발자 워크플로에서 완전 관리 에이전트로 옮기는 것이다. 근거는 규모 논리다. 각자 전용 평가 벤치마크와 파레토 효율 모델을 짝지은 특화 관리 에이전트 함대를 최적화하는 것이, 수천 명 엔지니어의 개별 터미널 세션을 최적화하는 것보다 본질적으로 더 비용 효율적이고 확장 가능하다.

Source

Running a Software Factory Efficiently at Uber Scale — Uday Kiran Medisetty, Uber Engineering Blog, 2026년 8월 27일

[uber.com/blog/efficient-software-factory](https://www.uber.com/kr/en/blog/efficient-software-factory/)

Knowledge

사람이 시작하지 않는 세션이 늘고 있다

도입 상황이 수치로 먼저 나온다. AI 도구는 우버에서 소프트웨어 개발의 모든 단계에 이제 박혀 있고 풀 리퀘스트의 70퍼센트가 넘는 비율이 로컬 또는 클라우드 에이전트에 귀속된다. 엔지니어들은 소프트웨어 개발 생애주기 전반에 3,600개가 넘는 에이전트 스킬을 만들었고 하루 3만 회가 넘는 에이전트 스킬 실행이 이뤄진다.

그런데 더 중요한 변화는 세션을 누가 시작하는지에 있다. AI Engineer 2026 컨퍼런스에서 소프트웨어 팩토리 비전과 생애주기 전반의 구성 블록, 관리 에이전트를 공유했는데, 그 비전을 진행하면서 사람이 개시하지 않는 세션의 비중이 커지고 있다. 자동화된 관리 에이전트가 코드 리뷰를 처리하고 CI 실패를 자기 치유하고 시각적 검증까지 붙은 종단간 PR을 완성하고 온콜 알림을 분류하고 들어오는 버그를 디버깅하고 다양한 코드 유지보수 작업을 사람 검토와 에스컬레이션과 함께 처리한다.

성장과 비용의 관계가 이 글의 출발점이다. 2월부터 8월 중순까지 모든 에이전틱 제공물에 걸친 전 직원의 주간 활성 사용자가 7배 늘었고 주간 에이전틱 요청은 9.4배 늘었다. 도구 간 중복 사용자는 제거한 수치다. 그런데 총 AI 지출은 4월 이후 전반적인 최적화 덕분에 상대적으로 안정됐다.

측정 방법에 대한 조건도 명시된다. 도입과 작업 부하 구성, 모델 업그레이드가 모두 계속 변하므로 자체 최적화 이득만 분리하려면 모델 하나를 고정해야 한다. 업그레이드와 모델 계열마다 행동이 달라지기 때문이다. 2월부터 7월까지 그렇게 했더니 모델 요청 1,000회당 비용이 정점 대비 34퍼센트 가까이 내려갔고 세션당 비용은 6월 정점 대비 52퍼센트 내려갔다. 세션당 비용 데이터는 5월 말부터 시작한다.

비교의 근거도 밝힌다. 이 비교의 모든 가격과 벤더 지표는 공개된 정보에 기반하고 비용 효율 이득은 표준 계층 가격 안에서 내부 우버 작업 부하를 더 영리하게 라우팅한 결과다. 측정한 특정 비용 절감은 우버 환경에 고유하고 코드베이스와 팀 규모, 에이전트 워크플로에 따라 결과가 다를 수 있지만 실제 작업을 벤치마킹하고 정확도와 비용을 함께 최적화하는 방법론 자체는 보편적으로 적용된다는 것이다.

네 계층과 곱해지는 여섯 항

AI 사용을 가장 특화된 것부터 가장 일반적인 것까지 네 계층으로 조직한다. 그리고 계층이 높을수록 비용과 품질, 모델 선택에 대한 통제력이 커진다.

비용 방정식이 이 글의 골격이다. 위 계층 어디서든 에이전틱 세션 비용을 여섯 항으로 분해할 수 있고 이 항들은 서로 곱해지며 각각 독립적으로 측정하고 최적화할 수 있다. 앞의 두 항은 도입과 참여를 나타내고 사용자가 상호작용으로 쓰든 에이전트가 대신 작업을 처리하든 전체 사용자 기반에서 계속 키우고 싶은 값이다.

최적화 대상은 가운데 세 항이다. 엔지니어가 실제로 한 요청 위에 에이전트가 자기 자신을 위해 하는 일이라고 규정된다. 노력의 대부분이 여기 들어가고 에이전트가 더 빨리 계획하도록 돕고 원치 않는 턴이나 오류를 줄이고 입력 토큰을 최적화하는 기제들이 포함된다.

무엇을 매주 세는가

주간과 월간으로 추적하는 지표 전체가 계층별로 제시된다. 단기와 장기 노력을 예측하고 계획할 수 있게 하는 것들이다.

포트폴리오 계층에서는 총 귀속 비용, 구별되는 귀속 사용자, 도구와 에이전트별 비용·사용자·지출 비중을 본다. 돈이 어디로 가는지, 어느 도구가 움직였는지에 답한다.

도구별 단위 경제성 계층은 목록이 길다. 사용자당 비용, 사용자당 요청, 요청 1,000회당 비용, 요청당 입력·출력·총 토큰, 100만 토큰당 비용, 세션 1,000회당 비용, 활성 세션 시간당 비용, 프롬프트 캐시 적중률이다. 도구가 실제로 싸지고 있는지, 아니면 사용량이 그냥 이동한 것인지에 답한다.

모델 경제성 계층은 모델별로 비용과 비용 비중, 요청과 요청 비중, 요청 1,000회당 비용, 100만 토큰당 비용을 본다. 토큰당 가격이 같든 다르든 어느 모델 출시가 실제로 청구서를 바꿨는지에 답한다.

드라이버 분해 계층이 특히 엄격하다. 비용 변화를 순차적으로 도입, 참여, 입력 작업 부하, 출력 작업 부하로 분해한다. 각각 사용자 수, 사용자당 요청, 요청당 입력 토큰, 요청당 출력 토큰이다. 숫자가 왜 움직였는지를 정확히 진술하고 설명되지 않은 잔차에 아무것도 남기지 않는 것이 목표다.

관리 에이전트 결과 계층은 단위를 결과로 바꾼다. 에이전트마다 결과 기준 비용을 재는데, 병합된 PR당 비용, 리뷰당 비용, 알림당 비용, 정리 작업당 비용이다. 품질 신호로는 되돌림 비율과 F1, 평균 복구 시간을 보고 물량으로는 반영된 디프와 게시된 리뷰, 분류된 알림을 본다. 각 관리 에이전트가 전달하는 가치 단위당 싸지고 있는지, 그리고 모델 이전을 거쳐도 품질이 유지되는지에 답한다.

벤더가 가격을 정하고 우리는 배치를 정한다

토큰당 가격 최적화의 전제가 분명하다. 벤더가 토큰 가격을 정하고 우리는 어느 모델이 어느 작업 부하를 돌릴지 고른다. 모든 관리 에이전트 계층에서 그 작업 부하에 가장 파레토 효율적인 모델을 고른다. 여기서 파레토 효율은 완료된 작업당 비용, 출력 품질, 모델 신뢰성을 뜻한다.

모델 선택은 운영하는 모든 관리 에이전트에서 같은 네 단계를 따른다. 에이전트의 실제 작업으로 벤치마크를 만들고 프런티어든 오픈 웨이트든 어떤 모델이든 하나의 인터페이스 뒤에서 제공하는 하네스에서 에이전트를 돌리고 파레토 최적인 것으로 옮기고 계속 옮기는 것이다. 이유가 붙는다. 프런티어는 몇 주마다 이동한다.

실제 사례가 uReview다. 모든 풀 리퀘스트의 AI 코드 리뷰를 처리하는 에이전트이고 벤치마크를 알려진 버그가 있는 실제 풀 리퀘스트로 만들어 쉬움과 보통, 어려움으로 등급을 매겼다. 그 버그들에 대해 정밀도와 재현율, F1을 채점하고 리뷰당 비용과 지연, 타임아웃, 노이즈를 함께 본다. 결과는 모델을 바꾸자 F1이 개선되면서 PR당 비용이 극적으로 줄었다는 것이다. 그림의 점선이 파레토 프런티어이고 그 아래와 왼쪽에 있는 모든 것은 더 싸거나 더 좋은 무언가에 진 것이다.

별도의 자체 벤치마크도 있다. 대규모 모노레포에 걸친 수천 개 실세계 PR을 써서 프런티어와 오픈 웨이트 모델을 여러 작업 유형에서 돌리는 Uber SWE 벤치마크이고 모든 생애주기 관리 에이전트의 모델 선택을 이것으로 결정한다.

기본 모델 설정에서 가장 큰 레버가 뜻밖의 곳에 있다. 상호작용형 인터페이스에서는 토큰 단위 비용이 고정이지만 모델 간 토큰 분포는 전략적으로 관리할 수 있고 그 분포를 지배하는 기본 설정이 둘이다. 최초 세션 모델과 서브에이전트 모델이다. 그중 서브에이전트 기본값이 가장 영향력 큰 레버로 입증됐고 그 중요성이 계속 커지고 있다. 최신 모델 능력이 더 효과적인 다중 에이전트 조율을 가능하게 하면서 서브에이전트를 개시하는 세션 비율이 꾸준히 늘었기 때문이다. 근거가 작업 성격에 있다. 서브에이전트는 명시된 입력으로 잘 정의된 작업을 수행하고 프런티어급 추론이 필요하지 않은 경우가 많으므로, 더 약하고 비용 효율적인 모델을 기본값으로 두면서 수동 재정의는 허용한다. 주 모델이 작업 분해와 평가를 맡고 서브에이전트가 실행을 맡는 구조다.

매 턴이 전체 대화를 다시 보낸다

요청당 토큰 최적화의 전제가 이것이다. 매 턴이 전체 대화 이력과 프로젝트 컨텍스트, 도구 결과를 다시 보낸다. 요청당 페이로드를 줄이는 것은 무엇이든 세션 전체에 복리로 쌓인다.

기본값 두 개가 직접 토큰 소비를 줄인다. 모든 상호작용형 하네스가 설치 관리와 설정, 인증, 비용 가시성을 위해 통합 래퍼를 쓰는데 여기에 표준 기본값이 들어간다. 첫째는 자동 압축을 100만 컨텍스트 창 모델에서도 40만 토큰에서 발동하는 것이다. 이 임계값이 모델 성능과 캐시 폭증, 반복되는 입력 토큰 비용 사이의 균형을 잡고 측정 결과 함대 전체의 요청당 입력 토큰이 유의미하게 줄었다. 둘째는 추론 노력을 기본 중간으로 두는 것이다. 근거가 가격 구조에 있다. 내부 추론 토큰을 포함한 출력 토큰은 주요 모델에서 입력 토큰의 몇 배로 청구되므로, 이 정책 조정이 가장 비싼 토큰 범주의 지출을 직접 줄인다. 상당한 범주의 작업에서 중간 추론이 비용과 품질의 좋은 균형점을 찍는다.

프롬프트 캐싱 전략은 공급자 캐시 읽기와 쓰기의 경제성에서 나온다. 매 턴이 전체 대화 이력을 재전송하므로 앞선 컨텍스트를 캐시하면 전액을 반복 지불하지 않고 이후 읽기를 표준 입력 토큰 요율의 0.1배로 줄인다. 그런데 쓰기 할증이 다르다. 5분 캐시 항목은 1.25배, 1시간 항목은 2배다. 그래서 최적 유효 기간 선택이 턴 사이 공백의 길이에 달려 있다. 가용 옵션은 앤스로픽의 5분과 1시간, 그리고 OpenAI의 30분이다.

선택 결과가 사용 패턴에서 나온다. 엔지니어가 상호작용 세션을 5분 넘게 놀려 두는 일이 많으므로 기본 5분 유효 기간에서 1시간 창으로 옮겼다. 이 잦은 유휴 공백이 이전에는 접두사 캐시를 무효화해 값비싼 전액 컨텍스트 재구축을 강제했기 때문이다. 반면 서브에이전트는 5분 유효 기간을 유지한다. 실행 초점이 단일하고 짧게 사는 작업에 한정되기 때문이다.

도구 스키마가 편집 중인 파일보다 무겁다

MCP 처리 방식이 구체적이다. 우버의 모든 MCP 상호작용은 통합 게이트웨이로 라우팅되고 이 단일 진입점이 내부와 제3자 SaaS MCP를 합쳐 1,000개가 넘는 MCP 서버를 포괄해 중앙 인증과 정책 집행을 가능하게 한다.

문제는 표준 MCP의 기본 동작이다. 엔지니어가 그 세션에서 호출할지 여부와 무관하게 모든 도구 스키마를 모든 세션에 적재한다. 100개가 넘는 도구가 설치된 경우 이 사전 적재가 초기 프롬프트에 대략 5만에서 7만 토큰의 스키마 부담을 더했고 그것이 이후 모든 컨텍스트 턴에서 다시 전송됐다.

이 컨텍스트 팽창에 두 보완 기제를 도입했다. 하나는 CLI 도구 해석이다. 직접 MCP 통합을 대체해 모델이 셸 명령을 실행하게 하고 CLI가 호출 시점에 게이트웨이를 상대로 필요한 도구를 동적으로 해석해 호출하므로 우버 MCP 스키마가 세션 컨텍스트에서 사라진다. 내부 MCP 게이트웨이의 1,000개가 넘는 도구 전부가 CLI 명령으로 투영된다. 다른 하나는 도구 검색이다. 모델이 도구 카탈로그를 검색해 필요한 도구만 요청 시점에 적재하게 해 수천 개 도구로 확장한다. 이 방식이 컨텍스트 팽창을 완화하고 도구 라이브러리가 커져도 높은 선택 정확도를 유지해 큰 도구 집합에 따르는 성능 저하를 막는다.

폴링을 모델의 컨텍스트에서 빼낸다

코드모드는 도구가 셸 명령으로 함수를 직접 호출할 때 모델이 여러 동작을 하나의 스크립트로 묶을 수 있다는 점을 이용한다. 이 묶음은 수다스러운 도구 프로토콜에 특히 유리하다. 표준 MCP 워크플로에서는 동작마다 별도의 모델 턴이 필요해 요청을 내보내고 원시 응답을 컨텍스트 창에 적재하고 결과를 순차 처리한다. SQL 질의 하나만 실행해도 요청을 제출하고 상태를 2회에서 5회 폴링하고 출력을 가져와야 한다. 코드모드는 이 전체 흐름을 자동화된 파이썬 루프로 간소화해 중간 폴링을 모델의 활성 컨텍스트 밖에 둔다. 왼쪽 그림에서는 모델이 폴링 루프에 참여하고 모든 응답이 컨텍스트에 들어오고 오른쪽에서는 루프가 서브프로세스에서 돌고 요약만 돌아온다.

측정은 같은 세션에서 동일한 SQL 5개를 두 경로로 돌려 했다. 클로드 코드 세션에서 잰 질의당 토큰이다.

질의	LLM 도구 사용	코드모드	절감
SELECT 1 (1행)	903	402	55%
COUNT(*) (1행)	954	403	58%
GROUP BY LIMIT 20 (20행)	1,600	457	71%
SHOW COLUMNS (175행)	2,200	900	59%
SELECT * 넓은 테이블 (50행)	1,431,594	900	~100%

해석이 중요하다. 처음 세 행이 주요 발견을 드러낸다. 응답 크기 제한을 한참 밑도는 최소 결과 집합에서도 코드모드가 토큰 사용을 50퍼센트 넘게 줄인다. 큰 데이터 페이로드를 우회해서가 아니라, 스키마 초기화와 다중 턴 폴링, 중복된 단계별 추론을 포함한 불필요한 부담을 제거한 데서 효율이 나온다. 대량 워크플로는 효과를 복리로 만든다. N번의 모델 턴이었을 루프가 하나의 스크립트가 되므로 절감이 90퍼센트를 넘게 쌓인다. 가장 많이 접근하는 MCP 서버들에 대해 미리 만든 코드모드 스킬 25개 이상을 배포해 표준 워크플로가 기본적으로 가장 비용 효율적인 경로를 타게 했다.

제3자 소프트웨어가 내부 서버보다 훨씬 까다로웠다는 서술이 이어진다. 벤더는 특정 고객의 사용 방식을 예상할 수 없으므로 제품 능력 전체를 노출하도록 MCP 서버를 설계한다. 어떤 워크스페이스 스위트는 도구 49개를 서버 하나에 묶어 약 2만 2,000 토큰의 스키마를 요구하고 메시징과 프로젝트 추적 벤더는 각각 34개와 46개 도구를 실어 보낸다. 그래서 결과가 이렇게 표현된다. 벤더 서버 두세 개를 적재하면 사용자가 프롬프트를 입력하기도 전에 에이전트가 편집 중인 파일보다 많은 스키마 부담을 지고 있게 된다. 대응은 내부 MCP와 같은 기제다. SaaS MCP 서버도 MCP 게이트웨이로 라우팅하고 모든 에이전틱 표면이 호출할 수 있는 CLI로 노출하며 서버마다 코드모드 플러그인 안에 전용 스킬을 작성해 흔한 워크플로를 캡슐화한다.

근거 없는 에이전트는 싸게 실패하지 않고 느리게 실패한다

턴당 요청 최적화의 진단이 이 문장이다. 근거 없는 에이전트는 싸게 실패하는 대신 느리게 실패하며 한 곳을 더 찾으려고 팽창하는 컨텍스트 창을 반복해서 보낸다. 더 풍부한 정보를 미리 제공하는 것이 이 검색 부담을 줄이는 가장 강력한 단일 레버로 남아 있다.

그래서 만든 것이 AI 컨텍스트 그래프다. 수억 줄 코드와 수천 개 테이블로 이뤄진 방대한 코드베이스와 데이터 생태계에서 에이전트는 코드를 생성하기보다 정보를 찾는 데 대부분의 턴을 쓴다. 컨텍스트 그래프는 노드 2,400만 개와 엣지 8,000만 개를 담고 노드 유형 86종, 엣지 유형 117종으로 구성된 통합 네트워크다. 30개가 넘는 내부 시스템의 데이터를 통합하는데 서비스, 엔지니어링 팀, 장애 로그, 풀 리퀘스트, 아키텍처 설계 문서, 배포, 데이터셋, 과거 테이블 사용 질의가 포함되고 어떤 에이전트든 자연어로 질의할 수 있다.

효과가 같은 프롬프트를 같은 모델에 넣은 비교로 제시된다. 근거를 가진 에이전트는 과거 사용을 질의해 50명이 넘는 분석가가 쓰는 특정 테이블을 식별하고 38초에 답을 냈다. 반대로 근거 없는 에이전트는 그 테이블을 볼 수 없었고 20분 동안 서비스 코드를 살피며 서브에이전트 2개를 띄우고 오류 3건을 맞은 뒤 그 데이터셋이 질의 불가라고 잘못 결론지었다.

상한을 걸지 않고 보이게 한다

가시성과 교육 영역의 레버는 엔지니어와 에이전트가 더 빨리 수렴하도록 돕는 가시성과 피드백 루프다. 하네스 상태줄에 실시간 비용 계수기를 넣어 하네스별 실시간 지출과 사용자별 전체 하네스 합계를 추적한다.

엄격한 상한을 부과하지 않기 위해 실시간 지출 추적과 자동 알림을 구현했다. 상태줄 실시간 계수기로 진행 중인 세션 비용이 터미널에 항상 보이고 하네스 풀은 도구별 예산이 아니라 모든 상호작용형 하네스에 걸친 하나의 공유 계층이며 관리 에이전트는 별도 계층을 쓴다. 슬랙 알림은 예상 지출의 50, 80, 100퍼센트에서 경보를 보내 엔지니어가 계획할 시간을 준다. 계층 상향은 매니저 승인 흐름으로 빠르게 전파되고 비용 확인 스킬과 팁으로 요청 시 비용 분해와 실시간 상태줄 코칭을 제공한다. 이것들이 엔지니어가 스스로 작업의 투자 대비 수익을 평가하게 하면서 폭주 비용을 막는다.

세션 분석 대시보드가 그 간격을 메운다. 상태줄은 세션 총지출을 보여 주지만 비용 동인이나 실행 가능한 효율 조치를 보여 주지 못하고 일반 지침은 고수준 원칙만 주며 개별 개발자 워크플로를 평가할 수 없다. 대시보드는 세션 산출물을 직접 검사해 이 간격을 메운다. 런타임에 직접 내장돼 설정이나 사전 동의가 필요 없고 비용 대시보드 스킬을 실행하면 사용자가 쓰는 모든 하네스의 로컬과 원격 클라우드 샌드박스에 걸친 모든 세션 추적을 분석한다.

결과를 집계 지표로 내지 않는다는 점이 핵심이다. 세션들에서 16가지 구별되는 안티패턴을 잡아내고 각각에 재무적 영향과 표적화된 시정 조치를 짝지어 준다. 범주 일부가 예시로 나온다. 차선의 모델 라우팅은 소네트로 충분히 될 단순한 다중 턴 세션을 오퍼스에서 돌리는 경우다. 컨텍스트 창 팽창은 예컨대 40킬로바이트 응답 같은 큰 MCP 페이로드가 컨텍스트에 남아 이후 턴마다 반복 청구되는 경우다. 캐시 만료 비효율은 긴 휴지 뒤 세션을 재개해 만료된 프롬프트 캐시가 전액 접두사 재구축을 강제하는 경우다. 프롬프트 초기화 부담은 사용자 입력이 주어지기 전에 시스템 지시와 도구 정의 10만 토큰을 사전 적재하는 경우다.

다음에 하려는 것

진행 중인 계획이 다섯 가지로 정리된다. 관리 에이전트 함대를 키우는 것인데, 새 에이전트마다 목표 결과 지표를 세우고 평가 벤치마크를 모으고 파레토 최적 모델을 찾는 일관된 로드맵을 따르며 생애주기 각 단계를 팩토리 성숙도 모델에서 더 위로 올리는 것이 목표다. 동적 모델 라우팅은 다양한 프로그래밍 언어와 코드 저장소, 에이전트 양식에 걸쳐 벤치마크 범위를 넓히는 일이고 모델 능력이 크게 갈리므로 효과적인 라우팅이 포괄적 평가에 크게 의존한다는 근거가 붙는다.

나머지 셋도 방향이 분명하다. 컨텍스트 그래프 통합을 심화해 더 넓은 자율 에이전트 선택지에 그래프 질의 능력을 여는 것, 세션 분석을 실시간 개발자 안내로 진화시켜 안티패턴의 주기적 배치 탐지에서 지속적 추적 모니터링으로 옮겨 개인화된 실시간 효율 권고를 엔지니어에게 직접 전달하는 것, 그리고 지속적 스킬 개선으로 에이전트 스킬 실행에서 나온 자잘한 불편을 기록하고 수집된 추적에서 스킬 업데이트를 자동 생성하는 자동화된 방법을 만드는 것이다.

결론이 말하는 전환

결론의 첫 문장이 문제 규정이다. 늘어나는 AI 코딩 비용을 관리하고 억제하는 것도 다루기 가능한 엔지니어링 과제라는 것이다. 방법은 단위 가격을 낮추거나 도구를 격하하는 데만 의존하지 않고 낭비되는 가치 영의 토큰 소비를 제거하는 것이었고 그래서 사용량을 7배로 확장하면서 동시에 모든 지표에서 단위 비용을 줄이고 출력 품질을 개선하거나 유지했다.

핵심 전략 전환은 상호작용형 개발자 워크플로에서 완전 관리 에이전트로 옮기는 것이다. 생애주기 작업 부하를 관리 환경으로 이전하면 모델 라우팅과 실행 하네스, 운영 지출에 대한 완전한 통제권을 얻는다. 그리고 마지막 근거가 규모 논리로 제시된다. 각자 전용 평가 벤치마크와 파레토 효율 모델을 짝지은 특화 관리 에이전트 함대를 최적화하는 것이, 수천 명 엔지니어에 걸친 개별 터미널 세션을 최적화하는 것보다 본질적으로 더 비용 효율적이고 확장 가능하다는 것이다.

더 생각해보기

• 비용을 곱해지는 여섯 항으로 분해하고 앞의 두 항은 키우고 가운데 세 항만 줄인다는 구분은, 다른 조직이 그대로 쓸 수 있는 틀인가 아니면 우버 규모에서만 성립하는가.
• 서브에이전트 기본 모델을 약한 것으로 두는 레버가 가장 컸다는 발견은, 앞으로 다중 에이전트 조율이 늘수록 어디까지 유효한가.
• 잔차에 아무것도 남기지 않는다는 드라이버 분해 원칙은 실제 운영에서 어느 정도까지 지켜질 수 있는가.
• 코드모드가 최소 결과 집합에서도 절반 넘게 절감한다면, MCP 프로토콜 자체의 기본 설계가 잘못된 지점은 어디인가.
• 벤더 MCP가 도구 49개와 2만 2,000 토큰 스키마를 싣는 관행은 게이트웨이 없이 쓰는 조직에 어떤 비용을 조용히 전가하는가.
• 근거 없는 에이전트가 20분 동안 틀린 결론에 도달했다는 사례는, 컨텍스트 그래프 없이 에이전트를 도입한 조직의 실제 실패 양상을 어떻게 예고하는가.
• 상한 대신 가시성과 알림을 택한 선택은 지출 폭주를 실제로 막는가, 아니면 규모가 커지면 상한이 다시 필요해지는가.
• 16가지 안티패턴을 재무 영향과 함께 지목하는 방식은 개발자 행동을 바꾸는가, 아니면 대시보드로만 남는가.
• 관리 에이전트 함대 최적화가 개별 세션 최적화보다 확장 가능하다는 결론은, 엔지니어의 탐색적 작업 비중이 큰 조직에서도 성립하는가.