아날로그 장애 스토리 나침반 타워: 종이 층을 쌓아 로비에서 옥상까지 장애를 걸어서 이해하기

장애가 터지면 대부분의 팀은 오직 한 가지 목표에 집중합니다. “빨리 복구하자.”

그리고 아드레날린이 빠지자마자 누군가 텅 빈 문서를 열고 이렇게 씁니다. “Post-mortem template(사후 분석 템플릿)”.

대부분 그다음에 일어나는 일은 대충, 얕게, “의무감에 하는 서류 작업”처럼 처리됩니다. 하지만 이 문서는 무슨 일이 있었는지, 왜 그 일이 일어났는지, 어떻게 다시는 반복하지 않을 것인지를 설명해 주는 유일하게 오래 남는 결과물입니다.

초고층 빌딩을 설계하면서 도면 없이 진행하지는 않습니다. 붕괴 후에 기억에만 의존해 재건하지도 않습니다. 장애도 다르지 않습니다.

이 글에서는 하나의 사고방식과 실전 포맷을 소개합니다. “아날로그 장애 스토리 나침반 타워(Analog Incident Story Compass Tower)”—장애 사후 분석을 책상 위에 쌓아 놓은 종이 “층”으로 시각화하고, 로비에서 옥상까지 걸어서 올라가듯 구조화하는 방법입니다. 이 여정 속에서 장애 대응을 건축, 소프트웨어, 비주얼 디자인 같은 설계(디자인) 분야와 연결해 보겠습니다.

왜 Post‑mortem 문서를 “핵심 문서”로 다뤄야 하는가

Post‑mortem은 이런 게 아닙니다:

누군가를 탓하기 위한 산출물
경영진 눈치 보기용 CYA(cover your ass) 보고서
컴플라이언스를 위한 의무 첨부 문서

좋은 Post‑mortem은 이렇게 정의할 수 있습니다:

무슨 일이 있었는지에 대한 표준 기록(canonical record)
조직 전체가 함께 학습하는 공유 학습 자료
비슷한 장애가 터졌을 때, 미래의 대응자가 다시 걸어볼 수 있는 지도

Post‑mortem을 “빨리 끝내야 하는 서류 작업”으로 취급하면, 다음을 잃습니다:

정확한 기억 – 장애 직후의 디테일은 매우 빠르게 사라집니다.
근본적인 원인 – 겉핥기식 요약은 시스템적인 문제를 가려 버립니다.
재사용 가능성 – 허술한 서사는 검색·재활용·교육이 어렵습니다.

항공, 의료, 우주 산업처럼 고신뢰 조직은 이런 문서에 집착에 가깝게 신경 씁니다. 지금 치밀한 서사를 남기는 비용은, 같은 실패를 반복할 때 치르게 될 비용에 비하면 극히 작다는 걸 알기 때문입니다.

여러분의 장애 보고서는 이렇게 말하며 신입에게 자신 있게 건넬 수 있어야 합니다.

“이 문서를 건물 걷듯이 한 번 쭉 걸어봐요. 우리 시스템 구조, 도구, 사고방식을 이해하게 될 거예요.”

나침반 타워 은유: 건물을 걷듯이 장애를 따라 올라가기

모든 장애 Post‑mortem을 책상 위에 펼쳐 놓인 종이 층으로 된 타워라고 상상해 보세요.

로비(Lobby) 는 사람들이 들어오는 입구입니다. 짧고 명확한 사람 중심 요약이 있습니다.
각 층(Floor) 은 서로 다른 이해의 레이어를 뜻합니다.
옥상(Rooftop) 에 올라가면 한 발 물러서서 시스템적 해결책과 설계 인사이트를 조망합니다.

이 타워를 통해 누구나 이렇게 할 수 있어야 합니다.

로비에서 시작해 무슨 일(What) 이 일어났는지 빠르게 파악하고,
층을 하나씩 올라가며 어떻게(How), 왜(Why) 그런 일이 벌어졌는지 이해하고,
옥상에서 무엇을 바꾸었는지, 앞으로 무엇을 다르게 설계할 것인지를 배울 수 있어야 합니다.

이게 바로 여러분의 아날로그 스토리 나침반(Analog Story Compass) 입니다. SRE, 지원 엔지니어, 임원, 신입, 심지어 감사인까지—누구든 이 이야기 속으로 들어오면 길을 잃지 않도록 도와주는 반복 가능한 구조입니다.

이제 층별로 이 타워를 설계해 봅시다.

층별 설계도: 재사용 가능한 Post‑mortem 템플릿

아래는 실무에서 바로 쓸 수 있는 템플릿입니다. 각 섹션을 여러분 타워의 하나의 층이라고 생각하세요.

로비: Executive Story (관리자용 요약)

목적: 비기술자도 이해할 수 있는 짧고 명확한 서사를 제공합니다.

포함해야 할 내용:

사건 이름 & ID
날짜와 시간(타임존 명시)
영향받은 시스템들
영향을 평이한 문장으로 (예: “전체 사용자 중 25%가 42분 동안 로그인할 수 없었습니다.”)
상태 (해결됨, 완화 중, 조사 중 등)

