우버의 AI 인프라 내부 — 에이전트 시대를 만든 개발자 도구

URL: https://www.youtube.com/watch?v=MDUYSMJmi8A 날짜: 2026-10-15 채널: The Pragmatic Engineer 원문 제목: Uber’s AI infra, from the inside 출연: Uday Kiran Medisetty (Uber Distinguished Engineer), Gergely Orosz

---

📌 핵심 질문 / 핵심 논점

==AI 코딩 에이전트의 생산성은 모델이나 하네스 자체보다, 에이전트가 코드를 이해하고 실행하고 검증하도록 받쳐 주는 10년 이상의 개발자 플랫폼 투자에서 나온다.==

• 우버는 2015년 두 개의 서비스에서 출발해 수천 개의 서비스와 수천 명의 엔지니어를 운영하는 동안, 모니터링·트레이싱·배포·실험·문서·테스트를 자체 플랫폼으로 표준화했다.
• Model Gateway, AIFX, MCP Gateway, 스킬 저장소, Context Graph, DevPod, Minion, Slate, Capri, Code Inbox가 서로 연결되어 모델·하네스와 무관한 실행·검증 루프를 만든다.
• 엔지니어의 성과는 생성한 diff 수가 아니라 실제 기능을 사용자에게 전달한 속도와 품질로 측정해야 하며, 새로운 핵심 역량은 컨텍스트 엔지니어링·멀티태스킹·에이전트 결과 검증이다.

우버의 AI 전환은 2025~2026년에 갑자기 생긴 신제품 묶음이 아니다. 2017년에 만든 클라우드 개발 환경이 2025년의 Minion을 가능하게 했고, 2017~2018년에 쌓은 Jaeger 트레이싱이 Slate의 서비스 라우팅을 가능하게 했으며, 기존 Thrift·Protobuf 레지스트리가 MCP 도구 자동 생성을 가능하게 했다. 인간 엔지니어를 편하게 만들기 위해 축적한 표준화가 에이전트에게도 그대로 실행 환경과 피드백 루프가 된다.

1. 우버의 성장과 플랫폼화가 만든 출발점

우버의 현재 AI 개발 환경은 빠른 사업 확장과 서비스 표준화의 역사 위에 세워졌다.

1.1. 2015년의 두 서비스와 실시간 API

1. Uday Kiran Medisetty의 합류와 경력 변화

   1. 합류 시점: Uday는 2015년 5월 우버에 합류했고, 자신을 추천한 두 엔지니어가 2026년에도 회사에 남아 있다고 말했다.
   2. 초기 담당: 실시간 API 팀에서 일하며 모바일 앱 전체를 위한 API Gateway와 모바일 프로토콜 변경을 맡았다.
   3. 이후 영역: Fulfillment, Uber for Business, 운전자·배달원 온보딩, 마켓플레이스 가격 책정을 거쳤고, 최근 1년은 일반 사용자·고객지원·사내 엔지니어를 위한 에이전트형 AI를 담당했다.

2. 초기 우버의 서비스 구조

   1. Dispatch: Node.js로 작성되어 당시 승객과 운전자의 모든 트래픽을 처리했다.
   2. API: Python으로 작성되어 운행 종료 후 결제·영수증·기타 후처리를 담당했다.
   3. 두 서비스의 규모: Uday가 합류했을 때 우버에는 이 두 서비스만 존재했다. 이후 마이크로서비스 전환이 시작되면서 서비스 수가 폭발했다.

3. RT API가 해결한 모바일 통신 문제

   1. 기존 방식: 약 4초마다 전체 세계 상태를 보내는 단순한 ping 프로토콜을 사용했다.
   2. 새 역할: RT API는 모바일 클라이언트와 내부 서비스를 추상화하고 REST API와 서버→클라이언트 push 프로토콜을 함께 제공했다.
   3. 실시간성: 승객과 운전자의 앱은 물리 세계의 변화에 따라 몇 초마다 상태가 바뀌므로, 변한 상태만 효율적으로 전달할 경로가 필요했다.
   4. 기술 진화: 초기에는 Node.js와 Python 스택을 따랐지만 뒤에 Go로 전환했으며, 지금도 우버에서 가장 높은 QPS를 처리하는 서비스 중 하나다.

1.2. 두 서비스에서 수천 개의 서비스로, 다시 적정 규모로

1. 마이크로서비스 붐의 배경

   1. 사업 확장: 우버는 여러 국가로 계속 진출했고, 모빌리티 제품군을 넓힌 뒤 Uber Eats까지 확장했다.
   2. 개발 속도: 성장 속도를 따라가려면 팀들이 새로운 기능을 빠르게 만들 수 있어야 했고, 서비스 생성·메트릭·트레이싱·모니터링·관측성·배포를 모두 지원하는 기반이 필요했다.
   3. 자체 구축의 이유: 당시 시장에는 우버가 요구한 규모와 변화율을 감당할 상용 소프트웨어가 거의 없었다.

2. 서비스 수의 변화

   1. 2015년: 총 두 개의 서비스에서 시작했다.
   2. 2019년 전후: 수천 개 수준까지 늘었다.
   3. 2026년: 사업 규모가 2019년보다 약 10배 커졌지만 서비스 수는 당시와 비슷한 수준이며, 서비스는 더 크고 적정하게 재편됐다.
   4. 현재 범위: 대략 4,500~5,000개의, 과거보다 덜 마이크로하고 더 잘 나뉜 서비스가 운영된다.

3. 플랫폼화와 기술 표준화

   1. 언어 표준: 2018~2019년 Go와 Java를 주요 언어로 정하고 기술 스택을 현대화했다.
   2. 공유 빌딩 블록: 국가마다 별도의 스택을 만드는 대신 하나의 글로벌 기술 스택과 모빌리티·배달 공통 플랫폼을 사용한다.
   3. 사업 효과: 공통 플랫폼 덕분에 새로운 모빌리티·배달 수직 제품을 더 쉽게 만들고, 지역 특화 제품을 다른 시장으로 확장할 수 있다.

4. 엔지니어링 조직의 성장

   1. 초기 규모: Uday가 합류했을 때 전체 엔지니어는 약 600명이었고, 마켓플레이스 팀은 50~60명 정도였다.
   2. 현재 조직: 수천 명 규모로 성장했으며, 2019~2020년부터 여러 지역으로 기술 조직을 확장했다.
   3. 글로벌 사이트: 현재 세계 거의 모든 대륙에 12개의 글로벌 기술 거점이 있다.
   4. 지역성과 공유성: 지역 팀은 현지 시장에 맞는 제품을 만들고, 검증된 제품은 전 세계로 확장하며, 글로벌 플랫폼은 그 작업을 공유한다.

2. AI 이전에 만들어 둔 우버 고유의 개발자 도구

우버의 규모와 도시 단위 사업 모델은 범용 제품만으로 해결하기 어려운 문제를 만들었고, 그 결과 AI 이전부터 내부 도구가 깊게 구축됐다.

2.1. 소유권·관측성·머신러닝·워크플로 플랫폼

