AI로 AI를 디버깅하다 — Incident.io의 내부 도구 철학
📺 원본 영상: Fighting AI with AI — Lawrence Jones, Incident 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-05-18 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 강연은 Incident.io의 창립 엔지니어인 Lawrence Jones가 자사의 AI SRE(Site Reliability Engineering) 제품을 개발하면서 직면한 복잡성 문제를 어떻게 해결했는지를 다룬다. 수백 개의 프롬프트와 수십 개의 에이전트로 구성된 AI 시스템이 인간이 추적하기 불가능할 수준으로 복잡해졌을 때, 그 해결책 역시 AI였다. Eval 자동화, 파일 시스템 기반 디버깅 환경, 그리고 병렬 분석 파이프라인이라는 세 가지 핵심 패턴이 이 강연의 뼈대를 이룬다.
Incident.io와 AI 자동화의 야망
Incident.io는 Netflix, Etsy, Skyscanner 등이 사용하는 인시던트 대응 관리 플랫폼이다. 장애가 발생하면 온콜 담당자에게 알림을 보내고, 인시던트를 운영하면서 고객과의 커뮤니케이션까지 지원한다. 그러나 Lawrence가 이 강연에서 공유하고자 한 것은 단순한 인시던트 관리 기능이 아니었다. Incident.io의 진짜 목표는 프로덕션 장애 조사를 완전히 자동화하는 것이다.
이 목표를 실현하기 위해 그들이 약 1년 반에서 2년에 걸쳐 개발한 것이 AI 기반 인시던트 조사 시스템이다. 인시던트가 시작되는 순간, 시스템은 자동으로 수백 건의 텔레메트리 쿼리를 실행한다. 로그, 메트릭, 트레이스, 과거 인시던트 데이터를 종합하고, 여기에 코드베이스와의 교차 분석까지 더해 “문제의 원인은 이것이고, 이렇게 수정하면 된다”는 형태의 조사 보고서를 생성한다. 단순히 데이터를 나열하는 것이 아니라, 장애의 근본 원인 분석(RCA, Root Cause Analysis)까지 자동으로 제시하는 것이다.
01:50 - 수백 건의 텔레메트리 쿼리, 로그/메트릭/트레이스 분석 결과가 표시된 AI 조사 보고서 화면
문제는 이 수준의 조사 보고서 하나가 제대로 작성됐는지를 인간이 검증하는 데만 약 한 시간이 걸린다는 점이었다. 인시던트 전체를 다시 파악하고, 포스트모텀을 읽고, 그 맥락 위에서 보고서의 정확성을 판단해야 하기 때문이다. 그리고 그 보고서 뒤에는 수백, 수천 개의 프롬프트가 존재한다. 수십 개의 고객사 계정에서 매일 이 시스템이 돌아가고 있는 상황에서, 인간의 힘만으로는 이 시스템의 성능을 파악하는 것 자체가 불가능해졌다.
Eval — AI 시스템의 단위 테스트
Lawrence는 Eval을 “AI 단위 테스트”라고 정의한다. 각 Eval은 특정 프롬프트에 입력 데이터를 주고, 프롬프트를 실행해 출력을 받은 뒤, 사전에 정의된 채점 기준(grading criteria)에 따라 통과/실패를 판정하는 구조다. Incident.io에서는 Go 언어로 모든 개발을 진행하며, Eval은 프롬프트 파일 바로 옆에 YAML 파일 형태로 관리된다.
강연 중에 제시된 예시는 메시지를 해적 말투로 번역하는 단순한 프롬프트다. 이 프롬프트의 Eval에는 두 가지 채점 기준이 정의된다. 하나는 출력이 실제로 해적 말투처럼 보이는가이고, 다른 하나는 입력 메시지의 의미가 출력에서 보존되었는가다. 이 두 기준을 모두 통과해야 Eval이 성공으로 기록된다. 프롬프트를 수정할 때마다, 머지(merge) 전에 반드시 Eval을 통과시켜야 하는 것이 팀의 규칙이다.
05:02 - 채점 기준(grading criteria), YAML 테스트 케이스, 실행 결과가 사분면으로 표시된 Eval 구조 전체 화면
Eval 도구의 한계 — 그리고 에이전트 친화적 CLI의 탄생
이 방식은 잘 작동했지만, 규모가 커지면서 두 가지 근본적인 문제가 드러났다. 첫째, 현실적인 테스트 데이터를 작성하기가 극도로 어렵다는 점이었다. Incident.io의 프로덕션 Eval에는 인시던트 전체 보고서에 해당하는 데이터가 필요한 경우가 있다. 이런 케이스는 프로덕션에서 직접 가져와야 하는데, 그렇게 되면 YAML 파일 하나가 2메가바이트에 달하는 방대한 크기가 되어버린다. 코드베이스에 이런 파일들이 쌓이기 시작하면 유지보수가 사실상 불가능해진다.
팀은 이 문제에 대응하기 위해 프로덕션에서 Eval을 “훔쳐오는” 버튼을 일찍이 만들었다. AI 인터랙션에서 문제가 발생하면, 해당 케이스를 바로 코드베이스로 끌어당겨 Eval 테스트 스위트에 추가할 수 있는 기능이었다. 그러나 프로덕션 Eval은 이상적인 단위 테스트가 아니다. 좋은 단위 테스트는 하나의 명확한 동작에 집중해야 하지만, 2MB짜리 YAML 덩어리는 그 반대다.
둘째이자 더 심각한 문제는, 이 거대한 YAML 파일들이 코딩 에이전트의 컨텍스트 윈도우를 빠르게 소진시킨다는 점이었다. Eval 스위트를 에이전트로 빠르게 읽고 수정하려고 해도, 파일을 컨텍스트에 로드하는 순간 한계에 부딪히기 때문에 에이전트가 제대로 작동할 수 없었다.
이 문제의 해결책으로 탄생한 것이 eval tool이라는 소규모 CLI 도구다. 이 도구는 에이전트가 Eval 스위트 파일을 효과적으로 다룰 수 있도록 설계된 인터페이스를 제공한다. “이 프롬프트에 어떤 테스트 케이스들이 있는가?”, “특정 케이스를 수정하고 싶다”, “새 케이스를 추가하고 싶다”, “기존 케이스를 교체하고 싶다” 같은 명령을 CLI를 통해 처리할 수 있다. 에이전트는 거대한 YAML 파일을 통째로 읽는 대신, 이 CLI를 통해 필요한 부분만 조작함으로써 컨텍스트 효율을 극적으로 높일 수 있게 됐다.
에이전트 주도 Eval 워크플로우 — 런북의 힘
eval tool이 마련되자, 팀은 코딩 에이전트가 따를 수 있는 런북(runbook)을 작성했다. Lawrence는 런북을 “스킬(skill)“이라고도 부르는데, 본질은 에이전트에게 Eval 작업을 처리하는 표준 절차를 알려주는 문서다. 이 워크플로우는 다음과 같은 흐름으로 진행된다.
에이전트는 먼저 문제가 있는 프롬프트를 살펴보고, 현재 동작이 기대 동작과 어떻게 다른지를 확인한다. 그런 다음 해당 실패를 재현하는 Eval 케이스를 직접 생성한다. Eval이 실패하는 상태를 확인한 뒤, 프롬프트를 수정해 해당 Eval이 통과하도록 만든다. 여기서 끝이 아니다. 런북의 가장 중요한 단계 중 하나는 새로운 수정이 기존의 다른 Eval들을 깨뜨리지는 않았는지 전체 테스트 스위트를 검증하는 것이다. 마지막으로, 반복적인 수정으로 인해 프롬프트가 비대해지는 것을 막기 위해 프롬프트 자체를 간결하게 정리하는 최종 패스도 포함되어 있다.
강연자는 이 워크플로우를 Claude Code 안에서 직접 사용하는 모습을 보여주었다. 실제 예시는 인간의 자연어 쿼리를 Loki와 같은 로그 쿼리 시스템에 맞는 쿼리로 변환하는 프롬프트였다.
08:21 - Claude Code 세션에서 eval tool을 사용해 에이전트가 새 Eval 케이스를 추가하고 통과율을 검증하는 모습
에이전트는 새로운 Eval 케이스를 추가하고, 일정 횟수 이상 반복 실행해 통과율이 허용 범위 안에 들어오는지를 스스로 검증한 뒤 작업 완료를 선언했다. 이 워크플로우 덕분에 프롬프트를 어떻게 수정해야 하는지를 안다는 전제 하에, 실제 수정 작업을 상당히 신뢰성 있게 자동화할 수 있게 됐다.
하나의 프롬프트가 아니다 — 복잡성의 폭발
그러나 이 Eval 워크플로우도 더 근본적인 문제를 해결하지는 못했다. 어떤 프롬프트를 수정해야 하는지 이미 알고 있는 경우에는 강력하지만, 현실에서 프로덕션 AI 시스템은 단 하나의 프롬프트로 이루어지지 않는다는 것이다. Incident.io의 챗봇 하나만 해도, 그 뒤에서 작동하는 에이전트, 도구, 서브에이전트의 계층 구조를 그래프로 시각화하면 10개 이상의 에이전트와 수십 개의 구성 요소가 얽혀 있다. Lawrence에 따르면 실제로는 화면에 다 담을 수 없을 정도로 크다고 한다.
09:13 - 10개 이상의 에이전트와 수십 개 구성 요소로 이루어진 챗봇 시스템의 전체 에이전트·도구·프롬프트 계층 시각화
인시던트 조사 시스템은 더 복잡하다. 조사 과정의 각 단계가 개별 트레이스로 펼쳐지고, 각 트레이스는 또다시 수백 개의 프롬프트와 도구 호출로 구성된다. 어느 한 단계에서 미묘한 오류가 발생하더라도, 그 오류가 어디서 시작됐는지를 시스템 전체에서 역추적하는 것은 인간에게는 사실상 불가능에 가깝다. 최종 RCA가 완전히 틀렸다는 것은 알아도, 수백 개의 중간 단계 중 어디에서 잘못됐는지를 특정하는 것은 별개의 문제다.
09:57 - 인시던트 조사 시스템의 단계별 실행 흐름과 우측의 상세 트레이스 뷰 — 각 블록이 수백 개의 하위 프롬프트로 구성됨
팀은 이 문제를 인간이 볼 수 있는 UI 도구를 만드는 것으로 일부 해결했다. 그러나 그것만으로는 충분하지 않았다. UI는 인간이 하나씩 들여다보는 용도로는 훌륭하지만, 에이전트가 프로그래밍 방식으로 활용할 수는 없었기 때문이다. 도구는 있는데, 에이전트가 쓸 수 없는 상황이었다.
파일 시스템 — 에이전트가 가장 잘 읽는 형식
이 문제에 대한 결정적인 돌파구는 Anthropic이 Claude Code를 출시하면서 얻은 통찰에서 영감을 받았다. 코딩 에이전트는 파일 시스템을 다루는 데 탁월하다는 것이다. 복잡한 MCP(Model Context Protocol) 레이어나 별도의 에이전트 간 통신 구조보다, 단순히 파일 시스템을 순회하며 표준 도구로 데이터를 분석하는 것이 훨씬 더 효과적이라는 점이 확인됐다.
Lawrence 팀이 내린 결론은 단순하면서도 강력했다. UI에서 인간이 보는 모든 것을 파일 시스템으로 다운로드할 수 있게 만들자는 것이었다. 이제 각 AI 시스템의 상호작용 전체를 파일 시스템으로 내보낼 수 있으며, 이 패키지를 Claude Code 샌드박스에 그대로 드롭하면 된다. 에이전트는 모든 프롬프트에 들어간 입력을 볼 수 있고, 파일 구조 자체가 자기 설명적(self-documenting)이기 때문에 별도의 문서 없이도 시스템의 구조를 파악할 수 있다. 코드베이스에도 동시에 접근할 수 있기 때문에, 문제를 발견하면 어느 파일의 어느 프롬프트를 수정해야 하는지까지 정확하게 알려준다.
ASCII 텍스트 형식으로 변환할 수 있는 내용의 범위도 생각보다 훨씬 넓다. 복잡한 분산 트레이스(distributed trace)도 UI에서 표현하는 방식 그대로 텍스트 파일로 변환할 수 있고, LLM은 이를 매우 효과적으로 소화한다. 실제 디버깅 흐름은 다음과 같다. 고객으로부터 잘못된 경험이 발생했다는 보고를 받으면, 해당 인터랙션을 파일 시스템으로 다운로드해 Claude Code 세션에 드롭한다. 그리고 에이전트에게 “이걸 보고, 무엇이 잘못됐다고 생각하는지 말해줘”라고 묻는다. 에이전트가 문제를 진단하면, “그러면 시스템의 어느 부분을 바꿔야 해?”라고 이어서 물으면 된다. 에이전트는 도구와 프롬프트의 계층 구조를 탐색하고, 수정 지점을 특정하며, 그 자리에서 바로 코드를 수정하고 앞서 설명한 Eval 런북으로 검증까지 수행한다.
대규모 분석 파이프라인 — Scrapbook의 등장
개별 인터랙션을 디버깅하는 문제는 해결됐지만, 더 큰 규모의 문제가 남아 있었다. Incident.io는 매일 수백 개의 고객 계정에서 수천 건의 조사를 실행한다. 이 전체 시스템이 어제보다 나아졌는지 나빠졌는지를 어떻게 파악할 것인가?
팀은 이를 위해 “백테스트(backtest)“라는 일일 배치 작업을 운영한다. 자사 계정과 다수의 고객 계정에 대해 배치로 조사를 실행하고, 결과를 집계해 단일 정확도 수치로 롤업한다. Lawrence에 따르면 자사 계정에서의 RCA 정확도는 86%까지 올라왔다. 그러나 이 숫자만으로는 시스템을 개선하기에 충분하지 않다. 숫자가 올라간 이유도, 내려간 이유도 알 수 없기 때문이다.
13:01 - 백테스트 집계 결과 화면 — 자사 계정 RCA 정확도 86% 수치 표시
이를 해결하기 위해 팀이 구축한 것이 Scrapbook이라는 레포지토리다. Scrapbook은 구조화된 AI 분석 파이프라인을 담은 공간으로, 마크다운 플레이북(playbook) 형태의 런북이 코딩 에이전트에게 분석 흐름을 안내한다.
13:48 - Scrapbook 레포지토리 내부 디렉토리 구조와 마크다운 플레이북 파일들
파이프라인의 핵심은 병렬화다. 먼저 약 25개의 에이전트를 동시에 실행해, 각 에이전트가 개별 조사 건을 독립적으로 분석한다. 에이전트들이 분석을 마치면, 다음 단계에서 코호트 클러스터링(cohort clustering)이 이루어진다. 어떤 유형의 실패들이 반복되는지, 어떤 패턴으로 시스템이 틀리는지를 메타 수준에서 파악하는 것이다. 이 군집화 과정을 거치면 단순한 정확도 수치가 아니라, 특정 고객 계정에서 시스템이 잘 작동하거나 실패하는 구체적인 이유, 그리고 실제로 무엇을 개선해야 하는지에 대한 actionable한 리포트가 생성된다.
이 파이프라인이 효과적으로 작동하기 위한 몇 가지 설계 원칙이 있다. 첫째, 개별 조사 분석은 반드시 서브에이전트를 통해 병렬로 수행해야 한다. 둘째, 분석 결과는 항상 파일로 저장해서 파이프라인이 중단되더라도 이어서 재개할 수 있어야 한다. 셋째, 조사 파일 시스템 외에 실제 시스템의 코드베이스도 함께 로드해야 한다. 문제를 발견했을 때 코드베이스를 참조해야만 수정 지점을 특정하고 변경안을 제안할 수 있기 때문이다. 이 모든 것이 하나의 Claude Code 세션 안에서 이루어지므로, 분석이 끝나는 즉시 코드 수정을 지시하고, Eval로 검증하고, PR을 생성하는 것까지 하나의 흐름으로 이어진다.
마무리 — 내부 도구에도 AI를 투자하라
Lawrence는 이 패턴들이 Incident.io에만 해당하는 것이 아니라 복잡한 AI 시스템을 개발하는 누구에게나 일반화될 수 있다고 강조한다. 프로덕트에 AI를 쏟아붓는 만큼, 내부에서 그 AI 시스템을 이해하고 디버깅하고 진화시키는 도구에도 동등한 수준의 AI를 투자해야 한다는 것이다.
실용적인 권고사항을 정리하면 다음과 같다. 에이전트가 활용할 수 있는 형태로 디버깅 도구를 설계해야 한다. 단순히 인간이 보기 좋은 UI를 만드는 것에 그쳐서는 안 된다. 파일 시스템은 에이전트에게 탁월한 컨텍스트 전달 매체다. MCP나 복잡한 API 레이어보다, 관련 정보를 파일로 일괄 다운로드해서 에이전트가 자유롭게 탐색하게 하는 접근이 훨씬 강력하다. 복잡한 반복 분석이 필요한 작업이라면, 그 분석을 위한 AI 런북을 만들어라. 한 번 잘 만들어진 런북은 며칠, 경우에 따라서는 몇 주치의 반복 분석 작업을 대체한다.
Lawrence는 이 패턴들이 자신의 팀에서 AI SRE 시스템을 개발하는 과정에서 점진적으로 발견되고 검증된 것들임을 강조했다. 복잡한 AI 시스템을 다루면서 그 복잡성 자체와 싸우는 가장 효과적인 무기 역시 AI라는 것, 그것이 이 강연의 핵심 메시지다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Fighting AI with AI — Lawrence Jones, Incident |
| 채널 | AI Engineer |
| 강연자 | Lawrence Jones (Incident.io 창립 엔지니어) |
| 리포트 작성 | 2026-05-18 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.