아날로그 인시던트 스토리 시티 맵: 종이 위 실패 동네를 걸으며 미래 장애를 우회하는 법

현대 시스템은 아주 오래된 방식으로 실패한다.

우리를 무너뜨리는 건 극적인 제로데이 익스플로잇이나 데이터센터 화재 같은 장면이 아니다. 더 자주 문제를 일으키는 건 이런 것들이다.

아무도 기억하지 못하는 오래된 cron job
“임시”였다가 아무도 내려치지 않은 서버
놓친 라이브러리 업데이트
스택 깊은 곳에 숨어 있는, 문서화되지 않은 작은 의존성 하나

이런 사소하고 눈에 잘 띄지 않는 요소들이 조용히 쌓이다가, 어느 날 서로 체인처럼 엮이면서 대형 장애로 터진다.

디지털 관측(Observability) 도구와 대시보드는 필수적이다. 하지만 대개는 증상을 확대해서 보여줄 뿐이다. 인시던트가 실제로 시스템·팀·프로세스 전반에 걸쳐 어떻게 전개되는지 이해하려면, 때로는 아주 인간적인 방식으로 ‘줌 아웃’할 필요가 있다.

그때 필요한 것이 바로 **아날로그 인시던트 스토리 시티 맵(incident story city map)**이다.

큰 장애는 왜 늘 작고 지루한 문제에서 시작되는가

장애는 흔히 이렇게 한 문장으로 요약된다. “DB가 죽었다”, “API 타임아웃이 났다.” 하지만 실제로 장애는 **하나의 이야기(story)**다. 작은 결정들, 사소한 누락, 보이지 않는 결합이 연속적으로 이어진 결과다.

자주 보이는 트리거는 다음과 같다.

여전히 중요한 내부 API를 제공하고 있는, 잊힌 레거시 서버
세 개의 핵심 서비스가 공유하고 있다는 사실을 아무도 몰랐던 작은 라이브러리
“잠깐” 끄고 다시 켜지 않은 모니터링 룰
테스트를 위해 바꿔 둔 설정 플래그가 프로덕션에 그대로 남아 있는 경우

각각은 다 사소하다. 하지만 시간, 트래픽, 비즈니스 이벤트가 특정 방식으로 맞물리는 순간, 이들은 도미노의 첫 조각이 되어 체인 리액션을 일으킨다.

이 체인을 움직이는 힘이 바로 **숨겨진 의존성(hidden dependency)**이다. 눈에 잘 띄지 않는 도구 하나가 다른 도구에 기대고 있고, 어떤 서비스는 다른 서비스가 항상 살아 있을 거라고 가정하며, 어떤 팀은 “그 부분은 다른 팀이 책임질 것”이라고 믿는다.

명확한 지도가 없다면, 이런 숨겨진 연결은 무언가가 실제로 깨질 때에만 모습을 드러낸다.

숨겨진 의존성: 당신의 시스템 아래에 숨은 보이지 않는 도시

당신의 시스템을 하나의 도시에 비유해 보자.

서비스는 건물이다.
API와 큐는 도로다.
데이터베이스와 캐시는 전기·수도 같은 기반 시설이다.
사람, 런북(runbook), 온콜(on-call) 로테이션은 소방서·경찰서 같은 긴급 서비스다.

문서 속 아키텍처 다이어그램만 보면 이 도시는 꽤 질서 정연해 보일 수 있다. 하지만 실제로는 다음과 같은 것들이 존재한다.

뒷골목: 공식화되지 않은 비공식 연동
지도에 없는 작은 길: 아무도 기억 못하는 레거시 데이터 플로우
이미 버려졌다고 생각하지만 여전히 트래픽이 통과하는 건물: 프로덕션에 그대로 남은 옛 서비스

이 숨겨진 의존성들은 **연쇄 장애(cascading failure)**를 만든다.

