아날로그 인시던트 종이 극장 발코니: 하이테크 스택 위에 세우는 로우테크 런북 무대

대형 인시던트가 터졌을 때 문제는 대개 툴이나 데이터가 부족해서가 아닙니다. 진짜 문제는 조율(coordination) 입니다.

Slack 채널은 불이 나 있고, 대시보드는 깜빡이고, 알람은 쉴 새 없이 울리는데도 현실은 이렇습니다.

누가 총괄 책임자인지 아무도 모른다.
팀들이 일을 중복해서 하거나, 인수인계가 빠진다.
리더십은 10분마다 상태를 물어본다.
어떤 결정이 이미 내려졌는지 아무도 확신하지 못한다.

즉, 소프트웨어 시스템 위에서 돌아가는 사람들의 시스템이 실패하고 있는 상태입니다.

여기서 의외로 효과적인 해법 하나가 있습니다. 아주 로우테크한 접근법입니다. 바로 아날로그 ‘종이 극장(paper theater)’ 발코니를 인시던트 대응에 도입하는 것입니다.

생각해보면 이렇습니다. 벽, 화이트보드, 대형 출력물 위에 시나리오 기반의 대형, 가시적인 런북을 만들어두고, 그걸 마치 연극 대본처럼 인시던트 전체를 오케스트레이션하는 겁니다. 역할, 장면, 큐(cue), 의사결정까지 모두 포함한 **“무대 연출표”**가 하이테크 스택 위에서 돌아가는 셈이죠.

이 글에서는 이러한 아날로그 인시던트 런북을 어떻게 설계하고 활용해 팀을 정렬시키고 혼선을 줄이며, 기존 대시보드와 자동화를 어떻게 보완할 수 있는지 살펴봅니다.

왜 하이테크 스택 위에 ‘종이 극장’을 올려야 할까?

디지털 도구는 강력하지만, 인시던트 상황에서는 두 가지 큰 약점이 있습니다.

파편화되어 있다. 모니터링, 티켓 시스템, 페이징, 채팅, 대시보드는 모두 서로 다른 시스템에 흩어져 있다.
몰입형이다. 모두가 각자 화면에 빨려들어 가면서, 큰 그림을 놓친다.

종이 극장 발코니는 다음을 한눈에 보여주는, 눈에 잘 보이고 모두가 공유하는 표현 수단입니다.

지금 우리가 어떤 시나리오에 있는지
대응의 어느 단계에 와 있는지
지금 누가 무엇을 하고 있는지
어떤 결정이 이미 내려졌고, 어떤 결정이 보류 중인지

이것이 물리적이고 중앙에 모여 있기 때문에, 인시던트 동안 사실상 단일 소스 오브 트루스(single source of truth)가 됩니다. 워룸에 모여 있든, 화이트보드를 비추는 카메라가 켜진 화상 회의 중이든, 모두가 동일한 이야기가 전개되는 것을 함께 볼 수 있습니다.

하이테크 도구를 대체하는 것이 아닙니다. 그 도구들을 무대 위에 올려 ‘연출’하고, 사람들이 그 도구를 어떻게 쓰는지 조율하는 것입니다.

표준화된 시나리오 기반 인시던트 플레이북

즉흥적인 체크리스트로는 위기 상황을 버티기 어렵습니다. 실제로 마주치는 인시던트 유형에 정확히 매핑되는 명확한 시나리오 기반 플레이북이 필요합니다.

예시 시나리오:

"코어 API에서 심각한 레이턴시 스파이크 발생"
"프라이머리 데이터베이스에서 부분 데이터 손실 발생"
"광범위한 인증 실패 발생"
"서드파티 의존성 서비스 장애"

각 시나리오 플레이북은 다음 네 가지 질문에 답해야 합니다.

