AI 장애 관리(AI Incident Management)를 위해 우리가 "기록(record)"을 어떻게 정의하느냐가 모든 것의 핵심입니다.

좋고 유용하지만, 또한 불완전합니다.

장애는 에이전트가 그럴듯한 근본 원인(root cause)을 내뱉는다고 해서 해결되지 않습니다. 장애는 대응자들이 무엇이 일어났는지, 무엇이 변했는지, 무엇이 제외되었는지, 다음 단계의 담당자가 누구인지, 무엇이 승인되었는지, 그리고 비즈니스 측에 무엇을 전달해야 하는지에 대해 합의할 때 해결됩니다. 그 합의는 지속 가능한 저장 공간이 필요합니다.

실제로 무슨 일이 일어났는지에 대한 해당 기록을 유지하는 에이전트는, 무엇이 잘못되었는지에 대해 그럴듯한 근본 원인을 찾아낸 첫 번째 영리한 에이전트보다 훨씬 더 가치 있습니다.

시장은 알림 요약(alert summarization)을 넘어 이동하고 있습니다

AI 장애 관리(AI Incident Management)는 하나의 명명된 운영 영역(operating surface)이 되어가고 있습니다. NIST는 AI 시스템이 핵심 인프라, 사이버 보안, 국가 안보 전반에 걸쳐 위험의 대상이자 원천이 되고 있기 때문에 AI 장애 관리에 관한 워크숍(Workshop on AI Incident Management)을 개최했습니다. 그것이 이 용어의 거버넌스(governance) 측면입니다. SRE 측면은 더 즉각적입니다. 에이전트들이 실제 운영 워크플로우(operational workflows)에 결합되고 있습니다.

Incident.io는 신뢰성 작업(예: 근본 원인 조사)에서 AI SRE 에이전트를 정의하며, 이는 여러 관측 가능성(observability) 데이터 소스의 데이터와 추론, 이력 데이터, 그리고 작업 실행을 통합합니다. 이러한 에이전트들은 실시간 문제 해결을 위해 온콜(on-call) 워크플로우에 내장될 수 있으며, PagerDuty 장애를 생성하는 것과 같은 작업을 자동화할 수 있습니다. PagerDuty 워크플로우 내에는 두 가지 에이전트가 있습니다. 조사를 수행하고 장애 생성을 유도하는 SRE 에이전트와, 오디오, 채팅, 중요한 결정 및 장애 지식을 캡처하는 Scribe 에이전트가 있습니다.

그러한 조합은 도구의 심각성(seriousness)을 변화시킵니다. 온콜(on-call) 에이전트는 트레이스(traces)를 조사하고, 로그(logs)를 가져오며, 런북(runbooks)을 열고, 최근 배포(deploys)를 비교하며, 이해관계자 업데이트(stakeholder update) 초안을 작성할 수 있습니다. 에이전트는 방금 잠에서 깨어난 사람보다 더 나은 컨텍스트(context)를 가지고 상황에 개입할 수 있습니다.

함정은 그 컨텍스트를 개인적인 메모장(private scratchpad)처럼 취급하는 것입니다.

Architecture diagram showing an alert flowing into an on-call agent that reads operational evidence and writes a shared incident record for human approval.

장애 기록(incident record)은 증거, 결정, 소유권(ownership), 그리고 승인(approvals)이 만나는 지점입니다.

진단은 장애 관리 업무의 일부분일 뿐입니다

Lorin Hochstein은 현재 AI SRE 도구들이 진단 작업(diagnostic work) 또는 문제 해결 시도(trying to fix problems)를 위해 사용되고 있다고 말합니다. 즉, 현재의 AI SRE 도구들은 그가 '조정 작업(coordination work)'이라고 정의하는 장애 관리(incident management)와 대조되는, 이른바 '완화 작업(mitigation work)'을 위해 사용되고 있다는 것입니다 (장애 관리는 조정 작업입니다). 이는 저에게도 타당하게 들립니다. 어떤 장애 상황에서든 AI가 학습하고 진단할 수 있는 시스템의 일부분이 존재하기 때문입니다. 하지만 AI가 인간의 업무에 가치를 더하기 위해서는, 그 시스템의 부분이 전체 시스템의 부분 집합(subset)이어야 합니다. 일단 AI가 시스템의 특정 부분에 고정되면, 다른 인간과 마찬가지로 그 관점에 고착될 수 있으며, AI가 시스템에 대해 알지 못하는 부분은 일반적으로 AI가 알고 있는 부분보다 훨씬 더 커질 것입니다.

