아날로그 장애 지도 캐비닛: 손으로 그린 장애 경로를 동네 도로 지도처럼 정리하기

대형 장애가 터졌을 때 대부분의 운영 워룸에 들어가 보면 비슷한 풍경을 보게 됩니다. 온갖 대시보드가 켜져 있고, 알람은 끊임없이 울리며, 몇몇 사람들은 다급하게 단 하나의 질문에 답하려고 애쓰고 있습니다.

“도대체 어디에서 실제로 깨지고 있고, 그게 지금 무엇까지 같이 말리고 있지?”

수많은 메트릭과 로그 뒤에서, 장애 대응의 실제 작업은 **‘길 찾기’**입니다. 서비스, 큐, 캐시, 외부 의존성들로 이루어진 복잡한 도시를 따라 경로를 추적하려는 시도죠. 실제 도시를 운전해서 다닐 때와 마찬가지로, 좋은 지도가 있으면 훨씬 수월해집니다.

여기서 등장하는 개념이 바로 **아날로그 장애 지도 캐비닛(analog incident map cabinet)**입니다. 의도적으로 저(低)기술이고 시각적인 방식으로, 시스템을 통과해 지나간 장애의 실제 경로를 기록하고 다시 활용하는 방법입니다. 마치 동네 도로 지도를 모아 둔 책자처럼, 장애가 어떤 길로 흘러갔는지 정리해 두는 거죠.

포스트모템보다 먼저 필요한 건 ‘토폴로지 지도’

장애가 터지면 대부분의 팀은 먼저 데이터부터 봅니다. 메트릭, 로그, 트레이스 같은 것들 말이죠. 하지만 맥락 없는 데이터는 지도 없는 위도·경도 좌표와 다를 바 없습니다.

**서비스 의존성 토폴로지 지도(service dependency topology map)**는 다음과 같은 맥락을 제공합니다.

어떤 서비스가 어떤 서비스와 통신하는지
결제, 인증 제공자, 데이터 파이프라인 등의 외부 시스템 의존성은 무엇인지
상태(state)가 어디에 저장되고, 어디에 캐시되는지
실제 사용자가 주로 지나가는 주요 요청 경로는 어디인지

시각화된 매핑이 이해 속도를 끌어올린다

좋은 토폴로지 지도는 다음과 같은 특징을 가집니다.

시각적 – 박스, 화살표, 클러스터, 라벨로 표현되고, 가능한 한 크게 인쇄하거나 화이트보드에 그려진 형태
방향성 – 데이터 흐름과 호출 방향을 보여 주는 화살표
레이어 구조 – 프론트엔드, 백엔드, 데이터, 서드파티 서비스 등 논리적인 레이어 분리

장애가 시작됐을 때, 대응자는 다음과 같이 행동할 수 있습니다.

현재 이상 징후를 보이는 컴포넌트에 큰 빨간 X 표시를 한다.
거기서부터 화살표를 따라 바깥으로 추적하며 누구(어떤 서비스)가 여기에 의존하는지 본다.
또 다른 색으로 **잠재적인 블라스트 레디우스(영향 범위)**를 표시한다.

그러면 금세 상황이 이렇게 바뀝니다.

“에러율이 올랐다”에서 → “서비스 A가 서비스 B에 요청할 때 타임아웃이 발생하고 있고, 이 때문에 B가 데이터베이스 C를 포화시키고 있다”로.

그리고 그걸 눈으로 볼 수 있게 됩니다.

이런 **시각적 의존성 지도(visual dependency map)**는 관측성(observability) 도구를 대체하지 않습니다. 그 도구들을 어떻게 쓸지 ‘프레임’을 제공합니다. 이번 장애 경로에서 어디를 먼저 봐야 할지, 어느 대시보드는 중요하고, 어느 대시보드는 이번에는 노이즈에 불과한지를 알려 줍니다.

