Rain Lag

아날로그 인시던트 스토리보드 월: 프로덕션 장애를 한 칸씩 그려보는 종이 코믹스로 바꾸기

프로덕션 인시던트를 아날로그 스토리보드 코믹스로 바꿔서, 포스트모템을 더 잘하고, 근본 원인 분석을 날카롭게 만들고, 새 도구나 대시보드 없이도 팀이 더 빨리 배우도록 돕는 방법을 소개합니다.

아날로그 인시던트 스토리보드 월: 프로덕션 장애를 한 칸씩 그려보는 종이 코믹스로 바꾸기

프로덕션 장애가 터졌을 때, 대부분의 엔지니어가 제일 마지막으로 떠올리는 건… 만화 그리기입니다.

하지만 제가 봤던 가장 효과적인 인시던트 리뷰 방식들 중 상당수는 대시보드나 타임라인에서 시작하지 않습니다. 대신 벽 하나, 포스트잇이나 인덱스 카드 뭉치, 그리고 펜 몇 자루에서 시작합니다.

이 글에서는 **“아날로그 인시던트 스토리보드 월(Analog Incident Storyboard Wall)”**을 소개합니다. 팀이 겪은 가장 고통스러운 장애를, 모두가 이해할 수 있는 한 프레임씩 나뉜 종이 코믹스로 바꾸는 방법입니다. 그러면서 이 아날로그 접근을 요즘 인시던트 운영 방식과 연결해 보겠습니다.

  • 커스터마이즈 가능한 포스트모템 템플릿
  • 파이브와이즈(Five Whys) 기법
  • 포스트모템 초안의 조기 공유
  • 숙련된 포스트모템 작성자의 역량 활용
  • 복잡한 의사결정을 위한 시각적·내레이션 기반 스토리텔링

왜 굳이 인시던트를 만화로 만들어야 할까?

인시던트는 그 자체로 이미 스트레스도 많고 복잡합니다. 여기에 그림까지 더해야 할까요?

그 이유는, 인시던트가 본질적으로 **‘이야기’**이기 때문입니다.

  • 시작 상태 (“모든 게 평소 같았는데… 갑자기 달라졌다”).
  • 트리거 (“09:42에 배포가 이뤄지면서 쿼리 경로가 변경됐다”).
  • 고조되는 전개 (알람, 슬랙 메시지, 대시보드, 추측, 롤백 시도).
  • 해결 (롤백, 패치, 혹은 임시 우회).
  • 교훈 (다음에는 무엇을 다르게 할 것인가).

문제는 대부분의 포스트모템이 이 이야기를 빽빽한 문서와 타임라인에 담는다는 점입니다. 그래서:

  • 신규 팀원은 압도되고
  • 핵심 의사결정 지점은 가려지고
  • 유능한 사람들이 그 긴박한 순간에 그런 선택을 했는지가 잘 드러나지 않습니다.

반면, 만화처럼 프레임 단위로 잘게 나눈 스토리보드는 팀이 다음을 강제로 하게 만듭니다.

  • 속도를 늦추고, 사건을 개별 순간들로 다시 구성하기
  • 보이지 않던 것들(가정, 오해, 막다른 시도)을 눈에 보이게 만들기
  • 해결책으로 바로 뛰어들기 전에, 공통된 이해를 맞춰 두기

그리고 이 작업을 다 같이 서서, 종이를 벽에 붙이며 할 때, 디지털 도구로는 거의 얻기 힘든 것을 얻게 됩니다. 바로 공유된 물리적 집중과 몸으로 기억하는 경험입니다. 사람들은 자신이 함께 만들어 본 것을 훨씬 더 잘 기억합니다.


1단계: 커스터마이즈 가능한 포스트모템 템플릿부터 준비하기

포스트잇을 벽에 붙이기 전에, 먼저 구조화돼 있으면서도 커스터마이즈 가능한 포스트모템 템플릿을 마련합니다.

좋은 템플릿은:

  • 기본 정보(언제, 무엇이, 누가, 어떤 영향)를 표준화하고
  • 서술과 해석을 위한 여백을 남기며
  • 더 깊은 분석(파이브와이즈, 기여 요인, 후속 조치)을 자연스럽게 이끌어 줍니다.

