AI 에이전트가 늘수록 왜 ‘더 좋은 모델’만으로는 부족할까?

먼저 배경: AI를 많이 쓰게 되면 문제가 달라집니다

AI 코딩 도구를 처음 도입할 때는 보통 “어떤 모델이 가장 똑똑한가”를 묻습니다. 하지만 여러 사람이 매일 AI 에이전트를 쓰고, 일부 업무를 사람이 시작하지 않아도 자동으로 처리하게 되면 질문이 달라집니다.[1]

에이전트가 같은 정보를 반복해서 찾고, 쓰지 않을 도구의 설명까지 매번 읽고, 단순한 상태 확인을 위해 여러 차례 모델을 호출한다면 모델이 아무리 좋아도 시간과 비용이 함께 늘어납니다.[1] 이 단계에서는 답변 한 번의 품질보다 작업 전체가 얼마나 짧고 정확하게 끝나는가가 더 중요해집니다.

Uber가 말하는 Software Factory(소프트웨어 팩토리)도 코드를 공장에서 찍어낸다는 뜻보다는, AI가 하는 일을 측정하고 적절한 모델과 도구에 배분하며 결과를 검증하는 운영체계에 가깝습니다.[1]

Uber에서는 어느 정도로 AI 에이전트를 쓰고 있을까

Uber는 자사 풀 리퀘스트의 70% 이상이 로컬 또는 클라우드 에이전트에 귀속되고, 직원들이 만든 에이전트 스킬이 3,600개를 넘으며 하루 실행 횟수도 3만 회 이상이라고 밝혔습니다.[1] 여기서 풀 리퀘스트는 작성한 코드 변경을 검토하고 합쳐 달라고 요청하는 단위를 뜻합니다.

2026년 2월부터 8월까지 주간 활성 사용자는 7배, 에이전트 요청은 9.4배 늘었습니다. Uber는 전체 AI 지출이 4월 이후 비교적 안정됐다고 설명합니다.[1]

같은 모델을 고정해 비교했을 때 요청 1,000건당 비용은 정점보다 약 34%, 세션당 비용은 6월 정점보다 52% 줄었다고도 밝혔습니다.[1] 다만 이 수치는 Uber의 코드베이스·팀 규모·업무 방식에서 나온 내부 결과이므로 다른 조직이 같은 비율을 얻는다는 뜻은 아닙니다.

첫 번째 변화: 월 총액 대신 비용이 생긴 경로를 봅니다

Uber는 에이전트 비용을 다음과 같은 흐름으로 나눠 봅니다.[1]

사용자 수 × 사용자당 세션 × 세션당 대화 차례 × 차례당 요청 × 요청당 토큰 × 토큰 가격

여기서 토큰은 AI가 글을 읽고 쓸 때 세는 작은 텍스트 단위입니다. 사용자가 늘어난 것이 원인인지, 한 작업에서 대화가 불필요하게 길어진 것인지, 매 요청에 너무 많은 자료가 다시 들어가는 것인지 구분해야 개선할 지점도 찾을 수 있습니다.[1]

그래서 최종적으로는 “API에 얼마를 썼는가”만 보는 대신, 코드 검토 1건·완료된 작업 1건처럼 실제 결과 하나를 만드는 데 든 비용과 품질을 함께 봅니다.[1]

두 번째 변화: 모델은 고정 선택이 아니라 업무별 배치 대상입니다

가장 비싼 모델이 모든 업무에서 가장 경제적인 것은 아닙니다. Uber는 실제 업무로 평가 문제를 만들고, 여러 모델을 같은 조건에서 실행한 뒤 완료 비용·품질·안정성을 비교한다고 설명합니다.[1]

복잡한 일을 나누고 최종 결과를 판단하는 주 에이전트에는 강한 모델이 필요할 수 있습니다.[1] 반면 입력과 결과가 분명한 하위 작업은 더 가벼운 모델로 충분할 수 있습니다.[1] 중요한 것은 무조건 낮은 가격을 고르는 일이 아니라, 업무 난이도에 맞춰 모델을 배치하고 결과로 다시 평가하는 것입니다.

세 번째 변화: 모든 도구 설명을 미리 읽히지 않습니다

AI가 외부 도구를 사용하려면 무엇을 할 수 있고 어떤 값을 넣어야 하는지 설명한 명세가 필요합니다. 그러나 도구가 많아질수록 이 설명 자체가 큰 짐이 됩니다.[1]

