원페이지 장애 리허설: 다음 프로덕션 장애 전에 ‘작은 화재훈련’을 스크립트로 준비하는 법

대부분의 팀은 실제 장애가 터졌을 때 비로소 자기 팀의 장애 대응 역량이 어느 정도인지 검증합니다.

그때는 이미 늦었습니다.

더 나은 패턴이 있습니다. 바로 작고, 스크립트로 짜인 화재훈련을 한 장짜리 리허설 런북으로 꾸준히 돌리는 겁니다. 이렇게 짧은 연습을 정기적으로 해두면, 장애 대응의 ‘근육 기억’을 단단히 만들고, SLO를 지키며, 실제 장애 상황을 혼돈이 아니라 계획된 실행에 가깝게 바꿀 수 있습니다.

이 글에서는 원페이지 장애 리허설을 핵심 SRE 실천법으로 설계하고 운영하는 방법을 구체적인 템플릿과 함께 설명합니다. 이 주 안에 바로 써먹을 수 있도록 구성했습니다.

왜 리허설이 SRE의 중심에 있어야 할까

SRE는 단순히 안정적인 시스템을 구축하는 일에 그치지 않습니다. 그 시스템을 스트레스 상황에서도 안정적으로 운영하는 것이 핵심입니다. 그 지점에서 ‘리허설’이 빛을 발합니다.

장애 리허설을 1급 SRE 실천으로 취급해야 하는 이유는 세 가지입니다.

SLO를 직접적으로 보호
더 빠른 탐지, 더 나은 트리아지, 더 명확한 커뮤니케이션은 모두 사용자 영향도를 줄여 줍니다. 리허설은 다음을 개선합니다.
- MTTA(Mean Time to Acknowledge, 인지까지 걸리는 평균 시간) – 이상 징후를 더 빨리 발견하고, 더 빨리 ‘보고 받았다’고 확정합니다.
- MTTR(Mean Time to Recover, 복구까지 걸리는 평균 시간) – 더 빠르게 조율하고, 올바르게 에스컬레이션하며, 혼선을 줄입니다.
- 에러 버짓 소진 속도 – 우왕좌왕하느라 허비하는 다운타임을 줄입니다.
운영 연속성 확보
핵심 인력이 자리에 없을 때도, 연습된 프로세스가 있으면 서비스는 계속 돌아갑니다. 표준화된 훈련은:
- 팀 전체에 지식을 분산시키고
- “그거 아는 사람 딱 한 명”에 대한 의존도를 줄이며
- 핸드오버와 온콜 로테이션의 리스크를 줄여 줍니다.
압박 속에서도 심리적 안전 확보
실제 장애가 터지면 아드레날린이 치솟습니다. 리허설은 이 과정을 익숙하게 만들어 줘서:
- 사람마다 자기 역할과 책임을 명확히 알고
- 커뮤니케이션 패턴이 자동화되고
- 팀이 침착하고 체계적으로 움직일 수 있게 돕습니다.

이 이점을 얻기 위해 복잡한 게임데이가 꼭 필요한 건 아닙니다. 필요한 것은 작고, 자주, 스크립트로 이뤄지는 연습입니다.

1단계: 표준화된 장애 ‘응답 코드’ 정의하기

리허설을 하기 전에, 먼저 공통 언어가 필요합니다.

장애 응답 코드(incident response code) 는 우선순위와 필요한 조치를 간단히 담아내는 짧고 표준화된 레이블입니다. 이 코드를 쓰면 긴 설명 없이도 현재 상황을 바로 공유할 수 있습니다.

예시 응답 코드 프레임워크:

