아날로그 인시던트 스토리 관람차: 하나의 장애로 여러 관점을 회전시키기

인시던트 안에 있을 때는 세상이 온통 혼란스러운데, 막상 사후 리포트를 읽으면 이상할 만큼 평면적으로 느껴집니다. 타임라인, 메트릭, 루트 커즈(root cause)는 필수지만, 정작 살아 있는 경험은 빠지는 경우가 많습니다. 누가 언제 무엇을 느꼈는지, 실제 결정은 어떻게 내려졌는지, 커뮤니케이션은 어디서 정말로 끊겼는지 같은 것들 말이죠.

여기서 등장하는 것이 아날로그 인시던트 스토리 관람차(Analog Incident Story Ferris Wheel) 입니다. 이건 하나의 동일한 장애를 여러 관점—엔지니어, 고객, 리더십, 서포트 등—에서 반복해서 돌아보게 만드는, 단순하지만 재사용 가능한 활동입니다. “무엇이 잘못됐나?” 대신, “이 사건은 관람차의 각 좌석에서 어떻게 보이고, 어떻게 느껴졌을까?” 를 묻는 것이죠.

Post-Incident Review(PIR) 과정 안에 이 관람차를 넣으면, 한 번의 고통스러운 인시던트를 오래 가는 학습·공감·신뢰성 개선의 원천으로 바꿀 수 있습니다.

왜 관람차일까?

관람차는 하나의 인시던트를 비유하기에 딱 좋은 구조입니다.

• 같은 구조, 다른 시야: 모두가 같은 관람차(인시던트)에 타 있지만, 무엇이 보이는지는 앉아 있는 자리(역할)에 따라 달라집니다.
• 회전하는 관점: 한 자리에 앉아서는 전체 풍경을 볼 수 없습니다. 회전하며 서로의 시야를 비교해야 합니다.
• 예측 가능한 의식(ritual): 관람차는 시작·회전·종료가 정해져 있듯, 좋은 포스트 인시던트 프로세스도 마찬가지입니다.

대부분의 팀은 이미 기술적인 의식을 가지고 있습니다. 인시던트 타임라인 정리, 메트릭 리뷰, 루트 커즈 분석 같은 것들요. 관람차 활동은 여기에 사회·정서적, 관점 전환 레이어를 얹어 주어, 팀이 다음을 할 수 있게 돕습니다.

• 역할 간 공감 형성
• 커뮤니케이션 프로토콜 개선
• 의사결정 책임과 권한을 더 명확히 하기
• 무엇이 일어났는지만이 아니라 어떻게 느껴졌는지, 왜 사람들이 그렇게 행동했는지까지 이해해 반복 실수를 줄이기

인시던트 관람차를 Post-Incident Review에 어떻게 녹일까

PIR을 크게 세 부분으로 나누어 생각해 볼 수 있습니다.

1. Facts & Signals (사실과 신호) – 무엇이, 언제 일어났는가? 시스템은 우리에게 무엇을 보여줬는가?
2. Decisions & Flows (의사결정과 흐름) – 누가 무엇을 했는가? 어떤 정보와 제약 조건에 기반했는가?
3. Perspectives & Impact (관점과 영향) – 같은 사건을 각 역할은 어떻게 경험했는가?

관람차 활동은 3번에 속하지만, 1·2번을 이해하는 데도 영향을 줍니다. 기본적인 포스트 인시던트 리뷰(타임라인, 영향도, 원인 분석)는 그대로 합니다. 그 다음에:

• 분석할 하나의 장애를 고르고
• 4~6개의 핵심 역할(관람차 좌석)을 선정한 뒤
• 인시던트를 각 좌석의 시점에서 차례로 따라가며
• 모두에게 도움이 되는 인사이트와 개선점을 뽑아냅니다.

이 활동의 목표는 블레임리스(blameless) 학습이지, 과거를 완벽하게 만들기 위한 재구성이 아닙니다. 만약 이 활동이 “누가 더 잘 알았어야 했나”를 찾는 사냥이 되면, 관람차는 이미 고장난 것입니다.

아날로그 관람차 세팅하기

화이트보드, 포스트잇, 혹은 프린트된 종이로 진행할 수 있습니다. 굳이 디지털 대신 아날로그를 쓰는 이유는, 사람들이 조금 더 천천히 생각하고 느끼게 만들기 위해서입니다.

1단계: 좌석(역할) 정의하기

이번 인시던트에 가장 관련 있는 관점을 고릅니다. 예를 들면:

