[한영자막] Uber에서 디버깅 에이전트 하네스를 구축하는 방법 — Kriti Dangi

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Uber의 디버깅 에이전트 하네스는 고정된 분석·수정·검증 절차에 팀별 스킬을 결합해, 장애 보고를 개발자가 검토할 수 있는 수정안으로 연결한다.

📌 핵심 요점

1. 문제 해결의 출발점은 풍부한 장애 맥락이다. Wisdom은 사용자 보고와 메타데이터·로그·스크린샷을, Healthline은 자동 감지한 성능 문제와 스택 트레이스·크래시 덤프를 수집한다.
2. Debug Assist는 발견과 자동 분류 이후 근본 원인 분석, 완화·수정, 검증, PR 전달을 연결한다. 발표자는 30분 이내의 심층 원인 분석을 설명하며, 배터리 문제의 수정안이 약 20분 만에 생성된 사례를 제시했다.
3. LangGraph 기반 파이프라인은 결정론적 노드와 LLM 노드를 섞는다. 실행 계획은 사람이 정하고, 단순 데이터 수집과 대용량 로그 전처리는 결정론적으로 처리해 맥락 과잉·지연·비용을 줄인다.
4. 원인 분석은 병렬 서브에이전트로 분담하며, 분석에는 Sonnet과 제한된 턴 수를, 수정·완화에는 Opus와 더 높은 턴 한도를 사용한다. 테스트 재현, 실행 추적, 입력 범위 제한도 함께 적용한다.
5. 공통 하네스와 실행 환경을 제공하고 팀이 전문 스킬을 추가하는 구조로 확장한다. 발표 시점 월 약 9,000건을 분석하며, 개발자 수정과 비교한 RCA 정확도는 50%, PR 병합률은 초기 5%에서 약 48%로 상승했다고 밝혔다.

🧩 배경과 문제 정의

Uber는 직원·베타 테스터의 수동 버그 보고를 받는 Wisdom과, 크래시·멈춤·성능 저하를 자동 감지하는 Healthline을 운영한다. 두 시스템에서 엔지니어에게 배정되는 이슈는 연간 약 50,000건이며, 발표자는 그중 90%가 고객에게 영향을 주고 약 12,000건의 온콜 호출로 이어진다고 설명한다.

정보가 수집돼 있어도 원인을 찾기는 어렵다. 오류 메시지는 모호하고 코드·로그·설정·데이터는 여러 도구에 흩어져 있으며, 대규모 모노레포와 팀 간 소유권·의존성이 탐색을 복잡하게 만든다. 발표에서는 Uber의 평균 이슈 해결 기간을 약 28일로 제시하고, Stripe의 공개 보고서를 인용해 개발자가 디버깅에 시간의 40%를 쓴다고 설명한다.

Debug Assist는 이 맥락을 모아 원인을 분석하고, 완화 또는 코드 수정을 수행한 뒤 테스트와 PR 전달까지 연결하려는 시스템이다. 발표의 중심은 이러한 절차를 공통 하네스로 제공하고 팀별 전문 지식을 스킬로 결합하는 구현·운영 방식이다.

🕒 시간순 섹션별 상세정리

1. 발표 주제와 Wisdom의 버그 보고

• Uber에서 만든 디버깅 AI 에이전트 Debug Assist를 소개하고, 디버깅의 어려움·데모·내부 구조·성과를 설명할 순서를 제시한다. [00:21]
• 직원과 베타 테스터는 앱에서 빈 화면, 멈춤, 배터리 문제 등을 자연어로 보고할 수 있다. Wisdom은 신고 내용과 함께 앱·OS 버전, 도시 등 메타데이터를 수집한다. [01:20]
• 네트워크·분석·콘솔·GraphQL·UI 상태 로그와 스크린샷도 확보한다. 발표자는 자동 캡처 대상이 Uber 화면이라고 보여준다. [01:42]

2. Healthline의 자동 감지와 장애 규모

• Healthline은 크래시, 멈춤, 화면 끊김, 성능 저하를 자동 감지하는 앱 품질 분석 도구다. [02:09]
• 세션·분석 식별자, 이전 사용자 행동, 여러 로그에 더해 스택 트레이스와 크래시 덤프를 수집해 문제 코드의 단서를 제공한다. [02:33]
• Wisdom과 Healthline에서 연간 약 50,000건이 엔지니어에게 배정되고, 90%는 고객 영향 이슈이며 약 12,000건의 온콜 호출로 이어진다고 보여준다. [02:50]

3. 실제 디버깅이 오래 걸리는 이유

