2021년 4월 23일, Fastly CDN 설정 변경으로 인해 영국 정부 웹사이트, New York Times, Reddit 및 수백 개의 다른 주요 인터넷 서비스가 약 1시간 동안 중단되는 글로벌 장애가 발생했습니다. 장애를 유발한 사건은 설정 푸시(configuration push)였습니다. 전파 메커니즘은 자동화되어 있었습니다. 설정이 푸시된 시점과 글로벌 영향이 가시화된 시점 사이의 시간은 1분 미만이었습니다. 인간 운영자가 원인을 파악하고 롤백(rollback)을 시작하는 데 필요한 시간은 그보다 약 49분 더 길었습니다.

Fastly 사건은 기본적으로 자동화 실패에 관한 이야기가 아닙니다. 이는 자동화된 전파와 인간의 대응 사이의 속도 비대칭(speed asymmetry)에 관한 이야기이며, 인간의 결정과 그 생산적 결과 사이의 자동화 계층이 이를 관리하기 위해 설계된 책임 계층(accountability layer)보다 더 빠르게 움직일 때 어떤 일이 발생하는지에 관한 이야기입니다.

이러한 비대칭성은 AI 지원 SRE의 결정적인 운영 과제입니다. 장애 탐지, 근본 원인 가설 생성, 심지어 복구(remediation)를 자동화하는 능력은 이제 5년 전에는 불가능했던 비용과 지연 시간(latency)으로 접근 가능해졌습니다. 운영 리스크는 이러한 능력이 과소 사용되는 것이 아닙니다. 리스크는 엄격한 에스컬레이션 정책(escalation policy) 없이 배포되는 것입니다. 즉, 자동화된 실행이 정확히 어디에서 끝나고 인간의 판단이 어디에서 시작되는지, 어떤 조건에서 경계가 이동하는지, 그리고 해당 결정이 내려질 당시 현장에 없었을 수도 있는 운영자를 대신하여 AI가 취하는 모든 행동에 대해 어떻게 책임을 보존할지를 정의하는 공식적인 프레임워크가 없는 것이 리스크입니다.

Human-in-the-Loop 스펙트럼

AI 지원 SRE 운영은 자율성 스펙트럼(autonomy spectrum)의 단일 지점에 존재하지 않습니다. 운영은 일정한 범위에 걸쳐 존재하며, 그 범위 내에서의 적절한 위치는 AI 시스템이 얼마나 정교한가가 아니라 신뢰도(confidence), 폭발 반경(blast radius), 참신성(novelty), 그리고 규제 맥락(regulatory context)의 함수입니다.

자동화 자율성 스펙트럼 (THE AUTOMATION AUTONOMY SPECTRUM)
────────────────────────────────────────────────────────────────────────────

...

핵심적인 제약 사항 — 즉, 어떤 조치도 영구적으로 레벨 4에 머물러서는 안 된다는 점 — 은 보수주의 때문이 아닙니다. 이는 특정 실패 모드(failure mode)에 대한 엔지니어링적 대응입니다. 즉, 배포 시점에는 올바르게 교정(calibrated)되었으나 시스템이 진화함에 따라 조용히 교정 범위를 벗어난(drifted out of calibration) 자동화에 대응하는 것입니다. 처음 배포되었을 때는 안전했던 OOM(Out of Memory) 재시작 자동화가, 근본 원인이 메모리 누수(memory leak)에서 동일한 증상을 유발하는 데이터 손상(data corruption) 이벤트로 변하는 순간 안전하지 않게 됩니다. 재자격 검토(re-qualification review)는 이러한 드리프트(drift)가 장애(incident)를 일으키기 전에 이를 포착하는 메커니즘입니다.

네 가지 에스컬레이션 트리거 (The Four Escalation Triggers)

모든 에스컬레이션 정책은 네 가지 기본 트리거(primitive triggers)로 구축됩니다. 각 트리거는 자동화 수준이 더 적은 개입이 아닌, 더 많은 인간의 개입을 향해 상향 조정되어야 하는 조건을 정의합니다.

트리거 1 — 신뢰도 임계값 위반 (Confidence Threshold Breach)

