Uber의 디버깅 에이전트 하네스 구축 방법

URL: https://www.youtube.com/watch?v=6YuIp-MwPv4 날짜: 2026-10-08 채널: Tech Bridge

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==운영 장애 디버깅에 필요한 데이터 수집·분석·수정·검증의 전 과정을 통제된 에이전트 하네스로 연결하면, 대규모 모노레포 환경에서도 개발자의 디버깅 시간을 크게 줄이고 실제 수정 PR까지 자동화할 수 있다.==

• Uber는 Wisdom과 Healthline으로 사용자 신고, 앱 상태, 로그, 스택 트레이스, 크래시 덤프를 수집한다.
• Debug Assist는 사전에 정한 LangGraph 파이프라인 안에서 분류, 근본 원인 분석(RCA), 완화, 코드 수정, 테스트, PR 생성까지 수행한다.
• 에이전트가 임의로 계획을 세우게 두지 않고 결정론적 노드, 제한된 턴 수, 런타임 플러그인, 증거 타임라인으로 환각과 비용을 통제한다.
• 공통 실행 하네스는 제공하되 도메인별 스킬과 서브에이전트는 각 팀이 가져오게 하여 Uber 규모로 확장한다.

운영 이슈는 오류 메시지가 모호하고 코드·로그·설정·데이터가 흩어져 있으며, 여러 팀이 하나의 모노레포에 기여하고 교차 팀 의존성이 얽혀 있어 어렵다. Debug Assist는 이 맥락을 한곳으로 모아 30분 이내의 심층 RCA와 검증된 수정 제안을 목표로 하며, 사람이 최종 검토·배포할 수 있는 형태로 결과를 전달한다.

1. 운영 디버깅이 어려운 이유와 데이터 기반

Debug Assist의 출발점은 개발자가 빈 화면, 멈춤, 배터리 소모 같은 현상을 재현하기 전에 이미 충분한 증거를 확보하는 것이다.

1.1. Wisdom 인앱 버그 리포터

1. 사용자와 신고 흐름

   1. Uber 내부 직원과 베타 테스터는 베타 버전의 Uber 앱 안에서 버그를 직접 신고할 수 있다.
   2. 화면이 갑자기 빈 화면이 되거나 앱이 멈추거나 배터리 문제가 생겼을 때 간단한 자연어 설명과 함께 신고 버튼을 누른다.
   3. 신고자는 “화면이 비어 있다” 또는 “Uber 앱이 배터리 사용량의 거의 30%를 차지하고 휴대폰이 뜨거워진다”처럼 현상을 짧게 적어도 된다.

2. 자동 수집되는 맥락

   1. 제품 내부 명칭은 Wisdom이며, 자연어 버그 설명과 함께 문제가 발생한 앱, 앱 버전, 운영체제(OS), 사용자가 문제를 겪은 도시를 기록한다.
   2. 네트워크 로그, 분석(analytics) 로그, 콘솔 로그, GraphQL 로그, UI 상태 로그 등 다수의 로그를 함께 저장한다.
   3. 문제가 발생한 기기의 스크린샷도 수집한다. 디버깅에 필요한 Uber 앱 화면만 캡처하므로 보안 우려를 줄일 수 있다.
   4. 개발자가 직접 올린 추가 스크린샷도 자연어 신고와 함께 분석 자료가 된다.

1.2. Healthline 자동 품질 분석

1. 자동 감지되는 앱 품질 문제

   1. Healthline은 앱 품질 분석 도구이며, Wisdom처럼 신고를 기다리지 않고 백엔드에서 자동으로 동작한다.
   2. 앱 크래시, 멈춤(hang), 화면 지터(jitter), 성능 저하가 발생하면 해당 세션의 분석을 시작한다.

2. 재현과 원인 추적에 필요한 자료

   1. 세션 ID, 분석 ID, 문제 직전에 사용자가 무엇을 했는지와 같은 메타데이터를 저장한다.
   2. Wisdom에서 수집하는 네트워크·분석·콘솔·GraphQL·UI 상태 로그와 그 밖의 로그를 함께 보관한다.
   3. Healthline은 여기에 스택 트레이스(stack trace)와 전체 크래시 덤프(crash dump)를 추가한다.
   4. 따라서 어떤 코드가 문제를 일으켰는지까지 추적할 수 있다.

