아날로그 인시던트 팬트리: 다음 신뢰성 기근 전에 종이 의식을 비축하는 법

실제 프로덕션 인시던트가 터지면, 상황은 대시보드와 도구들이 가정하던 모습과 전혀 다르게 흘러가는 경우가 많습니다. 네트워크는 파티션 나고, 아이덴티티 프로바이더는 다운되고, 노트북은 VPN에 접속하지 못하고, 애써 만들어 둔 아름다운 클라우드 호스팅 런북(runbook)은 순식간에 접근 불가가 됩니다.

바로 그때, 여러분이 **아날로그 인시던트 팬트리(analog incident pantry)**를 잘 비축해 두었는지 드러납니다. 모든 게 불타고 있을 때 손에 집어 들 수 있는, 종이로 된 의식(ritual), 플레이북, 체크리스트의 선반 말입니다.

이 글에서는 Site Reliability Engineering(SRE) 관점, 테이블탑(tabletop) 연습, 종이 기반 플레이북이 어떻게 실용적인 로우테크 안전망으로 결합되는지 살펴봅니다. 무엇을 비축해야 하는지, 어떻게 연습해야 하는지, 그리고 다음 신뢰성 기근이 왔을 때 굶주리지 않도록 어떻게 신선하게 유지할지를 이야기합니다.

디지털 세상에서 왜 ‘아날로그 팬트리’가 중요한가

대부분의 조직은 **행복 경로(happy path)**에 과도하게 최적화되어 있습니다.

인시던트 도구는 대부분 SaaS 기반이며 인터넷 상태가 멀쩡하다고 가정합니다.
문서는 단일 위키나 SSO 뒤에 있는 지식 베이스에만 존재합니다.
알림 라우팅은 채팅, 이메일, 단일 페이징(provider)에 의존합니다.

하지만 심각한 인시던트는 여러분의 도구가 의존하는 가정을 종종 깨뜨립니다. 예를 들면:

위키, 티켓 시스템, 채팅에 대한 접근 상실
주요 플랫폼 로그인 자체를 막아버리는 인증 장애
핵심 팀이나 서비스가 고립되는 네트워크 장애
부분적인 데이터 손실이나 손상된 대시보드

이런 혼란 속에서 팀은 즉흥 대응으로 되돌아갑니다. “지금 이걸 누가 총괄하는 거지? 먼저 뭘 해야 하지? 고객에게는 누가 말하지? 롤백 승인 누가 해 줄 수 있지?”

SRE 문화는 다른 입장을 취합니다. 인시던트가 터진 후에 인시던트 프로세스를 만들어내지 않는다는 것입니다. 미리 설계하고, 미리 연습합니다. 그리고 그 설계에는 의도적으로 종이 기반 가이드로의 폴백(fallback) — 바로 ‘아날로그 팬트리’가 포함됩니다.

아날로그 인시던트 팬트리의 핵심 구성요소

아날로그 팬트리는 단순히 위키 페이지 몇 장을 프린트한 것이 아닙니다. 디지털 환경이 심각하게 저하되었을 때도 조직이 기능을 유지하도록 도와주는, **의식(ritual), 역할(role), 런북(runbook)**의 최소·정선된 모음입니다.

최소한 다음은 비축해야 합니다.

1. 공통 시나리오용 종이 플레이북

깊이 있는 기술 문서일 필요는 없습니다. 특히 첫 15–30분 동안 무엇을 어떤 순서로 할지에 집중해야 합니다.

예시:

메이저 인시던트 개시 체크리스트
- 인시던트 선언 및 역할 지정
- 타임라인 시작(화이트보드, 노트, 혹은 인쇄된 양식 사용)
- 커뮤니케이션 채널 확인(전화 브릿지, SMS 트리 등)
주요 커뮤니케이션 도구 상실 (채팅 또는 이메일 장애)
- 백업 채널(전화 브릿지 번호, SMS 제공업체, 백업 채팅 도구)로 전환하는 방법
- 누가 전환을 트리거하고, 이를 어떻게 알릴지
인증/SSO 장애
- 어떤 비상 계정이 존재하는지, 그리고 어떻게 접근할 수 있는지
- 자격 증명(credential)의 물리적 사본을 누가 가지고 있고, 어디에 보관되는지
데이터센터 또는 리전(region) 장애
- 트래픽 페일오버 혹은 성능 저하 운영의 고수준 계획
- 비즈니스 관점 의사결정: 핵심 플로우를 지키기 위해 무엇을 내려도 되는지

각 플레이북은 1–2페이지 내에 들어가야 하며, 압박감이 큰 상황에서도 누구나 읽기 쉽게 작성되어야 합니다.

2. 명확히 정의된 역할과 책임

효과적인 인시던트 대응은 개인의 영웅적 활약보다 역할 체계에 훨씬 더 의존합니다.

종이 문서로 다음을 정리해 두세요.