AI 시스템의 진단 또는 권장 조치에 대한 신뢰도(confidence)가 정의된 임계값 아래로 떨어졌을 때입니다. LLM 기반 운영(HolmesGPT, LiteLLM Proxy 라우팅)의 맥락에서 신뢰도는 모델이 보고하는 토큰 확률 분포(token probability distributions)와 권장 출력값에 적용되는 도메인 특화 휴리스틱(domain-specific heuristics)의 조합으로 표현됩니다.

신뢰도가 낮은 진단은 AI가 그럴듯한 패턴 매칭을 식별했으나, 인간의 검토 없이 조치를 권장하기에는 충분한 뒷받침 신호(corroborating signal)가 부족함을 의미합니다. 낮은 신뢰도의 진단에 기반하여 조치를 실행하는 것은 모니터링 대시보드의 단일 데이터 포인트에 근거하여 행동하는 것과 운영상 동일합니다. 이는 가끔은 맞을 수 있지만, 정책으로서 실행하기에는 확실히 위험합니다.

트리거 2 — 폭발 반경 임계값 (Blast Radius Threshold)

제안된 작업이 정책에서 허용하는 자율 실행 범위를 초과하는 인프라에 영향을 미치는 경우입니다. 폭발 반경 (Blast Radius)은 세 가지 차원에서 평가됩니다: 서비스 수 (얼마나 많은 서비스가 영향을 받는지), 트래픽 비율 (영향을 받는 인프라가 사용자 요청의 몇 퍼센트를 처리하는지), 그리고 가역성 (단일 명령으로 5분 이내에 작업을 되돌릴 수 있는지)입니다.

높은 폭발 반경이 자동화의 결격 사유는 아닙니다. 이는 신뢰도 점수 (Confidence Score)와 관계없이 자동화 수준을 최소 레벨 2 (감독형, Supervised)로 전환해야 하는 조건입니다.

트리거 3 — 신규성 탐지 (Novelty Detection)

실패 패턴이 AI 시스템의 학습 코퍼스 (Training Corpus) 또는 과거 장애 데이터베이스의 어떤 패턴과도 일치하지 않는 경우입니다. 신규성은 자율 실행에 있어 가장 위험한 조건인데, 그 이유는 AI의 패턴 매칭 (Pattern-matching) 능력이 가장 낮은 가치를 제공하는 지점이자, 확신에 찬 듯 들리지만 잘못된 권장 사항이 가장 높은 운영 비용을 초래하는 지점이기 때문입니다.

신규성 탐지는 제대로 구현하기 가장 어려운 트리거입니다. AI 시스템이 스스로의 지식 경계를 정확하게 평가해야 하기 때문입니다. "이 패턴을 본 적이 있으며 확신한다"와 "표면적으로 유사한 패턴을 본 적이 있어 추론하고 있다"를 신뢰성 있게 구분하지 못하는 시스템은 레벨 3 또는 레벨 4에서 작동해서는 안 됩니다.

트리거 4 — 규제 경계 (Regulatory Boundary)

제안된 작업이 규제 대상 자산에 접촉하거나, 문서화된 변경 기록을 요구하거나, NERC CIP, PCI-DSS, HIPAA 또는 그에 상응하는 의무가 적용되는 시스템에 영향을 미치거나, 컴플라이언스 (Compliance) 이벤트를 생성하는 경우입니다. 규제 환경에서는 신뢰도 점수나 폭발 반경에 관계없이 어떠한 자동화된 작업도 변경 관리 거버넌스 프레임워크 (Change Management Governance Framework)를 우회할 수 없습니다.

이 트리거는 절대적입니다. 신뢰도 임계값 (Confidence Threshold) 예외는 존재하지 않습니다. 99%의 신뢰도로 운영 환경의 문제를 정확히 진단하고, 규제 대상 자산 (Regulated Asset)에 대한 문서화되지 않은 변경을 구성하는 복구 조치를 제안하는 AI 시스템은, 해당 조치가 서비스 복구 속도를 더 높일 수 있더라도 반드시 레벨 2 (Level 2)로 에스컬레이션하고 변경 기록 (Change Record)을 생성해야 합니다.