1. uOwn과 사고 대응 도구

   1. 소유자 확인: uOwn은 서비스나 다른 자산의 담당 팀과 소유자를 찾게 해 준다.
   2. 온콜 연결: 장애가 발생하면 해당 서비스를 누가 소유하고 누가 온콜인지 바로 확인할 수 있다.
   3. 문서와 사고 학습: 엔지니어링 설계 문서와 제품 설계 문서를 한곳에 모으고, 인시던트 관리와 재발 방지 학습을 체계화했다.

2. M3DB와 대규모 관측성

   1. 처리량: 2015~2016년에도 초당 약 5억 개의 메트릭을 방출했고, 높은 카디널리티까지 처리해야 했다.
   2. 자체 구축: 이 부하를 감당할 상용 메트릭 시스템이 없어서 M3DB를 만들었다.
   3. 산업 파급: M3DB는 오픈소스화됐고 이를 기반으로 관측성 기업 Chronosphere가 만들어졌다.

3. Michelangelo와 ML 생명주기

   1. 필요성: 우버는 수백 개의 머신러닝 모델을 운영했기 때문에 피처 생성, 모델 구축, 모니터링, 서빙을 한 흐름으로 처리해야 했다.
   2. 플랫폼: Michelangelo는 2015~2016년부터 개발된 엔드투엔드 머신러닝 플랫폼이다.
   3. AI 확장: 생성형 AI와 에이전트형 AI를 위한 구성 요소가 Michelangelo 안에 추가됐고, 딥러닝 및 Michelangelo 일부 인프라는 오픈소스화됐다.

4. Cadence와 장기 실행 워크플로

   1. 문제: 운전자 온보딩이나 CRM 캠페인처럼 며칠에 걸쳐 진행되는 작업은 각 팀이 상태 저장과 복원 로직을 따로 구현해야 했다.
   2. 해결: Cadence는 내구성 있는(durable) 워크플로 엔진으로 장기 실행 흐름과 상태를 관리했다.
   3. 생태계: Cadence는 오픈소스화됐고, Temporal은 Cadence에서 영감을 받아 더 넓은 규모로 발전한 시스템으로 알려졌다.

2.2. Morpheus와 도시라는 기본 프리미티브

1. Morpheus의 기능

   1. 통합 플랫폼: 설정 관리, 기능 플래그, 실험을 하나로 엮고 모바일 기능 플래그와도 통합했다.
   2. 데이터 기반 운영: 우버에서는 거의 모든 변경이 기능 플래그와 실험을 거치며, 실험 결과를 즉시 보고 분석할 수 있었다.
   3. 시장 구조 반영: 2면·3면 마켓플레이스에 맞춘 switchback 실험을 지원하고, p-value와 분석 지표를 자동으로 계산했다.
   4. 기반 데이터: 신뢰할 수 있는 분석을 위해 메트릭·데이터 기반도 함께 강화했다.

2. 도시가 범용 도구에 맞지 않는 이유

   1. 1급 개념: 도시는 메트릭 카디널리티, 기능 플래그, 실험, 배포, 서비스 샤딩 전반에서 기본 프리미티브로 취급된다.
   2. 상용 제품의 한계: 일반적인 기능 플래그나 관측성 제품 가운데 도시를 이 수준으로 지원하는 제품이 없었다.
   3. 초기 사례: 일부 서비스는 데이터베이스를 도시별로 샤딩했다.

3. 물리 인프라까지 이어지는 도시 라우팅

   1. 지역 고정: 각 도시는 특정 클라우드 리전에 매핑된다.
   2. 장애 전환: 필요하면 도시 전체를 다른 리전으로 failover할 수 있다.
   3. 논리 배포 그룹: 일부 중요 서비스는 여러 도시를 여러 컨테이너 그룹에 연결해 도시 그룹 단위로 트래픽을 배치한다.
   4. 신뢰성 목표: 도시별 트래픽과 계층을 따로 관찰해 모든 지역의 안정성을 확인한다.

3. DevPod에서 AI 실행 공간으로

2017년에 만든 DevPod는 인간을 위한 클라우드 개발 환경이면서, 뒤에 Minion과 다른 에이전트가 사용할 표준 작업공간이 됐다.

3.1. 마이크로리포지토리에서 언어별 모노리포로

1. 초기의 저장소 문제

   1. 마이크로리포지토리: 서비스마다 독립된 저장소를 사용했고, 표준 빌드 시스템이 없었다.
   2. 도구 파편화: 서비스마다 빌드·테스트 시스템이 달랐고, 최소 두세 종류의 시스템이 병존했다.
   3. 업그레이드 비용: 중앙 팀이 라이브러리 업그레이드를 전체 서비스에 적용하기가 매우 어려웠다.

2. 2017~2018년 모노리포 전환

   1. 언어별 저장소: 마이크로서비스 구조는 유지하되 Go, Java, iOS, Android 등 언어별로 하나의 모노리포를 만들었다.
   2. 표준 빌드: 모든 서비스가 공통된 빌드·테스트 체계를 통해 배포됐다.
   3. 새로운 병목: 저장소 규모가 커지면서 로컬 노트북에서 빌드하기 어려워졌고, 각 개발자가 도구를 설치하며 겪는 설정 문제가 커졌다.

3.2. DevPod의 설계와 에이전트 확장

1. 클라우드 개발 박스

   1. 저장소별 환경: 엔지니어는 주로 작업하는 모노리포에 맞는 DevPod를 만들고, 각 환경은 빌드 캐시를 미리 가진다.
   2. 성능과 SLA: 클라우드 머신은 노트북보다 강력하므로 빌드·테스트 시간에 대한 예측 가능한 SLA를 제공한다.
   3. 설정 제거: 표준 도구가 이미 설치되어 있어 로컬 설정 오류를 줄인다.

2. AI 시대의 Mega DevPod

   1. 전체 코드베이스: 에이전트가 여러 저장소를 넘나들며 작업하도록 모든 저장소를 포함한 Mega DevPod를 만들었다.
   2. 표준 지침: 루트에 Agents.md와 Claude.md를 두어 표준 빌드·테스트 방식과 저장소 맥락을 전달한다.
   3. 기본 설치: Claude Code, Codex, OpenCode 같은 AI 도구가 기본 설치된다.
   4. 접근성: 비엔지니어도 DevPod를 만들어 Claude Code나 Codex를 바로 실행할 수 있다.

3. 에이전트에 대한 플랫폼화 효과

   1. 재사용: 엔지니어를 편하게 만든 플랫폼 구성 요소가 에이전트의 작업공간·빌드·테스트에도 그대로 사용된다.
   2. 재현성: 인간과 에이전트가 같은 환경과 같은 명령을 사용하므로 결과를 재현하기 쉽다.
   3. 핵심 교훈: AI 인프라를 새로 만드는 속도는 기존 개발자 플랫폼의 표준화 수준에 크게 좌우된다.

4. 모델·하네스·도구를 중립화한 AI Foundations

모델과 코딩 하네스가 빠르게 바뀌는 상황에서 우버는 특정 공급자에 고정되지 않는 공통 계층을 만들었다.

4.1. Model Gateway와 AI Guard