이 플레이북은 언제 트리거되는가?
- 어떤 증상이나 알람이 발생하면 이 시나리오라고 볼 수 있는가?
목표는 무엇인가?
- 예: "데이터 무결성을 유지하면서 API p95 레이턴시를 500ms 미만으로 복구한다."
단계(phase)는 어떻게 나뉘는가?
- 탐지 및 트리아지(Detection & triage)
- 격리 및 완화(Containment & mitigation)
- 복구 및 검증(Recovery & validation)
- 포스트 인시던트 리뷰 준비(Post-incident review prep)
각 단계별 핵심 액션은 무엇인가?
- 모호한 의도가 아니라, 구체적인 실행 단계여야 합니다.

아날로그 보드나 출력물에서는 이것이 세로 혹은 가로로 뻗은 타임라인 형태로 표현됩니다. 각 단계가 나열되고, 각 역할/팀별로 컬럼이나 스윔레인(swimlane)을 분리해 표시할 수 있습니다.

이런 표준화는 MTTA(Mean Time to Acknowledge, 인지까지 소요 시간) 와 MTTR(Mean Time to Resolve, 복구까지 소요 시간) 개선으로 직결됩니다. 이유는 단순합니다.

무엇을 먼저 할지 가지고 논쟁하지 않는다.
신규 대응자도 “대본(script)”을 보고 곧바로 참여할 수 있다.
스트레스가 최고조일 때 인지적 부담(cognitive load)을 줄여준다.

모니터링·지능형 알림과 런북을 강하게 연결하기

언제 커튼을 올려야 할지 모른다면, 종이 극장은 아무 의미가 없습니다.

런북은 다음과 강하게 연동되어야 합니다.

가용성, 레이턴시, 에러, 포화도, 핵심 비즈니스 지표까지 아우르는 종합 모니터링
단순 노이즈가 아니라 실제 영향도와 SLO(Service Level Objective)에 기반해 트리거되는 지능형 알림 임계값

각 시나리오 기반 런북에는 “탐지(Detection)” 블록을 명시적으로 포함해야 합니다.

주요 시그널: 가장 먼저 확인해야 할 대시보드, 메트릭, 로그는 무엇인가?
알림 소스: PagerDuty / VictorOps / 기타 어떤 채널에서 인시던트가 시작되는가?
진입 조건: 이 플레이북을 시작해야 함을 의미하는 정확한 임계값이나 패턴은 무엇인가?

예시(런북 내 표기):

트리거: /checkout 엔드포인트 p95 레이턴시 > 2초 상태가 5분 이상 지속, 에러율 > 2%, SLO 번 레이트(burn rate) > 4배.

진행: API 레이턴시 스파이크 플레이북, 1단계(탐지 & 트리아지)로 이동.

이렇게 런북 페이지 안에 조건을 직접 박아두면, 오브저버빌리티(observability) 와 행동(action) 이 자연스럽게 연결됩니다.

“이 정도면 심각한가?” 같은 질문으로 시간을 낭비하지 않습니다. 이미 임계값과 판단 기준이 합의되어 있기 때문입니다.

런북 안에 에스컬레이션 경로와 의사결정 트리를 녹여 넣기

인시던트 상황에서 모호함은 시간을 갉아먹습니다.

롤백 승인은 누가 해줄 수 있는가?
언제 세컨더리 리전으로 페일오버 해야 하는가?
고객 커뮤니케이션은 누가, 언제 시작해야 하는가?

종이 극장은 이런 내용을 에스컬레이션 경로와 의사결정 트리로 명확하게 드러내야 합니다.

에스컬레이션 경로

다음 내용을 시각적으로 보여줍니다.

누가 인시던트 커맨더(Incident Commander) 인가
누가 테크니컬 리드(Technical Lead) 인가
커뮤니케이션(내부/외부) 담당은 누구인가
언제, 어떻게 다음으로 에스컬레이션하는가:
- 다른 팀 온콜
- 시니어 엔지니어링 리더십
- 컴플라이언스 또는 보안 팀
- 고객 지원 및 어카운트 매니지먼트

