Uber 규모에서 소프트웨어 팩토리를 효율적으로 운영하기

https://www.uber.com/us/en/blog/efficient-software-factory/?uclick_id=2f9b151a-0a4b-4e6a-a58a-d0e2da90d79d

들어가며

Uber에서는 이제 소프트웨어 개발의 모든 단계에 AI 도구가 들어가 있습니다. 풀 리퀘스트의 70% 이상이 로컬 에이전트나 클라우드 에이전트가 만든 것으로 집계됩니다. 엔지니어들은 소프트웨어 개발 수명 주기 전반에 걸쳐 3,600개가 넘는 에이전트 스킬을 만들었고, 하루에 3만 건이 넘는 에이전트 스킬을 실행합니다.

AI Engineer 2026 컨퍼런스에서 저희는 소프트웨어 팩토리에 대한 저희의 비전과 함께, 개발 수명 주기 전반에 걸쳐 만들고 있는 구성 요소와 관리형 에이전트를 소개했습니다. 그 비전을 향해 나아가면서 사람이 시작하지 않는 세션의 비중이 점점 커지고 있습니다. 코드 리뷰를 하고, CI 실패를 스스로 고치고, 시각 검증까지 포함해 E2E 풀 리퀘스트를 완성하고, 온콜 알림을 분류하고, 새로 들어온 버그를 디버깅하고, 사람의 리뷰나 에스컬레이션을 거쳐 각종 코드 유지보수 작업을 처리하는 자동화된 관리형 에이전트가 그 세션을 대신 시작합니다.

그림 1에서 보듯이 2026년 2월부터 8월까지, 엔지니어와 비엔지니어를 모두 포함한 전체 직원 가운데 에이전트 제품을 쓰는 주간 활성 사용자 수는 7배로, 주간 에이전트 요청 수는 9.4배로 늘었습니다. 그러는 동안에도 전방위적인 최적화 덕분에 저희의 전체 AI 지출은 4월 이후 비교적 안정세를 유지했습니다.

그림 1: 2026년 2월부터 8월 중순까지의 주간 활성 사용자 수, 에이전트 요청 수, 비용. 사용자는 도구 간 중복을 제거한 수치입니다.

도입 규모와 작업 구성, 모델 업그레이드가 모두 끊임없이 바뀌기 때문에, 저희가 직접 만들어 낸 최적화 효과만 떼어 내려면 모델을 하나로 고정해야 합니다. 업그레이드가 있을 때마다, 모델 계열이 달라질 때마다 동작이 달라지기 때문입니다. 저희는 2월부터 7월까지 그렇게 측정했습니다. 모델 요청 1,000건당 비용은 정점 대비 34% 가까이 내려갔고, 세션당 비용은 6월 정점 대비 52% 내려갔습니다.

그림 2: 모델을 고정한 상태에서 측정한 비용 최적화 효과. *세션당 비용 데이터는 5월 말부터 집계했습니다.

이 글에서는 저희가 소프트웨어 팩토리를 어떻게 바라보는지 차례대로 풀어 보겠습니다. 에이전트 세션이 실행되는 네 계층, 지출을 분해할 때 쓰는 비용 방정식, 각 항을 측정하는 방법, 그리고 모든 계층에서 그 항들을 최적화하는 방법을 다룹니다.

이 비교에 나오는 모든 가격과 벤더 지표는 공개된 정보를 바탕으로 했으며, 비용 효율 개선은 표준 등급 요금 안에서 Uber 내부 작업을 더 똑똑하게 라우팅해 얻은 결과입니다. 저희가 측정한 구체적인 비용 절감 폭은 저희 환경에 한정된 것이고, 코드베이스와 팀 규모, 에이전트 워크플로에 따라 결과는 달라질 수 있습니다. 다만 실제 업무로 벤치마크를 만들고 정확도와 비용을 함께 최적화한다는 방법론 자체는 어디에나 적용할 수 있습니다.

소프트웨어 팩토리와 비용 방정식

에이전트 사용의 네 계층

저희는 AI 사용을 가장 전문화된 쪽에서 가장 범용적인 쪽까지 네 계층으로 나눕니다. 그림 3에서 보듯이 계층이 위로 갈수록 비용과 품질, 모델 선택을 저희가 더 많이 통제할 수 있습니다.