1. 모델 중립성

   1. 초기 판단: 2023년 ChatGPT와 GPT 모델이 확산된 뒤, 모델과 하네스가 빠르게 바뀌므로 모든 AI 시스템을 model-agnostic·harness-agnostic으로 만들기로 했다.
   2. 공통 API: Michelangelo 위에 생성형 AI 기반을 만들고, OpenAI 호환 API와 Anthropic 호환 API를 제공했다.
   3. 모델 선택: Anthropic·OpenAI 등 외부 업체 모델과 우버가 운영하는 오픈 모델을 하나의 Gateway 뒤에 배치해 호출자가 모델을 바꿔도 애플리케이션을 다시 만들 필요가 없게 했다.

2. 프로젝트 초기화

   1. 간단한 클라이언트: 엔지니어는 Michelangelo에서 프로젝트를 만들고 프로젝트 ID와 호출자 토큰만 제공하면 된다.
   2. 중앙 라우팅: 모델 선택기가 Model Gateway로 들어가 당시의 ChatGPT나 Opus 등 올바른 모델로 라우팅한다.
   3. 단일 진입점: 모든 모델 요청이 한곳을 통과하므로 보안·정책·비용·관측성 기능을 일관되게 적용할 수 있다.

3. AI Guard

   1. 보안 미들웨어: 보안팀이 운영하며 모든 요청과 응답을 검사한다.
   2. 정책 검사: 민감정보, 콘텐츠 안전성, 커뮤니케이션 정책을 확인하는 여러 파인튜닝 모델을 사용한다.
   3. 지연시간 기준: 모든 요청·응답에서 실행하되 엄격한 지연시간 가드레일을 지켜야 한다.
   4. 일관된 기준: 각 프로젝트가 따로 안전 정책을 구현하지 않아도 동일한 기본 보안 수준을 적용할 수 있다.

4. 비용과 관측성

   1. 귀속: 프로젝트·사용자·호출자 단위로 모델 사용량과 비용을 추적한다.
   2. 감사 가능성: 중앙 Gateway에서 감사 로그와 세션 트레이스를 남긴다.
   3. 향후 확장: 모든 모델 트래픽이 한곳을 지나므로 모델 라우팅과 비용 최적화를 도입하기 좋은 지점이 된다.

4.2. AIFX와 책임 있는 토큰 사용

1. 하네스 래퍼

   1. 지원 대상: Claude Code, Codex, OpenCode를 AIFX(AI Foundations)로 감싼다.
   2. 설정 이동: 하네스를 바꿔도 설정·스킬·도구·플러그인이 따라오며, 로컬과 DevPod의 환경 사이에서도 설정을 동기화한다.
   3. 중앙 관리: 회사 차원의 설정을 한 번 관리해 모든 사용자에게 배포하고, 개인 설정은 각 사용자의 여러 환경에 동기화한다.

2. 페르소나와 사용 편의성

   1. 기본 묶음: 페르소나마다 기본 플러그인과 스킬을 제공해 별도 설치를 줄인다.
   2. 상태 표시줄: 하네스·세션별 비용과 사용량을 표시하고 작업 중 최적화 팁을 제공한다.
   3. 도구 통합: 어떤 하네스를 쓰든 동일한 설치·설정·관리 경로를 사용한다.

3. 소비 티어

   1. 기본 할당: 엔지니어에게 기본 비용 티어를 주고, 티어가 부족하면 다음 티어를 요청하게 한다.
   2. 관리자 승인: 프로젝트의 ROI와 사용 이유를 간단히 설명하고 매니저 승인을 받으면 한도를 올릴 수 있다.
   3. 목표: 가치 있는 작업은 막지 않되, 토큰이 공짜인 것처럼 무책임하게 소모하지 않게 한다.
   4. 분리된 한도: 대화형 하네스와 백그라운드 코딩 에이전트에 서로 다른 티어를 적용한다.

4. CostCheck

   1. 세션 간 분석: CostCheck 플러그인이 여러 세션의 사용량을 살펴본다.
   2. 개인화 조언: 프로젝트별 지출과 비용 프로필을 보여주고 모델 크기·컨텍스트 사용 개선 팁을 제공한다.
   3. 성과: 비용을 지속적으로 피드백한 결과 최근 몇 달 동안 토큰 비용을 약 50% 줄였다.

4.3. MCP Gateway와 Skills 저장소

1. MCP Gateway의 출발

   1. 시기: 2025년 초 Cursor와 MCP가 확산되자 내부 도구를 에이전트에 노출할 기회가 커졌다.
   2. 공통 계층: 2025년 4월부터 Model Gateway와 유사한 MCP Gateway를 만들기 시작했다.
   3. 범위: 코딩뿐 아니라 모든 소프트웨어 엔지니어링 작업에서 내부 서비스를 사용할 수 있게 했다.

2. Thrift·Protobuf 레지스트리의 재사용

   1. 계약 레지스트리: 우버 서비스는 강한 계약으로 Thrift 또는 Protobuf API를 사용하며, 최근 서비스는 주로 Protobuf로 전환했다.
   2. 자동 생성: 중앙 API 레지스트리의 정의에서 MCP 서버와 도구의 요청·응답 스키마·설명을 자동 생성한다.
   3. 최적화: 원래 API 설명을 바탕으로 LLM에 맞춘 설명도 생성하며, 3,000~4,000토큰에 이르는 도구 설명을 더 효율적으로 줄인다.

3. 내부·외부 도구의 통합

   1. 커스텀 MCP: 팀이 직접 만든 MCP와 프록시도 MCP Gateway를 통해 제공할 수 있다.
   2. 외부 서비스: Google, Slack 같은 벤더 도구도 같은 Gateway에 노출한다.
   3. 설정 단순화: AIFX에서 내부 MCP와 외부 MCP를 동일한 방식으로 설치·관리한다.
   4. CLI 투영: 최근에는 모든 MCP를 CLI로도 실행할 수 있게 해, 에이전트가 MCP 방식이나 CLI 방식 중 토큰 효율이 높은 경로를 고르게 했다.

4. Skills 모노리포

   1. 구성: 중앙 플랫폼 팀의 공통 스킬과 개별 팀의 스킬을 하나의 스킬 저장소에 모은다.
   2. 하네스 호환성: 동일한 품질 게이트와 AIFX 설치 명령으로 여러 하네스에 스킬을 배포하며, 사용하지 않는 하네스 설정까지 미리 갱신한다.
   3. 도구 접근: 모든 스킬이 MCP Gateway의 동일한 도구 계층을 사용한다.
   4. 규모: 최근 몇 주 기준으로 하루 약 30,000회의 스킬 실행이 발생했다.

5. 스킬 품질과 토큰 비용

   1. 초기 품질의 한계: 최신 모델로 스킬의 V0를 만드는 일은 쉽지만 다양한 사용 사례에서 안정적으로 작동하게 만드는 일은 어렵다.
   2. CLI 전환: 두 플러그인이 각각 여러 MCP를 컨텍스트에 상주시킬 때 토큰 부담이 커지자, 일부 엔지니어가 스킬을 CLI 패턴으로 바꿔 토큰 효율을 높였다.
   3. 운영 자동화: 전 직원에게 스킬 마켓플레이스를 자동 설치해 검색·설정·관리 단계를 줄이고, 평가(evaluation)와 발견성 파이프라인을 구축했다.
   4. 지속 개선: 하네스 트레이스를 수집해 스킬의 개선 패치를 만들고, 스킬 평가 품질을 계속 높이는 작업이 진행 중이다.