이것이 바로 에이전트 데모(agent demos)가 과소평가하는 부분입니다. 진단 과정은 데모하기에 깔끔하고 명확합니다. 알람이 울립니다. 온콜 담당자가 텔레메트리(telemetry) 데이터를 읽습니다. 에이전트가 문제의 근본 원인(root cause)에 대해 강력한 직감을 가집니다. 에이전트가 해결을 위한 권장 사항을 제시하고, 모든 것이 결국 잘 풀리며 데모용으로 보기 좋은 깔끔한 흐름을 완성합니다.

도구의 장애 관리 (incident management) 측면에서도, 깔끔하고 멋진 진단 (diagnosis)과는 대조적으로 장애 대응 (incident response)의 지저분한 부분은 다양한 팀 간의 조율입니다 (예: API 팀은 최근 배포가 문제의 원인이라고 주장할 수 있고, 데이터 팀은 시스템 깊숙한 곳에서 문제를 일으키는 타임아웃 (timeout)을 발견할 수 있으며, 플랫폼 팀은 특정 지역의 부하 급증 (load spike)을 보고할 수 있습니다 등). 그러는 동안, 10분 이내에 고객 업데이트를 전달해야 합니다. 누군가는 롤백 (roll back)을 할지, 피처 플래그 (feature flag)를 비활성화할지, 큐 (queue)를 확장할지, 아니면 상황을 계속 지켜볼지를 결정해야 합니다. 또한 누군가는 팀이 왜 더 무서운 옵션을 선택하지 않았는지에 대한 이유를 기록해야 합니다 (결과적으로 그 옵션이 효과가 있었던 것으로 밝혀지더라도 말입니다).

이러한 작업은 부차적인 퀘스트 (side quest)가 아닙니다. 그것이 바로 장애 (incident) 그 자체입니다.

온콜 (on call) 상황에서의 개인적인 메모장 (private scratch pad)은 온콜 담당자가 질문에 답하는 데 도움을 줄 수는 있습니다. 하지만 증거, 결정, 소유권 (ownership), 그리고 승인 사항들이 나머지 팀원들이 실시간으로 읽을 수 있는 곳에 기록되지 않는다면, 그것은 장애 기록 (incident record)으로서의 가치가 없습니다.

이러한 증거와 운영 지식 (operational knowledge)을 위한 데이터 플레인 (data plane)을 구축하려는 OpenTelemetry의 GenAI 작업: GenAI 관측성 (GenAI observability)에 관한 OpenTelemetry 블로그. 모델 호출 (model calls), 도구 호출 (tool invocations), 토큰 수 (token counts) 및 지연 시간 (latency)이 트레이스 (traces), 메트릭 (metrics), 이벤트 (events)와 결합되는 방식입니다. 프롬프트 (prompts)와 도구 인자 (tool arguments)에는 민감한 정보가 포함될 수 있으므로, 콘텐츠 캡처 (content capture)는 기본적으로 꺼져 있다는 점에 유의하십시오. 따라서 이러한 장애 기록은 증거에 기반하되, 비밀을 유출하는 채팅 로그가 되어서는 안 됩니다.

Comparison matrix showing the difference between AI SRE diagnostics and AI incident management coordination work.

진단 (Diagnosis)은 가능한 원인을 설명합니다. 장애 관리 (Incident management)는 대응 팀이 정렬된 상태를 유지하도록 합니다.

공유된 기록은 제어 표면 (control surface)이다

유용한 AI 장애 기록은 단순히 분위기만 더 나은 채팅 로그가 아닙니다. 그것은 구조화된 운영 객체 (structured operational object)입니다.

알림 (alert), 서비스 (service), 심각도 (severity), 영향받은 고객 (customers affected), 배포 시간 (deploy time), 의심되는 영향 범위 (suspected blast area)와 같은 트리거가 기록을 시작합니다. 그 뒤를 이어 추적 데이터 (traces), 로그 (logs), 메트릭 (metrics), 최근 변경 사항 (recent changes), 런북 (runbooks), 소유권 데이터 (ownership data), 관련 장애 (related incidents), 그리고 에이전트 (agent) 자신의 도구 호출 (tool calls)과 같은 증거들이 뒤따릅니다. 그 증거들은 다시 가설 (hypotheses), 기각된 가설 (rejected hypotheses), 신뢰도 (confidence), 공백 (gaps), 결정 (decisions), 승인 (approvals), 소유자 (owners), 현재 상태 (current status), 그리고 후속 작업 (follow-up work)이 됩니다.