교차 서비스 영향: 미스터리에서 예측 가능한 경로로

요즘 시스템은 거의 혼자서는 잘 고장 나지 않습니다. 아래쪽(다운스트림) 서비스의 작은 타임아웃 하나가 연쇄적으로 번져서 사용자에게 보이는 장애로 이어지곤 합니다.

잘 관리된 의존성 지도는 다음을 도와줍니다.

전파 예측 – “이 캐시가 죽으면 이 세 개 서비스가 느려지고, 이 UI는 오래된 데이터를 보여 줄 거야.”
취약한 병목 지점 발견 – 많은 상류 서비스가 의존하는 핵심 서비스는 **단일 장애점(SPOF)**으로 한눈에 보입니다.
안전한 완화 전략 수립 – 어떤 서킷 브레이커, 피처 플래그, 폴백이 어느 경로에 영향을 주는지 시각적으로 파악할 수 있습니다.

장애 중에는 이것이 **근본 원인 분석(RCA)**을 빠르게 만들어 줍니다.

무작정 로그를 뒤지는 대신, 증상에서 출발해 화살표를 따라 가능성이 높은 근원지까지 추적할 수 있습니다.

시간이 지나면 패턴이 보이기 시작합니다. 장애가 자주 따라가는 전형적인 경로들이 눈에 들어옵니다. 마치 “퇴근 시간마다 항상 막히는 도로”를 알게 되는 것과 비슷합니다.

“장애 지도 캐비닛”: 과거 장애 경로의 아틀라스

이제 현재 진행 중인 장애만 지도로 그리는 게 아니라, 그 지도를 계속 보관한다고 상상해 봅시다.

중요한 장애마다 다음을 남깁니다.

손으로 그리거나 단순한 도구로 만든 장애 경로 지도(failure route map)
증상이 처음 나타난 시점, 실제 근본 원인이 있었던 위치 등 타임스탬프와 메모
어떤 완화(mitigation)를 썼고, 어떤 체크가 실패하거나 성공했는지 강조 표시

그리고 이 지도들을 전부 장애 지도 캐비닛에 보관합니다. 진짜 서랍에 넣은 종이 폴더일 수도 있고, 구조화된 디지털 폴더일 수도 있습니다.

시간이 지나면 장애 경로 아틀라스가 쌓입니다. 마치 동네 도로 지도를 모아 둔 책처럼요.

“이건 결제 처리 장애가 날 때마다 따라가는 전형적인 경로야. 벌써 세 번 봤지.”
“이건 피처 플래그 서비스에서 시작하는, 배포가 꼬였을 때의 전형적인 경로.”
“이건 핫 엔드포인트에서 캐시 스탬피드(cache stampede)가 날 때마다 나오는 클래식 패턴이야.”

왜 ‘아날로그’가 중요한가

여기서 **아날로그(손으로 그리기)**를 강조하는 데는 이유가 있습니다.

손으로 그리면 어쩔 수 없이 단순화하게 됩니다. 그 장애에서 실제로 중요했던 것만 남기게 되죠.
사람은 빽빽한 문서보다 그림과 경로를 훨씬 잘 기억합니다.
워룸에서는 종이를 넓게 펼쳐 놓기 쉬워서, 과거 장애 지도 세 장을 나란히 놓고 비교해 볼 수 있습니다.

이렇게 쌓인 지도 캐비닛은 다음과 같은 역할을 합니다.

신규 엔지니어 온보딩을 위한 교육 도구
SRE와 온콜 대응자들을 위한 패턴 라이브러리
아키텍트와 신뢰성 엔지니어를 위한 설계 인풋

이제 매번 완전 백지 상태에서 시작하는 대신, 이렇게 묻게 됩니다.

“이번 장애 경로, 예전에 봤던 어느 지도랑 비슷하지 않아?”

관련 지도를 꺼내 와서 그때 썼던 사고 모델을 재사용하면 됩니다.