예를 들어 다음과 같은 섹션을 포함할 수 있습니다.

  1. 인시던트 요약(Incident Summary)
    한 문단으로, 쉬운 언어로 작성합니다: 무엇이, 누구에게, 어떻게 일어났고 어떻게 끝났는지.

  2. 영향 설명(Impact Description)
    누가 영향을 받았는지(고객, 내부 팀), 얼마나 심각했는지, 얼마나 오래 지속됐는지.

  3. 타임라인(상위 수준 Timeline)
    주요 이벤트를 시간 순서대로: 탐지 시점, 주요 의사결정, 핵심 액션.

  4. 서술: 그 순간에 느끼기엔 어땠는가
    엔지니어와 대응자가 1인칭으로 쓸 수 있는 공간: 무엇을 봤고, 어떻게 생각했고, 무엇을 시도했는지.

  5. 분석(파이브와이즈, 기여 요인)
    “무슨 일이 있었는가”에서 “왜 그 일이 일어났는가”로 넘어가는 부분.

  6. 후속 조치 및 예방 액션(Follow‑Ups & Preventive Actions)
    우선순위와 오너가 명확한 개선 사항의 짧은 목록.

템플릿이 커스터마이즈 가능해야 하는 이유는:

  • 스토리보딩을 돕는 프롬프트를 추가할 수 있고 (예: “핵심 의사결정 5–10개를 적으세요”)
  • 인시던트 심각도에 따라 내용을 조정할 수 있고
  • 조직의 규범과 기대를 반영할 수 있기 때문입니다.

이 템플릿은 이후 만들 아날로그 스토리보드가 기대는 ‘뼈대’ 역할을 합니다.


2단계: 파이브와이즈를 ‘영향’에서 거꾸로 적용하기

파이브와이즈(Five Whys) 기법은 보통 이렇게 소개됩니다. 문제를 정하고, “왜?”를 다섯 번 묻다 보면 근본 원인에 도달한다.

실제로는 많은 팀이:

  • 한두 번 “왜?”를 묻고 너무 일찍 멈추거나
  • 기술적인 단일 루트 코즈에만 집착하고, 프로세스나 인간적 요소는 무시하곤 합니다.

스토리보드 월은 파이브와이즈를 명확한 영향 설명에서 시작해 거꾸로 거슬러 올라갈 때 가장 잘 작동합니다.

“EU 지역 고객이 53분 동안 auth 서비스에서 반복되는 500 에러로 인해 로그인할 수 없었다.”

여기서부터 시작합니다.

  1. 왜 고객이 500 에러를 보았는가?
    auth 서비스가 DB 커넥션을 소진했기 때문이다.

  2. 왜 DB 커넥션이 소진됐는가?
    새로운 배포에서 인덱스를 사용하지 않는 쿼리가 추가되었고, 이 쿼리가 타임아웃을 유발했기 때문이다.

  3. 왜 인덱스가 없는 쿼리가 프로덕션까지 올라갔는가?
    프리프로덕션(pre‑prod) 환경이 프로덕션 수준의 데이터 볼륨을 반영하지 못하기 때문이다.

  4. 왜 프리프로덕션이 프로덕션 볼륨을 반영하지 못하는가?
    현실적인(비식별 처리된) 데이터셋과 그것을 유지관리할 시간이 없기 때문이다.

  5. 왜 그런 환경에 투자하지 않았는가?
    책임자가 명확하지 않았고, 이번 인시던트 전까지는 그 리스크가 가시화되지 않았기 때문이다.

각 “왜”는 그대로 벽 위의 프레임이 될 수 있습니다.

  • ‘왜’ 하나당 포스트잇 한 장
  • 짧은 설명과 간단한 스케치나 아이콘
  • 필요하다면 로그, PR, 대시보드 링크를 적을 수 있지만, 어디까지나 참고용으로만

이렇게 영향에서부터 거꾸로 시각화하며 걸어가다 보면, 루트 코즈는 결코 하나가 아니라는 걸 보여 줍니다. 늘 기술·조직·사람이 섞인 연결된 사슬입니다.


3단계: 아날로그 스토리보드 월 만들기

이제 본격적으로, 인시던트를 만화처럼 만들어 봅니다.

준비물

  • 포스트잇 또는 인덱스 카드(색깔을 여러 개 쓰면 좋습니다)
  • 마커나 펜(멀리서도 읽을 수 있을 정도의 두께)
  • 충분한 공간이 있는 벽이나 화이트보드

기본 레이아웃

