아날로그 인시던트 스토리 등대: 장애의 안개 속을 비추는 손글씨 종이 비컨

장애가 터지면, 그 상황은 깨끗하고 선형적인 “이야기”처럼 느껴지지 않습니다.

그건 거의 안개에 가깝습니다.

Slack 메시지는 너무 빠르게 흘러가 따라가기 어렵고, 수많은 대시보드가 동시에 주의를 끕니다. 모두가 말은 하지만, 실제로 정렬된 사람은 거의 없고, 인시던트의 “스토리”는 여러 도구에 흩어져 존재합니다. 사람은 지치고, 맥락은 사라지고, 결정은 점점 흐트러집니다.

바로 이때 **아날로그 인시던트 스토리 등대(Analog Incident Story Lighthouse)**가 등장합니다.

등대는 인시던트 동안 방 안(또는 카메라에 보이는 곳)에 놓이는 **물리적인, 손으로 만든 종이 비컨(Beacon)**입니다. 기존 디지털 도구를 대체하지 않고, 오히려 그것들을 정박시키는 역할을 합니다. 혼란스럽고 안개 낀 사건을 팀 전체가 실제로 손가락으로 가리킬 수 있는 공유되는 하나의 이야기로 바꿔줍니다.

이 글에서는 이런 종이 등대를 어떻게 만들고, 인시던트 중에 어떻게 활용해 팀을 안내하며, 온콜 경험을 개선하고, 장기적인 학습 자료를 더 좋게 만드는지 살펴보겠습니다.

디지털 인시던트에 왜 아날로그 도구가 필요한가

이론상, 우리는 이미 필요한 모든 것을 갖추고 있습니다.

• Slack 인시던트 채널
• 이슈 트래커(Jira 등)
• 상태 페이지(Status Page)
• 대시보드와 트레이스
• 런북(runbook)과 플레이북(playbook)

그러나 실제로 스트레스가 높은 인시던트 상황에서는, 이런 디지털 도구가 오히려 인지 부하(cognitive load)를 높이기도 합니다.

• 컨텍스트가 여러 탭과 채널에 쪼개져 있습니다.
• 타임라인이 암묵적일 뿐, 눈에 보이지 않습니다.
• 소유권과 책임이 명확하지 않습니다.
• “잠깐, 지금 상황이 정확히 뭐죠?”라고 묻기 망설입니다.

높은 압박 + 높은 복잡도는 최악의 조합입니다.

반대로, 종이, 마커, 포스트잇, 테이프 같은 아날로그 도구는 단순하고, 인간의 스케일에 맞기 때문에 효과가 있습니다. 이런 도구는:

• 진짜로 중요한 정보에만 집중하게 만들고,
• 스크롤이나 창 전환 없이 항상 시야에 들어오며,
• “누가 무엇을 하고 있는가?” 같은 추상적인 개념을 구체적인 형태로 만들고,
• 말 없이 각자 추측하는 대신 공유된 이해를 유도합니다.

등대는 여러분의 디지털 스택과 경쟁하지 않습니다. 대신, 뇌가 그 복잡한 스택을 항해하도록 도와줍니다.

인시던트 스토리 등대란 무엇인가?

**인시던트 스토리 등대(Incident Story Lighthouse)**는 인시던트 룸(또는 워 룸 벽) 한가운데 자리 잡는 크고 손으로 만든 종이 아티팩트입니다. 이 등대의 역할은 다음과 같습니다.

• 사건의 타임라인을 눈에 보이게 만들고
• 역할과 책임을 명확히 하며
• 주요 결정과 그 이유를 기록하고
• 현재 가설, 액션, 상태를 추적하며
• 팀 모두가 참고할 수 있는 단일 공유 레퍼런스 포인트를 제공합니다.

즉, 인시던트를 시각적인, 아날로그, 실시간 이야기로 만들어 주는 도구입니다.

구현은 아주 단순할 수 있습니다.

• 벽에 붙인 플립차트용 큰 종이 한 장
• 인시던트 전용으로 명확히 구분한 화이트보드 영역
• Miro, FigJam 같은 가상 화이트보드를, 실제 종이처럼 사용하는 방법

핵심은 이 등대가 의도적으로 만들어지고, 눈에 잘 보이며, 지정된 사람이 계속 업데이트한다는 점입니다.