• 심야 호출과 모호한 오류 메시지 때문에 엔지니어는 낯선 코드에서 조사 출발점을 찾아야 한다. [03:35]
• 코드·로그·설정·데이터가 여러 도구에 흩어져 있고, 대규모 모노레포와 팀 간 의존성 때문에 원인과 담당자를 찾기 어렵다. [04:18]
• 평균 이슈 해결에 약 28일이 걸린다고 밝히고, Stripe 보고서의 디버깅 시간 비중 40%를 인용하며 Debug Assist의 개발 목적을 보여준다. [04:48]

4. 발견에서 해결까지 이어지는 파이프라인

• Wisdom·Healthline에서 이슈를 발견한 뒤 자동 분류 단계에서 우선순위, 심각도, 소유 팀과 온콜 담당자를 결정한다. [05:17]
• Debug Assist는 30분 이내 심층 근본 원인 분석을 수행한다고 보여준다. 최종 목표는 개발자가 실행할 수 있는 결과와 이슈 해결로 연결하는 것이다. [05:38]

5. 배터리 소모와 발열 문제의 실제 사례

• 출근 차량을 기다리던 개발자가 Uber 앱의 배터리 사용량이 약 30%이고 휴대전화가 뜨겁다고 신고했다. 약 20분 뒤 수정안이 생성돼 개발자는 검토와 배포를 진행할 수 있었다고 보여준다. [06:29]
• Wisdom에는 신고 내용, 화면과 배터리 사용량 스크린샷, 메타데이터·로그가 모였다. 첨부 화면에서 Uber의 배터리 사용량은 29%로 드러난다. [07:02]
• 분석 결과는 백그라운드에서 실행돼야 할 코드가 포그라운드 반복 경로로 처리돼 CPU와 배터리를 과도하게 사용하는 문제였다. 앱이 17분간 백그라운드에 있었다는 근거와 타임라인을 함께 제시했다. [07:51]

6. 초기 롤아웃에서 발견한 고우선순위 크래시

• 푸시 알림을 매우 빠르게 누르면 앱이 종료되는 잘못된 롤아웃 사례를 소개하며, 해당 문제를 P1으로 분류했다고 보여준다. [08:15]
• Debug Assist가 원인 코드와 수정안을 찾고 Slack으로 전달했다. 5% 롤아웃 단계에서 문제를 포착해 당일 병합·배포했다고 밝혔다. [08:39]

7. LangGraph와 결정론적 맥락 수집

• 에이전트는 결정론적 노드와 LLM 노드를 혼합한 LangGraph 파이프라인으로 구성한다. 사람이 정한 절차를 따라 실행하게 해 계획 생성에 따른 불확실성을 줄인다. [09:28]
• 맥락 수집 노드는 LLM 없이 Wisdom·Healthline과 알려진 API에서 데이터를 가져온다. 불필요한 맥락 증가, 지연, 모델 비용을 줄이려는 선택이다. [10:03]
• 로그가 메가바이트에서 기가바이트 규모이므로 그대로 모델에 넣지 않고 파싱·전처리·가지치기를 수행한다. [10:20]

8. 분류와 병렬 근본 원인 분석

• LLM 노드는 Uber 코드, 외부 라이브러리, 인프라, 네트워크 중 문제 유형을 분류하고 PR 필요 여부와 신뢰도 점수를 판단한다. [10:54]
• 추가 정보가 필요하면 MCP 연결을 통해 Jaeger 분산 추적, 로그, 진행 중인 인시던트 등의 데이터를 조회한다. [11:13]
• 여러 서브에이전트가 병렬로 RCA를 수행하고 결과를 통합한다. 사용자 세션 타임라인을 재구성하는 분석과 크래시를 특정 릴리스에 연결하는 분석을 예로 든다. [11:57]

9. 분석 모델과 턴 수 제한

• RCA 노드는 Sonnet을 사용하며, 데이터 확인·추가 수집·요약이 주요 작업이므로 턴 수를 제한한다고 보여준다. [12:27]
• 시행착오에서 20턴을 넘는 분석은 잘못된 방향으로 빠지는 경우가 많았다고 보고, 이를 에이전트 가드레일의 근거로 삼는다. [12:38]

10. 코드 수정과 피처 플래그 완화

• 수정 노드는 앞선 노드의 상태를 받아 대규모 코드베이스에서 영향받는 모듈과 코드 경로를 찾는다. [13:03]
• 수정에 앞서 피처 플래그 MCP로 문제와 플래그의 상관관계를 조사한다. 강한 연관성이 있으면 플래그를 롤백해 영향을 완화한 뒤 수정할 시간을 확보한다. [13:48]
• 수정·완화 단계는 Opus와 더 높은 최대 턴 수를 사용한다. [13:55]