구조화된 장애 포스트모템: 이야기를 지도와 연결하기

지도만으로는 충분하지 않습니다. 무슨 일이 있었는지, 왜 그랬는지, 무엇을 배웠는지를 담은 이야기가 필요합니다.

여기서 **구조화된 장애 포스트모템(structured incident postmortem)**이 중요해집니다. 포스트모템은 매 장애를 다음 항목과 함께 정리하도록 강제합니다.

무엇이 일어났는지 – 타임라인, 사용자 영향, 관련 시스템
왜 일어났는지 – 기술적·조직적 기여 요인
무엇을 배웠는지 – 설계 결함, 프로세스 구멍, 관측성 블라인드 스팟
무엇을 바꿀지 – 구체적이고 책임자와 기한이 있는 후속 조치

표준 템플릿의 힘

표준화된 포스트모템 템플릿을 사용하면 일관성을 얻을 수 있습니다.

모든 장애 보고서가 같은 핵심 질문에 답하게 됩니다.
시간에 따라 여러 장애를 비교해 보고, 시스템적인 문제를 찾을 수 있습니다.
신규 대응자도 무엇이 어디에 있는지, 무엇을 써야 하는지 금방 익힐 수 있습니다.

좋은 템플릿에는 다음이 포함됩니다.

요약(Summary) – 한 단락짜리 설명, 심각도, 장애 지속 시간
고객 영향(Customer impact) – 누가, 어떻게 영향을 받았는지
기술적 영향(Technical impact) – 관련 서비스, 데이터, 의존성
타임라인(Timeline) – 탐지부터 복구까지 핵심 이벤트
근본 원인 분석(Root cause analysis) – 마지막 버그 하나가 아니라, 그에 이르기까지의 원인 체인
기여 요인(Contributing factors) – 빠진 알람, 애매한 런북, 오해를 부른 대시보드 등
잘된 점 / 부족했던 점(What went well / poorly) – 좋은 관행은 강화하고, 나쁜 패턴은 드러내기 위해
액션(Action items) – 설계 변경, 테스트 개선, 프로세스 업데이트
첨부(Attachments) – 이 장애에 대한 장애 경로 지도(failure route map) 포함

마지막 항목이 특히 중요합니다. 아날로그 장애 지도는 필수 첨부물이어야 합니다. 포스트모템은 이야기를 들려주고, 지도는 그 이야기가 지나간 길을 보여 줍니다.

신뢰성과 유지보수성(R&M): 그냥 운전이 아니라 도시를 설계하기

장애 대응은 이미 존재하는 도시 안에서 길을 찾아다니는 일입니다. 반면, 신뢰성과 유지보수성(Reliability & Maintainability, R&M) 엔지니어링은 애초에 더 나은 도시를 설계하는 일입니다.

R&M은 시스템 설계 초기 단계에서 개입해 다음을 목표로 합니다.

가용성(availability) 향상 – 장애 횟수와 지속 시간 줄이기
라이프사이클 비용(lifecycle cost) 절감 – 소방전처럼 뛰어다니는 시간을 줄이고 유지보수 비용 낮추기
장애가 났을 때 진단과 복구를 단순화하기

여기서 과거 장애 지도 아틀라스는 R&M 작업에 있어 금광 같은 자원입니다.

반복해서 나타나는 경로는 만성적인 설계 약점을 드러냅니다.
지도가 복잡하게 얽힌 구간은 아키텍처가 지나치게 엉켜 있는 부분을 보여 줍니다.
특정 서비스에 의존하는 경로가 유난히 많다면, 그건 위험한 중앙집중화의 신호입니다.

처음부터 유지보수성을 설계에 녹여 넣기

장애가 어떻게 흘러가는지 알고 있다면, 유지보수성을 애초 설계에 박아 넣을 수 있습니다.

