Uber의 Software Factory에서 배울 점: AI 에이전트는 ‘비용’이 아니라 ‘운영 설계’의 문제다

Uber Engineering이 공개한 “Running a Software Factory Efficiently at Uber Scale” 글은 단순한 AI 코딩 도구 소개가 아닙니다. 핵심은 AI 에이전트를 개발 현장에 많이 쓰면서도 비용을 통제하기 위한 운영 구조입니다.

저는 이 글을 보면서 개인용 AI 오케스트레이션, 특히 제가 정리하고 있는 CPAO(Cost-aware Personal Agentic Orchestration)와 매우 가까운 문제의식을 느꼈습니다. 규모는 Uber처럼 크지 않더라도, 개인·소규모 조직도 이제 AI를 “가끔 쓰는 도구”가 아니라 “반복 업무를 맡기는 업무팀”으로 운영해야 하는 단계에 들어섰기 때문입니다.

1. Uber가 말하는 AI Software Factory

Uber는 AI 도구가 소프트웨어 개발 전 과정에 들어와 있다고 설명합니다. 코드 작성, 코드 리뷰, CI 실패 복구, 버그 분석, 온콜 알림 처리, 유지보수 PR 생성 등 여러 업무가 에이전트 기반으로 움직이고 있습니다.

인상적인 것은 사용량 증가입니다. Uber에 따르면 2026년 2월부터 8월까지 주간 활성 사용자는 7배, 주간 에이전트 요청은 9.4배 증가했습니다. 그런데 총 AI 비용은 4월 이후 비교적 안정화됐다고 합니다. 동일 모델 기준으로 보면 1,000개 요청당 비용은 피크 대비 약 34%, 세션당 비용은 6월 피크 대비 52% 낮아졌다고 합니다.

즉, Uber의 방향은 “AI를 덜 쓰자”가 아닙니다. 오히려 더 많이 쓰되, 낭비되는 턴·요청·토큰을 줄이는 방식입니다.

2. 핵심은 비용 방정식이다

Uber는 AI 에이전트 비용을 다음과 같은 식으로 분해합니다.

총비용 = 사용자 수 × 세션/사용자 × 턴/세션 × 요청/턴 × 토큰/요청 × 토큰당 가격

이 식이 중요한 이유는 AI 비용을 막연한 “이번 달 청구서”가 아니라, 각각 줄이거나 관리할 수 있는 운영 지표로 바꿔주기 때문입니다.

사용자 수: AI를 쓰는 사람 또는 에이전트 수
세션/사용자: 얼마나 자주 AI를 업무에 쓰는가
턴/세션: 한 작업을 끝내기 위해 오가는 대화 횟수
요청/턴: 한 턴에서 모델이나 도구를 몇 번 호출하는가
토큰/요청: 매 요청마다 얼마나 많은 문맥·도구 설명·파일 내용이 들어가는가
토큰당 가격: 어떤 모델을 어떤 가격으로 쓰는가

여기서 앞의 두 항목, 즉 사용자 수와 세션 수는 늘어나는 것이 좋습니다. AI가 실제 업무에 더 많이 쓰인다는 뜻이기 때문입니다. 반대로 턴/세션, 요청/턴, 토큰/요청은 줄여야 합니다. 이 세 항목이 바로 에이전트가 쓸데없이 헤매거나, 같은 정보를 반복해서 보내거나, 불필요한 도구를 많이 부르는 영역입니다.

3. 모델 가격보다 중요한 것은 에이전트 운영 방식

많은 사람들이 AI 비용을 이야기할 때 먼저 “어떤 모델이 싸냐”를 묻습니다. 물론 모델 가격은 중요합니다. 하지만 Uber 글이 보여주는 더 중요한 포인트는 비용 폭증의 원인이 모델 가격만은 아니라는 점입니다.

실무에서 AI 비용이 커지는 이유는 대체로 이런 것들입니다.

에이전트가 같은 문제를 여러 번 반복해서 시도한다.
필요 없는 파일과 긴 대화 내역을 매번 다시 보낸다.
도구 목록이나 MCP 스키마가 너무 많이 로드된다.
실패한 명령을 원인 분석 없이 계속 재시도한다.
작업이 중간에 오래 멈춰 캐시가 깨지고, 다시 비싼 컨텍스트를 보낸다.

따라서 AI 비용 최적화는 단순히 “싼 모델 쓰기”가 아닙니다. 더 정확히는 에이전트가 일을 덜 헤매고, 필요한 도구만 쓰고, 작은 문맥으로도 정확히 끝내게 만드는 운영 설계입니다.

4. 개인용 Hermes에도 그대로 적용된다

이 관점은 대기업에만 필요한 것이 아닙니다. 오히려 개인이나 소규모 조직일수록 더 중요합니다. 예산이 작기 때문입니다.

제가 Hermes를 개인용 AI 업무팀으로 운영한다고 할 때, Uber의 비용 방정식은 이렇게 바꿔볼 수 있습니다.

블로그 글 1건당 비용
문서 리뷰 1건당 비용
상담 리포트 1건당 비용
자동화 성공 1건당 비용
작업당 재시도 횟수
검증 완료율

