아날로그 장애 대응 지하철 노선도: 관측성이 사라졌을 때 장애를 탐색하는 종이 설계도

소개: 관측성의 불이 꺼지는 순간

현대적인 장애 대응은 한 가지를 전제로 합니다. 당신의 관측성 스택이 살아 있다는 것.

하지만 이런 일이 벌어지면 어떻게 될까요?

모니터링 클러스터가 다운되었을 때
클라우드 제공자가 “부분 장애”를 겪고 있을 때(실제 의미: 혼돈)
SSO나 VPN이 먹통이 되어 아무도 대시보드에 접근하지 못할 때
네트워크 분할로 인해 주요 도구들이 서로 고립되었을 때

이 순간에 잃는 것은 메트릭과 트레이스만이 아닙니다. 바로 **방향 감각(orientation)**입니다. 팀은 더 이상 시스템이 어떻게 생겼는지, 무엇이 고장 났는지, 그리고 다음에 무엇이 고장 날 수 있는지에 대한 공통된 그림을 공유하지 못합니다.

이럴 때 등장하는 것이 **아날로그 장애 대응 지하철 설계도(Analog Incident Subway Blueprint)**입니다. 모든 디지털이 암흑으로 떨어졌을 때 백업 관측성 레이어 역할을 해 주는, 방 한쪽 벽을 가득 채우는 종이 기반 네트워크 지도입니다.

인프라, 애플리케이션, 데이터 저장소, 핵심 외부 서비스들을 지하철 노선도 스타일로 한눈에 볼 수 있게 표현하고, 알려진 장애 양상과 대응 휴리스틱을 메모처럼 달아 둔 물리적 다이어그램이라 생각하면 됩니다. 향수 팔이용 소품이 아니라, 정보가 부족하고 스트레스가 극심한 상황에서 실제로 도움이 되는 실용 도구입니다.

왜 디지털 장애 대응실에서 여전히 ‘종이’가 중요한가

벽 한 면을 가득 채운 종이 지도는, 대시보드가 줄 수 없는 세 가지 장점을 제공합니다.

절대 다운되지 않습니다. 로그인도, 네트워크도, 전기도 필요 없습니다.
본질적으로 공유됩니다. 방 안에 있는 모두가 말 그대로 같은 그림을 보고 있습니다.
스트레스 상황에서 대화를 고정(anchor)해 줍니다. 비상 상황일수록, 사람들은 손가락으로 가리키며 이야기할 수 있는 무언가가 있을 때 더 잘 사고하고 소통합니다.

화면이 꺼졌거나 접근이 막힌 상황에서, 벽에 붙어 있는 지도는 백업 관측성 인터페이스가 됩니다. 실시간 텔레메트리는 아니지만, **실시간 인지(live cognition)**가 이루어지는 장소입니다. 남아 있는 어떤 신호든 모아, 거기서 무슨 일이 벌어지는지 사람들의 머릿속에서 재구성하는 공간인 셈입니다.

인지 지도(Cognitive Map): 소방관에게서 배우기

소방관들은 불이 난 건물에 대해 **인지 지도(cognitive map)**를 그리는 훈련을 받습니다.

비상구와 계단이 어디에 있는지
어느 벽이 구조를 지탱하는지(내력벽)
불길이 어디로 번질 가능성이 큰지

그들은 건물 전체를 선명히 보지 못하는 경우가 대부분이지만, 부분 정보만으로도 빠르게 행동할 수 있게 해 주는 내부 모델을 유지합니다.

당신의 엔지니어들도 비슷한 것이 필요합니다.

아날로그 지하철 설계도의 목적은 완벽한 정밀도를 갖추는 것이 아닙니다. 대응자들이 다음에 대한 **공유 인지 지도(shared cognitive map)**를 만들고, 지속적으로 업데이트할 수 있도록 돕는 것입니다.

어떤 컴포넌트들이 존재하는지
그것들이 어떻게 연결되어 있는지
문제가 어디를 통해 전파될 가능성이 큰지

이 지도를 가지고 연습을 자주 할수록, 사람들 머릿속의 인지 지도는 더 또렷해집니다. 실제 장애가 터졌을 때, 완전히 백지 상태에서 시작하는 것이 아니라, 이미 알고 있는 구조에 새로운 장애 단서를 채워 넣는 수준에서 대응하게 됩니다.

1단계: 의존성 유형별로 시스템을 분해하기

유용한 아날로그 지도는, 먼저 의존성 레이어를 명확히 나누는 것에서 시작합니다. 최소한 다음 정도는 구분하는 것이 좋습니다.

인프라
- 컴퓨트: 노드, 클러스터, 오토스케일 그룹 등
- 네트워크: VPC, 서브넷, 게이트웨이, 로드밸런서 등
- 스토리지: 블록, 오브젝트, 공유 파일 시스템
애플리케이션 / 서비스
- 사용자 지향 서비스: API, 웹 앱, 모바일 백엔드
- 내부 서비스: 인증, 빌링, 검색, 추천 등
- 배치 / 백그라운드 워커
데이터 시스템
- 데이터베이스: SQL, NoSQL
- 캐시, 큐, 이벤트 스트림
- 분석 / 파이프라인
외부 서비스
- 서드파티 API: 결제, 메시징, 인증
- 관리형 SaaS 의존성: 로깅, 이메일, CDN 등

