Databricks가 AI를 활용하여 인시던트 조사를 가속화하는 방법

이전 블로그 포스트에서 Databricks가 AI를 사용하여 수천 개의 데이터베이스를 디버깅하는 방법을 공유해 드렸습니다. 여기서는 저희 엔지니어들이 AI를 활용해 70개 이상의 리전과 3개의 클라우드에 걸쳐 있는 1,500개 이상의 Kubernetes 클러스터에서 수백 개의 마이크로서비스를 운영하는 방법을 살펴보며 그 이야기를 이어가고자 합니다.

새벽 2시에 문제가 발생하면, 온콜(on-call) 엔지니어는 한 가지 질문에 신속하게 답해야 합니다. 바로 '무엇이 변경되었는가?'입니다.

AI SRE는 장애(incident)가 발생하자마자 조사를 시작하는 AI 기반 디버깅 에이전트입니다. 전체 스택에서 발생하는 신호들을 서로 연결하고 엔지니어가 근본 원인 분석을 수행할 수 있도록 안내합니다.

본 포스트에서는 AI SRE를 탄생시킨 디버깅 여정, 그 뒤에 숨겨진 아키텍처, 그리고 장애 상황에서도 LLM 기반 시스템을 신뢰할 수 있도록 만들기 위해 준수한 엔지니어링 원칙을 설명합니다.

AI SRE 도입 전: 새벽 2시의 경험

일반적인 온콜 호출 상황을 상상해 보세요. 고객용 API에 대기 시간(latency) 급증 현상이 발생합니다. 엔지니어는 잠에서 깨어 익숙한 작업을 시작합니다.

• 여러 대시보드와 리전에서 서비스 메트릭을 검사합니다.
• 로그에서 관련성이 있으면서도 특이한 오류를 검색합니다.
• 배포, 종속성 변경 사항, 피처 플래그(feature-flag) 업데이트를 검토합니다.
• 클라우드, 네트워크, 공유 플랫폼의 상태를 확인합니다.
• 적절한 런북(runbook)을 찾아 실행합니다.

이러한 각각의 워크플로우는 개별적으로는 잘 작동하지만, 이들 간의 신호를 연결하는 디버깅 워크플로우는 전적으로 엔지니어의 머릿속에서 이루어집니다. 숙련된 엔지니어는 이전에 유사한 패턴을 본 적이 있어 몇 분 만에 해결할 수 있지만, 초임 엔지니어는 몇 시간을 허비하거나 다른 사람에게 에스컬레이션해야 할 수도 있습니다.

도구 자체가 주된 문제는 아니었습니다. 여러 신호를 연결해야 하는 부담이 SLA를 준수해야 하는 온콜 엔지니어에게 고스란히 전가되는 것이 문제였습니다.

기술이 아닌 고객에서 출발하기

저희는 에이전트를 구축하는 것부터 시작하지 않았습니다. 사람들이 디버깅하는 모습을 관찰하는 것부터 시작했습니다.

몇 주 동안 수십 개의 팀에 소속된 온콜 엔지니어들을 인터뷰하여 이들의 디버깅 여정을 처음부터 끝까지 파악했습니다. 사후 분석(postmortem) 보고서와 조사 문서도 읽어보았습니다. 그리고 '어디에서 시간을 가장 많이 보내고, 어디에서 막히나요?'라는 간단한 질문을 던졌습니다.

그 결과 세 가지 패턴이 일관되게 나타났습니다.

