7. 혼자서는 안 된다 — 멀티 에이전트와 자동 포스트모템

프롬프트가 점점 길어지고 있다.

감시도 하고, 분석도 하고, 실행도 하고, 보고도 하는 Agent를 하나의 프롬프트로 만들면, 프롬프트 자체가 3,000토큰을 넘긴다. 경로 B에서 32K 컨텍스트 모델을 쓰면 로그 넣을 공간이 부족해진다. 역할이 모호해지면서 응답 품질도 떨어진다.

실제 SRE 팀도 한 사람이 모든 걸 하지 않는다. 모니터링 담당, 장애 분석 담당, 실행 담당이 나뉘어 있다. AI도 마찬가지다.

4-Agent 아키텍처

역할별로 Agent를 분리하면 이렇게 된다.

                    ┌──────────────┐
                    │ 오케스트레이터 │
                    │  (상태 관리)  │
                    └──────┬───────┘
                           │
          ┌────────────────┼────────────────┐
          │                │                │
   ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
   │  감시 Agent  │ │  분석 Agent  │ │  보고 Agent  │
   │             │ │             │ │             │
   │ 로그 분석    │ │ RCA         │ │ 포스트모템    │
   │ 이상 판정    │ │ 알림 상관관계│ │ 타임라인     │
   └──────┬──────┘ └──────┬──────┘ └─────────────┘
          │                │
          │         ┌──────▼──────┐
          └────────►│  실행 Agent  │
                    │ Runbook 실행 │
                    │ 안전장치     │
                    └─────────────┘

각 Agent의 프롬프트가 짧아진다. 감시 Agent는 "이 로그와 메트릭 추세를 보고 정상/주의/이상을 판정해라"만 하면 된다. 분석 Agent는 5편의 v5 프롬프트로 원인 분석에 집중한다. 역할이 명확하니 응답 품질이 올라간다.

Agent 간 컨텍스트 공유

여기서 바로 부딪히는 문제가 있다. Agent마다 별도 LLM 호출이니까, 세션을 공유할 수 없다. 감시 Agent가 "db-01이 원인 같다"고 판정한 걸, 분석 Agent가 알 방법이 없는 거다.

그래서 공유 컨텍스트 문서를 둔다. 인시던트가 열리면 JSON 문서 하나를 만들고, 각 Agent가 자기 결과를 거기에 쓴다. 다음 Agent는 이 문서를 프롬프트에 넣어서 앞 단계의 판단을 이어받는다.

┌──────────────────────────────────────┐
│     공유 컨텍스트 (인시던트별)         │
│                                      │
│  incident_id: INC-2025-0305-001     │
│                                      │
│  [감시 결과] 판정: 이상              │
│  근거: 에러율 15%, 응답 5초          │
│  관련 로그: (핵심 20줄)              │
│                                      │
│  [분석 결과] 추정 원인: DB 커넥션 고갈│
│  신뢰도: 높음, 조치 필요: true       │
│                                      │
│  [실행 결과] idle 커넥션 정리 완료    │
│  디스크: 88%→72%                     │
└──────────────────────────────────────┘

저장소는 Redis 하나면 충분하다. 인시던트 ID를 키로, JSON으로 저장. 인시던트가 종료되면 포스트모템용으로 벡터 DB에 옮기고, Redis에서는 TTL로 정리한다.

감시 Agent — 매 호출이 독립적인데 추세를 어떻게 잡나

감시 Agent는 다른 Agent와 성격이 다르다. 분석/실행/보고는 장애가 발생했을 때만 동작하지만, 감시는 장애가 없을 때도 계속 돌아가야 한다.

매번 새 LLM 호출이면, 이전 판정을 기억 못 한다. "10분 전부터 서서히 느려지고 있다"는 추세를 감시 Agent 단독으로는 잡을 수 없다.

4편에서 설계한 구조가 여기서 그대로 적용된다. 추세 분석은 Prometheus가 하고, 감시 Agent에게는 메트릭 추세 요약 + 로그를 함께 넘긴다. LLM은 "이 추세와 이 로그가 결합됐을 때 뭘 의미하는가"만 판정하면 된다. 매 호출이 독립적이어도, Prometheus가 추세를 넘겨주니까 문제없다.

감시 Agent 앞단에 상태 머신을 두면 더 안정적이다. "주의"가 연속 3회면 "이상"으로 승격하고 인시던트를 여는 식이다. 이건 LLM 없이 코드로 처리한다.

전체 흐름

정리하면 이렇다.

[감시 단계 — 상시]
  Prometheus 추세 + 로그 → 감시 Agent (매 호출 독립)
       │ 판정: 정상/주의/이상
       ▼
  상태 머신 (Python, 주의 3연속 → 이상 승격)
       │
  이상 감지 → 인시던트 열기 → 공유 컨텍스트 생성
 
[대응 단계 — 인시던트 단위]
  분석 Agent (공유 컨텍스트 읽기 → RCA → 결과 쓰기)
       ▼
  실행 Agent (공유 컨텍스트 읽기 → Runbook → 결과 쓰기)
       ▼
  보고 Agent (공유 컨텍스트 전체 → 포스트모템)
       ▼
  인시던트 닫기 → 벡터 DB 저장 (RAG용)

에스컬레이션

모든 걸 AI가 해결할 수는 없다. 분석 Agent가 원인 불명이면 사람에게 넘긴다. 실행 Agent가 High 위험 작업이면 승인을 요청한다. 어느 Agent든 3회 연속 실패하면 사람에게 에스컬레이션한다.