작은 내부 API 하나가 다운된다.
빌링 시스템이 그 API에 접근하지 못해 트랜잭션을 큐에 쌓기 시작한다.
큐가 가득 차면서 다른 서비스까지 느려진다.
프론트엔드 타임아웃이 폭발한다.
코어 인프라는 기술적으로 건강해 보이는데도, 고객 눈에는 앱이 “다운”된 것처럼 보인다.

대시보드는 어디가 아픈지 알려준다. 하지만 왜 그 조합의 것들이, 왜 그렇게 실패했는지까지 보여주진 못한다.

그걸 보려면, 직접 이 도시를 걸어봐야 한다.

‘인시던트 스토리 시티 맵’이란 무엇인가?

**인시던트 스토리 시티 맵(incident story city map)**은 한 번의 장애를 손으로 그려보는, 서사적인(narrative) 지도다.

어떤 시스템들이 관여했는지 보여주고,
데이터·요청·알림이 어떻게 움직였고 혹은 어디에서 멈췄는지 추적하며,
사람·팀·결정·지연까지 포함하고,
첫 번째 이상 징후부터 최종 복구까지의 스토리를 서사로 풀어낸다.

이건 단순한 인프라 다이어그램이 아니라, 동네 지도처럼 그린 스토리보드에 가깝다.

실제로 일어난 일을 지도 위에 옮겨 적는다.

어떤 서비스가 어떤 서비스의 “옆집”이었는지
디버깅 과정에서 어떤 도구들을 “지나가며” 거쳤는지
어디에서 막혔는지
어디에서 블라인드 스폿을 발견했는지

이 작업은 처음에는 종이 위에서 하는 것이 가장 좋다.

디지털 세상에서 굳이 아날로그를 쓰는 이유

스티키 노트와 마커를 꺼내는 건 APM, 트레이싱, 의존성 그래프 같은 최신 도구를 쓰는 시대에 거꾸로 가는 일처럼 느껴질 수 있다. 하지만 로우테크 방식에는 중요한 장점이 있다.

느리고 깊은 사고를 강제한다
이 지도는 자동 생성할 수 없다. 그게 핵심이다. 직접 그리는 과정에서 순서를 재구성하고, 서로 질문을 던지고, 빠져 있는 부분을 눈치채게 된다.
협업을 자연스럽게 만든다
사람들은 벽이나 화이트보드 앞에 모인다. Ops, Dev, Product, Support 등 각 역할이 특정 도구 접근 권한 없이도, 손가락으로 짚고, 질문하고, 옆에 메모를 붙일 수 있다.
디지털 도구가 놓치는 블라인드 스폿을 드러낸다
- “잠깐, 이 홉에 대한 로그가 아예 없네?”
- “이 서비스 실제로 누가 오너야?”
- “이건 배치 잡이라 트레이싱에 안 잡혀서, 지금까지 의존성으로 인식 못 했네.”
시스템뿐 아니라 사람과 프로세스까지 함께 표현할 수 있다
대부분의 다이어그램은 다음과 같은 것들을 무시한다. “페이지 알림이 잘못된 온콜 로테이션으로 갔다”, “런북이 오래돼서 실제 환경과 안 맞았다.” 종이 지도에서는 이런 프로세스 실패들을 기술적인 장애와 같은 동네에 놓고 볼 수 있다.
수정·재구성이 쉽고, 다른 시나리오로 ‘재프레이밍’하기 좋다
스티키 노트를 옮기고, 대체 경로를 그려보고, “다음에는 이렇게 대응하자”는 가상의 우회 루트를 만들어 볼 수 있다.

아날로그 인시던트 스토리 시티 맵 만드는 법

거창한 도구가 필요 없다. 필요한 건 이것뿐이다.

큰 종이나 화이트보드
스티키 노트나 인덱스 카드
마커와 테이프
인시던트에 실제로 관여했던 사람 몇 명

1단계: 고객이 서 있는 ‘메인 스트리트’부터 시작하기

