아날로그 인시던트 이야기의 기차역 다락방: 잊힌 장애들을 털어내 다음 장애를 예측하는 법

이 장면을 떠올려 보세요. 여러분 조직의 인시던트 히스토리는 오래된 기차역 다락방입니다.

위층, 수십 년 된 먼지 아래에는 손으로 쓴 로그, 누렇게 바랜 장애 보고서, 새벽 3시 워룸에서 끄적였던 메모가 담긴 상자들이 쌓여 있습니다. 상자 하나하나에는 망가진 시스템, 영향을 받은 고객, 그리고 서비스를 다시 살리기 위해 분투했던 팀의 이야기가 들어 있습니다.

이제 그 다락방을 이용해서 다음 장애를 예측해야 한다고 상상해 봅시다.

이렇게 해야 할 겁니다.

삐걱거리는 사다리를 타고 올라가고
라벨도 없는 상자를 뒤지고
반쯤만 기록된 이야기를 이어 붙여야 합니다.

오늘날에도 많은 SRE와 플랫폼 팀이 인시던트 지식을 이런 식으로 다룹니다. 아날로그이고, 조각나 있고, 정말 필요할 때는 거의 쓸 수 없는 상태로 말이죠.

이 글은 그 다락방을 치우는 이야기입니다.

흩어진, 정적인 포스트모템을 구조화되고, 블레임리스하며, 완전히 검색 가능한 인시던트 지식 베이스로 바꾸는 과정을 살펴보겠습니다. 이 지식 베이스는 과거의 이야기를 들려주는 데 그치지 않고, 다음 대형 장애를 예측하고 예방하는 데 도움을 줍니다.

SRE에 엔드 투 엔드 인시던트 라이프사이클이 필요한 이유

대부분의 팀은 인시던트의 한 부분, 즉 불 끄기(firefighting) 는 꽤 잘합니다.

보통 문제가 되는 곳은 이 불 끄기를 둘러싼 모든 부분입니다.

사전에: 예전에 비슷한 일이 있었음을 암시하는 약한 신호를 포착하는 것
이후에: 무슨 일이, 왜 일어났고, 무엇이 달라졌는지 기록하는 것
그 후에: 그 정보를 실제로 활용해 재발을 막는 것

인시던트를 개별 사건으로 취급하는 SRE 조직은 항상 "반응"만 하고 있다는 느낌을 받게 됩니다. 더 탄탄한 복원력을 갖추려면, 인시던트 관리를 위한 구조화된 엔드 투 엔드 접근법이 필요합니다.

탐지(Detection) – 문제가 발생했음을 얼마나 빠르고 신뢰성 있게 알아차리는가
트리아지 및 대응(Triage and Response) – 어떻게 조율하고, 커뮤니케이션하며, 영향을 줄이는가
복구 및 해결(Resolution) – 어떻게 서비스를 복구하고, 상태를 검증하며, 이해관계자와의 사이클을 닫는가
사후 리뷰(Post-Incident Review) – 무슨 일이 있었고 무엇을 배웠는지 어떻게 문서화하는가
후속 조치 및 개선(Follow-Up and Improvement) – 어떻게 액션을 추적하고, 리스크를 줄이며, 효과를 검증하는가

이 중 마지막 두 단계에서 바로 "다락방 문제"가 드러납니다. 구조와 중앙화가 없다면, 모든 인시던트는 한 번 이야기하고 잊어버리는 단발성 스토리가 됩니다.

먼지 쌓인 이야기에서 검색 가능한 시스템 오브 레코드로

포스트모템이 여기저기 랜덤한 문서, 채팅 로그, 사람들 머릿속에 흩어져 있다면, 미래를 위한 인사이트로 쓰일 수 없습니다.

아날로그 다락방에서 벗어나는 첫 단계는 중앙화입니다.

모든 인시던트 포스트모템이 모이는 하나의 검색 가능한 플랫폼
심각도(severity), 지속 시간, 영향, 관련 서비스, 근본 원인(root causes), 트리거(trigger), 재발 방지 조치(remediation) 등 핵심 데이터를 위한 표준 필드
인시던트, 알림(alert), 런북(runbook), 코드 변경 사항 사이의 링크

이렇게 하면 인시던트 히스토리가 오래된 다락방이 아니라, 현대식 기차역의 시간표처럼 변합니다. 정리되어 있고, 조회할 수 있으며, 행동으로 옮길 수 있습니다.

이제 다음과 같은 질문에 답할 수 있습니다.

“지난 12개월 동안 발생한 SEV-1 인시던트 중 결제 게이트웨이와 관련된 것만 보여줘.”
“설정 플래그(config flag) 때문에 고객에게 영향을 준 인시던트는 얼마나 자주 있었지?”
“어떤 서비스가 가장 많은 고심각도 인시던트를 유발하고 있지?”

인시던트 이야기가 먼지 쌓인 페이지에서 구조화된 데이터로 옮겨가는 순간, 과거의 장애는 전설이 아니라 증거가 됩니다.