Code 0 – 정보성(Informational)
- 사용자 영향 없음.
- 예: 비프로드(non-prod) 시스템 성능 저하, 지표 이상 징후를 탐지 중인 상태.
- 조치: 추적하고 학습하며 개선은 하되, 폭넓은 알림은 없음.
Code 1 – 낮은 영향(Low Impact)
- 사용자 영향은 경미하고, 범위가 제한적이거나 쉬운 우회 방법이 있음.
- 조치: 온콜 엔지니어가 원인 조사. 풀 스케일 인시던트 룸은 열지 않아도 되고, 상태 페이지 업데이트는 선택 사항.
Code 2 – 중간 수준 장애(Moderate Incident)
- 사용자가 체감할 만한 영향. SLO가 위협받고 있으나 아직 명확히 위반된 상태는 아님.
- 조치: 인시던트 선언, 전용 채널 생성, 역할 지정(Incident Commander, 커뮤니케이션 리드, 운영 리드), 정기적인 업데이트 수행.
Code 3 – 중대 장애(Major Incident)
- 광범위한 영향 또는 심각한 SLO 위반.
- 조치: 풀 응답 팀 구성, 경영진 가시성 확보, 고객 커뮤니케이션, 엄격한 업데이트 타임라인.
Code 4 – 치명적/안전/법적(Critical / Safety / Legal)
- 규제, 안전, 보안, 핵심 데이터 무결성 등과 관련된 중대 리스크.
- 조치: 전사적 대응, 별도 절차 가동, 법무/컴플라이언스 참여.

반드시 이 구조를 그대로 따를 필요는 없습니다. 다만 다음은 꼭 지켜야 합니다.

명확성: 누구나 각 코드가 의미하는 바를 이해할 것.
실행 가능성: 각 코드가 구체적인 조치(누가 참여하고, 누가 커뮤니케이션하며, 업데이트 주기는 얼마인지)와 바로 연결될 것.
일관성: 같은 코드는 팀과 서비스에 상관없이 항상 같은 응답 수준을 의미할 것.

리허설에서는 이 코드를 계속해서 사용합니다. 예: “에러율과 고객 문의를 보니 이건 Code 1에서 Code 2로 에스컬레이션해야겠네요.” 이런 반복이 실제 장애에서도 빠르고 일관된 판단을 훨씬 쉽게 만들어 줍니다.

2단계: 원페이지 리허설 스크립트 설계하기

리허설 런북은 한 장에 들어가야 합니다. 더 길어지면 실제 압박 상황에서 아무도 안 씁니다.

목표는: 언제든 프린트하거나 공유하거나, 세컨드 모니터에 띄워두고 바로 따라갈 수 있는 스크립트를 만드는 것입니다.

좋은 원페이지 스크립트에는 다음이 포함됩니다.

시나리오 헤더(Scenario header)
- 이름: 예) “부분적인 DB 장애 – 쓰기 실패 발생”
- 기본 응답 코드(시작 레벨)
- 영향받는 시스템
- 주시해야 할 의존성
이번 드릴의 목표(Objectives)
- X분 안에 탐지 및 트리아지 연습
- 에스컬레이션 경로와 오너십 검증
- 외부 커뮤니케이션(상태 페이지, 이해관계자 업데이트) 연습
타임라인 체크리스트(엔드 투 엔드 응답 흐름)

0–5분: 탐지 & 인지(Acknowledgment)
- 누가 문제를 감지하는가? (모니터링, 고객 지원, 수동 제보?)
- 어떻게 인지(acknowledge)하는가? (페이징 툴, Slack, SMS?)
- 응답 코드가 지정되었는가?
5–15분: 트리아지 & 격리(Containment)
- 역할 지정: Incident Commander(IC), Ops Lead, Comms Lead.
- 영향 범위 파악: 어떤 서비스, 리전, 테넌트가 영향 받는가?
- 가능한 빠른 격리 또는 완화 조치가 있는가?
15–30분: 커뮤니케이션 & 에스컬레이션
- 인시던트 채널/티켓 생성 또는 업데이트.
- 응답 코드를 에스컬레이션할지 결정.
- 내부 업데이트: X분마다.
- 필요시 외부 커뮤니케이션(상태 페이지, 주요 고객) 진행.
30분 이후: 해결 & 검증(Resolution & Verification)
- 수정(fix) 또는 롤백(rollback) 플랜 적용.
- 메트릭, 로그, 합성 모니터링(synthetic check)으로 검증.
- 안정화되면 장애 코드를 낮추거나 종료.
드릴 동안 꼭 던져봐야 할 질문들
- 아무도 알려주지 않아도, 이 문제가 발생했다는 걸 어떻게 알 수 있을까?
- 실패한 컴포넌트의 오너는 누구인가?
- 가장 빠르면서도 안전한 롤백/완화책은 무엇인가?
- 언제 에스컬레이션해야 하는가? 누가 승인하는가?
추적할 지표(Metrics)
- (시뮬레이션 기준) 탐지까지 걸린 시간
- 인지(acknowledge)까지 걸린 시간
- 적절한 사람을 호출하는 데 걸린 시간
- 외부 커뮤니케이션까지 걸린 시간
- (시뮬레이션 기준) 해결까지 걸린 시간

