종이로 그리는 인시던트 스토리 지하철 노선도: 숨겨진 장애 신호의 지하 경로를 손으로 설계하기

복잡한 시스템은 거의 절대 직선으로 망가지지 않습니다. 장애는 옆으로 번지고, 알림은 여러 도구 사이를 튀어 다니고, 아주 작은 글리치는 이상한 경로를 타고 땅속을 파고들다 어느 순간 “중대 인시던트”로 터져 나옵니다. 알림은 울리고, 대시보드 세 개를 번갈아 보는데도 여전히 상황이 안 보였던 적이 있다면 이미 알고 있을 겁니다. 우리가 머릿속에 갖고 있는 시스템 모델은 실제 동작과 거의 맞지 않는다는 사실을요.

이 간극을 줄이는 강력한 방법 중 하나는 의외로 아주 저기술(low‑tech)입니다. 그냥 그려 보는 것입니다.

이 글에서는 제가 인시던트 스토리 지하철 노선도(Incident Story Subway Map) 라고 부르는 기법을 다룹니다. 장애가 시스템·도구·사람 사이를 어떻게 흘러가는지 손으로 설계해 그려 보는, 다이어그램 중심의 방법입니다. 인시던트를 위한 시각적 지하철 노선도라고 생각하면 됩니다. 어떤 노선(신호) 이 어디를 지나고, 어떤 역(도구/팀) 을 통과하며, 어디에서 조용히 막혀 버리는지 한눈에 보이게 하는 거죠.

이 아이디어를 검증된 신뢰성 기법들과 연결해 보겠습니다. 신뢰도 블록 다이어그램(Reliability Block Diagrams, RBD), 결함수 분석(Fault Tree Analysis, FTA), 그리고 겐바(gemba)식 관찰을 어떻게 함께 활용하면, 로그나 코드만 봐서는 절대 보이지 않을 숨겨진 장애 경로를 드러낼 수 있는지 살펴보겠습니다.

왜 인시던트에 ‘지하철 노선도’가 필요한가

대부분의 팀은 다음과 같은 것들을 어느 정도 갖고 있습니다.

한 레포에 모여 있는 모니터링 설정
다른 레포에 있는 알림 라우팅 규칙
위키 어딘가에 있는 런북
별도의 운영 도구 안의 에스컬레이션 정책

각 산출물은 현실의 한 조각을 설명하지만, 어느 것도 전체 그림을 보여주지는 않습니다. 무언가 망가지면, 우리는 이 여러 레이어를 오가며 머릿속에서 인과 관계를 다시 복원하려 애쓰게 됩니다.

지하철 노선도는 이 모든 것을 하나의 시각적 스토리로 묶어 줍니다.

장애가 어디서 시작되는지 (알림의 소스)
장애 신호가 어떻게 이동하는지 (알림 라우트와 변환 과정)
어디에서 갈라지거나 멈추는지 (라우팅 로직, 필터, 사일런스 규칙)
사람은 언제, 어떻게 개입하는지 (에스컬레이션, 온콜, 핸드오프)

이렇게 신호와 경로의 전체 네트워크를 한 번에 보게 되면 다음과 같은 것들이 눈에 들어오기 시작합니다.

알림 커버리지가 전혀 없는 중요한 컴포넌트
알림은 발행되지만 책임 있는 사람에게 절대 도달하지 못하는 경우
문서상으로는 정의되어 있지만 실제로는 깨져 있는 에스컬레이션 경로
서로 겹치기만 하고 정보를 흐리게 만드는 중복 알림들

이 지점에서 신뢰성 다이어그램 도구들이 힘을 발휘합니다.

1단계: 신뢰도 블록 다이어그램 – 누가 불을 켜 두는가?

**신뢰도 블록 다이어그램(RBD)**은 개별 컴포넌트의 신뢰도가 전체 시스템 신뢰도에 어떤 영향을 주는지 시각적으로 표현하는 방법입니다. 직렬(series) 로 놓인 블록은 그중 하나만 실패해도 전체가 깨지는 구조를, 병렬(parallel) 블록은 중복 구성(레던던시)을 나타냅니다.

인시던트 지하철 노선도에서 RBD는 인프라의 척추(backbone) 역할을 합니다.

주요 서비스, 의존성, 크리티컬 컴포넌트를 블록으로 그립니다.
사용자 관점의 핵심 기능이 이들에 어떻게 의존하는지 연결합니다.
단일 장애 지점(SPOF)과 중요한 중복 구성을 강조합니다.

예를 들면 (텍스트 표현):

User Request → API Gateway → Auth Service → App Service → DB Cluster
                                           └→ Cache Cluster