• 온콜 엔지니어 / 인시던트 커맨더(incident commander)
• 고객(또는 엔드 유저)
• 서포트 / 고객 성공(Customer Success)
• 프로덕트 매니저(PM)
• 리더십(VP / CTO 등)
• SRE / 플랫폼 / 신뢰성 엔지니어

각 좌석마다 “관점 시트(perspective sheet)” 를 하나씩 만듭니다. 1페이지짜리 템플릿에 구조화된 질문들을 넣는 형식입니다(아래 예시 참고).

2단계: 라이프사이클 단계 표시하기

화이트보드의 상단이나 측면(혹은 템플릿의 세로 방향)에 인시던트의 라이프사이클 단계를 정의합니다.

1. Early signals (초기 신호) – 뭔가 이상할 수도 있겠다 싶은 첫 힌트
2. Recognition (인시던트 인지) – 명백히 인시던트라고 인식된 순간
3. Escalation (에스컬레이션) – 더 많은 사람을 호출하거나 심각도(severity)를 선언하는 단계
4. Mitigation (완화) – 영향도를 줄이기 위해 적극적으로 대응하는 단계
5. Resolution (해결) – 시스템이 정상화되고 인시던트가 종료되는 시점
6. Aftermath (여파) – 커뮤니케이션, 후속 작업, 감정적 잔여물

모든 역할의 스토리는 이 동일한 단계를 따라 이동하게 됩니다.

3단계: 각 좌석을 돌며 진행하기

각 좌석마다 누군가가 그 역할을 롤플레이(role-play) 하도록 합니다. 실제로 그 역할을 맡았던 사람이 해도 되고, 프롬프트를 보고 대신 연기하는 사람이어도 됩니다. 그룹은 각 역할의 관점에서 라이프사이클을 처음부터 끝까지 따라간 뒤, 다음 좌석으로 회전합니다.

중요한 규칙: 한 번에 한 좌석만 말한다. 나머지는 모두 듣고 메모만 합니다.

각 좌석에서 쓸 수 있는 프린트용 프롬프트 예시

아래는 실제로 출력해서 나눠줄 수 있는 예시 프롬프트입니다. 각 좌석은 같은 구조를 사용하지만, 자기 맥락에 맞게 질문을 읽어 내려가면 됩니다.

좌석 1: 온콜 엔지니어 / 인시던트 커맨더

라이프사이클 단계별 프롬프트(각 단계마다 반복):

• 이 순간 나는 무엇을 알고 있었나? (구체적인 신호, 알람, 대시보드 등)
• 이때 나는 어떤 감정이었나? (자신감, 과부하, 불안, 침착함 등)
• 어떤 결정을 내렸는가? 왜 그랬는가?
• 어떤 제약을 인지하고 있었나? (시간 압박, 리스크, 애매한 오너십, 툴링 한계 등)
• 이 순간을 더 쉽거나 안전하게 만들어 줄 수 있었던 것은 무엇일까?

신뢰성(reliability) 관점:

• 어떤 부분에서 툴링이 도움이 되었고, 어떤 부분에서 방해가 되었나?
• 커뮤니케이션은 어디서 명확했고, 어디서 애매했나?
• X에 대한 의사결정을 누가 할 수 있는지 명확히 알고 있었나?

좌석 2: 고객 / 엔드 유저

실제 고객이 자리에 없어도, 최대한 그 시야를 상상해 볼 수 있습니다.

라이프사이클 프롬프트:

• 나는 언제 처음 이상함을 느꼈나?
• 무엇을 하려고 했고, 무엇 때문에 막혔나?
• 어떤 정보를 보았나? (에러 메시지, 상태 페이지, 이메일 등)
• 이 경험이 나의 신뢰나 행동에 어떤 영향을 미쳤나?
• 어떤 대응이 ‘존중받고 있고, 능력 있는 팀이 다루고 있다’는 느낌을 줬을까?

신뢰성 관점:

• 영향도 설명이 고객 언어였나, 아니면 내부 용어(jargon)였나?
• 타임라인과 리스크에 대해 현실적인 기대치를 설정해 줬나?

좌석 3: 서포트 / 고객 성공

라이프사이클 프롬프트:

• 이 단계에서 고객들은 뭐라고 말하고 있었나?
• 그들에게 답변하기 위해 나는 어떤 정보를 가지고 있었나?
• 내가 고객에게 전달한 내용과, 내부에서 공유되던 내용의 정합성은 어땠나?
• 어디서 막히거나, 위험에 노출된 느낌이 들었나?
• 어떤 템플릿, 플레이북, 데이터가 있었다면 더 좋았을까?