이건 건물의 현관(foyer) 입니다. 누군가 이 부분만 읽어도, 지금 어떤 건물 안에 들어와 있는지 감이 와야 합니다.

1층: 타임라인 워크스루

목적: 서사를 시간 축에 고정합니다.

타임스탬프가 찍힌 이벤트를 사용합니다. (예: “10:14 UTC – 알람 발생 …”)
누가 무엇을 했는지, 어떤 툴이나 대시보드를 썼는지 기록합니다.
자동화 도구도 하나의 액터로 취급합니다. (예: 오토스케일링, 배치 스크립트)

이 층은 벽에 시계가 줄지어 달린 복도를 걷는 느낌입니다. 응답 과정의 흐름과 속도를 한눈에 볼 수 있습니다.

2층: 기술적 해부(Technical Anatomy)

목적: 시스템 구조와 장애 양상을, 학습이 가능할 정도의 깊이로 설명합니다.

시각 자료: 장애 당시 시스템 상태를 보여주는 간단하고 라벨이 붙은 다이어그램 하나
관여한 핵심 컴포넌트 (서비스, 큐, 데이터베이스, 외부 API 등)
무엇이 저하되거나 실패했는지 (예: “Primary DB의 쓰기 지연이 2초 이상으로 급상승.”)

여기서는 소프트웨어 디자인과 비주얼 디자인의 원칙을 차용합니다.

사건들 간에 일관된 도형과 색상을 사용합니다.
다이어그램은 고수준이지만 정확하게 유지합니다.
불필요한 정보는 덜어냅니다. 전체 아키텍처가 아니라, 이번 장애와 관련된 슬라이스만 보여줍니다.

3층: 인과 스토리(Causal Story) – “루트 원인” 하나로 끝내지 않기

목적: 여러 기여 요인이 어떻게 겹치며 장애를 만들어 냈는지 보여줍니다.

단일한 “Root Cause(근본 원인)” 하나를 찍기보다는, 인과의 층(stack) 을 쌓습니다.

방아쇠가 된 이벤트(Triggering event) – 일을 촉발한 계기
기여 조건들(Contributing conditions) – 예: 누락된 알람, 위험한 배포 패턴
시스템 특성(System characteristics) – 예: 백프레셔 부재, 단일 장애 지점(SPOF)
조직적 맥락(Organizational context) – 예: 온콜 피로, 툴링 격차, 모호한 소유권

여기서는 건축과 시스템 설계 관점을 활용합니다.

레이어(layer) 를 떠올리세요. (기초, 구조, 외장)
스스로에게 물어보세요: “이 레이어가 달랐다면, 이 실패는 여전히 일어났을까?”

목표는 일관된 이야기이지, 희생양 찾기가 아닙니다.

4층: 대응 디자인 & 툴링(Response Design & Tooling)

목적: 도구와 프로세스가 실제 대응 과정을 어떻게 형성했는지 분석합니다.

다음 질문에 답해 봅니다.

알람이 얼마나 빨리 감지되고 이해되었나요?
대시보드와 로그는 팀 전체가 쉽게 사용할 수 있었나요, 아니면 몇몇 전문가만?
런북(runbook)은 도움이 되었나요, 혼란을 주었나요, 아니면 무시되었나요?
대응자들이 현장에서 즉석에서 만들어 낸 우회 방법은 무엇이었나요?

여기서는 장애 대응을 UX 디자인 문제로 다룹니다.

온콜 인터페이스가 하나의 제품이라면, 지금 상태로 출시할 수 있겠나요?
“우리 문제인지, 외부 서비스 문제인지” 확인하는 데 클릭 몇 번이 필요하나요?
신입 엔지니어가 몇 분 안에 상황을 파악하는 것이 현실적으로 가능한가요?

이 층에서 더 나은 Incident Management 도구, 지원 리소스(support resources) 에 대한 요구를 명확히 표시합니다.

5층: 의사결정 & 트레이드오프(Decisions & Tradeoffs)

목적: 압박 속에서 내려진 주요 의사결정을 기록합니다.

각 주요 결정마다 다음을 정리합니다.

어떤 옵션들이 검토되었는가?
그중 이 옵션을 선택한 이유는?
어떤 제약 조건이 있었는가? (리스크 허용도, 규제, SLA 등)

이건 곧 건축적 사고입니다. 어떤 건물도 완벽하게 안전하면서, 싸고, 아름다울 수는 없습니다. 트레이드오프를 기록해 두면, 이후 비슷한 결정을 할 때 훨씬 빠르고 명료하게 판단할 수 있습니다.

옥상: 변경 사항, 실험, 장기 설계(Rooftop)

목적: 건물 위로 올라가, 하나의 도시를 내려다보듯 시스템을 조망합니다.

다음 세 부분으로 나눕니다.

즉각적인 수정(Immediate fixes) – 이미 완료된 것들 (설정 변경, 롤백, 신규 알람 추가 등)
단기 액션(Short‑term actions, 수일~수주) – 작은 설계 개선: 문서 보완, 대시보드 튜닝, 플레이북 업데이트
장기 설계 작업(Long‑term design work, 수개월) – 시스템적 프로젝트: 의존성 재설계, 온콜 구조 개편, 교육 프로그램 등