지하철 노선도 관점에서 RBD 레이어는 기본 선로도입니다. 장애가 실제로 흘러갈 수 있는 트랙이 어디에 깔려 있는지를 보여주는 셈이죠.

이 레이어로 다음 질문에 답해 보십시오.

핵심 사용자 여정을 제공하려면 어떤 것들이 반드시 살아 있어야 하는가?
어느 지점에서의 국지적 장애가 전체 장애로 증폭될 수 있는가?

2단계: 알림 라우트 다이어그램 – 신호는 실제로 어떻게 이동하는가?

어떤 블록이 중요한지 이해했다면, 다음 단계는 장애가 났을 때 알림이 어떻게 이동하는지를 다이어그램으로 그려 보는 것입니다.

대부분의 팀에서는 이 부분의 복잡도가 의외로 상당합니다.

메트릭 → Alertmanager → Notification Router → 채팅/이메일/페이저
로그 → SIEM → 상관 규칙 → 인시던트 관리 도구
Synthetic 체크 → 외부 프로바이더 → 웹훅 → 온콜 시스템

이 경로들을 명시적인 선로로 그려 보면, 그동안 숨어 있던 관계들이 드러납니다.

무엇을 그려야 할까

RBD에서 뽑아낸 각 중요 컴포넌트에 대해 다음을 정리합니다.

알림 소스(Alert Sources)
- 메트릭, 로그, 트레이스, synthetic 체크, 헬스 엔드포인트 등
변환 단계(Transformation Steps)
- 알림 규칙, 상관 엔진, 디듀플리케이션, 노이즈 필터링
라우팅과 에스컬레이션(Routing and Escalation)
- 온콜 로테이션, 에스컬레이션 정책, 폴백 채널
사람의 개입 지점(Human Interaction Points)
- 누가 가장 먼저 무엇을 보는지, 누가 승인/에스컬레이트/종료할 수 있는지

여기서 “지하철” 비유가 특히 잘 먹힙니다. 각 알림 소스를 노선(line) 으로, 각 도구/팀을 역(station) 으로, 에스컬레이션을 환승(transfer) 으로 그려보십시오.

알림 라우트 다이어그램이 중요한 이유

어디서 신호가 사라지는지 보입니다. (수신자가 없는 알림, 비활성화된 채널 등)
하나의 이벤트가 여러 경로로 갈라지며 엇갈린, 모순된 신호를 보내는 지점을 잡아낼 수 있습니다.
잠복 지연(latent delay) 을 찾을 수 있습니다. 예: 처음엔 이메일로만 보내고 30분 뒤에야 페이저를 울리는 알림.

이렇게 다이어그램으로 정리해 두면 에스컬레이션 경로를 안전하게 커스터마이즈하고 개선하기가 훨씬 쉬워집니다.

종이 위에서 변경안을 시뮬레이션해 볼 수 있고,
고심각도(severity) 알림은 항상 명확하고 신속한 경로를 갖도록 검증할 수 있으며,
우선순위가 낮은 노이즈가 크리티컬 신호와 같은 노선을 타지 않도록 설계할 수 있습니다.

3단계: 숨겨진 연결을 눈에 보이게 만들기

알림과 에스컬레이션 로직의 상당 부분은 코드나 불투명한 설정 파일 안에 숨어 있습니다.

Alertmanager를 위한 Terraform 모듈
규칙과 라우트를 정의한 YAML
인시던트 도구 안의 JSON 정책

각 파일을 따로 보면 “그럴듯하게” 보입니다. 하지만 이 모든 것이 합쳐지면, 그 누구도 온전히 머릿속에 그려 본 적 없는 emergent behavior가 만들어질 수 있습니다.

다음 요소들 사이의 연결을 명시적으로 보여줌으로써:

모니터/알림 규칙
서비스/컴포넌트
팀/온콜 역할
채널/도구

…다음과 같은 것들을 드러낼 수 있습니다.

현재는 아무도 책임지지 않는 컴포넌트에 연결된 고아 알림(orphan alerts)
대응 알림이 하나도 붙어 있지 않은 고아 컴포넌트(orphan components)
(예: 어떤 팀의 알림이 항상 다른 팀을 먼저 깨우는 식의) 암묵적 의존 관계

이렇게 만든 지하철 노선도는 단순한 설정 의도(intent)를 넘어서, 실제 현실을 반영하는 살아 있는 문서가 됩니다.

4단계: 결함수 분석 – 인시던트는 실제로 어디서 시작되는가?

RBD가 시스템이 어떻게 살아남는지를 보여 준다면, 결함수 분석(FTA) 은 시스템이 어떻게 죽는지를 보여 줍니다.

