The 5 Levels of Self-Driving Production — Eric Schwartz, Traversal

한 줄 핵심

코딩 에이전트로 개발 속도는 빨라졌지만 운영 복잡도와 장애 대응 비용이 폭증했으며, Traversal은 이를 대규모 생산 환경에서 원인 분석·수정·검증까지 자동화하는 'self-driving production'으로 풀려는 접근을 제시한다.

시간별 요약

1. 0:00
   도입 배경 음악으로 시작하며 발표의 분위기를 여는 구간이다.
2. 0:12
   발표 개요 AI 에이전트가 SDLC를 어떻게 바꾸는지, 그로 인해 생기는 엔지니어링 문제, 그리고 Traversal이 AI SRE로 이를 어떻게 해결하는지의 흐름을 설명한다. 이어서 기업 고객 사례와 제품 구조를 보여주겠다는 예고를 한다.
3. 1:02
   코딩 에이전트가 SDLC를 바꾼 방식 소프트웨어 엔지니어링은 시스템 설계, 개발, 트러블슈팅의 세 축으로 나뉘며, 코딩 에이전트로 인해 개발 구간이 크게 단축되었다. 그 결과 더 많은 인력이 프로덕션 코드를 만들 수 있게 되었지만, 설계와 장애 대응의 비중은 상대적으로 더 중요해졌다.
4. 2:02
   코드가 늘수록 트러블슈팅도 늘어난다 더 많은 코드가 더 빠르게 배포되면서, 프로덕션에 들어가는 코드에 대한 이해도는 낮아지고 환경은 더 복잡해진다. 그 결과 팀의 시간이 창의적 설계보다 문제 해결에 더 많이 묶이게 된다.
5. 2:32
   트러블슈팅의 비용 기업은 트러블슈팅에 연간 수천억 달러를 쓰고 있고, 엔지니어는 온콜 중 매주 7시간 이상을 장애 대응에 잃는다는 데이터가 제시된다. Cloud Code, CodeX, Cursor 같은 도구가 코딩을 가속할수록 이 비용은 더 커질 수밖에 없다고 본다.
6. 3:12
   관측 도구가 멈추는 지점 Datadog, Elastic, Splunk, ServiceNow 같은 관측 도구는 무엇이 깨졌는지는 알려주지만, 왜 깨졌는지와 무엇을 해야 하는지는 알려주지 못한다. 대시보드를 늘려도 팀이 복잡도 증가 속도를 따라잡기 어렵다는 문제가 강조된다.
7. 4:01
   LLM도 근본 원인 파악은 어렵다 Google의 SRE 관점과 Anthropic의 언급을 빌려, LLM 역시 근본 원인 분석에 강하지 않다고 설명한다. 단순히 로그를 읽는 수준을 넘어 원인을 특정하는 일이 본질적으로 어렵다는 문제의식이 이어진다.
8. 4:31
   다단계 실패가 원인 분석을 어렵게 만드는 이유 겉으로는 checkout API 실패처럼 보이더라도 실제 원인에 도달하려면 수많은 서비스와 방대한 데이터 사이를 여러 단계 건너뛰어야 한다. 대기업 환경에서는 한 사람이 전체 맥락을 갖고 있지 않기 때문에, 결국 여러 엔지니어가 모인 war room이 길어질 수밖에 없다.
9. 5:46
   근본 원인은 인과 문제다 Traversal은 근본 원인 분석을 관측성의 문제가 아니라 인과 추론의 문제로 정의한다. 창업팀이 인과 머신러닝을 오랫동안 연구해 온 배경도 이 문제를 푸는 데 맞춰져 있다.
10. 6:26
    자율 운용되는 프로덕션의 정의 self-driving production은 장애나 알림이 발생하면 AI가 원인을 찾고, 수정안을 제시하고, 수정이 실제로 해결됐는지 검증하는 닫힌 고리 시스템이다. 사람이 깨우지 않아도 운영이 계속 돌아가도록 만드는 것이 목표다.