각 액션을 인과 스택의 레이어 중 어디를 강화하는지에 명시적으로 연결하세요. 어느 층을 보강하고 있는지 한눈에 보입니다.

도구를 “아키텍처의 일부”로 보기: 누구나 배울 수 있게 만들어라

아무리 잘 구조화된 Post‑mortem이라도, 장애 대응 도구를 제대로 다룰 줄 아는 사람이 두 명뿐이라면 아무 소용이 없습니다.

Incident Management 도구를 선택·구성할 때, 이를 공공 인프라(public infrastructure) 처럼 다루어야 합니다.

학습 용이성(Learnability): 새 팀원이 하루 만에 “위험하지만 쓸모 있는 수준”으로는 쓸 수 있어야 합니다.
일관성(Consistency): 알람, 런북, 대시보드가 익숙한 패턴을 따르는가?
가시성(Visibility): 채팅, 타임라인, 변경 사항 등을 통해 지금 무슨 일이 벌어지고 있는지 모두가 실시간으로 볼 수 있는가?

그리고 무엇보다, 외부 벤더와 내부 팀에서 제공하는 지원 리소스(support resources) 를 적극 확보·활용해야 합니다.

명확한 문서와 퀵스타트 가이드
짧고 집중된 튜토리얼과 동영상
질문과 답변이 오가는 공유 포럼/채널
정기적인 교육 세션과 장애 대응 드릴(drill)

우리는 단지 소프트웨어만 설계하는 것이 아니라, 학습 환경(learning environment) 을 설계하고 있습니다.

장애 대응을 “복합 설계 문제”로 보기

장애는 그냥 버그가 아닙니다. 장애는 복잡한 설계 문제(complex design problem) 입니다.

기술적 측면: 코드 경로, 페일오버, 성능 동학
사회적 측면: 커뮤니케이션, 역할, 기대치
인지적 측면: 사람들이 스트레스 상황에서 어떻게 지각·추론·행동하는가

다른 분야는 이런 복잡성과 오래 싸워 왔습니다.

건축(Architecture): 하중 경로, 실패 모드, 안전 여유
소프트웨어 설계: 모듈성, 인터페이스, 관측 가능성(observability)
비주얼 디자인: 정보 계층 구조, 대비, 제약 속 가독성

이들의 실천법을 가져옵니다.

스케치: 정교한 지표에 앞서, 먼저 거친 다이어그램을 그립니다.
반복(Iterate): 몇 번의 장애마다 Post‑mortem 템플릿을 계속 다듬습니다.
표준화(Standardize): 시각 패턴과 용어를 재사용합니다.
크리틱(Critique): Post‑mortem을 상태 보고서가 아니라 디자인 리뷰처럼 다룹니다.

장애를 설계의 기회로 다루기 시작하면, 시스템도 팀도 시간이 갈수록 구조적으로 더 단단해집니다.

실전에 옮기기

“아날로그 장애 스토리 나침반 타워”를 도입하려면 다음 단계를 밟아 보세요.

여러분만의 층 정의하기: 위의 섹션들을 바탕으로 조직에 맞는 템플릿을 커스터마이즈합니다.
한 번은 실제로 출력하기: 다음 주요 장애 후, 각 층을 실제 종이로 출력해 책상 위에 층층이 펼쳐 두고 팀과 함께 걸어 보세요.
청사진 다듬기: 아무도 쓰지 않는 섹션은 과감히 제거하고, 필요한 부분을 추가합니다.
도구에 녹이기: 이 템플릿을 Incident Management 플랫폼과 사내 지식 베이스에 그대로 통합합니다.
타워 교육하기: 신입에게 예전 장애 문서를 주고, 로비에서 옥상까지 걸어 올라가듯 읽는 법을 가르칩니다.

시간이 지나면 여러분의 장애 라이브러리는 하나의 스카이라인(skyline) 이 됩니다. 우리가 어떤 일들을 겪어 왔고, 그때마다 어떻게 더 나아졌는지가 한눈에 보이는 풍경입니다.

결론: 걸어볼 만한 타워를 지어라

모든 장애는 이야기를 남깁니다. 하지만 대부분의 조직은 그 이야기의 스케치만 겨우 남깁니다.

Post‑mortem을 핵심 건축 문서로 대하고, 명확하고 재사용 가능한 템플릿을 쓰며, 팀 누구나 익숙해질 수 있는 도구와 지원 리소스를 선택한다면, 장애는 우연한 상처가 아니라 설계된 학습 경험이 됩니다.

“아날로그 장애 스토리 나침반 타워”는 결국 하나의 은유에 불과합니다. 하지만 매우 강력한 은유입니다. 로비에서 옥상까지, 층층이 장애를 걸어서 올라갈 수 있을 때 우리는 드문 능력을 얻게 됩니다. 단지 고장 난 것을 고치는 데서 그치지 않고,

같은 실패가 다시 일어나기 훨씬 더 어려운 미래를 설계하는 능력.