자율주행 프로덕션의 5단계 — Eric Schwartz, Traversal

URL: https://www.youtube.com/watch?v=y-OVWZD4j6U
날짜: 2026-10-03
채널: aiDotEngineer
발표자: Eric Schwartz, Traversal Product Manager

---

📌 핵심 질문 / 이 발표가 다루는 핵심 논점

==코딩 에이전트가 개발 속도를 폭발적으로 높일수록 운영 복잡성과 장애 대응 부담이 커지므로, 프로덕션을 관찰하는 수준을 넘어 원인을 찾고 수정하고 검증하는 폐쇄 루프를 만들어야 한다.==

• 소프트웨어 엔지니어링의 세 축은 시스템 설계, 개발, 트러블슈팅이며 코딩 에이전트는 개발 축을 크게 단축한다.
• 더 많은 코드와 복잡한 환경은 관측 도구가 알려 주는 ‘무엇이 깨졌는가’와 엔지니어가 알아야 하는 ‘왜 깨졌는가’ 사이의 간극을 키운다.
• 근본 원인 분석은 단순한 관측(observability) 문제가 아니라 원인과 결과를 연결하는 인과(causal) 문제다.
• 자율주행 프로덕션의 최종 형태는 장애를 감지하고 근본 원인을 찾고 수정 사항을 배포한 뒤 수정 결과까지 검증하는 폐쇄 루프다.

개발자의 생산성이 높아진다는 사실만으로 개발 조직 전체가 더 창의적인 설계에 집중할 수 있는 것은 아니다. 코드 생성 속도가 빨라지면 장애를 일으킬 수 있는 코드와 운영 대상도 함께 늘어난다. 따라서 AI 운영 시스템은 모든 프로덕션 데이터를 읽고, 데이터 사이의 관계를 모델링하고, 증상에서 멀리 떨어진 원인까지 몇 분 안에 추적하며, 가능하다면 수정과 검증까지 수행해야 한다.

1. 코딩 에이전트가 소프트웨어 생명주기의 균형을 바꾸다

소프트웨어 엔지니어링은 설계·구현·운영 장애 대응이라는 세 영역으로 나뉘며, AI 코딩 에이전트는 그중 구현만 빠르게 만들고 나머지 병목을 자동으로 해결하지는 않는다.

1.1. 세 가지 기본 작업

1. 시스템 설계(System Design)

   1. 무엇을 만들지 결정하기: 제품이 해결할 문제와 기능 범위를 정한다.
   2. 아키텍처 선택하기: 어떤 컴포넌트와 데이터 흐름으로 시스템을 구성할지 결정한다.

2. 개발(Development)

   1. 설계를 코드로 옮기기: 실제 코드를 작성하고 시스템을 구축한다.
   2. 진입 장벽 낮아지기: 코딩 에이전트 덕분에 정식 컴퓨터과학 교육을 받지 않은 사람도 프로덕션 코드를 만드는 데 기여할 수 있다.

3. 트러블슈팅(Troubleshooting)

   1. 현실 세계와 상호작용한 뒤 고치기: 배포된 시스템은 실제 트래픽·의존성·데이터와 만나면서 고장 나므로 원인을 찾아 수정해야 한다.
   2. 운영 맥락 복원하기: 어떤 코드가 어떤 서비스·로그·메트릭·외부 조건과 연결됐는지 파악해야 한다.

1.2. 구현 속도 향상과 운영 부담의 역전

1. 개발 축의 축소

   1. 작성 시간 단축: 코딩 에이전트가 구현 속도를 높여 팀이 같은 시간에 훨씬 많은 기능을 만들게 한다.
   2. 10배 생산성의 양면성: 팀이 10배 더 많은 일을 할 수 있지만, 그 결과 프로덕션에 들어가는 코드의 양도 증가한다.

2. 설계와 트러블슈팅의 비대칭

   1. 기대했던 방향: 구현이 빨라진 만큼 창의적인 아키텍처와 제품 설계에 더 많은 시간을 쓸 수 있어야 한다.
   2. 기업 현장에서 관찰되는 방향: 실제로는 코드에 대한 이해가 낮아진 상태로 더 많은 코드가 배포되고, 팀은 설계보다 트러블슈팅에 더 많은 시간을 쓴다.

