Uber의 에이전틱 SDLC와 소프트웨어 팩토리

URL: https://www.youtube.com/watch?v=17-YSUHo6Lk 날짜: 2026-08-22 채널: aiDotEngineer 원문 제목: Agentic SDLC at Uber — Uday Kiran Medisetty & Adam Huda, Uber 발표자: Uday Kiran Medisetty, Adam Huda 영상 길이: 1,106초

---

📌 핵심 질문 / 핵심 논점

==모델 하나를 붙이는 수준을 넘어 모델 게이트웨이, MCP 게이트웨이, 실행 환경, 스킬 마켓플레이스, 컨텍스트 그래프, Cortana를 하나의 소프트웨어 팩토리로 연결해야 에이전틱 AI가 개발 생명주기 전체의 처리량과 품질을 동시에 높일 수 있다.==

• Uber는 수천 명의 엔지니어와 12개 글로벌 기술 사이트를 대상으로 에이전트 기반 개발을 운영한다.
• 최근 1년 동안 로컬 또는 클라우드 에이전트가 만든 PR의 비중이 70%를 넘었고, 엔지니어 1인당 코드 라인 수는 전년 대비 2배가 됐다.
• 모델·도구·환경·지식·제품 표면을 통합하면 아이디어 검증부터 유지보수까지의 반복 작업을 빠르게 수행하면서 보안, 비용, 품질, CI 용량을 함께 통제할 수 있다.

Uday Kiran Medisetty는 먼저 여섯 가지 기반 블록을 제시하고, Adam Huda는 월드컵 경기장 픽업 기능을 아이디어에서 유지보수까지 통과시키는 사례로 이 블록들의 결합 방식을 보여준다. 핵심 변화는 코딩 에이전트를 배치하는 데서 멈추지 않고, 에이전트가 안전한 모델과 도구를 쓰고, 재현 가능한 환경에서 실행되며, 조직 지식을 찾아 검증하고, 사람에게 신뢰 가능한 결과를 넘긴 뒤, 운영 단계의 반복 작업까지 관리하는 구조를 만드는 데 있다.

1. 배경과 성과의 기준선

1.1. 발표 구성과 Uber의 개발 규모

1. 두 단계로 나뉜 발표 구조

   1. Uday는 Uber가 투자 중인 핵심 building blocks를 여섯 가지로 나눠 설명한다.
   2. Adam은 그 블록들을 이용해 하나의 기능을 end-to-end로 설계·구현·검증·유지보수하는 흐름을 이어서 보여준다.
   3. 여섯 블록은 Uber 내부에서 성숙도와 rollout 단계가 서로 다르며, 완성된 단일 제품이 아니라 실제 확장 중인 플랫폼 집합이다.

2. 조직과 코드베이스의 규모

   1. Uber에는 여러 글로벌 기술 사이트에 걸쳐 수천 명의 엔지니어가 있다.
   2. 6년 동안 monorepo와 Bazel로 이동한 투자가 대규모 코드베이스에서 에이전트를 가속할 수 있는 기초가 됐다.
   3. 수백만 줄의 코드가 있는 대형 monorepo에서 검색, 빌드, 의존성 탐색을 빠르게 만드는 기반이 없으면 장시간 실행 에이전트의 이점이 제한된다.

1.2. 에이전틱 AI의 정량적 변화

1. PR 생성의 변화

   1. 최근 1년 동안 Uber PR의 70% 이상이 로컬 에이전트 또는 클라우드 에이전트의 도움으로 만들어졌다.
   2. 여기서 PR 비중은 단순한 코드 자동완성 사용률이 아니라, 실제 변경을 만들고 검토 흐름에 들어온 결과를 뜻한다.

2. 개발 처리량과 toil 감소

   1. 엔지니어 1인당 연간 코드 라인 수는 전년 대비 2배가 됐다.
   2. 효과는 코딩에 국한되지 않고 엔지니어링 생명주기의 여러 단계로 확장됐다.
   3. 자동화된 migration은 250건을 넘었고, 엔지니어 대신 자동으로 처리한 코드 규모는 900만 줄을 넘었다.
   4. 따라서 목표는 사람을 코드 작성 화면에서 밀어내는 것이 아니라, 반복적인 toil을 대규모로 없애고 엔지니어가 더 높은 수준의 판단에 집중할 수 있게 만드는 데 있다.

2. 여섯 가지 기반 블록

2.1. 모델 게이트웨이(Model Gateway): 안전한 단일 진입점

모든 내부·외부 모델 사용을 하나의 호환 엔드포인트와 미들웨어 계층으로 통과시키면 보안, 비용, 관측성을 모델별 구현에서 공통 플랫폼으로 끌어올릴 수 있다.