1.3. 규모와 개발자 경험의 문제

1. 운영 부담

   1. Wisdom과 Healthline을 통해 해마다 거의 50,000건의 이슈가 엔지니어에게 배정된다.
   2. 그중 90%는 고객에게 영향을 주는 이슈이며, 엔지니어링 팀으로 약 12,000건의 페이지 알림이 발송된다.
   3. 새벽 2시에 페이지를 받고 흐릿한 정신으로 어디서부터 살펴봐야 할지 모른 채 밤새 운영 이슈를 디버깅하는 상황이 반복된다.

2. 맥락이 흩어지는 구조

   1. 오류는 “문제가 발생했습니다”처럼 원인이 드러나지 않는 경우가 많다.
   2. 개발자는 익숙하지 않은 코드 로직을 따라가면서 코드, 로그, 설정, 데이터 사이를 오가야 한다.
   3. 데이터 접근에 필요한 내부 도구가 많아 조사 경로가 길어진다.
   4. Uber는 여러 모노레포(mono repo) 구조로 운영되며, 하나의 저장소에 많은 팀이 기여한다.
   5. 문제를 일으킨 팀을 찾아도 실제 코드는 다른 팀이 소유하고 있을 수 있고, 같은 팀 안에서도 모든 코드를 알고 있기는 어렵다.

3. 시간 비용

   1. Uber 엔지니어가 이슈 하나를 해결하는 데 걸리는 평균 시간은 거의 28일이다.
   2. Stripe가 공개한 보고서에서는 개발자 업무 시간의 40%가 디버깅에 쓰인다고 집계했다.
   3. Debug Assist는 개발자가 반복적인 원인 탐색보다 개발과 수정에 집중하도록 앱 품질과 디버깅 경험을 개선하는 것을 목표로 삼는다.

2. Debug Assist의 엔드투엔드 해결 여정

파이프라인은 이슈 발견부터 최종 수정까지의 흐름을 단계별로 고정한다.

2.1. 발견과 자동 트리아지

1. Discovery

   1. Healthline의 자동 감지와 Wisdom의 사용자·직원 신고가 이슈 발견의 입구가 된다.
   2. 두 시스템이 수집한 신고 설명, 메타데이터, 스크린샷, 로그, 크래시 자료가 이후 단계의 입력이 된다.

2. Auto triage

   1. 이슈의 우선순위와 심각도를 판정한다.
   2. 실제 소유 팀과 담당자를 찾고, 누구를 온콜(on-call)로 태그해야 하는지 결정한다.

2.2. RCA와 실행 가능한 해결

1. 심층 근본 원인 분석

   1. Debug Assist는 30분 이내에 심층 RCA를 수행하는 것을 목표로 한다.
   2. 단순히 로그를 개발자에게 덤프하지 않고, 원인·근거·영향 범위·다음 행동을 연결해 결과를 실행 가능한 형태로 만든다.

2. 최종 해결

   1. 가능한 경우 기능 플래그를 되돌려 이슈를 먼저 완화한다.
   2. 코드 수정, 테스트, diff 또는 PR 생성까지 이어 가며 개발자는 결과를 검토하고 배포한다.
   3. PR은 Healthline이나 Wisdom의 원래 이슈와 Jira에 연결되고 Slack으로 담당 개발자에게 전달된다.

2.3. 배터리 회귀 사례

1. 신고와 자동 수정

   1. Uber 개발자가 출근을 위해 차량을 호출한 뒤 휴대폰이 주머니에서 뜨거워지는 것을 느끼고 Wisdom에 버그를 신고했다.
   2. 신고 내용은 Uber 앱이 배터리 사용량의 거의 30%를 차지하고 휴대폰이 과열된다는 한 문장이었다.
   3. 개발자가 차량 안에서 사무실까지 이동하는 약 20분 동안 Debug Assist는 버튼을 한 번 누르지 않고 수정안을 만들었다.
   4. 개발자에게 남은 일은 수정안을 검토하고 배포하는 것이었다.

