AI를 위한 SRE(SRE for AI) — 멀티 에이전트 장애 대응(Multi-Agent Incident Response), 런북(Runbook), 예측 감지(Predictive Detection)

AI SRE는 로그(log), 런북(runbook), 서비스 토폴로지(service topology) 같은 인프라 데이터(infrastructure data)에 근거(grounded)한 LLM을 검색 증강 생성(RAG)으로 활용해 조사(investigation), 문서화(documentation), 조율(coordination) 단계를 자동화합니다. 2026년의 아키텍처 패턴(architecture pattern)은 멀티 에이전트 오케스트레이션(multi-agent orchestration)입니다. 로그, 지표(metric), 런북을 담당하는 전문화된 에이전트(specialized agent)를 슈퍼바이저(supervisor)가 조율합니다. AI는 가설(hypothesis)과 질의(query)를 제안하고, 사람은 판단이 필요한 결정(judgment call)을 승인합니다. Datadog Bits AI와 Azure SRE Agent가 이를 관리형 제품(managed product)으로 제공합니다. 런북도 함께 진화하고 있습니다. NeuBird Hawkeye는 대립적 평가(adversarial evaluation)를 사용해 두 모델이 같은 사건(incident)을 분석하고, 합의(agreement)는 신뢰도(confidence)로, 불일치(disagreement)는 불확실성(uncertainty)으로 취급합니다. 운영 메모리(operational memory)는 팀 구성이 바뀌어도 유지됩니다. 자동 복구(auto-remediation)는 여전히 조심스럽게 다뤄집니다. AI가 제안하고 사람이 승인합니다. 완전 자율 행동(fully autonomous action)은 파드 재시작(restart pod), 특정 배포 롤백(rollback specific deploy)처럼 엄격한 가드레일(tight guardrail)이 있는 좁은 범위에만 머뭅니다. "켜두기만 하면 알아서 된다(set it and forget it)"고 파는 사람은 과장하고 있는 것입니다. 새롭게 떠오르는 영역(emerging frontier)은 장애 발생 전 예측(pre-incident prediction)입니다. MIT 연구는 과거 로그(historical logs)와 GPU 온도, API 오류 패턴(API error pattern)으로 학습한 LLM이 장애(outage)의 89%를 10~15분 일찍 예측했다고 보고합니다. 전망(projection): 2026년 말까지 기업용 LLM의 95%가 자동 페일오버(automated failover)를 갖추게 될 것입니다.

유형: Learn 언어: Python(표준 라이브러리, 장난감 수준의 멀티 에이전트 장애 분류 시뮬레이터(multi-agent incident triage simulator)) 선수 지식: Phase 17 · 13 (관측 가능성(Observability)), Phase 17 · 24 (카오스 엔지니어링(Chaos Engineering)) 예상 시간: 약 60분

학습 목표

• 멀티 에이전트 AI SRE 아키텍처를 그림으로 그릴 수 있습니다. 슈퍼바이저(supervisor) + 전문화된 에이전트(로그, 지표, 런북) + 사람 승인 게이트(human approval gate)로 구성됩니다.
• 자동 복구가 왜 파드 재시작이나 배포 되돌리기(revert deploy)처럼 좁은 범위에 머물고, 서비스 재설계(re-architect service)처럼 넓은 범위로는 가지 않는지 설명할 수 있습니다.
• 대립적 평가 패턴(adversarial evaluation pattern), 즉 NeuBird Hawkeye의 두 모델이 합의하면 신뢰도가 높고 불일치하면 사람에게 에스컬레이션(escalate)한다는 패턴을 말할 수 있습니다.
• MIT의 89% 조기 감지(early-detection) 결과와 함께 운영상의 제약, 즉 작동(actuation) 없는 예측(prediction)은 결국 대시보드(dashboard)일 뿐이라는 점을 인용할 수 있습니다.

문제