이는 보드 한쪽에 간단한 플로우차트로도 표현할 수 있습니다.

Sev-1 인시던트가 30분 이상 지속 → 엔지니어링 디렉터 온콜 호출.

데이터 노출 가능성이 의심됨 → 즉시 보안 온콜(Security On-Call) 통보.

의사결정 트리

주요 의사결정마다 짧고 굵은 if/then 흐름을 넣습니다.

If 프라이머리 데이터베이스 쓰기 성능은 저하되었지만 읽기는 정상이라면 → 읽기 전용(read-only) 모드 전환을 고려.
If 에러율이 서드파티 의존성에 의해 발생한다면 → 기능 플래그(feature flag)를 이용해 강등(degraded) 경험으로 페일오버.

이때 화살표, 박스, 색상 등을 적극 활용해 눈에 확 들어오게 만드세요. 실제 상황에서는, 사람들이 그 부분을 손가락으로 가리키며 논의하고 몇 초 안에 정렬될 수 있어야 합니다.

런북을 ‘살아있는 문서’로 만들기: 서랍 속 문서 되지 않게 하기

런북의 가장 큰 실패 패턴은, 쓰는 순간부터 구식이 되어버린다는 점입니다.

이를 피하려면 인시던트 런북을 살아 있는 문서(living document) 로 다루고, 크고 작은 인시던트 및 유의미한 니어미스(near-miss) 이후마다 진화시켜야 합니다.

간단한 사이클을 만드세요.

인시던트 중 실제로 플레이북을 사용한다.
현실을 종이에 직접 표시한다.
- 건너뛴 단계는 과감히 취소선으로 지운다.
- 즉흥적으로 대응한 부분에는 메모를 남긴다.
- 시간, 병목, 장애물 등을 간단히 기록한다.
포스트 인시던트 리뷰에서 런북을 업데이트한다.
- 실제로 효과적이었던 것에 맞춰 단계, 액션, 의사결정 포인트를 조정한다.
다시 출력/다시 그려서 공유한다.
- 업데이트된 보드를 사진이나 GIF로 공유해 전파한다.

목표는 런북을 무시하는 것보다 수정하는 게 더 쉽도록 만드는 것입니다. 시간이 지날수록 런북은 조직의 집단 기억과 회복력(resilience) 을 간결하게 정리한 산출물이 됩니다.

종이 극장에 SRE 원칙을 녹여 넣기

좋은 인시던트 런북은 단순 체크리스트가 아니라, SRE(Site Reliability Engineering) 원칙을 운영 수준으로 구현한 것입니다.

런북을 설계·유지할 때 다음 SRE 원칙을 자연스럽게 녹여 넣으세요.

1. 신뢰성(Reliability)

각 액션을 SLO(Service Level Objective) 와 직접 연결합니다. 예: 업타임, 레이턴시, 에러 버짓(error budget) 등.
완화(mitigation) 단계에서는 인프라를 깔끔하게 만드는 것보다 사용자 영향 최소화를 우선합니다.

2. 오브저버빌리티(Observability)

각 단계마다 무엇을 측정해야 하고, 어디를 봐야 하며, 성공 상태는 무엇인지를 명시합니다.
인시던트를 종료하기 전, 간단한 “최종 sanity check”를 추가합니다. 예: 주요 대시보드, 로그, 트레이스 확인.

3. 성능과 트레이드오프(Performance & Tradeoffs)

의도된 트레이드오프를 명시적으로 문서화합니다.
- "데이터 무결성을 지키기 위해 레이턴시 증가를 허용한다."
- "완전 다운타임보다 읽기 전용 모드를 선호한다."
이를 눈에 잘 띄게 표시해, 인시던트 커맨더가 빠르고 정렬된 결정을 내릴 수 있게 합니다.

이런 원칙을 녹여두면, 아날로그 극장은 고압 상황에서 방향을 잃지 않게 해주는 신뢰성 나침반(reliability compass) 역할을 하게 됩니다.