신뢰성 관점:

• 표준화된 인시던트 커뮤니케이션 템플릿이 있는가?
• 상태 페이지, 서포트 매크로, 내부 업데이트 간에 명확한 정렬(alignment)이 되어 있는가?

좌석 4: 프로덕트 매니저

라이프사이클 프롬프트:

• 이 시스템에 대해, 미리 알고 있던 리스크나 트레이드오프는 무엇이었나?
• 영향도가 커질수록 무엇이 걱정됐나? (SLA, 로드맵, 계약 등)
• 완화 단계에서 나는 어떤 결정을 지지하거나 관여했나?
• 인시던트 이후, 우선순위는 어떻게 재조정됐나?

신뢰성 관점:

• 플래닝에서 신뢰성(reliability) 작업과 기능 개발이 균형 있게 다뤄지고 있는가?
• 이번 인시던트가 누락된 SLI/SLO나 애매한 대외 커밋먼트(약속)를 드러내진 않았나?

좌석 5: 리더십(VP / CTO)

라이프사이클 프롬프트:

• 이 사안이 ‘심각하다’고 느끼게 만든 신호는 무엇이었나? (심각도 레벨, 특정 고객, 매출 영향 등)
• 어떤 업데이트를, 얼마나 자주 받았나?
• 내가 내려야 했던 결정은 무엇이었나? (대외 메시지, 리소스 재배치 등)
• 어디서 평판 리스크나 규제 리스크를 우려했나?
• 다음번에는 인시던트 프로세스에 대한 내 신뢰를 높이려면 무엇이 필요할까?

신뢰성 관점:

• 심각도(severity) 정의와 에스컬레이션 기준이 충분히 명확한가?
• 메이저 인시던트 동안, 표준화되고 신뢰할 수 있는 커뮤니케이션 캐던스(cadence)가 있는가?

좌석 6: SRE / 플랫폼 / 신뢰성 엔지니어

라이프사이클 프롬프트:

• 이번 일을 통해 ‘머릿속 모델’과 실제 시스템 동작 사이에서 무엇을 새로 배웠나?
• 옵저버빌리티(observability)는 어디서 도움이 되었고, 어디서 실패했나?
• 어떤 근본적인 시스템 또는 프로세스 부채가 드러났나?
• 현실적으로 적용 가능한, 지속 가능한 개선은 무엇인가?

신뢰성 관점:

• 어떤 방어선(defense)이 실패했거나, 애초에 없었나?
• 재발 가능성이나 블라스트 레디어스(blast radius)를 가장 크게 줄일 수 있는 변화는 무엇인가?

블레임리스하고 정서적으로 안전하게 만드는 법

관람차 활동이 제대로 작동하려면, 사람들이 다음과 같은 것들을 솔직하게 말할 수 있어야 합니다.

• 헷갈렸던 순간
• 신호를 놓쳤던 경험
• 과부하나 두려움을 느꼈던 감정
• 불확실성 속에서 “최선의 추측”으로 결정을 내렸던 상황

이 정직함을 지키기 위해서는:

1. 프레임을 명확히 설정한다

   • “우리가 여기 모인 이유는, 각 사람이 아니라 시스템과 프로세스가 사람들에게 어떻게 작동했는지 이해하기 위해서입니다.”

2. 힌드사이트 바이어스(hindsight bias) 언어를 금지한다

   • 피해야 할 표현: “그때는 당연히 알았어야지…”, “왜 그걸 못 봤어?”
   • 대신 이렇게 묻기: “그 시점에 보이던 정보만 기준으로 하면, 어떤 선택지들이 가능해 보였나?”

3. 감정을 ‘데이터’로 취급한다

   • 과부하, 혼란, 불안, 심지어 지루함까지도 시스템 설계의 신호이지, 개인의 나약함이 아닙니다.

4. 학습 내용을 시스템 레벨에 기록한다

   • “에스컬레이션 경로를 더 명확히 해야 한다”
   • “서비스 X에 대한 더 나은 대시보드가 필요하다”
   • “시나리오 Y에 맞는 서포트 매크로가 필요하다”

관점을 실제 신뢰성 개선으로 연결하기

각 좌석의 스토리는, 인시던트 대응이나 시스템 설계 방식을 바꾸는 최소 한 가지 이상의 변화로 이어져야 합니다. 예를 들면:

