종이 런북 관측소: 실제로 ‘사건이 어떻게 끝나는지’를 보여주는 벽 전체 아날로그 지도 만들기

디지털 런북은 대체로 낙관적인 소설에 가깝습니다.

런북에는 incident(사건)이 어떻게 진행돼야 하는지가 단계별로 적혀 있습니다. 하지만 실제로 시스템에 불이 나면, 사람들은 즉흥적으로 움직이고, 어떤 단계는 건너뛰고, 새로운 단계를 만들어내며, 원래 다이어그램에는 없던 팀까지 끌어들입니다.

결과적으로, 공식 런북과 실제 incident 대응 행태는 서서히 서로 멀어지게 됩니다.

여기서 등장하는 것이 바로 **종이 런북 관측소(Paper Runbook Observatory)**입니다. 이건 벽 전체를 쓰는 아날로그 지도이자, incident가 실제로 어떻게 흐르는지 한눈에 보이게 해 주는 도구입니다. 거대한 플라이트 레코더(블랙박스)를 모두가 함께 보는 시각적 작업 공간으로 펼쳐 놓은 것에 가깝습니다. incident가 실제로 어떻게 시작되고, 누가 실제로 참여하며, 어떤 경로가 흔하고, 마지막은 어떻게 끝나는지를 보여줍니다.

이 글에서는 종이 런북 관측소를 설계하고 사용하는 방법, 대시보드 시대에도 물리적인 시각 관리가 여전히 중요한 이유, 그리고 이 접근이 어떻게 더 나은 디지털 런북, 더 나은 협업, 더 빠른 incident 복구로 이어지는지 살펴보겠습니다.

왜 벽 전체를 쓰는 ‘종이 런북’을 만들어야 할까?

디지털이 우선인 시대에 종이로 돌아가자는 얘기는 다소 역행처럼 들릴 수 있습니다. 이미 이런 것들이 있겠죠:

티켓 시스템
페이저/알림 시스템
채팅 로그
포스트모템
디지털 런북 도구들

그런데 왜 굳이 이 모든 걸 다시 종이로 끌어내서 벽에 붙여야 할까요?

이유는 단순합니다. 스프레드시트나 JSON 덩어리 속에서는 절대 못 보는 패턴이, 벽 전체를 쓰는 시각 정보 안에서는 보이기 때문입니다.

벽 전체를 쓰는 지도는 다음과 같은 특징이 있습니다.

맥락을 압축합니다: 수십 개 incident와 다양한 경로를 동시에 볼 수 있습니다.
우선순위를 강제합니다: 모든 디테일을 다 담을 수 없기 때문에, 핵심 흐름만 추려내야 합니다.
협업을 끌어냅니다: 사람들이 직접 걸어와서 가리키고, 토론하고, 메모를 덧붙이며 함께 배울 수 있습니다.
마찰을 드러냅니다: 병목, 루프, 어색한 핸드오프 같은 것들이 실제로 그려 놓으면 눈에 확 들어옵니다.

이건 반(反) 디지털이 아닙니다. 말 그대로 **관측소(Observatory)**입니다. incident 대응 시스템이 실제로 어떻게 행동하는지 한 발짝 물러나 관찰하고, 그 관찰 결과를 바탕으로 나머지 모든 것(디지털 도구 포함)을 개선하기 위한 장치입니다.

1단계: ‘이상적인’ 경로가 아니라 실제 incident 경로를 모으기

관측소의 출발점은 데이터입니다. 다만, 일반적으로 떠올리는 그 데이터는 아닙니다.

여기서 그릴 건 공식 런북에 적힌 의도된 프로세스가 아닙니다. 실제 최근 incident에서 실제로 밟았던 경로를 복원하는 것입니다.

활용할 수 있는 소스는 다음과 같습니다.

포스트모템: 타임라인, 채팅 로그, 주요 의사결정 지점, 에스컬레이션 기록
페이저/알림 이력: 누가, 어떤 순서로, 어떤 알림을 받았고, 어떤 효과가 있었는지
티켓 시스템: 담당자 변경, 우선순위 변경, 해결 절차
incident 리뷰 미팅: “사실은 X한테 바로 전화했어요” 같은 비공식 흐름

