종이부터 시작하는 인시던트 드릴북: 한밤중 온콜 악몽을 대낮에 미리 리허설하는 법

온콜 엔지니어에게 가장 두려운 게 뭐냐고 물어보면 비슷한 답이 돌아옵니다. 뜬금없는 알람, 없는 런북, 모호한 오너십, 뒤엉킨 슬랙 채널, 아직 뭐가 망가졌는지도 모르는 상황에서 계속 들어오는 리더십의 업데이트 요청 같은 것들이죠.

이런 혼란은 모니터링 툴을 하나 더 산다고 해결되지 않습니다. 인시던트가 터지기 전에, 모두가 깨어 있고 조용하며 안전한 환경에서 미리 리허설해야 합니다. 그것도 종이 위에서요.

여기서 필요한 것이 바로 **종이부터 시작하는 인시던트 드릴북(paper-first incident drillbook)**입니다. 조직의 현실을 반영한 인시던트들을 단계별로 따라가며 연습하는, 사전에 설계된 테이블탑(tabletop) 연습 모음이죠. 반복하다 보면 좋은 관행이 몸에 밸 정도로요.

아래에서는 이런 드릴을 설계·진행·개선하는 실무 가이드를 단계별로 정리했습니다.

왜 ‘종이부터(paper-first)’가 즉흥적인 혼돈보다 나은가

팀이 처음 인시던트 드릴을 시도할 때 흔히 이런 패턴이 나타납니다.

누군가 말합니다. “일단 시나리오 하나 지어서 한번 굴려보죠.”
연습은 곧바로 아키텍처 다이어그램을 두고 하는 구조 토론으로 변합니다.
정작 인시던트 대응 프로세스는 아무도 제대로 연습하지 못합니다.

결과적으로 흥미로운 대화는 남지만, 운영 역량은 전혀 개선되지 않습니다.

‘종이부터’ 접근이란 다음을 의미합니다.

드릴을 사전에, 문서 형태로 설계한다.
실제 프로세스와 실제 위협 환경에 기반해 만든다. (뜬구름 잡는 가정이 아니라)
역할, 단계, 질문·인젝트(inject)를 연습 전에 종이(또는 문서)로 명시해 둔다.

이렇게 하면 연습은 즉흥 연기가 아니라 의도적인 연습(deliberate practice) 으로 바뀝니다. 연극처럼 모두가 같은 대본을 가지고 시작한 다음, 그 대본이 어디서 틀렸고 어디가 비어 있는지 찾아가는 식이죠.

1단계: 실제 프로세스에 드릴을 앵커링하라

존재하지 않는 프로세스를 드릴로 개선할 수는 없습니다.

시나리오부터 만들기 전에, 먼저 어떤 핵심 워크플로를 리허설하고 싶은지 정해야 합니다. 대부분의 팀에 공통적으로 중요한 것들은 다음과 같습니다.

인시던트 탐지 및 트리아지 (알람이 울리면 무슨 일이 시작되는가?)
인시던트 커맨드(Incident Command) (누가 리드하는가? 어떻게 커뮤니케이션하는가?)
기술적 조사 및 완화(Mitigation) (응답자들이 어떻게 협업하는가?)
이해관계자 커뮤니케이션 (고객, 경영진, 지원팀에 언제·어떻게 업데이트하는가?)
기록 및 후속 조치 (인시던트를 어떻게 기록하고 리뷰하는가?)

드릴을 돌리기 전에 최소한 대략적인 인시던트 대응 프로세스가 문서로 있어야 합니다. 한 페이지짜리 체크리스트라도 괜찮습니다. 그 다음에 이 프로세스를:

엔드투엔드로 실제처럼 실행해 보고,
어디가 모호하고, 비현실적이고, 빠져 있는지 드러내는

시나리오를 설계합니다.

만약 여러분의 “프로세스”가 사실상 구전 지식에 가깝다면, 드릴을 하면 그게 곧바로 드러날 것입니다. 그 자체가 큰 수확입니다. 드릴 중 실제로 사람들이 어떻게 행동하는지 잘 기록해 두고, 그걸 기반으로 프로세스를 정식 문서로 만들어 가면 됩니다.

2단계: 실제 위협 환경을 반영한 시나리오를 설계하라