5. Context Graph와 Cortana: 조직 지식을 에이전트의 기본 맥락으로

검색만으로는 여러 시스템에 흩어진 우버의 지식을 충분히 연결하기 어렵기 때문에, 사람·코드·문서·운영 자산 사이의 관계를 그래프로 만들었다.

5.1. Cortana에서 Context Graph로

1. Cortana의 시작

   1. 질의 인터페이스: 2025년 12월 한 엔지니어가 웹과 Slack에서 어떤 코드베이스든 질문할 수 있는 AI 비서 Cortana를 만들었다.
   2. 질문 범위: 조사, 쿼리 실행법, 데이터 출처, 소유자 확인, 근본 원인 분석(RCA) 등 다양한 엔지니어링 질문이 들어왔다.
   3. 발견된 문제: 작업 관리, 온콜 대시보드, 소유권 시스템, 문서가 서로 고립되어 있어 답을 찾으려면 여러 번의 도구 호출이 필요했다.

2. 그래프 스키마

   1. 노드·엣지 규모: 100개가 넘는 노드 유형과 130개가 넘는 엣지 유형을 가진다.
   2. 사람 노드: 모든 직원이 노드가 되고, 자신이 만든 PR·작성한 설계 문서·담당 자산·작업 중인 기능과 연결된다.
   3. 자산 노드: PR, 서비스, 기능, 설계 문서, 온콜 이벤트, 설정 변경, 인시던트, 데이터 쿼리 등도 노드가 된다.
   4. 관계: 누가 PR을 만들었는지, 누가 자산을 관리하는지, 누가 문서에 기여했는지를 연결한다.

3. 기본 grounding의 동작

   1. 첫 단계: 질문을 받으면 Context Graph에서 질문자와 대상 도메인·서비스·자산을 먼저 찾는다.
   2. 깊은 탐색: 범위를 좁힌 뒤 관련 문서와 도구를 읽어 상세 답을 만든다.
   3. 품질과 효율: 모델이 근거를 얻기 위해 필요한 왕복 횟수와 비용·지연시간이 줄고, 답변 품질은 높아졌다.

5.2. 복잡한 질의, 운영 권한, 조직 사일로

1. 데이터 질문 사례

   1. 질문: 전 세계 모빌리티 운행 중 현금 결제 유형이 얼마나 되는지 묻는다면, 먼저 관련 테이블과 컬럼을 찾아야 한다.
   2. 관계 탐색: 비슷한 쿼리를 작성한 사람, 소속 조직, 최근 30일에 사용된 쿼리, 관련 테이블·컬럼을 그래프에서 찾는다.
   3. 검증된 답: 연결된 쿼리와 문서에서 이른바 blessed query를 찾아 복잡한 질문에도 빠르게 답한다.

2. 그래프 플랫폼의 재사용

   1. 기존 기반: 우버의 프로덕션 그래프는 수십억 개의 노드를 다루며, 같은 그래프 플랫폼 팀이 Context Graph를 만들었다.
   2. 상대적 규모: 전사 지식 그래프는 프로덕션 그래프보다 훨씬 작아 저장·탐색 자체가 새로운 규모 문제는 아니었다.
   3. 접점: Cortana는 Slack·웹·CLI 어디서나 호출되며, 운영 조직의 직원도 서비스 구조·위치·담당자를 질문할 수 있다.

3. 권한 보존

   1. 기존 권한 상속: Cortana는 질문자의 기존 접근 권한을 그대로 적용한다.
   2. 민감 데이터 보호: 접근 권한이 없는 로그·모니터링·문서는 답변에 포함되지 않는다.
   3. Break glass: 추가 권한이 필요할 때는 과거 우버의 방식처럼 매니저·디렉터 승인을 거치는 예외 권한 흐름을 사용한다.
   4. 360도 상태 보고: 허용된 범위 안에서 서비스 의존성, 저장소, 로그, 모니터링을 조회해 자산의 건강 상태를 종합한다.

6. 계획에서 실행까지: PRD·ERD와 Minion

에이전트에게 바로 코드를 요구하기보다 제품·엔지니어링 맥락과 제약을 먼저 구조화해야 물리 세계와 국가별 변형을 안전하게 다룰 수 있다.

6.1. PRD·ERD를 소스 오브 트루스로 만들기

1. 문서 종류 통합

   1. 기능 계획: 제품 요구사항 문서(PRD)와 엔지니어링 요구사항 문서(ERD)를 한 흐름에서 관리한다.
   2. 검토 문서: 제품 설계 문서, 엔지니어링 설계 문서, 출시 리뷰, 실험(XP) 리뷰, 프로덕션 준비성 리뷰를 같은 시스템에 둔다.
   3. 상태 추적: 프로젝트 담당자와 진행 상태, 승인 상태, 원본 문서를 확인할 수 있다.

2. 실행 시스템과의 연결

   1. 업무 링크: 각 문서는 Jira나 Linear 이슈와 연결된다.
   2. 그래프 연결: 문서·프로젝트·작업·사람이 Context Graph에 들어가 전체 역사를 추적한다.
   3. 인간·에이전트 공통 기반: 어떤 문서가 소스 오브 트루스인지 에이전트와 엔지니어가 동일하게 확인한다.

3. 계획의 필요성

   1. 이질성: 국가별 제품과 물리 세계를 다루는 우버는 정상 경로만으로 구현할 수 없다.
   2. 예외 조건: 제품·국가·도시·서비스 조합의 코너 케이스를 설계 단계에서 생각해야 한다.
   3. 분해 가능성: 좋은 계획은 엔지니어와 에이전트가 작업을 쪼개고 순서대로 실행하기 쉽게 만든다.

6.2. Minion 백그라운드 코딩 에이전트

1. 기본 역할

   1. 생산 PR 비중: 우버의 프로덕션 PR 중 약 15%가 현재 Minion을 통해 만들어진다.
   2. 사용 방식: 웹이나 Slack에서 계획 모드로 검토한 뒤 실행시키거나, 단순 작업은 한 번의 프롬프트로 백그라운드에 넘긴다.
   3. 코드 범위: Mega DevPod에서 모든 저장소에 접근하고, 계획에 따라 여러 저장소에 하나 또는 여러 개의 PR을 만든다.

2. 작업 범위의 확장

   1. 초기 작업: 처음에는 유지보수성 작업이 주로 Minion에 위임됐다.
   2. 검증 도구 추가: 웹·모바일·백엔드 API의 자체 검증 도구가 늘어나면서 더 복잡한 작업도 맡기는 것이 목표다.
   3. Slack 협업: Slack 스레드에서 @minion을 호출하고, PM·EM과 합의한 설계 맥락을 그대로 따라 PR을 만들 수 있다.
   4. 버그 대응: 지원 채널에서 버그가 보고되면 Minion이 원인을 찾고, 단순한 문제라면 그 자리에서 수정 PR까지 만든다.

