아날로그 장애 스토리 지도 캐비닛: 온콜 엔지니어는 실제로 어떻게 실패를 탐색하는가를 손으로 그리기

실제 장애가 터지면, 상황은 대개 우리가 그려둔 깔끔한 박스와 화살표 다이어그램을 거의 따라가지 않습니다.

대신 온콜 엔지니어들은 즉흥적으로 움직입니다. 촉을 따라가고, 여러 도구를 이리저리 오가며, 이상한 엣지 케이스를 “그냥 아는” 그 한 사람에게 DM을 보내고, 조금씩 실제로 무슨 일이 일어나는지에 수렴해 갑니다. 공식 아키텍처 다이어그램은 Confluence 어딘가에 박혀 있을지 몰라도, 사람들이 장애 속을 어떻게 실제로 헤쳐 나가는지에 대한 진짜 지도는 각자의 머릿속에 들어 있습니다.

여기서 등장하는 것이 바로 아날로그 장애 스토리 지도 캐비닛(Analog Incident Story Cabinet of Cartographers) 입니다.

이것은 엔지니어들에게, 장애 동안 어떻게 움직였는지를 손으로 직접 그려보게 하는 실천입니다. 무엇을 봤는지, 어디로 갔는지, 누구와 이야기했는지, 무엇을 시도했는지, 그리고 이해가 어떻게 업데이트됐는지를 그려보는 거죠. 이런 아날로그 스토리‑맵은 운영의 진짜 지형을 드러냅니다. 엉성하고, 사람 냄새 나고, 엄청나게 가치 있는 모습으로요.

진짜 장애 대응 초능력은 ‘공유된 이해’다

우리는 장애 대응을 이야기할 때 보통 이런 것들을 떠올립니다.

• 더 좋은 툴링
• 더 빠른 알림
• 더 촘촘한 런북
• 더 명확한 역할 정의

이 모든 건 분명 중요하지만, 장애 상황 한가운데서는 그 어떤 것보다 중요한 게 하나 있습니다.

팀이 지금 무슨 일이 벌어지고 있는지에 대해 ‘공유된 이해’를 만들고 유지할 수 있느냐?

인지 시스템 연구자들은 이를 공통 작전 그림(common operational picture) 이라고 부릅니다. 실전에서는 대략 이런 풍경입니다.

• 모두가 무엇이, 누구에게 고장 났는지 대략 합의하고 있고
• 왜 이런 일이 벌어졌는지에 대해 그럴듯한 가설을 공유하고 있으며
• 다음에 무엇을, 왜 시도하는지에 대한 방향성이 맞춰져 있는 상태

이 공유된 이해가 약하면 이런 일들이 벌어집니다.

• 여러 사람이 동시에 같은 지점을 중복 디버깅
• 서로 다른 설명이 Slack에서 뒤엉켜 소리쳐지기
• 각자 따로 떨어져 솔로 디버깅에 빠지기
• 상황이 좋아지는 중인지, 더 나빠지는 중인지에 대한 혼란

기술 역량과 절차는 분명 도움이 됩니다. 하지만 그것들이 가치가 있는 건, 어디까지나 이 끊임없이 변화하는 ‘머릿속 그림’을 지탱해 줄 때뿐입니다. 장애 관리의 실제 업무는, 압박 속에서 각자의 멘탈 모델을 계속 업데이트하고 맞춰 가는 일입니다.

멘탈 모델은 보이지 않는다 — 그려 보기 전까지는

모든 온콜 엔지니어는 머릿속에 이런 내부 지도를 하나씩 가지고 있습니다.

• 시스템이 어떻게 서로 연결되어 있는지
• 어떤 컴포넌트가 어떤 방식으로 주로 실패하는지
• 각 대시보드에서 ‘정상’이 어떤 모습인지
• 어떤 종류의 이상 징후에 누구를 호출해야 하는지
• 예전 비슷한 장애에서 무엇이 통했고 무엇이 실패했는지

이러한 멘탈 모델이 실제 행동을 좌우합니다.

• 어떤 로그를 가장 먼저 열어볼지
• 어떤 메트릭을 신뢰할지
• 어떤 Slack 채널에 들어갈지
• 어떤 가설이 “시도해 볼 만하다”고 느껴지는지