• 맥락을 파악하는 데 대부분의 시간이 소요되었습니다. 엔지니어 앞에 올바른 신호가 주어지면 근본 원인을 파악하는 실제 '아하!' 모먼트는 대개 빠르게 찾아왔습니다. 하지만 이러한 신호(올바른 메트릭, 적절한 시간대, 관련 배포, 변경된 업스트림 종속성 등)를 수집하는 데 조사 시간의 60~80%가 소요되었습니다.
• 지식이 고르게 분포되어 있지 않았습니다. 모든 팀에는 시스템이 어떻게 실패하는지 '그냥 아는' 몇 명의 전문가가 있었습니다. 이 전문가들이 부재중일 때는 조사 속도가 급격히 느려졌습니다. 런북이 존재하긴 했지만 대개 최신 상태가 아니거나 불완전했으며, 새로운 실패 모드에는 대처할 수 없었습니다.
• 플랫폼 상태는 문제가 터지기 전까지는 보이지 않았습니다. 많은 장애가 클라우드 제공업체나 네트워크 중단과 같은 대규모 인프라 문제, 또는 Auth(인증)와 같은 핵심 시스템 장애에서 비롯되었습니다. 하지만 애플리케이션 레이어에서 디버깅하는 엔지니어는 이러한 신호를 쉽게 확인할 방법이 없었기 때문에, 하위 인프라 레이어에 문제가 있다는 사실을 발견하기 전에 애플리케이션 수준의 가설을 검증하느라 시간을 허비하곤 했습니다.

디버깅이 반복 가능한 조사 단계와 전문가의 판단이 결합된 일련의 과정임을 인식한 후, AI 에이전트가 이 작업을 가속화할 수 있음이 분명해졌습니다. 하지만 단일 팀이 모든 서비스, 신호, 실패 모드를 이해하는 에이전트를 구축할 수는 없었습니다. 저희에게는 맥락 수집, 도구 및 런북 실행, 증거 연관성 분석과 같은 공통 빌딩 블록을 처리하는 동시에, 각 팀이 자체적인 운영 지식으로 이를 확장할 수 있는 공유 플랫폼이 필요했습니다. 이에 따라 질문은 '디버깅을 자동화할 수 있는가?'에서 '어떻게 하면 모든 팀에 더 빠르고 정보에 기반한 진단 및 해결을 지원하는 AI 기반 플랫폼을 제공할 수 있을까?'로 전환되었습니다.

AI SRE를 소개합니다

AI SRE는 두 가지 상호 보완적인 경험을 지원합니다. 장애가 발생할 때 시작되는 자동 분류(automatic triage)와 온콜 엔지니어가 가설을 탐색하고 추가 증거를 요청할 수 있는 대화형 조사(interactive investigation)입니다.

장애 발생 시 자동 분류

장애가 발생하면 엔지니어가 노트북을 열기도 전에 AI SRE가 즉시 작동하기 시작합니다. AI SRE는 병렬로 세 가지 조사 트랙을 실행하여 상호 보완적인 증거를 수집하고 초기 평가를 생성합니다.

플랫폼 상태 확인은 서비스가 실행 중인 환경을 평가합니다.

• 기반 클라우드 인프라가 정상인가요?
• 해당 리전에 진행 중인 네트워크 문제가 있나요?
• 업스트림 종속성(데이터베이스, 메시지 큐, 공유 서비스)의 성능이 저하되고 있나요?

이것만으로도 수많은 혼란스러운 요소를 제거할 수 있으므로, 엔지니어가 애플리케이션 코드를 디버깅하는 데 30분을 허비한 후에야 근본 원인이 대규모 인프라 문제였음을 깨닫는 일이 없어집니다.

서비스 수준 분석은 영향을 받은 서비스 및 해당 서비스의 직간접적 종속성에 대한 관련 로그, 메트릭, 트레이스(trace)를 가져옵니다. 최근 배포 및 구성 변경 사항을 검토합니다. 단순히 "CPU 사용량이 높음"이 아니라 "처리 파이프라인의 배치 크기를 변경한 배포와 맞물려 오전 2시 47분에 CPU가 3배 급증함"과 같이 서비스의 기준 동작과 비교하여 이상 징후를 식별합니다.