종이의 맨 위나 왼쪽에 고객 경험을 먼저 둔다.

고객은 무엇을 봤는가? 타임아웃? 잘못된 데이터? 에러 페이지?
고객이 이상을 느끼기 시작한 시점은 언제인가?

이게 당신의 “메인 스트리트(Main Street)”다. 나머지 모든 것은 결국 이 메인 스트리트로 연결된다.

2단계: 가장 먼저 보인 실패 지점 추가하기

가장 먼저 증상이 드러난 시스템들을 배치한다.

프론트엔드 서비스
엣지/API 게이트웨이
모바일 API

고객에서 이 서비스들로 화살표를 그린다. 그리고 옆에 다음을 적어 둔다.

가장 먼저 울린 알림
처음 확인한 대시보드
초기에 가졌던 가설들

3단계: 동네를 거슬러 올라가며 한 칸씩 걸어가기

이제 실패한 서비스의 “블록을 따라” 한 칸씩 뒤로 걸어간다.

각 실패 지점이 의존하고 있던 것은 무엇인가? DB, 캐시, 서드파티 API, 내부 서비스 등.
그 다음에는, 그 대상들은 또 무엇에 의존하고 있었는가?

“User DB”, “Billing Service”, “Auth Provider” 같은 카드를 만들어 놓고, 데이터/요청 흐름을 화살표로 잇는다. 그리고 다음을 표시한다.

타임아웃이 발생한 지점
에러율이 치솟은 지점
관측 가능성이 부족하거나(로그, 메트릭, 트레이싱) 아예 없었던 구간

4단계: 사람과 프로세스 레이어를 덧입히기

이제 그 위에 인간적인 요소를 겹쳐 올린다.

가장 먼저 페이지를 받은 사람은 누구였는가? 두 번째는 누구였는가?
알림을 받고 실제 대응을 시작하기까지 얼마나 걸렸는가?
어떤 도구를 썼는가? (Slack, 티켓 시스템, 인시던트 관리 플랫폼 등)
어떤 결정이 ‘헛걸음’으로 드러났는가? (예: “45분 동안 엉뚱한 서비스를 디버깅했다”)

이 요소들을 기술 노드 주변에 배치하고, 다음을 보여주도록 선을 연결한다.

커뮤니케이션이 원활하게 흐른 곳
흐름이 막히거나 잘못 전달된 곳

5단계: 숨겨진 골목과 뜻밖의 발견 표시하기

놀라웠던 지점은 다른 색으로 강조한다.

“Service A가 Service B에 의존하는 줄 아무도 몰랐다.”
“레거시 잡이 아직도 이 데이터베이스에 쓰고 있었다.”
“옵셔널이라고 생각했던 서비스에 실제로 중요한 플래그가 묶여 있었다.”

이곳들이 바로 동네 블라인드 스폿이다. 나중에 반드시 다시 들여다봐야 할 구역이다.

지도에서 미래 우회로로: 핵심 의존성 문서화하기

이 지도는 단순한 과거 기록이 아니다. 다음 인시던트를 위한 내비게이션 도구다.

지도를 보며 다음을 추출한다.

핵심 의존성(Critical dependencies)
- 어떤 시스템이 내려가면 고객 경험이 치명적으로 훼손되는가?
- 우리를 놀라게 한 싱글 포인트 오브 페일리어(SPOF)는 무엇이었나?
우회·폴백 경로(Rerouting options)
각 핵심 의존성마다 스스로에게 묻는다.
- 이게 실패해도, 품질은 다소 떨어지지만 ‘괜찮은 수준’의 응답을 줄 수 있는가?
- 폴백(fallback) 경로가 있는가? (캐시된 데이터, 대체 공급자, read-only 모드 등)
- 임시로 투입할 수 있는 수동 운영 절차가 있는가?
오너십과 에스컬레이션 경로
- 각 핵심 의존성의 오너는 누구인가?
- 문제가 생겼을 때, 정확히 누구에게, 어떤 채널로 연락해야 하는지 알고 있는가?