문제는, 이 모델들이 대부분 눈에 보이지 않는다는 것입니다.

어떤 엔지니어는 문제의 출발점을 항상 “DB부터”라고 생각하는 반면, 다른 사람은 “네트워크부터”라고 생각한다는 사실을, 겉으로는 알기 어렵습니다. 팀의 절반은 어떤 컴포넌트가 상태를 갖지 않는다고 믿고, 나머지 절반은 그게 중요한 세션 데이터를 쥐고 있다고 믿고 있다는 걸, 한밤중 장애 한가운데에서 협업이 폭발적으로 꼬여 보기 전까지는 모를 수 있습니다.

이 멘탈 모델을 말과 그림, 공유 아티팩트를 통해 눈에 보이게 만드는 것은, 장애 상황에서 협업을 개선하고 스트레스를 줄이는 가장 빠른 방법 중 하나입니다.

그리고 바로 그 목적을 위해 설계된 것이 아날로그 장애 스토리‑맵입니다.

‘아날로그 장애 스토리 지도 캐비닛’이란 무엇인가?

이걸 하나의 반복 가능한 실천이자 공유 라이브러리라고 생각하면 됩니다.

• 아날로그(Analog) – 펜, 종이, 화이트보드, 포스트잇 등 손으로 하는 작업
• 장애 스토리(Incident Story) – 단순 시스템 그림이 아니라, 사람들이 장애를 어떻게 이동하고 경험했는지의 서사
• 캐비닛(Cabinet) – 이런 아티팩트를 보관하고 다시 꺼내 보는 (물리적 혹은 디지털) 공간
• 지도 제작자(Cartographers) – 이 지도를 그리는 온콜 엔지니어와 장애 대응자들

핵심은 단순합니다.

의미 있는 장애가 발생한 뒤, 주요 대응자 각각이 자신이 실제로 실패 속을 어떻게 탐색했는지 ‘손으로 그린 지도’를 남긴다.

각 지도에는 이런 것들이 담깁니다.

• 진입 지점: 처음으로 문제가 있음을 어떻게 눈치챘는지
• 경로: 어디로 이동했는지 (대시보드, 서비스, 사람, 도구 등)
• 갈림길: 의사결정 지점과 버려진 가설들
• 랜드마크: 사고를 형성한 단서들
• 결말: 무엇이 최종적으로 연결되어 이해되었고, 그에 따라 무엇을 했는지

그 결과물은 공식 아키텍처 다이어그램이나 런북과는 전혀 다른 모습을 한, 날것의 인간 규모 지도들의 모음이 됩니다.

왜 손그림 지도인가? (디지털 다이어그램만 더 잘 만들면 안 될까?)

자연스럽게 떠오르는 질문이 있습니다. “그냥 공식 다이어그램을 더 잘 만들면 되는 거 아닌가요? 왜 굳이 손으로 그린 아날로그 지도여야 하죠?”

아날로그 지도는 디지털 다이어그램이 보통 놓치는 것들을 포착해 줍니다.

1. 서사의 흐름
   디지털 다이어그램은 구조를 보여줍니다. 반면 손그림 지도는 순서를 보여줍니다. “이걸 봤고, 그래서 저걸 확인했고, 그다음에 저 사람을 ping 했다.” 이것이야말로 사람들이 실제로 장애 속을 이동하는 방식입니다.

2. 불확실성과 막다른 길
   엔지니어들은 지도의 여기저기에 지워진 경로, 커다란 물음표, “이상한 스파이크??” 같은 메모를 남깁니다. 이 지점들이 바로 지식의 경계입니다. 도구, 문서, 이해가 모두 우리를 버린 지점이죠.

3. 비공식 시스템
   “#infra‑secrets” 채널이나 “Maya에게 물어보기”, “2022년 오래된 Jira 티켓” 같은 연결선은 공식 아키텍처 다이어그램에 없습니다. 하지만 장애 지도에는 아주 선명하게 등장합니다.

4. 체감되는 토폴로지
   시간이 지나면, 이 지도들은 팀이 체감상 무엇이 서로 연결되어 있다고 느끼는지를 보여줍니다. 설계상 “독립적”이어야 하는 두 서비스가 장애 지도에서 항상 나란히 등장한다면, 운영 현실에서는 전혀 독립적이지 않다는 뜻입니다.