3. 빠른 개발 환경

   1. 준비된 클러스터: 여러 클라우드의 Kubernetes 클러스터에서 개발 환경을 미리 데워 둔다.
   2. 복제 방식: 사전 빌드 이미지, 저장소, 빌드 캐시가 준비되어 있어 DevPod를 수초 안에 복제한다.
   3. 공통 명령: 모든 저장소에 Bazel을 사용하며, 인간과 에이전트가 Agents.md·Claude.md에 정의된 동일한 빌드·테스트 명령을 사용한다.
   4. 개발 흐름: 엔지니어는 수초 안에 DevPod를 만들고, 하나의 일관된 방식으로 어느 모듈이든 빌드할 수 있다.

7. CI와 코드 리뷰를 에이전트 시대에 맞추기

PR 수가 늘수록 모든 변경을 같은 깊이로 읽는 방식은 병목이 되므로, 자동 신호와 위험도에 기반해 사람의 주의를 배분한다.

7.1. Inner Loop와 Self-healing CI

1. 병목 측정

   1. 사이클 타임: PR을 만들기 전 내부 루프와 원격 PR 이후의 P50·P90 사이클 타임을 모두 측정한다.
   2. 증가 원인: PR 물량과 CI 작업이 해마다 늘어나 리뷰와 빌드가 병목이 됐다.
   3. 코드 레드: 2026년 초 CI 작업 수가 12개월 동안 두 배 이상 늘어 내부적으로 CI 시스템에 code red를 선언했다.

2. AIFX Validate

   1. Inner Loop 이동: 린트, 커버리지 규칙, 빌드 규칙, 템플릿 규칙처럼 단순한 검사를 PR 생성 전에 실행한다.
   2. 단일 명령: 에이전트가 aifx validate를 호출하면 기본 검사를 한꺼번에 수행한다.
   3. 목표: PR이 처음부터 양호한 상태일 확률을 높이고, 원격 CI에서 낭비되는 시간을 줄인다.

3. 시각·환경 검증

   1. 클라이언트 검증: 에뮬레이터, 웹 환경, 모바일 환경을 띄워 변경된 기능을 실제로 시험한다.
   2. 스테이징 검증: 변경 사항을 스테이징에 배포하고 백엔드 API를 실행해 결과를 확인한다.
   3. 에이전트 루프: 대화형 하네스와 Minion이 이 검증 스킬을 실행해 스스로 결과를 확인한다.

4. Self-healing CI

   1. 실패 후 수정: PR 전체 또는 특정 PR에 자동 수정을 적용해 실패한 검사에 대응한다.
   2. 피드백 루프: 에이전트가 검증 결과를 받고 코드를 고친 뒤 다시 검사한다.
   3. 전제 조건: 자동 수정이 곧 자동 병합을 뜻하지는 않으며, 이후 위험도 신호와 인간 리뷰가 남는다.

7.2. Code Inbox와 인간 리뷰의 미래

1. Code Inbox의 화면

   1. 통합 큐: 담당자에게 도착한 PR과 본인이 만든 PR을 한곳에서 본다.
   2. 검토 신호: 빌드 검사, 테스트 결과, 기능 화면의 영상·스크린샷, 변경의 위험도와 blast radius를 함께 제공한다.
   3. 주의 배분: 어떤 변경에 깊이 시간을 쓸지, 어떤 변경이 안전한지 빠르게 판단하게 한다.

2. 인간 리뷰의 현재 원칙

   1. 전수 승인: 사고 비용이 큰 우버는 현재 모든 PR에 엔지니어 리뷰를 요구한다.
   2. 자동화의 방향: AI 코드 리뷰와 위험도 점수를 함께 쌓고, 과거 수년의 데이터를 이용해 위험도 점수를 백테스트한다.
   3. Green Lane: 충분한 신뢰가 생기면 저위험 PR 일부를 자동 병합하는 green lane을 열 수 있지만, 아직은 모든 차원을 확신하는 일이 우선이다.
   4. 순서: P0는 모든 신호를 한곳에 모아 리뷰를 쉽게 만드는 것이고, 자동 병합 비율을 높이는 일은 그 다음인 P1이다.

8. Slate와 Capri: 사람이 하던 검증을 에이전트의 피드백 루프로

우버의 서비스 수와 제품 조합이 많아지면서, 단위 테스트만으로는 엔드투엔드 동작을 충분히 확인할 수 없다.

8.1. Slate의 다중 서비스 샌드박스

1. 기본 동작

   1. 브랜치 환경: 엔지니어가 작업 중인 브랜치를 별도의 Slate 인스턴스에 배포한다.
   2. 계정 고정: 테스트 계정 UID를 특정 인스턴스에 고정해 로그인 요청이 그 브랜치로 향하게 한다.
   3. 서비스 그래프: 나머지 상·하류 서비스는 스테이징을 사용하고, 테스트 중인 두세 서비스만 Slate 인스턴스로 라우팅한다.

2. 트레이싱 기반 라우팅

   1. Jaeger: 2017~2018년에 구축한 분산 트레이싱 인프라로 모든 서비스 호출에 부모·자식 span을 남긴다.
   2. Baggage 전파: 트레이스에 서비스와 테스트 계정 정보를 실어 서비스 메시 전체로 전파한다.
   3. 정밀 라우팅: 서비스 메시가 baggage를 보고 특정 요청을 정상 환경이 아닌 Slate 환경으로 보낸다.
   4. 축적 비용: 모든 기존 서비스가 이 방식을 지원하도록 개조하고 새 서비스도 같은 전제로 만들기까지 수년이 걸렸다.

3. 에이전트 검증

   1. CLI 도구: 에이전트가 slate mcp create로 새 환경을 만들고, 서비스 배포와 테스트 계정 고정을 수행한다.
   2. 비교 테스트: 에이전트 브라우저가 main과 작업 브랜치를 A/B 테스트하고, 전후 화면의 차이와 회귀 여부를 보고서로 만든다.
   3. 첨부 결과: iOS·Android·웹의 스크린샷과 동영상을 PR에 붙이고 백엔드 API도 같은 방식으로 확인한다.

8.2. Capri의 실제 트래픽 캡처·재생

1. 조합 폭발 문제

   1. 앱 복잡도: Rider 앱만 해도 수백 개의 화면이 있고, 사업·제품·도시·국가 같은 차원이 겹친다.
   2. 테스트 한계: 모든 순열을 수동 테스트로 만들면 수천 개의 테스트를 유지해야 하므로 현실적으로 어렵다.
   3. 목표: 특정 국가의 Uber Eats 현금 운행처럼 드문 조합에서 변경이 회귀를 만들지 확인해야 한다.

2. 캡처 파이프라인

   1. 미들웨어: 표준화된 언어 프레임워크에 미들웨어 하나를 붙여 실제 운영 트래픽을 캡처한다.
   2. 범위: 서비스의 인바운드·아웃바운드뿐 아니라 하위 서비스로 보내는 요청·응답까지 기록한다.
   3. 차원 추출: 요청의 특정 필드를 규칙으로 분석해 마켓플레이스 유형, 사업 라인, 최종 상태 등 관심 차원을 태깅한다.

