연필과 포스트잇의 인시던트 미로: 다음 페이저 스톰을 위한 제로‑툴 훈련 설계하기

새벽 3시에 시스템이 불타고 있고 페이저(온콜 알람)가 폭주하는데, 그 대응을 조율하는 데 쓰이던 것들까지 전부 불타고 있다면 어떻게 될까?

Slack도 없다. Zoom도 없다. Jira도 없다. 인시던트 봇도 없다. 대시보드도 없다. 남은 건 울리는 전화기, 화이트보드, 그리고 포스트잇 한 묶음뿐.

이 불편한 그림이 바로, 의도적으로 **제로‑툴 인시던트 훈련(zero‑tool incident drill)**을 해야 하는 이유다. 모든 주요 시스템과 협업 도구가 사용할 수 없다고 가정하고, 그래도 어떻게든 대응을 해보는 구조화된 시뮬레이션이다.

이건 단순한 카오스 엔지니어링 이벤트나 재미로 하는 실험이 아니다. 이건 핵심적인 회복탄력성(capability of resilience) 역량이다. 실제 보안 사고나 대규모 장애 상황에서는, 평소에 잘 꾸며둔 디지털 커맨드 센터는 순식간에 사라질 수 있다. 하지만 고객은 여전히 “이 사람들이 뭘 하는지 알고 있다”라는 느낌을 기대한다.

왜 굳이 제로‑툴 훈련을 설계해야 할까?

대부분의 조직은 의도치 않게 “모든 게 완벽하게 동작하는 상황”에 최적화되어 있다. 인시던트 대응도 보통 이런 환경에서 연습된다.

완전한 모니터링과 대시보드
실시간 채팅 채널
자동 생성되는 인시던트 티켓과 라우팅
런북과 봇이 결합된 자동화된 워크플로우

물론 이것들은 모두 가치 있다. 하지만 **도구가 보강하는 대응(tool‑augmented response)**과 **도구 없이도 가능한 대응(tool‑independent response)**은 전혀 다른 이야기다. 도구가 사라지는 순간 팀은 종종 이런 문제를 처음 마주하게 된다.

실제로 누가 인시던트 레벨(심각도)을 선언하는지 아무도 모른다
연락처 정보가 전부 클라우드 기반 시스템 안에만 있고, 그 시스템이 다운돼 있다
평소에는 인시던트 봇이 역할을 지정해 주는데, 그게 없으니 역할과 책임이 애매하다
한 화면에서 모두가 같은 데이터를 볼 수 없어서 의사결정이 지연된다

제로‑툴 훈련은 이런 취약점을 실제 재난이 터지기 전에 드러나게 해준다.

아날로그 준비태세: 펜과 종이가 아직도 중요한 이유

대형 보안 사고나 광범위한 장애가 발생하면, 대응은 놀라울 정도로 단순한 도구들로 되돌아가곤 한다.

펜과 종이 노트: 로그와 타임라인 기록용
포스트잇: 태스크, 담당자, 우선순위 표시용
화이트보드나 플립 차트: 공통 상황 인식(Shared Situational Awareness)을 위한 시각화 도구
출력된 연락망(contact tree)과 조직도: 에스컬레이션 및 연락용
인쇄된 런북과 플레이북: 핵심 절차 수행용

이 아날로그 층위는 구시대의 유물이 아니다. 오히려 의도적인 **세이프티 넷(safety net)**이다. 디지털 도구는 증폭기 같은 존재다. 좋은 프로세스를 더 좋게 만들기도 하고, 나쁜 프로세스를 더 혼란스럽게 만들기도 한다. 하지만 그 도구들이 사라지면 남는 건 결국 “밑바탕 프로세스”뿐이다.

프로세스가 도구 안에만 존재한다면, 사실 당신에게 있는 건 프로세스가 아니라 도구에 대한 의존성일 뿐이다.

핵심 개념: 수동(Manual)이 먼저, 자동화는 그 다음

제로‑툴 훈련은 아주 단순한 질문을 정면으로 묻게 만든다.

“모든 자동화가 사라져도, 우리는 어떻게 여전히 괜찮은 인시던트 대응을 해낼 수 있을까?”

이 질문은 곧 세 가지 설계 원칙으로 이어진다.

사전에 정의된 수동 프로세스
전화와 종이만 있어도 수행할 수 있는, 명확한 단계별 절차
저기술(Lo‑Tech) 기반 실행
출력해서 오프라인으로 사용 가능한 런북, 체크리스트, 연락망
몸에 밸 때까지 연습
봇이 침묵해도 굳어버리지 않도록, 정기적인 훈련을 통한 근육기억 형성

그 뒤에 자동화를 덧입히는 것이다. 탄탄한 수동 뼈대 위에 자동화를 쌓는 것이지, 자동화로 프로세스를 대체해서는 안 된다.

