아날로그 인시던트 스토리 열차 묘지: 다음 배포를 조용히 지켜보는 ‘퇴역 장애’의 벽

화이트보드나 벽 한쪽에 오래된 인시던트 노트, 포스트잇, 출력물이 빽빽이 붙어 있는 걸 지나칠 때 묘하게 안도감이 들 때가 있습니다. 각각은 하나의 이야기입니다. 새벽 3시를 깨운 페이저, 잘못 설정된 플래그, 빠진 인덱스, 연쇄적인 타임아웃. 개별적으로는 다 아픈 기억입니다. 하지만 함께 모이면 다른 것이 됩니다. 바로 **스토리 열차 묘지(Story Train Graveyard)**입니다.

이 벽은 시스템이 겪었던 최악의 날들을 드러내놓고 기록해 둔 아카이브입니다. 누군가를 탓하기 위한 게 아니라, 기억하기 위해서입니다. 물리적(또는 디지털)인 이 ‘퇴역 장애’의 벽은 무엇이, 왜, 어떻게 망가졌고, 어떻게 고쳤는지를 계속 상기시키면서 다음 배포를 조용히 지켜줍니다.

이 글은 그 벽을 어떻게 ‘의도적으로’ 만드는지에 관한 이야기입니다. 인시던트 회고(incident retrospective)를 구조화된 데이터 기반 엔진으로 활용해서, 모든 장애를 재사용 가능한 실행 가능한 스토리로 만들고, 같은 실패를 두 번 다시 마주칠 확률을 낮추는 방법을 다룹니다.

왜 스토리 열차 묘지가 필요한가

인시던트는 비쌉니다. 가용성, 돈, 팀 사기, 사용자 신뢰를 모두 갉아먹습니다. 그중 가장 최악은 아무것도 배우지 못한 장애입니다.

대부분의 팀은 어느 정도 형태로든 ‘사후 분석(postmortem)’을 합니다. 하지만 흔히 이렇게 됩니다.

• 노트는 누구도 다시 열어보지 않는 문서에 묻혀 버린다
• 액션 아이템은 실행되지 않는다
• 똑같은 패턴이 미래의 인시던트에서 반복된다

스토리 열차 묘지는 이런 문제를 다음과 같이 해결합니다.

1. 인시던트를 시각화합니다 – 문서에 적힌 미화된 버전이 아니라, 시스템이 실제로 겪은 역사를 모두가 볼 수 있게 합니다.
2. 데이터만이 아니라 ‘서사’를 기록합니다 – 실제로 무슨 일이 있었고, 왜 그런 의사결정을 했는지까지 담습니다.
3. 과거 실패와 미래 변경을 연결합니다 – 이미 ‘학습 비용’을 치른 경험이, 이후 배포마다 실제로 도움이 되도록 만듭니다.

이건 단지 문화 만들기를 넘어서 리스크 관리입니다. 인시던트를 ‘자산’으로 바꾸는 작업입니다.

1단계: 모든 장애를 ‘학습 자산’으로 취급하라

토대는 구조화된, 데이터 기반 인시던트 회고 프로세스입니다. “뭐가 고장 났지?”에서 끝나는 게 아니라, “이 인시던트는 우리 시스템과 조직에 대해 무엇을 말해 주는가?”까지 가야 합니다.

좋은 회고는 다음을 목표로 합니다.

• 사실 데이터 수집: 타임라인, 로그, 메트릭, 알림, 사용자 영향
• 의사결정 이해: 왜 이 롤백을 택했는지, 왜 저 완화책을 썼는지, 왜 그 알림은 무시됐는지
• 시스템적 기여 요인 식별: 설계 결함, 프로세스 구멍, 도구 부족, 불분명한 오너십 등

이렇게 하면 회고가 단순한 의식이 아니라 반복 가능한 분석 프로세스가 됩니다. 모든 장애가 분석 가능한 하나의 ‘실험 결과’가 됩니다.

포함해야 할 핵심 요소는 다음과 같습니다.