3. MatchGuard 재생

   1. 실제 조합 집합: 캡처한 요청과 차원에서 현재 운영 중인 전체 조합을 만든다.
   2. 배포 전 검사: CI/CD에서 PR 변경을 전체 조합에 재생하고 전후 데이터를 비교한다.
   3. 세션 활용: 세션의 메타데이터와 하위 호출을 확인하고, 특정 요청을 Slate 환경에서 다시 실행할 수 있다.
   4. 버그 수정: 수정 전·후 delta가 기대한 변화인지 확인하고, 에이전트는 재생→비교→수정 루프를 반복한다.

4. Deputy와 Cerberus에서 Capri로

   1. 이전 도구: 2016~2020년에는 Deputy와 Cerberus가 운영 데이터 재생과 라우팅을 일부 지원했지만 실제 기준 데이터를 잡고 사용하기가 어려웠다.
   2. 현재 개선: Capri는 실제 세션을 훨씬 쉽게 캡처하고 재생하며, 버그 재현과 수정 검증을 일상적인 흐름으로 만든다.
   3. 규모의 난이도: 4,500~5,000개 서비스 환경에서 모든 요청·응답·라우팅을 일관되게 지원하는 일 자체가 거대한 시스템 작업이다.

8.3. Edge Gateway와 운영 진단

1. 통합 진입점

   1. 계보: 기존 RT API는 Go 기반 Edge Gateway로 발전했다.
   2. 프로토콜: gRPC, webhook, GraphQL 등 여러 엔드포인트 유형을 하나의 진입점에서 처리한다.
   3. 공통 기능: 모니터링·알림·신뢰성 기능을 한곳에서 구축할 수 있다.

2. 재생과 의존성 맥락

   1. Capri 연동: Edge Gateway도 내부적으로 Capri 기반의 캡처·재생을 사용한다.
   2. 의존성 태그: 어떤 서비스가 필수 의존성이고 어떤 서비스가 선택적 의존성인지 자동 태깅한다.
   3. 효과: 풍부한 의존성·재생 맥락이 인간 엔지니어와 에이전트의 장애 진단을 빠르게 한다.

9. Shepherd·Fox·Wisdom: 유지보수와 버그 대응의 자동화

기능 개발뿐 아니라 대규모 마이그레이션, 반복적인 코드 청소, 직원이 신고한 실제 버그까지 에이전트 흐름에 넣었다.

9.1. Shepherd의 캠페인과 Fox의 지속 개선

1. Shepherd의 결정론적 마이그레이션

   1. 출발점: 모노리포로 옮겨도 모든 모듈의 라이브러리 사용법을 바꾸는 작업은 남았다.
   2. OpenRewrite: 단순한 시그니처 변경은 OpenRewrite 정책으로 자동 변환한다.
   3. 팀 경계: Shepherd는 팀별 소유 모듈을 파악하고 각 모듈에 별도의 PR을 만든다.

2. AI Shepherd

   1. 복잡한 변경: 모든 서비스의 컨텍스트 전파를 고쳐 트레이싱을 개선하는 것처럼 단순 치환을 넘어서는 작업에 프롬프트와 스킬을 사용한다.
   2. 캠페인: JUnit 4에서 JUnit 5로 전환하는 작업처럼 YAML 정책과 다수의 PR을 캠페인으로 묶는다.
   3. 관리: 캠페인 소유자는 모듈별 진행 상태와 생성된 PR을 한 화면에서 추적한다.

3. Fox의 주기적 코드 유지보수

   1. 등록 방식: 서비스 팀이 dead code 정리, 성능 분석, noisy log 제거 같은 스킬에 서비스를 등록한다.
   2. 실행 시점: CI 부하가 낮은 일요일에 다음 주 작업을 위한 PR을 생성한다.
   3. 옵트인에서 옵트아웃으로: 현재는 빠르게 확장하는 단계라 opt-in이지만, 스킬 품질이 높아지면 일부 스킬은 opt-out으로 전환한다.
   4. 관리형 루프: 서비스가 스킬을 선택하면 매주 코드 개선 PR이 생성되는 지속적인 agentic loop가 된다.

4. 유지보수의 생산성 효과

   1. 토일 제거: 반복적인 maintenance PR을 자동화해 엔지니어가 진짜 기능 작업에 더 많은 시간을 쓰게 한다.
   2. 스킬 투자: 반복되는 maintenance PR을 분석해 새 스킬을 만들거나 기존 스킬을 개선한다.
   3. 중요한 구분: 코드 양을 늘리는 것보다 반복 작업을 줄여 기능 출시 용량을 늘리는 것이 목표다.

9.2. Wisdom과 DebugAssist

1. 직원용 버그 신고

   1. 도그푸딩: 우버 직원이 Rider·Earner 앱을 사용하다 버그를 발견하면 앱에서 바로 신고한다.
   2. 자동 라우팅: AI가 내용을 보고 담당 팀으로 자동 전달한다.
   3. 풍부한 자료: 직원 베타 앱에서 신고하므로 로그·텔레메트리·네트워크 요청·분석 이벤트·기능 플래그를 함께 수집할 수 있다.

2. 재현 정보 자동화

   1. 환경 포함: 국가를 바꿔 기능을 시험하는 경우처럼 기기 위치를 모킹한 상태도 기록한다.
   2. 사용자 경로: 사용자가 거친 화면의 순서를 로그에서 복원한다.
   3. 문제 정의: 재현 단계, 기대 동작, 실제 관찰 동작을 정리해 엔지니어가 문제를 바로 이해하게 한다.

3. DebugAssist와 Minion 연결

   1. 근본 원인: DebugAssist가 수집된 맥락과 코드베이스를 함께 보고 원인·영향·증거·시간선을 제시한다.
   2. PR 위임: 엔지니어가 원인을 승인하면 그 맥락을 Minion에 넘겨 수정 PR을 만든다.
   3. 업무 추적: PR은 Jira 작업에 연결되고, Jira에는 RCA가 남는다.
   4. 학습 루프: 잘못된 RCA나 PR이 나오면 결과를 다시 활용해 DebugAssist와 Minion의 품질을 개선한다.

4. 직원 버그의 재연

   1. 버그 UID: 신고된 버그의 식별자를 테스트 기기에 전달하면 같은 네트워크 응답을 재현한다.
   2. 동일 경험: 엔지니어가 신고자와 같은 앱 상태와 응답을 경험해 문제를 재현한다.
   3. 수정 확인: 수정 후 같은 시나리오를 실행해 실제로 문제가 사라졌는지 확인한다.

10. 엔지니어의 역할과 생산성 측정의 변화

에이전트가 코드 생성량을 늘리는 것만으로는 가치가 증가하지 않으며, 전체 제품 생명주기의 병목을 없애고 기능 출시를 늘려야 한다.

10.1. Capability overhang와 지속적인 병목 제거

1. 새로운 목표

   1. 전체 생명주기: 요구사항 작성, 설계, 구현, 검증, 리뷰, 출시, 롤아웃 전체를 다시 설계한다.
   2. 다음 병목 탐색: AI와 시스템 엔지니어링을 함께 사용해 가장 느린 단계를 계속 제거한다.
   3. 제품 결과: 최종 목표는 모델 호출 수나 PR 수가 아니라 모든 제품에서 출시할 수 있는 기능 수를 극대화하는 것이다.