Uber는 100개가 넘는 도구를 미리 연결했을 때 도구 설명만 약 5만~7만 토큰이 초기 입력에 더해졌다고 밝혔습니다.[1] 사용하지 않을 도구의 설명까지 대화가 이어질 때마다 따라다니면, 실제 작업보다 도구 목록을 읽는 데 더 많은 비용이 들 수 있습니다.

그래서 필요한 기능을 먼저 검색하고, 그때 필요한 도구만 불러오는 방식을 사용합니다.[1] 사람에게 회사의 모든 업무 매뉴얼을 외우게 하는 대신, 필요할 때 목록에서 정확한 매뉴얼을 찾게 하는 것과 비슷합니다.

네 번째 변화: 반복 확인은 AI 대화가 아니라 코드가 맡습니다

작업이 끝났는지 몇 초마다 확인하거나, 여러 페이지의 데이터를 차례로 읽는 일은 정해진 규칙으로 반복됩니다. 이 과정을 매번 AI가 보고 판단하게 하면 대화 횟수와 입력 기록이 계속 늘어납니다.[1]

Uber는 반복 조회를 별도 코드가 처리하고 마지막 결과만 모델에 돌려주는 code-mode를 시험했습니다. 같은 세션에서 실행한 다섯 SQL 예시 가운데 작은 결과에서도 토큰 사용량이 55~71% 줄었고, 여러 건을 묶은 작업에서는 90% 이상 줄었다고 보고했습니다.[1] 이 역시 Uber의 특정 실험 결과이며 모든 도구에서 같은 절감률을 보장하지는 않습니다.

핵심은 단순합니다. 판단이 필요한 순간은 AI가 맡고, 정해진 반복은 프로그램이 맡는 편이 낫다는 것입니다.

가장 인상적인 사례: 같은 모델도 정보 연결에 따라 달라졌습니다

Uber처럼 코드가 수억 줄이고 데이터 표가 수천 개라면, 에이전트는 답을 만드는 시간보다 정보가 어디 있는지 찾는 데 더 많은 시간을 쓸 수 있습니다.[1]

Uber는 서비스·팀·장애 기록·코드 변경·설계 문서·배포·데이터 사용 이력을 연결한 AI Context Graph를 운영합니다. Context Graph는 흩어진 정보와 그 관계를 연결해 필요한 사실을 찾게 하는 지도라고 이해하면 됩니다.[1]

공개된 한 사례에서 필요한 조직 정보에 연결된 에이전트는 같은 질문에 38초 만에 정확히 답했습니다. 연결되지 않은 에이전트는 20분 9초 동안 탐색하고, 하위 에이전트 두 개와 오류 세 번을 거친 뒤에도 틀린 결론을 냈습니다.[1]

이 사례가 모든 업무에서 같은 차이를 보인다는 뜻은 아닙니다. 다만 모델 성능 문제처럼 보이는 실패 중 일부는 실제로 정보 구조와 검색 경로의 문제일 수 있음을 보여줍니다.[1]

큰 회사가 아니어도 적용할 수 있는 부분

개인이나 작은 팀이 Uber와 같은 거대한 시스템을 만들 필요는 없습니다. 먼저 자주 반복되는 작업 하나만 골라도 됩니다.

같은 정보를 몇 번 다시 찾았는지 기록합니다.
사용하지 않은 도구 설명이 작업에 얼마나 들어왔는지 살펴봅니다.
단순 반복 조회와 파일 처리는 한 번의 코드 실행으로 묶습니다.
작업이 끝났는지뿐 아니라, 시간·비용·수정 횟수·오류를 함께 남깁니다.

이 기록이 쌓이면 “더 좋은 모델을 쓸까?”보다 먼저 “왜 이 작업이 이렇게 많은 대화와 검색을 필요로 했을까?”를 물을 수 있습니다.

읽을 때 함께 기억할 한계

공개된 수치는 Uber의 내부 환경에서 측정한 결과입니다.[1]
코드베이스 크기, 팀 구성, 사용하는 모델과 도구가 다르면 비용과 속도도 달라집니다.
업체가 공개한 운영 사례를 미래이다가 독립적으로 재현한 것은 아닙니다.
Software Factory는 제품 하나의 이름이라기보다 Uber가 AI 업무 운영체계를 설명하기 위해 사용한 개념입니다.[1]

따라서 이 글의 결론은 특정 절감률을 그대로 기대하자는 것이 아닙니다. AI 에이전트가 늘어날수록 모델 선택만이 아니라 정보를 찾는 방식, 도구를 불러오는 방식, 반복을 처리하는 방식, 결과를 평가하는 방식을 함께 설계해야 한다는 점입니다.