그림 3: 에이전트 세션이 실행되는 네 계층.

비용 방정식

위 계층 어디에서든 에이전트 세션의 비용은 다음 항들로 분해할 수 있고, 각 항은 따로 측정하고 따로 최적화할 수 있습니다.

그림 4: 전체 지출을 서로 곱해지는 여섯 개 항으로 분해한 모습.

앞의 두 항은 도입과 참여를 나타냅니다. 사용자가 직접 대화형으로 쓰든 에이전트가 사용자를 대신해 일을 처리하든, 이 두 항은 전체 사용자층에서 계속 키워 나가고 싶은 값입니다. 가운데 세 항이 최적화의 여지가 있는 부분입니다. 엔지니어가 실제로 요청한 일 위에 에이전트가 스스로 얹어서 하는 작업이기 때문입니다. 저희 노력의 대부분이 여기에 들어갑니다. 에이전트가 더 빨리 계획을 세우도록 돕고, 불필요한 턴이나 오류를 줄이고, 입력 토큰을 최적화하는 등의 장치가 여기에 해당합니다.

측정 방식

아래는 단기와 장기 계획을 세우고 예측하기 위해 저희가 매주, 매월 추적하는 지표 전체입니다.

최적화 레버

이어지는 절에서는 비용 방정식의 각 부분을 최적화할 때 쓴 핵심 레버를 자세히 설명합니다. 이 레버 중 일부는 비용 방정식의 여러 항에 동시에 영향을 줍니다.

토큰당 가격 최적화

토큰 가격은 벤더가 정합니다. 저희가 정하는 건 어떤 작업을 어떤 모델로 돌릴지입니다. 관리형 에이전트의 모든 계층에서 저희는 해당 작업에 가장 파레토 효율적인 모델을 고릅니다. 여기서 파레토 효율은 완료한 작업당 비용, 출력 품질, 모델 안정성을 함께 본다는 뜻입니다.

벤치마크 기반 모델 선택

모델 선택은 네 단계로 진행되고, 저희가 운영하는 모든 관리형 에이전트에 같은 방식을 적용합니다.

• 에이전트가 실제로 하는 일로 벤치마크를 만듭니다.
• 프런티어 모델이든 오픈 웨이트 모델이든 하나의 인터페이스로 제공하는 하네스에서 에이전트를 돌립니다.
• 파레토 최적인 쪽으로 옮기고, 계속 옮깁니다. 프런티어는 몇 주마다 바뀝니다.

앞으로는 관리형 에이전트에서 모아 온 데이터를 활용해 여러 모델 라우팅 전략을 시험하고 적용하면서, 작업별 성능을 계속 끌어올릴 계획입니다.

예를 들어 저희는 모든 풀 리퀘스트의 AI 코드 리뷰를 담당하는 uReview를 운영합니다. 이 에이전트의 벤치마크는 버그가 이미 확인된 실제 풀 리퀘스트로 만들고, 각 건을 쉬움·중간·어려움으로 등급을 매겼습니다. 그 버그들을 기준으로 정밀도와 재현율, F1을 채점하고, 여기에 리뷰당 비용과 지연 시간, 타임아웃, 잡음을 함께 봅니다. 그림 5에서 보듯이 모델을 바꾸자 F1은 올라가면서 풀 리퀘스트당 비용은 크게 내려갔습니다. 그림의 점선이 파레토 프런티어입니다. 그 선의 아래쪽과 왼쪽에 있는 조합은 모두 더 싸거나 더 좋은 다른 조합에 밀린 것들입니다.

그림 5: uReview로 시험해 본 모든 구성.

저희는 대규모 모노레포에서 뽑은 수천 건의 실제 풀 리퀘스트를 활용해, 프런티어 모델과 오픈 웨이트 모델을 여러 작업 유형으로 돌려 보는 자체 Uber SWE 벤치마크도 갖고 있습니다. 개발 수명 주기 전반의 관리형 에이전트에 어떤 모델을 쓸지 결정할 때 이 벤치마크를 참고합니다.

기본 모델 설정