벽 위에서는 이를 아래에서 위로 올라가는 **수평 레이어(밴드)**처럼 배치할 수 있습니다. 예를 들어, 맨 아래는 인프라, 그 위는 데이터, 그 위는 애플리케이션과 사용자 흐름처럼 쌓는 식입니다. 이렇게 하면 장애 상황에서 지도가 실제 행동에 바로 연결됩니다. 대응자들이 이런 식으로 질문할 수 있기 때문입니다.

“이 데이터베이스가 성능 저하 상태라면, 그 위 레이어에서 어떤 서비스들이 같이 죽지?”
“이 리전이 불안정하면, 맨 위 사용자 플로우 중 무엇이 영향 받지?”

목표는 상세한 아키텍처 문서화가 아니라, 빠른 블라스트 레디우스(영향 범위) 추정입니다.

2단계: 애플리케이션 의존성 맵핑을 ‘종이 위에’ 구현하기

대부분의 조직은 이미 도구 안에 어떤 형태로든 애플리케이션 의존성 맵핑을 가지고 있습니다. 서비스 ↔ 서비스, 서비스 ↔ 데이터베이스, 서비스 ↔ 외부 API와 같은 관계도죠.

아날로그 지하철 설계도는 이 개념을 가져와 지하철 노선도 스타일로 납작하게(flatten) 펼쳐 놓습니다.

노선(line) = 핵심 비즈니스 플로우 (예: “결제/체크아웃 플로우”, “사용자 로그인”, “데이터 수집/적재”)
역(station) = 그 흐름을 구성하는 핵심 컴포넌트 (서비스, 데이터베이스, 큐, 서드파티 API 등)
환승역(interchange) = 여러 노선이 공유하는 의존성 (예: 인증, 유저 프로필, 결제 공용 서비스)

예를 들어, “체크아웃 노선”은 다음처럼 시각적으로 이어질 수 있습니다.

웹 프런트엔드 → API 게이트웨이 → 주문 서비스 → 결제 서비스 → 결제 제공자 API → 주문 DB → 알림 서비스

여러 노선을 하나의 지도 위에 얹어 두면, 즉시 다음을 볼 수 있습니다.

교차점이 유난히 밀집된 구간: 여러 흐름이 같은 의존성에 매달린 고위험 공유 지점
우회 경로나 중복이 전혀 없는 경로
핵심 비즈니스 노선 위에 직접 올라탄 외부 서비스들

스트레스 상황에서 대응자들은 지도를 힐끗 보고 이렇게 생각할 수 있어야 합니다.

“이 역이 불타면, 어떤 노선들이 멈추는 거지?”

3단계: 영향이 큰 의존성부터 우선순위를 매기기

방 한가득한 지도는, 크론 잡 하나하나나 디버그용 서비스까지 죄다 그려 넣을 공간이 아닙니다.

여기서 필요한 것은 **결과(영향) 중심 설계(consequence‑driven design)**입니다.

다음과 같은 컴포넌트들을 위주로 포함합니다.

장애가 나면:
- 핵심 사용자 여정을 중단시키거나
- 중요한 데이터를 손상시키거나 크게 지연시키거나
- 규제·보안 통제를 깨뜨릴 수 있는 것들
영향이 상대적으로 작은 요소들은 과감히 생략하거나, 더 큰 노드로 묶습니다. (예: “보조 워커 클러스터”)

그리고 시각적인 강조를 통해 중요도를 표현합니다.

굵은 노선: 핵심 비즈니스 플로우
큰 역 아이콘: 영향도가 높은 컴포넌트
색상 코드: 심각도 구분 (예: 빨간색 = 단일 장애점 / SPOF)

목표는 속도입니다. 장애 발생 후 첫 5분 안에, 대응자들이 문서를 뒤적이지 않고도 가능성 높은 장애 전파 경로를 추적하고 블라스트 레디우스를 대략 추정할 수 있어야 합니다.

4단계: 관측성 지식을 지도 위에 직접 인코딩하기

관측성 시스템이 죽어 있어도, 우리는 여전히 시스템이 평소에 어떻게 행동하는지에 대한 경험적 지식을 가지고 있습니다. 이 지식을 미리 종이 지도에 새겨 두는 것이 가능합니다.

추가하면 좋은 레이어는 다음과 같습니다.

1. 자주 발생하는 장애 양상(Failure Mode)

주요 역 옆에는 작은 범례처럼 메모를 붙입니다.

“전형적인 장애: 커넥션 풀 고갈, 쓰로틀링, 스테일 캐시, DB 락 경합”
“자주 발생하는 이슈: 외부 제공자 TLS 오류, 리전 단위 지연 급증”

이런 메모는 실시간 에러 대시보드가 없을 때 쓸 수 있는 인지적 단축키(cognitive shortcut) 역할을 합니다.

2. 이상 징후 패턴(Anomaly Pattern)