FTA 다이어그램은 하나의 최상위 이벤트(top event) 에서 출발합니다. 예: “결제 기능 불가(Checkout unavailable)”. 그리고 거꾸로 내려가며 분석합니다.

이를 중간 이벤트(intermediate events) 로 쪼갭니다. (API 장애, DB 쓰기 거부 등)
각 이벤트들을 논리 게이트(AND/OR) 로 조합해, 어떤 조합에서 최상위 이벤트가 일어나는지 표현합니다.
잎사귀(leaves)에는 기본 이벤트(basic events), 즉 구체적인 컴포넌트/프로세스 장애를 위치시킵니다.

FTA를 지하철 노선도와 결합하면 다음을 할 수 있습니다.

각 장애 경로마다 어떤 알림이 실제로 울리는지 (또는 안 울리는지) 추적
중대 인시던트를 일으킬 수 있는 핵심 장애 경로 중, 얼리 워닝이 전혀 없는 것 식별
실제로 인시던트로 이어질 가능성이 높은 장애 모드에 우선순위를 두고 대응 계획 수립

예를 들어, 상위 레벨의 장애가 다음과 같은 조합으로도 발생할 수 있음을 발견할 수 있습니다.

조용히 실패한 캐시 장애 + 백그라운드 잡 슬로우다운의 조합
그런데 둘 다 현재는 페이징(페이지) 수준의 알림을 갖고 있지 않은 상황

이 단계에서 우리는 “지도를 그려 봤다” 수준을 넘어, 어떤 선로를 우선 보수해야 하는지를 말할 수 있게 됩니다.

일관된 시각적 범례의 힘

이 모든 작업이 제대로 작동하려면, 사람들이 지도를 읽을 수 있어야 합니다.

간단하지만 일관된 시각 언어(범례)를 정의해 두십시오.

도형(Shapes)
- 직사각형: 컴포넌트/서비스
- 원: 알림 또는 이벤트
- 마름모: 의사 결정 지점 (라우팅/에스컬레이션 로직)
- 평행사변형: 사람의 액션 또는 핸드오프
색상(Colors)
- 빨강: 장애 상태
- 초록: 정상 상태
- 주황: 성능 저하·위험 상태
- 파랑: 도구/플랫폼 (모니터링, 페이징, 채팅 등)
선(Line)
- 실선: 동기식 의존성 또는 즉시 전달되는 알림
- 점선: 비동기 또는 지연이 존재하는 경로
- 이중선: 고(高) 중요도 라우트

RBD, 알림 라우트, FTA 다이어그램 전체에 이 범례를 공통으로 쓰면 다음과 같은 이점이 생깁니다.

개발자, SRE, 인시던트 매니저가 같은 시각 언어를 공유하게 됩니다.
신규 팀원은 모든 설정 파일을 읽기보다, 지도를 읽는 것만으로도 빠르게 상황을 파악할 수 있습니다.
포스트 인시던트 리뷰에서 특정 심볼과 경로를 가리키며 이야기할 수 있어 혼선을 줄입니다.

각 다이어그램의 가장자리에 이 범례를 인쇄해 두십시오. 지루할 정도로 일관되게 유지하는 것이 중요합니다.

겐바(gemba): 인시던트가 실제로 일어나는 곳으로 가라

린(lean) 제조에는 겐바(gemba) 라는 개념이 있습니다. 실제로 일이 벌어지는 “현장”이라는 뜻입니다. 소프트웨어 신뢰성 관점에서 겐바는 다음과 같습니다.

실시간 장애 상황에서의 인시던트 Slack/Teams 채널
새벽 3시에 온콜 엔지니어가 들여다보고 있는 노트북 화면
인시던트 초반 30분 동안 팀 사이에서 오가는 핸드오프

실제 일이 벌어지는 모습을 그대로 관찰하면 다음과 같은 것들을 발견할 수 있습니다.

어떤 일들은 어떤 런북에도 적혀 있지 않은 채 매번 수행됩니다.
대시보드에는 전혀 나타나지 않는 우회로(workaround) 가 사용됩니다.
소유권이 불분명해 생기는 지연
아키텍처 다이어그램이 말하는 것과 달리, 사람들이 실제로 의존하는 도구가 무엇인지

기본적인 지하철 노선도를 하나 만든 뒤, 실제 인시던트 동안 온콜 엔지니어 옆에 앉아(또는 녹화를 보며) 다음을 해 보십시오.

그들이 하는 행동을 새로운 노선과 역 으로 지도에 추가합니다.
도구를 바꾸는 지점, 질문하는 지점, 막히는 지점을 표시합니다.
현실이 기존 다이어그램과 어디서 어긋나는지 기록합니다.