3. 복잡성의 누적

   1. 문제 수 증가: 코드가 많아질수록 장애 가능성과 서로 얽힌 실패 경로가 함께 증가한다.
   2. 지식의 분산: 어느 한 엔지니어도 전체 시스템을 이해하지 못하는 상황이 되면 장애 대응이 여러 사람의 부분적인 지식을 모으는 작업으로 변한다.

1.3. 비용으로 드러난 운영 병목

1. 기업 규모의 손실

   1. 연간 비용: 일부 추산에 따르면 기업은 프로덕션 문제와 트러블슈팅에 연간 4,000억 달러 이상을 지출한다.
   2. 경영진의 인식: 경영진의 40%가 이 문제를 팀이 실제로 겪는 문제라고 답한다.

2. 개인 엔지니어의 손실

   1. 온콜 시간: 엔지니어는 온콜 상태에서 트러블슈팅만으로 매주 7시간 이상을 잃는다.
   2. 앞으로의 악화: Cloud Code, Codex, Cursor처럼 훌륭한 도구가 널리 쓰일수록 코드와 시스템 복잡성이 계속 증가한다.

2. 관측 도구가 설명하지 못하는 인과 관계

대시보드와 로그 검색은 장애의 표면을 보여 주지만, 복잡한 분산 시스템에서 근본 원인을 증명하고 다음 조치를 제시하는 일은 별도의 인과 추론 문제다.

2.1. “무엇이 깨졌는가”와 “왜 깨졌는가”의 차이

1. 기존 관측성 도구의 강점

   1. 장애 감지: Datadog, Elastic, Splunk, ServiceNow 같은 도구는 무언가 고장 났다는 사실을 빠르게 알려 준다.
   2. 상관 신호 제시: 동시에 변한 메트릭과 로그를 묶거나, 장애와 상관된 현상을 보여 줄 수 있다.

2. 기존 관측성 도구의 한계

   1. 근본 원인 부재: 상관된 현상을 나열해도 실제로 무엇이 최초 원인이었는지는 알려 주지 않는다.
   2. 조치 부재: “무엇이 깨졌는지”를 보여 주는 것만으로는 “왜 깨졌고 무엇을 해야 하는지”에 답하지 못한다.

3. 현장 고객의 반복되는 질문

   1. ServiceNow 경험에서 나온 문제: Eric Schwartz가 ServiceNow에서 관측성 제품을 담당할 때 고객들은 같은 불만을 반복했다.
   2. 핵심 불만: “무엇이 깨졌는지는 알려 주지만, 왜 깨졌는지와 무엇을 해야 하는지는 알려 주지 않는다”는 문제다.

2.2. 다중 홉과 분산된 맥락

1. 체크아웃 API 사례

   1. 증상: 체크아웃 API가 실패한다는 경고가 발생한다.
   2. 추적 경로: 근본 원인에 도달하려면 수십 개 서비스와 페타바이트 규모의 데이터를 가로질러 다섯 번에서 열 번의 추적 홉을 거쳐야 할 수 있다.

2. 작은 조직과 대기업의 차이

   1. 작은 환경: 숙련된 SRE 한 명이 전체 스택과 조직의 트라이벌 지식을 알고 있다면 혼자 문제를 풀 가능성이 있다.
   2. 대기업 환경: Fortune 50 또는 Fortune 100 기업에는 전체 맥락을 가진 단일 엔지니어가 없기 때문에 한 장애에 50명이 모인 워룸이 만들어진다.

3. 부분 지식의 조합 비용

   1. 각자의 조각: 엔지니어마다 특정 서비스, 저장소, 로그 인덱스에 대한 지식만 갖고 있다.
   2. 전체 경로의 부재: 체크아웃 API 실패에서 멀리 떨어진 만료된 TLS 인증서까지 이어지는 경로를 한 사람이 한 번에 보지 못한다.

2.3. 근본 원인은 인과 문제다