11. 테스트 검증과 PR 전달

• 검증 단계는 단위 테스트 또는 모바일 자동화 테스트로 문제를 재현하고 수정안을 확인한다. 주요 승차 예약 흐름에는 시뮬레이터·에뮬레이터에서 실행되는 테스트가 있다고 보여준다. [14:23]
• 검증으로 수정안의 신뢰도를 높인 뒤 diff나 PR을 생성해 Jira와 Healthline·Wisdom 이슈에 연결하고, Slack으로 개발자에게 전달하며 메타데이터를 갱신한다. [14:50]

12. 고정된 하네스와 팀별 전문 스킬

• 기본 에이전트 골격은 유지하고, PR 작성·테스트 계획·Android 수정 같은 지식은 각 LLM 노드의 스킬과 플러그인으로 제공한다. [15:16]
• 업무 로직은 골격 밖에 두고 런타임에 가져온다. 새 에이전트를 추가할 때 필요한 전문 스킬을 모으는 방식으로 확장한다. [15:37]
• 플랫폼팀은 실행 단계·환경·의존성을 제공하고 각 팀은 전문 스킬을 가져온다. 이를 통해 중앙팀의 스킬 유지관리 부담을 줄인다고 보여준다. [16:21]

13. 공통 배포 구조와 필요한 플러그인만 로딩

• 약 8개 에이전트가 5개 모노레포에서 운영되며 하나의 코드베이스를 공유한다. Python 코드를 PEX 바이너리로 패키징해 공통 아티팩트 저장소에 올린다. [16:37]
• 에이전트 유형에 따라 필요한 바이너리, Docker 실행 환경·이미지, 여러 모노레포에 있는 파이프라인을 가져온다. [16:55]
• 약 3,000개 플러그인이 있는 스킬 마켓플레이스 전체를 맥락에 넣지 않는다. 에이전트 유형에 맞는 스킬·플러그인을 런타임에 선택해 불러온다. [17:25]

14. 개발자의 수정·대화·직접 디버깅

• PR 생성 후에도 개발자가 결과를 다듬도록 지원한다. diff fixer는 테스트 추가, 리팩터링, 변수명 변경 같은 작은 수정을 버튼과 짧은 프롬프트로 수행한다. [18:05]
• Ask AI에서 RCA와 이슈를 질문하고 분석을 교정할 수 있다. 이 교정은 프롬프트와 스킬을 개선하는 피드백으로 연결된다고 보여준다. [18:27]
• 개발자는 자신의 컴퓨터나 원격 머신에서 직접 디버깅할 수도 있다. 이슈 관련 환경을 미리 구성해 설치 없이 한 번의 클릭으로 열도록 지원한다. [19:01]

15. 운영 성과와 다음 개선 목표

• 월 약 9,000건의 심층 RCA를 제공하며, 개발자 수정과 비교한 정확도는 50%라고 밝혔다. 나머지 50% 가운데 약 40%도 올바른 모듈이나 파일 방향을 제시해 도움을 준다고 보여준다. [19:44]
• Jira 해결 관련 지표를 약 2배 개선으로 소개하지만 원문은 해결 시간이 증가했다고 표현해 지표 해석에 확인이 필요하다. PR 병합률은 약 1년 전 5%에서 약 48%로 상승했다고 밝혔다. [20:16]
• 적용 범위·사용 사례·정확도를 높이고, 정확도는 이상적으로 100%를 목표로 삼아 Jira 해결과 평균 해결 시간을 더 개선하겠다고 말한 뒤 질의응답을 시작한다. [20:47]

16. 질의응답: 가장 간단한 재현 방법부터 검증

• 매번 Android·iOS 앱을 새로 빌드해 테스트하는지 묻자, 단위 테스트로 재현할 수 있으면 먼저 사용하고 통합·컴포넌트 테스트도 활용한다고 답한다. [22:26]
• 코드 수준에서 재현하기 어려운 환경 문제에는 모바일 자동화 테스트를 사용한다. 공항 근처의 약한 네트워크에서만 발생한 문제를 예로 들며 별도의 시뮬레이터·에뮬레이터 인프라를 보여준다. [23:11]
• 사용자 로그의 네트워크 강도·배터리·피처 플래그 조건을 모사하고 APK·IPA를 빌드해 반복 검증한다. 재시도 횟수에는 한도를 두고 이후 수정안을 개발자에게 전달한다. [23:48]

17. 질의응답: 서브에이전트 추적·통제와 도메인 확장