곧 다음과 같은 것들을 발견하게 됩니다.

어떤 공식 시스템에도 존재하지 않는 “그림자 경로(shadow routes)”
(예: 특정 전문가에게 직접 DM을 보내는 패턴)
채널이 너무 시끄러워서, 그 안에 올라온 알림은 아무도 보지 못하는 지점
매번 반복되는 수동 점검 작업 – 사실상 자동화 혹은 모니터링해야 할 후보

겐바를 통해 지하철 노선도는 단순한 설계 산출물이 아니라, 현장에서 검증된 신뢰성 모델로 진화합니다.

지도, 데이터, 관찰을 결합하기

가장 강력한 인시던트 모델은 다음 세 가지 관점이 교차하는 지점에서 나옵니다.

시각적 장애 지도(Visual failure maps)
- 시스템 구조를 위한 RBD
- 신호 흐름을 위한 알림 라우트 다이어그램
- 장애 경로를 위한 FTA
실제 데이터(Real‑world data)
- 과거 인시던트 타임라인
- 알림 발생/승인/해제 패턴
- 경로·팀별 MTTA/MTTR 지표
겐바식 관찰(Gemba‑style observation)
- 온콜 행동을 지켜보기
- 인시던트 커맨더를 섀도잉
- 인시던트 대응자들과 사후 디브리핑

이 세 가지를 겹쳐 보면 다음을 할 수 있습니다.

설계 상의 크리티컬 경로가 실제 인시던트에서도 활용되는지 검증
의도만이 아니라 실제 인간 행동을 반영하도록 지도를 수정
이론상 위험이 아니라, 실제로 인시던트가 가장 자주 발생하는 지점을 기준으로 우선순위 설정

이렇게 만들어진 인시던트 스토리 지하철 노선도는 다음과 같은 역할을 할 수 있습니다.

신규 엔지니어를 위한 교육 도구
신뢰성 투자 계획을 세우기 위한 기획 도구
포스트 인시던트 리뷰에서 활용하는 진단 도구

직접 종이로 인시던트 스토리 지하철 노선도 그리기 – 시작 방법

특별한 소프트웨어는 필요 없습니다. 다음만 있으면 됩니다.

하나의 핵심 사용자 여정
예: 로그인, 결제, 메시지 전송
화이트보드나 큰 종이 한 장
작은 크로스펑셔널 그룹
(개발, SRE, 인시던트 매니저가 함께)

그다음 순서는 다음과 같습니다.

그 사용자 여정의 크리티컬 패스에 대해 RBD를 그립니다.
그 위에 알고 있는 모든 알림 소스와 라우트를 오버레이합니다.
가벼운 FTA 사고방식을 활용해 장애 경로를 추가합니다.
단순한 범례를 정의하고, 끝까지 일관되게 사용합니다.
최근 실제 인시던트 하나를 이 지도 위에서 재현하며 검증합니다.

그러면 거의 확실하게 다음 중 적어도 하나를 발견하게 됩니다.

직접적이고 실행 가능한 알림이 전혀 없는 크리티컬 컴포넌트
잘못된 팀을 먼저 깨우는 알림
사용자 불만 외에는 감지 방법이 없는 장애 경로

이 발견들이 곧 다음 신뢰성 개선 사이클의 로드맵이 됩니다.

맺으며: 지하를 그려라

대시보드는 무슨 일이 벌어지고 있는지를 알려 줍니다. 로그는 어디서 벌어졌는지를 말해 줍니다. 설정 파일은 우리가 무엇을 만들려고 했는지를 보여 줍니다.

손으로 그린 인시던트 스토리 지하철 노선도는, 장애 신호가 실제로 어떻게 이동하는지를 보여 줍니다. 시스템과 도구, 그리고 사람을 가로질러, 첫 이상 징후에서 인시던트 해결까지 어떤 여정을 거치는지를요.

다음 요소들을 결합하면:

크리티컬 의존성을 지도화하는 RBD
신호 경로를 드러내고 개선하는 알림 라우트 다이어그램
중요한 장애 모드에 우선순위를 주는 FTA
공통 이해를 돕는 일관된 시각 범례
모델을 현실에 단단히 고정시키는 겐바식 관찰

…어떤 단일 도구보다 훨씬 정확하고 실행 가능한 신뢰성 그림을 갖게 됩니다.

가장 현대적인 시스템을 고치는 가장 빠른 방법이, 때로는 펜을 들고 매일 인시던트가 달리는 지하 선로를 그려 보는 것일 수 있습니다.