1. 초기에 고정한 세 가지 원칙

   1. 기본 설정에서 개인식별정보(PII)가 Uber의 perimeter 밖 vendor로 절대 나가지 않게 한다.
   2. 게이트웨이에 추가하는 guardrail의 지연시간(latency)은 엄격한 상한 안에 둔다.
   3. 모든 요청을 사용자(user), 프로젝트(project), 팀(team) 단위로 귀속할 수 있게 한다.

2. 단일 호환 엔드포인트와 미들웨어

   1. 내부 사용 사례와 coding harness, 외부 모델 사용 사례가 모두 하나의 OpenAI·Anthropic 호환 엔드포인트를 사용한다.
   2. 첫 번째 계층은 SPIRE를 이용한 identity와 authentication이다.
   3. data anonymizer는 20개가 넘는 PII 유형을 redaction한다.
   4. AI guard는 안전성과 정책 준수를 확인하는 다섯 개의 specialized model로 여러 검사를 수행한다.
   5. 이 미들웨어 전체의 처리는 100밀리초 이내에 끝나도록 설계됐다.
   6. 같은 계층에서 caching과 token optimization 전략도 함께 적용한다.

3. 귀속·비용·감사 데이터

   1. 요청마다 사내 catalog의 특정 project를 연결하고, caller·user·team별로 실시간 데이터와 data lake 양쪽에서 귀속한다.
   2. 이 귀속 정보는 포트폴리오 전체의 spend 제어와 guardrail을 통합적으로 적용하는 기반이 된다.
   3. audit log와 session trace를 수집해 benchmarking과 self-improvement loop에 연결한다.
   4. 엔지니어는 vanilla client에 project ID만 설정하면 되고, 인증·익명화·정책 검사·기록·라우팅은 게이트웨이가 맡는다.

4. 운영 규모

   1. 현재 800개가 넘는 내부 project가 모델 게이트웨이를 통과한다.
   2. 전체 요청량은 하루 1억 건이 넘는다.
   3. 대상에는 frontier model뿐 아니라 Uber 인프라나 vendor가 호스팅하는 open-source model도 포함된다.

2.2. MCP 게이트웨이(MCP Gateway): 도구 접근의 표준화

에이전트가 수천 개의 내부 API와 SaaS 도구를 일관된 방식으로 발견·인증·호출하도록 MCP 접근을 한 곳으로 모으고, 도구 수가 늘면서 생기는 token tax를 줄인다.

1. MCP를 직접 연결하기 어려웠던 이유

   1. Uber에는 수천 개의 내부 API가 있었지만 처음부터 agent-accessible하게 만들어진 것은 아니었다.
   2. Google, Slack, Jira 같은 SaaS 도구마다 인증 방식과 setup 방식이 달라 엔지니어가 각각을 배워야 했다.
   3. MCP가 충분히 많아지면 각 도구의 설명과 응답이 컨텍스트를 잠식하는 massive token tax가 생긴다.

2. 자동 투영과 단일 설치 경로

   1. 자동 crawler가 내부 API와 project를 스캔하고 설정 한 번으로 MCP 형태로 투영한다.
   2. Google·Slack·Jira 등 SaaS MCP도 같은 게이트웨이를 통과하며, Uber가 호스팅과 token exchange를 처리한다.
   3. 엔지니어와 직원은 하나의 진입점과 공통 설치 방식으로 어떤 MCP든 사용할 수 있다.
   4. 도구마다 다른 인증과 설치 절차를 감추면서 내부 API와 외부 SaaS를 같은 경험으로 묶었다.

3. 토큰 최적화의 단계적 발전

   1. 초기에는 필요한 MCP를 각각 직접 연결하는 direct MCP 패턴을 사용했다.
   2. 올해 초에는 하나만 설치하면 게이트웨이 안의 MCP를 발견하고 호출하는 Omni MCP를 만들었다.
   3. 몇 달 뒤에는 MCP를 CLI pattern으로 투영해 도구 응답이 에이전트 컨텍스트를 과도하게 차지하지 않게 했다.
   4. 최근에는 자동 설치되는 code mode skill이 실행 시점에 Python script를 만들고, token을 가장 많이 소비하는 일부 사용 사례를 hyper-optimize한다.

4. 효과

   1. 게이트웨이에는 1,000개가 넘는 MCP tool이 연결돼 있다.
   2. 위 최적화만으로 fleet 전체 토큰 사용량을 40% 넘게 절감했다.

2.3. 에이전트 실행 환경(Agentified DevPod): 빠르고 격리된 작업 공간

장시간 실행되는 에이전트에는 빠르게 준비되고, 서로 격리되며, 여러 개를 동시에 설치할 수 있고, 전 세계 사이트에서 접근할 수 있는 환경이 필요하다.