SRE에서 빌려오기: 도구를 뺀 역할과 의식(Ritual)

Site Reliability Engineering(SRE)과 현대 인시던트 관리 체계는 이미 검증된 구조를 제공한다. 역할, 의식(ritual), 플레이북이다. 이 패턴들을 그대로 오프라인 훈련에 가져올 수 있다.

최소한 다음 역할들을 중심으로 제로‑툴 인시던트를 설계해보자.

Incident Commander(IC, 인시던트 커맨더)
전체 대응을 책임지고, 우선순위를 정하며, 시간을 관리하고, 최종 결정을 내린다.
Operations / Tech Lead(운영/기술 리드)
여러 시스템에 걸친 진단과 복구 작업을 조율한다.
Communications Lead(커뮤니케이션 리드)
이해관계자, 경영진, 그리고 필요하다면 고객에게까지 상황을 전달한다.
Scribe / Timeline Owner(서기 / 타임라인 담당)
사건의 흐름, 의사결정, 실행된 조치를 시간 순서대로 기록한다.

일상적인 인시던트에서는 이 역할들이 부분적으로 자동화되어 있거나, 채팅 내에서 느슨하게 지정되곤 한다. 제로‑툴 훈련에서는 의도적으로 아날로그 수단만으로 역할을 명시하고, 필요하면 교대까지 해본다.

오프라인이어도 반드시 유지해야 할 의식(ritual)은 다음과 같다.

첫 5분: 역할을 확정하고, 인시던트가 무엇인지 정의하며, 즉각적인 목표를 설정한다.
정기적인 상태 점검(huddle): 10~15분마다 모여 현재 상태를 정리하고, 우선순위를 재조정한다.
명시적인 의사결정 기록: 주요 결정과 그 근거를 화이트보드나 물리적인 로그에 써두기.
명확한 종료 조건: 무엇을 “안정화(stabilized)”로 볼지 정의하고, 누가 그 종료를 선언할지 정해둔다.

이걸 도구 없이도 일관되게 수행할 수 있다면, 도구가 망가졌을 때도 훨씬 덜 취약하다.

첫 번째 제로‑툴 훈련 설계하기

처음부터 세상이 멸망하는 수준의 시나리오가 필요하지는 않다. 중요한 건 아무도 평소의 툴링에 의존할 수 없다는 규칙이다.

1. 제약 조건 정의하기

우선 게임의 룰을 정한다.

Slack, Teams 같은 채팅 도구 금지
화상회의 도구 금지
인시던트 관리 플랫폼 / 봇 사용 금지
훈련 중 티켓 시스템 사용 금지
프로덕션 대시보드 접근은 제한하거나, 제한 상황을 시뮬레이션하기

현실적으로 여전히 쓸 수 있을 법한 통신 수단은 허용하자. 예를 들면:

전화 통화(모바일, 유선)
SMS 문자
대면 커뮤니케이션(직접 모여 이야기하기)

2. 아날로그 툴킷 준비하기

훈련 전에 물리적인 도구들을 준비한다.

출력된 인시던트 역할 및 책임 정의서
종이 타임라인 템플릿 (시각, 이벤트, 수행자 기록용)
출력된 연락망(contact tree) (온콜 엔지니어, 리더, 벤더 연락처)
흔하게 발생하는 장애 시나리오에 대한 인쇄된 런북
화이트보드/플립 차트, 마커, 포스트잇

원칙은 단순하다. 대형 인시던트에서 정말 중요하다면, 반드시 출력 가능한 형태가 있어야 한다.

3. 시나리오 선택하기

현실적이고, 중요도가 높은 문제를 하나 고른다. 예를 들면:

광범위한 인증(Authentication) 장애
DNS 설정 오류로 인한 외부 접속 불가
클라우드 제공 사업자의 특정 리전에 대규모 성능 저하 발생
핵심 환경에서 랜섬웨어가 탐지된 상황

첫 훈련이라면 기술적인 난이도는 다소 단순하게 잡고, 대신 조율(협업) 측면의 난이도에 초점을 맞추는 편이 좋다.

4. 진짜 페이저 스톰처럼 운영하기

혼란을 적극적으로 시뮬레이션해보자.

사전에 합의한 범위 안에서, 실제 페이저 알람처럼 훈련을 트리거한다
초기 역할(IC, Tech Lead, Comms Lead, Scribe)을 바로 지정한다
주요 커뮤니케이션 수단으로 전화와 대면 상태 회의를 활용한다
실행한 조치와 현재 상태를 화이트보드와 물리 로그에 남긴다
시간 압박과 상충되는 우선순위를 일부러 만들어본다

그리고 중요한 규칙: **“치팅 금지”**다. 누군가가 “잠깐만, Slack으로 이것만 물어보고 올게요”라고 하면, 슬랙이 다운된 것으로 간주하라.