이 스크립트는 시스템을 실제로 고치는 기술적인 런북이 아니라, 장애 대응 프로세스를 운영하는 플레이북이라는 점이 중요합니다.

3단계: 작고 집중된 화재훈련 돌리기

“한 번에 다 망가지는” 시나리오를 시뮬레이션하고 싶은 유혹이 있습니다. 하지만 그런 훈련은 드물고, 무겁고, 반복하기 어렵습니다.

대신, 하나의 구체적인 실패 모드만 시뮬레이션하는 작고 집중된 화재훈련을 계획하세요. 예를 들면:

한 리전에서만 API 지연(latency) 급증
데이터베이스 커넥션 풀 고갈
인증 서비스 부분 장애
특정 핵심 큐 하나에만 메시지 큐 백로그 발생
5% 트래픽에만 영향을 주는 잘못 설정된 피처 플래그

각 드릴은 다음을 만족하는 것이 좋습니다.

전체 소요 시간은 30–45분 정도.
참가 인원은 소규모: 3–6명이 이상적.
대참사 시나리오의 폭보다, 응답 품질의 깊이에 집중.

드릴은 실제 시스템에는 영향 없이 문서와 도구 위에서만 진행하는 테이블톱(tabletop) 연습으로 할 수도 있고, 조직 성숙도가 허용한다면 안전한 환경에서 가벼운 카오스 실험과 묶어서 진행해도 좋습니다.

예시 일정:

주간: 현재 온콜 담당자와 함께 15–30분짜리 마이크로 드릴.
월간: 여러 팀이 함께 참여하는 45–60분짜리 시나리오.
분기별: 두세 개의 실패 모드를 연쇄적으로 엮은 대규모 크로스-조직 연습.

4단계: ‘수정’만이 아니라 전체 플로우를 연습하기

많은 팀이 사실상 버그를 고치고 장애를 처리하면서, 암묵적으로 ‘기술적 해결’은 자주 연습합니다. 하지만 그들이 연습하지 않는 것이 있습니다. 바로 그 해결을 둘러싼 모든 것들입니다.

각 드릴이 반드시 전체 라이프사이클을 다루도록 하세요.

탐지(Detection)
- 어떤 알림(alert)이 떠야 하는가?
- 그 알림은 실제로 액션 가능하도록 잘 튜닝되어 있는가?
- 고객 지원이나 영업팀이 티켓/전화로 먼저 눈치채게 될 수도 있는가?
트리아지(Triage)
- 이 시스템의 오너는 누구인가?
- 관련 대시보드와 로그는 어디에 있는가?
- Code 1 / Code 2 / Code 3 중 어떤 수준으로 볼지 어떻게 결정하는가?
커뮤니케이션(Communication)
- 누가 인시던트를 공식 선언하는가?
- 업데이트는 얼마나 자주 올릴 것인가?
- 아직 근본 원인(RCA)을 모를 때는 무엇을 어떻게 말해야 하는가?
에스컬레이션(Escalation)
- 언제 두 번째 온콜이나 전문가를 호출할 것인가?
- 언제 이해관계자나 리더십에 알릴 것인가?
- Code 4(법/보안/규제) 시나리오에서는 법무/컴플라이언스를 언제 끌어들일 것인가?
해결 & 검증(Resolution & Verification)
- 시스템이 정말 건강해졌다는 걸 어떻게 확신하는가?
- 수정 이후 얼마나 오랫동안 집중 모니터링을 해야 하는가?
- 언제 인시던트를 공식적으로 종료할 것인가?

엔드 투 엔드로 리허설을 하면, 단순히 디버깅 실력만이 아니라 팀 전체의 조율 능력이 눈에 띄게 매끄러워집니다.

5단계: 스크립트를 계속 다듬어 MTTA/MTTR 개선하기

원페이지 스크립트는 살아있는 문서입니다.

각 드릴이 끝난 뒤, 10–15분짜리 미니 회고를 진행하며 다음을 물어보세요.

우리를 느리게 만든 건 무엇이었는가?
오너십이나 응답 코드에 대해 헷갈린 지점은 어디였는가?
명백한 완화책을 놓친 부분은 없었는가?
커뮤니케이션이 불명확하거나, 너무 늦었거나, 너무 두루뭉술하진 않았는가?