2. 증거에 기반한 원인

   1. 수집된 스크린샷에는 Uber 앱이 배터리 사용량의 29%를 차지하는 상태가 나타났다.
   2. RCA는 백그라운드에서 실행되어야 할 코드 경로가 포그라운드 루프처럼 처리된 hot loop임을 찾아냈다.
   3. 잘못된 루프 처리로 CPU 사이클 사용량이 커지고 배터리 회귀가 발생했다.
   4. 앱은 포그라운드가 아니라 17분 동안 백그라운드에 있었다는 사실도 분석 결과에 포함됐다.
   5. 오른쪽의 evidence timeline은 각 결론이 어느 로그·상태·시간 정보에서 나왔는지 보여 주어 에이전트의 환각 여부와 수정안의 신뢰도를 판단하게 한다.

2.4. 푸시 알림 크래시 사례

1. 고심각도 장애

   1. 잘못된 롤아웃 뒤 사용자가 푸시 알림을 아주 빠르게 누르면 Uber 앱이 크래시하는 문제가 발생했다.
   2. 고객 영향이 큰 고심각도 이슈여서 P1(priority one)으로 표시됐다.

2. 당일 수정

   1. Debug Assist는 문제를 일으킨 코드를 특정하고 깊은 RCA와 수정안을 만들었다.
   2. 수정안은 Slack 메시지로 개발자에게 전달됐다.
   3. 5% 롤아웃 단계에서 크래시를 포착했고, 같은 날 수정안을 병합하고 배포했다.

3. LangGraph 기반 에이전트 하네스

고정된 파이프라인과 LLM 노드의 조합이 에이전트의 자율성을 필요한 범위로 제한한다.

3.1. 계획을 통제하는 파이프라인

1. 결정론적 노드와 LLM 노드의 혼합

   1. Debug Assist는 LangGraph 파이프라인 위에 구축됐으며, 결정론적 노드와 LLM 노드를 섞는다.
   2. 일반 에이전트가 계획 단계와 실행 단계를 스스로 만들 수 있는 것과 달리, 필요한 실행 계획을 미리 제공한다.
   3. 매번 따라야 할 단계를 고정하면 LLM이 잘못된 계획을 세워 문제를 수정하려는 과정에서 생기는 환각을 줄일 수 있다.

2. 초기 설계 원칙

   1. 모든 기능을 에이전트로 처리하지 않는다.
   2. 이미 알고 있는 API에서 데이터를 가져오는 일은 결정론적 코드로 실행해 에이전트의 컨텍스트 팽창, API 지연, LLM 비용을 피한다.
   3. 거대한 로그를 그대로 LLM에 넣지 않고 파싱, 전처리, 가지치기(pruning)한 뒤 필요한 정보만 전달한다.

3.2. 컨텍스트 수집과 분류/RCA 노드

1. Context collector

   1. Context collector는 Healthline, Wisdom, 각종 로그에서 필요한 데이터를 가져오는 결정론적 노드다.
   2. 로그는 메가바이트를 넘어 기가바이트까지 커질 수 있으므로 전처리와 압축 없이 에이전트에 전달할 수 없다.
   3. 이 단계가 입력을 정리해 LLM 호출 수와 컨텍스트 크기를 줄인다.

2. 분류와 RCA

   1. LLM 기반 분류/RCA 노드는 수집된 자료를 보고 문제의 범주를 먼저 판단한다.
   2. Uber 코드 문제인지, 서드파티 라이브러리 문제인지, 인프라 문제인지, 네트워크 문제인지, PR이 필요한 문제인지 분류한다.
   3. 분류 결과와 함께 confidence score를 산출한다.
   4. 자료가 부족하면 Uber 생태계를 추가로 조회한다.
   5. MCP 연결로 Jaeger 분산 트레이싱, 로깅, 진행 중인 인시던트 데이터 등을 확인한다.

3.3. 병렬 RCA 서브에이전트

1. 여러 관점의 분석

   1. 여러 서브에이전트를 병렬로 fan-out해 각각 RCA를 수행하게 한다.
   2. 각 결과를 다시 통합해 하나의 RCA로 정리한다.

2. 대표적인 분석 전략

   1. Breadcrumb analysis 에이전트는 세션 데이터를 받아 사용자의 행동 타임라인을 재구성한다.
   2. 행동 타임라인은 원인 분석뿐 아니라 문제 재현에도 도움을 준다.
   3. Crash correlation 에이전트는 크래시가 특정 버전 릴리스와 연관되는지 확인한다.
   4. 특정 버전에서 크래시가 발생한다고 통계적으로 자신 있게 말할 수 있는지 검증한다.