런북 실행 단계에서 AI SRE는 팀별 맞춤형 페르소나를 취합니다. 각 팀은 도메인 전문가가 실행할 검사, 모니터링할 임계값, 취해야 할 완화 조치 등 자신들의 디버깅 절차를 인코딩합니다. 팀은 스킬을 사용하여 기존 런북을 에이전트형 런북(agentic runbooks)으로 변환할 수 있습니다. 이러한 스킬은 코드베이스, 관측 가능성(observability) 데이터, 과거 장애 이력을 활용하여 런북을 더욱 정확하고 맥락에 맞게 만듭니다. 그런 다음 온콜 엔지니어를 대신하여 이러한 단계를 실행하며, 도메인 전문가가 수행할 조사를 몇 분이 아닌 몇 초 만에 완료합니다.

엔지니어가 장애 세부 정보를 처음 읽을 때쯤이면 AI SRE는 이미 풍부한 진단 요약을 구성해 둔 상태입니다. 무엇이 고장 났는지, 무엇이 변경되었는지, 팀의 런북에서 확인하라고 지시하는 사항은 무엇인지 등 모든 신호, 연관성, 다음 단계가 단일 뷰에 제공됩니다.

심층 조사를 위한 대화형 디버깅

모든 조사가 자동 분류로 끝나는 것은 아닙니다. 때로는 근본 원인이 미묘하거나 엔지니어가 가설을 탐색하고 싶어 할 수 있습니다. AI SRE UI는 엔지니어가 자연어로 후속 질문을 하고, 추가 신호를 요청하며, 특정 시간대나 구성 요소를 상세히 분석할 수 있는 대화형 디버깅 환경을 제공합니다.

여기서 구조화된 상태 확인과 대화형 AI의 결합이 강력한 힘을 발휘합니다. 엔지니어가 "이 경고가 발생하기 10분 전에 Kafka 컨슈머 랙(consumer lag)에 특이한 점이 있었나요?"라고 질문하면, AI SRE는 관련 메트릭을 가져와 장애 타임라인과 대조하고 발견한 내용을 설명합니다.

디버깅을 위한 레이어드 아키텍처

고객 인터뷰를 통해 얻은 핵심 인사이트는 디버깅이 단일 문제가 아니라 여러 문제의 스택이며, 이를 해결하려면 의도적인 추상화가 필요하다는 점이었습니다. 저희는 AI SRE를 레이어드 플랫폼으로 설계하여 각 레이어가 명확한 책임을 갖도록 하고, 상위 레이어는 점진적으로 더 높은 수준의 관심사에 집중할 수 있도록 했습니다.

프리미티브(Primitives)는 모든 조사가 궁극적으로 의존하는 가공되지 않은 운영 데이터인 기초를 형성합니다. 메트릭, 경고, 로그, 릴리스 정보, 코드에 대한 프리미티브는 이미 존재하지만, 장애 발생 시 이에 액세스하려면 서로 다른 5가지 쿼리 언어를 사용하는 5가지 도구를 번갈아 사용해야 했습니다. 프리미티브 레이어는 이러한 시스템을 대체하는 것이 아니라, 이를 단일 진실 공급원(source of truth)으로 인정합니다.

API 레이어는 프리미티브를 활용하고 기본 데이터에 대한 제어되고 일관된 액세스를 제공합니다. 모든 디버깅 도구가 로그나 메트릭 저장소와 같은 데이터 소스를 직접 쿼리하도록 하는 대신, 인증, 속도 제한, 데이터 정규화를 처리하는 목적별 API(Observability API, Deployment API, Alerts API)를 구축했습니다. 이 레이어는 "가공되지 않은 인프라"를 "디버깅 가능한 인프라"로 변환하는 역할을 합니다. 또한 기본 시스템을 교체하더라도 상위의 디버깅 도구가 중단되지 않음을 의미합니다.

핵심 엔진은 지능이 작동하는 곳입니다. 봇 프레임워크는 디버깅 워크플로를 구축하기 위한 오케스트레이션 레이어를 제공하며, 엔진은 병렬 실행, 결과 상관관계 분석, LLM 기반 종합의 메커니즘을 처리합니다. 이 플랫폼은 자체 개발 봇이 실행되는 플랫폼이기도 하지만, 무엇보다 중요한 점은 자체 봇을 구축하려는 모든 팀이 동일하게 사용할 수 있는 플랫폼이라는 것입니다.