좋은 테이블탑 드릴은 뻔한 사이버 재난 영화 시나리오를 쓰지 않습니다. 여러분 팀이 실제로 겪을 법한 온콜 악몽을 시뮬레이션합니다.

현실적인 시나리오를 설계하려면:

과거를 돌아본다
- 과거 SEV-1, SEV-2 인시던트
- 아슬아슬하게 넘어간 사고, 반복되는 문제들
- 비슷한 회사·업계에서 발생한 대형 장애 사례
현재 환경에 매핑한다
예를 들어 다음을 고려합니다.
- 사용 중인 클라우드 제공자와 리전
- 핵심 의존성 (결제 게이트웨이, SSO, 데이터베이스, 메시지 큐 등)
- 규제·컴플라이언스 (예: 개인정보, 가용성 SLA)
가치 높은 시나리오 유형 2–4개를 고른다. 예를 들어:
- 갑작스러운 트래픽 급증으로 인한 연쇄 장애
- 데이터 스토어 손상 또는 주요 DB 가용성 상실
- 보안 인시던트 (유출된 크리덴셜, 수상한 접근 패턴 등)
- 주요 서드파티(결제, 로그인, 알림 등) 장애로 인한 핵심 플로우 중단

각 시나리오는 다음 요소를 포함해야 합니다.

배경(Background): 평소 상태는 어떤가? 무엇이 걸려 있는가? (매출, 안전, 컴플라이언스, 브랜드 등)
트리거(Trigger): 처음 이상을 눈치채는 신호는? (알람, 고객 문의, 대시보드 이상 징후 등)
제약(Constraints): 무엇이 고장 났거나 사용할 수 없는가? 시간 압박은 있는가?
복잡도 인젝트(Complications): 연습 도중 어떤 “꼬임”을 추가할 것인가? (예: “PagerDuty가 죽어 있다”, “벤더 X의 주 연락자가 연락 두절이다” 등)

참여자들이 이렇게 말하게 만드는 게 목표입니다.
“이거 진짜라면 내가 잠을 못 잘 만한 딱 그 케이스네.”

3단계: 올바른 이해관계자를 모두 참여시켜라

온콜 악몽은 기술 퍼즐에 그치지 않는 경우가 대부분입니다. 사회기술적(socio-technical) 문제입니다. 사람, 프로세스, 인프라가 만나는 지점에서 꼬이죠.

그 지점에서 어떤 일이 벌어지는지 보려면, 실제 인시던트에 관여할 사람들이 연습에도 있어야 합니다.

누가 참여해야 할까?

실제 온콜에 들어가는 엔지니어 / SRE / 개발자
인시던트 커맨더(Incident Commander) (또는 현재 그 역할을 맡는 사람)
고객 지원 / 고객 성공(Customer Success) (고객의 첫 신고가 이쪽으로 오는 경우가 많음)
영향을 받는 서비스의 프로덕트·비즈니스 오너
보안 팀(Security) (보안 이슈가 조금이라도 걸려 있다면 필수)
고객 커뮤니케이션이 필요한 경우 커뮤니케이션 / PR / 마케팅

매번 전원을 불러 모을 필요는 없지만, 시나리오마다 이렇게 자문해야 합니다.

“실제 이런 인시던트가 터지면 누가 적극적으로 관여하게 될까?”

그 사람들은 구경만 해서는 안 됩니다. 드릴 동안 말하고, 결정하고, 행동해야 합니다.

이해관계자들이 실제로 참여하면 다음과 같은 것들이 잘 드러납니다.

오너십의 공백 (“이 결정을 실제로 누가 내릴 수 있지?”)
핸드오프 실패 (지원팀 → 엔지니어링, 엔지니어링 → 리더십 등)
커뮤니케이션 경로 문제 (채널이 너무 많거나, 구조가 없어서 소음만 심한 경우 등)

4단계: 토론형 vs. 실습형, 포맷을 상황에 맞게 선택하라

모든 드릴이 풀스케일 기술 시뮬레이션일 필요는 없습니다. 크게 두 가지 스타일이 있고, 둘 다 유용합니다.

1. 토론 기반 테이블탑(Tabletop)

모두가 (물리적 혹은 온라인) 같은 테이블에 앉아서 시나리오를 단계별로 따라갑니다. 퍼실리테이터가 시간이 지날수록 새로운 정보를 조금씩 공개합니다.