3. 모델과 턴 수 가드레일

   1. RCA 노드는 주로 데이터를 읽고 정보를 모아 요약하므로 Sonnet과 제한된 최대 턴 수를 사용한다.
   2. 실험 결과 20턴을 넘기면 대체로 잘못된 방향이나 나쁜 토끼굴(rabbit hole)로 빠졌다.
   3. 모델 선택과 최대 턴 수 제한이 에이전트의 탐색 범위를 관리하는 가드레일이 된다.

3.4. 수정과 완화 노드

1. 코드베이스 탐색

   1. 수정 노드는 수십억 줄 규모의 Uber 코드베이스를 살펴본다.
   2. 영향을 받는 모듈과 코드 경로를 찾고, 앞선 노드의 상태를 다음 노드로 전달한다.
   3. 각 노드는 이전 정보를 잊지 않고 누적된 상태를 사용한다.
   4. 이 복잡한 작업은 더 큰 모델과 더 많은 최대 턴 수가 필요한 영역이어서 Opus를 사용한다.

2. 기능 플래그 기반 완화

   1. 실제 수정에 앞서 문제를 완화할 수 있는지 먼저 확인한다.
   2. Uber의 많은 기능은 기능 플래그 뒤에 있으므로 기능 플래그 MCP에 연결한다.
   3. Uber 앱에는 백그라운드에서 작동하는 기능 플래그가 최소 수만 개 이상 존재한다.
   4. 특정 크래시를 그중 하나의 플래그와 연결하는 일 자체가 복잡하지만, 상관관계가 강하면 플래그를 즉시 되돌려 장애를 완화한다.
   5. 장애가 완화되면 담당자는 안정된 상태에서 코드 수정 작업을 이어 갈 수 있다.

3.5. 검증, diff, PR

1. Bazel test라는 이름의 검증 단계

   1. 내부 명칭은 레거시 이유로 Bazel test이지만 실제 역할은 수정안 검증 단계다.
   2. 가장 짧고 단순한 재현 경로를 우선 사용한다.
   3. unit test로 재현할 수 있으면 unit test를 사용하고, 불가능하면 모바일 자동화 엔드투엔드 테스트로 넘어간다.
   4. Uber의 핵심 호출 흐름처럼 시뮬레이터나 에뮬레이터에서 자동화 테스트가 가능한 영역도 있다.

2. 자기 수정 검증

   1. 개발자에게 PR만 건네고 테스트를 떠넘기지 않는다.
   2. 에이전트가 만든 수정안을 스스로 재현·검증해 결과에 대한 신뢰도를 높인다.

3. 결과 전달

   1. 수정안이 충분히 검증되면 diff 또는 PR을 생성한다.
   2. PR은 Jira 이슈와 Healthline·Wisdom 이슈에 연결한다.
   3. Slack으로 개발자에게 보내고 관련 메타데이터를 내부 시스템에 업데이트한다.

3.6. 변하지 않는 골격과 런타임 스킬

1. 하네스와 스킬의 분리
   1. 에이전트의 기본 골격은 고정되며, 바뀌는 부분은 스킬과 플러그인이다.
   2. 각 LLM 노드는 Uber에서 좋은 PR을 만드는 방법, 테스트 계획 관행, Android 이슈 수정법, 지연 로딩 여부, 백그라운드 위임 여부 같은 고유 스킬을 갖는다.
   3. 스킬과 플러그인은 런타임에 가져오는 플러그형 구성 요소다.
   4. 핵심 비즈니스 로직을 고정 골격 밖에 두면 새 에이전트를 추가할 때 파이프라인을 다시 설계하기보다 스킬을 모아 연결하면 된다.

4. Uber 규모로 생산화한 실행 하네스

로컬에서 동작하는 에이전트와 대규모 조직에서 반복 실행되는 에이전트 사이의 차이는 런타임과 책임 경계를 표준화하는 데서 생긴다.

4.1. 공통 기반과 팀별 전문화

1. 하네스가 제공하는 것

   1. 개발자에게 실행 하네스, 따라야 할 단계, 런타임 환경, 의존성을 제공한다.
   2. 각 팀은 이미 제공된 공통 기반 위에 자신의 도메인 전문 스킬만 추가한다.
   3. 공통 플랫폼 팀이 모든 팀의 수많은 스킬과 플러그인을 직접 유지보수하지 않아도 된다.