1. Traversal의 출발점

   1. 핵심 명제: 근본 원인 분석은 관측성 문제가 아니라 인과 문제다.
   2. 인과 머신러닝: Traversal의 창업자 네 명 가운데 세 명은 학계 출신이고 한 명은 퀀트 금융 출신이며, 모두 수십 년 동안 원인과 결과를 찾는 인과 머신러닝을 다뤄 왔다.

2. 제품화된 목표

   1. 인과 관계 연결: 단순히 오류가 동시에 발생했다는 사실이 아니라 어느 사건이 다른 사건을 일으켰는지 연결한다.
   2. 운영 가능한 답변: 원인 탐색 결과가 사람의 추가 검색으로 끝나지 않고 실제 수정과 검증으로 이어져야 한다.

3. 자율주행 프로덕션의 0단계부터 5단계까지

자율주행 프로덕션은 한 번에 완성되는 기능이 아니라 수동 대응에서 전체 환경의 진단·수정·검증까지 점진적으로 올라가는 성숙도 스펙트럼이다.

3.1. 레벨 0과 레벨 1: 수동 대응에서 규칙 자동화로

1. 레벨 0 — 완전 수동 운영

   1. 대응 방식: Slack 워룸이나 Zoom 회의에 여러 사람을 소집해 몇 시간 동안 디버깅한다.
   2. 병목: 온콜 팀이 문제를 발견하고, 관련자를 찾고, 데이터를 모으고, 원인을 추론하고, 수정 여부를 확인하는 모든 단계를 직접 수행한다.

2. 레벨 1 — 규칙과 자동화

   1. 구조화된 워크플로: 특정 알림이 발생하면 정해진 명령이나 런북을 실행하는 규칙 기반 자동화를 만든다.
   2. 코딩 도구와의 결합: Cloud Code, Cursor, Codex 같은 도구로 팀이 알림 반응 루프를 직접 구성할 수 있다.

3. 규칙의 경계

   1. 반복 가능한 상황에 강함: 이미 알고 있고 절차가 정해진 사건에는 규칙 자동화가 효율적이다.
   2. 새로운 상황에 약함: 처음 보는 장애에는 기존 런북이 없으므로 규칙이 작동하지 않고 사람이 다시 추론해야 한다.

3.2. 레벨 2와 레벨 3: 제한된 범위의 에이전트

1. 레벨 2 — 더 많은 자동화

   1. 분석 단계 확장: 단순한 트리거-명령 실행을 넘어 데이터 조회와 일부 판단을 자동화한다.
   2. 여전히 제한된 맥락: 자동화가 다루는 서비스나 알림의 범위가 좁으면 전체 장애의 원인을 놓칠 수 있다.

2. 레벨 3 — 홈그로운 에이전트

   1. 전문화된 디버거: 특정 서비스 또는 특정 알림 집합의 장애를 잘 디버깅하는 사내 에이전트를 만든다.
   2. 도메인 편중: 한 서비스에 깊이 최적화된 에이전트는 다른 서비스와의 연쇄 장애나 전사 환경의 관계까지 이해하기 어렵다.

3. 레벨 3까지의 공통 한계

   1. 국소 최적화: 자동화가 특정 지점에서는 뛰어나도 조직 전체의 수백 개 서비스와 저장소를 가로지르는 분석은 제공하지 못한다.
   2. 유지보수 부담: 시스템이 바뀔 때마다 규칙, 런북, 에이전트 지식을 사람이 갱신해야 한다.

3.3. 레벨 4와 레벨 5: 환경 전체와 폐쇄 루프

1. 레벨 4 — 전체 프로덕션 환경의 진단

   1. 범위 확장: 수백 개 서비스, 수백 개 저장소, 수천 개 로그 인덱스를 하나의 분석 맥락으로 다룬다.
   2. 홈그로운 구현의 난점: 이렇게 넓은 범위와 데이터 양을 사내에서 처음부터 구축하기는 매우 어렵다.