애플리케이션 레이어는 실제로 디버깅이 이루어지는 곳입니다. 이곳에서 플랫폼 수준의 인시던트 분류 봇이 실행됩니다. 또한 서드파티 AI 도구를 쉽게 연동하여, 처음부터 모든 것을 다시 개발하지 않고도 보완적인 기능을 제공할 수 있는 곳이기도 합니다.

이러한 분리를 통해 중앙에서 관리되는 워크플로와 각 팀이 소유한 런북을 모두 지원하는 동시에, 데이터 액세스 및 오케스트레이션을 독립적으로 개선할 수 있습니다.

비결정적인 환경에서 신뢰성 구축하기

신뢰가 가장 중요한 인시던트 대응 분야에서 LLM 기반 에이전트의 신뢰성을 충분히 확보하려면 정교한 엔지니어링이 필요했습니다. 이를 위해 다음과 같은 몇 가지 원칙을 세웠습니다.

개방형 추론 전에 구조화된 점검을 먼저 수행합니다. AI SRE는 결정론적인 플랫폼 상태 점검과 런북 단계를 먼저 실행합니다. LLM 레이어는 그 결과를 종합하고 설명할 뿐, 데이터 수집 자체를 모델의 판단에만 맡겨두지 않습니다.

블랙박스식 답변보다 투명성을 우선합니다. AI SRE가 제시하는 모든 결론은 특정 메트릭, 로그 라인, 배포 디프(diff) 등 근거가 되는 증거로 연결됩니다. 덕분에 엔지니어는 단순히 결과를 믿는 것을 넘어 추론 과정을 직접 검증할 수 있습니다. 온콜(on-call) 엔지니어는 직접 검증할 수 없는 권장 사항에 따라 조치를 취하지 않기 때문에, 이 부분은 타협할 수 없는 원칙이었습니다.

실패 시 유연한 대처(Graceful degradation). AI SRE가 근본 원인을 확실하게 파악할 수 없는 경우, 이를 명확히 밝히고 수집된 증거를 관련성 순으로 정리하여 제시합니다. 한계를 솔직하게 인정하는 부분적인 조사 결과가 환각 현상(hallucination)으로 만들어진 잘못된 진단보다 훨씬 더 유용합니다.

성과

현재 AI SRE는 Databricks 전반의 150개 이상의 팀을 지원하고 있으며, 250명 이상의 주간 활성 사용자가 매일 2,000건 이상의 조사를 실행하여 디버깅 시간을 매번 몇 시간씩 단축하고 있습니다. 출시 이후 다음과 같은 긍정적인 피드백을 받았습니다.

“스토리지 플랫폼 팀은 인시던트 분류 작업에서 AI SRE에 크게 의존하고 있습니다. 이 에이전트는 제 조사를 앞서서 지원해 줍니다. 제가 경고를 열기도 전에 에이전트가 이미 신호들을 연관 분석하여 초기 근본 원인 분석 결과를 만들어 둡니다. 여러 팀이 에이전트 기반 워크플로를 일상 업무에 자연스럽게 녹여낼 수 있도록 진정으로 범용적인 디버깅 플랫폼을 구축해 준 팀에 찬사를 보냅니다.”—Gaurav Garg, Sr. Staff Engineer

“AI SRE가 도입되기 전에는 인시던트가 발생하면 대시보드, 시간 범위 설정, 전체 시스템 필터링 등 컨텍스트를 수집하는 데 가장 먼저 시간을 써야 했습니다. 이제는 관련 컨텍스트가 경고나 인시던트 범위에 맞춰 한곳에 깔끔하게 정리되어 제공됩니다. 에이전트의 말을 무조건 믿을 필요도 없습니다. 조사 결과에 증거가 포함되어 있어, 클릭 한 번으로 필터링이 완료된 원본 도구를 열어 직접 검증할 수 있습니다.”—Himanshu Mishra, Senior Engineer