• 인시던트 요약: 영향, 범위, 지속 시간은 어땠는가?
• 사용자 영향: 사용자 관점에서 실제로 뭐가 망가졌는가?
• 타임라인: 트리거에서 복구까지의 흐름을 명확히 기록
• 탐지(Detection): 어떻게, 얼마나 빨리 알아챘는가?
• 진단(Diagnosis): 루트 원인이 명확했는지, 무엇이 혼란을 줬는지?
• 해결(Resolution): 무엇이 효과가 있었고, 무엇이 헛수고였는가?
• 기여 요인(Contributing factors): 기술적·조직적·인적 요인 모두 포함

이 구조가 탄탄할수록, 여러 인시던트에서 패턴을 나중에 분석하기가 쉬워집니다.

2단계: 회고는 ‘회의에서’가 아니라 ‘회의 전에’ 시작된다

좋은 회고는 캘린더 알림이 울릴 때 시작되는 게 아닙니다. **사전 준비(pre-work)**에서 이미 시작됩니다.

회의 이전에, 보통 인시던트 커맨더나 SRE가 다음을 준비해야 합니다.

• 메트릭 수집: 지연 시간, 에러율, 리소스 사용량 등
• 인시던트와 관련된 로그를 내보내기(export)
• 알림, 커밋, 롤아웃, 채팅 로그를 바탕으로 초안 타임라인 구성
• 다양한 관점 수집:
  • 온콜 대응자들
  • 영향을 받은 프로덕트/지원 팀
  • 외부 주요 이해관계자(예: 큰 영향 받은 주요 고객)

이 사전 작업 덕분에 회의 45분을 “무슨 일이 있었지?”를 되짚는 데 쓰지 않고, 훨씬 어려운 질문인 **“왜 시스템이 이렇게 행동했을까?”**에 집중할 수 있습니다.

이 프리리드를 회의 전에 미리 공유해서, 모두가 공통된 컨텍스트를 가진 상태로 회의에 들어오게 하세요.

3단계: 안전과 명확한 역할을 기반으로 회고를 진행하라

회고는 탓하기, 상태 보고, 또는 후속 조치 없이 그냥 ‘썰 풀기’ 시간이 되면 실패합니다. 반대로, 다음과 같을 때 성공합니다.

• 심리적 안전이 보장되고
• 시스템 중심으로 논의하며
• 좋은 퍼실리테이션이 있을 때

다음과 같은 역할을 고려해 볼 수 있습니다.

• 퍼실리테이터(Facilitator): 논의를 이끌고, 초점을 개인이 아닌 시스템과 프로세스에 두도록 유지합니다.
• 서기(Scribe): 인사이트, 결정 사항, 액션 아이템을 실시간으로 기록합니다.
• 인시던트 오너(Incident Owner): 후속 작업이 실제로 이행되도록 책임을 집니다.

도움이 되는 기본 규칙들:

• No blame, no shame(탓하지 말고, 부끄럽게 만들지 말자): 사람들이 실수를 숨기면 데이터가 사라집니다. 개인의 실패가 아니라 조건과 인센티브에 집중하세요.
• 선의 가정(Assume good intent): 사람들은 당시 가지고 있던 정보로 최선의 결정을 내렸다고 가정합니다.
• 시스템 우선(System first): “누가 실수했는가?”가 아니라, “우리 도구, 프로세스, 설계가 어떻게 이런 결과를 ‘가능하게’ 했는가?”를 묻습니다.

유용한 질문들:

• “우리를 가장 놀라게 한 건 무엇이었나?”
• “우리가 가진 시스템 ‘멘탈 모델’과 실제가 어디에서 달랐나?”
• “어떤 시그널을 놓치거나 무시했나?”
• “이 인시던트가 ‘지루했을’ 방법은 뭐였을까?”
  • (더 나은 자동화, 더 강한 가드레일, 더 명확한 런북 등)

4단계: 인사이트를 구체적인 후속 작업으로 바꿔라