2. 레벨 5 — 진단·수정·검증의 완전 자동화

   1. 근본 원인 진단: 대기업 전체 프로덕션 환경에서 증상과 원인을 연결한다.
   2. 수정 배포: 진단 결과를 바탕으로 문제를 완화하거나 해결하는 수정 사항을 올린다.
   3. 수정 검증: 수정이 실제로 장애를 해결했는지 확인한다.

3. 폐쇄 루프의 운영 목표

   1. 순환 구조: 장애 발생 → 문제·인시던트·알림 탐지 → 근본 원인 분석 → 수정 → 수정 결과 검증의 루프를 닫는다.
   2. 사람의 집중력 보호: 가능하면 팀원을 호출하거나 업무를 방해하지 않고, 엔지니어가 새로운 것을 만드는 데 집중하게 한다.

4. Traversal이 다루는 규모와 사용 사례

Traversal은 대규모 데이터 통합과 인과 검색을 기반으로 알림 지능화, 인시던트 근본 원인 분석, 셀프 힐링, 프로덕션 지원, 코드 회복탄력성까지 운영 생명주기 전반을 겨냥한다.

4.1. 대기업 규모의 처리 능력

1. 고객 환경

   1. 대표 고객: American Express, Pepsi, DigitalOcean, Capital One 같은 대기업이 포함된다.
   2. 운영 조건: 각 고객은 서비스·로그·메트릭·이벤트가 매우 큰 규모로 생성되는 복잡한 프로덕션 환경을 가진다.

2. 데이터 규모

   1. 로그와 트레이스: 수조 개의 로그와 수조 개의 스팬(spans)을 처리한다.
   2. 메트릭과 이벤트: 수백억 개 규모의 메트릭과 이벤트도 분석 대상에 포함된다.

3. 성과 지표

   1. 고심각도 장애: 이 규모에서 고심각도 인시던트의 80% 이상에 대해 근본 원인을 찾아내는 성과를 제시한다.
   2. 기술적 의미: 데이터 양과 서비스 수를 감안하면 단순 대시보드 집계보다 데이터 연결과 검색 구조 자체가 핵심 기술 과제다.

4.2. 다섯 가지 운영 사용 사례

1. 알림 지능화(Alert Intelligence)

   1. 우선순위화: 하루 수백~수천 개의 알림을 받는 온콜 팀이 실제로 조사해야 할 신호를 먼저 보게 한다.
   2. 알림 피로 완화: 알림 규칙 수정, 즉시 처리하지 않아도 되는 알림의 보류, 나중에 처리할 기술 부채의 티켓 생성으로 소음을 줄인다.

2. 인시던트 근본 원인 분석

   1. 시간 단축: 수십 명의 엔지니어가 몇 시간 동안 하던 원인 분석을 몇 분 안에 수행하는 것이 출발점이다.
   2. 초기 응답 강화: 장애 대응 채널에 원인과 관련 근거를 제공해 무작정 여러 팀을 호출하는 상황을 줄인다.

3. 셀프 힐링(Self-Healing)

   1. 진단을 넘어 수정: 무엇이 원인이었는지 설명하는 데서 끝나지 않고 수정 사항을 올린다.
   2. 완화와 검증: 장애를 완화한 뒤 시스템이 회복됐는지 검증한다.

4. 프로덕션 지원(Production Support)

   1. 대화형 질의: 대규모 인시던트가 아니더라도 팀이 프로덕션 환경에 질문해 특정 데이터 포인트를 얻는다.
   2. 반복 업무 감소: 사소해 보이지만 매일 누적되는 운영 질문과 수작업을 줄인다.

5. 코드 회복탄력성(Code Resilience)

   1. 배포 전 관점: 변경 사항을 올리기 전에 코드가 시스템의 회복탄력성과 신뢰성을 높이는지 확인한다.
   2. 운영과 개발의 연결: 장애가 난 뒤 고치는 것뿐 아니라 사전 단계에서 더 견고한 코드를 만드는 데 운영 지식을 활용한다.

4.3. Pepsi 공급망의 알림 지능화