11. 7:06
    자율성의 다섯 단계 수동 대응이 전부인 0단계에서 시작해, 규칙 기반 자동화, 부분적 에이전트, 특정 서비스에 특화된 에이전트로 점점 올라간다. 핵심 도약은 전체 환경을 가로지르는 4단계이며, 최종 5단계는 진단뿐 아니라 수정과 검증까지 자동으로 수행하는 수준이다.
12. 8:50
    엔터프라이즈 규모에서의 Traversal American Express, Pepsi, Digital Ocean, Capital One 같은 대형 고객과 함께 수조 단위의 로그, 스팬, 메트릭을 처리한다고 설명한다. 이 규모에서 높은 비율로 근본 원인을 찾아내는 점이 기술적 성과로 제시된다.
13. 9:35
    활용 사례 Traversal의 주요 활용처로 알림 인텔리전스, 사건 RCA, 셀프 힐링, 운영 지원, 프리프로덕션 코드 회복성 검증이 소개된다. 이 중 알림 인텔리전스와 사건 근본 원인 분석이 특히 자세히 다뤄진다.
14. 11:05
    PepsiCo의 알림 인텔리전스 사례 Pepsi는 공급망 시스템에서 매주 수만 건의 알림을 받았고, 엔지니어 한 명당 700개씩 쌓이는 상황에 놓여 있었다. Traversal은 알림을 사전 조사하고 우선순위를 매겨, 정말 봐야 할 것만 남기고 노이즈는 규칙 수정·무시·티켓화로 정리하게 돕는다.
15. 12:55
    American Express의 사건 RCA 사례 이전에는 하나의 장애에 5~10개 팀과 20~50명의 엔지니어가 동원되었고, 해결까지 60분 이상 걸리거나 더 오래 지속되기도 했다. Traversal은 사건이 선언되면 3분 안에 Slack과 ServiceNow에 상세 RCA를 제공해, 불필요한 페이징을 크게 줄인다.
16. 14:44
    AI SRE에 던져야 할 다섯 가지 질문 모든 프로덕션 데이터를 볼 수 있는지, 대규모 데이터를 비용 폭증 없이 검색할 수 있는지, 데이터 간 관계를 맵핑할 수 있는지, 시간이 지나며 스스로 더 똑똑해지는지, 그리고 여러 단계를 건너뛰어 비자명한 원인을 빠르게 찾을 수 있는지를 확인해야 한다. 특히 온콜 환경에서는 몇 분 이상 지체되면 실무 대응 품질이 급격히 떨어진다.
17. 16:39
    Traversal의 스택 Traversal의 구조는 데이터를 저비용으로 수집·연결하는 층, 데이터를 해석하는 production world model, 그리고 제품 경험으로 출력하는 층으로 나뉜다. Fortune 500 규모에서 이 세 부분을 모두 맞춰야만 실제 운영 가치가 나온다고 본다.
18. 17:39
    프로덕션 월드 모델과 인과 탐색 production world model은 연결된 모든 데이터를 관계 중심으로 이해하게 해 주는 기반이며, causal search engine은 그 위에서 원인과 결과를 추적하는 탐색 장치다. 이 조합이 대규모 엔터프라이즈를 5단계 자율 운영으로 이끄는 핵심이라고 결론짓는다.

실무 인사이트

• 운영 자동화의 핵심은 알림을 줄이는 것이 아니라, 원인 규명과 검증까지 포함한 폐쇄 루프를 만드는 데 있다.
• 대규모 프로덕션에서는 관측성 도구만으로는 부족하므로, 데이터 관계를 모델링하는 인과 기반 접근이 필요하다.
• AI SRE 도입을 검토할 때는 '얼마나 많이 볼 수 있는가'보다 '얼마나 빨리, 얼마나 정확히, 얼마나 적은 인력 개입으로 원인을 찾는가'를 기준으로 평가해야 한다.