“AI SRE는 메트릭, 로그, 종속성 상태를 통합하여 인시던트 분류를 가속화하고 근본 원인을 더 빠르게 파악함으로써 회사 전반의 MTTR을 단축하고 인시던트 대응 방식을 완전히 바꾸어 놓았습니다.”—Adama Kone, NOC 팀 매니저

가장 중요한 성과는 엔지니어의 판단을 대체하는 것이 아니었습니다. 엔지니어들이 증거에 기반하여 더 빠르게 조사를 시작할 수 있도록 돕는 것이었습니다.

배운 점들

AI SRE를 구축하며 얻은 세 가지 교훈은 다음과 같습니다.

각 팀이 전문성을 직접 관리하도록 하세요. 모든 팀의 도메인 지식을 하나의 중앙 집중식 에이전트에 담으려고 하면 정보가 금방 노후화되고 취약해집니다. 에이전트 기반 런북을 각 팀이 직접 소유하고 유지 관리할 수 있는 조합 가능한 기본 구성 요소로 만듦으로써, 플랫폼 자체가 병목이 되지 않으면서도 성장할수록 더 똑똑해지는 플랫폼으로 AI SRE를 발전시킬 수 있었습니다.

모델을 최적화하기 전에 컨텍스트 레이어부터 구축하세요. 저희는 프롬프트 엔지니어링보다 엔지니어들이 실제로 인시던트를 조사하는 과정을 분석하는 데 더 많은 시간을 보냈습니다. 문제를 이해하기 위한 이러한 사전 투자가 있었기에, 단순히 기존 관측 가능성(observability) 시스템에 챗봇을 덧붙이는 뻔한 방식 대신, 컨텍스트를 수집하고 기정의된 점검을 실행하는 에이전트라는 올바른 솔루션을 구축할 수 있었습니다.

추적 가능한 증거를 통해 신뢰를 얻으세요. 온콜 엔지니어는 압박감 속에서 일하기 때문에 잘못된 단서를 쫓을 여유가 없습니다. AI SRE가 제시하는 모든 권장 사항은 추적 가능한 증거를 바탕으로 합니다. 이러한 투명성 덕분에 회의적이었던 초기 사용자들이 매일 시스템을 사용하는 활성 사용자로 전환될 수 있었습니다.

가드레일은 사람보다 에이전트에게 더 중요합니다. 에이전트에게 관측 가능성 데이터에 대한 액세스 권한을 부여하는 것은 단순히 API를 개방하는 것을 넘어 API 레이어를 재설계하는 것을 의미했습니다. 에이전트는 사람과 다르게 쿼리를 보냅니다. 엔드포인트에 일시에 수많은 요청을 보내고, 점검을 병렬로 실행하며, 지치거나 스스로 멈추지 않습니다. 따라서 비즈니스에 중요한 경고 및 모니터링을 구동하는 인프라에 무리를 주지 않으면서도 에이전트가 빠르게 작동할 수 있도록 가드레일을 구축해야 했습니다.

향후 계획

현재 AI SRE는 무슨 일이 왜 일어났는지 이해하는 인시던트 대응의 조사 단계에 집중하고 있습니다. 자연스러운 다음 단계는 단순한 문제 진단을 넘어, 엔지니어가 올바른 완화 조치를 안전하게 취할 수 있도록 돕는 안내형 완화 조치로 영역을 확장하는 것입니다.

또한, 과거 인시던트의 패턴을 활용해 향후 진단 성능을 개선하고, 호출(page)이 발생하기 전에 반복되는 문제를 미리 감지하며, 팀이 시스템적인 신뢰성 결함을 식별할 수 있도록 돕는 인시던트 간 교차 학습에도 투자하고 있습니다.

함께하기

앞으로도 저희는 AI가 프로덕션 시스템을 어떻게 변화시킬 수 있는지 그 한계를 계속 넓혀가고, 복잡한 인프라를 손쉽게 관리할 수 있도록 만드는 일에 도전하고자 합니다. 차세대 AI 기반 내부 플랫폼 구축에 열정이 있으시다면 저희와 함께하세요!

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)