아날로그 장애 스토리 스케치북: 최악의 장애를 한 장짜리 만화로 그리기

엔지니어링 팀은 정말 말도 안 되는 장애들을 겪으며 살아갑니다.

이런 것들 말이죠:

새벽 3시에 벌어진 데이터베이스 페일오버로 세 개 리전의 결제가 모두 멈춰 버린 사건
“별 거 아니라고 생각했던” 설정 변경이 조용히 트래픽을 블랙홀로 빨아들인 사건
모두가 대수롭지 않게 넘겼던 모니터링 알림이… 더 이상 무시할 수 없게 된 순간

우리는 이런 인시던트들을 늘 글로 남깁니다. 포스트모템, 인시던트 리포트, RCA 문서 등. 하지만 이런 문서는 대개 건조하고, 길고, 잘 기억도 나지 않습니다.

이걸 남기는 또 다른 방법이 있습니다. 직접 그리는 것입니다.

이 글은 여러분의 최악의 장애들을 명확하고, 재미있고, 잊기 힘든 이야기로 바꿔 주는 “인시던트 스토리 스케치북”—한 장짜리 만화에 대한 이야기입니다.

왜 장애를 굳이 그림으로 그려야 할까?

우리는 장애를 잘 이야기로 생각하지 않습니다. 하지만 모든 장애에는 분명한 내러티브 구조가 있습니다.

설정(Setup) – 원래 시스템이 어떻게 동작해야 하는지
방아쇠(Trigger) – 문제가 시작되는 계기
격화(Escalation) – 혼란, 실패한 가설들, 예상 못 한 부작용들
해결(Resolution) – 수정, 롤백, 혹은 완화 조치
교훈(Lesson) – 이전에는 몰랐지만 이제는 알게 된 것

포스트모템은 보통 이걸 담아 보려고 하지만, 타임라인과 로그, 스크린샷 속에 파묻혀 버리기 쉽습니다.

한 장짜리 만화는 여러분에게 이렇게 강제합니다:

모든 디테일이 아니라, 이야기 자체에 집중할 것
모든 Slack 메시지가 아니라, 핵심적인 의사결정에만 초점을 맞출 것
단순한 다이어그램이 아니라, 시스템이 살아 움직이는 존재처럼 행동하는 모습을 보여 줄 것

그리고 시각적이기 때문에, 특히 시스템에 깊이 관여하지 않은 사람일수록 “무슨 일이 진짜로 일어났는지”를 훨씬 더 쉽게 이해할 수 있습니다.

시각적 스토리텔링은 복잡한 시스템을 ‘탁’ 하고 이해시키는 힘이 있다

요즘 시스템은 복잡합니다. 마이크로서비스, 큐(queue), 캐시(cache), rate limiting, circuit breaker, feature flag… 이런 모든 것을 텍스트로만 설명하려 하면, 작은 RFC 한 편을 읽는 느낌이 됩니다.

만화는 훨씬 더 넓은 표현 대역폭을 제공합니다.

화살표와 흐름으로 인시던트 동안 데이터나 트래픽이 어떻게 움직였는지 보여 주기
패널로 장애 이전, 중간, 이후를 한눈에 보여 주기
나란히 비교해서 “우리가 벌어졌다고 생각한 일” vs. “실제로 벌어진 일”을 대비시키기
아이콘과 비유 사용하기 (예: 캐시는 냉장고, 큐는 카페 줄 서 있는 사람들처럼 그리기)

시각 요소는 텍스트만으로는 전달하기 어려운 부분을 보완해 줍니다. 예를 들어:

계속 행복하게 서비스를 이용하던 사용자들이 갑자기 작은 게이트웨이 박스 하나 앞에서 병목에 걸려 줄 서 있는 패널 하나가, 세 단락에 걸친 “로드 밸런서 포화 상태” 설명보다 훨씬 직관적으로 혼잡을 보여 줍니다.
엔지니어의 머릿속 모델 다이어그램과 실제 프로덕션 트래픽 패턴을 좌우로 나눠 보여 주면, 잘못된 가정이 왜 잘못된 대응으로 이어졌는지 단번에 이해됩니다.

“우리는 레이턴시 원인을 잘못 진단했다”고 말로 쓰는 대신, 팀이 처음에 따라간 경로와 실제로 문제였던 경로를 그림으로 보여 줄 수 있습니다.

유머와 “부검 만화”로 정서적 부담 낮추기

장애는 감정적으로도 무게가 큽니다.

사람들은 지치고 스트레스를 받습니다.
고객은 화가 나 있을 수 있습니다.
리더십은 불안합니다.

이런 분위기에서는, 아무리 “블레이밍은 없다”고 해도 포스트모템이 위협적으로 느껴지기 쉽습니다.