이러한 형태가 중요한 이유는 장애 대응자 (incident responders)가 모니터링해야 할 또 다른 스트림을 필요로 하지 않기 때문입니다. 그들에게 필요한 것은 현재의 이론에 합류하고, 떠나고, 인수인계하고, 이의를 제기하는 비용을 줄여주는 공유된 상태 객체 (shared state object)입니다.

새로운 대응자는 장애에 쉽게 합류하여 현재 작업 중인 가설 (working hypothesis)이 무엇인지, 팀이 왜 그 가설을 믿고 있는지, 이미 무엇을 배제했는지, 어떤 조치가 승인을 기다리고 있는지, 그리고 고객 대상 메시지가 이미 발송되었는지 등을 즉시 확인할 수 있어야 합니다. 만약 팀의 Slack 채널을 5분 동안 뒤져야 한다면, 설령 팀이 장애의 근본 원인 (root cause)을 찾아냈더라도 팀 전체가 장애 관리 (incident management)에 실패한 것입니다.

이 지점에서 에이전트 인수인계가 런타임 상태가 됩니다. 한 에이전트에서 다른 에이전트로 장애를 인수인계하는 것은 단순히 작업 항목 (work item)을 넘기는 것이 아닙니다. 그것은 컨텍스트 (context)의 인수인계이며, 누가 조치를 취하고 승인할 수 있는지에 대한 인수인계입니다. 에이전트 A에서 에이전트 B로 장애가 인수인계된다는 것은, 이제 B가 데이터베이스 조사 (database investigation)를 담당하고, B가 고객 커뮤니케이션 (customer communication)을 담당하며, A는 추적 데이터 (traces)를 모니터링하면서 운영 환경을 위한 롤백 노트 (rollback note)를 작성한다는 것을 의미합니다. 다른 사람들이 읽을 수 있도록 누군가는 이 내용을 기록 (record)에 작성해야 합니다.

또한 이 기록은 권한 경계 (permission boundary)를 생성합니다. 쓰기 권한 (write access)은 나중에 부여됩니다.

에이전트에게 처음에 무엇을 허용할 것인가에 대해서는, 증거 검색 (evidence retrieval), 업데이트 작성, 과거 장애 사례 비교 등이 모두 좋은 시작점이 될 수 있습니다. 하지만 프로덕션 변이 (production mutation)의 경우, 롤백 경로 (rollback paths)와 변경 기록 (change records)을 위해 반드시 승인 절차를 거쳐야 합니다. (이는 프로덕션 작업 전 에이전트 배포 작업에 변경 기록이 사용되는 방식과 유사합니다. 이를 통해 팀은 자율성의 장점을 유지하면서도, 예를 들어 권한을 가진 채 '느낌(vibes)'에만 의존하는 상황으로 변질되는 것을 방지할 수 있습니다).

사실상 해당 정책은 런타임 (runtime)에서 거버넌스를 수행합니다. 따라서 이는 AI SRE 도구 호출 (AI SRE tool call) 이전에 이루어져야 합니다. 결과적으로 해당 정책은 팀이 장애를 처리하는 동안 나타나야 합니다. 따라서 장애가 종료된 후에는 복구 작업, 즉 프로덕션 변이 변경 기록 (production mutation change records)에 나타나야 합니다.

기록은 고착화 (fixation)에 맞선다

이는 장애 발생 중 단 한 번의 실수를 저지르는 것과는 근본적으로 다른 유형의 실패입니다. 사람들은 장애 상황에서 언제나 실수를 저지르곤 하며, 이는 현재의 기술로는 해결할 수 없는 문제입니다. 이 유형의 실패는 에이전트가 '높은 확신을 가진 중력의 구덩이 (high-confidence gravity well)'가 될 때 발생합니다. 즉, 에이전트가 장애의 그럴듯한 원인을 찾아내면, 나머지 대응 팀이 그 원인을 중심으로 궤도를 돌게 되고, 이후의 모든 증거가 그 원인이라는 렌즈를 통해 해석됩니다. 또한 에이전트가 가설을 생성하기 위해 사용하는 도구와 데이터 자체가 이미 에이전트가 믿고 있는 그 원인에 의해 형성되어 있기 때문에, 에이전트는 해당 원인을 뒷받침하는 증거를 점점 더 많이 찾아내게 됩니다.