발코니 뷰: 대시보드를 대체하는 것이 아니라 보완한다

대시보드는 오케스트라 피트(관현악단 자리)를 세밀하게 보여줍니다. 종이 극장은 그와 별개로 발코니에서 내려다보는 시야를 제공합니다.

발코니에서 보이는 것은 다음과 같습니다.

어떤 시스템이 장애(또는 성능 저하) 상태인지 그리고 어떤 팀들이 관여 중인지
인시던트 대응이 지금 어느 단계에 와 있는지
무엇이 막혀 있고, 무엇이 진행 중인지
이번 인시던트의 더 큰 비즈니스 문맥

아날로그 보드에서는 예를 들어 이런 식으로 시각화할 수 있습니다.

시스템과 서비스: 왼쪽에 박스 형태로 나열
팀과 역할: 행(row)이나 레인(lane)으로 구분
인시던트 단계: 컬럼(column) 또는 섹션으로 분리
진행 중인 태스크와 담당자: 포스트잇, 자석, 카드 등으로 표시

이것은 대시보드를 다음과 같이 보완합니다.

대시보드: "시스템이 지금 무엇을 하고 있는가?"
종이 극장: "우리는, 인간은 지금 그것에 대해 무엇을 하고 있는가?"

리더와 이해관계자는 엔지니어를 방해하지 않고도 보드를 힐끗 보는 것만으로 상황을 파악할 수 있습니다. 엔지니어는 로그에서 눈을 떼 잠깐만 위를 올려다봐도 자신의 일이 전체 대응 안에서 어떤 위치에 있는지 알 수 있습니다.

실전 적용: 간단한 시작 레시피

거창한 프로세스 개편 없이도 시작할 수 있습니다. 다음을 시도해 보세요.

자주 발생하는 Sev-1 또는 Sev-2 인시던트 시나리오 2~3개를 고른다.
각 시나리오에 대해 단계, 핵심 액션, 의사결정 포인트가 포함된 단순한 시나리오 기반 런북을 작성한다.
이를 크게 출력하거나, 화이트보드 템플릿으로 그려둔다.
다음 인시던트 때 종이 극장을 실제로 써서 운영해 본다. (한 명의 퍼실리테이터가 보드를 업데이트하는 것만으로도 충분하다.)
인시던트마다 리뷰하고 개선한다.

몇 번의 사이클만 돌려도, 아날로그 발코니는 팀의 자연스러운 대응 방식의 일부가 됩니다. 혼선은 줄고, 역할은 더 명확해지고, 의사결정은 훨씬 빨라질 것입니다.

결론: 로우테크지만 레버리지는 높다

복잡한 하이테크 환경에서 인시던트 대응의 병목은 대개 툴링이 아니라, 조율·명확성·공유 컨텍스트입니다.

눈에 보이는 로우테크 종이 극장 발코니—시나리오 기반 런북에 에스컬레이션 경로, 의사결정 트리, SRE 원칙을 녹여 둔 형태—는 다음을 가능하게 합니다.

혼란과 결정 번복(decision thrash)을 줄인다.
MTTA와 MTTR을 개선한다.
모두에게 공유된, 시스템 전반을 아우르는 시야를 제공한다.
실제 인시던트를 통해 얻은 교훈을 살아 있는 문서로 남겨 조직의 회복력을 키운다.

이미 대시보드, 오브저버빌리티, 알림 시스템에 많은 투자를 하고 있을 것입니다. 이제 사람들에게도 그에 못지않은 도구를 제공해야 합니다. 각자 대사만 보는 것이 아니라, 전체 연극을 한눈에 볼 수 있는 무대 말입니다.

다음 대형 인시던트가 터졌을 때, 하이테크 스택이 하는 일은 예전과 크게 다르지 않을 수 있습니다. 하지만 발코니에서 내려다본 당신의 대응 모습은 완전히 달라져 있을 것입니다.