다음 상황에 적합합니다.

프로세스가 새로 생겼거나, 아직 자주 바뀌는 단계인 경우
다양한 조직이 섞인 크로스펑셔널 커뮤니케이션 연습
아직 성숙도가 낮거나, 팀 규모가 작거나, 시간 자원이 적을 때

장점:

비용이 낮습니다. 슬라이드나 공유 문서만으로도 가능합니다.
비기술 직군도 부담 없이 참여시킬 수 있습니다.
의사결정과 조율 능력을 점검하기 좋습니다.

2. 운영/실습형(Hands-On) 연습

실제 시스템 상태를 시뮬레이션(또는 아주 조심스럽게 유도)하고, 사람들이 프로덕션에서 사용하는 것과 동일한 툴과 채널에서 대응하도록 합니다.

다음 상황에 적합합니다.

프로세스가 비교적 안정되고 성숙한 팀
기술적 디버깅과 완화 절차를 집중적으로 연습하고 싶을 때
모니터링, 대시보드, 런북이 실제로 잘 동작하는지 검증하고 싶을 때

장점:

알람, 대시보드, 런북까지 포함한 고충실도(high-fidelity) 리허설이 됩니다.
깊은 기술적 근육 기억(muscle memory)을 형성하는 데 좋습니다.

대부분의 조직에는 하이브리드 접근이 잘 맞습니다.

먼저 토론 기반 테이블탑으로 프로세스와 역할을 다듬고,
충분히 안정된 핵심 시나리오만 실습형으로 승격시키는 식입니다.

5단계: 간단한 종이 기반 드릴 템플릿 만들기

멋진 플랫폼이 꼭 필요하지 않습니다. 구조만 잘 잡힌 문서 하나면 충분합니다.

아래는 바로 가져다 쓸 수 있는 최소한의 드릴 템플릿 예시입니다.

1. 시나리오 개요(Scenario Overview)

이름(Name): 결제 게이트웨이 부분 장애(Payment Gateway Partial Outage)
유형(Type): 가용성 / 서드파티 의존성
영향 서비스(Services impacted): Checkout API, Order processing
비즈니스 영향(Business impact): 매출 손실, 장바구니 이탈 증가, 지원 티켓 폭증

2. 목표(Objectives)

인시던트 탐지 및 트리아지 플로우를 검증한다.
지원팀과 리더십을 대상으로 한 커뮤니케이션을 연습한다.
백업 결제 제공자로 페일오버할지에 대한 의사결정을 연습한다.

3. 참여자 및 역할(Participants & Roles)

인시던트 커맨더(Incident Commander): Name
1차 대응자(Primary Responder, Service X): Name
지원팀 리드(Support Lead): Name
프로덕트 오너(Product Owner): Name
옵저버 / 기록 담당(Observer / Note-taker): Name

4. 타임라인 & 인젝트(Timeline & Injects)

T+0분: 모니터링 알람: Checkout errors > 15%
T+5분: 지원팀에서 “결제 실패” 티켓이 급증했다고 보고.
T+10분: 에러 로그 확인 결과, PaymentProviderA로 가는 요청에서 대부분 실패.
T+15분: 새로운 인젝트: 경영진이 묻는다. “지금 상태 페이지에 올려야 하나요?”
T+20분: 새로운 인젝트: 백업 결제 제공자는 수수료가 더 비싸며, 재무팀이 우려를 제기.

각 인젝트마다 퍼실리테이터는 이렇게 질문합니다.

지금 무엇을 하겠습니까?
누가 그 작업을 담당합니까?
관련 내용은 어디에 문서화되어 있습니까?
어떻게, 누구에게 이 상황을 커뮤니케이션합니까?

5. 아티팩트 & 도구(Artifacts & Tools)

관련 런북 링크
상태 페이지 운영 가이드
내부 인시던트 채널 네이밍 컨벤션
모니터링 대시보드 링크

6. 사후 리뷰 메모(After-Action Review Notes)
연습 중에 나온 관찰, 결정, 발견된 갭을 자유롭게 적을 수 있는 공간을 남겨둡니다.

이 모든 것이 바로 “종이부터”입니다. 리허설 전에 대본을 준비해 두는 것이죠.

6단계: 구조화된 사후 리뷰(After-Action Review)를 진행하라