벽을 여러 레인(lane)으로 나눕니다.

  • 시간 레인(Time Lane) – 왼쪽이 시작, 오른쪽으로 갈수록 해결 시점
  • 행위자 레인(Actors Lane) – 온콜, SRE, 기능팀, 고객지원 등
  • 상태 레인(State Lane) – 시스템 상태(정상, 성능 저하, 장애, 복구 중)
  • 의사결정 레인(Decision Lane) – 핵심 결정, 가설, 분기점

프레임별로 스토리 재구성하기

  1. 탐지 시점에서 시작하기

    • 프레임 예: "PagerDuty 알람 – /login 레이턴시 스파이크"
    • 그림: 작은 페이저나 휴대폰 아이콘
  2. 관측 내용을 추가하기

    • 대응자들이 처음에 무엇을 봤는지
    • 어떤 대시보드나 로그를 열어봤는지
    • 당시 무엇이 일어나고 있다고 믿었는지
  3. 의사결정과 분기점 표시하기

    • "마지막 배포를 롤백하기로 결정"
    • "DB 커넥션 수를 증가시킴"
    • 관측 vs. 의사결정은 색깔을 다르게 쓰면 좋습니다.
  4. 실수와 막다른 길도 담기

    • "처음에는 CDN 문제로 오해해 15분을 소모"
    • 이런 건 메인 타임라인에서 가지를 쳐 나갔다가, 다시 본선으로 돌아오는 형태로 그립니다.
  5. 해결과 후속 조치에서 마무리하기

    • 프레임: "롤백 완료; 에러율이 기준선으로 복귀"
    • 프레임: "새 쿼리에 인덱스 추가 및 프리프로덕션 개선 티켓 생성"

엔지니어들은 직접 포스트잇을 옮기고, 순서를 놓고 토론하고, 문구를 다듬습니다.

이런 촉각적·시각적 협업 방식은:

  • 숨겨진 가정을 드러내고(“잠깐, 난 DB 리밋 변경 전에 롤백한 줄 알았는데?”)
  • 실제 의사결정의 복잡성을 보여 주며
  • 나중에 글로 옮길 때 기반이 되는, 모두가 공유하는 하나의 이야기를 만들어 줍니다.

4단계: 포스트모템 초안 작성 후, 미리 공유하기

벽 위의 스토리가 어느 정도 일관되게 정리되면, 이제 이를 포스트모템 초안으로 옮깁니다.

여기서 1단계에서 만든 템플릿이 크게 역할을 합니다.

  • 타임라인 섹션에는 스토리보드의 프레임을 시간순 이벤트로 옮깁니다.
  • 서술 섹션에는 사람 이야기—혼란, 트레이드오프, 커뮤니케이션—를 담습니다.
  • 분석 섹션에서는 앞에서 만든, 영향에서 거꾸로 올라온 파이브와이즈를 녹여 넣습니다.

그리고 포스트모템 회의 24시간 전쯤에 초안을 공유합니다. 예를 들면 전용 슬랙 채널에 올립니다.

초안을 미리 공유하면:

  • 회의 전에 사실 관계 오류를 바로잡을 수 있고
  • 인시던트 당시 조용했던 사람들도 자신의 관점을 추가할 수 있으며
  • 회의 시간 중 ‘무슨 일이 있었는지 복원하는 데’ 쓰이는 시간을 줄이고, 학습과 후속 조치 논의에 더 집중할 수 있습니다.

리뷰어들에게는 스타일과 내용 둘 다에 대해 피드백을 달라고 요청합니다.

  • 영향이 고객 관점에서 명료하게 설명돼 있는가?
  • 실수와 시행착오를 솔직하게 드러내되, 개인을 비난하지 않고 있는가?
  • 약어와 서브시스템 이름이 비전문가도 이해할 수 있게 쓰였는가?

이 사전 피드백 단계에서, 아날로그 스토리보드가 준 명료함이 명확하고 공유 가능한 문서로 바뀌게 됩니다.


5단계: 숙련된 포스트모템 작성자를 적극 활용하기

모든 사람이 글쓰기를 좋아하는 것도 아니고, 혼란스러운 사건을 명쾌한 글로 정리하는 데 능숙한 것도 아닙니다.

