소개

대부분의 팀은 장애가 난 뒤에 포스트모템(post‑mortem) 을 어떻게 하는지 알고 있습니다. 로그를 모으고, 타임라인을 재구성하고, 근본 원인(root cause)을 놓고 토론하고, “다음엔 더 잘하자”고 다짐하죠. 하지만 그때쯤이면 이미 피해는 발생한 뒤입니다. 고객은 영향을 받았고, 평판은 상처를 입었으며, 누군가는 밤잠을 설쳤습니다.

프리모템(pre‑mortem) 은 이 흐름을 거꾸로 뒤집습니다. “무엇이 잘못됐지?”라고 묻는 대신, 이렇게 묻습니다.

“지금으로부터 석 달 뒤라고 상상해 봅시다. 이번 런치가 spectacular하게 망했습니다. 무슨 일이 벌어진 걸까요?”

아직 존재하지 않는 장애를 미리 리허설하는 것입니다.

여기에 한 가지를 더 얹어 봅니다. 바로 아날로그 방식입니다.

대시보드와 공유 문서가 넘쳐나는 시대에, 팀이 함께 걸어 다닐 수 있는 바닥 길이의 종이 지도—말 그대로 ‘인시던트 스토리 블루프린트 스크롤(incident story blueprint scroll)’ 을 펼치는 것은 의외로 강력한 효과를 냅니다. 시스템, 의존성, 사람, 실패 모드가 모두 잉크로 펼쳐진, 가상의 장애를 위한 물리적인 무대가 되기 때문입니다.

이 글에서는 아날로그 방식을 활용해 바닥 길이의 ‘인시던트 스크롤’을 만들고, 이를 기반으로 사전 장애(pre‑mortem) 리허설을 설계하고 운영하는 방법을 설명합니다. 이 방식은 시스템과 리스크를 더 이상 외면할 수 없게 눈앞에 펼쳐 줍니다.

왜 프리모템 장애 리허설이 중요한가

프리모템은 대규모 릴리스, 마이그레이션, 아키텍처 변경을 하기 전에 진행하는 구조화된 연습입니다. 핵심 아이디어는 간단합니다.

“프로젝트가 심각하게 실패했다고 가정하자. 그 이유를 거슬러 올라가며 찾아보자.”

일반적인 리스크 체크리스트 대신, 팀원들이 생생하고 구체적인 실패 시나리오를 상상할 수 있게 해 줍니다. 이를 통해 다음과 같은 효과를 얻을 수 있습니다.

• 기존의 리스크 로그에는 잘 드러나지 않는 숨은 실패 모드를 드러낸다.
• “우리에겐 그런 일 안 생겨”라는 낙관 편향(optimism bias) 을 현실적인 재해 시나리오로 깨뜨린다.
• 팀의 시선을 정렬시켜, 진짜 지뢰밭이 어디에 있는지 합의한다.
• 상상 속 재앙을 구체적인 계획으로 전환한다: 완화책, 플레이북, 모니터링 개선 등.

특히 복잡한 IT 환경에서는 어느 누구도 전체 시스템을 완전히 이해하고 있지 못한 경우가 많습니다. 프리모템은 엔지니어링, SRE, 보안, 프로덕트, 고객 지원 등 모든 역할이 각자 퍼즐 조각을 더할 수 있게 해 줍니다.

인시던트 스토리 블루프린트 스크롤: 왜 아날로그인가?

프리모템에 바닥 길이의 종이 스크롤 또는 지도를 쓰자는 제안은 다소 구식으로 들릴 수 있습니다. 하지만 바로 그 점이 장점입니다. 아날로그 도구에는 소프트웨어만으로는 얻기 어려운 이점이 있습니다.

• 물리적 존재감: 바닥이나 벽에 펼쳐진 거대한 스크롤은 무시하기 어렵습니다. 모두의 시선을 하나의 공유된 공간에 고정시켜 줍니다.
• 공유된 멘탈 모델: 모두가 같은 지도를 둘러싸고 서서 서비스들을 가리키고, 화살표를 그리며, 연결 관계를 두고 토론합니다.
• 몸으로 걷는 워크스루: 참가자들은 가상의 타임라인을 직접 걸어가며 장애를 분 단위, 단계별로 따라가 볼 수 있습니다.
• 낮은 마찰: 마커와 포스트잇은 회의 시간에 다이어그램 툴을 만지작거리는 것보다 훨씬 빠르고 자연스럽습니다.