예를 들어 블로그 자동화를 한다면 “글을 썼다”가 끝이 아닙니다. 다음까지 봐야 합니다.

자료 수집은 자동화됐는가?
초안 작성은 자동화됐는가?
사실 확인과 출처 표시는 됐는가?
Blogger 초안 저장까지 됐는가?
발행 전 사람의 승인 지점이 있는가?
이 한 건을 만드는 데 비용과 시간이 얼마나 들었는가?

5. 개인용 Software Factory 4단계

Uber의 Software Factory 개념을 개인용 Hermes 운영에 맞추면 다음 네 단계로 볼 수 있습니다.

1단계: 대화형 에이전트

텔레그램에서 Hermes에게 직접 요청합니다. 예를 들면 “이 글 리뷰해줘”, “이 문서 요약해줘” 같은 방식입니다. 가장 쉽지만, 매번 사람이 지시해야 합니다.

2단계: Skill 기반 에이전트

반복되는 업무를 Skill로 표준화합니다. 예를 들면 한국어 문서 리뷰, DOCX 보고서 생성, 유튜브 원고 패키지 작성, 블로그 초안 작성 같은 작업입니다. 이 단계부터 품질이 안정됩니다.

3단계: Managed Workflow

정해진 흐름을 자동으로 실행합니다. 예를 들면 “자료 수집 → 요약 → 블로그 초안 → 승인 요청 → Blogger 초안 저장” 같은 흐름입니다. n8n, cron, Hermes 작업을 연결할 수 있습니다.

4단계: Autonomous Factory

여러 에이전트가 역할을 나눕니다. 리서처, 작성자, 검토자, 발행 담당자, 기록 담당자가 따로 움직이는 구조입니다. 단, 이 단계에서도 중요한 결정은 사람이 승인해야 합니다.

6. 조심해야 할 점

Uber 글에서 한 가지 조심할 부분도 있습니다. “70% 이상의 PR이 local 또는 cloud agent에 attributed 된다”는 표현은 매우 인상적입니다. 하지만 이것이 곧 “AI가 개발자의 70%를 대체했다”는 뜻은 아닙니다.

AI가 코드 일부를 작성했을 수도 있고, 리뷰나 테스트나 수정 과정에 관여했을 수도 있습니다. 따라서 이런 숫자는 과장해서 해석하면 안 됩니다. 중요한 것은 대체율이 아니라, 업무 흐름 안에 AI가 얼마나 안정적으로 들어왔는가입니다.

또 하나는 품질입니다. 비용을 줄이는 것만으로는 충분하지 않습니다. 싸게 만든 결과물이 틀리면 오히려 더 비쌉니다. 그래서 AI 업무 자동화에는 항상 다음 질문이 따라와야 합니다.

이 작업은 자동화됐는가? 그리고 검증됐는가?

7. 내일부터 해볼 수 있는 3단계

1단계: 반복 업무 하나를 고른다

처음부터 모든 업무를 자동화하려고 하면 실패하기 쉽습니다. 블로그 초안 작성, 강의안 정리, 회의록 요약, 상담 리포트 작성처럼 반복되는 업무 하나를 고릅니다.

2단계: 작업당 비용과 시간을 적는다

AI를 쓰기 전과 쓴 후를 비교합니다. 몇 분이 걸렸는지, 몇 번 수정했는지, 최종 산출물이 바로 쓸 수 있었는지를 봅니다.

3단계: 승인 지점을 남긴다

AI가 초안을 만들고 저장까지 할 수는 있습니다. 하지만 공개 발행, 고객 발송, 결제, 삭제 같은 일은 사람이 승인해야 합니다. 자동화의 목적은 사람을 빼는 것이 아니라, 사람이 더 중요한 판단에 집중하게 하는 것입니다.

마무리 의견

Uber 글에서 제가 가장 크게 배운 점은 이것입니다.

AI 비용은 모델 가격 문제가 아니라, 에이전트 운영 설계 문제다.

개인이나 소규모 조직도 이제 같은 질문을 해야 합니다.

AI가 실제 업무를 줄여주고 있는가?
작업당 비용은 낮아지고 있는가?
품질 검증은 되고 있는가?
사람의 승인 지점은 안전하게 남아 있는가?

앞으로 Hermes를 단순 챗봇이 아니라 개인용 AI 업무팀으로 운영하려면, 이런 지표가 필요합니다. 저는 이것을 CPAO(Cost Aware Personal Agentic Orchestration), 비용인지형 개인 에이전틱 오케스트레이션이라고 부르고 싶습니다.

AI를 많이 쓰는 시대에는 “어떤 모델이 제일 똑똑한가”보다 더 중요한 질문이 생깁니다.

내 AI 업무팀은 같은 비용으로 더 많은 검증된 결과를 만들고 있는가?

이 질문을 관리하는 사람이 앞으로 AI를 제대로 쓰는 사람이 될 것입니다.

참고: Uber Engineering, “Running a Software Factory Efficiently at Uber Scale”
https://www.uber.com/kr/en/blog/efficient-software-factory/

찰리초이 스토리 블로그

이 블로그 검색