본문으로 바로가기
리옵트 핸드북
리옵트 핸드북
에이전틱 시대의 문서화 혁신

패러다임 전환

왜 문서화가 변해야 하는가AI-readable 문서 설계 원칙AI와 협업하는 문서 작성 프로세스

문서 유형별 실전

프로젝트 규칙 문서문서에서 스킬·플러그인·MCP로에이전트 문서 보안API 문서 & 스펙README & 온보딩 문서아키텍처 결정 기록 (ADR)런북 & 운영 문서사용자 가이드 & 튜토리얼지식기반 (KB) & 내부 위키

운영

문서 유지보수 전략팀 문서화 문화 만들기

부록

템플릿 모음검증 리포트업데이트 내역
핸드북›에이전틱 시대의 문서화 혁신›런북 & 운영 문서
한국어English

런북 & 운영 문서

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_metricsmetric 조회DiagnosereadOnlyHint: true자동 가능
list_deployments배포 이력 조회DiagnosereadOnlyHint: true자동 가능
purge_cache캐시 삭제ActdestructiveHint: false, idempotentHint: true정책에 따라
rollback_release릴리스 롤백ActdestructiveHint: true사람 승인
rotate_secretsecret 교체ActdestructiveHint: 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.sh

SKILL.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에 있는가☐

관련 문서

부록 A. 런북 템플릿

Prisma Production Guardrails · 마이그레이션 배포·장애 대응·복구 리허설(DR Drill)·포스트모템 네 가지 런북 템플릿을 복사해 바로 쓸 수 있는 체크리스트 형태로 제공합니다.

팀 하네스 설계 체크리스트

하네스 엔지니어링 · 리포·역할·평가·도구·HITL·샌드박스·배포·운영 8개 영역을 0~2점으로 진단하고, 점수별 다음 행동과 30일 도입 순서, MVP 패키지까지 제시하는 하네스 설계 체크리스트입니다.

Ch3. 승인/샌드박스 전략

Codex 고급 활용 · 승인 정책, 자동 승인 범위, 안전한 운영 패턴

업데이트 내역

에이전틱 시대의 문서화 혁신 핸드북 변경 로그

Ch7. 롤백 전략

Prisma Production Guardrails · 코드 롤백 우선, 데이터는 롤포워드, PITR은 최후 수단이라는 우선순위와 호환성 창 운영, 롤백 결정 트리, 비즈니스 승인 체계를 다룹니다.

아키텍처 결정 기록 (ADR)

AI 에이전트가 코드베이스의 과거 설계 결정, 검토한 대안, 트레이드오프를 이해하도록 ADR을 구조화하고 유지하는 실무 방법과 팀 운영 규칙을 정리합니다.

사용자 가이드 & 튜토리얼

고객 지원 챗봇과 RAG가 정확히 매칭하도록 FAQ를 구조화된 Q&A로, 튜토리얼을 전제조건-단계-결과 확인 패턴으로 설계하고 이미지에 텍스트 대체를 병행하는 방법.

On this page

왜 런북이 바뀌어야 하는가런북의 세 가지 모드AI-readable 런북 작성 원칙1. 조건-행동-확인-승인2. 수치화된 판단 기준3. 관측값과 명령의 분리4. 에스컬레이션 조건 명시MCP Tool과 런북 연결런북 Skill 패턴런북 템플릿AI가 실패하는 패턴AI 프롬프트 예시체크리스트