1. 문제의 규모

   1. 핵심 업무: 원재료와 완제품이 공급망을 통과하고, 창고의 완제품이 트럭을 거쳐 소매점으로 이동하도록 내부 도구와 소프트웨어가 지원한다.
   2. 알림 폭증: Traversal 도입 전에는 매주 수천~수만 개의 알림이 발생했다.

2. 엔지니어의 업무 상태

   1. 700개 backlog: 한 엔지니어가 동시에 700개 알림을 쌓아 두는 경우가 있었다.
   2. 두 가지 실패: 소음 속에서 중요한 장애를 놓치거나, 모든 것을 따라잡으려다 번아웃에 빠졌다.

3. Traversal의 개입

   1. 사전 조사된 목록: 알림을 먼저 파싱하고 조사해 실제로 파고들 가치가 있는 항목을 우선순위가 매겨진 목록으로 제공한다.
   2. 소음 처리 제안: 코드의 알림 규칙을 수정할 기회, 당장 대응할 필요가 없는 알림의 해제, 나중에 처리할 기술 부채 티켓을 구분한다.

4.4. American Express 인시던트의 첫 번째 대응자

1. 도입 전 장애 대응

   1. 호출 규모: 하나의 장애에 5~10개 팀과 20~50명의 엔지니어가 호출됐다.
   2. 해결 시간: 사례에 따라 60분이 걸렸고, 어떤 장애는 해결까지 몇 시간 또는 며칠이 걸렸다.
   3. 고객 영향: 카드 대금을 결제하지 못하거나 모바일 앱에 로그인하지 못하는 장애는 고객에게 직접적인 피해를 준다.

2. Traversal의 첫 응답

   1. 브리지 선언 직후 실행: American Express가 내부적으로 브리지(bridge)를 선언하는 순간 Traversal이 모든 인시던트의 첫 번째 대응자가 된다.
   2. 3분 내 분석: 3분 안에 인시던트가 관리되는 Slack 채널에 상세한 근본 원인 분석을 게시한다.
   3. 업무 시스템 연동: 필요하면 ServiceNow 티켓에도 상태와 분석 결과를 업데이트한다.

3. 호출 감소 효과

   1. 필요한 팀만 호출: 초기 분석이 있으면 5개 팀과 58명을 무작정 부르는 대신 아무도 부르지 않거나 결과를 확인할 1~2개 팀만 호출할 수 있다.
   2. 50명 이상의 시간 절감: 사례에서 50명 이상의 엔지니어가 호출에 따른 시간과 부담을 피했고, 한밤중 장애라면 53명이 잠을 잘 수 있는 효과가 생긴다.

5. AI SRE 시스템을 평가하는 다섯 가지 질문

AI SRE가 실제 대기업 운영을 맡으려면 모델의 언어 능력보다 데이터 범위, 검색 비용, 관계 이해, 자율적 학습, 다중 홉 속도를 먼저 검증해야 한다.

5.1. 모든 프로덕션 데이터를 볼 수 있는가

1. 전체 맥락의 필요성

   1. 데이터 조각의 한계: 시스템의 일부 데이터만 제공하거나 연결에 빈틈이 있으면 상세한 근본 원인에 도달하기 어렵다.
   2. 숨은 원인의 가능성: 최초 증상이 한 서비스에서 보여도 원인이 다른 서비스·인증서·배포에 있을 수 있다.

2. 접근 범위의 검증

   1. 연결된 데이터 확인: 어떤 로그, 트레이스, 메트릭, 이벤트, 서비스 관계를 실제로 읽는지 확인해야 한다.
   2. 공백의 위험: 관측 대상에서 빠진 시스템은 원인 그래프의 끊어진 링크가 되어 오진을 만든다.

5.2. 대규모 데이터를 비용 폭발 없이 검색할 수 있는가

1. 검색의 현실적 조건

   1. 데이터 양: 페타바이트 규모 데이터와 수천억 개의 로그를 조사해야 하는 경우가 있다.
   2. 운영 안전성: 검색 때문에 비용이 폭증하거나 기존 관측성 인프라가 다운되면 자동화의 가치가 사라진다.