"모르겠다"고 솔직하게 말하는 AI가 "아무 답이나 내놓는" AI보다 낫다. 5편에서 다룬 환각 방지와 같은 맥락이다.

경로 A vs B

경로 A(Claude)에서는 하나의 Claude가 시스템 프롬프트를 교체하면서 4개 역할을 순차 수행할 수 있다. 시스템이 단순하다.

경로 B에서는 역할별로 다른 모델을 쓸 수 있다. 감시는 가벼운 모델, 분석은 무거운 모델. 유연하지만 인프라 관리가 복잡해진다.

Microsoft의 멀티 에이전트 사례

Microsoft가 2025년 12월에 공개한 구조가 이 방향이다.

Azure SRE Agent가 PagerDuty SRE Agent, NeuBird Hawkeye 등 외부 AI Agent와 협업한다. PagerDuty Agent가 과거 장애 패턴과 Runbook 지식을 제공하면, Azure SRE Agent가 Azure 진단 데이터를 결합해서 분석한다. 각 Agent가 자기 전문 영역의 데이터를 가지고 있고, 필요할 때 합치는 구조다. 이 시리즈에서 설계하는 4-Agent 아키텍처와 같은 패턴이다.

자동 포스트모템

장애가 해결되면 끝이 아니다. 포스트모템을 써야 한다.

솔직히 포스트모템은 SRE 업무 중에서 가장 밀리는 작업이다. 장애 대응은 아드레날린이 나와서라도 하는데, 끝나고 나면 피곤하다. 빈 페이지를 열면 "뭐부터 쓰지"가 된다. 타임라인을 기억에 의존해서 쓰면 부정확하고, 3일 지나면 디테일이 날아간다. 결국 대충 쓰거나 안 쓴다. 재발 방지 액션 아이템은 적어만 놓고 실행이 안 된다.

보고 Agent가 해결하는 건 이 중에서 초안 작성이다. 새로운 분석을 하는 게 아니라, 이미 끝난 장애 대응의 기록을 정리하는 거다. 공유 컨텍스트에 감시 판정, 분석 결과, 실행 이력이 전부 남아있으니까.

가장 가치 있는 건 타임라인 자동 추출이다. 새벽 3시에 서버 고치느라 바쁜데 "14

보고 Agent의 프롬프트 핵심은 "분석해라"가 아니라 **"정리해라"**다. 그리고 5편에서 다뤘던 환각 방지 원칙이 여기서도 적용된다. "타임라인은 제공된 타임스탬프에서만 추출해라. 추측하지 마라." 포스트모템에 잘못된 기록이 남으면, RAG를 통해 다음 장애 분석에 오류가 전파되니까.

자동 생성된 초안은 이런 모양이 된다.

## 장애 보고서 — api-service OOM (2025-02-27)
 
### 요약
14:03 api-service OOM 종료. 약 3분간 API 응답 불가.
 
### 타임라인
12:00 v2.3.2 배포
13:30 메모리 75% (감시 Agent: 주의)
14:00 메모리 92% (감시 Agent: 이상 → 인시던트 열림)
14:03 OOM 발생 (분석 Agent: BatchProcessor 메모리 릭 추정)
14:05 서비스 재시작 (실행 Agent)
14:06 정상 복구 확인
 
### 근본 원인
v2.3.2의 BatchProcessor 메모리 릭. 배포 후 메모리 선형 증가.
[신뢰도: 높음 — 과거 유사 사례 패턴 일치]
 
### 재발 방지
1. [개발팀] BatchProcessor 스트리밍 처리 수정 — 1주 이내
2. [SRE] 배포 후 메모리 추이 자동 모니터링 — 3일 이내

완벽하진 않다. 영향 사용자 수는 빠져있을 수 있고, 담당자 이름은 비어있다. 하지만 타임라인과 원인 분석의 뼈대가 잡혀있다. 엔지니어는 빈 곳을 채우고 부정확한 부분만 고치면 된다.

액션 아이템도 중요하다. "다음에 조심하자" 같은 추상적인 항목이 아니라, "[담당팀] [구체적 조치] [기한]" 형태로 뽑히면 그대로 Jira 티켓으로 만들 수 있다. 포스트모템을 쓰고 잊는 패턴을 끊는 거다.

지식 축적 — 선순환 구조

완성된 포스트모템은 벡터 DB에 저장한다. 3편에서 다뤘던 RAG 파이프라인의 "입력"이 만들어지는 시점이 여기다.

포스트모템만 넣는 게 아니다. 6편에서 다뤘던 Runbook도 넣고, 서비스 간 의존관계 같은 아키텍처 문서도 넣는다. 알림이 오면 RAG로 관련 Runbook을 찾아서 실행 Agent에게 넘기고, 분석 Agent는 아키텍처 문서를 참조해서 "이 서비스가 저 서비스에 의존한다"는 맥락을 쓸 수 있다.

한 가지 신경 써야 할 건 중복이다. 같은 유형의 OOM이 세 번 나면 비슷한 포스트모템이 세 개 쌓인다. 유사도가 높은 문서는 병합하거나 최신 것만 남기는 정책이 있어야 한다. Runbook은 Confluence가 바뀔 때 주기적으로 동기화하면 된다.

이 루프가 돌면서 시스템이 점점 똑똑해진다. 장애 → 분석 → 조치 → 포스트모템 → 벡터 DB → 다음 장애에서 RAG로 참조. 1편에서 소개한 Google의 "선순환 구조"가 이거다.

다음 편은 마지막이다. 지금까지 설계한 시스템을 실제로 도입할 때의 현실 — 보안, 비용, 조직 설득 — 과 SRE 엔지니어의 역할 변화를 다룬다.