표준화된 포스트모템: 혼돈 속을 가르는 레일라인

중앙화만으로는 충분하지 않습니다. 포스트모템마다 포맷, 표현 방식, 디테일 수준이 제각각이라면, 데이터는 잡동사니 서랍이 되어 버립니다.

SRE 팀은 포스트모템 전반에 걸쳐 일관되고 표준화된 데이터가 있어야 패턴을 발견할 수 있습니다.

좋은 표준 템플릿에는 보통 다음 항목이 포함됩니다.

메타데이터: 날짜, 시간, 지속 시간, 심각도, 영향을 받은 리전/서비스
영향 요약: 누가, 어떻게, 얼마나 오래 영향을 받았는지
타임라인: 탐지부터 해결까지 핵심 이벤트
기술적 근본 원인(Technical root cause): 근본이 되는 기여 요인들
트리거(Trigger): 잠재된 문제를 수면 위로 끌어올린 구체적 사건
탐지 및 대응(Detection & response): 인시던트를 어떻게 발견하고 처리했는지
인시던트 중 적용된 완화책 및 우회책(Mitigations & workarounds)
후속 조치(Follow-up actions): 담당자, 기한, 성공 기준

이 구조가 자리 잡으면, 시스템적 패턴과 반복되는 실패 양상이 보이기 시작합니다. 예를 들면 다음과 같습니다.

특정 서비스에 과도하게 몰린 인시던트
도구 부족으로 인해 반복되는 설정 실수
실제 고객 영향보다 훨씬 늦게 탐지되는 인시던트가 여러 번 발생한 경우

일관된 데이터가 없으면, 가지고 있는 건 그저 이야기뿐입니다. 일관된 데이터가 있으면, 거기에는 시그널이 있습니다.

블레임리스 리포팅: 진짜 이야기를 끌어내는 유일한 방법

이 모든 것은 솔직함에 달려 있습니다.

엔지니어들이 포스트모템이 책임을 전가하는 도구로 쓰일까 두려워한다면 자연스럽게 이런 행동을 하게 됩니다.

타임라인을 정제해서 내보이고
사람의 실수를 숨기거나 축소하고
문제를 시스템적 취약점이 아닌 "희귀한 사고"로 포장합니다.

이는 사기를 꺾는 수준에서 끝나지 않습니다. 여러분의 데이터를 망가뜨립니다.

블레임리스(blameless) 리포팅은 책임을 무시하자는 뜻이 아닙니다. 대신 다음 사실을 인정하자는 것입니다.

복잡한 시스템은 복잡한 방식으로 실패한다.
개인은 도구, 프로세스, 문화, 인센티브로 형성된 제약 속에서 일한다.
대부분의 "인적 오류"는 실제로는 주변 시스템의 설계 오류다.

블레임리스 포스트모템은 다음과 같은 질문에 초점을 맞춥니다.

무엇이 이 실수가 일어나기 쉽게 만들었는가?
왜 우리의 탐지 시스템은 이 문제를 더 일찍 잡아내지 못했는가?
도구, 문서, 프로세스 중 무엇이 대응자에게 도움을 주지 못했는가?

비난은 피상적인 이야기를 만들어 냅니다. 블레임리스 문화는 진짜 근본 원인을 파고들 수 있을 만큼 깊이를 만들어 줍니다.

메이저 인시던트 리뷰: 탈선을 새로운 선로로 바꾸기

모든 인시던트에 대해 크로스펑셔널 회의를 열 필요는 없습니다. 하지만 메이저 인시던트(major incident), 즉 고객 영향이 크거나 반복 패턴이 보이는 인시던트에 대해서는 반드시 해야 합니다.

탄탄한 메이저 인시던트 리뷰 프로세스는 보통 다음을 포함합니다.

사전 작업(Pre-work)
- 사전에 공유된, 잘 작성된 구조화된 포스트모템
- 컨텍스트를 위한 관련 로그, 대시보드, 아키텍처 다이어그램 링크
구조화된 리뷰 미팅(Structured review meeting)
- 논의를 포커스 있게, 블레임리스하게 이끄는 퍼실리테이터
- 타임라인, 원인, 탐지/대응, 영향, 후속 조치로 구성된 명확한 아젠다
- 인시던트 플랫폼에 저장된 데이터를 기반으로 한 논의
결과 캡처(Outcome capture)
- 합의된 근본 원인 및 기여 요인
- 우선순위가 매겨진 실행 가능한 후속 조치
- 담당자, 마감일, 기대 결과가 명확히 정의됨

핵심은 이 리뷰가 데이터 기반이어야 한다는 점입니다. 의견이 아니라, 중앙화되고 표준화된 인시던트 기록이 대화의 기준선이 되어야 합니다.

근본 원인 vs 트리거: 신호와 객차를 혼동하지 말라