2. Fortune 100의 난이도

   1. 단순한 데모와 다른 문제: 소량의 샘플 데이터에서 답하는 것과 기업 전체의 실제 데이터를 안전하게 탐색하는 것은 전혀 다르다.
   2. 검색 엔진의 중요성: 에이전트가 무엇을 볼지와 어떤 순서로 좁힐지를 통제할 수 있는 고성능 검색 계층이 필요하다.

5.3. 데이터 속의 관계를 매핑할 수 있는가

1. 관계 지식의 필요성

   1. 읽기만으로 부족함: 모든 데이터를 수집하고 읽을 수 있어도 서비스, 배포, 의존성, 오류 사이의 관계를 모르면 분석 결과를 만들 수 없다.
   2. 엔터티 연결: 개별 로그를 서비스·호출 경로·인프라·변경 사항과 연결해야 한다.

2. 관계가 만드는 추론

   1. 증상에서 원인으로 이동: 체크아웃 API의 실패를 TLS 인증서 만료 같은 먼 원인과 연결한다.
   2. 전체 환경의 지도: 관계 지도는 에이전트가 어느 방향으로 다음 검색을 진행할지 알려 준다.

5.4. 엔지니어가 지식을 관리하지 않아도 스스로 좋아지는가

1. 유지보수 비용의 문제

   1. 문서 갱신 부담: 수많은 Markdown 파일과 런북을 엔지니어가 계속 수정해야 한다면 자동화가 새로운 운영 업무가 된다.
   2. 전담 인력 의존: 포워드 디플로이된 엔지니어가 팀마다 붙어 지식을 유지해야 한다면 확장성이 제한된다.

2. 자율적 개선의 기준

   1. 환경 변화 반영: 서비스와 배포가 바뀔 때 시스템이 새 관계와 패턴을 스스로 반영해야 한다.
   2. 운영팀의 시간 보호: 팀의 엔지니어링 리소스를 지식 베이스 유지보수에 계속 할당하지 않아야 한다.

5.5. 5분 안에 멀리 떨어진 원인을 찾을 수 있는가

1. 다중 홉 능력

   1. 비자명한 원인: 처음 나타난 증상에서 다섯 번 이상의 의존성 홉을 건너뛰어야 하는 원인을 찾아야 한다.
   2. 빠른 탐색: 눈에 보이는 오류와 실제 원인이 멀리 떨어져 있어도 몇 분 안에 검색 경로를 완성해야 한다.

2. 시간과 신뢰의 관계

   1. 5분의 기준: 분석이 5분을 넘기면 온콜 팀의 인내심을 잃고 사람들은 익숙한 수동 대응 습관으로 돌아간다.
   2. 속도와 정확도의 동시 요구: 빠르기만 한 추측이 아니라 빠르고 근거 있는 원인 분석이어야 한다.

6. Traversal의 기술 구조와 레벨 5로 가는 경로

Traversal은 데이터 수집 계층, 프로덕션 월드 모델, 인과 검색 엔진, 사용 사례별 경험을 결합해 대규모 환경에서 에이전트가 탐색하고 조치하도록 설계한다.

6.1. 세 층으로 나눈 제품 구조

1. 하단 — 데이터 통합과 비용 효율적 분석

   1. 수집: 연결된 시스템에서 모든 프로덕션 데이터를 수집한다.
   2. 비용 통제: 관측성 비용을 늘리지 않으면서 대규모 데이터를 분석할 수 있도록 한다.

2. 중간 — 프로덕션 월드 모델(Production World Model)

   1. 관계 지도: 수집된 데이터에 등장하는 엔터티와 그 사이의 관계를 매핑한다.
   2. 운영 맥락: 로그 한 줄을 고립된 텍스트로 보지 않고 서비스, 의존성, 호출, 변경의 세계 안에 배치한다.

3. 상단 — 사용 사례와 사용자 경험

   1. 결과 표면화: 모델이 이해한 관계를 알림 지능화, 근본 원인 분석, 셀프 힐링 같은 기능으로 패키징한다.
   2. 팀에 전달: Slack과 ServiceNow 같은 운영 흐름에 결과를 제공해 대응팀이 바로 확인하고 행동하게 한다.