당직(on-call) 엔지니어가 새벽 3시에 호출(page)을 받습니다. "체크아웃(checkout)에서 오류율이 높다." 엔지니어는 Datadog, Loki, 런북 세 개, 배포 로그(deploy log)를 차례로 확인합니다. 30분 뒤에야 근본 원인(root cause)이 KV 캐시(KV cache) 급증으로 인한 vLLM의 메모리 부족(OOM)이라는 것을 깨닫습니다. 파드를 재시작하자 오류가 사라집니다.

2026년에는 이 조사의 처음 20분이 자동화 가능합니다. 서비스별 로그 묶기(log grouping), 최근 배포와의 상관관계(correlation), 런북 매칭(runbook match)은 모두 RAG와 도구 사용(tool-use)의 영역입니다. 감독을 받는 에이전트(supervised agent)는 사람이 Datadog을 열기 전에 1차 분류(first-pass triage)를 수행하고 가설을 제시할 수 있습니다.

완전 자율 복구(fully autonomous remediation)는 또 다른 문제입니다. 파드 재시작은 안전합니다. 정책(policy)이 허용하면 GPU 풀(GPU pool)의 규모 조절(scale)도 안전할 수 있습니다. 그러나 서비스 재설계는 절대 그렇지 않습니다. 결국 핵심은 이 좁은 경계선을 정확히 긋는 규율(discipline)입니다.

개념

멀티 에이전트 아키텍처

          Incident
             │
             ▼
        Supervisor
        /    |    \
       ▼     ▼     ▼
  Log agent  Metric agent  Runbook agent
       │     │     │
       └─────┴─────┘
             │
             ▼
        Hypothesis + evidence
             │
             ▼
        Human approval
             │
             ▼
        Action (narrow set)

슈퍼바이저는 사건을 하위 질의(sub-query)로 쪼갭니다. 전문화된 에이전트는 도구 접근권(tool access)을 가지며, 각각 로그 검색(log search), PromQL, 문서 검색(doc retrieval) 같은 도구를 사용합니다. 슈퍼바이저는 결과를 종합(synthesize)해 가설과 근거(evidence)를 사람에게 제시합니다. 사람은 이를 승인하거나 다른 방향으로 돌립니다.

자동 복구의 범위

안전(좁은 범위): 파드 재시작, 특정 배포 되돌리기, 사전 승인된 한도(pre-approved bound) 안에서의 풀 규모 조절, 사전 승인된 기능 플래그(feature flag) 활성화.

위험(넓은 범위): 서비스 토폴로지 변경, 리소스 한도(resource limit) 수정, 새 코드 배포, IAM 변경, 데이터베이스 변경.

"켜두기만 하면 알아서 된다"고 파는 사람은 과장하고 있습니다. AI SRE가 성숙할수록 안전한 행동의 집합은 커지지만, 그 경계선(boundary) 자체는 분명하게 존재합니다.

대립적 평가(NeuBird Hawkeye)

두 모델이 같은 사건을 독립적으로 분석합니다. 근본 원인에 대해 두 모델이 합의하면 신뢰도가 높다고 봅니다. 의견이 갈리면 두 가설을 모두 보여주면서 사람에게 에스컬레이션합니다. 단순하지만, 환각(hallucinated)된 근본 원인을 걸러내는 효과적인 패턴입니다.

운영 메모리

팀 이직(team turnover)은 전통적 SRE의 조용한 사망 원인입니다. 부족 지식(tribal knowledge)이 사람과 함께 떠나기 때문입니다. AI SRE는 런북과 사후 분석 문서(post-mortem)를 벡터 데이터베이스(vector DB)에 저장합니다. 에이전트는 새 사건이 생길 때마다 이를 다시 가져옵니다(retrieve). 새 엔지니어가 합류해도 AI는 이미 전체 이력(full history)을 갖고 있습니다.

장애 발생 전 예측

MIT의 2025년 연구는 과거 로그, GPU 온도, API 오류 패턴으로 학습한 LLM이 테스트 세트(test set)에서 장애의 89%를 발생 10~15분 전에 예측했다고 보고했습니다.