인시던트 커맨더(Incident Commander, IC) — 기술적 의사결정이 아닌, 전체 조정·진행 책임
오퍼레이션 리드 / 테크 리드 — 기술적인 분석과 변경 작업을 이끄는 역할
커뮤니케이션 리드 — 내부·외부 커뮤니케이션 전반 책임
고객/비즈니스 담당자(Liaison) — 세일즈, 고객지원, 리더십과의 조율
스크라이브(Scribe) — 이벤트·결정·액션의 타임라인 기록

각 역할마다 다음을 명시합니다.

주요 책임
에스컬레이션 경로
백업 담당 가능자

이렇게 해 두면 혼란스러운 상황에서도 사람들이 자신 있게 역할을 맡을 수 있습니다.

3. 연락 트리와 에스컬레이션 맵

이 부분은 “그때 가서 하면 되겠지” 했다가 실제 상황에서 재구성하는 데 생각보다 훨씬 큰 고통을 겪는 영역입니다.

종이 문서로 다음을 보관하세요.

온콜(on-call) 로테이션과 1차/2차 담당 엔지니어(대략적이어도 괜찮음)
각 핵심 기능별 전화번호 및 백업 연락 수단:
- SRE/DevOps/인프라 팀
- 핵심 애플리케이션 팀들
- 고객지원 및 인시던트 매니저
- 법무·컴플라이언스
- PR/커뮤니케이션
- 외부 인시던트 대응 업체

가능하면 **개인 이름보다 기능(팀/역할)**을 중심으로 구성하되, 각 기능별로 최소 한 명 이상의 실제 연락처는 반드시 포함하세요.

4. 사전 승인된 커뮤니케이션 템플릿

메이저 인시던트 중에 상태 공지를 다듬는 데 쓰는 1분 1분이, 실제로는 문제를 고치거나 트라이애지하는 데 쓰였어야 할 시간입니다.

다음 항목들을 위한 템플릿을 인쇄해 두세요.

사내 전체 인시던트 알림
고객 대상 상태 페이지(Status Page) 업데이트
중요 고객 또는 규제 기관에 대한 최초 응답

그리고 각 템플릿은 빈칸 채우기 형식으로 만듭니다.

현재 **[서비스/리전]**에 영향을 주는 [증상] 이슈를 **[시간, 타임존]**부터 조사 중입니다. 저희 팀은 근본 원인 파악 및 영향 완화를 위해 대응하고 있습니다. 새로운 정보가 확인되는 대로 늦어도 **[시간]**까지 추가 업데이트를 제공드리겠습니다.

이 템플릿들을 사전에 법무, PR, 리더십과 함께 검토해두면, 실제 상황에서 마찰과 리스크가 크게 줄어듭니다.

테이블탑 연습: 기근이 오기 전에 팬트리 가지고 ‘요리’해 보기

종이 의식들을 선반에 쌓아 두는 것만으로는 충분하지 않습니다. 실제로 써 보는 연습이 필요합니다.

테이블탑(tabletop) 연습은 구조화된 저위험 시뮬레이션으로, 사람들이 가상의 인시던트에 어떻게 대응할지 말로 풀어가며 연습하는 방식입니다. 프로덕션 변경도, 실제 고객 영향도 없습니다. 오직 집중된 리허설만 있을 뿐입니다.

누가 테이블에 앉아야 하는가

현실적이고 유용한 연습을 위해서는 핵심 이해관계자들이 모두 함께 참여해야 합니다.

기술 팀 (SRE, 개발, 플랫폼, 보안팀 등)
고객·매출 영향에 민감한 비즈니스 및 프로덕트 오너
규제·데이터 이슈를 담당하는 법무·컴플라이언스
내부·외부 메시지를 담당하는 커뮤니케이션/PR
인시던트 시 의존하는 외부 인시던트 대응 업체나 파트너

이 그룹들이 한 팀으로 연습해 보면, 실제로 큰 피해를 부르기 전에 서로 다른 가정과 관점의 충돌을 미리 발견할 수 있습니다.

효과적인 테이블탑을 운영하는 방법

The Site Reliability Workbook과 업계 SRE 플레이북에서 차용하자면, 좋은 테이블탑 연습은 보통 다음 요소들을 갖습니다.

현실적인 시나리오
예: “글로벌하게 Auth 프로바이더가 다운되었고, 고객은 로그인할 수 없으며, 대시보드는 지연되고 있지만 상태 페이지는 아직 살아 있다.”
퍼실리테이터(facilitator)
시나리오를 단계별로 제시합니다. (“지금 10분이 지났습니다… 30분이 지났습니다…”) 그리고 환경을 흉내 내는 역할을 맡습니다.
역할 할당
IC, 커뮤니케이션 리드, 스크라이브 등을 지정합니다. 종이 플레이북에 정의된 역할 체계를 그대로 사용합니다.
물리적 아티팩트 활용
- 인쇄된 플레이북과 역할 정의를 나누어줍니다.
- 인시던트 타임라인은 화이트보드나 종이에 기록합니다.
- 도구 장애를 시뮬레이션합니다. “지금 Slack이 다운됐습니다. 어떻게 하시겠습니까?”
시간 제한과 명확한 종료 시점
보통 60–90분 정도 진행한 뒤, 종료하고 디브리핑(debrief)을 합니다.