2. 공유 실행 구조

   1. 현재 5개 모노레포에 걸쳐 거의 8개의 에이전트가 규모 있게 실행되고 있다.
   2. 모든 에이전트는 하나의 Python 모노레포 안에 있는 공통 코드베이스를 공유한다.
   3. 코드는 PEX라는 Python 바이너리로 패키징되어 공통 아티팩트 저장소에 업로드된다.
   4. 에이전트가 실행될 때 자신의 agent type을 기준으로 올바른 바이너리와 Docker 런타임·이미지를 가져온다.
   5. 필요한 의존성과 실행 환경을 Docker 이미지로 확보하고, 여러 모노레포에 흩어진 해당 에이전트의 파이프라인도 런타임에 가져온다.

4.2. 컨텍스트 폭발을 막는 런타임 선택

1. 스킬 마켓플레이스의 선택적 로딩
   1. Uber의 스킬 마켓플레이스에는 현재 거의 3,000개의 플러그인이 있다.
   2. 모든 플러그인의 컨텍스트를 에이전트에 넣으면 에이전트가 혼란스러워지고 정상적으로 작업하기 어렵다.
   3. agent type 파라미터로 필요한 종류의 바이너리, Docker 환경, 파이프라인, 스킬만 선택해 로드한다.
   4. 공통 하네스는 유지하면서도 각 실행에 맞는 전문 지식만 전달하는 방식이다.

4.3. 개발자와의 상호작용

1. Diff fixer

   1. 개발자가 unit test를 더 추가하거나 리팩터링하거나 변수명을 바꾸고 싶을 때 작은 증분 수정이 필요하다.
   2. Diff fixer는 버튼 한 번과 한 줄 프롬프트만으로 이런 수정 작업을 처리한다.

2. Ask AI chat

   1. 개발자는 Debug Assist와 직접 대화하며 RCA와 이슈에 대해 질문할 수 있다.
   2. 에이전트의 결론을 수정하거나 추가 지시를 제공할 수도 있다.
   3. 개발자의 수정 피드백은 에이전트에 대한 피드백 루프가 되어 프롬프트와 스킬을 개선하는 데 활용된다.

3. 개발자 머신에서 재현

   1. 자동 수정 이후에도 직접 디버깅하고 싶은 개발자는 이슈를 자신의 머신에서 열 수 있다.
   2. 원격 머신 풀에서 머신을 선택해 열 수도 있다.
   3. 이슈와 관련된 환경이 미리 설정되므로 설치 과정 없이 한 번의 클릭으로 바로 작업을 시작한다.

5. 검증 인프라와 질의응답

5.1. 환경 의존 이슈의 재현

1. 테스트 경로 선택

   1. 코드로 재현 가능한 문제라면 unit test를 가장 먼저 선택한다.
   2. unit test가 어렵지만 integration test나 component test가 가능하면 그 경로를 사용한다.
   3. 코드만으로 재현할 수 없고 실행 환경이 원인이라면 모바일 자동화 테스트를 사용한다.

2. 저신호 네트워크 사례

   1. 공항 근처에서 네트워크 신호가 약할 때만 발생하는 이슈는 단순한 코드 모킹만으로 재현하기 어렵다.
   2. Uber의 별도 시뮬레이터·에뮬레이터 인프라 팀이 BrowserStack이나 Kobiton과 비슷한 테스트 환경을 제공한다.
   3. 사용자 로그에서 네트워크 세기, 배터리 상태, 적용된 파라미터와 기능 플래그를 이미 확보했으므로 그 조건을 시뮬레이터나 에뮬레이터에 모킹한다.
   4. Android APK 또는 iOS IPA를 빌드해 업로드하고, 테스트 통과까지 반복 피드백 루프를 돌린다.
   5. 무한 재시도를 막기 위해 고정된 재시도 횟수 가드레일을 두며, 한도를 넘기면 최종 결과를 개발자에게 전달한다.

5.2. 서브에이전트 관측과 제어

1. 트레이싱

   1. RCA 서브에이전트와 각 작업을 관측하기 위해 Arize tracing을 사용한다.
   2. LangChain과 통합해 모든 LLM 호출을 추적한다.
   3. 서브에이전트뿐 아니라 모든 MCP 호출, 에이전트가 실행하는 모든 Bash 명령까지 확인할 수 있다.