좋은 등대를 구성하는 핵심 요소

멋진 디자인이 필요하지는 않습니다. 중요한 건 선명한 구조입니다. 잘 만든 등대에는 보통 굵은 마커로 나눈 다음과 같은 섹션이 있습니다.

1. 인시던트 헤더

페이지 맨 위에는 다음 정보가 들어갑니다.

• 인시던트 이름 / ID
• 시작 시간(타임존 포함)
• 인시던트 커맨더(Incident Commander, IC)
• 스크라이브(Scribe) – 등대를 작성·유지하는 사람

이 헤더는 다음과 같은 프레임을 잡아줍니다.

우리는 지금 인시던트 상황에 있다. 그리고 이 등대가 그 인시던트다.

2. 역할과 담당자 목록

작은 박스를 하나 만들어 누가 무엇을 맡고 있는지 적습니다.

• IC(Incident Commander): 이름
• Comms(커뮤니케이션 담당): 이름
• Tech Lead(기술 리드)들: 이름
• 온콜 / 응답자(Responders): 이름 또는 팀

역할이 바뀌면, 기존 이름에 줄을 긋고 새 담당자를 적습니다. 이렇게 하면 소유권과 책임 이관이 명확해지고 혼란이 줄어듭니다.

3. 단순하고 선형적인 타임라인

종이 한쪽에 세로로 굵은 선을 그립니다. 인시던트가 진행되는 대로 타임스탬프를 추가합니다.

• 14:07 – API 오류율 높음 알람 트리거
• 14:10 – IC 지정, Slack #inc-1234 채널 생성
• 14:18 – 이전 릴리스로 롤백
• 14:24 – 고객 임팩트 확인: EU 사용자만 영향

이 타임라인은 모든 것을 다 적는 곳이 아닙니다. **이야기의 척추(spine)**를 세우는 영역입니다.

4. 현재 상황 & 가설들

“지금(Now)” 또는 “현재 상태(Current State)” 라벨이 붙은 박스를 만듭니다.

• 우리가 확실히 알고 있는 것
• 우리가 그렇다고 생각하는 것(가설)
• 아직 불확실한 점과 열린 질문들

예시:

• 증상: EU 트래픽의 약 30%에서 /checkout 엔드포인트 5xx 발생
• 가설: 엣지 프록시의 새로운 rate-limiting 설정 문제
• 미지점: 모바일/웹 각각의 영향? 정말 EU만인가?

5. 액션 & 결정 사항

타임라인과는 별도로, 핵심 액션과 결정을 기록하는 공간을 둡니다. 가능하면 포스트잇을 써서 필요할 때 옮겨 붙일 수 있게 하면 좋습니다.

• “릴리스 2026.02.20.1 롤백”
• “feature flag new_checkout_flow 비활성화”
• “데이터베이스 팀 호출(engage)”

각 항목에는 다음 정보가 포함되면 좋습니다.

• 짧은 라벨
• 시간
• 누가 시작했는지(initiator)

이 기록들은 인시던트 진행 중 조율의 기준점이 되며, 나중에 리뷰할 때도 핵심 역할을 합니다.

6. 상태 & 다음 단계

“다음 10–15분(Next 10–15 minutes)” 이라고 명확히 표시된 구역을 둡니다.

• 지금 실제로 하고 있는 일
• 기다리고 있는 것(테스트 결과, 메트릭, 다른 팀의 응답 등)
• 다음 체크인 시간

이렇게 하면 팀이 무작정 흩어지지 않고, 짧고 의도적인 사이클로 움직이게 됩니다.

인시던트 중에 등대를 사용하는 방법

스크라이브 지정하기

인시던트 커맨더(IC)는 직접 그림을 그리면 안 됩니다. IC는 등대를 스크라이브에게 위임해야 합니다. 스크라이브의 역할은 다음과 같습니다.

• 타임라인 업데이트
• 결정과 액션 기록
• “현재 상태”를 솔직하고 최신으로 유지
• 혼란을 표면화: “지금 가설이 세 개 있는데, 실제로 어떤 걸 밀고 가는 거죠?”

소리 내어 등대를 참조하기

등대를 **의식적인 의식(ritual)**으로 만듭니다.

• “등대 좀 보죠. 지금 가설이 뭐죠?”
• “타임라인 상으로, 첫 에러 스파이크가 언제였나요?”
• “새 액션을 추가하기 전에, 이전 액션은 정리됐나요?”