목표는 시나리오에서 ‘승리’하는 것이 아닙니다. 실제 신뢰성 기근이 오기 전에, 커뮤니케이션의 빈틈, 불명확한 소유권, 깨진 가정을 드러내는 것이 목적입니다.

각 연습에서 배우기: 재비축과 신선도 유지

아날로그 팬트리는 다시 채우지 않으면 쉽게 낡아 버립니다. 각 테이블탑 연습은 종이 의식을 개선할 수 있는 기회입니다.

블레임리스(Blameless) 디브리핑 진행

각 연습 후에는 짧은 회고를 합니다.

우리를 가장 느리게 만든 건 무엇이었나?
어떤 결정이 모호하거나 논쟁적이었나?
어디에서 정보나 권한이 부족했나?
어떤 역할이 비어 있거나 과부하였나?
누가 플레이북을 무시했거나, 사용하기 어려웠다고 느꼈나?

개인의 성과가 아닌, 프로세스와 시스템 설계에 초점을 맞추세요.

문서화 및 업데이트

배운 점을 구체적인 변경 사항으로 옮깁니다.

체크리스트에 새로운 단계를 추가하거나 불필요한 항목 제거
역할 설명이 겹치거나 혼란스러웠던 부분을 명확히 정리
연락처 목록과 에스컬레이션 경로 업데이트
실제로 사용된 문구를 반영해 커뮤니케이션 템플릿 개선

그다음 업데이트된 문서를 다시 인쇄해서 필요한 위치에 재배포합니다. 팀 스페이스, 인시던트 룸, NOC 모니터 주변의 바인더 등입니다.

정기적인 드릴 일정화

테이블탑 연습을 소방 훈련처럼 다루세요.

정기 일정으로 진행합니다(분기 1회 정도가 일반적입니다).
시나리오를 다양화합니다: 보안 사고, 데이터 손실, 서드파티 장애, 리전 장애 등.
가끔은 주요 도구나 결정권자가 없는 최악의 상황도 시뮬레이션합니다.

시간이 지날수록 다음과 같은 변화를 보게 될 것입니다.

역할 인수인계가 매끄러워짐
더 빠르고 자신감 있는 의사결정
실제 인시던트에서의 ‘뜻밖의’ 상황 감소

이것이 곧 효과성입니다. 더 큰 장애가 와도, 비즈니스를 굶기지 않고 버텨낼 수 있습니다.

SRE 원칙과 다시 연결하기

여기까지 이야기한 모든 것은 SRE 정신과 정확히 맞닿아 있습니다.

장애를 전제로 설계하기: 도구, 네트워크, 사람은 가장 안 좋은 타이밍에 없을 수 있다고 가정합니다.
프로세스의 코드화: 즉흥 행동을 체크리스트, 역할 정의, 런북 같은 작성된 의식으로 바꿉니다.
연습 후 개선: 테이블탑 연습을 통제된 실험으로 사용해, 시스템(과 조직)이 어디서 취약한지 드러냅니다.
계획과 위기를 분리: 인시던트 한복판이 아니라, 그 전에 사려 깊은 설계를 끝내둡니다.

The Site Reliability Workbook 같은 자료는 인시던트 커맨드 구조, 커뮤니케이션 주기, 사후 인시던트 학습 방식에 대한 구체적인 패턴을 제공합니다. 디지털 세상이 말썽을 부릴 때, 여러분의 아날로그 팬트리는 그 아이디어들을 물리적으로 구현한 결과물입니다.

결론: 배가 고플 때 요리법을 배우지 마라

질문은 “우리 조직에 메이저 인시던트가 올까 말까”가 아닙니다. 언제 올지, 그리고 그때 준비가 되어 있을지입니다.

잘 갖춰진 아날로그 인시던트 팬트리는 여러분에게 다음을 제공합니다.

인지 부하가 극도로 높은 순간에도 따를 수 있는 명확한 역할과 체크리스트
도구나 접근 권한이 끊겼을 때 쓸 수 있는 안전한 폴백
법무, 비즈니스, 기술 이해관계자가 정렬될 수 있는 공통의 스크립트

여기에 정기적인 테이블탑 연습과 지속적인 개선을 더하면, 혼돈은 여러분이 이미 여러 번 돌려 본 드릴에 훨씬 가까운 모습이 됩니다.

다음 신뢰성 기근이 닥치기 전에 스스로에게 물어보세요.

평소 쓰는 도구가 전부 사라진다면, 우리 팀이 손에 쥘 수 있는 물리적인 가이드는 무엇인가?
전사적인 크로스 펑셔널 그룹이 한 번이라도 함께 대응 연습을 해 본 적이 있는가?
실제 경험을 반영해 인시던트 의식을 마지막으로 업데이트한 것이 언제인가?

이 질문들이 마음을 불편하게 만든다면, 지금이 바로 그 선반을 채우기 시작할 때입니다. 불이 꺼지기 전에, 종이와 프로세스, 그리고 연습으로 말입니다.