장애 디버깅 에이전트 구축: 지금까지 배운 점들

데이터 파이프라인 (Data pipeline) 다운타임은 기업에 시간당 15만 달러에서 54만 달러의 비용을 발생시킵니다. 평균적인 장애 (incident)는 수동으로 진단하는 데 2~4시간이 소요되는데, 그 시간의 대부분은 실제로 문제를 해결하는 것이 아니라 다섯 가지 서로 다른 도구를 통해 리니지 (lineage)를 추적하는 데 소비됩니다. 우리는 이러한 진단 병목 현상을 제거하기 위해 장애 디버깅 에이전트 (Incident Debugging Agent)를 구축했습니다.

우리가 구축을 시작한 지점은 장애 디버깅입니다. 이것이 가장 쉬운 문제이기 때문이 아니라, 가장 고통스러운 문제이기 때문입니다. 우리가 대화한 모든 데이터 엔지니어 (data engineer)들은 동일한 경험을 설명했습니다. 알림 (alert)이 발생하면 노트북을 열고, 이후 2~4시간 동안 다섯 가지 서로 다른 도구를 사용하여 수동으로 문제를 추적하는 것입니다.

에이전트가 하는 일

데이터 장애가 발생하면, 에이전트는 다음과 같은 작업을 수행합니다:

• 알림 컨텍스트 (alert context) 수집. 무엇이 실패했는지, 언제 발생했는지, 어떤 시스템이 보고했는지 파악합니다.

• 진단 쿼리 (diagnostic queries) 실행. 영향을 받은 테이블과 그 상위 의존성 (upstream dependencies)에 대해 최신성 (freshness), 행 수 (row counts), Null 비율 (null rates), 스키마 변경 (schema changes), 그리고 값 분포 (value distributions)를 확인합니다.

• 리니지 (lineage) 추적. 데이터 컨텍스트 및 카탈로그 에이전트 (Data Context and Catalog Agent)의 리니지 정보를 사용하여 상위 소스 (upstream sources)와 하위 소비자 (downstream consumers)를 식별합니다. 영향 범위 (blast radius)를 매핑합니다.

• 최근 변경 사항과 상관관계 분석. dbt 배포 로그 (deployment logs), 스키마 마이그레이션 이력 (schema migration history), 그리고 오케스트레이터 (orchestrator) 실행 기록을 확인하여 장애를 설명할 수 있는 최근의 변경 사항이 있는지 점검합니다.

• 진단 생성. 예상되는 근본 원인 (root cause), 영향을 받은 자산 (affected assets), 영향 범위 (blast radius)

• 평균 진단 시간 (Mean time to diagnosis): 수동 디버깅 시 몇 시간이 걸리던 작업이 몇 분 단위로 단축되었습니다.

• 근본 원인 정확도 (Root cause accuracy): 진단의 대다수가 근본 원인을 정확하게 식별합니다. 나머지 경우는 기여 요인 (contributing factor)은 식별하지만 주요 원인 (primary cause)을 놓칩니다.

중요한 주의 사항: 이는 소수의 환경에서 발생한 제한된 과거 장애 사례들을 바탕으로 얻은 초기 결과입니다. 저희는 이를 운영 환경에 즉시 적용 가능하다는 주장(production readiness)을 하기 위함이 아니라, 방향성 있는 진전(directional progress)을 보여드리기 위해 공유합니다.

실패하는 지점

• 새로운 장애 모드 (Novel failure modes): 에이전트는 패턴을 경험하지 못한 장애, 즉 미묘한 데이터 드리프트 (data drift), 비즈니스 로직의 변경, 데이터 문제로 나타나는 인프라 문제 등에는 어려움을 겪습니다.
• 시스템 간 상관관계 (Cross-system correlation): 근본 원인이 여러 시스템에 걸쳐 있을 때, 에이전트의 상관관계 분석 능력이 현저히 떨어집니다.
• 의미론적 이해 (Semantic understanding): 에이전트는 특정 컬럼의 값이 변경되었다고 말할 수는 있습니다. 하지만 그 값들이 틀린 것인지까지는 판단할 수 없습니다.
• 거짓된 확신 (False confidence): 에이전트는 때때로 그럴듯하게 들리지만 틀린 진단을 생성하기도 합니다.

신뢰에 대해 배운 점

데이터 엔지니어들은 직접 검증할 수 없는 진단을 신뢰하지 않습니다. 모든 디자인 파트너 (design partner)와의 대화에는 다음과 같은 취지의 질문이 포함되었습니다: "이 기능은 멋지지만, 이것이 맞다는 것을 어떻게 알 수 있나요?" 모든 쿼리와 결과를 보여주는 증거 체인 (evidence chain)은 있으면 좋은 기능 (nice-to-have feature)이 아닙니다. 그것이 바로 핵심 기능 (the feature)입니다.

또한 에이전트가 "모르겠습니다"라고 말할 수 있어야 한다는 점도 배웠습니다. 초기 버전은 증거가 모호할 때조차 항상 진단을 내놓았습니다. 엔지니어들은 "이러한 이상 징후들을 발견했지만, 확정적인 근본 원인은 판단할 수 없습니다"라고 말하는 에이전트보다, 억지로 진단을 내놓는 에이전트를 덜 신뢰한다는 것을 발견했습니다.

원문은 https://dataworkers.io/blog/building-incident-debugging-agent/ 에 게시되었습니다. Data Workers는 데이터 엔지니어링을 위한 오픈 소스 자율 에이전트 스웜 (autonomous agent swarm)입니다 — 리포지토리 확인.