구조화된 데이터와 엄 disciplined 한 리뷰를 활용하면 다음 둘을 구분하기가 쉬워집니다.

트리거(Trigger) – 인시던트를 촉발한 눈에 보이는 사건 (배포, 설정 변경, 페일오버 등)
근본 원인(Root causes) – 그 트리거가 치명적인 결과로 이어지게 만든 더 깊은 시스템적 조건 (검증 부재, 세이프가드 부족, 용량 부족, 취약한 의존성 등)

예를 들어:

트리거: 피처 플래그 토글이 한 번에 모든 고객에게 변경 사항을 롤아웃했다.
근본 원인:
- 점진적 롤아웃이나 카나리 배포 프로세스 부재
- 에러율 급증 시 자동 롤백 메커니즘 부재
- 특정 리전에 대한 모니터링 블라인드 스폿

피상적인 리뷰는 “그 플래그는 다시 건드리지 말자.” 에서 멈춥니다.

구조화되고 블레임리스한 리뷰는 여기까지 갑니다. “왜 단일 플래그가 모든 사용자에게 영향을 줄 수 있었지? 어떤 보호 장치가 없었나?”

여기서 다락방 비유가 다시 중요해집니다. 트리거의 이야기에만 집착하면, 서로 전혀 달라 보이는 인시던트들을 이어 주는 근본 원인의 패턴을 놓치게 됩니다.

실행 가능한 후속 조치: 실제로 선로를 바꾸는 일

“우리가 앞으로는 더 잘해야 한다”라는 말로 끝나는 인시던트 리뷰는 일종의 연극에 불과합니다.

재발 가능성을 낮추려면, 후속 조치는 다음과 같아야 합니다.

구체적(Specific) – 모호한 다짐이 아니라 명확한 기술/프로세스 변경
책임 있는 주체가 지정(Owned) – 책임지는 사람 또는 팀이 명시되어야 함
기한이 있음(Time-bound) – 마감일 또는 마일스톤
측정 가능(Measurable) – "유사 이슈에 대한 MTTD 50% 감소"와 같은 성공 기준 정의

그리고 결정적으로, 이 액션들은 인시던트 기록과 같은 시스템 안에 존재해야 합니다.

각 인시던트는 자신의 후속 태스크에 링크되고
각 태스크는 자신이 완화하는 인시던트(들)에 링크되며
상태(열림, 진행 중, 완료)가 보이고 리포팅 가능해야 합니다.

시간이 지나면, 다음과 같은 강력한 질문을 던질 수 있습니다.

후속 조치가 이행되지 않은 인시던트에서 재발 사고가 얼마나 많이 발생했나?
어떤 팀은 인시던트 후속 조치를 꾸준히 완료하고, 어떤 팀은 그렇지 못하는가?
특정 완화 조치를 도입한 이후 사라진 인시던트 유형은 무엇인가?

이 지점에서 과거의 장애는 단순한 회고를 넘어 미래를 예측하는 도구가 됩니다. 어떤 리스크는 줄었고, 어떤 리스크는 그대로 노출되어 있는지가 명확해지기 때문입니다.

다락방에서 컨트롤 룸으로

이 모든 요소를 하나로 모으면, 여러분이 구축하는 것은 더 이상 단순한 이야기 모음이 아닙니다.

여러분은 신뢰성을 위한 컨트롤 룸(control room) 을 만들고 있는 것입니다.

엔드 투 엔드 인시던트 라이프사이클을 통해 모든 장애는 단순한 소방 훈련이 아니라 학습의 기회가 됩니다.
중앙화되고 검색 가능한 인시던트 플랫폼은 흩어진 포스트모템을 운영 지식 베이스로 바꿉니다.
표준화되고 구조화된 데이터는 시스템 전반의 패턴과 반복되는 실패 양상을 드러냅니다.
블레임리스 문화는 진짜 이야기를 안전하게 꺼낼 수 있게 해 주며, 데이터가 현실을 제대로 반영하도록 만듭니다.
메이저 인시던트 리뷰는 고통스러운 장애를 장기적인 시스템 개선으로 전환합니다.
실행 가능하고 추적 가능한 후속 조치는 루프를 닫고, 실제로 시스템의 동작 방식을 바꿉니다.

아날로그 인시던트 이야기의 다락방은 어떤 형태로든 항상 존재할 것입니다. 전설 같은 워 스토리, 밤샘 히어로 스토리, “예전에 프로덕션이 불타던 거 기억나?” 같은 농담 말이죠.

차이는 그 이야기들이 먼지 쌓인 상자 속에 잠겨 있는가, 아니면 열차를 제때 달리게 해 주는 구조화된 살아 있는 지식으로 변환되었는가에 있습니다.

다음 장애를 예측하고 싶다면, 우선 지난 수십, 수백 건의 장애를 털어내세요. 그리고 그 이야기들이 다락방이 아닌, 더 나은 집—살아 있는 인시던트 지식 베이스—을 갖도록 해 주십시오.