여기서 유머와 기발한 시각적 장치가 온도를 낮춰 줍니다. 말하자면, 적당히 위트 있는 “카툰 부검” 같은 겁니다.

어떤 서비스가 의존성이 타임아웃 되자 캐릭터처럼 과장되게 “기절”하는 모습
feature flag를 거대한 빨간 스위치로 그려서, 누군가 방향을 잘못 내렸다가 부랴부랴 다시 돌리는 장면
모두 자고 있을 때 허공을 향해 계속 소리치는 캐릭터로 묘사된 알림 대시보드

포인트는 사람을 비웃는 게 아니라, 다음을 가능하게 하는 데 있습니다.

인시던트를 편하게 이야기할 수 있는 분위기 만들기
사람들이 자신의 혼란과 모르던 점을 솔직하게 인정하게 만들기
우리가 여기서 하는 일은 “누굴 탓하는 게 아니라, 배우는 것”이라는 메시지 강화하기

터미널을 멍하니 바라보는 자기 자신 위에 “???”가 떠 있는 패널을 보고 웃을 수 있다면, 모른다는 것 자체가 인시던트 대응 과정의 자연스러운 일부라는 사실을 팀이 공유하게 됩니다.

장애를 ‘이야기’ 구조로 정리하기

좋은 한 장짜리 인시던트 만화는 고전적인 내러티브 구조를 그대로 따릅니다.

설정(Setup)
정상적인 세계를 보여 줍니다.
- 패널: 행복한 사용자들, 초록색 대시보드, 원래 설계대로 동작하는 시스템 다이어그램.
방아쇠(Trigger)
일이 잘못되기 시작하는 순간입니다.
- 패널: 작은 설정 변경 커밋, 실패하는 의존성, 갑작스러운 트래픽 급증.
격화(Escalation)
혼란, 잘못된 추론, 복합적인 영향이 드러나는 단계입니다.
- 패널들: 여러 엔지니어가 각자 다른 가설을 시험해 보는 장면, 예기치 못한 부작용, 불길하게 치솟는 그래프.
해결(Resolution)
전환점과 최종적인 해결이 일어나는 순간입니다.
- 패널들: “아하!” 하는 깨달음, 결정적인 변경, 시스템이 서서히 정상으로 돌아가는 모습.
교훈(Lesson)
앞으로 무엇을 다르게 할지 정리합니다.
- 패널: 새 알림, 런북, 혹은 세이프가드 덕분에 혜택을 보는 미래의 엔지니어.

이 구조로 장애를 정리하면, 단지 만화가 잘 나오는 것에서 그치지 않습니다. 다음을 돕습니다.

인과 관계를 더 선명하게 드러내기 (무엇이 무엇을 불렀는지)
결정적 의사결정 포인트를 강조하기
다른 팀이 이 사례를 자기 시스템에 전이 학습하기 쉽게 만들기

이 스토리 아크는 조직 전체가 재사용할 수 있는 하나의 템플릿이 됩니다.

왜 SRE와 이렇게 잘 맞는가

Site Reliability Engineering(SRE)의 핵심은 다음과 같습니다.

운영을 엔지니어링 문제로 다루기
인시던트를 체계적이고 반복 가능하게 처리하기
실패를 두려워하기보다, 그로부터 학습하기

장애를 **“소프트웨어 이야기”**로 바라보는 시각은 이와 깊이 맞닿아 있습니다.

이야기는 다시 재생할 수 있습니다: 신입, 파트너 팀, 리더십과 함께 여러 번 되짚어 볼 수 있습니다.
이야기는 패턴을 만들어 냅니다: 사례가 쌓일수록 반복되는 안티패턴, 맹점, 사회기술적(sociotechnical) 이슈들이 보입니다.
이야기는 공유하기 쉽습니다: 한 장짜리 만화는 Slack 채널, 위키, 슬라이드 어디에 붙여도 의미가 통합니다.

여러분의 인시던트 스토리 스케치북은 곧 이런 것들의 시각적 라이브러리가 됩니다.

예상하지 못했던 엣지 케이스들
잘못 이해하고 있었던 시스템 상호작용들
압박 속에서 다듬어진 운영 관행들

시간이 흘러도, 이 라이브러리는 조직이 단지 장애를 “버티기만” 한 것이 아니라, 그로부터 배워 왔다는 증거가 됩니다.

한 장짜리 제약이 주는 힘

왜 굳이 한 페이지로 제한할까요?

제약은 생각을 더 날카롭게 만듭니다.

한 장 안에 담으려면, 반드시 선택해야 합니다.

