핵심 요약
- PR의 70% 이상이 로컬·클라우드 에이전트에 의해 처리되며, 에이전트가 개발 1차 라인 역할을 수행함
- 3,600개 이상의 에이전트 스킬이 하루 3만 회 이상 실행될 정도로 자동화가 광범위하게 작동함
- 2026년 2월부터 8월 중순까지 주간 사용자 수가 7배, 에이전트 요청 수는 9.4배 증가함
분석
목차
에이전트 기반 개발이 Uber의 코드베이스에서 PR의 70% 이상을 자동 처리하고 있다. 단순 코드 자동완성이 아니라, 로컬과 클라우드 양쪽에서 작동하는 에이전트가 1차 PR 라인의 역할을 맡는다. Uber가 공개한 운영 지표는 이 변화를 구체 숫자로 보여준다.
필자가 이 사례를 주목하는 이유는 ‘코드를 대신 써주는 도구’가 아니라 ‘PR 흐름 전체를 운영하는 운영체제’에 가깝기 때문이다. Uber의 소프트웨어 팩토리 운영 방식은 에이전트 기반 개발의 규모와 비용 구조를 동시에 드러낸다.
소프트웨어 팩토리라는 이름의 의미
Uber는 자사 개발 시스템을 ‘소프트웨어 팩토리’라 부른다. 핵심은 단일 에이전트가 아니라 역할별 에이전트 묶음을 빌딩블록처럼 쌓는 설계다. PR 생성, 리뷰, 머지 후보, 사후 모니터링이 에이전트 안에서 닫힌다. 사람은 최종 게이트 역할만 남는다.
규모를 숫자로 본다
3,600개 이상의 에이전트 스킬이 하루 3만 회 이상 실행된다. 2026년 2월부터 8월 중순까지 주간 사용자 수는 7배, 에이전트 요청 수는 9.4배로 뛰었다. PR의 70% 이상이 에이전트가 1차로 처리한다.
| 지표 | 수치 |
|---|---|
| 일일 스킬 실행 | 30,000회 이상 |
| 에이전트 처리 PR 비중 | 70% 이상 |
| 주간 사용자 증가 (2~8월) | 7배 |
| 에이전트 요청 증가 | 9.4배 |
| 활성 스킬 수 | 3,600개 이상 |
| 비용 곡선 (4월 이후) | 평탄 유지 |
이런 폭증에도 4월 이후 비용 곡선은 평탄해졌다. 사용량과 비용이 분리된 그래프가 그려진 것이다.
에이전트 기반 개발에서 비용이 잡힌 이유
Uber가 비용을 잡아낸 방식은 단일 트릭이 아니다. 캐싱, 라우팅, 작은 모델과 큰 모델의 혼용, 요청 단위 토큰 절감 같은 전방위 최적화가 상시로 돌아간다. 실무자 입장에서 가장 의미 있다고 본 건, 비용이 사용량 그래프와 비례하지 않게 설계됐다는 사실이다.
에이전트 기반 개발의 진짜 쟁점은 모델 성능이 아니라 이 분리 구조를 어떻게 운영하느냐에 있다. 실무 도구 맥락의 사례에서도 같은 흐름이 반복적으로 관측된다.
대규모 코드베이스에 적용할 때의 설계 고려사항
Uber 규모의 모노리스·마이크로서비스 혼합 환경에서 에이전트를 굴리려면 세 가지가 전제된다. 코드베이스 인덱싱과 검색 인프라가 충분히 빨라야 하고, PR 단위 권한과 책임 범위가 에이전트에게 위임 가능한 수준으로 정리돼야 하며, 사람이 최종 머지를 결정하는 게이트가 분명해야 한다.
이 중 어느 하나라도 비면 자동화의 이득이 역효과로 바뀐다.
에이전트 기반 개발의 리스크와 한계
에이전트 기반 개발로 PR의 70% 이상을 처리하는 조직은 새로운 리스크를 안는다. 보안 정책 우회 가능성, 책임 소재의 모호함, 그리고 ‘에이전트 기반 개발로 생성된 코드를 다시 사람이 리뷰한다’는 역설이 그것이다. Uber의 사례는 가능성을 보여주지만, 그 위에서 무엇을 통제할지는 각 조직이 스스로 답해야 한다.
이 같은 다중 에이전트의 거동은 이미 에이전트 생태계의 자발적 군집화 현상과 무관하지 않다.
실무 적용 포인트
- 에이전트에 맡길 PR 단계와 사람이 게이트할 단계를 코드화한다.
- 비용과 사용량을 같은 그래프에 그려 분기점을 찾는다.
- 에이전트 스킬 카탈로그를 사내 표준으로 운영한다.
지금 바로 해볼 것
- 이번 주 PR 5개를 골라 어떤 단계가 에이전트로 대체 가능한지 적는다.
- 사용량과 비용을 한 그래프에 그려 4월 같은 분기점을 표시한다.
- 에이전트 스킬 카탈로그 초안을 10개 이내 항목으로 만든다.
- PR 머지 권한과 책임 매트릭스를 한 페이지 문서로 정리한다.
자주 묻는 질문
에이전트 기반 개발에서 비용이 왜 사용량과 분리될 수 있나요?
캐싱, 라우팅, 모델 혼용 같은 최적화가 상시 적용되면 토큰 단위 비용이 떨어집니다. Uber 사례처럼 사용량 9.4배 증가에도 비용이 평탄해진 건 이 분리 구조 덕분입니다.
Uber의 PR 70% 자동화는 어떤 단계를 포함하나요?
단순 코드 생성이 아니라 PR 생성·리뷰·머지 후보 생성까지 폭넓게 포함합니다. 사람이 최종 게이트를 두는 구조가 전제라는 점이 핵심입니다.
중소 규모 조직도 에이전트 기반 개발을 도입할 수 있나요?
가능합니다. 다만 코드베이스 인덱싱 인프라와 PR 게이트 설계가 먼저 준비돼야 의미 있는 자동화로 이어집니다. 처음부터 70%를 목표보다 10~20% 지점에서 시작하는 게 현실적입니다.
에이전트 의존도가 높아지면 가장 큰 리스크는 무엇인가요?
보안 정책 우회, 책임 소재 모호함, 에이전트 산출물을 다시 사람이 검증해야 하는 비용입니다. 이 셋을 동시에 관리하지 않으면 자동화의 이득이 빠르게 깎입니다.
참고 원문
이 기사는 다음 원문을 확인해 작성했습니다: geeknews — Uber 규모의 소프트웨어 팩토리를 효율적으로 운영하는 법
전문가 코멘트(AI)
LLM시스템엔지니어
사용량-비용 분리 구조가 증명하는 것: 에이전트 개발의 승부처는 모델이 아니라 추론 플랫폼이다
사용량 증가와 비용 곡선의 분리는 에이전트 운영 플랫폼의 성숙도를 재는 가장 정직한 지표이며, 캐싱·모델 라우팅·토큰 절감의 조합은 LLM 추론 최적화의 정석적 구성이다. 9.4배 요청 증가에도 비용이 평탄하게 유지됐다면 캐시 히트율과 소형 모델 위임 비율이 상당한 수준에 도달했을 개연성이 높고, 이는 단발성 프롬프트 튜닝으로는 얻을 수 없는 플랫폼 레벨의 성과다. 다만 소형 모델 위임이 늘어날수록 PR 생성·리뷰 품질의 조용한 저하가 발생하기 쉬운데, 수용률·롤백률·머지 후 결함률 같은 품질 가중 지표 없이는 비용 절감이 품질을 잠식하고 있는지 판별할 수 없다. 빠르게 변하는 대규모 코드베이스에서 스킬·컨텍스트 캐시의 신선도 관리도 실무 난점으로, 이 부분이 무너지면 최적화 이득이 재작업 비용으로 되돌아온다. 그럼에도 이기종 모델 위에 오케스트레이션 계층을 얹어 단위 경제성을 통제하는 이 구조는 향후 CI/CD처럼 표준 인프라가 될 방향이 맞다.
소프트웨어공학전문가
PR의 70% 에이전트 위임은 유망하지만, 책임과 검증 구조가 완성되지 않으면 병목을 제거한 게 아니라 옮긴 것이다
PR 생성부터 리뷰·머지 후보·사후 모니터링까지 에이전트가 1차 라인을 맡고 사람이 최종 게이트를 지키는 구조는, 코드 리뷰가 병목인 현대 개발 조직에서 자연스러운 다음 진화 단계다. 스킬 카탈로그를 사내 표준으로 운영해 도구 파편화를 막고 위임 범위를 단계별로 코드화하는 접근은 조직 차원의 통제 장치로서 타당하다. 그러나 PR의 70%가 에이전트를 거치면 사람의 역할이 코드 이해에서 산출물 감사로 이동하게 되고, 자동화 편향으로 검토가 형식화될 위험이 커진다. 에이전트 산출물을 다시 사람이 검증하는 구조는 병목을 없앤 것이 아니라 검증 능력으로 병목을 옮긴 것이며, 스킬별 롤백률과 머지 후 결함률 추적이 병행되지 않으면 자동화율만 올라가고 품질 책임은 흐려진다. 보안 정책 우회와 책임 소재 문제는 에이전트 식별자 서명, PR 단위 권한 매트릭스, 감사 로그 같은 제도적 장치 없이는 해소되지 않으므로, 도입 조직은 자동화율보다 게이트 설계를 먼저 완성해야 한다.
비판적 분석가
70% 자동화와 비용 평탄화라는 수치는 기술 성과이기 이전에, 정의를 누가 정했는지가 관건인 잘 다듬어진 기업 서사일 가능성이 있다
이번 지표 공개의 최대 수혜자는 Uber 자신이다. 인력 증원 없는 성장 서사, AI 시대 채용 불확실성 속의 고용주 브랜딩, 그리고 막대한 볼륨을 근거로 한 모델 공급자와의 가격 협상 카드까지 한 번의 공개로 동시에 확보될 수 있기 때문이다. ‘에이전트가 처리한 PR 70%’라는 수치는 정의와 분모가 공개돼 있지 않은데, 의존성 업그레이드·포맷·사소한 정리 같은 저난도 PR이 다수 포함됐다면 실질 개발 자동화율보다 훨씬 높게 측정됐을 가능성이 있다. ‘4월 이후 비용 평탄’ 역시 플랫폼 구축 인력비나 인프라 감가상각이 어디까지 포함됐는지 알 수 없어, 순수 효율이 아니라 비용의 회계적 재배치로도 재현될 수 있는 그림이다. 대형 기술기업들이 AI 생산성 수치를 줄지어 내놓는 최근의 업계 흐름과 맞물려 보면, 이 사례는 동종 업계 경쟁 압력에 대한 선제적 포지셔닝으로도 읽힌다. 우리가 진짜 주목해야 할 것은 70%라는 숫자가 아니라, 그 숫자를 감사할 수 있는 제3자 검증이 존재하는지 여부다.
물밑 시나리오
- 인력 서사로서의 전략적 공개일 가능성 — 대형 기술기업들이 AI 생산성 지표를 공개하는 시점이 인력 계획이나 실적 발표 주기와 겹치는 경향을 보이는 가운데, ‘7배 사용자 증가에도 비용 평탄’이라는 도식은 채용 없는 성장을 정당화하는 근거로 기능하기 쉽다.
- 지표 정의의 유리한 설계 가능성 — ‘에이전트가 처리한 PR’의 분모에 저난도 자동 PR이 다수 포함될 경우 70%는 실제보다 부풀려진 자동화율로 재현될 수 있고, 정의와 측정 기준이 비공개인 상태에서는 그렇게 읽힐 여지가 남는다.