이 중 1–3가지만 골라 바로 스크립트에 반영합니다.

체크리스트 항목을 추가하거나 다듬고
응답 코드를 언제 어떻게 에스컬레이션할지 더 명확히 적고
적절한 대시보드, 런북, 플레이북 링크를 붙이고
누구를 먼저 호출해야 하는지 조정합니다.

시간이 지나면 다음과 같은 개선이 눈에 띄게 나타날 겁니다.

MTTA 개선 – 언제, 어떻게 인시던트를 인지하고 분류해야 하는지 모두가 정확히 안다.
MTTR 개선 – 헛발질이 줄고, 완화까지 더 빨라지며, 에스컬레이션도 더 신속해진다.
회복력(Resilience) 향상 – 시니어 인력이 없어도 팀이 충분히 효과적으로 움직인다.

이 지표들을 눈에 보이게 만드세요. 실제 인시던트에서 추적하듯, 드릴에서도 MTTA·MTTR을 함께 트래킹하세요.

바로 사용 가능한 원페이지 리허설 템플릿

다음은 문서 도구에 그대로 복사해서 쓸 수 있는 간단한 템플릿입니다.

# One-Page Incident Rehearsal Script

## Scenario
- Name: ________________________________
- Date: ________________________________
- Facilitator: _________________________
- Participants: ________________________
- Default Response Code: [0/1/2/3/4]
- Systems/Services affected: ___________
- Dependencies to monitor: _____________

## Objectives (pick 2–3)
- [ ] Improve time to acknowledge alert
- [ ] Practice assigning roles quickly
- [ ] Validate escalation path
- [ ] Exercise external communication
- [ ] Test our dashboards/runbooks

## Timeline & Checklist

**0–5 min: Detection & Acknowledgment**
- [ ] Alert/source that detects issue: ___________
- [ ] On-call acknowledges via: ________________
- [ ] Assign initial response code: [0/1/2/3/4]

**5–15 min: Triage & Containment**
- [ ] Assign roles: IC, Ops Lead, Comms Lead
- [ ] Identify blast radius (services/regions)
- [ ] Identify potential quick mitigations

**15–30 min: Communication & Escalation**
- [ ] Create/update incident channel/ticket
- [ ] Decide whether to escalate response code
- [ ] Internal update frequency: every __ min
- [ ] External update? [Yes/No] If yes, where?

**30+ min: Resolution & Verification**
- [ ] Proposed fix/rollback: ________________
- [ ] Verification via metrics/logs/checks
- [ ] Downgrade/close incident when stable

## Key Learnings (post-drill)
- What went well?
- What slowed us down?
- What will we change in our process/script?

## Metrics (simulated)
- Time to detect: ______
- Time to acknowledge: ______
- Time to engage right people: ______
- Time to first internal update: ______
- Time to (simulated) resolution: ______

응답 코드, 역할, 타임라인은 각 조직의 상황과 리스크 허용 범위에 맞게 자유롭게 커스터마이징하세요.

결론: 작게 시작해서 자주 반복하라

더 나은 장애 대응을 위해 꼭 대규모 게임데이가 필요한 것은 아닙니다. 필요한 건 반복 가능한 원페이지 스크립트와, 이를 기반으로 하는 작고 집중된 화재훈련을 습관화하는 것입니다.

정리하면 다음과 같습니다.

명확한 장애 응답 코드를 정의해, 우선순위와 필요한 조치가 바로 드러나게 하라.
장애 리허설을 핵심 SRE 업무로 취급하고, 부가적인 옵션이 아니게 만들라.
압박 속에서도 쓸 수 있도록 원페이지 런북으로 훈련을 가볍게 유지하라.
실제 실패 모드를 닮은 작고 구체적인 화재훈련을 돌려라.
기술적 수정뿐 아니라 전체 대응 라이프사이클을 모두 연습하라.
스크립트를 계속 다듬어 MTTA, MTTR, 회복력을 꾸준히 개선하라.

이제 시나리오 하나를 고르고, 위 템플릿을 복사해서, 온콜 팀과 45분짜리 세션을 잡아 첫 번째 원페이지 장애 리허설을 돌려 보세요. 새벽 2시에 실제 장애를 맞이한 미래의 당신이, 그때 연습해 둔 자신에게 고마워하게 될 것입니다.