이렇게 등대를 기준으로 말하는 습관은, 스트레스 상황에서 어설픈 기억에 의존하지 않고, 공유된 현실을 함께 점검하는 문화를 만들어 줍니다.

무자비하게(Simple) 단순하게 유지하기

등대가 빼곡한 노트처럼 보이기 시작했다면, 이미 너무 멀리 간 겁니다. 몇 가지 가이드라인을 두면 좋습니다.

• 글자는 크게, 텍스트는 최소화
• 정말 중요한 타임스탬프만 기록
• 모든 행동이 아닌 핵심 결정만 기록
• 나중에 팀 외부 사람이 봐도 이해할 수 있도록 불필요한 전문 용어 최소화

목표는 압박 속에서도 선명한 이해이지, 완벽한 기록이 아닙니다.

실용적인 런북과 등대를 함께 쓰기

아날로그 등대는 구조가 잘 잡힌 **짧고 실용적인 런북(runbook)**과 함께 쓸 때 가장 효과적입니다. 런북의 구조를 등대의 구조와 비슷하게 맞추면 더 좋습니다.

좋은 런북의 조건:

• 짧을 것: 이상적인 길이는 1–3페이지
• 한눈에 보일 것: 명확한 헤더, 불릿, 체크리스트
• 위치가 분명할 것: 모두가 어디에 있는지 알고 있을 것

예시 목차:

1. 인시던트를 언제 선언할 것인가

   • 기준: SLO 위반, 특정 알람, 고객 신고 등
   • 누가 인시던트를 선언할 수 있는지

2. 첫 5분 체크리스트

   • IC 지정
   • 인시던트 채널 생성
   • 등대 시작
   • 대략적인 심각도(Severity) 설정

3. 역할과 책임 정의

   • IC: 의사결정, 조율, 시간 관리
   • 스크라이브: 등대 유지, 결정·액션 캡처
   • Comms: 이해관계자 및 상태 페이지 커뮤니케이션

4. 15분 리듬(15-Minute Rhythm)

   • 등대 리뷰: 타임라인, 가설, 액션
   • 다음 집중 포인트 정하기
   • 각 액션의 담당자 확인
   • 다음 체크인 시간 확정

5. 종료 & 인수인계(Closure & Handover)

   • 완화 또는 해결 상태 확인
   • 등대에 최종 상태 기록
   • 포스트모텀/사후 리뷰용 사진 촬영 또는 내보내기(export)

정리하면, 런북은 ‘무엇을 해야 하는지’를 말해주고, 등대는 ‘실제로 지금 무엇이 일어나고 있는지’를 보여줍니다.

아날로그 등대가 온콜 삶을 더 낫게 만드는 방법

인지 부하 감소 = 더 빠르고 나은 결정

누가, 무엇을, 언제, 왜 했는지를 물리적인 아티팩트에 내려놓으면, 응답자는 머릿속 리소스를 시스템 자체를 이해하고 추론하는 데 쓸 수 있습니다.

다시 말해, 이런 것들을 기억하느라 에너지를 쏟지 않아도 됩니다.

• 누가 지금 책임자인지
• 무엇을 이미 시도했는지
• 롤백이 정확히 언제 시작되었는지
• 누군가 이미 X를 확인했는지

이 모든 것이 벽에 적혀 있기 때문입니다.

더 나은 조율, 더 적은 크로스톡(cross-talk)

등대는 다음과 같은 조율 패턴을 자연스럽게 만듭니다.

• “잊어버리기 전에, 그거 등대에 추가해 주세요.”
• “그건 14:22에 이미 시도했어요. 여기 적혀 있어요.”
• “지금 활성화된 액션이 세 개예요. 네 번째를 추가하기 전에 하나 정리하죠.”

이런 패턴은 **중복 작업, 채널 소음, 혼자 영웅처럼 굴기(‘히어로 모드’)**를 줄여 줍니다.

공유된 이해를 통한 번아웃 감소

스트레스는 다음과 같은 조건에서 줄어듭니다.

• 사람들이 지금 무슨 일이 일어나는지 눈으로 볼 수 있을 때
• 역할이 분명할 때
• 계획이 눈앞에 보이고, 설령 그 계획이 계속 바뀌더라도 방향성이 있을 때