대화형 인터페이스에서는 토큰 단가가 고정되어 있지만, 모델별로 토큰이 어떻게 분배되는지는 전략적으로 관리할 수 있습니다. 이 분배를 결정하는 기본 설정은 크게 두 가지입니다. 세션을 시작할 때 쓰는 모델과 서브에이전트가 쓰는 모델입니다.

그중 서브에이전트 기본 설정이 가장 효과가 큰 레버로 확인됐고, 그 비중은 계속 커지고 있습니다. 최신 모델의 능력이 좋아지면서 멀티 에이전트 오케스트레이션이 더 잘 작동하게 되자, 서브에이전트를 띄우는 세션의 비율이 꾸준히 올라갔습니다. 서브에이전트는 입력이 정해진 명확한 작업을 수행하고, 이런 작업에는 프런티어급 추론이 필요하지 않은 경우가 많습니다. 그래서 저희는 서브에이전트의 기본값을 더 약하고 비용 효율이 좋은 모델로 두고, 필요하면 수동으로 바꿀 수 있게 했습니다. 기본 모델은 작업을 쪼개고 평가하는 일을 맡고, 실제 실행은 서브에이전트가 합니다.

요청당 토큰 최적화

턴마다 전체 대화 기록과 프로젝트 컨텍스트, 도구 실행 결과가 다시 전송됩니다. 요청 하나의 크기를 줄이는 조치는 무엇이든 세션 전체에 걸쳐 복리로 쌓입니다.

기본값

모든 대화형 하네스는 설치 관리와 설정, 인증, 비용 가시성을 담당하는 통합 래퍼를 씁니다. 그중 표준으로 정한 두 가지 기본 설정이 요청당 토큰 소비를 직접 줄여 줍니다.

• 컨텍스트 윈도가 100만 토큰인 모델에서도 40만 토큰에서 자동 압축을 실행합니다. 이 기준값은 모델 성능과, 캐시가 한꺼번에 몰리는 부담 및 입력 토큰이 반복 청구되는 비용 사이에서 균형을 잡은 값입니다. 저희가 측정해 보니 전사 차원에서 요청당 입력 토큰이 의미 있게 줄었습니다.
• 추론 강도의 기본값을 중간(Medium)으로 둡니다. 내부 추론 토큰을 포함한 출력 토큰은 주력 모델에서 입력 토큰 단가의 몇 배로 과금되기 때문에, 이 정책 조정은 가장 비싼 토큰 항목의 지출을 곧바로 줄여 줍니다. 상당히 넓은 범위의 작업에서 중간 추론은 비용과 품질 사이의 균형이 좋습니다.

프롬프트 캐싱 전략

저희 프롬프트 캐싱 전략은 제공자의 프롬프트 캐시 읽기와 쓰기 비용 구조에서 출발합니다. 턴마다 전체 대화 기록을 다시 보내는 구조이므로, 앞선 컨텍스트를 캐시에 올려 두면 같은 비용을 반복해서 내지 않아도 되고, 이후 읽기 비용은 표준 입력 토큰 단가의 0.1배로 내려갑니다. 다만 쓰기 할증은 차이가 있습니다. 5분 캐시 항목은 1.25배, 1시간 항목은 2배입니다. 그래서 최적의 TTL(유효 기간)을 고르는 문제는 결국 턴 사이의 공백이 얼마나 긴가에 달려 있습니다. 선택할 수 있는 TTL은 Anthropic®의 5분과 1시간, 그리고 OpenAI®의 30분입니다.

그림 6: 두 TTL에서 5개 턴을 각각 돌려 비교한 결과.

엔지니어는 대화형 세션을 5분 넘게 그대로 놔두는 일이 잦기 때문에, 저희는 기본값인 5분 TTL에서 1시간으로 옮겼습니다. 이런 잦은 공백은 그전까지 접두 캐시를 무효화해서, 컨텍스트를 정가로 다시 쌓게 만들었습니다. 반면 서브에이전트는 짧게 끝나는 단일 작업만 처리하므로 캐시 TTL을 5분으로 유지합니다.

셸로 MCP 도구 실행하기

Uber에서는 모든 MCP(Model Context Protocol) 통신을 통합 게이트웨이로 보냅니다. 이 단일 진입점 하나가 내부 MCP와 서드파티 SaaS MCP를 합쳐 1,000개가 넘는 MCP 서버를 아우르고, 덕분에 인증과 정책 적용을 한곳에서 처리할 수 있습니다.