5. 가차 없는 회고(Debrief) 진행하기

훈련이 끝나자마자, 구조화된 회고를 진행한다. 특히 다음을 살펴본다.

어디에서 커뮤니케이션이 끊겼는가?
어떤 결정이 지연되었는가, 그리고 그 이유는 무엇이었는가?
모두가 연락처와 런북이 어디 있는지 알고 있었는가?
역할이 충분히 명확했는가? IC는 과부하 상태였거나, 지원이 부족하다고 느끼지 않았는가?
모두가 있었으면 좋겠다고 느낀 정보는 무엇이었고, 왜 접근이 안 되었는가?

이 결과를 구체적인 후속 조치로 옮기자.

새로운 혹은 개선된 인쇄형 런북
업데이트된 연락망과 에스컬레이션 경로
정리된 역할 정의와 백업 담당자
“첫 15분에 할 일”, “올클리어(all‑clear) 선언 체크리스트” 같은 체크리스트 작성

미로를 반복해서 걷기: 근육 기억 만들기

단 한 번의 제로‑툴 훈련은 좋은 경각심(wake‑up call)이 된다. 하지만 여러 번 반복된 훈련은 진짜 근육을 만들어 준다.

이 훈련들을 정규 운영 관행의 일부로 포함하자.

주요 팀마다 분기별 제로‑툴 미니 훈련 1회 이상
연 1회 이상 크로스 펑셔널(여러 조직이 함께 참여하는) 대형 훈련
인시던트 커맨더 역할을 여러 사람에게 순환 배정
시나리오를 다양화: 보안 사고, 벤더 장애, 내부 변경 작업 실패 등

시간이 지날수록 다음과 같은 변화가 나타난다.

역할 배정이 더 빨라지고, 자신감 있게 이루어진다
도구가 있을 때조차 커뮤니케이션이 더 깔끔하고 구조적으로 변한다
팀이 즉흥 대응보다 체크리스트와 플레이북을 먼저 찾는 습관을 갖게 된다
“수동 기준선”을 이해하게 되면서 자동화를 더 신중하고 현명하게 설계한다

목표는 반(反)‑도구주의가 아니다. 도구가 **선택 가능한 가속기(optional accelerator)**가 되게 하고, 결코 **단일 실패 지점(single point of failure)**이 되지 않게 만드는 것이다.

자동화와 튼튼한 수동 폴백(Fallback)의 결합

몇 차례 제로‑툴 훈련을 하고 나면, 아마 디지털 툴링도 일부 재설계하게 될 것이다.

중요한 정보를 인쇄 가능한 서머리로 동시에 보여주는 인시던트 봇
오프라인에서도 쓸 수 있는 연락망과 역할 목록을 내보내기(export) 쉬운 티켓 시스템
주기적으로 스냅샷(PDF 등)으로 내보낼 수 있는 대시보드
런북의 첫 머리에 “매뉴얼 모드(manual mode)” 섹션을 두어, 플랫폼이 죽었을 때 할 일을 명시하기

이 지점이 바로 스위트 스폿(sweet spot)이다.

모든 것이 정상일 때는 속도와 규모를 보장해 주는 자동화된 기능들
그 기능들이 사라져도 버틸 수 있는 탄탄한 수동 폴백

회복탄력성 높은 운영은 도구가 항상 있을 것이라 가정하지 않는다. 오히려 그 반대를 가정하고, 그 전제에서부터 설계를 시작한다.

결론: 일부러 길을 잃어봐야, 진짜 길을 안다

“연필과 포스트잇의 인시던트 미로”는 최악의 상상 시나리오가 아니다. 심각한 장애나 보안 사고가 터지면, 실제로 그 모드로 들어갈 가능성이 충분히 있다.

제로‑툴 훈련을 설계하고 실행하는 일은, 그 특정 상황만을 준비하는 게 아니다. 이 훈련은 다음을 가능하게 한다.

도구에 숨어 있던 숨은 의존성을 드러낸다
역할과 의사결정 구조를 더 명확하게 만든다
프로세스를 강화해, 그 위에 올라가는 자동화의 기반을 단단히 다진다
“모든 게 꺼진 어둠 속에서도 우리는 움직일 수 있다”라는 자신감을 팀에 심어준다

다음 분기 계획을 세울 때, 반짝이는 대시보드와 바쁘게 움직이는 봇이 있는, 평범한 인시던트 리허설만 또 하나 잡고 끝내지 말자. 적어도 한 번은 아날로그‑전용 페이저 스톰을 일정에 넣어보라.

연필과 포스트잇만 들고 미로를 걸어보는 연습을 하라. 그래야 진짜 폭풍이 닥쳤을 때, 이미 어디로 나가야 할지 알고 있을 것이다.