1. DevPod에서 agentified DevPod로

   1. Uber는 수년 동안 대형 monorepo를 다루기 위해 cloud remote environment인 DevPod를 사용해 왔다.
   2. 수백만 줄의 코드와 복잡한 빌드 구조가 엔지니어 작업 방식에 이미 반영돼 있었기 때문에, 새로운 에이전트 환경을 완전히 별도로 만들지 않고 기존 DevPod를 agentified했다.
   3. 에이전트는 짧은 질의뿐 아니라 오래 실행되는 작업도 수행하므로 시작 속도와 실행 지속성이 중요하다.

2. 사전 프로비저닝

   1. Kubernetes의 pre-provisioned balloon pod를 미리 준비해 둔다.
   2. 에이전트가 새 환경을 요청하면 대기 중인 pod를 가져간다.
   3. 저장소 snapshot과 search index가 이미 준비돼 있어 에이전트가 수초 안에 작업을 시작한다.
   4. 격리된 환경을 여러 개 동시에 만들 수 있어 병렬 autonomous coding에 적합하다.

3. Mega DevPod와 역할의 변화

   1. 예전에는 Go, Java, Android처럼 언어별 flavor의 DevPod를 제공했다.
   2. 에이전트와 엔지니어가 여러 repository를 넘나들면서 언어별 경계가 흐려졌고, 모든 repository를 한곳에 둔 mega DevPod가 필요해졌다.
   3. autonomous coding agent는 이 공통 공간에서 front end와 back end를 함께 다룬다.
   4. 비엔지니어 직원도 agent harness를 수초 만에 시작할 수 있는 단순한 진입 경로를 제공받는다.

2.4. 관리형 스킬 마켓플레이스(Managed Skills Marketplace)

스킬을 개인이 만들어 흩어 놓는 대신 중복·발견·품질 문제를 관리하는 수명주기를 만들면 조직 지식을 재사용 가능한 실행 단위로 바꿀 수 있다.

1. 스킬 확산에서 발견한 세 가지 문제

   1. 여러 repository에서 서로 다른 엔지니어가 같은 기능의 스킬을 중복 제작했다.
   2. 필요한 스킬을 어디서 찾고 어떤 configuration으로 실행해야 하는지가 큰 hassle이었다.
   3. 많은 스킬의 품질이 subpar해 에이전트 결과의 일관성을 해쳤다.

2. 마켓플레이스와 품질 기준

   1. 공통으로 쓰는 core skill과 특정 영역에서 쓰는 domain-specific skill을 관리형 마켓플레이스에 등록한다.
   2. 현재 등록된 스킬은 2,500개다.
   3. 각 스킬은 lint check와 automated review를 통과해야 하며, 이 검사가 baseline skill quality를 보장한다.
   4. 생태계의 어떤 plugin이든 한 번의 공통 명령으로 발견하고 설치할 수 있다.
   5. engineer persona에 따라 기본 스킬 일부를 자동 설치하므로 사용자가 직접 찾거나 설치하지 않아도 에이전트가 적절한 능력을 선택한다.

3. 평가와 지속 개선

   1. 최근에는 실행 trace와 사용자의 comment를 수집하고 continuous eval을 추가하는 데 투자하고 있다.
   2. 평가 결과를 스킬 author에게 돌려보내 품질을 계속 개선한다.
   3. 전체 fleet에서 스킬 실행은 하루 20,000회를 넘는다.

2.5. 컨텍스트 그래프(Context Graph): 흩어진 조직 지식의 연결

에이전트가 서비스 위치·의존성·소유자·코딩 패턴을 찾는 데 토큰과 시간을 쓰지 않도록 Uber의 시스템 지식을 하나의 그래프로 연결한다.

1. 기존 탐색의 병목

   1. 대규모 monorepo에서 에이전트는 실제 변경보다 먼저 서비스가 어디에 있는지 찾아야 한다.
   2. 해당 서비스의 dependency, owner, 따라야 할 pattern도 파악해야 한다.
   3. 필요한 정보는 Uber의 20~30개 시스템에 흩어져 있었고, 각 시스템마다 별도 skill과 MCP가 필요했다.
   4. 이 구조는 token 사용량과 latency를 늘리고, 매번 어떤 정보를 찾는지에 따라 결과를 예측하기 어렵게 만들었다.

2. 그래프의 구성

   1. Uber가 운영되는 방식을 하나의 context graph에 담았다.
   2. 그래프에는 150개의 unique node·edge type과 현재 4,000만 개의 entry가 있다.
   3. mobile app 구성 방식부터 back end, data lake까지 연결한다.
   4. design doc, Jira, incident, bug도 같은 연결망 안에서 참조할 수 있다.
   5. 에이전트가 조직 안에서 필요한 맥락을 빠르게 찾을 수 있어 skill과 use case가 더 짧은 경로로 실행된다.