5. 마찰은 낮고, 솔직함은 높다
   손으로 그리기는 빠르고 부담이 적습니다. 사람들은 Lucidchart나 Figma에서 ‘예쁜’ 다이어그램을 다듬을 때보다 훨씬 덜 의식하고, 더 솔직하게 그립니다.

아날로그 지도 제작 세션을 어떻게 진행할까

처음부터 거창할 필요는 없습니다. 의미 있는 장애(크지 않아도 좋습니다)가 있었을 때, 1–2일 안에 이렇게 시작해 보세요.

1. 대응자들을 모은다
   실제로 적극 참여했던 사람 3–8명이 적당합니다.

2. 단순한 도구를 준다
   종이, 포스트잇, 펜, 마커 같은 것들. 리모트라면 빈 슬라이드나 온라인 화이트보드도 괜찮지만, 가능하면 ‘손그림 느낌’을 유지하도록 유도합니다.

3. 각자 자기 지도를 그리게 한다
   다음과 같이 프롬프트를 주세요.

   • "처음으로 이상하다고 느낀 순간에서 시작해 보세요."
   • "무엇을 봤고, 누구와 이야기했고, 무엇을 시도했는지 그려 보세요."
   • "막다른 길, 헷갈렸던 순간, 이해가 확 바뀐 순간을 표시해 주세요."

4. 보여주고, 이야기하고, 서로 비교한다
   각자가 자신의 지도를 설명하는 동안, 다른 사람들은 듣다가 자기 지도에 메모를 덧붙입니다.

   • "저 대시보드가 있는지 몰랐어요."
   • "잠깐, 당신은 캐시 문제라고 봤어요? 저는 계속 큐 문제라고 확신했는데."
   • "그 알림이 당신에겐 항상 노이즈라는 걸 몰랐어요."

5. 패턴과 공백을 찾는다
   함께 이런 것들을 찾아봅니다.

   • 반복해서 나타나는 우회 경로와 막다른 길
   • 컴포넌트 동작에 대한 서로 다른 가정들
   • 없거나 찾기 어려운 도구·대시보드
   • 특정 사람에게 과도하게 의존하는 지점(“이건 Alex 없인 못 고친다”)

6. 메타 인사이트를 정리한다
   그림만 저장하지 말고, 간단히 글로도 남깁니다.

   • 무엇이 우리를 놀라게 했는가?
   • 이 지도들이 우리 런북/다이어그램에 없는 무엇을 보여 주는가?
   • 이 경로들을 짧게 만들, 가장 단순한 변화는 무엇이었을까?

7. 지도를 ‘캐비닛’에 넣는다
   여기서 말하는 "캐비닛"은 이런 것일 수 있습니다.

   • 팀 스페이스 어딘가의 실제 폴더
   • 각 지도를 사진 찍어 올려 둔 위키 페이지
   • "Incident Story Maps" 같은 이름을 붙인 Notion/Confluence 공간

이 실천은 큰 장애에만 쓰지 말고, 주기적으로 반복해 보세요. 시간이 지나면, 이 캐비닛은 시스템과 팀이 함께 어떻게 진화해 왔는지 보여 주는 시각적 역사서가 됩니다.

이런 지도들이 운영 모델을 어떻게 바꾸는가

아날로그 장애 스토리 지도 캐비닛은 SRE나 팀 토폴로지를 대체하지 않습니다. 오히려 그 옆에 놓여, 두 접근이 가진 핵심 아이디어를 강화합니다.

SRE 실천과 함께

• 에러 버짓과 SLO는 언제 우리가 위험선에 다다랐는지 알려 줍니다.
• 장애 지도 제작(incident cartography) 는 우리가 실제로 어떻게 그 위험에서 빠져나오는지를 이해하게 해 줍니다.

스토리‑맵에서 반복해서 드러나는 패턴은 이런 곳에 피드백됩니다.

• 더 나은 알림 설계 (적절한 ‘랜드마크’를 더 일찍 보여 주도록)
• 더 현실적인 런북 (사람들이 실제로 밟는 경로를 반영하도록)
• 툴링 투자 (모두가 계속해서 그리고 있는 ‘괴로운 부분’을 자동화)