현실 점검(reality check): 작동이 따라오지 않는 예측은 대시보드일 뿐입니다. 운영상의 질문은 "예측이 나왔을 때 실제로 무엇을 할 것인가?"입니다. 사전 비우기(pre-emptive drain)? 호출기(pager) 발송? 자동 규모 조절(auto-scale)? 답은 정책에 따라 달라집니다(policy-specific).

2026년의 제품들

• Datadog Bits AI — Datadog 내부에서 동작하는 관리형 SRE 코파일럿(copilot)입니다.
• Azure SRE Agent — Azure에 네이티브하게 통합됩니다.
• NeuBird Hawkeye — 대립적 평가 + 운영 메모리 패턴을 갖춘 제품입니다.
• PagerDuty AIOps — 분류(triage)와 중복 제거(deduplication)를 담당합니다.
• Incident.io Autopilot — 사건 지휘(incident commander)와 조율을 맡습니다.

코드로서의 런북(Runbooks as code)

런북은 Confluence 페이지에서, 증상(symptom) / 가설(hypothesis) / 검증(verify) / 행동(act)이라는 구조화된 섹션을 가진 버전 관리되는 마크다운(versioned markdown)으로 진화합니다. 구조화된 런북은 더 나은 RAG 검색(retrieval)으로 이어집니다. AI-SRE 도입(rollout)은 비구조 런북(unstructured runbook)을 구조화된 형태로 바꾸는 일부터 시작해야 합니다.

기억해야 할 숫자

• MIT 조기 감지: 장애의 89%, 10~15분의 선행 시간(lead time).
• 멀티 에이전트 분류: 슈퍼바이저 + (로그, 지표, 런북) 에이전트 + 사람.
• 안전한 자동 복구 집합: 파드 재시작, 배포 되돌리기, 정해진 범위 안에서의 규모 조절.
• 대립적 평가: 두 모델이 독립적으로 분석하고, 합의 = 신뢰도.

사용해보기

code/main.py는 멀티 에이전트 분류(triage)를 시뮬레이션합니다. 로그 에이전트는 오류를 찾고, 지표 에이전트는 CPU 급증(spike)을 찾고, 런북 에이전트는 알려진 이슈(known issue)에 매칭합니다. 슈퍼바이저는 가설들을 순위(rank)로 정리합니다.

산출물 만들기

이 강의는 outputs/skill-ai-sre-plan.md를 만듭니다. 현재 당직 체계(current on-call), 사건 발생량(incident volume), 팀의 성숙도(team maturity)가 주어지면 AI SRE 도입 계획을 설계합니다.

연습문제

1. 쉬움: code/main.py를 실행해 봅니다. 로그 에이전트와 지표 에이전트의 의견이 어긋나면 어떻게 됩니까? 슈퍼바이저는 이를 어떻게 해결합니까?
2. 중간: 자신의 서비스를 위한 "안전한(safe)" 자동 복구 행동 세 가지를 정의합니다. 각각이 안전한 이유를 정당화합니다.
3. 중간: 구조화된 런북 템플릿을 작성합니다. 섹션 구성, 필수 필드(required field), 검증 명령(verification command)을 포함합니다.
4. 어려움: 예측 감지가 12분의 선행 시간으로 발화(fire)합니다. 정책은 무엇입니까? 호출, 사전 비우기, 또는 둘 다입니까?
5. 어려움: 3인 팀이 2026년에 AI SRE를 도입해야 하는지, 아니면 기다려야 하는지 논합니다. 성숙도, 사건 발생량, 위험을 함께 고려합니다.

핵심 용어

더 읽을거리

• incident.io — AI SRE Complete Guide 2026
• InfoQ — Human-Centred AI for SRE
• DZone — AI in SRE 2026
• Datadog Bits AI
• NeuBird Hawkeye
• awesome-ai-sre