3. 연결되는 사용 사례와 예시 질문

   1. on-call RCA, planning, data analysis, security scan 등 여러 스킬과 사용 사례를 그래프에 연결하는 중이다.
   2. 간단해 보이는 질문인 “인도의 mobility trip 중 cash 결제는 몇 건인가?”에도 적절한 개념, 데이터 테이블, 도시 범위, SQL 생성 방식이 필요하다.
   3. context graph가 없으면 여러 시스템을 차례로 탐색해야 하지만, 그래프가 있으면 필요한 맥락을 더 적은 turn으로 모을 수 있다.
   4. 내부 평가에서 graph 사용은 token 수, turn 수, latency를 모두 크게 낮췄고, 이런 개선이 특정 질문 하나가 아니라 여러 인프라 사용 사례에서 반복됐다.

2.6. Cortana: 전사 사용자에게 노출하는 공통 AI 표면

모델·MCP·스킬·컨텍스트 그래프를 Slack, CLI, web에 통합한 Cortana가 엔지니어와 비엔지니어가 같은 지식·도구 기반을 쓰게 한다.

1. 다중 표면의 공통 경험

   1. 직원은 Slack, CLI, web 어느 표면에서든 자연어 질문을 할 수 있다.
   2. Cortana는 context graph를 조회하고, 적절한 skill을 호출하며, 어느 codebase의 코드든 확인할 수 있다.
   3. 그 결과 여러 repository와 조직 시스템을 가로지르는 답변을 한곳에서 얻는다.

2. 팀별 개인화

   1. 직원은 custom skill과 custom prompt를 연결할 수 있다.
   2. 이를 팀 Slack channel에 붙이면 Cortana가 해당 팀의 관례와 지식을 알고 일하는 teammate처럼 동작한다.
   3. 같은 질문을 Slack에서 호출하고 한 명 이상이 동일한 channel에서 결과를 함께 검토할 수 있다.

3. 최근 사용량

   1. 최근 한 달에 300개의 unique persona가 만들어졌다.
   2. 하루 session 수는 20,000회를 넘는다.
   3. 이 표면은 앞선 다섯 블록을 별도 제품으로 노출하는 대신 회사 구성원이 하나의 조력자로 경험하게 하는 packaging 계층이다.

3. 아이디어에서 프로토타입까지: 월드컵 경기장 픽업 기능

3.1. 문제 정의와 사업성 검토

1. 월드컵을 계기로 한 아이디어

   1. 월드컵처럼 사람이 몰리는 경기장을 빠져나오는 라이더(rider)가 군중을 피해 더 나은 pickup location으로 이동할 수 있게 하자는 아이디어를 세운다.
   2. 발표 중 “이 순간에는 월드컵 관련 아이디어가 좋겠다”는 가벼운 농담으로 시나리오를 시작한다.
   3. 팀은 Slack에서 아이디어를 주고받으며 Cortana를 대화에 태그한다.

2. Cortana의 사업성 조사

   1. context graph를 이용한 Cortana는 이 기능이 추구할 만한 business opportunity인지 검토한다.
   2. 과거에 어떤 large-scale venue event가 있었는지 조사한다.
   3. 어떤 stadium이 적합한지 비교해 사업성 가설을 구체화한다.
   4. Slack에서 시작한 조사 흐름은 Cortana web interface로 열어 더 넓은 business research를 수행한다.

3.2. 제품 요구사항과 디자인

1. 초기 rollout 범위

   1. 경기장이 있는 지역을 기준으로 우선 North America rollout으로 범위를 좁힌다.
   2. 모든 지역을 동시에 지원하기보다 데이터와 운영 조건이 맞는 범위에서 실험하도록 요구사항을 정리한다.

2. Figma와 A/B 실험

   1. Cortana가 초기 Figma mock-up 제작을 돕는다.
   2. 두 개의 variant를 만들어 A/B experiment를 준비한다.
   3. 두 variant는 button string을 다르게 두고 실제 성과를 비교한다.
   4. 어떤 문구가 사용자의 pickup 선택과 이동에 더 잘 작동하는지 실험으로 확인한다.

3. 기존 코드 활용과 정렬 시간 단축

   1. Cortana는 앱에 이미 있는 화면과 back end 기능 중 재사용할 수 있는 부분을 찾는다.
   2. 필요한 front-end code change와 back-end code change를 함께 식별한다.
   3. 과거에는 여러 팀이 정렬하고 요구사항을 합의하는 데 몇 주가 걸릴 수 있었다.
   4. 통합된 맥락과 설계 초안 덕분에 같은 흐름을 짧은 시간 안에 prototype까지 압축한다.

4. 프로토타입에서 PR까지: Minion과 검증 중심 SDLC

4.1. Minion을 이용한 cross-repository 구현

1. Cortana에서 Minion으로 handoff

   1. 구현 단계에서 Cortana agent의 결과를 Uber의 cloud coding agent인 Minion으로 넘긴다.
   2. Minion은 interactive mode와 autonomous mode를 모두 지원한다.
   3. 이번 사례는 DevPod 기반의 full build environment에서 진행된다.