중요 경로에 내장된 테스트: 헬스 체크, synthetic transaction, 서비스 간 계약 테스트(contract test) 등
타깃형 진단 장치: 약점으로 드러난 지점에 더 풍부한 로그와 트레이스, 서비스 간 명확한 에러 메시지
격리 메커니즘: 자주 문제를 일으키는 경로에 서킷 브레이커, 벌크헤드(bulkhead), 우아한 강등(graceful degradation) 설계
온콜 친화성 개선: 실제로 자주 발생한 장애 경로에 맞춰 미리 정렬된 런북과 대시보드

이런 것들을 앞단에서 설계해 두면, 이후 장애 진단과 복구에 드는 위험, 시간, 비용을 크게 줄일 수 있습니다. “다음 장애는 좀 덜 힘들겠지”라고 막연히 기대하는 수준이 아니라, 그럴 수밖에 없도록 설계하는 것입니다.

나만의 장애 지도 캐비닛 시작하기

이걸 시작하는 데 거창한 도구 투자가 필요하지는 않습니다. 작게, 가볍게 시작하면 됩니다.

살아 있는 토폴로지 지도 만들기
- 상위 레벨의 서비스 의존성 지도를 만든다.
- 크게 인쇄하거나, 화이트보드에 상시 그려 둔다.
- 분기마다, 또는 큰 아키텍처 변경 이후에 업데이트한다.
장애 중에는 ‘경로’를 그리기
- 최초 증상이 나타난 지점을 표시하고, 근본 원인까지의 경로를 추적해 그린다.
- 색을 다르게 써서 증상, 원인, 완화책을 구분한다.
- 예술성은 신경 쓰지 말고, 명확함이 미관보다 우선이라고 생각한다.
포스트모템 템플릿 표준화하기
- 필수 섹션으로 **“장애 경로 지도(Failure Route Map)”**를 추가한다.
- 아날로그로 그렸다면 스캔이나 사진을 찍어 링크하거나 첨부한다.
캐비닛 만들기
- 물리적: 날짜나 장애 유형별로 라벨을 붙인 폴더에 보관한다.
- 디지털: database, cache, third-party, deployment 같은 태그를 붙인 폴더 구조나 위키 공간을 만든다.
아틀라스를 주기적으로 리뷰하기
- 신뢰성 리뷰나 설계 논의 때 이 아틀라스를 꺼내 쓴다.
- “이번 변경으로 어떤 기존 장애 경로를 아예 불가능하게 만들 수 있지?”라고 질문해 본다.
- 반복적으로 등장하는 경로를 R&M 투자 근거로 삼아 이해관계자를 설득한다.

맺음말: 수치를 넘어서, 장애를 ‘읽을 수 있게’ 만들기

장애는 언제든 일어납니다. 목표는 모든 장애를 피하는 것이 아니라, 장애가 터졌을 때 얼마나 빨리 이해하고, 가두고, 거기서 배우느냐입니다.

아날로그 장애 지도 캐비닛, 그리고 그 바탕이 되는 명확한 토폴로지 지도, 구조화된 포스트모템, R&M 중심 설계는, 개별 장애들을 서로 동떨어진 위기가 아니라 연결된 지형으로 바꿔 줍니다.

이제는 매 장애를 완전히 새로운 미스터리로 대하지 않고, 익숙한 도로, 자주 서는 교차로, 우회로를 인식하게 됩니다. 시간이 지나면, 이 지도들은 단지 현재의 도시를 묘사하는 데 그치지 않고, 여러분이 원하는 더 안전하고 신뢰할 수 있는 도시를 설계하는 데 기여하게 됩니다.

그리고 다음번 워룸에서 누군가가 *“지금 이게 정확히 어디에서 깨지고 있는 거야?”*라고 물으면, 더 이상 로그와 추측만 들이밀 필요가 없습니다. 여러분에겐 지도가 있고, 길을 안내해 줄 역사 한 캐비닛이 있으니까요.