2. Capability overhang

   1. 잠재력: 최신 모델이 수행할 수 있는 능력은 이미 많다.
   2. 부족한 주변부: 오케스트레이션, 하네스, 도구, 권한, 검증 시스템이 충분하지 않아 그 능력을 올바른 장소와 방식으로 활용하지 못하는 상태가 capability overhang다.
   3. 투자 방향: AI Foundations와 검증 도구를 늘릴수록 모델의 잠재 능력을 실제 기능 출시로 전환할 수 있다.

10.2. Diff velocity에서 Feature velocity로

1. 기존 지표

   1. 산출물 지표: 과거에는 diff 처리량, 코드 처리량, 리뷰 수 같은 쉬운 지표를 참고했다.
   2. 개발자 경험: 정기적인 DevEx 설문, NPS와 감정, 코드 품질, 결함당 인시던트, 코드 커버리지도 함께 본다.
   3. 한계: 에이전트가 수십~수백 개의 PR을 만들 수 있게 되면 PR 수나 diff velocity만으로 사용자 가치가 늘었다고 판단할 수 없다.

2. PR 분류

   1. 태그: PR을 feature, bugfix, maintenance, testing, documentation과 복잡도 등으로 분류한다.
   2. 방향성: 우버는 기능 PR 비율이 올라가고 maintenance PR 비율이 내려가는지를 본다.
   3. 해석: 코드량 증가와 기능 PR 비율 증가가 함께 나타나야 실제 가치가 늘었다고 본다.

3. Feature velocity 추적

   1. 연결 복원: PRD·ERD·작업·출시·롤아웃을 AI로 자동 클러스터링하고 누락된 연결을 찾아낸다.
   2. 측정: 복잡도별 기능의 P50 출시 시간을 반기 단위로 과거 2~3년과 비교할 수 있게 만든다.
   3. 병목 분석: PRD 단계, 출시 단계, 롤아웃 단계 중 어디가 막히는지 찾아 다음 투자를 결정한다.

10.3. 컨텍스트 엔지니어링·멀티태스킹·검증

1. 컨텍스트 엔지니어링

   1. 새로운 정의: 엔지니어의 일은 에이전트가 신뢰할 수 있는 결과를 낼 수 있도록 올바른 컨텍스트를 구축하는 일이 됐다.
   2. 실행 전 질문: 작업을 넘기기 전에 어떤 코드·문서·도구·제약·환경이 필요한지 정하고, 그 맥락을 에이전트에 제공한다.
   3. 좋은 명세: 올바른 스펙과 제약을 줄수록 에이전트가 생성하는 결과의 신뢰성이 높아진다.

2. 멀티태스킹

   1. 과거 방식: PR을 만드는 데 오래 걸려 한 작업에 집중하는 것이 자연스러웠다.
   2. 현재 방식: 여러 에이전트 세션을 병렬로 실행하며 작업 범위와 상태를 계속 전환한다.
   3. 필요 역량: 일을 잘 쪼개고, 진행 상황을 추적하고, 짧은 시간에 결과를 확인해야 한다.

3. 검토와 검증

   1. 코드 냄새: 에이전트의 결과에서 회귀와 위험한 코드 냄새를 빠르게 발견해야 한다.
   2. 새 프리미티브: 소프트웨어를 어떻게 만들고 검증할지뿐 아니라, 에이전트가 만들고 검증할 수 있는 환경을 어떻게 만들지 설계해야 한다.
   3. 병렬화의 대가: 더 많이 병렬화할수록 컨텍스트·멀티태스킹·검증 능력이 중요해진다.

4. 고객지원 정책 전환 사례

   1. 기존 흐름: 인간 상담원이 따르던 런북을 AI 에이전트 정책으로 바꾸려면 동적 데이터, 호출할 API, 사용할 속성, 시스템 설정, 수동 평가를 차례로 준비해야 했다.
   2. 자동화: 에이전트가 필요한 API와 속성을 찾고 설정을 만들며, 과거 맥락을 이용해 합성 평가를 생성하도록 바꿨다.
   3. 시간 단축: 수주 걸리던 정책 전환을 훨씬 짧은 시간에 수행하게 됐다.
   4. 안전장치: 사람의 검증과 가드레일을 없애는 것이 아니라, 자동화된 흐름 중간에 필요한 인간 승인과 평가를 배치한다.

11. 결론과 실용적 시사점

1. 에이전트 하네스는 전체 시스템의 작은 일부다

   1. 코딩 하네스를 설치하는 일은 쉽지만, 코드·서비스·권한·문서·빌드·테스트·관측성·리뷰를 연결하는 일이 어렵다.
   2. 프로덕션 코드에는 생성 능력보다 실행 환경과 검증 피드백 루프가 더 중요하다.

2. 오래된 플랫폼 투자가 AI 전환의 속도를 결정한다

   1. DevPod, Jaeger, Thrift·Protobuf 레지스트리, Bazel, Michelangelo, 서비스 메타데이터가 새 AI 도구의 기반이 됐다.
   2. AI 인프라가 1년 만에 만들어진 것처럼 보여도 실제로는 10년 이상의 개발자 생산성 투자가 누적된 결과다.

3. 모델·하네스 중립 계층을 먼저 세워야 한다

   1. Model Gateway는 모델 교체·보안·비용·감사·트레이스를 한곳에 모은다.
   2. AIFX와 MCP Gateway는 하네스나 프로토콜이 바뀌어도 도구·스킬·내부 서비스 접근 방식을 유지한다.

4. 검증 가능한 자동화가 자율성보다 먼저다

   1. Slate는 브랜치별 엔드투엔드 테스트를, Capri는 실제 운영 조합의 캡처·재생을 제공한다.
   2. Code Inbox와 위험도 점수는 인간 리뷰를 없애기보다 중요한 변경에 사람의 시간을 집중시킨다.

5. 생산성의 단위를 기능으로 바꿔야 한다

   1. PR·코드량·토큰량 대신 feature velocity, 품질, 출시 시간, 사용자 가치를 측정해야 한다.
   2. maintenance 자동화로 확보한 시간은 실제 기능 개발과 제품 실험에 재투자해야 한다.

6. Uday가 강조한 핵심 역량

   1. “엔지니어링의 일은 에이전트가 신뢰할 수 있는 결과를 만들도록 올바른 컨텍스트를 구축하는 일이다.”
   2. “컨텍스트 엔지니어링, 멀티태스킹, 결과를 리뷰하고 검증하는 능력이 이제 훨씬 중요해졌다.”
   3. 올바른 맥락을 주고, 병렬 작업을 관리하고, 자동화 결과를 검증하는 사람이 에이전트 시대의 생산성을 결정한다.

7. 개인 작업에도 적용되는 패턴

   1. Uday는 최근 Instinct, Muse, Grok Bot 같은 개인용 에이전트를 사용해 수동적인 개인 업무를 자동화한다고 말했다.
   2. 개인 업무도 필요한 컨텍스트와 입력을 충분히 주고, 사람이 결과를 확인하는 human-in-the-loop 단계를 두면 안전하게 자동화할 수 있다.