• 엔지니어 좌석 → 더 나은 런북 & 역할 정의
  롤백 결정 권한이 누구에게 있는지 헷갈렸던 경험이, 업데이트된 인시던트 역할 차트와 더 명확한 롤백 정책으로 이어질 수 있습니다.

• 고객 좌석 → 더 명확한 커뮤니케이션
  상태 메시지가 사용자에게 의미가 없었다는 사실(예: “elevated 5xx errors”)을 깨닫고, 새로운 평이한 언어(plain language)의 상태 페이지 템플릿을 도입할 수 있습니다.

• 서포트 좌석 → 단일한 소스 오브 트루스(Single Source of Truth)
  서포트는 고객에게 한 말을 하고, 엔지니어는 다른 상황을 알고 있는 괴리가 드러났다면, 라이브 인시던트 채널 또는 문서를 중앙에 두고, 서포트 매크로를 거기에 맞춰 업데이트할 수 있습니다.

• 리더십 좌석 → 더 높은 신뢰, 적은 방해
  리더십이 실시간 상황을 몰라 엔지니어들을 수시로 직접 핑하던 문제가 드러났다면, 표준화된 업데이트 주기와 브로드캐스트 포맷을 만들 수 있습니다.

• SRE 좌석 → 재발률을 줄이는 개선
  동일한 실패 패턴이 반복되고 있음을 발견하면, 우선순위를 재조정해 레이트 리미팅(rate limiting), 서킷 브레이커(circuit breaker), 더 나은 알람 임계값 등 탄탄한 회복력(resilience) 작업에 투자할 수 있습니다.

이러한 결과들은 모두 **조직 차원의 회복탄력성(organizational resilience)**에 직결됩니다. 더 빠른 완화, 더 깨끗한 커뮤니케이션, 줄어든 인지 부하, 더 적은 ‘뜻밖의 놀람’을 의미합니다.

엔지니어링 팀의 사회·정서적 스킬 키우기

겉으로 보기에는 프로세스 개선 활동 같지만, 관람차는 동시에 조용한 훈련장이기도 합니다.

• 공감(Empathy): 엔지니어가 자신의 행동이 고객과 서포트에게 어떻게 느껴졌을지 상상해 봅니다.
• 관점 전환(Perspective-taking): 리더는 최전선에 있는 사람들의 압박과 모호성을 더 잘 이해하게 됩니다.
• 협업(Collaboration): 각자의 제약을 존중하며 함께 개선안을 설계합니다.
• 목표 설정(Goal setting): 다음 인시던트를 위해 구체적인 행동·프로세스 변화를 팀 차원에서 약속합니다.

이를 강화하려면, 마지막에 클로징 라운드를 추가해 볼 수 있습니다.

• “다른 좌석의 관점에서 들은 것 중 가장 놀라웠던 점은 무엇이었나요?”
• “다음 인시던트 때, 나는 개인적으로 무엇을 다르게 할 건가요?”
• “서로를 더 잘 지지하기 위해, 팀으로서 어떤 약속을 해야 할까요?”

이 내용을 1페이지짜리 커밋먼트 문서로 정리해 두고, 다음 인시던트 리뷰 때 다시 꺼내 보는 것도 좋습니다.

결론: 한 번의 탑승, 여러 개의 시야, 그리고 함께 만드는 개선

사실 모든 인시던트는 이미 하나의 관람차입니다. 여러 사람이 같은 혼란의 루프를 오르내리며, 각자 자기 자리에서 보이는 풍경만 보고 지나갑니다. 아날로그 인시던트 스토리 관람차는 이 현실을 보이게 만들고, 활용 가능하게 만드는 도구입니다.

각 관점을 구조적이고 블레임리스하게 회전하며 살펴봄으로써, 당신의 팀은 다음을 할 수 있습니다.

• 개별적인 스트레스를 공동의 인사이트로 전환하기
• 커뮤니케이션, 툴링, 역할 정의의 빈틈을 드러내기
• 감정적 현실을 기술·프로세스 변화와 연결하기
• 신뢰성을 모두의 공동 책임으로 만드는 문화를 구축하기

이 연습을 몇 번만 반복해도 하나의 의식이 됩니다. “중대 인시던트가 있으면, 우리는 함께 관람차를 탄다.”
인시던트 자체는 아팠을지 몰라도, 그 사건을 두고 우리가 함께 만들어가는 스토리는, 시스템과 그 시스템을 운영하는 사람들을 다음 번을 위해 더 강하게 만들어 줄 수 있습니다.