팀 토폴로지와 함께

팀 토폴로지는 팀 간 상호작용과 변화의 흐름에 주목합니다. 스토리‑맵은 장애 상황에서 이 흐름이 실제로 어떻게 흘러가는지 눈에 보이게 해 줍니다.

• 어떤 지점에서 팀 간 전환이 반복적으로 일어나는가?
• 어떤 팀들이 중요한 경로에서 ‘뜻밖의 의존성’으로 등장하는가?
• 어느 지점에서 인지 부하(cognitive load)가 가장 높은가?

이 지도들은 종종, 우리가 설계상 그려둔 “의도된” 팀 경계와, 장애 상황에서 드러나는 “운영상의” 팀 경계가 서로 어긋나 있다는 사실을 보여 줍니다. 이는 소유권이나 인터페이스를 재고해야 한다는 중요한 신호입니다.

사람 중심 운영 모델을 향해서

대부분의 운영 모델은 도구와 프로세스 중심입니다.

• 여기 시스템 다이어그램이 있다.
• 여기 런북이 있다.
• 여기 승격/에스컬레이션 체인이 있다.

아날로그 장애 지도 제작은 다시 사람 시스템에 초점을 맞춥니다.

• 사람들은 실제로 어떻게 감지하고, 해석하고, 행동하는가?
• 이해는 어디에서 깨지는가?
• 협업과 조정은 어디에서 취약한가?

이 질문들을 1급 시민처럼 다루기 시작하면, 문서상으로만 튼튼한 모델이 아니라, 실전에서 회복력 있는(resilient) 운영 모델을 갖게 됩니다.

시작을 위한 최소 플레이북

이걸 조직에 도입하기 위해 거창한 프로그램이 필요한 것은 아닙니다. 이렇게 시작해 보세요.

1. 사람들이 아직 생생히 기억하는 최근 장애 하나를 고른다.
2. **대응자들을 45–60분짜리 ‘매핑 회고’**에 초대한다.
   분명히 해 주세요: 이 자리는 책임 추궁을 위한 자리가 아니라, 이해를 위한 자리입니다.
3. 손그림 연습과 비교 토론을 진행한다.
4. 그린 지도들과, 거기서 배운 점의 짧은 요약을 공개한다.
5. 반복한다. 다음 의미 있는 장애 때도 다시 해 본다.

사람들이 이걸 유용하다고 느낀다면(대부분 그렇습니다), 장애 리뷰 프로세스에 가벼운 단계로 정식 포함시킬 수 있습니다.

결론: 우리가 실제로 걷는 지도를 그려라

모든 팀에는 자기 시스템에 대한 두 가지 지도가 있습니다.

1. 공식 디지털 지도: 아키텍처 다이어그램, 서비스 카탈로그, 런북.
2. 비공식 멘탈 지도: 새벽 3시, 모든 게 불타고 있을 때 엔지니어들이 실제로 머릿속에서 펼치는 지도.

대부분의 조직은 첫 번째 지도에는 엄청난 투자를 하지만, 두 번째 지도는 거의 신경 쓰지 않습니다.

아날로그 장애 스토리 지도 캐비닛은 이 멘탈 지도를 빛 아래로 끌어내는 방법입니다. 엔지니어들이 실패 속을 통과해 나갈 때 실제로 밟는 경로를 존중하고, 거기서 배우는 방식이죠.

이렇게 할 때 얻을 수 있는 것은 다음과 같습니다.

• 더 빠르고, 더 침착한 장애 대응
• 압박 속에서도 더 선명한 공유된 이해
• 툴과 프로세스 개선에 대한 더 현실적인 인사이트
• 시스템과 함께 진화하는, 살아 있는 사람 중심 운영 모델

실제로 프로덕션에서 시스템이 어떻게 작동하는지 알고 싶다면, 아키텍처 다이어그램만 펼쳐 보지 마세요.

엔지니어들에게 펜을 쥐어 주고, **직전에 겪은 장애에서 어떻게 빠져나왔는지 ‘이야기를 그려 달라’**고 요청해 보세요.

그게 여러분이 실제로 걷고 있는 지도이고, 진짜로 개선할 가치가 있는 지도입니다.