> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.
# 런북
> 인시던트 발생 시 AI 에이전트가 복구 절차를 검색하고 실행할 수 있도록 팀의 운영 런북을 연결하세요
프로덕션 인시던트가 발생하면 팀에는 런북이 있습니다. 파드 재시작, 데이터베이스 페일오버, 스케일링 작업 등 일반적인 장애에 대한 단계별 절차서입니다. 문제는 새벽 3시에 올바른 런북을 찾아 압박감 속에서 정확히 실행하는 것입니다.
CloudThinker 런북이 그 간격을 메워줍니다. [RCA 조사](/ko/guide/incident/root-cause-analysis) 중 AI 에이전트는 연결된 런북 소스를 자동으로 검색하고, 관련 절차를 찾아 복구 명령을 실행합니다. 파괴적인 작업에 대해서는 정책 기반 승인 제어를 통해 사람이 개입할 수 있도록 보장합니다.
수동 업로드 및 연결된 저장소가 포함된 런북 소스 대시보드
***
## 런북 작동 방식
기존 런북 저장소인 Confluence, GitHub, GitLab을 연결하거나 마크다운 파일을 직접 업로드하세요.
인시던트가 [근본 원인 분석](/ko/guide/incident/root-cause-analysis)을 트리거하면, AI 에이전트는 인시던트 컨텍스트와 영향받은 서비스를 기반으로 연결된 소스에서 관련 런북을 검색합니다.
명령을 실행하기 전에 시스템이 워크스페이스 [승인 정책](/ko/guide/approval)을 평가합니다. 정책에 따라 명령은 자동 실행되거나, 승인 대기 상태에 놓이거나, 차단됩니다.
승인이 필요한 명령의 경우 이메일, Slack, 인앱 알림을 통해 알림을 받습니다. 어느 채널에서든 직접 승인하거나 거부할 수 있습니다. 승인된 명령은 즉시 실행됩니다.
***
## 런북 소스 연결
**Deep Response Engine > Runbooks**로 이동하여 소스를 관리하세요. CloudThinker는 네 가지 소스 유형을 지원하며, 각각 다른 워크플로에 적합합니다.
Confluence 구성으로 새 런북 소스 추가
### Confluence
Confluence 지식 베이스를 연결하여 에이전트가 위키 페이지에서 운영 절차를 검색할 수 있도록 합니다.
**설정:**
1. 런북 페이지에서 **소스 추가**를 클릭합니다
2. 이름을 입력합니다 (예: "SRE 런북")
3. 소스 유형으로 **Confluence**를 선택합니다
4. Atlassian 연결을 선택합니다 ([연결 > Atlassian](/ko/guide/connections/atlassian)에서 설정)
5. 검색 범위를 특정 **스페이스 키**로 제한합니다 (선택 사항, 예: `SRE`)
6. 페이지를 필터링할 **레이블**을 추가합니다 (예: `runbook`, `incident-response`)
7. **소스 추가**를 클릭합니다
**에이전트 검색 방식:** RCA 중 에이전트는 Confluence의 CQL 쿼리 언어를 사용하여 구성된 스페이스 및 레이블 필터 내에서 인시던트 컨텍스트와 일치하는 페이지를 찾습니다.
### GitHub
에이전트가 런북 마크다운 파일이 포함된 GitHub 저장소를 참조하도록 설정합니다.
**설정:**
1. **소스 추가**를 클릭합니다
2. 소스 유형으로 **GitHub**를 선택합니다
3. GitHub 연결을 선택합니다 ([연결](/ko/guide/connections/overview)에서 설정)
4. 런북이 포함된 **저장소**를 선택합니다
5. **브랜치**를 설정합니다 (기본값: `main`)
6. 검색 범위를 제한할 **경로 접두사**를 설정합니다 (선택 사항, 예: `docs/runbooks/`)
7. 매칭할 **파일 패턴**을 구성합니다 (기본값: `*.md`)
8. **소스 추가**를 클릭합니다
**에이전트 검색 방식:** 에이전트는 GitHub API를 사용하여 경로 및 패턴 필터에 맞는 파일을 나열하고 읽은 후, 현재 인시던트와의 관련성을 분석합니다.
### GitLab
GitHub와 동일한 워크플로로, GitHub 연결 대신 GitLab 연결을 사용합니다.
**설정:**
1. **소스 추가**를 클릭합니다
2. 소스 유형으로 **GitLab**을 선택합니다
3. GitLab 연결을 선택합니다
4. **저장소**, **브랜치**, **경로 접두사**, **파일 패턴**을 선택합니다
5. **소스 추가**를 클릭합니다
**에이전트 검색 방식:** 에이전트는 GitLab API를 사용하여 저장소에서 매칭 파일을 검색하고 가져옵니다.
### 수동 업로드
절차가 외부 시스템에 저장되지 않은 경우 마크다운 런북 파일을 직접 업로드합니다.
**설정:**
1. 런북 페이지에서 **런북 업로드**를 클릭합니다
2. `.md` 파일을 드래그 앤 드롭합니다 (파일 최대 20개, 각 5MB)
3. 확인 전 필요한 경우 파일 이름을 수정합니다
4. **업로드 확인**을 클릭합니다
업로드 후 CloudThinker는 마크다운의 코드 블록에서 쓰기 명령 (`kubectl apply`, `aws` 변경, `helm install` 등)을 자동으로 추출합니다. 추출된 명령은 [명령어별 권한](#명령어별-권한)의 기반이 됩니다.
***
## 명령어별 권한
수동 런북은 고유한 안전 기능인 **명령어별 권한 제어**를 제공합니다. 마크다운 파일을 업로드하면 CloudThinker의 AI가 코드 블록을 분석하여 모든 쓰기/변경 명령을 추출합니다. 이를 통해 에이전트가 자율적으로 실행할 수 있는 항목을 세밀하게 제어할 수 있습니다.
파드 CrashLoopBackOff 런북에 대한 명령어별 권한 제어
### 작동 방식
1. **자동 추출**: 업로드 후 시스템이 모든 코드 블록을 파싱하여 인프라를 변경하는 셸 명령을 식별합니다 (예: `kubectl set resources`, `kubectl rollout restart`, `kubectl delete`)
2. **읽기 전용 명령 제외**: `kubectl get`, `kubectl describe`, `kubectl logs` 같은 명령은 추출되지 않으며, 에이전트는 항상 읽기 전용 명령을 실행할 수 있습니다
3. **각 명령에 권한 부여**: 추출된 모든 쓰기 명령은 기본적으로 **승인 필요** 상태로 시작합니다
### 권한 수준
| 권한 | 동작 |
| --------- | ------------------------------------------------ |
| **허용** | 에이전트가 사람의 승인 없이 즉시 명령을 실행합니다 |
| **승인 필요** | 에이전트가 실행 전 승인을 요청합니다. 이메일, Slack, 인앱으로 알림이 전송됩니다 |
| **거부** | 에이전트가 이 명령을 실행할 수 없습니다 |
### 명령 관리
런북 세부 정보 대화상자에서:
* **모든 권한 일괄 설정**: "모두 다음으로 설정..." 드롭다운을 사용하여 모든 명령을 허용, 승인 필요, 또는 거부로 일괄 변경합니다
* **개별 권한 변경**: 명령 옆의 드롭다운을 클릭하여 권한 수준을 조정합니다
* **명령 추가**: 새 명령 패턴을 입력하고 Enter 키를 눌러 목록에 추가합니다
* **명령 제거**: 삭제 아이콘을 클릭하여 정책에서 명령을 제거합니다
* **전체 명령 보기**: 확장 화살표를 클릭하여 여러 줄이나 긴 명령의 전체 내용을 확인합니다
명령어별 권한은 현재 수동으로 업로드된 런북에만 사용할 수 있습니다. 외부 소스(Confluence, GitHub, GitLab)의 경우 모든 명령은 기본적으로 승인이 필요합니다. 외부 소스에 대한 명령어별 제어 기능은 곧 제공될 예정입니다.
***
## 승인 워크플로
RCA 중 에이전트가 관련 런북을 찾고 정책이 승인을 요구하는 경우 다음 흐름이 진행됩니다:
### 승인 흐름
1. **에이전트가 런북 발견**: 조사 중 에이전트가 소스를 검색하여 매칭 절차를 식별합니다
2. **정책 평가**: 시스템이 런북 및 해당 명령에 대해 워크스페이스 승인 정책을 확인합니다
3. **알림 전송**: 승인이 필요한 경우 구성된 모든 채널로 알림이 전송됩니다:
* **이메일**: 런북 제목, 소스 링크, 정책 사유
* **Slack**: 인시던트 컨텍스트가 포함된 인터랙티브 알림
* **인앱**: 인시던트의 배지로 대기 중인 승인 표시
4. **승인 또는 거부**: 승인을 클릭하여 에이전트가 진행하도록 하거나, 거부를 클릭하여 실행을 차단합니다
5. **에이전트 계속 진행**: 승인 시 에이전트가 런북 명령을 실행합니다. 거부 시 에이전트는 런북을 실행하지 않고 조사를 계속합니다
### 승인 상태
| 상태 | 의미 |
| -------- | ------------------------------------ |
| **대기 중** | 사람의 승인을 기다리는 중 — 에이전트가 이 단계에서 일시 정지됨 |
| **승인됨** | 사람이 승인함 — 명령이 실행 중이거나 완료됨 |
| **거부됨** | 사람이 거부함 — 에이전트가 이 런북을 건너뛰고 조사를 계속함 |
### 실행 상태
승인 후 각 실행은 결과를 추적합니다:
| 상태 | 의미 |
| -------- | --------------------------- |
| **시작 전** | 승인되었지만 명령이 아직 실행되지 않음 |
| **완료** | 모든 명령이 성공적으로 실행됨 |
| **실패** | 실행 중 하나 이상의 명령이 실패함 |
| **건너뜀** | 실행이 건너뛰어짐 (예: 승인 만료 또는 대체됨) |
### 실행 내역 보기
런북 페이지의 **실행 내역** 탭으로 전환하여 인시던트 전반에 걸친 모든 런북 실행 내역을 확인합니다. 다음 작업을 수행할 수 있습니다:
* 런북 제목으로 검색
* 정책 결정, 승인 상태, 실행 결과 확인
* 어떤 인시던트에 어떤 런북이 사용되었는지 추적
***
## 모범 사례
**소스 구성:**
* 소스 이름을 설명적으로 지정합니다 (예: "K8s 긴급 런북", "데이터베이스 페일오버 절차")
* 경로 접두사와 파일 패턴을 사용하여 검색 범위를 집중적이고 빠르게 유지합니다
* Confluence의 경우 레이블을 사용하여 도메인별로 런북을 분류합니다 (예: `kubernetes`, `database`, `networking`)
**권한 전략:**
* 확신이 생길 때까지 모든 명령에 대해 **승인 필요** (기본값)로 시작합니다
* 검증된 저위험 명령은 점진적으로 **허용**으로 변경합니다 (예: 스케일링 작업, 로그 수집)
* 파괴적인 명령(삭제, 드롭, 강제)은 영구적으로 **승인 필요**로 유지합니다
* 자동화해서는 안 되는 명령에는 **거부**를 사용합니다 (예: 프로덕션 데이터베이스 삭제)
**런북 품질:**
* 셸 언어 힌트(` ```bash `)가 있는 명확한 코드 블록으로 마크다운 런북을 작성합니다
* 최상의 추출 결과를 위해 한 줄에 하나의 명령을 사용합니다
* 각 절차를 언제 사용해야 하는지에 대한 컨텍스트를 포함합니다 — 에이전트가 런북을 인시던트에 매칭하는 데 사용합니다
* 런북을 집중적으로 유지합니다: 모든 것을 다루는 단일 문서보다 파일당 하나의 절차가 더 효과적입니다
***
## 다음 단계
AI 에이전트가 인시던트를 조사하는 방법과 분석 워크플로 중 런북이 트리거되는 시점을 알아보세요.
에이전트가 자율적으로 실행할 수 있는 내용을 제어하는 워크스페이스 수준의 승인 정책을 구성하세요.