6.2. 프로덕션 월드 모델과 인과 검색 엔진

1. 프로덕션 월드 모델의 역할

   1. 전체 환경의 이해: 통합된 데이터와 그 관계를 바탕으로 어떤 서비스와 사건이 서로 연결되는지 파악한다.
   2. 다중 홉의 기반: 증상에서 출발해 의존성을 따라 먼 원인까지 이동할 수 있는 공통 맥락을 제공한다.

2. 인과 검색 엔진(Causal Search Engine)의 역할

   1. 에이전트의 하네스: 에이전트가 매핑된 데이터를 어떤 방식으로 탐색할지 안내하는 메커니즘이다.
   2. 근거 있는 축소: 수조 개의 이벤트를 무작정 읽는 대신 가능한 원인을 좁혀 가며 인과 경로를 검색한다.

3. 레벨 5와의 연결

   1. 진단 능력: 월드 모델이 범위를 제공하고 인과 검색 엔진이 원인 경로를 찾는다.
   2. 행동 능력: 진단 결과가 수정 배포와 검증 단계로 이어질 때 프로덕션이 완전한 자율주행에 가까워진다.

주요 발언 모음

“Development is a lot faster. Teams can do 10x more. But then what happens to either end of the spectrum?”

개발은 훨씬 빨라지고 팀은 10배 더 많은 일을 할 수 있다. 그렇다면 양 끝단, 즉 시스템 설계와 트러블슈팅에는 무슨 일이 생기는가?

“You’re telling me what’s broken, you’re not telling me why, and you’re not telling me what to do about it.”

무엇이 깨졌는지는 알려 주지만 왜 깨졌는지와 무엇을 해야 하는지는 알려 주지 않는다는 것이 기존 관측성 도구에 대한 고객의 불만이다.

“Root cause analysis is not an observability problem. It’s a causal problem.”

근본 원인 분석은 관측성 문제가 아니라 인과 문제라는 것이 Traversal의 출발점이다.

“Anything more than 5 minutes and you’ve kind of lost the plot.”

분석에 5분 이상 걸리면 온콜 팀의 인내심을 잃고 사람들이 다시 자신의 익숙한 습관으로 돌아간다.

핵심 데이터 & 수치

• 연간 4,000억 달러 이상: 일부 추산에서 기업이 프로덕션 문제와 트러블슈팅에 지출하는 규모다.
• 경영진 40%: 팀이 이 문제를 겪고 있다고 답한 경영진의 비율이다.
• 주당 7시간 이상: 엔지니어가 온콜 트러블슈팅으로 잃는 평균 시간이다.
• 다섯~열 번의 홉: 체크아웃 API 실패에서 근본 원인까지 이동할 수 있는 서비스·데이터 추적 단계다.
• 수조 개의 로그와 스팬: Traversal이 대기업 환경에서 처리하는 데이터 규모다.
• 수백억 개의 메트릭과 이벤트: 추가로 처리하는 대규모 운영 신호다.
• 80% 이상: 이 규모의 고심각도 인시던트에 대해 제시된 근본 원인 분석 비율이다.
• 주당 수천~수만 개 알림: Pepsi 도입 전 공급망 시스템에서 발생한 알림량이다.
• 700개 알림 backlog: 도입 전 Pepsi의 한 엔지니어가 떠안던 예시 backlog다.
• 5~10개 팀, 20~50명: American Express 도입 전 하나의 인시던트에 호출되던 범위다.
• 3분: 브리지 선언 뒤 Traversal이 상세 근본 원인 분석을 게시하는 목표 시간이다.
• 50명 이상, 53명: 사례에서 호출을 피한 엔지니어 규모와 한밤중 수면을 지킬 수 있는 예시 인원이다.

결론 및 시사점