그런데 표준 MCP는 엔지니어가 그 세션에서 쓸지 안 쓸지와 무관하게 모든 도구 스키마를 모든 세션에 그대로 올려 버립니다. 예를 들어 도구를 100개 넘게 설치한 상태에서는 이 사전 적재만으로 초기 프롬프트에 약 5만~7만 토큰의 스키마가 붙고, 그게 턴마다 다시 전송됐습니다.

그림 7: 같은 도구에 접근하는 세 가지 방식에서, 에이전트가 세션 시작 시점에 이미 들고 있는 것.

이 컨텍스트 팽창을 해결하기 위해 저희는 서로 보완하는 두 가지 장치를 도입했습니다.

• CLI 도구 해석: MCP를 직접 연결하는 대신 모델이 셸 명령을 실행하게 합니다. CLI가 호출 시점에 게이트웨이를 상대로 필요한 도구를 동적으로 찾아 호출하므로, Uber MCP 스키마가 세션 컨텍스트에서 완전히 빠집니다. 내부 MCP 게이트웨이에 있는 1,000개 이상의 MCP 도구를 전부 CLI 명령으로 노출했습니다.
• 도구 검색: 모델이 도구 카탈로그를 검색해 필요한 도구만 그때그때 올리게 해서 도구 수천 개 규모까지 확장합니다. 이 방식은 컨텍스트 팽창을 줄이고, 도구 정의에 쓰이는 토큰을 대체로 줄여 주며, 사용할 수 있는 도구 목록이 늘어나도 선택 정확도를 높게 유지해 도구가 많아질 때 흔히 생기는 성능 저하를 막아 줍니다.

코드 모드

도구를 셸 명령으로 직접 호출하게 하면, 모델이 여러 동작을 하나의 스크립트 안에 묶어서 처리할 수 있습니다. 주고받는 횟수가 많은 도구 프로토콜에서 특히 유리합니다. 표준 MCP 방식에서는 동작마다 모델 턴이 따로 필요해서, 요청을 내보내고 원본 응답을 컨텍스트 윈도에 올리고 결과를 순차적으로 처리해야 합니다. 예를 들어 SQL 쿼리 하나를 실행하려면 요청을 보내고, 상태를 두 번에서 다섯 번 확인하고, 결과를 받아 와야 합니다. 코드 모드는 이 흐름 전체를 자동화된 파이썬 루프로 정리해서, 중간 상태 확인이 모델의 활성 컨텍스트에 들어오지 않게 합니다. 그림 8의 왼쪽에서는 모델이 상태 확인 루프에 직접 참여하고, 모든 응답이 컨텍스트에 쌓입니다. 오른쪽에서는 루프가 서브프로세스에서 돌고, 요약만 돌아옵니다.

그림 8: 같은 웨어하우스 쿼리를 두 방식으로 실행한 모습.

같은 세션 안에서 동일한 SQL 쿼리 5개를 두 경로로 돌려 측정했습니다.

앞의 세 행이 핵심을 보여 줍니다. 응답 크기 제한에 한참 못 미치는 아주 작은 결과 집합에서도 코드 모드는 토큰 사용량을 절반 이상 줄입니다. 큰 데이터 페이로드를 우회해서 얻은 효과가 아니라, 스키마 초기화와 여러 턴에 걸친 상태 확인, 단계마다 반복되는 불필요한 추론 같은 군더더기를 없애서 생긴 효과입니다.

대량 작업에서는 효과가 더 커집니다. 원래 모델 턴 N번이 필요했을 루프가 스크립트 하나로 줄어들면서 절감 폭이 90%를 넘게 쌓입니다. 저희는 가장 많이 쓰는 MCP 서버들을 대상으로 코드 모드 스킬을 25개 넘게 미리 만들어 배포해서, 표준 워크플로가 기본적으로 가장 비용 효율적인 경로를 타게 했습니다.

SaaS MCP