incident 하나당, 다음을 정리해 봅니다.

트리거/진입 지점(문제가 처음 감지된 계기)
최초 대응자와 소속 팀
주요 의사결정과 분기점
팀 간 에스컬레이션 또는 핸드오프
우회로(workaround)나 ‘그림자 프로세스’
incident가 실제로 끝난 방식(롤백, 패치, 피처 플래그, 핫픽스 등)

모든 마우스 클릭을 기록하려는 게 아닙니다. incident의 상태를 실제로 바꿨거나, 책임이 넘어간 의미 있는 단계(semantic step) 에 초점을 맞추세요.

2단계: 표준 시각 언어 사용하기 (예: BPMN)

그냥 박스랑 화살표를 막 그리기 시작하면, 금세 ‘아름답지만 알아보기 힘든’ 혼돈의 그림이 됩니다.

지도(맵)를 팀 간에 읽기 쉽고 일관되게 유지하려면, BPMN(Business Process Model and Notation) 같은 표준 표기법이나, 그걸 단순화한 버전을 쓰는 편이 좋습니다. 모든 기호를 다 쓸 필요는 없고, 중요한 범주만 구분 가능할 정도면 충분합니다.

가벼운 세트는 예를 들어 이렇게 구성할 수 있습니다.

둥근 사각형: 활동(예: "DB 진단 실행", "온콜 SRE에게 알림")
마름모: 의사결정(예: "에러율이 감소 중인가?", "롤백이 안전한가?")
원(circle): 시작/종료 지점(예: "사용자 불만 접수", "incident 종료")
수영 레인(Swimlane): 팀이나 역할(SRE, 앱 팀, 보안, 고객지원, 매니지먼트 등)
화살표 스타일:
- 실선 화살표: 정상 흐름
- 점선 화살표: 비공식/비정규 채널(예: "슬랙 DM으로 바로 연락")
- 빨간 화살표: 에스컬레이션이나 긴급 개입

지도 옆에는 반드시 범례(legend) 를 붙입니다. 누구든지 와서 바로 이해할 수 있어야 합니다.

지금 보고 있는 박스가 어떤 종류의 단계인지
어느 팀의 소유인지
incident가 어떻게 다른 팀이나 사람에게 넘어갔는지

표준 표기법을 사용하면, 벽은 그저 예쁜 그림이 아니라 운영에 대한 공유 언어가 됩니다.

3단계: 벽을 ‘incident 관측소’로 만들기

이제 본격적인 작업입니다. 지도를 만듭니다.

필요한 것들:

넓은 벽 공간(또는 여러 개의 화이트보드)
활동과 의사결정 단계를 적을 포스트잇 또는 인덱스 카드
단계 간 흐름을 표시할 색 테이프나 실
팀이나 심각도에 따라 색을 달리 사용

대표적인 레이아웃 두 가지가 있습니다.

1) 라이프사이클 단계 기준 레이아웃

벽을 가로 방향으로 incident 라이프사이클 단계별로 나눕니다. 예를 들면:

탐지(Detection)
트리아지(Triage)
진단(Diagnosis)
완화(Mitigation)
복구(Recovery)
후속 조치(Follow-up)

각 단계 안에, 실제 incident들에서 확인한 단계를 팀별 수영 레인 아래에 배치합니다. 그리고 incident 하나하나가 이 단계를 어떻게 거쳐 갔는지 화살표로 연결합니다.

2) incident 유형 기준 레이아웃

또는, 자주 발생하는 incident 유형별로 벽을 나눌 수도 있습니다.

성능 저하
장애/다운타임
보안 이벤트
데이터 무결성 문제
외부/의존성 장애

각 범주 안에, 해당 유형 incident 여러 건의 실제 흐름을 나란히 그려 놓습니다. 이렇게 하면, 예를 들어 보안 incident가 성능 incident와는 완전히 다른 패턴을 가진다는 점이 훨씬 쉽게 드러납니다.

