런북 & 운영 문서
Diagnose/Recommend/Act 모드로 진단·승인·조치를 분리하고, 조건-행동-확인-승인을 수치화하며 MCP Tool과 에스컬레이션까지 연결하는 에이전트 운용형 런북 설계.
핵심 요약
- 좋은 에이전틱 런북은 진단은 자동화하되, 위험한 조치는 승인 경계 안에서만 실행하게 만듭니다.
- 런북을 Diagnose(읽기 전용)·Recommend(제안)·Act(사전 승인된 저위험 실행) 세 모드로 나눕니다.
- 모든 조치를 조건-행동-확인-롤백-에스컬레이션 형식으로 쓰고 "응답이 느리면" 같은 표현을 p95>3s처럼 수치화합니다.
- 데이터 삭제·권한 변경·결제·배포/롤백·고객 영향 작업은 별도 승인 경계를 둡니다.
- MCP Tool 연결 시 annotation은 힌트일 뿐이며 서버 권한·scope·approval policy·audit으로 강제하고 frontmatter에
last_tested·owner를 둡니다.
런북(Runbook)은 장애가 터졌을 때 누가 읽어도 같은 기준으로 판단하게 만드는 운영 문서입니다. AI 에이전트가 운영을 거드는 시대에는 런북을 더 단단하게 구조화해야 합니다. 그렇다고 모든 조치를 자동화해도 된다는 뜻은 아닙니다.
좋은 에이전틱 런북은 진단은 자동화하고, 위험한 조치는 승인 경계 안에서 실행하게 만듭니다.
왜 런북이 바뀌어야 하는가
기존 런북에는 "상황을 보고 판단", "필요하면 롤백", "심각하면 연락"처럼 판단을 사람에게 떠넘기는 표현이 많습니다. 이런 표현은 사람마다 다르게 읽고, AI 에이전트는 더 쉽게 오판합니다.
핵심 변화
런북은 장애 대응 설명서를 넘어 에이전트가 읽는 운영 계약으로 바뀝니다. 조건, 관측값, 허용된 조치, 승인 필요 여부, 성공 기준을 모두 명시해야 합니다.
런북의 세 가지 모드
| 모드 | 에이전트 권한 | 예시 | 원칙 |
|---|---|---|---|
| Diagnose | 읽기 전용 | 로그 조회, metric 확인, 상태 요약 | 기본값 |
| Recommend | 조치 제안 | 롤백 후보, scale-up 제안 | 사람 승인 전 실행 금지 |
| Act | 제한적 실행 | 캐시 purge, feature flag off | 사전 승인된 저위험 조치만 |
위험한 조치를 런북에 적었다고 자동 실행해도 된다는 뜻은 아닙니다. 특히 데이터 삭제, 권한 변경, 결제/정산, 배포/롤백, 외부 고객에 영향을 주는 작업은 승인 경계를 따로 둡니다.
AI-readable 런북 작성 원칙
1. 조건-행동-확인-승인
모든 조치를 다음 형식으로 작성합니다.
### 조치: API worker 재시작
- **조건**: p95 latency > 3s 상태가 5분 이상 지속되고, error rate < 1%
- **권한 모드**: Act allowed
- **행동**: `kubectl rollout restart deployment/api-worker`
- **확인**: 5분 안에 p95 latency < 1s
- **롤백/복구**: rollout 실패 시 `kubectl rollout undo deployment/api-worker`
- **에스컬레이션**: 10분 안에 복구 실패 시 L1 호출2. 수치화된 판단 기준
| 모호한 표현 | 수치화된 표현 |
|---|---|
| 응답이 느리면 | p95 응답 시간 > 3초, 5분 rolling window |
| 에러가 많으면 | 5xx error rate > 5%, 10분 지속 |
| 오래 지속되면 | 15분 이상 지속 |
| 심각한 장애 | Sev1: 전체 사용자 주요 기능 불가 |
3. 관측값과 명령의 분리
## 진단
| 순서 | 관측값 | 명령/도구 | 정상 기준 |
|---|---|---|---|
| 1 | API error rate | Grafana `api-5xx-rate` | < 1% |
| 2 | 최근 배포 | `kubectl rollout history deployment/api` | 30분 내 배포 없음 |
| 3 | DB connection | `SELECT count(*) FROM pg_stat_activity` | < max의 80% |진단 단계는 되도록 읽기 전용으로 제한합니다. 쓰기 작업은 조치 섹션에서만 다룹니다.
4. 에스컬레이션 조건 명시
## 에스컬레이션 매트릭스
| 레벨 | 조건 | 대상 | 채널 | SLA |
|---|---|---|---|---|
| L1 | 자동/저위험 조치 후 10분 미해결 | 온콜 엔지니어 | Slack #oncall | 10분 |
| L2 | L1 후 30분 미해결 또는 고객 영향 확대 | 팀 리드 | 전화 + Slack | 15분 |
| L3 | Sev1 또는 데이터 손상 가능성 | Incident Commander | War room | 즉시 |MCP Tool과 런북 연결
런북을 MCP Tool과 연결할 때는 Tool의 위험도를 문서화합니다.
| Tool | 용도 | 권한 모드 | annotation 힌트 | 승인 |
|---|---|---|---|---|
get_metrics | metric 조회 | Diagnose | readOnlyHint: true | 자동 가능 |
list_deployments | 배포 이력 조회 | Diagnose | readOnlyHint: true | 자동 가능 |
purge_cache | 캐시 삭제 | Act | destructiveHint: false, idempotentHint: true | 정책에 따라 |
rollback_release | 릴리스 롤백 | Act | destructiveHint: true | 사람 승인 |
rotate_secret | secret 교체 | Act | destructiveHint: true, openWorldHint: true | 별도 change 승인 |
annotation은 힌트
MCP Tool annotation은 클라이언트 판단을 돕는 힌트일 뿐입니다. 보안 정책은 서버 권한, scope, approval policy, 감사 로그로 강제합니다.
런북 Skill 패턴
반복적인 장애 대응 절차는 Skill로 분리할 수 있습니다.
.agents/skills/incident-triage/
├── SKILL.md
├── references/
│ ├── severity-policy.md
│ └── escalation-matrix.md
└── scripts/
└── collect-diagnostics.shSKILL.md에는 조치 실행보다 진단과 보고 형식을 먼저 둡니다.
---
name: incident-triage
description: 장애 알림을 분석하고, 관련 런북을 찾아 진단 요약과 권장 조치를 보고할 때 사용한다.
---
1. 관련 런북을 찾는다.
2. 읽기 전용 진단만 수행한다.
3. 조치가 필요한 경우 권한 모드와 승인 필요 여부를 표시한다.
4. 사용자 승인 없이 destructive action을 실행하지 않는다.
5. 출력은 "관측값 / 판단 / 권장 조치 / 승인 필요 / 에스컬레이션" 순서로 작성한다.런북 템플릿
---
title: "런북: {서비스명} - {장애 유형}"
severity: "{sev1|sev2|sev3}"
services: ["{서비스1}", "{서비스2}"]
owner: "{팀/담당자}"
last_tested: "{YYYY-MM-DD}"
allowed_modes: ["diagnose", "recommend"]
---
# 런북: {서비스명} - {장애 유형}
## 트리거
- 알림: {모니터링 알림 이름/ID}
- 조건: {수치 기반 조건}
## 영향 범위
- 영향 서비스:
- 영향 사용자:
- 비즈니스 영향:
## 진단
| 순서 | 관측값 | 명령/도구 | 정상 기준 |
|---|---|---|---|
| 1 | {metric/log} | `{read-only command}` | {기준} |
## 조치
### 조치 1: {조치 이름}
- **조건**:
- **권한 모드**: Diagnose / Recommend / Act
- **행동**:
- **확인**:
- **롤백/복구**:
- **승인 필요 여부**:
## 에스컬레이션
| 조건 | 대상 | 채널 | SLA |
|---|---|---|---|
| {조건} | {담당자/팀} | {Slack/전화} | {응답 시간} |
## 사후 처리
- [ ] 포스트모템 작성
- [ ] 근본 원인 분석
- [ ] 재발 방지 조치 등록
- [ ] 런북 업데이트AI가 실패하는 패턴
| 실수 | AI가 실패하는 이유 | 수정 방법 |
|---|---|---|
| "상황을 보고 판단한다" | 주관적 판단 불가 | 수치 기준 명시 |
| 진단과 조치가 섞임 | 읽기 전용 확인 중 쓰기 명령 실행 가능 | Diagnose/Recommend/Act 분리 |
| 에스컬레이션 없음 | 해결 못하면 반복 루프 | 레벨별 조건과 SLA 명시 |
| 롤백 방법 생략 | 조치 실패 시 복구 불가 | 모든 쓰기 조치에 rollback/recovery 포함 |
| Tool 권한 미표시 | 위험한 Tool 자동 호출 가능 | annotation, approval, scope 문서화 |
AI 프롬프트 예시
다음 장애 대응 위키를 에이전트 운용형 런북으로 변환해줘.
요구사항:
1. 진단, 권장 조치, 실행 조치를 분리한다.
2. 모든 조건을 수치화한다.
3. 각 조치에 권한 모드와 승인 필요 여부를 표시한다.
4. destructive action은 기본적으로 사람 승인 필요로 둔다.
5. MCP Tool로 노출할 수 있는 진단/조치 후보를 별도 표로 정리한다.
기존 문서:
{위키 내용}체크리스트
| 항목 | 확인 |
|---|---|
| 트리거 조건이 수치 기반인가 | ☐ |
| 진단 단계가 읽기 전용으로 분리되어 있는가 | ☐ |
| 각 조치에 권한 모드가 있는가 | ☐ |
| destructive action에 사람 승인 조건이 있는가 | ☐ |
| 모든 조치에 확인 기준과 rollback/recovery가 있는가 | ☐ |
| 에스컬레이션 조건과 SLA가 명시되어 있는가 | ☐ |
| MCP Tool과 연결될 경우 scope, annotation, approval policy가 문서화되어 있는가 | ☐ |
last_tested와 owner가 frontmatter에 있는가 | ☐ |