• 내장 추적을 LangChain과 LLM 호출에 연결해 서브에이전트, MCP 호출, bash 명령 등 실행 과정을 관측한다고 보여준다. [25:46]
• 최대 턴 수와 입력 범위로 탐색을 통제한다. 문제 커밋을 찾는 에이전트에는 정상·문제 버전 사이와 관련 모듈의 Git 이력만 보도록 범위를 줄인다. [26:51]
• 현재 고유 서브에이전트는 약 30개이며, 도메인 소유자가 자신의 에이전트와 지식 기반을 관리하는 도메인 확장을 개발 중이라고 밝혔다. 다음 반기 말까지 약 10,000개로 늘어날 수 있다는 전망으로 답변을 마친다. [27:55]

🧾 결론

• 하네스의 핵심은 분석 순서, 상태 전달, 도구 연결, 검증, 결과 전달을 공통 구조로 묶는 데 있다. 팀별 업무 지식은 런타임에 불러오는 스킬과 플러그인으로 보완한다.
• 원인 분석과 수정안에 근거 타임라인을 붙이고 테스트로 확인하면 개발자가 결과를 판단하기 쉬워진다. 발표 사례의 최종 검토와 배포에는 개발자가 참여했다.
• 모델 성능과 함께 로그 전처리, 제한된 탐색 범위, 턴·재시도 한도, 피드백 통로가 운영 품질을 좌우한다.
• 공개된 정확도와 병합률은 유용성과 한계를 함께 보여준다. 발표자는 적용 범위와 정확도를 더 높이겠다는 목표를 제시했다.

📈 투자·시사 포인트

• 기업용 디버깅 에이전트의 가치를 평가할 때는 모델 응답 품질과 함께 기존 관측 데이터, 코드 저장소, 테스트 환경, 이슈 관리 시스템을 얼마나 연결하는지 살펴볼 필요가 있다.
• 공통 하네스와 팀별 스킬을 분리하는 방식은 중앙 플랫폼팀이 모든 도메인 지식을 관리해야 하는 부담을 줄이는 설계 사례다. 각 도메인 소유자의 지식 관리 책임이 함께 필요하다.
• 비용과 생산성을 판단하려면 RCA 정확도, PR 병합률, 해결 시간, 모델·실행 비용을 함께 봐야 한다. 이 발표에는 비용 대비 효과를 계산할 수 있는 구체적인 비용 자료가 없다.
• 관측·테스트 인프라는 에이전트의 입력과 검증 기반으로 작동한다. 기술 도입을 검토하는 조직에는 이러한 기반의 준비 상태가 중요한 점검 항목이다.

⚠️ 불확실하거나 확인이 필요한 부분

• RCA 정확도 50%는 개발자의 실제 수정과 비교한 수치로 소개됐지만, 평가 표본·기간·일치 판정 기준은 공개되지 않았다. 나머지 50% 가운데 약 40%가 올바른 방향이었다는 설명을 전체 정확도 90%로 해석하면 안 된다.
• Jira 성과는 약 2배의 개선으로 소개되지만, 원문은 해결 시간이 증가했다고 표현한다. 해결 속도·처리량·소요 시간 중 어떤 지표를 뜻하는지 확인하기 전에는 해결 시간이 절반으로 줄었다고 단정할 수 없다.
• 연간 약 50,000건의 엔지니어 배정 이슈와 월 약 9,000건의 에이전트 분석 이슈는 집계 범위와 중복 여부가 설명되지 않았다. 두 수치로 자동화 적용률을 계산하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 장애 보고에 앱·OS 버전, 세션 정보, 로그, 스크린샷, 스택 트레이스를 연결하고, LLM에 전달하기 전 전처리·축약할 범위를 정한다.
• 수집 → 분류·원인 분석 → 완화·수정 → 검증 → PR 전달의 고정 절차를 설계하고, 결정론적으로 처리할 단계와 LLM이 필요한 단계를 구분한다.
• 서브에이전트에 정상·문제 버전 사이의 커밋 범위와 관련 모듈을 제공하고, 최대 턴 수·재시도 횟수·도구 호출 추적을 설정한다.
• 단위 테스트로 재현 가능한지 먼저 확인하고, 필요에 따라 통합·컴포넌트 테스트와 사용자 환경을 모사한 모바일 자동화 테스트로 확장한다.

❓ 열린 질문

• 개발자 수정과 일치하지 않은 RCA가 실제로 얼마나 시간을 절약하며, 잘못된 방향으로 안내한 경우의 비용은 어느 정도인가?
• Jira의 약 2배 개선은 정확히 어떤 지표이며, 이슈 난이도나 팀별 차이를 어떻게 반영했는가?
• 피처 플래그 자동 롤백은 어떤 근거와 권한 조건에서 실행되며, 잘못된 완화 조치는 어떻게 감지하고 복구하는가?