정말 중요한 세네 가지 사건만 고르기
실제 결과를 바꾼 한두 개 핵심 결정만 남기기
가장 명확한 단 하나의 교훈으로 압축하기

이 규율은 다음과 같은 자연스러운 욕구와 싸우게 만들어 줍니다.

Slack 대화를 통째로 복사해 넣고 싶은 욕구
모든 메트릭과 그래프를 붙이고 싶은 욕구
사소한 기여 요인까지 전부 나열하고 싶은 욕구

대신 이런 질문을 던지게 됩니다.

6개월 뒤의 미래 엔지니어가 이 사건에서 딱 하나만 기억해야 한다면, 그게 무엇일까?
이 오해 하나만 미리 잡았더라면, 대부분의 사태를 막을 수 있었을까?
이번에 우리는 “현실의 시스템이 실제로 어떻게 동작하는지”에 대해 무엇을 새로 배웠을까?

이 질문들에 대한 답이 바로 한 페이지를 떠받치는 골격이 됩니다.

인시던트 스토리 스케치북, 이렇게 시작해 보기

그림 실력은 중요하지 않습니다. 막대기 인간도 괜찮고, 박스와 화살표만으로 그려도 충분합니다. 중요한 건 완성도가 아니라 명료함입니다.

1. 포맷을 정하기

인시던트 워룸 근처에 두는 실물 노트
Miro, Figma, Excalidraw, Google Slides 같은 도구에 만든 공유 템플릿
4–6개 패널과 “교훈(Lesson)” 박스가 있는 재사용 가능한 PDF나 화이트보드 레이아웃

2. 단순한 템플릿 정의하기 (페이지별)

제목: “캐시가 모든 걸 잊어버린 날” 처럼 기억에 남게 짓기
스토리 아크를 담을 4–6개 패널
데이터베이스, 큐, 서비스, 사용자 등에 쓰는 아이콘 작은 범례
하단 섹션: “우리가 배운 것(What We Learned)” (불릿 목록 혹은 하나의 큰 시각 요소)

3. 포스트모템을 ‘대신’하는 게 아니라, 끝난 뒤에 그리기

평소처럼 인시던트 리뷰를 진행합니다.
회의록과 타임라인을 만화의 원재료로 사용합니다.
스스로에게 묻습니다: “이걸 짧은 만화로 만든다면, 패널은 어떤 장면들일까?”

4. 팀 전체를 참여시키기

모두에게 묻습니다: “이 페이지에 꼭 들어가야 한다고 생각하는 순간이 하나 있다면?”
의외의 순간, 잘못된 시도, 아슬아슬했던 순간들도 담습니다.
원한다면, 사람들이 각자 다른 패널을 하나씩 맡아 그리게 해도 좋습니다.

5. 보관하고, 공유하기

스케치북의 집을 정합니다 (repo, 위키 페이지, 실물 바인더 등)
온보딩, 브라운백 세션, SRE 리뷰 때 이 만화들을 참고합니다.
새로운 인시던트가 예전 사례와 비슷해 보이면, 옛 페이지를 꺼내 와서 비교합니다.

시간이 지나면, 이 스케치북을 넘겨 보는 일은 곧 여러분 신뢰성 여정의 ‘베스트 앨범’을 읽는 경험이 됩니다.

고통스러운 장애에서 ‘공유되는 전설’로

어느 팀에나 이미 장애 전설이 있습니다. “그때 기억나지? 그 사건 말이야…”로 시작해서 교훈으로 끝나는 이야기들 말입니다.

아날로그 인시던트 스토리 스케치북은 이런 구전 전설을 다음과 같이 바꿔 줍니다.

우연히 남는 기억이 아니라, 의식적인 실천으로
흩어진 이야기 조각이 아니라, 시각적인 지식 베이스로
가장 스트레스 받았던 순간들을 다루는 안전하고, 심지어는 약간 장난기 있는 방식으로

물론 여전히 탄탄한 인시던트 커맨드, 블레이밍 없는 포스트모템, 좋은 메트릭, 실행 가능한 후속 조치가 필요합니다. 하지만 그 위에 한 장짜리 만화를 얹으면 다음과 같은 것들을 덤으로 얻습니다.

새 엔지니어를 더 빠르게 온보딩하기
시스템이 어떻게 실패하는지 팀 간 이해를 더 잘 맞추기
인시던트에 대한 감정적 거리두기를 건강하게 만들기

최악의 장애들이 빽빽한 문서와 불편한 기억 속에만 갇혀 있을 필요는 없습니다. 그 장애들은 스케치북 속에서—페이지 한 장 한 장—그래프가 다시 초록으로 돌아간 뒤에도 계속해서 우리를 가르칠 수 있습니다.

펜을 집어 드세요. 다음 포스트모템을 그려 보세요.