에스컬레이션 정책 문서 설계 (Designing the Escalation Policy Document)

에스컬레이션 정책은 설정 파일 (Configuration File)이 아니라 운영 거버넌스 문서입니다. 이 문서는 버전 관리 (Version-controlled)되어야 하며, SRE 리더십 및 컴플라이언스 (Compliance) 부서의 검토와 승인을 거쳐야 하고, 모든 AI 지원 자동화의 런타임 설정 (Runtime Configuration)에서 참조되어야 합니다. 이 정책의 권위는 이를 참조하는 AI 시스템이 아니라, 인간의 검토로부터 나옵니다.

ESCALATION POLICY: AI-ASSISTED INCIDENT RESPONSE
────────────────────────────────────────────────────────────────────────────
Service:       production-platform (all services)
...

HolmesGPT 에스컬레이션 아키텍처 (HolmesGPT Escalation Architecture)

에스컬레이션 정책 문서가 거버넌스 규칙을 정의한다면, 에스컬레이션 아키텍처는 AI 지원 운영 스택 내에서 해당 규칙을 런타임 로직 (Runtime Logic)으로 구현합니다. 여기에 표시된 아키텍처는 규제 대상 온프레미스 (On-premises) 환경에서의 HolmesGPT + LiteLLM Proxy + Ollama 배포 패턴에 특화된 것입니다.

# HolmesGPT Escalation Policy ConfigMap
# 각 작업별 자율성 수준을 결정하기 위해 런타임 시 HolmesGPT에서 소비됨
# git에서 버전 관리됨; Argo CD 동기화를 통해서만 업데이트됨 (변경 기록 강제 적용)
...

에스컬레이션 품질을 위한 모델 라우팅 (Model Routing for Escalation Quality)

LiteLLM Proxy의 모델 라우팅 (Model Routing) 설정은 에스컬레이션 아키텍처의 핵심 구성 요소입니다. 적절한 신뢰도 계층 (Confidence Tier)에서 적절한 모델로 라우팅하는 것은 성능 최적화가 아니라, 안전 메커니즘 (Safety Mechanism)입니다.

LiteLLM Proxy — 에스컬레이션 티어 (Escalation Tiers)를 위한 모델 라우팅 (Model Routing)

낮은 영향 범위 (Low Blast Radius) / 일상적인 패턴을 위한 더 작은 로컬 모델

높은 영향 범위 (High Blast Radius) / 새로운 패턴을 위한 더 큰 컨텍스트 윈도우 (Context Window)를 가진 더 큰 모델

...

권장 품질 피드백 루프 (The Recommendation Quality Feedback Loop)

AI 지원 권장 사항 (AI-assisted recommendations)의 운영 리스크는 정적이지 않습니다. 시스템이 변화하고 모델의 학습 분포 (Training Distribution)가 현재의 운영 현실과 괴리됨에 따라 리스크는 진화합니다. AI 권장 품질 피드백 루프는 이러한 드리프트 (Drift)가 해로운 자율적 행동을 유발하기 전에 이를 가시화하는 메커니즘입니다.

# Prometheus Recording Rules — AI 권장 품질 추적
# HolmesGPT의 권장 사항이 운영적으로 가치가 있는지 측정
# 높은 오버라이드 (Override) 비율 또는 낮은 실행 (Action) 비율 = 권장 품질 저하
...

책임 체인 원칙 (The Accountability Chain Principle) 및 NIST AI RMF 정렬

책임 체인 원칙 — 즉, 모든 AI 지원 행동은 직접적인 승인이든, 인간이 작성하고 승인한 정책이든 간에 반드시 인간의 결정으로 거슬러 올라갈 수 있어야 한다는 원칙 — 은 NIST AI 리스크 관리 프레임워크 (NIST AI Risk Management Framework)의 GOVERN (거버넌스) 기능에 대한 운영적 구현입니다.

NIST AI RMF는 AI 리스크 관리를 위한 네 가지 핵심 기능인 GOVERN (정책, 책임), MAP (리스크 식별), MEASURE (리스크 정량화), 그리고 MANAGE (리스크 대응)를 설정합니다. 각 f