2. front end와 back end의 동시 변경

   1. Minion은 여러 repository를 가로질러 작업할 수 있다.
   2. 월드컵 pickup 기능에 필요한 back-end 변경과 front-end 변경을 함께 만든다.
   3. 결과는 곧바로 CI에 넣지 않고 draft PR을 만드는 단계에서 멈춘다.

3. draft PR에서 멈춘 이유

   1. toil 성격의 작업은 에이전트가 곧바로 CI에 보내도 괜찮지만, 복잡한 end-to-end feature는 먼저 기능 자체를 검증해야 한다.
   2. 초기 생성물을 바로 CI에 보내면 아직 검증되지 않은 변경이 CI에 extra load를 만든다.
   3. CI push 전에 더 많은 검사를 inner loop에서 끝내면 실패를 더 일찍 발견하고 전체 피드백 비용을 줄일 수 있다.

4.2. Inner loop에서의 조기 검증

1. SDLC 두 루프의 역할

   1. 개발자 작업 중 빠르게 반복하는 inner loop와 CI·리뷰로 이어지는 outer loop가 있다.
   2. Uber는 기존 outer-loop 검사를 가능한 한 inner loop로 옮겨 agentified SDLC를 구성한다.

2. 정적 검사와 자동 수정

   1. 기존에 실행하던 static analysis check가 inner loop에서 먼저 동작한다.
   2. 문제가 발견되면 CI에 올리기 전에 에이전트가 수정한다.
   3. 이 방식은 생성 직후의 코드와 통합된 결과 사이의 간격을 줄인다.

3. 시각적 검증(Visual Validation)

   1. skill을 이용해 simulator를 실행한다.
   2. simulator screenshot을 가져와 Figma specification과 비교한다.
   3. 코드가 컴파일되는지만 보는 것이 아니라 버튼·화면 구성·시각적 결과가 설계와 맞는지 확인한다.

4. front-end와 back-end 통합 검증

   1. back-end service를 staging environment에서 띄운다.
   2. front end와 back end의 integration을 실제로 연결해 검증한다.
   3. 복잡한 기능에서 API 계약이나 화면 상태가 어긋나는 문제를 outer loop 진입 전에 찾는다.

4.3. Outer loop, self-healing CI, code review

1. CI의 self-healing

   1. inner loop에서 검사해도 CI에서 오류가 발생할 수 있다.
   2. self-healing CI는 CI에서 발견된 일정 범위의 문제를 자동으로 수정한다.
   3. 에이전트가 실패 원인을 확인하고 보완 diff를 만들어 반복 실패를 줄인다.

2. 코드 리뷰의 분할 배치

   1. code review의 일부는 빠른 inner loop로 이동한다.
   2. inner loop에는 더 작은 medium model을 사용해 빠르게 피드백한다.
   3. outer loop에는 reasoning 능력이 강한 model과 skill을 사용해 더 깊은 review를 수행한다.
   4. 속도가 중요한 검사와 깊이가 필요한 검사를 모델 크기와 실행 위치에 맞춰 나눈다.

3. 자율 diff에 대한 사람의 신뢰

   1. Minion이 만든 autonomous diff를 사람이 처음 생성된 코드만 보고 판단해서는 안 된다.
   2. PR에는 수행한 check 목록을 표 형태로 첨부한다.
   3. static check, 통합 검증, screenshot 비교를 포함해 어떤 self-improvement 단계를 통과했는지 보여준다.
   4. human reviewer는 diff뿐 아니라 에이전트가 이미 수행한 검증의 증거를 보고 리뷰 깊이를 결정할 수 있다.

5. 더 많은 코드 이후의 유지보수

5.1. Maintenance skill과 feature flag 정리

1. 유지보수도 자동화 대상이다

   1. software factory가 생성하는 코드가 많아질수록 maintenance가 더 중요해진다.
   2. feature 또는 service를 maintenance skill에 등록하면 운영 후 반복 작업을 관리형 루프로 돌릴 수 있다.

2. 월드컵 기능의 feature flag cleanup

   1. 초기 실험에는 A와 B 두 modal variant가 있다.
   2. 실험이 끝나 B variant가 더 이상 필요 없어지면 feature flag cleanup skill이 제거 diff를 만든다.
   3. 기능을 만드는 에이전트와 기능을 정리하는 에이전트를 별도로 두어 실험 잔여물을 방치하지 않는다.

5.2. 무제한 자동화가 아닌 관리형 루프

1. 공통 관리 표면

   1. 회사 전체에서 수천 개의 maintenance loop가 제멋대로 생기면 운영과 CI가 통제되지 않는다.
   2. 따라서 루프를 설정하는 managed surface를 제공하고, 모든 팀이 정해진 표면에서 실행 조건을 등록하게 한다.