이 내용은 다음에 반영한다.

런북
아키텍처 문서
온콜 플레이북

다음에 비슷한 유형의 인시던트가 시작되면, 대응자들은 다시 이 도시를 탐험하느라 시간을 날리지 않아도 된다. 이미 만들어 둔 지도를 보며, 알고 있는 ‘샛길’로 **우회(reroute)**하면 된다.

지도와 구조화된 포스트모템을 함께 쓰기

지도는 지형을 보여준다. **포스트모템(post-mortem)**은 왜 그 지점까지 가게 되었는지를 설명한다.

아날로그 지도와 함께, 구조화된 포스트모템 템플릿을 사용해 다음을 정리한다.

타임라인: 첫 신호부터 완전 복구까지의 주요 이벤트
임팩트: 고객·비즈니스 영향도와 지속 시간
기술적 근본 원인: 망가진 컴포넌트 하나만이 아니라, 그에 기여한 요소들의 연쇄
인간·프로세스 기여 요인: 커뮤니케이션 오류, 불분명한 오너십, 누락된 런북, 오해를 부른 메트릭 등
잘 작동한 부분: 성공적인 우회, 명확한 커뮤니케이션, 탄탄했던 설계
구체적 액션 아이템: 담당자와 데드라인이 있는 명확한 변경 사항

지도는 팀이 “DB가 느렸다” 같은 단순한 설명에서 벗어나게 돕는다. 대신 다음을 함께 볼 수 있다.

그 느려짐이 왜 더 일찍 감지되지 않았는지
왜 시스템에 안전한 디그레이드(degrade) 경로가 없었는지
왜 사람들이 처음에 잘못된 곳부터 살펴보게 되었는지

지도와 포스트모템을 결합하면, 각 인시던트는 다시 꺼내볼 수 있는 학습 아티팩트가 된다. 단순히 고통스러운 기억으로 사라지지 않는다.

모든 장애를 더 나은 도시 계획으로 바꾸기

시스템은 항상 변한다. 새 건물이 올라가고, 오래된 건물은 용도가 바뀌고, 지름길이 생긴다. 계속해서 지도를 업데이트하지 않으면, 머릿속의 도시와 실제 프로덕션의 도시는 점점 더 달라진다.

중요한 인시던트 이후에 아날로그 인시던트 스토리 시티 맵을 그리는 습관을 들이면, 다음과 같은 효과를 얻을 수 있다.

다음에 다시 물릴 수 있는 숨겨진 의존성을 미리 드러낸다.
작은 문제가 어떻게 큰 장애로 변하는지 이해하게 된다.
더 나은 우회·폴백 설계를 떠올리게 된다.
온콜 플레이북과 에스컬레이션 경로를 개선한다.
각 장애를, 향후 안정성에 투자하는 경험 자산으로 전환한다.

디지털 도구를 버릴 필요는 없다. 대신 아날로그 매핑을 다음과 같은 보완적(practice) 실천으로 활용하자.

의미 있는 규모의 장애가 발생하면, 관련 인원들을 모은다.
종이 위에 인시던트 스토리를 그린다. 시스템, 사람, 도구, 결정 모두 포함해서.
이 지도를 구조화된 포스트모템에 입력값으로 사용한다.
여기서 핵심 의존성과 우회 전략을 추출한다.
완성된 지도는 사진을 찍거나 디지털로 다시 그리고, 인시던트 문서에 링크를 남긴다.

신뢰성은 실패를 없애서 얻는 것이 아니다. 시스템이 우리를 놀라게 하는 속도보다 더 빨리 학습하는 것에서 나온다.

가장 빠르게 배우는 방법이, 때로는 마커를 집어 들고 실패의 동네를 걸어보는 것이다. 그리고 그 도시가 들려주는 이야기를, 먼저 종이 위에 받아 적는 것에서 시작한다.