2. 행동 범위 제한

   1. 각 에이전트가 수행할 수 있는 최대 턴 수를 정해 지나친 탐색을 차단한다.
   2. 문제가 된 커밋을 찾는 에이전트라면 Git 전체 히스토리를 무제한으로 보게 하지 않는다.
   3. 깨끗한 버전과 문제가 생긴 버전을 먼저 제공하고, 두 버전 사이의 변경만 조사하게 한다.
   4. Rider, Driver, Uber Eats처럼 가능성이 있는 모듈을 먼저 좁히고 히스토리를 계속 가지치기한다.

3. 전략의 규모

   1. 현재 고유 서브에이전트는 전체 약 30개로 제한되어 있다.
   2. 도메인 소유자가 자신의 지식 베이스와 도메인을 관리하며 고유 서브에이전트를 연결할 수 있도록 domain extensions를 구축하고 있다.
   3. 플랫폼 팀은 각 도메인의 소유자가 아니라 하네스 제공자이므로, 서브에이전트 수는 다음 반기 말까지 대략 10,000개로 늘어날 것으로 전망한다.

주요 발언 모음

“모든 것이 에이전트를 통해야 하는 것은 아닙니다. 단순히 데이터를 가져오는 일은 결정론적 노드로 처리합니다.”

“에이전트에 좋은 수정 계획을 스스로 만들라고 전적으로 맡기지 않고, 매번 따라야 할 계획을 제공합니다.”

“20턴보다 오래 걸리면 대체로 잘못된 방향의 나쁜 토끼굴로 들어간 것입니다.”

“PR을 개발자에게 던지고 테스트하라고만 하지 않습니다. 수정안 자체를 검증해 자신의 수정에 대한 신뢰도를 높입니다.”

“우리는 도메인의 소유자가 아니라 하네스의 제공자입니다.”

핵심 데이터 & 수치

• 50,000건/년: Wisdom과 Healthline에서 엔지니어에게 배정되는 연간 이슈 규모.
• 90%: 연간 배정 이슈 중 고객에게 영향을 주는 비율.
• 12,000건: 엔지니어링 팀으로 발송되는 연간 페이지 알림 규모.
• 28일: Uber 엔지니어가 이슈 하나를 해결하는 평균 기간.
• 40%: Stripe 공개 보고서가 제시한 개발자 업무 시간 중 디버깅 비율.
• 30% 및 29%: 배터리 신고에서 Uber 앱이 차지한 배터리 사용량의 신고 표현과 스크린샷 수치.
• 17분: 배터리 문제 당시 앱이 백그라운드에 있었던 시간.
• 5% 롤아웃: 푸시 알림 크래시를 조기에 포착한 배포 단계.
• 약 8개 에이전트: 5개 모노레포에서 현재 규모 있게 실행되는 에이전트 수.
• 약 3,000개 플러그인: Uber 스킬 마켓플레이스의 규모.
• 9,000건/월: Debug Assist가 처리하는 월간 이슈와 제공하는 심층 RCA 규모.
• 50%: 개발자의 실제 수정과 정확히 일치하는 현재 RCA 정확도.
• 나머지 50% 중 약 40%: 정확한 파일이나 함수는 아니어도 올바른 모듈·방향으로 가는 RCA의 비율.
• 2배: Jira 해결 시간이 거의 두 배로 개선되어 SLA를 넘긴 백로그를 해소하는 데 기여한 정도.
• 5% → 48%: 약 1년 사이 Debug Assist가 만든 PR의 병합률 변화.
• 약 30개 → 약 10,000개: domain extensions를 통해 확장될 것으로 예상되는 고유 서브에이전트 수.

결론 및 시사점