이 스크롤을 당신의 아날로그 인시던트 스토리 블루프린트라고 생각해 보세요. 시스템, 사람, 시간 축을 함께 펼쳐 놓고, 첫 번째 징후부터 최종 해결까지의 장애를 하나의 이야기로 연기하는 서사 공간입니다.

1단계: 프리모템의 목표를 명확히 정의하기

종이를 펼치기 전에, 먼저 무엇을, 왜 리허설하는지를 분명히 해야 합니다.

다음 세 가지를 정리해 보세요.

1. 범위(Scope)

   • 특정 변경(예: 데이터베이스 마이그레이션, 신규 기능 론칭)에 집중할 것인가?
   • 아니면 특정 유형의 실패(예: IDP/인증 제공자 장애, 클라우드 리전 전체 장애)를 다룰 것인가?

2. 목표(Goals)

   • 세션이 끝날 때 무엇을 손에 쥐고 싶나요?
   • 예시:
     • 우선순위가 매겨진 리스크 레지스터(risk register)
     • 새로 만들 알람·대시보드 목록
     • 런북(runbook) 개선 사항과 온콜 교육 주제

3. 참가자(Participants)

   • 다음과 같은 사람들을 포함하세요.
     • 애플리케이션 엔지니어링
     • SRE / 플랫폼 / 인프라 팀
     • 보안 팀
     • 고객 지원 / 운영 팀
     • 필요하다면 프로덕트 또는 비즈니스 이해관계자

세션 시작에 목표를 명확히 선언합니다.

“오늘 세션이 끝날 때 우리는 핵심 장애 시나리오 목록, 각각의 리스크, 그리고 이를 예방하거나 더 잘 대응하기 위한 구체적인 액션 아이템을 손에 넣을 것입니다.”

2단계: 스크롤을 펼치고 시스템 지도를 그리기

종이를 바닥, 긴 테이블, 또는 복도 벽에 길게 펼칩니다. 이것이 곧 시스템과 스토리를 담을 캔버스가 됩니다.

스크롤을 두 개의 주요 축으로 나눕니다.

1. 가로축: 시간 / 인시던트 타임라인

   • 왼쪽: T‑0 (변경이 라이브되는 시점) 또는 T‑0 (첫 번째 증상이 나타나는 시점)
   • 오른쪽: T+X 시간 (장애 해결 및 RCA 시작 시점)
   • T+5분, T+15분, T+1시간 등 주요 시간 구간을 표시합니다.

2. 세로축: 시스템 레이어 & 액터(Actors)

   • 최상단: 외부 사용자, 서드파티 서비스 등 외부 액터
   • 그 아래: 엣지 / API / 프런트엔드
   • 중간: 서비스, 마이크로서비스, 비즈니스 로직
   • 하단: 데이터 스토어, 큐, 캐시, 인프라, 네트워크
   • 맨 아래: 온콜, 지원, 인시던트 커맨더 등 팀과 역할(Roles)

이제 색깔이 다른 마커와 포스트잇을 활용해 다음을 수행합니다.

• 서비스, 도구, 외부 의존성을 박스로 그립니다.
• 데이터 흐름과 주요 크리티컬 패스를 스케치합니다.
• 알려진 단일 실패 지점(SPOF, Single Point of Failure) 을 주석으로 표시합니다.
• 이미 존재하는 관측 가능성(Observability) 지점과, 아직 없는 지점을 구분해 표시합니다.

이 지도는 거칠고 하이레벨이어도 됩니다. 목표는 공유된 이해를 눈앞으로 끄집어내고, “우리가 모르는 부분”을 드러내는 것입니다.

3단계: “무엇이 어떻게 망가졌는지”를 현실감 있게 상상하기

스크롤 준비가 끝났다면 이제 본격적인 프리모템 모드로 전환합니다.

핵심 질문을 던집니다.

“이 변경이 라이브된 지 6주가 지났다고 가정해 봅시다. 우리는 대규모, 고객 가시적인 장애를 겪었습니다. 무슨 일이 어떻게 잘못된 걸까요?”