1. 코드 생성 속도와 운영 능력을 함께 확장해야 한다: AI 코딩 도구 도입을 개발자 생산성 지표만으로 평가하지 말고, 새 코드가 만드는 장애 대응 비용까지 함께 측정해야 한다.
2. 관측성과 근본 원인 분석을 분리해서 설계해야 한다: 로그·메트릭·트레이스를 수집하는 것과 인과 경로를 찾아 조치하는 것은 서로 다른 문제다.
3. 자동화의 성숙도는 범위로 평가해야 한다: 특정 알림에 반응하는 레벨 1 자동화나 특정 서비스용 레벨 3 에이전트만으로는 전체 프로덕션을 자율화할 수 없다.
4. 레벨 3에서 레벨 4로 넘어갈 때 전체 관계 지도가 필요하다: 수백 개 서비스와 저장소, 수천 개 로그 인덱스를 연결하는 공통 모델이 확장성의 핵심이다.
5. 5분 안에 유용한 결과를 내야 한다: 정확성만큼 응답 속도가 중요하며, 느린 분석은 온콜 팀이 자동화를 신뢰하지 않게 만든다.
6. AI SRE 구매·구축 시 다섯 가지를 검증해야 한다: 전체 데이터 접근, 비용 효율적 검색, 엔터티 관계 매핑, 자율적 지식 개선, 다중 홉 근본 원인 분석을 확인해야 한다.
7. 진짜 레벨 5는 설명이 아니라 행동까지 포함한다: 원인을 찾는 데서 멈추지 않고 수정 사항을 배포하고 회복을 검증해야 폐쇄 루프가 완성된다.
8. 운영 데이터를 사전 예방적 개발에 되돌려야 한다: 코드 회복탄력성 사용 사례처럼 장애 대응에서 얻은 지식을 다음 변경의 안전성 검증에 활용해야 한다.

핵심 요약 (20줄)

1. AI 코딩 에이전트는 개발 속도를 높이지만 시스템 설계와 트러블슈팅을 자동으로 해결하지는 않는다.
2. 더 많은 코드가 더 복잡한 프로덕션 환경과 더 많은 장애 가능성을 만든다.
3. 기업 팀은 설계보다 트러블슈팅에 더 많은 시간을 쓰는 방향으로 이동하고 있다.
4. 일부 추산은 기업의 프로덕션 문제 대응 비용을 연간 4,000억 달러 이상으로 본다.
5. 엔지니어는 온콜 트러블슈팅으로 매주 7시간 이상을 잃는다.
6. Datadog과 Splunk 같은 관측성 도구는 고장 난 대상을 보여 주지만 근본 원인을 보장하지 않는다.
7. 체크아웃 API 장애의 원인은 다섯~열 번의 홉과 수십 개 서비스 너머에 있을 수 있다.
8. 대기업에서는 전체 맥락을 아는 사람이 없어 수십 명이 워룸에 모인다.
9. Traversal은 근본 원인 분석을 관측성 문제가 아닌 인과 문제로 정의한다.
10. 레벨 0은 Slack이나 Zoom 워룸에서 모든 장애를 수동으로 처리하는 상태다.
11. 레벨 1 규칙 자동화는 반복되는 장애에 강하지만 새로운 상황에서 무너진다.
12. 레벨 3 홈그로운 에이전트는 특정 서비스나 알림 집합을 잘 디버깅한다.
13. 레벨 4는 수백 개 서비스와 저장소, 수천 개 로그 인덱스를 가로질러 진단한다.
14. 레벨 5는 근본 원인을 찾아 수정하고 수정 결과까지 검증하는 폐쇄 루프다.
15. Traversal은 수조 개의 로그와 스팬, 수백억 개의 메트릭과 이벤트를 처리한다고 설명한다.
16. Pepsi는 주당 수천~수만 개 알림과 엔지니어 한 명당 700개 backlog 문제를 겪었다.
17. American Express는 인시던트마다 5~10개 팀과 20~50명의 엔지니어를 호출하곤 했다.
18. Traversal은 브리지 선언 후 3분 안에 Slack에 근본 원인 분석을 게시하는 첫 대응자가 된다.
19. AI SRE는 모든 데이터를 보고 비용 효율적으로 검색하며 관계를 매핑하고 스스로 개선해야 한다.
20. 프로덕션 월드 모델과 인과 검색 엔진은 레벨 5 자율주행 운영을 가능하게 하는 핵심 계층이다.