1. 운영 디버깅 자동화의 첫 단계는 LLM을 붙이는 일이 아니라 Wisdom과 Healthline처럼 풍부하고 구조화된 실행 맥락을 수집하는 일이다.
2. 데이터 수집·전처리·기능 플래그 조회처럼 결정적인 작업은 코드로 고정하고, 분류·원인 추론·수정·검증처럼 판단이 필요한 부분에 LLM을 배치해야 비용과 지연을 통제할 수 있다.
3. 고정된 LangGraph 골격, 제한된 최대 턴 수, 모델별 역할 분리, 증거 타임라인은 에이전트의 환각과 무한 탐색을 줄이는 핵심 하네스 장치다.
4. 단일 거대 에이전트보다 breadcrumb, crash correlation, 커밋 분석처럼 목적이 좁은 서브에이전트를 병렬로 실행하고 결과를 통합하는 편이 RCA의 관점을 넓히기 쉽다.
5. 기능 플래그 롤백을 코드 수정 전에 배치하면 고객 영향을 먼저 줄이고, 개발자가 더 안전한 상태에서 근본 수정에 집중할 수 있다.
6. 에이전트가 만든 PR의 가치는 생성 자체보다 unit·integration·component·모바일 E2E 테스트를 통한 자기 검증에서 커진다.
7. 공통 하네스와 런타임을 플랫폼 팀이 제공하고 도메인별 스킬과 지식 베이스를 각 팀이 소유하면 조직 규모가 커져도 중앙팀의 유지보수 부담을 제한할 수 있다.
8. 개발자에게 diff fixer, Ask AI, 사전 구성된 원격 머신을 제공하면 자동화 결과를 사람이 검토하고 수정하는 피드백 루프가 닫힌다.
9. 9,000건의 월간 처리량과 48%의 PR 병합률은 완전 자율화 이전에도 디버깅 보조가 실질적인 생산성 개선을 낼 수 있음을 보여 준다.
10. 다음 단계는 처리 범위와 RCA 정확도를 높여 이상적으로 100% 정확도에 접근하고 Jira 해결 시간과 평균 해결 시간(MTTR)을 더 줄이는 것이다.

핵심 요약 (20줄)

Uber는 Wisdom과 Healthline으로 운영 장애의 신고·로그·스크린샷·스택 트레이스를 구조화해 수집한다.

Wisdom은 내부 직원과 베타 테스터가 앱 안에서 자연어로 버그를 신고하게 한다.

Healthline은 크래시·멈춤·지터·성능 저하를 백엔드에서 자동 감지한다.

두 시스템은 매년 거의 50,000건의 이슈와 약 12,000건의 페이지 알림을 만든다.

운영 이슈는 모호한 오류와 흩어진 맥락, 거대한 모노레포와 교차 팀 의존성 때문에 해결하기 어렵다.

Uber 엔지니어는 이슈 하나를 해결하는 데 평균 거의 28일을 사용한다.

Debug Assist는 발견·트리아지·RCA·완화·수정·검증·PR 생성을 하나의 여정으로 연결한다.

배터리 사례에서 hot loop가 백그라운드 코드에 높은 CPU 사용량과 배터리 회귀를 일으킨 원인으로 확인됐다.

앱이 17분 동안 백그라운드에 있었다는 사실이 evidence timeline으로 RCA를 뒷받침했다.

푸시 알림 크래시는 5% 롤아웃 단계에서 포착돼 같은 날 수정·병합·배포됐다.

LangGraph 하네스는 미리 정한 계획으로 LLM의 임의적인 계획 수립을 제한한다.

결정론적 컨텍스트 수집기는 거대한 로그를 전처리해 컨텍스트 팽창과 불필요한 비용을 줄인다.

RCA 노드는 분류·신뢰도 산출·MCP 조회·병렬 서브에이전트 분석을 수행한다.

수정 노드는 Opus로 코드베이스를 탐색하고 기능 플래그 롤백을 통해 먼저 장애를 완화한다.

검증 노드는 unit test부터 모바일 자동화 테스트까지 가장 짧은 재현 경로를 선택한다.

공통 하네스는 Python 모노레포·PEX 바이너리·Docker 런타임·런타임 스킬 로딩을 제공한다.

개별 팀은 공통 기반 위에 도메인별 스킬과 플러그인을 추가해 전문성을 확장한다.

Uber 스킬 마켓플레이스의 약 3,000개 플러그인은 agent type에 따라 선택적으로 로드된다.

Debug Assist는 월간 약 9,000건의 이슈를 처리하고 실제 개발자 수정과 50% 일치하는 RCA를 낸다.

PR 병합률은 약 1년 사이 5%에서 48%로 상승했으며 도메인 확장으로 서브에이전트도 늘어날 예정이다.