시간이 지나고 incident가 추가될수록 이 벽은 진짜 관측소가 됩니다.

화살표가 두껍게 뭉치는 구간은 공통 경로임을 의미합니다.
드물지만 큰 피해를 준 경로는 특이한 가지(branch)로 눈에 띕니다.
incident가 자주 ‘막히는’ 지점은 주변이 유난히 복잡하거나 지나치게 연결되어 보입니다.

이제 여러분은, 압박 상황에서 시스템이 실제로 어떻게 반응하는지를 보여주는 살아 있는 모델을 갖게 된 것입니다.

4단계: 시각 관리를 통해 커뮤니케이션 개선하기

이 거대한 종이 지도는 단순한 문서가 아니라 시각 관리(Visual Management) 도구입니다.

시각 관리는(린 제조/운영에서 비롯된 개념으로) 업무 상태를 즉각적으로 눈에 보이게 만드는 것을 말합니다. incident 관리에서는 이런 의미를 가집니다.

신입은 벽 앞에 서 보는 것만으로도 incident가 조직 안에서 보통 어떻게 흐르는지 감을 잡을 수 있습니다.
팀 간 혼선은 핸드오프가 애매하거나 에스컬레이션이 빙빙 도는 모습을 통해 시각적으로 드러납니다.
리더십은 어떤 구간에 가장 많은 시간이 소요되는지, 단계가 밀집된 구역만 봐도 감을 잡을 수 있습니다.

벽을 다음과 같은 시각적 신호로 보강해 보세요.

자주 혼선을 일으키는 단계에 색깔 점 스티커 붙이기
오래 걸리는 단계 옆에 시계 아이콘 붙이기
임시 우회로가 반복적으로 사용되는 지점에 번개(⚡) 아이콘 붙이기

이런 시각 언어는 벽을 강력한 대화의 출발점으로 만듭니다.

“왜 이렇게 많은 incident가 SRE와 DB 팀 사이에서 멈춰 있지?”
“왜 성능 문제 트리아지 초기에 매번 즉흥 대응을 하고 있지?”
“왜 보안 팀은 항상 흐름의 맨 끝에만 등장하지?”

단순히 문서를 남기는 게 아니라, 조율 문제를 눈에 띄게 만들고 논의 가능하게 만드는 겁니다.

5단계: 현실 vs 런북 비교하기

이제 실제 흐름을 다 그렸으니, 현실 점검을 해볼 차례입니다.

중요한 런북 몇 개를 골라서 스스로에게 물어보세요.

공식 런북과 벽에 그려진 실제 흐름이 어디서 갈라지는가?
어떤 단계는 항상 건너뛰는가? 그 이유는 무엇인가?
벽에는 있는데 런북에는 없는 단계는 무엇인가?
대응자들이 성공하기 위해 반복적으로 ‘스크립트를 벗어나는’ 지점은 어디인가?

이 과정에서 종종 다음과 같은 사실을 발견하게 됩니다.

실제로는 비현실적이어서 실행되지 않는 단계
아무도 쓰지 않는 형식상의 에스컬레이션 경로
런북에는 등장하지 않지만 실제 핵심 역할을 하는 팀
DM, 개인 통화 같은 비공식 채널이 핵심 의사결정을 담당하고 있는 구간

이 격차 분석은 정말 값진 인사이트입니다.

“프로세스를 안 지켰다”라고 대응자를 탓하기보다는, 벽을 통해 프로세스가 현실과 맞지 않는다는 증거로 삼으세요. 프로세스를 현실에 맞게 고치거나, 이미 효과적으로 작동하고 있는 실제 행동을 반영해 런북을 업데이트해야 합니다.

6단계: 인사이트를 디지털 런북과 지표에 반영하기

관측소는 끝이 아니라 피드백 엔진입니다.

벽에서 얻은 내용을 바탕으로 할 수 있는 일들:

자주 등장하는 성공 경로를 기준으로 런북을 재설계합니다.
애매한 핸드오프 구간에 대해 책임과 소유권을 명확히 합니다.
거의 모든 incident 경로에 반복해서 나타나는 단계들(예: 페이징, 라우팅, 공통 대시보드 호출)을 자동화합니다.

그리고 이런 변화들을 구체적인 성과 지표와 연결합니다.

MTTA(Mean Time to Acknowledge, 인지까지 걸리는 평균 시간): 우선 대응자의 책임을 명확히 해서, 탐지/트리아지의 앞단을 단축할 수 있는가?
MTTR(Mean Time to Resolve, 복구까지 걸리는 평균 시간): 진단이나 에스컬레이션 단계에서 반복되는 병목을 사전에 제거하거나 간소화할 수 있는가?
회복탄력성(Resilience): 개편된 흐름이 특정 ‘히어로’나 한두 명의 전문가에게 덜 의존하도록 만들어 주는가?

업데이트된 디지털 런북을 가지고 새로운 incident들을 처리하면서, 주기적으로 다음을 반복합니다.

새 incident의 실제 경로를 다시 벽에 추가합니다.
지도가 점점 더 작고 명확한, 효율적인 경로 집합으로 수렴하고 있는지 확인합니다.
필요하다면 다시 조정합니다.

이 사이클은 결국 이렇게 정리할 수 있습니다.

관찰 → 지도화 → 논의 → 재설계 → 실행 → 재관찰

7단계: 포스트모템 인사이트를 얹어 시스템적 문제 찾기

마지막으로, 관측소에 포스트모템 인사이트를 덧입힙니다.

incident 하나하나에 대해 다음 정보를 벽에 함께 붙여 보세요.

주요 기여 요인(예: "알림 피로", "대시보드 부재", "소유권 불명확")
눈에 띄는 실수와 그 복구 과정
배운 점과 액션 아이템

간단한 태그나 아이콘을 관련 단계 옆에 붙이면 충분합니다. 한 발짝 물러나면, 패턴이 보이기 시작합니다.

같은 기여 요인이 여러 incident에서 반복적으로 등장합니다.
서로 다른 팀이 유사한 우회로를 반복해서 사용합니다.
“더는 어떻게 해야 할지 모르겠을 때” 마지막으로 몰리는 팀이 항상 비슷합니다.

이렇게 되면 벽은 단순한 흐름도가 아니라, 시스템의 취약성과 회복력에 대한 지도가 됩니다. 개별 incident를 각각의 불끄기 작업으로 보는 대신, 조직이 구조적으로 약한 부분이 어디인지 볼 수 있습니다.

마무리: 모두를 벽 앞으로 불러 모으는 저기압 지대

종이 런북 관측소는 다소 로우테크처럼 느껴질 수 있습니다. 하지만 바로 그 점이 가장 큰 장점입니다.

incident 대응을 화면 밖으로 끌어내어 하나의 공유된 벽 위에 올려놓으면, 다음과 같은 일이 벌어집니다.

이론과 실제 사이의 간극이 드러납니다.
시각 관리를 통해 조율 문제를 눈에 띄게 만듭니다.
표준 표기법을 사용해 복잡한 멀티팀 워크플로를 읽기 쉽게 만듭니다.
팀 간 학습과 정렬이 실제로 어떤 방식이 효과적인지 중심으로 이루어집니다.
관찰 내용을 디지털 런북에 반영해 MTTA/MTTR을 줄이고 회복탄력성을 높입니다.
포스트모템 인사이트를 흐름도 위에 덧입혀 반복되는 구조적 문제를 드러냅니다.

incident가 항상 혼란스럽게 느껴지고, 런북은 아무도 안 보는 문서 같고, 큰 장애 때마다 매번 처음 하는 즉흥 연주처럼 느껴진다면, 직접 종이 관측소를 만들어 보세요.

복잡한 사회기술 시스템을 이해하는 가장 빠른 길은, 때로는 대시보드에서 눈을 떼고, 마커를 집어 들고, incident가 실제로 어떻게 끝나는지 벽 전체를 써 가며 그려 보는 것일 수 있습니다.