서드파티 소프트웨어를 관리하는 일은 내부 서버보다 훨씬 까다로웠습니다. 벤더는 고객이 어떻게 쓸지 미리 알 수 없으니 제품 기능 전체를 드러내도록 MCP 서버를 설계합니다. 예를 들어 어느 워크스페이스 제품군은 도구 49개를 서버 하나에 몰아넣어 약 2만 2천 토큰의 스키마를 요구하고, 메신저 벤더와 프로젝트 관리 벤더는 각각 34개와 46개의 도구를 제공합니다. 벤더 서버를 두세 개만 올려도, 사용자가 프롬프트를 입력하기 전부터 에이전트는 편집 중인 파일보다 더 많은 스키마를 짊어지게 됩니다.

이를 해결하기 위해 저희는 내부 MCP에 쓰는 것과 같은 방식으로 SaaS MCP 서버도 MCP 게이트웨이를 통해 라우팅합니다. 또한 이 MCP들을 모두 CLI로 노출해서 어떤 에이전트 환경에서든 호출할 수 있게 했습니다. 여기에 더해 서버마다 코드 모드 플러그인 안에 전용 스킬을 작성해, 자주 쓰는 워크플로를 하나로 묶었습니다. 그 결과 여러 SaaS 벤더에 걸쳐 효율적인 에이전트 워크플로가 가능해졌습니다.

그림 9: 모든 SaaS MCP 서버를 저희 MCP 게이트웨이 뒤에 두어 접근 방식을 하나로 통일하고 효율을 확보했습니다.

턴당 요청 최적화

근거가 없는 에이전트는 싸게 실패하는 대신 천천히 실패합니다. 한 군데만 더 찾아보겠다며 점점 커지는 컨텍스트 윈도를 계속 다시 보냅니다. 이 탐색 비용을 줄이는 가장 강력한 레버는 여전히 처음부터 더 풍부한 정보를 주는 것입니다.

컨텍스트 엔지니어링

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

그림 10: 같은 모델에 같은 프롬프트를 주고, 그래프 근거가 있을 때와 없을 때의 실행 경로를 비교한 결과.

그래프에 근거를 둔 에이전트는 과거 사용 기록을 조회해서 분석가 50명 이상이 쓰는 특정 테이블을 찾아내고, 38초 만에 답을 내놨습니다. 반대로 근거가 없는 에이전트는 그 테이블의 존재를 알지 못한 채 20분 동안 서비스 코드를 뒤지고, 서브에이전트를 2개 띄우고, 오류를 3번 낸 뒤에, 그 데이터셋은 질의할 수 없다는 틀린 결론을 내렸습니다.

가시성과 교육

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

상태 표시줄

저희는 하네스의 상태 표시줄에 실시간 비용 카운터를 넣어서, 하네스별 지출과 사용자별 전체 하네스 합계 지출을 실시간으로 보여 줍니다.

그림 11: 상태 표시줄과 함께 제공되는 세션 분석기, 효율 가이드.

가시성과 지출 등급

엄격한 상한을 두지 않으려고 저희는 실시간 지출 추적과 자동 알림을 도입했습니다.

• 상태 표시줄 실시간 카운터. 진행 중인 세션의 비용이 터미널에 항상 표시됩니다.
• 하네스 통합 한도. 도구별 예산을 따로 두지 않고 모든 대화형 하네스에 하나의 등급을 공유합니다. 관리형 에이전트는 별도 등급을 씁니다.
• 슬랙 알림. 예상 지출의 50%, 80%, 100% 시점에 알려 주어 엔지니어가 미리 계획을 세울 수 있게 합니다.
• 간편한 승인 절차. 등급 상향은 관리자 승인으로 처리하고, 승인 결과는 빠르게 반영됩니다.
• 비용 확인 스킬과 팁. 필요할 때 비용 내역을 뜯어보는 대시보드 스킬과, 상태 표시줄에서 바로 알려 주는 실시간 코칭을 제공합니다.

이 장치들은 엔지니어가 작업의 투자 대비 효과를 스스로 판단하게 하면서도, 비용이 통제를 벗어나는 상황을 막아 줍니다.

세션 분석 대시보드

상태 표시줄은 세션의 총지출을 보여 주지만, 비용을 밀어올리는 원인이나 지금 당장 할 수 있는 개선 조치까지는 보여 주지 못합니다. 일반적인 가이드는 큰 원칙을 알려 줄 뿐, 개발자 각자의 워크플로를 평가해 주지는 못합니다. 세션 분석 대시보드는 세션이 남긴 기록을 직접 들여다보면서 이 빈틈을 메웁니다.