2. 실행 시점과 diff 양 제어

   1. CI 용량이 더 여유로운 일요일에 cleanup loop를 실행한다.
   2. 월요일 아침 엔지니어에게 한꺼번에 많은 diff가 도착하지 않도록 월요일에 보여줄 diff 수를 제어한다.
   3. 자동화의 속도만 높이지 않고 사람의 review capacity와 CI capacity를 함께 관리한다.

3. 스킬 학습 데이터와 새 스킬 발굴

   1. maintenance skill이 만든 diff에는 reviewer comment가 달리고, diff가 실제로 land됐는지 land되지 않았는지가 기록된다.
   2. 이 comment와 수용 여부는 스킬 자체를 개선하는 데 쓸 수 있는 좋은 label data가 된다.
   3. 매월 incident review에서 반복되는 대응 패턴을 찾고, 이를 새로운 maintenance skill로 만들어 모든 service에 적용하는 방향을 추진한다.

6. 남은 병목과 결론

6.1. 관측·인프라·실험의 확장

1. 모니터링까지 확장되는 생명주기

   1. 구현과 검증 외에도 monitoring 같은 SDLC 단계가 남아 있다.
   2. 같은 building blocks와 하부 아키텍처를 monitoring과 운영 자동화에도 연결할 수 있다.

2. 인프라 병목

   1. 코드 생산량이 늘면서 CI와 다른 인프라에 더 큰 부하가 걸린다.
   2. Uber는 CI capacity가 언제 부족해질지 미리 예측하고, 그에 맞는 foundational investment를 해야 한다.
   3. 자동화를 확대하는 속도만큼 실행 인프라의 처리량과 격리·캐시 구조를 확장하지 않으면 software factory가 새 병목을 만든다.

3. 실험과 의사결정의 병목

   1. 실제로 실행할 수 있는 experiment 수에는 한계가 있다.
   2. 이제 핵심 질문은 “만들 수 있는가?”보다 “정말 만들어야 하는가?”에 가까워진다.
   3. 구현 비용이 낮아질수록 제품 우선순위, 사업성, 실험 슬롯, 사용자 가치에 대한 판단이 상대적으로 중요해진다.

6.2. 실무적 시사점

1. 에이전트 도입의 순서

   1. 먼저 모델 호출을 표준화하고 PII·정책·비용·추적성을 단일 gateway에서 확보해야 한다.
   2. 다음으로 도구 설치와 인증을 MCP gateway로 통합하고, 토큰 비용을 줄이는 호출 패턴을 제공해야 한다.
   3. 장시간 실행을 지원하는 격리 환경과 빠른 repository 준비가 있어야 자율 agent가 실제 작업을 맡을 수 있다.
   4. 스킬 품질과 조직 지식을 marketplace·eval·context graph로 관리해야 결과를 반복 재현할 수 있다.
   5. 마지막으로 Slack·CLI·web 같은 일상 표면에 통합해 사용자가 이 복잡성을 직접 조립하지 않게 해야 한다.

2. SDLC 운영 원칙

   1. 생성 직후의 inner loop에서 정적·시각·통합 검사를 빠르게 수행하고, outer loop에서 CI와 심층 review를 수행해야 한다.
   2. 자율 diff에는 검증 표와 screenshot 같은 증거를 붙여 사람의 신뢰를 확보해야 한다.
   3. 유지보수는 managed loop로 제한하고 실행 시점·diff 수·수용 여부를 관리해야 한다.
   4. 더 많은 자동화가 곧바로 더 나은 제품을 의미하지 않으므로 인프라 capacity와 build-or-not-build 의사결정을 같은 운영 체계에 넣어야 한다.

주요 발언 모음

“모든 요청을 사용자, 프로젝트, 팀 단위로 귀속할 수 있어야 한다.”

“모든 내부 사용 사례와 외부 사용 사례가 하나의 OpenAI·Anthropic 호환 엔드포인트를 통과한다.”

“스킬을 찾고 configuration하는 일이 큰 hassle이었고, 많은 스킬의 품질도 subpar했다.”

“에이전트가 처음 생성한 diff만 보는 것이 아니라 이미 많은 self-improvement를 거쳤다는 확신을 사람에게 줘야 한다.”

“이제 질문은 만들 수 있는가가 아니라 만들어야 하는가에 더 가깝다.”

핵심 데이터 & 수치