공유된 기록을 통해 기각된 이론을 배제하고, 각 관점(설령 그것이 일시적으로 하나의 이론에만 할당되었더라도)에 대한 지지 증거와 불일치 증거를 보여주도록 강제하는 것은 에이전트의 편향 (bias)을 억제하는 데 도움이 될 것입니다. 누락된 데이터를 나열하고 팀원 간의 현재 논쟁 지점도 함께 명시하십시오. 예를 들어, 하나의 캐시 이론 (cache theory)과 또 다른 배포 이론 (deploy theory)이 각각 서로 다른 대시보드의 데이터에 의존하고 있다면, 두 가지 모두 담당자와 함께 기록하고 각각을 확인하기 위한 다음 단계 (next steps)를 나열하십시오.

이러한 항목들을 검토하는 데는 몇 분밖에 걸리지 않으며, 팀이 현재 일어나고 있다고 믿는 상황의 기본 프레임워크 (framework)에 동의하는지 확인해 줍니다. 일단 기록에 팀이 무엇을 믿고 있는지, 왜 그렇게 믿는지, 지금까지 무엇이 배제되었는지, 그리고 고객에게 전달할 현재 메시지가 무엇인지가 명시되면, 대응자 (responder)는 이미 진행 중인 대화에 참여하여 가치를 더할 수 있는 충분한 정보를 갖게 됩니다.

장애 (incident)가 해결된 후에는, 해당 기록이 조직의 지식 (institutional knowledge)으로서 살아남아야 합니다. PagerDuty의 Scribe 프레임워크가 중요한 이유는 기록 (transcripts)과 결정 사항들이 단순한 회의 부산물이 아니라 재사용 가능한 운영 지식 (operational knowledge)이 되기 때문입니다. 만약 장애를 통해 누락된 런북 (runbook) 단계, 취약한 알림 (alert), 또는 반복되는 조사 과정이 드러났다면, 에이전트 실패가 티켓이 되어야 하는 것과 마찬가지로 추적 데이터 (traces), 회귀 테스트 (regression checks), 그리고 릴리스 증거 (release evidence)를 포함하여 명명된 이슈 (named issue)를 생성하십시오.

장애 대응 에이전트보다 먼저 장애 기록을 구축하라

올바른 첫 번째 행보는 극적인 데모를 보여주는 자율 대응자 (autonomous responder)가 아니라, 구조화된 장애 기록 (incident record)을 만드는 것입니다.

첫 번째 단계는 과거 및 현재 진행 중인 장애에 대한 구조화된 기록을 만드는 것입니다. 명확한 필드 (fields)를 부여하십시오. 에이전트가 이를 안전하게 읽고 내용을 추가할 수 있도록 하십시오. 어떤 증거를 기록할지, 어떤 비밀 정보 (secrets)를 제외할지, 대응자 (responder)의 역할이 어떻게 이동하는지, 그리고 해결 후 후속 작업 (follow-up work)이 어떻게 생성되는지를 정의하십시오.

그다음 에이전트(agent)를 트레이스(traces), 로그(logs), 배포 이력(deploy history), 그리고 과거 장애 기록(past incidents)에 연결하십시오. 에이전트가 확신이 있는 부분과 증거가 부족한 부분(evidence gaps)을 구분하여 첫 번째 업데이트 초안을 작성하게 하십시오. 인간은 이를 편집, 승인 또는 거부합니다. 더 빠른 컨텍스트 수집(context gathering), 더 깔끔한 인수인계(handoffs), 더 나은 장애 후속 작업(post-incident work), 그리고 "왜 롤백(roll back)했지?"라는 의문이 발생하는 순간의 감소를 측정하십시오.

컨설팅 버전은 고통스러울 정도로 실용적입니다. 고객이 AI 장애 관리(AI incident management) 문제를 겪는 이유는 모델이 추론(reasoning)을 할 수 없기 때문이 아닙니다. 고객은 장애 기록(incident-record) 문제, 소유권(ownership) 문제, 트레이스 품질(trace-quality) 문제, 승인 경로(approval-path) 문제, 그리고 후속 작업(follow-up-work) 문제를 겪고 있는 것입니다. 모델은 이러한 격차들 사이에서 작동하려고 시도하기 때문에 그 격차들을 드러내게 됩니다.

여기서는 가장 영리한 AI가 승리하지 않습니다. 상황이 험난하고 세부 사항이 지루해지는 순간에도 풍부한 공유 기록(shared record)을 남기는 AI가 유용한 AI입니다.