이제 협업 브레인스토밍을 진행합니다.

1. 조용한 아이디어 작성 (5–10분)

   • 모두가 각자 머릿속에 떠오르는 가상의 실패 시나리오를 포스트잇에 적습니다.
     • “새 설정 플래그가 레이트 리미팅(rate limiting)을 끔 → 다운스트림 DB가 과부하.”
     • “서드파티 인증( auth) 제공자 API 변경 → 로그인 실패 다발.”
     • “마이그레이션 스크립트가 중간에 멈춤 → B 리전에 불일치 데이터 남음.”

2. 스크롤 위에서 주제·위치별로 클러스터링

   • 각 포스트잇을 시스템 지도와 타임라인 상에서 실제로 나타날 위치에 붙입니다.
   • 데이터 손상, 레이턴시 스파이크, 인증 실패 등 유사한 실패 유형끼리 그룹화합니다.

3. 인시던트 스토리 풀어내기

   • 하나의 시나리오를 골라, 실제로 있었던 일처럼 이야기 형식으로 풀어갑니다.
     • 첫 번째 증상은 언제 나타났는가?
     • 고객은 무엇을 겪었는가?
     • 온콜이 본 것(또는 보지 못한 것)은 무엇인가?
     • 이슈는 어떻게 에스컬레이션되고, 어디까지 전파되었는가?

이 이야기를 가로축인 타임라인을 따라 적어 내려갑니다. 작은 문제에서 시작해 연쇄 효과(cascading effects) 로 커지는 과정을 화살표로 그립니다. 예를 들어, 지원 서비스의 사소한 문제가 재시도, 떼거리 접근(thundering herd), 잘못된 폴백 설정 때문에 전체 장애로 확대되는 식입니다.

4단계: 의존성과 연쇄 리스크를 꼼꼼히 추적하기

스크롤의 진가는 의존성(dependency) 을 따라가 보기 시작할 때 드러납니다. 많은 중대 장애는 아주 작은 것에서 출발합니다.

• “크리티컬하지 않다”고 여겼던 내부 API가 다운되었는데, 사실 세 개의 매출 핵심 서비스가 조용히 그 API에 의존하고 있었던 경우
• 백그라운드 잡 하나가 오작동해 큐를 막아 버리고, 사용자에게 보이는 작업까지 지연시키는 경우
• 특정 용도에 맞게 튜닝된 공유 캐시 클러스터가, 다른 워크로드에 의해 심하게 thrash되는 경우

세션 시간에 다음을 수행해 보세요.

• 서비스 → 데이터 스토어 → 서드파티로 이어지는 체인을 추적합니다.
• 데이터베이스, 캐시, 메시지 버스, 피처 플래그 시스템, CI/CD 도구처럼 공유 리소스를 표시합니다.
• 장애 시점에 중요해질 팀 간 의존성을 식별합니다.

누군가 “잠깐, 저게 X에 의존하는 줄 몰랐는데요?”라고 말하는 지점마다 동그라미를 크게 쳐 두세요. 이런 곳은 모니터링 강화, 격리, 신뢰성 개선의 1순위 후보입니다.

5단계: 상상 속 실패를 구체적인 계획으로 바꾸기

프리모템이 가치 있으려면, 손에 잡히는 결과물로 이어져야 합니다.

스크롤 위에서 다룬 주요 시나리오마다 다음을 정리합니다.

1. 리스크 레지스터 항목

   • 리스크 설명
   • 대략적인 발생 가능성과 영향도(impact)
   • 관련된 시스템 컴포넌트

2. 완화(Mitigation) 계획

   • 설계·아키텍처 변경 (예: 서킷 브레이커, 벌크헤드 패턴, 더 나은 백프레셔)
   • 프로세스 변경 (예: 단계적 롤아웃, 피처 플래그 활용, 변경 동결 기간 설정)
   • 테스트 커버리지 (예: 카오스 테스트, 부하 테스트, 통합 테스트)

3. 액션 아이템

   • 신규 또는 개선된 알람과 SLO(Service Level Objective)
   • 런북 업데이트와 인시던트 롤(role) 정의
   • 온콜 엔지니어를 위한 교육·시뮬레이션 주제