어떤 드릴이든 가장 중요한 부분은 끝난 후에 무엇을 하느냐입니다.

구조화된 사후 리뷰(AAR, After-Action Review) 없이 연습만 반복하면, 실제 인시던트에서 똑같은 문제가 계속 재발합니다.

가능하면 드릴이 끝난 직후, 늦어도 같은 날 안에 AAR을 진행하고 다음에 집중합니다.

실제로 무엇이 일어났는가?
- 핵심 결정과 행동의 타임라인을 정리합니다.
무엇이 잘 되었는가?
- 다시 반복하고 싶은 행동, 도구, 단계들을 구체적으로 짚어 줍니다.
무엇이 헷갈렸거나 망가졌는가?
- 애매한 오너십
- 없거나 오래된 런북
- 도구의 빈틈 (대시보드 부재, 소용없는 알람 등)
다음 드릴 전까지 무엇을 바꿀 것인가?
- 발견된 이슈 하나하나를 작고 구체적인 액션으로 쪼개고, 오너와 기한을 정합니다.

예시 개선 항목:

“인시던트 커맨더용 짧은 체크리스트를 만든다.”
“내부 업데이트 기본 주기를 15분 단위로 표준화한다.”
“백업 결제 제공자로 페일오버하는 단계를 문서화한다.”

AAR 결과는 인시던트 드릴북에 축적합니다. 드릴을 할수록 지식 베이스가 커지고, 팀의 대응력도 함께 성장합니다.

7단계: 작게 시작하고, 자주 반복하라

인시던트 드릴에서 가치를 얻기 위해 거창한 예산은 필요 없습니다. 복잡함보다 중요한 것은 꾸준함입니다.

현실적인 주기와 범위 예시:

분기별 크로스팀 테이블탑 드릴: 회사 전체에 영향을 줄 수 있는 큰 시나리오 (예: 전사 장애, 보안 인시던트)
월 1회 가벼운 드릴: 핵심 서비스 대상, 30–60분, 소수 인원으로 진행
시나리오를 로테이션해 가며, 가용성·보안·데이터 무결성·서드파티 의존성 등 핵심 리스크 영역을 골고루 다룬다.

초기 드릴은 의도적으로 단순하게 가져가세요.

한 번에 시나리오 1개, 시간 1시간, 퍼실리테이터 1명.
이미 쓰는 도구만 활용 (화상 회의, 공유 문서, 채팅 채널).
회당 1–3개의 명확한 개선 사항만 도출해도 충분하다고 생각하십시오.

시간이 지나면 반복을 통해 다음이 쌓입니다.

근육 기억: 새벽 3시에 호출을 받아도 몸이 먼저 움직일 만큼 익숙해집니다.
공유된 멘탈 모델: 팀이 시스템과 역할이 어떻게 맞물려 있는지 공통된 그림을 갖게 됩니다.
심리적 안전 문화: 인시던트를 개인의 실패가 아니라, 배울 수 있는 이벤트로 바라보게 됩니다.

결론: 대낮에 연습하면, 밤에 더 잘 잘 수 있다

실제 인시던트는 지저분하고, 감정적으로 힘들고, 비용이 많이 듭니다. 하지만 그때 필요한 역량—명확한 커뮤니케이션, 단호한 리더십, 효과적인 기술 대응—은 모두 훈련 가능한 것들입니다.

종이부터 시작하는 인시던트 드릴북은 다음을 위한 저위험 연습장을 제공합니다.

실제 온콜 악몽을, 터지기 전에 미리 리허설하기
프로세스·툴링·오너십의 빈틈을, 리스크가 낮을 때 드러내기
매번의 연습을 구조화된 리뷰를 통해 지속적인 개선으로 연결하기

완벽한 계획이나 거대한 플랫폼은 필요 없습니다. 필요한 것은:

간단하더라도 문서화된 프로세스
현실감 있는 시나리오
제대로 된 사람들을 한자리에 모으는 것
배운 것을 기록하고, 실제로 행동으로 옮기겠다는 약속

인시던트를 대낮에, 종이 위에서 먼저 겪어 보십시오. 그러면 진짜 새벽 3시 호출이 왔을 때, 그것은 더 이상 악몽이 아니라 이미 여러 번 맞춰 본 대본처럼 느껴질 것입니다.