주요 발언 모음

“엔지니어링의 일은 어떤 의미에서 에이전트가 신뢰할 수 있는 출력을 만들도록 올바른 컨텍스트를 구축하는 것이다.”

“컨텍스트 엔지니어링, 멀티태스킹, 그리고 출력물을 리뷰하고 검증하는 능력이 이제 훨씬 중요해졌다. 이전보다 훨씬 더 많이 병렬화할 수 있기 때문이다.”

“엔지니어의 삶을 더 쉽게 만들기 위해 만든 모든 것이 에이전트의 삶도 더 쉽게 만든다.”

“생산 PR의 수가 늘었다고 가치가 늘어난 것은 아니다. 중요한 질문은 추가 처리량이 새로운 기능을 여는 데 쓰였는가이다.”

“하네스는 쉬운 부분이다. 어려운 부분은 하네스 주변의 모든 것이다.”

“우리는 먼저 모든 신호를 올바른 곳에 모아 리뷰를 쉽게 만드는 일을 해야 한다. 자동 병합은 그 다음이다.”

핵심 데이터 & 수치

• 2015년 서비스 수: Dispatch와 API, 총 2개.
• 2019년 전후 서비스 수: 수천 개.
• 현재 서비스 수: 약 4,500~5,000개이며 과거보다 더 적정한 크기로 통합됨.
• 사업 성장: 2026년 사업 규모는 2019년보다 약 10배 크지만 서비스 수는 비슷한 수준.
• 초기 엔지니어링 조직: 약 600명, 마켓플레이스 팀 50~60명.
• 글로벌 기술 거점: 12개.
• M3DB 처리량: 초당 약 5억 개 메트릭.
• Context Graph: 100개 초과 노드 유형, 130개 초과 엣지 유형.
• Skills 저장소 사용량: 하루 약 30,000회 실행.
• Minion 기여도: 프로덕션 PR의 약 15%.
• CI 증가: 12개월 동안 CI 작업이 두 배 이상 증가해 내부 code red 발생.
• 토큰 비용 절감: 최근 몇 달 동안 약 50% 감소.
• 기능 지표: diff velocity에서 feature velocity로 전환.
• 기존 그래프 기반: 우버 프로덕션 그래프는 수십억 개 노드를 다룸.

보조 안내 및 언급된 제품

1. 도입·협찬 메시지

   1. turbopuffer: 객체 스토리지 기반 검색 저장소를 처음부터 다시 설계하는 팀으로 소개됐다. v3는 벡터 기본 인덱스를 버리고 모든 인덱스를 컬럼형 저장소에 통합하며 벡터화 쿼리 엔진을 사용한다. 배치 읽기로 전체 텍스트 검색 속도를 9배 높인 사례가 언급됐다.
   2. Linear Diffs: 이슈·프로젝트 옆에서 PR을 리뷰하고, 큰 PR의 핵심 변경과 보조 코드를 나눠 안내하며 stacked PR을 지원한다.
   3. WorkOS Airlock: 에이전트의 의도와 규칙을 바탕으로 도구 호출을 허용·거부하거나 사람에게 승인 요청을 보내는 권한 계층이다. 자격 증명을 에이전트에 노출하지 않고 판정을 기록한다.

2. 관련 참고 항목

   1. 우버의 AI 개발 방식, 첫 CTO Thuan Pham과의 확장 이야기, 클라우드 전환, 플랫폼·프로그램 분리, 관측성 플랫폼, 엔지니어링 생산성, 개발자 경험이 추가 참고 주제로 제시됐다.
   2. Uday Kiran Medisetty의 X와 LinkedIn이 추가 연락처로 안내됐다.

핵심 요약 (20줄)

1. 우버의 AI 개발 생산성은 최신 모델보다 10년 이상 누적된 개발자 플랫폼 투자에 크게 의존한다.

2. Uday Kiran Medisetty는 2015년 5월 두 서비스만 존재하던 우버에 합류해 실시간 API와 여러 사업 플랫폼을 거쳤다.

3. RT API는 4초 주기 전체 상태 전송을 REST와 push 프로토콜로 확장해 승객·운전자 앱의 실시간 변화를 처리했다.

4. 우버는 사업 확장기에 두 서비스에서 수천 개로 늘어난 서비스를 Go·Java 표준화와 플랫폼화로 다시 적정 규모로 통합했다.

5. uOwn, M3DB, Michelangelo, Cadence, Morpheus는 범용 제품이 감당하지 못한 우버 고유의 규모와 도시 모델에서 탄생했다.

6. 도시 단위 샤딩과 리전 failover는 관측성·실험·배포·신뢰성을 관통하는 우버 특유의 인프라 프리미티브다.

7. DevPod는 언어별 모노리포의 빌드 캐시와 표준 도구를 제공하며 인간과 에이전트가 같은 작업공간을 사용하게 한다.

8. Mega DevPod와 Agents.md·Claude.md는 에이전트가 여러 저장소를 넘나들며 일관된 빌드·테스트를 수행하게 한다.

9. Model Gateway는 다양한 상용·오픈 모델을 하나의 API 뒤에 두고 AI Guard, 비용 귀속, 감사 로그, 세션 트레이스를 통합한다.

10. AIFX는 Claude Code, Codex, OpenCode 사이에서 설정·스킬·플러그인을 보존하며 하네스 교체 비용을 낮춘다.

11. 소비 티어와 CostCheck는 가치 있는 작업을 막지 않으면서 토큰 낭비를 줄이고 최근 토큰 비용을 약 50% 낮추는 데 기여했다.

12. MCP Gateway는 Thrift·Protobuf 레지스트리에서 내부 서비스 도구를 자동 생성하고 Google·Slack 같은 외부 도구도 같은 방식으로 제공한다.

13. MCP를 CLI로도 투영하면 스킬이 불필요한 도구를 컨텍스트에 상주시켜 발생하는 토큰 부담을 줄일 수 있다.

14. Context Graph는 사람·PR·문서·서비스·온콜·쿼리를 연결해 Cortana가 더 적은 왕복으로 정확한 조직 지식을 찾게 한다.

15. Minion은 Mega DevPod에서 계획을 실행해 여러 저장소의 PR을 만들며 현재 프로덕션 PR의 약 15%를 담당한다.

16. AIFX Validate, 시각 검증, Self-healing CI는 에이전트가 PR 전에 검사하고 실패를 수정하는 inner loop를 만든다.

17. Code Inbox는 위험도·blast radius·스크린샷·영상·검사 결과를 모아 인간이 중요한 PR에 리뷰 시간을 집중하게 한다.

18. Slate는 Jaeger baggage로 테스트 계정을 브랜치 환경에 라우팅하고 Capri는 실제 운영 트래픽을 캡처·재생해 조합별 회귀를 찾는다.

19. Shepherd와 Fox는 대규모 마이그레이션과 주기적인 dead code·성능·로그 정리를 관리형 에이전트 루프로 바꾼다.

20. 에이전트 시대의 핵심 엔지니어 역량은 컨텍스트 엔지니어링, 병렬 작업 관리, 결과 검증이며 생산성 지표는 diff velocity에서 feature velocity로 이동한다.