각 항목에 명확한 오너와 마감일을 지정합니다. 포스트잇에 적힌 내용을 티켓 시스템, 리스크 트래커, 신뢰성 로드맵 등 평소 사용하는 도구에 옮겨 담습니다.

6단계: 인사이트를 인시던트 도구와 연결하기

아날로그 스크롤이 고립된 산출물로 남지 않게 해야 합니다. 디지털 인시던트 툴체인과 긴밀히 연결하세요.

• 알림 & 모니터링(Alerting & Monitoring)

  • 주요 실패 경로마다 이렇게 자문해 보세요. “이 상황을 우리는 얼마나 빨리 눈치챌 수 있을까?”
  • 그에 맞게 알람, 대시보드, SLO, 트레이스를 추가·개선합니다.

• 에스컬레이션 경로(Escalation Paths)

  • 시나리오가 여러 팀이나 벤더를 가로지른다면, 에스컬레이션 정책에 그 현실이 반영되어 있는지 확인합니다.
  • 온콜 로테이션, 연락처 목록, 인시던트 커맨더 플레이북을 업데이트합니다.

• RCA & 인시던트 관리 도구

  • 프리모템에서 만든 스토리를, 나중에 실제 RCA를 작성할 때 활용할 템플릿으로 재사용합니다.
  • 실제 인시던트가 발생하면, 사전에 연습한 시나리오와 비교해 봅니다. 예측했던 유형이었는지, 미리 해 둔 완화책이 효과를 냈는지 확인합니다.

이렇게 하면 리허설 → 탐지 → 대응이 하나의 루프로 이어집니다. 종이 위에서 상상한 내용이 실제 프로덕션 환경에서 보는 것과 행동으로 직결되는 구조입니다.

7단계: 반복·개선하기 — 스크롤을 낡게 두지 말 것

시스템은 끊임없이 변합니다. 아키텍처는 서서히 변형되고, 의존성은 조용히 늘어납니다. 한 번만 한 프리모템은 금세 구시대의 산물이 됩니다.

인시던트 스크롤을 반복적인 의식(ritual) 으로 만드세요.

• 주요 릴리스나 마이그레이션 이전에 프리모템을 수행합니다.
• 신규 하이리스크 영역을 대상으로 분기별 또는 반기별 장애 리허설을 계획합니다.
• 서비스가 추가·폐기·재설계될 때마다 시스템 지도를 업데이트합니다.

이 과정을 지속하다 보면, 인시던트 스토리와 리스크 패턴의 라이브러리가 쌓입니다. 동시에, “이제 우리는 안전하다”는 안일함도 줄어듭니다. 주기적으로 새로운, 그럴듯한 실패 모드를 마주하기 때문입니다.

실제 장애가 발생했을 때도 스크롤을 활용하세요.

• 실제 발생한 인시던트 경로를 스크롤 위에 표시합니다.
• 과거에 상상했던 시나리오와 비교합니다.
• 새로 얻은 인사이트를 다음 프리모템에 반영합니다.

결론

프리모템은 팀이 프로덕션에서 실패하기 전에, 종이 위에서 미리 실패해 보는 방법입니다. 아날로그 방식의 바닥 길이 인시던트 스토리 블루프린트 스크롤을 펼치면, 보이지 않던 복잡성이 팀 전체가 함께 보고, 손으로 만지고, 걸어 다니며 이해하는 구체적인 대상으로 바뀝니다.

프로세스를 다시 정리하면 이렇습니다.

1. 명확한 목표와 범위를 정의한다.
2. 스크롤을 펼치고 시스템의 타임라인과 레이어를 스케치한다.
3. 현실적인 “무엇이 어떻게 망가졌는지” 이야기를 상상한다.
4. 의존성을 따라가며 연쇄 실패 경로를 드러낸다.
5. 시나리오를 리스크 레지스터, 완화책, 액션 아이템으로 전환한다.
6. 인사이트를 인시던트 및 모니터링 도구와 연결한다.
7. 아키텍처 변화에 맞춰 반복하고 개선한다.

이 결과물은 단순히 멋진 다이어그램이 아닙니다. 스트레스 상황에서 시스템이 실제로 어떻게 동작하는지에 대한 공유되고 체화된 이해이며, 다음 번 뉴스거리가 될 장애를 발생 전에 막기 위한 구체적인 계획이기도 합니다.