Slack 알림에 파묻혀 허우적대는 느낌 대신, 하나의 지도를 중심으로 함께 문제를 풀어나가는 팀의 일부가 되는 감각을 줄 수 있습니다. 이것만으로도 온콜 경험은 훨씬 인간적이고 덜 고통스럽게 느껴질 수 있습니다.

등대를 장기 학습 재료로 바꾸기

인시던트가 끝나면, 등대는 학습을 위한 원재료가 됩니다.

지우거나 버리기 전에 다음을 수행하세요.

1. 등대를 여러 각도에서 사진으로 찍습니다.
2. 포스트 인시던트 문서(포스트모텀, Incident Review 등)에 등대의 핵심 요소를 옮기거나 재정리합니다.
   • 타임라인
   • 주요 결정과 그 이유
   • 틀렸던 가설들
3. 거기에 학습한 내용을 주석으로 추가합니다.
   • “우리는 DB 문제라고 생각했지만, 실제 원인은 DNS였다.”
   • “이 리전은 아예 머릿속 모델에서도 빠져 있었다.”

이렇게 하면 포스트 인시던트 리뷰가 “누가 망쳤나?”라는 비난 게임에서 벗어나, “우리의 이해가 시간에 따라 어떻게 변했는가?”라는 이야기와 발견의 과정으로 바뀝니다.

시간이 지나면 패턴이 보이기 시작합니다.

• 반복되는 소유권 혼선
• 반복해서 드러나는 관측(Observability) 블라인드 스팟
• 반복되는 의사결정 지연

이 통찰들은 다시 다음을 개선하는 데 쓰입니다.

• 더 나은 도구
• 더 나은 문서화
• 더 나은 교육과 온보딩

이 모든 것이, 결국 벽에 붙은 종이 한 장에서 시작됩니다.

가볍게 시작하는 파일럿(Pilot)

이걸 시도하는 데 조직의 공식 승인이 꼭 필요하지는 않습니다. 아주 작게 시작할 수 있습니다.

1. 인시던트 룸(또는 본인 책상 근처)에 큰 종이와 굵은 마커를 둡니다.
2. 다음 인시던트에서는, 스크라이브를 명시적으로 지정합니다.
3. 간단한 등대를 그립니다: 헤더, 역할, 타임라인, 액션 구역.
4. 딱 한 번의 인시던트에만 사용해 보고, 그 후에:
   • 팀에 무엇이 도움이 되었는지 물어봅니다.
   • 포스트 인시던트 리뷰를 위해 등대 사진을 남깁니다.
   • 다음을 위해 레이아웃을 조금 수정합니다.

팀이 완전히 원격이라면, 공유 가상 화이트보드를 사용하되 실제 종이처럼 다루십시오: 글자는 크게, 구조는 단순하게, 모두가 동시에 볼 수 있는 한 화면만 사용합니다.

맺으며: 나만의 비컨을 만들자

인시던트가 완전히 명료해지는 날은 오지 않을 것입니다. 시스템은 본질적으로 복잡하고, 상황은 스트레스가 크며, 어떤 도구도 장애를 “쉽게” 만들지는 못합니다.

하지만, 그 안개를 더 잘 항해할 수 있게 만드는 것은 가능합니다.

손으로 만든 아날로그 인시던트 스토리 등대는 기존 인시던트 관리 플랫폼을 더 자동화하려 하지 않습니다. 대신, 사람의 스케일에 맞는 기준점을 제공합니다. 모두가 공유할 수 있는, 누가 무엇을 언제 왜 했는지에 대한 눈에 보이는 이야기입니다.

다음 세 가지를 결합하면:

• 종이, 마커, 포스트잇 같은 단순한 물리 도구
• 체크리스트 위주의 가벼운 런북
• 등대를 꾸준히 유지하고 계속 참조하는 팀의 의식(ritual)

…인시던트 대응은 더 잘 맞춰지고, 덜 소모적이며, 궁극적으로 학습이 훨씬 더 풍부한 활동이 됩니다.

이걸 시작하기 위해 허락을 받을 필요는 없습니다. 종이를 한 장 꺼내고, 첫 번째 등대를 그려 보세요. 방 안에 하나의 비컨이 생겼을 때, 안개 속이 얼마나 더 또렷해지는지 직접 느껴보게 될 것입니다.