아무리 완벽한 인시던트 스토리도, 변화로 이어지지 않으면 무용지물입니다. 모든 회고는 구체적이고, 오너가 있고, 기한이 있는 액션으로 끝나야 합니다.

각 인사이트에 대해 다음을 정의하세요.

• Action(조치): 무엇이 정확히 바뀌는가?
  • 예: “에러율 > X가 Y분 이상 지속되면 자동 롤백 추가”
• Owner(오너): 책임을 지는 ‘한 사람’을 명시합니다.
• Deadline(마감일): “다음 스프린트 언젠가”가 아니라, 실제 날짜.
• Impact(영향): 이 조치가 어떤 리스크, 메트릭, 인시던트 패턴을 대상으로 하는지.

이 액션들을 Jira, Linear, 내부 툴 등 보이는 곳에 기록하고 주기적으로 점검하세요.

• 인시던트에서 나온 액션 중 얼마나 완료됐는가?
• 어떤 것들이 반복해서 밀리고 있는가?
• 고임팩트 장애를 예방할 수 있는 작업을 계속해서 뒤로 미루고 있지는 않은가?

이 루프를 닫아야만, ‘퇴역한 장애’들이 실제로 다음 배포를 설계하는 힘이 됩니다.

5단계: 스토리 열차 묘지를 구축하라

이제 재미있는 부분입니다. 쌓여 있는 회고들을 참조 가능한 아카이브로 바꾸는 일입니다.

스토리 열차 묘지를 잘 조직된 ‘나쁜 날’ 지도라고 생각해 보세요. 새로운 작업을 할 때, 과거의 아픔을 쉽게 찾아볼 수 있게 만드는 지도입니다.

최소한 각 인시던트 스토리는 다음을 포함해야 합니다.

• 이름 / 슬러그: 예) 2024-10-API-THROTTLING-STORM
• 짧은 내러티브: 평이한 언어로, 무슨 일이 있었는지
• 주요 루트 원인: 단순한 근접 원인(proximal cause)이 아니라 시스템적(root) 원인
• 핵심 기여 요인들
• 자세한 데이터 링크: 로그, 대시보드, PR, 변경 기록 등
• 적용된 픽스와 남아 있는 작업들
• 태그: 시스템, 서비스, 기능, 장애 유형, 환경(prod/stage 등)

그다음, 이걸 눈에 띄게 만드세요.

• 물리적 벽(Physical wall): 인시던트 요약을 출력해서 팀 자리 근처 벽에 ‘퇴역’시켜 붙입니다.
• 디지털 벽(Digital wall): 인시던트를 카드/타일 형태로 보여주는 내부 대시보드나 위키 페이지.

그리고 이걸 일상 업무에 녹여야 합니다.

• 큰 배포 전에, 묘지를 검색합니다.
  • “예전에 이와 비슷한 걸 배포한 적이 있었나?”
  • “마지막으로 이 영역을 건드렸을 때 뭐가 잘못됐지?”
• 설계 리뷰 중에는 섹션을 하나 추가합니다.
  • “Story Train Graveyard 관련 인시던트”
• 온보딩 동안:
  • 새 엔지니어를 벽(또는 대시보드) 앞에 데리고 가서, 몇 가지 이야기를 들려줍니다.

이렇게 하면 조직의 기억이 문서 속에 묻히는 대신, **공기 중에 떠다니는 환경(ambient memory)**이 됩니다.

6단계: ‘반응적 탐지’에서 ‘사전 예방’으로 이동하라

시간이 지나면, 인시던트 아카이브는 예방을 위한 데이터셋이 됩니다.

다음과 같은 질문을 던져 보세요.

• 어떤 서비스가 가장 자주 등장하는가?
• 어떤 장애 유형이 반복되는가?
  • (타임아웃, 설정 드리프트, DB 포화, 잘못된 피쳐 플래그 등)
• 어디에 테스트, 카나리, 서킷 브레이커가 부족한가?

이 정보를 토대로 다음에 투자합니다.