포스트모템 작성 자체를 하나의 ‘기술’로 보고, 잘하는 사람들의 역량을 의도적으로 활용하세요.

  • 경험이 적은 인시던트 커맨더에게, 글을 잘 쓰는 사람을 짝으로 붙여 주기
  • ‘포스트모템 에디터’ 역할을 지정해 초안을 검토·다듬기
  • 잘 쓴 포스트모템을 모아 ‘베스트 프랙티스 라이브러리’를 만드는 것

숙련된 작성자는 다음을 특히 잘 다듬습니다.

  • 디테일의 수준 – 도움이 될 만큼은 자세하지만, 중요한 내용이 묻히지 않도록
  • 중립적이고 사실 중심의 톤 – 사람을 평가하지 않고, 행동과 결정을 기술하는 방식으로
  • 이야기의 흐름 – 영향 → 대응 → 분석 → 액션으로 이어지는 명확한 스토리라인

스토리보드 월이 있으면 이들의 작업도 훨씬 쉬워집니다. 구조가 이미 눈앞에 있기 때문입니다. 그들은 단지:

  1. 프레임 순서를 따라가며
  2. 이를 자연스러운 문장으로 옮기고
  3. 그 안에 파이브와이즈와 기여 요인을 엮어 넣기만 하면 됩니다.

시간이 지날수록, 이런 멘토링을 통해 조직 전체의 인시던트 문서화 수준이 올라갑니다.


6단계: 시각적·내레이션 기반 스토리텔링으로 교육과 정렬 맞추기

아날로그 인시던트 스토리보드 월의 진짜 힘은, 교육과 조직 정렬(alignment) 측면에서 발휘됩니다.

포스트모템 회의에서:

  • 벽 앞에 서서, 마치 만화를 해설하듯이 이야기를 처음부터 끝까지 걸어가며 설명합니다.
  • 각 프레임을 가리키며, 그때 무엇을 알고 있었는지, 무엇을 생각했는지, 무엇을 결정했는지를 이야기합니다.
  • 중요한 분기점에서는 멈추고: “여기에서 우리는 기능 플래그 대신 롤백을 택했습니다. 왜 그랬는지 같이 얘기해 봅시다.”

이런 시각적 내러티브 형식은 다음을 돕습니다.

  • 신규 팀원이 20페이지짜리 문서를 읽지 않고도 복잡한 시스템과 상황을 이해하도록
  • 크로스펑셔널 파트너(고객지원, 프로덕트, 리더십)가 중요한 트레이드오프를 빠르게 파악하도록
  • 경영진이 단순한 기술 문제를 넘어, 실제 의사결정 과정까지 볼 수 있도록

원한다면 회의 후에 벽을 사진 찍거나 디지털화해서, 위키나 인시던트 관리 도구에 함께 올릴 수 있습니다. 이 코믹스는 팀이 압박 속에서 어떻게 대응했는지를 보여주는, 살아 있는 아티팩트가 됩니다.


결론: 인시던트에서의 학습을 손에 잡힐 만큼 ‘구체적’으로

아날로그 인시던트 스토리보드 월은 귀여운 그림을 위한 장치가 아닙니다. 그 목적은:

  • 인시던트를, 워룸에 있던 사람만 이해할 수 있는 게 아니라 누구에게나 읽히는 형태로 만드는 것
  • 구조화된 분석(템플릿, 파이브와이즈, 후속 조치)과 사람의 경험(그때 느낀 압박과 혼란)을 연결하는 것
  • 조직이 함께 배우고 개선할 수 있는 공유된 서사를 만드는 것에 있습니다.

이를 위해 다음을 결합합니다.

  • 커스터마이즈 가능한 포스트모템 템플릿
  • 명확한 영향에서 시작해 거꾸로 올라가는 파이브와이즈
  • 피드백을 위한 포스트모템 초안의 조기 공유
  • 숙련된 포스트모템 작성자의 가이드
  • 프레임 단위의 시각적 스토리텔링

이렇게 하면, 고통스러운 장애가 조직에 가장 큰 학습 기회를 주는 사건으로 바뀝니다.

다음에 무언가가 또 깨진다면, 대시보드만 하나 더 열지 말고, 포스트잇 뭉치를 집어 들고, 벽을 찾은 뒤, 함께 그 사건의 이야기를 그려 보세요.

아날로그 인시던트 스토리보드 월: 프로덕션 장애를 한 칸씩 그려보는 종이 코믹스로 바꾸기 | Rain Lag