• 조직 규모: 수천 명의 엔지니어와 12개 글로벌 기술 사이트가 대상이다.
• 에이전트 PR 비중: 최근 1년 동안 로컬 또는 클라우드 에이전트가 관여한 PR이 70%를 넘었다.
• 코드 처리량: 엔지니어 1인당 코드 라인 수가 전년 대비 2배가 됐다.
• 자동화 성과: 250건이 넘는 migration과 900만 줄이 넘는 자동 코드 변경을 처리했다.
• 모델 게이트웨이: 800개가 넘는 project와 하루 1억 건이 넘는 model request를 처리한다.
• 모델 보안 계층: 20개가 넘는 PII 유형을 익명화하고, 다섯 개의 specialized AI guard model을 사용하며, 전체 guardrail latency를 100밀리초 이내로 유지한다.
• MCP 게이트웨이: 1,000개가 넘는 tool을 연결하고 token 사용량을 fleet 전체에서 40% 넘게 줄였다.
• 스킬 마켓플레이스: 2,500개의 skill과 하루 20,000회가 넘는 skill execution을 운영한다.
• 컨텍스트 그래프: 150개의 node·edge type과 4,000만 개의 entry를 보유하고, 20~30개 시스템의 지식을 연결한다.
• Cortana: 최근 한 달 300개의 unique persona가 생성됐고 하루 session이 20,000회를 넘었다.

영상 흐름 요약

• 00:00~01:20 — Uday가 여섯 building block과 Adam의 end-to-end feature 시연 구성을 소개하고, Uber의 에이전트 기반 PR·코드 처리량·migration 성과를 제시한다.
• 01:20~03:47 — model gateway의 PII, latency, attribution 원칙과 800개 project·하루 1억 요청 규모를 설명한다.
• 03:47~05:42 — MCP gateway의 자동 투영, SaaS 통합, Omni MCP·CLI·code mode를 통한 40% 이상 token 절감을 설명한다.
• 05:42~07:10 — DevPod를 agentified하고 pre-provisioned Kubernetes pod와 mega DevPod로 빠른 cross-repository 실행 환경을 만든다.
• 07:10~08:38 — 2,500개 스킬의 marketplace·lint·review·자동 설치와 trace·eval 기반 개선을 설명한다.
• 08:38~10:20 — 20~30개 시스템을 150개 type·4,000만 entry의 context graph로 묶고 토큰·turn·latency를 줄이는 사례를 제시한다.
• 10:20~11:34 — Cortana를 Slack·CLI·web에 통합하고 persona 개인화, 300개 persona, 하루 20,000 session을 제시한다.
• 11:34~13:18 — Adam이 월드컵 경기장 pickup 아이디어를 Slack·Cortana business research·North America 요구사항·Figma A/B prototype으로 구체화한다.
• 13:18~14:21 — Minion이 DevPod에서 front end와 back end를 함께 바꾸고 draft PR까지만 만든 뒤 조기 검증으로 넘긴다.
• 14:21~15:54 — inner loop의 static·visual·integration validation, outer loop의 self-healing CI와 모델별 code review 분할을 설명한다.
• 15:54~17:15 — feature flag cleanup을 managed maintenance loop로 실행하고, 일요일 실행·월요일 diff 제한·comment와 land 여부를 학습 데이터로 활용한다.
• 17:15~18:26 — monitoring, CI capacity, 실험 수, build-or-not-build 의사결정을 남은 병목으로 제시하고 다음 agentic code review 발표를 예고한다.

결론 및 시사점

1. Uber의 에이전틱 SDLC는 모델 호출 자동화가 아니라 보안·도구·실행·지식·사용자 표면·유지보수까지 연결하는 플랫폼 설계다.
2. 높은 PR 자동화 비중은 monorepo·Bazel·DevPod 같은 기존 개발 인프라와 모델·MCP·context graph 투자 위에서 가능해졌다.
3. 모델 gateway는 PII 경계, 정책, latency, 비용, 감사 로그를 공통 계층에서 해결해 개별 팀의 반복 구현을 줄인다.
4. MCP gateway는 API와 SaaS 도구의 인증·발견 문제를 단일 경로로 추상화하고, 호출 응답의 token tax를 줄인다.
5. agentified DevPod와 mega DevPod는 에이전트가 여러 repository를 빠르게 격리된 환경에서 다루게 한다.
6. managed skills marketplace와 continuous eval은 조직의 프롬프트·절차·도메인 지식을 재사용 가능한 자산으로 만든다.
7. context graph는 에이전트의 검색·추론 전 비용을 줄여 대형 조직에서 결과의 latency와 변동성을 낮춘다.
8. Cortana는 복잡한 플랫폼을 Slack·CLI·web의 공통 동료 경험으로 포장해 비엔지니어까지 사용 범위를 넓힌다.
9. Minion의 draft PR 전략은 고난도 기능을 무검증 상태로 CI에 보내지 않고 inner loop에서 조기에 실패시키는 방식이다.
10. screenshot과 Figma 비교는 코드·테스트 통과만으로 잡기 어려운 제품 표면의 오류를 찾는다.
11. outer-loop reasoning review와 inner-loop 빠른 review를 나누면 품질과 feedback speed를 동시에 조정할 수 있다.
12. PR에 검증 표를 첨부하면 사람은 autonomous diff의 생성 과정과 신뢰 근거를 함께 판단할 수 있다.
13. maintenance skill은 실험이 끝난 feature flag와 반복 운영 작업을 지속적으로 정리한다.
14. managed loop는 자동화가 CI와 엔지니어의 월요일 업무를 압도하지 않도록 실행 시간과 diff 양을 통제한다.
15. reviewer comment와 land 여부는 maintenance skill을 개선하는 실제 label data로 재사용된다.
16. incident review에서 추출한 반복 패턴은 모든 service에 적용할 새로운 maintenance skill 후보가 된다.
17. 자동 생성량이 늘어날수록 CI capacity와 인프라 예측이 제품 개발 속도를 결정하는 병목이 된다.
18. 실험 슬롯이 한정되므로 구현 가능성보다 사용자 가치와 사업적 우선순위를 판단하는 일이 더 중요해진다.
19. 에이전틱 SDLC의 성공 조건은 에이전트의 자율성 자체가 아니라 빠른 검증, 사람의 신뢰, 비용·보안·운영 통제의 결합이다.
20. 완성된 심층 노트는 /Users/flowkater/Obsidian/flowkater/flowkater/Study/YouTube다이제스트/2026-08-22-aiDotEngineer-Agentic-SDLC-Uber.md 경로에 저장했다.