이 대시보드는 런타임에 바로 내장되어 있어 별도 설정이나 사용 신청이 필요 없습니다. cost dashboard 스킬을 실행하면, 사용자가 쓰는 모든 하네스에서 로컬과 원격 클라우드 샌드박스에 걸쳐 남은 세션 트레이스를 전부 분석합니다. 그리고 하나의 종합 점수를 내놓는 대신, 세션 전반에서 16가지 안티패턴을 짚어 내고 각각에 금액 영향과 구체적인 개선 방법을 함께 붙여 줍니다. 유형에는 이런 것들이 있습니다.

• 모델 라우팅이 최적이 아닌 경우: Sonnet으로도 충분한 단순한 멀티 턴 세션을 Opus에서 돌리는 상황입니다.
• 컨텍스트 윈도 팽창: 40KB짜리 응답처럼 큰 MCP 페이로드가 컨텍스트에 계속 남아 다음 턴마다 반복 과금되는 상황입니다.
• 캐시 만료로 인한 비효율: 오래 쉬었다가 세션을 다시 이어가면서, 만료된 프롬프트 캐시 때문에 접두 컨텍스트를 정가로 다시 쌓는 상황입니다.
• 프롬프트 초기화 부담: 사용자가 아무 입력도 하기 전에 시스템 지시문과 도구 정의로 10만 토큰을 미리 올려 두는 상황입니다.

그림 12: 세션 단위 비용 대시보드가 낭비 패턴과 절감 가능액을 짚어 줍니다..

다음은 무엇일까요?

지금 진행 중인 일들은 다음과 같습니다.

• 관리형 에이전트 확대: 새 에이전트를 만들 때마다 같은 순서를 따릅니다. 목표 성과 지표를 정하고, 평가 벤치마크를 모으고, 파레토 최적 모델을 찾습니다. 이 방식으로 개발 수명 주기의 각 단계를 팩토리 성숙도 모델에서 한 단계씩 끌어올리는 것이 목표입니다.
• 동적 모델 라우팅: 여러 프로그래밍 언어와 코드 저장소, 에이전트 형태에 걸쳐 벤치마크 범위를 넓히고 있습니다. 모델 능력의 편차가 크기 때문에, 라우팅을 잘하려면 결국 폭넓은 평가가 뒷받침돼야 합니다.
• 컨텍스트 그래프 통합 심화: 더 많은 자율 에이전트가 그래프를 질의할 수 있게 열어 가고 있습니다.
• 세션 분석을 실시간 개발자 가이드로 발전: 안티패턴을 주기적으로 일괄 탐지하던 방식에서 트레이스를 계속 모니터링하는 방식으로 옮겨서, 엔지니어에게 개인화된 효율 개선 조언을 실시간으로 전달하려 합니다.
• 스킬 지속 개선: 에이전트 스킬을 실행하면서 생긴 자잘한 불편을 자동으로 기록하고, 모인 트레이스에서 스킬 업데이트를 자동 생성하는 방식을 만들고 있습니다.

맺음말

늘어나는 AI 코딩 비용을 관리하고 억제하는 일도 결국 풀 수 있는 엔지니어링 문제입니다. 단가가 더 싼 쪽으로 옮기거나 도구 수준을 낮추는 데 의존하지 않고, 아무 가치도 만들지 못한 채 낭비되는 토큰을 없애는 방식으로, 저희는 사용량을 7배로 늘리면서도 모든 지표에서 단위 비용을 낮추고 출력 품질은 유지하거나 개선했습니다.

전략의 핵심 전환은 대화형 개발자 워크플로에서 완전한 관리형 에이전트로 옮겨 가는 것입니다. 개발 수명 주기의 작업을 관리형 환경으로 옮기면 모델 라우팅과 실행 하네스, 운영 지출을 전부 통제할 수 있습니다. 전용 평가 벤치마크와 파레토 효율 모델을 각각 짝지어 둔 전문 관리형 에이전트들을 최적화하는 편이, 엔지니어 수천 명의 개별 터미널 세션을 최적화하는 것보다 본질적으로 더 저렴하고 더 잘 확장됩니다.