아이콘이나 간단한 라벨로 자주 관측되던 패턴을 표시합니다.

“배포 직후 자주 실패함”
“트래픽 스파이크에 민감함”
“리전 A가 불안정할 때 연쇄적으로 영향 받음”

이렇게 하면 대응자들은 자연스럽게 가설 중심으로 사고하게 됩니다.

“이거 또 배포 후 캐시 비동기화 문제 아닐까?”

3. 알림 플로우(정상일 때 기준)

현재 알림 시스템이 죽어 있더라도, 평소에 어떤 알림이 어디를 감시하는지를 지도에 표시합니다.

각 주요 역에 연결된 SLO / 알람 종류
해당 알람에 소유권을 가진 팀

만약 누군가 부분적으로라도(예: 아직 VPN이 살아 있는 노트북 하나) 시스템에 접근할 수 있다면, 실제로 무엇이 깨져 있는지와 원래 같으면 어디에 알람이 떴을지를 교차 참조할 수 있습니다. 그때 종이 지도가 내비게이션 역할을 해 줍니다.

5단계: 실제 장애 상황에서도 ‘운영 가능’하게 만들기

아날로그 설계도가 쓸모 있으려면, 장애 대응 중에도 실시간으로 손쉽게 업데이트할 수 있어야 합니다.

장애 대응실에는 다음을 기본으로 준비해 둡니다.

색깔별 포스트잇: 현재 이슈, 가설, 완화 조치 등을 표시
보드마카(라미네이팅 했을 경우): 의심 구간을 강조 표시
간단한 색상 규칙 예시:
- 빨간 포스트잇: 영향이 확정된 컴포넌트
- 노란 포스트잇: 의심 구간 / 조사 중
- 파란 포스트잇: 완화 조치 적용 / 임시 우회 중

장애가 진행되는 동안 지도는 하나의 살아 있는 스토리보드가 됩니다.

각 팀이 영향 받은 역과 노선을 표시하고
전파가 의심되는 경로를 화살표로 그리고
주요 결정 사항을 메모합니다. (예: “14:32에 트래픽을 리전 B로 전환함”)

장애 종료 후에는, 이 지도 전체를 사진으로 남겨서 **사후 분석(Post‑Incident Review)**에서 타임라인을 복원하는 데 활용할 수 있습니다.

6단계: 유지 보수와 리허설 – 공유 멘탈 모델 구축

낡았거나 아무도 쓰지 않는 지도는 오히려 위험합니다. 아날로그 지하철 설계도를 1급 운영 자산으로 취급해야 합니다.

정기적인 유지 보수
- 분기마다(또는 큰 아키텍처 변경 이후) 리뷰
- 새로 생긴 핵심 서비스 추가, 사라진 서비스 제거
- 의존성 노선이 실제 현실을 계속 반영하는지 검증
리허설과 교육
- 지도만 놓고, 대시보드 없이 테이블탑(모의) 연습 진행
- “관측성을 잃었다. 이제 무엇을 할 것인가?” 시나리오를 반복 훈련
- 다양한 팀에서 퍼실리테이터를 돌아가며 맡게 해서, 소유권을 넓게 분산

이런 리허설을 반복하면:

인프라, 애플리케이션, 데이터 팀 간의 공유 멘탈 모델이 형성되고
“뭐가 어디에 있는지”를 두고 소모적으로 논쟁하는 시간을 줄이며
불완전한 정보만 주어져도 비교적 편안하게 의사결정을 내릴 수 있게 됩니다.

실제 “관측성 블랙아웃” 이벤트가 왔을 때, 방 안 사람들은 벽을 멍하니 바라보고만 있지 않습니다. 이미 여러 번 연습해 본 익숙한 내비게이션 도구를 사용하고 있을 것입니다.

결론: 당신의 대시보드가 사라지는 날을 설계하라

대부분의 조직은 모든 도구가 항상 온라인일 것이라는 가정 아래 지나치게 최적화되어 있습니다. 아날로그 장애 대응 지하철 설계도는 정반대 상황에 거는 베팅입니다. 관측성 스택은 정작 가장 필요할 때 실패할 것이라는 전제를 두는 것이죠.

다음과 같은 특성을 가진, 방 한쪽 벽을 채우는 종이 지도를 준비함으로써:

시스템을 명확한 의존성 유형으로 나누고
애플리케이션·데이터 플로우를 지하철 노선도 형태로 시각화하며
영향이 큰 의존성에 우선순위를 두고
관측성 지식과 장애 대응 휴리스틱을 지도 위에 인코딩하고
정기적으로 유지·리허설까지 수행한다면

…당신은 장애, 인증 실패, 벤더 측 사고를 모두 견디는 견고한 로우테크 관측성 레이어를 갖게 됩니다.

관측성이 암흑으로 떨어졌을 때, 팀이 공허한 추측만 하고 있어서는 안 됩니다. 대신, 방 한쪽 벽을 가득 채운 설계도 앞에 서서, 노선을 따라가고, 역을 표시하고, 함께 안정 상태로 돌아가는 길을 찾아가고 있어야 합니다.