핵심 요약 (20줄)

1. Uber는 수천 명의 엔지니어와 12개 글로벌 기술 사이트에서 에이전틱 AI를 소프트웨어 개발 생명주기 전체에 적용한다.

2. 최근 1년 동안 로컬 또는 클라우드 에이전트가 관여한 PR 비중은 70%를 넘었고 엔지니어당 코드 라인 수는 2배가 됐다.

3. 250건이 넘는 자동 migration과 900만 줄이 넘는 코드 변경이 반복적인 toil을 대규모로 줄였다.

4. 6년 동안 추진한 monorepo와 Bazel 전환은 대형 코드베이스에서 에이전트가 빠르게 탐색하고 빌드하는 토대가 됐다.

5. 모델 게이트웨이는 PII 경계, guardrail latency, 사용자·프로젝트·팀별 귀속을 모든 모델 요청에 일관되게 적용한다.

6. SPIRE 인증, 20개가 넘는 PII redaction, 다섯 개의 AI guard model이 100밀리초 이내의 공통 계층에서 동작한다.

7. 800개가 넘는 프로젝트가 하루 1억 건 이상의 frontier 및 open-source model 요청을 모델 게이트웨이로 보낸다.

8. MCP 게이트웨이는 내부 API와 Google·Slack·Jira 같은 SaaS 도구를 하나의 인증·설치·호출 경로로 통합한다.

9. Omni MCP, CLI pattern, code mode skill은 1,000개가 넘는 도구의 token tax를 줄여 fleet 전체 사용량을 40% 이상 절감했다.

10. pre-provisioned Kubernetes pod와 snapshot·search index를 갖춘 mega DevPod는 에이전트가 수초 안에 격리된 작업을 시작하게 한다.

11. 관리형 스킬 마켓플레이스는 2,500개 스킬에 lint와 automated review를 적용하고 persona별 기본 스킬을 자동 설치한다.

12. 하루 20,000회가 넘는 스킬 실행 trace와 continuous eval은 스킬 author가 결과를 반복 개선할 수 있는 feedback을 만든다.

13. context graph는 150개 node·edge type과 4,000만 개 entry로 20~30개 시스템의 조직 지식을 연결한다.

14. Cortana는 Slack·CLI·web에서 context graph, skill, 다중 codebase를 호출하는 전사 AI 동료이며 하루 20,000회가 넘는 session을 처리한다.

15. 월드컵 경기장 pickup 아이디어는 Slack 토론, Cortana 사업성 조사, North America 요구사항, Figma A/B prototype으로 빠르게 구체화된다.

16. Minion은 DevPod에서 front end와 back end를 함께 수정하지만 검증되지 않은 복잡한 기능을 CI에 바로 보내지 않고 draft PR에서 멈춘다.

17. inner loop는 static analysis, simulator screenshot과 Figma 비교, staging back-end 통합 검사를 CI 이전에 수행한다.

18. outer loop는 self-healing CI와 강한 reasoning model의 심층 code review를 맡고 PR에는 수행한 검증 표를 첨부한다.

19. maintenance skill은 feature flag cleanup을 일요일 managed loop로 실행하고 diff 수, reviewer comment, land 여부를 품질 개선에 활용한다.

20. 구현 가능성보다 만들어야 할 이유와 CI capacity가 중요해진 상황에서 심층 노트는 위 Obsidian 경로에서 확인할 수 있다.