• 더 나은 설계: 취약한 컴포넌트를 단순화하고, 핫스팟을 디커플링하고, 백프레셔를 추가합니다.
• 강한 검증(Validation): 스키마 체크, 설정 검증, CI 단계에서의 세이프티 체크.
• 회귀 테스트(Regression testing): 과거 장애를 명시적으로 커버하는 새 테스트를 추가합니다.
• 점진적 배포(Progressive delivery): 카나리 릴리스, 블라스트 반경 제어가 가능한 피쳐 플래그.

어떤 변경 제안이 올라왔을 때, 엔지니어들이 자동으로 이렇게 묻게 만들고 싶습니다.

“스토리 열차 묘지에 있는 어느 인시던트가, 이 변경으로 예방되거나 더 악화됐을까?”

이 질문 하나만으로도 사고방식이 ‘사고 수습’에서 ‘사고 예방’ 쪽으로 자연스럽게 기울어집니다.

7단계: 분석으로 인시던트 관리 자체를 계속 개선하라

회고를 표준화하고 인시던트를 잘 아카이빙하기 시작했다면, 이제 정량 분석을 할 수 있습니다.

기본적인 신뢰성 지표부터 추적하세요.

• MTTR (Mean Time to Recovery): 평균 복구 시간
• MTTD (Mean Time to Detect): 평균 탐지 시간
• 인시던트 빈도: 서비스별, 장애 유형별
• Change-failure rate(변경 실패율): 배포가 인시던트로 이어지는 비율

여기서 더 나아가:

• 장애 발생 확률 분석(Outage probability analysis)
  • 다음 분기 안에 SEV-1을 일으킬 가능성이 가장 높은 서비스는 어디인가?
  • 이중화, 모니터링, 오너십 부재로 인해 어디에서 가장 크게 노출되어 있는가?
• 패턴 탐지
  • 고임팩트 인시던트 대부분이 특정 유형의 변경(스키마 마이그레이션, 대량 import, 인프라 업그레이드 등)과 연결되어 있지 않은가?
  • 인시던트가 특정 릴리스 시간대나 특정 팀 주변에 몰려 있지는 않은가?

이 인사이트를 활용해 다음을 수행합니다.

• 로드맵에서 신뢰성 작업의 우선순위 조정
• 온콜 로테이션과 교육의 재설계
• 카오스 엔지니어링이나 게임데이(훈련)를 ‘효과가 가장 클’ 곳에 집중

이렇게 하면 스토리 열차 묘지는 기억이자 모델이 됩니다. 서사를 담은 아카이브이자, 예측에 활용 가능한 도구입니다.

결론: 퇴역한 장애들이 레일을 지키게 하라

장애는 앞으로도 계속 발생할 것입니다. 차이는, 그것들이 잊힌 채 채팅 로그와 캘린더 초대 속으로 사라질지, 아니면 다음 배포를 조용히 지키는 수호자가 될지에 있습니다.

다음과 같은 실천을 통해:

• 구조화된, 데이터 기반 회고를 운영하고
• 탄탄한 데이터와 다양한 이해관계자의 입력으로 철저히 준비하며
• 심리적 안전과 시스템 중심 사고를 바탕으로 회고를 진행하고
• 인사이트를 오너가 있는, 기한이 정해진 액션 아이템으로 번역하고
• 눈에 보이는 스토리 열차 묘지를 만들어 인시던트 스토리를 쌓고
• 반응적 탐지에서 사전 예방 중심으로 전환하며
• 분석과 모델링으로 인시던트 관리 자체를 계속 개선하면

…모든 “다시는 이런 일이 없었으면” 하는 순간을 실제 ‘개선’으로 바꿀 수 있습니다.

기차는 여전히 가끔 탈선할 것입니다. 하지만 잘 돌본 ‘퇴역 장애’ 묘지가 선로를 지켜보고 있다면, 각 배포는 이전보다 조금 더 안전한 레일 위를 달리게 됩니다.