연필로 그린 장애 타임머신: 종이 위에서 장애를 다시 재생해 미래의 실패를 다시 쓰는 법

장애를 위한 타임머신이 있다고 상상해보자.

화려한 불빛이 번쩍거리는 SF 속 장치가 아니라, 훨씬 소박한 것들이다. 연필 한 자루, 종이 한 장, 그리고 일어난 일을 다시 재생하는 구조화된 방식. 이미 발생한 장애 자체를 되돌릴 수는 없지만, 충실하게 되감기 해서 한 프레임씩 다시 보고, 이해하고, 다음 번 장애가 어떻게 진행될지 “다르게 작성”할 수는 있다.

좋은 장애 포스트모템(사후 분석)은 바로 그런 연필로 그린 타임머신이다.

잘만 하면 혼란은 명료함으로, 패닉은 프로세스로, 힘들었던 하루는 수십 번의 더 나은 날로 바뀐다.

이 글에서는 명확한 타임라인, 근본 원인 분석(RCA), 블레임리스 리뷰, 표준화된 액션 아이템, 재사용 가능한 템플릿이 포함된 구조적이고 반복 가능한 포스트모템 접근법이, 팀이 장애에 대응하고 그로부터 학습하는 방식을 어떻게 바꿀 수 있는지 살펴본다.

왜 연필로 그린 타임머신이 필요한가

장애는 실시간에선 늘 지저분하게 느껴진다. Slack 스레드, 로그 대시보드, 어렴풋이 기억나는 타임스탬프, 개인적인 촉 같은 것들이 뒤섞인다. 장애가 끝난 뒤, 이런 조각난 정보는 금방 흐릿한 기억과 전설 같은 이야기로 휘발된다.

“그때쯤 DB가 read-only로 바뀐 것 같아요… 누가 서비스 재시작하긴 했는데…”

구조가 없으면, 포스트모템은 매번 새로 하는 발굴 작업이 된다. 무엇을 남길지 매번 다시 논쟁하고, 중요한 걸 놓치지 않기만을 바랄 뿐이다. 비싸고, 신뢰하기 어렵고, 확장도 안 된다.

구조화되고 반복 가능한 포스트모템 템플릿은 연필로 그린 타임머신을 제공한다.

• 항상 어디서부터 시작해야 할지 안다.
• 매번 같은 핵심 정보를 빠짐없이 수집한다.
• 한 번의 나쁜 장애를, 미래 대응자들을 위한 교육·가이드용 재사용 아티팩트로 만든다.

압박 속에서 즉흥적으로 대응하는 대신, 검증된 스크립트를 따른다. 시간이 지날수록 조직은 “시스템이 스트레스 상황에서 실제로 어떻게 동작하는지”를 보여주는, 풍부하고 검색 가능한 장애 라이브러리를 쌓게 된다.

타임라인: 프레임 단위로 다시 보는 당신의 장애 영화

타임머신의 심장은 이벤트 타임라인이다.

좋은 타임라인은 단순히 타임스탬프 나열을 넘어서, 시스템·사람·의사결정 전반에서 현실이 어떻게 전개됐는지를 보여준다.

• 감지(Detection) – 최초 신호는 언제였나? 알림? 고객 제보?
• 인지·응답(Acknowledgment) – 사람이 언제 개입했고, 누가 메인 담당이었나?
• 진단(Diagnosis) – 무엇을 시도했나? 어떤 가설이 검토됐다가 폐기됐나?
• 완화(Mitigation) – 어떤 조치를 어떤 순서로 수행했나?
• 복구(Resolution) – 서비스가 실제로 언제 복구·검증됐나?

타임라인이 그렇게 중요한 이유

명확한 타임라인은 다음을 드러낸다.

• 모니터링·알람의 빈틈 (예: 사용자가 문제를 보고한 지 20분 뒤에야 알람이 울렸다.)
• 협업·조율의 병목 (예: DB 접근 권한을 기다리느라 15분이 소요됐다.)
• 헷갈리는 신호와 막다른 길 (예: 전혀 엉뚱한 컴포넌트를 30분 동안 디버깅했다.)

이 이벤트들을 실제로 선 위에 그려보면—화이트보드든, 공유 문서든—팀은 장애를 영화처럼 다시 재생하며 질문할 수 있다. 우리는 어디서 시간을 잃었지? 무엇이 우리를 헷갈리게 했지? 무엇이 실제로 도움이 됐지?

여기서 “연필”이 중요해진다. 사실을 모아가며 타임라인을 계속 다듬고, 가설과 추측은 지우고, 증거로 교체한다.

근본 원인 분석: 처음 고장 난 것에서 멈추지 않기

포스트모템에서 흔한 유혹은 가장 먼저 깨진 것에만 책임을 돌리는 것이다. 잘못된 설정, 버그가 있는 배포, 죽은 노드 같은 것들 말이다.

하지만 근본 원인 분석(Root Cause Analysis, RCA) 은 더 깊은 질문을 던진다.

왜 “이” 장애가 이렇게 큰 인시던트로까지 번질 수 있었을까?

표면적인 증상에서 멈추지 않고, RCA는 시스템의 뿌리로 들어간다.

• 기술적 원인 – 설계 결함, 빠진 세이프가드, 부족한 용량, 취약한 의존성.
• 프로세스적 원인 – 누락된 리뷰, 허술한 변경 관리, 부서지기 쉬운 런북, 모호한 오너십.
• 조직적 원인 – 리소스 부족 팀, 사일로화된 지식, 속도를 위해 안전을 희생하는 인센티브 구조.

유용한 RCA 기법으로는 다음이 있다.

• 5 Whys 기법 – “왜?”를 계속 물어, 시스템 레벨의 문제에 도달할 때까지 파고든다.
• 인과관계 다이어그램(피시본 등) – 여러 기여 요인이 어떻게 합쳐져 장애를 만들었는지 시각적으로 그려본다.

예를 들어,

• 증상: API 지연 시간이 급격히 올랐다.
• 직접 원인: DB CPU가 포화 상태에 도달했다.
• 더 깊은 원인: 부하 테스트 없이 릴리스된, 제어되지 않은 쿼리 패턴.
• 시스템적 원인: CI/CD 파이프라인에 성능 회귀 검증이 없었고, DB CPU에 대한 알람도 포화 상태가 될 때까지 없었다.

근본 원인 분석의 목적은 누군가를 탓하는 것이 아니라, 레버리지 포인트—작지만 시스템 전체의 장애 유형을 예방할 수 있는 변화 지점을 찾는 것이다.

블레임리스 리뷰: 심리적 안전의 엔진

사람들이 진실을 말하기 두려워한다면, 이 모든 것은 작동하지 않는다.

블레임리스(Blameless) 포스트모템은 다음과 같은 전제를 바탕으로 한다.

합리적인 사람들이, 제한된 정보 안에서, 최선을 다했지만, 시스템이 그들을 뒷받침해주지 못했다.

비난은 누가 잘못했는지에 집중한다. 학습은 무엇이 그런 실수를 쉽게, 눈에 띄지 않게, 혹은 필연적으로 만들었는지에 집중한다.

블레임리스 리뷰는 다음을 장려한다.

• 솔직한 공유 – 판단 착오, 혼란, 아슬아슬했던 순간까지 드러낸다.
• 풍부한 맥락 – “무슨 일이 있었는지”뿐 아니라, 각 단계에서 엔지니어들이 “무엇을 생각했는지”를 공유한다.
• 심리적 안전 – 문제 제기와 리스크 신고가 처벌이 아니라 인정받는 행동임을 모두가 안다.

실제로는 다음과 같은 방식으로 구현된다.

• “오퍼레이터 실수”, “XXX의 실수로 인해” 같은 표현을 피한다.
• 질문을 맥락과 제약에 맞춘다. “그때 가지고 있던 정보는 무엇이었나요? 무엇 때문에 그게 옳은 선택처럼 보였나요?”
• 리더가 먼저 나서서 시스템적 공백을 인정하고, 취약함을 드러낸다.

블레임리스는 “책임 없음”을 의미하지 않는다. 다만 먼저 시스템에 책임을 묻는다는 뜻이다. 사람들이 안전하다고 느낄 때, 향후 장애 예방에 진짜 도움이 되는 디테일이 공유된다.

표준화된 액션 아이템: 인사이트를 실제 변화로 바꾸기

아무리 훌륭한 포스트모템도, 변화로 이어지지 않으면 그냥 잘 쓰인 이야기일 뿐이다.

미래의 실패를 다시 쓰려면, 모든 포스트모템은 표준화되고 추적 가능한 액션 아이템으로 끝나야 한다.

• 명확한 오너 – 특정 개인 또는 팀이 책임을 가진다.
• 구체적인 설명 – 무엇을 할지 정확히 적는다. (“모니터링 개선”이 아니라 “p95가 5분 동안 400ms를 초과하면 알람이 울리도록 Latency SLO 및 알람 추가”처럼.)
• 우선순위와 효과 – 이 작업이 어떻게 리스크를 줄이거나 신뢰성을 높이는지.
• 완료 기한 – 언제까지 반영할 것인지.

좋은 액션 아이템 예시:

• “3월 15일까지 DB CPU·커넥션 풀 포화 알람을 추가하고, 관련 런북 항목을 작성한다 (SRE 팀).”
• “Q3 이전까지 /v1/orders 엔드포인트에 대한 성능 회귀 테스트를 CI에 도입한다 (API 팀).”

액션 아이템은 표준 포맷으로 작성하고, JIRA, Linear 등의 기존 플래닝 툴에서 추적하자. 정기적으로 인시던트 관련 액션 아이템의 오픈 상태를 리뷰하지 않으면, 인사이트가 문서 안에서만 쌓이고 실제 시스템에는 전혀 반영되지 않는 상황이 온다.

재사용 가능한 체크리스트와 템플릿: 매번 양식부터 다시 만들지 말 것

매번 포스트모템을 완전한 백지 상태에서 시작하면, 정작 배울 것보다 프로세스 설계에 더 많은 에너지를 쓴다.

재사용 가능한 체크리스트와 템플릿은 다음을 쉽게 만들어준다.

• 인시던트 데이터를 일관되게 수집한다.
• 새로운 인시던트 커맨더(Incident Commander)를 빠르게 온보딩한다.
• 다른 팀도 쉽게 이해·비교할 수 있는 리포트를 빠르게 발행한다.

가벼운 포스트모템 템플릿에는 다음 정도가 들어갈 수 있다.

• 요약(Summary) – 한 단락 정도의 개요와 비즈니스 임팩트.
• 타임라인(Timeline) – 주요 이벤트, 타임스탬프, 출처.
• 임팩트(Impact) – 누가, 얼마나, 얼마나 오래 영향을 받았는지.
• 기술적 상세(Technical details) – 실제로 무엇이 어떻게 고장 났는지.
• 근본 원인 분석(RCA) – 시스템 차원의 기여 요인들.
• 잘된 점(What went well) – 피해를 줄이는 데 도움이 된 관행.
• 헷갈렸던 점(What was confusing) – 도구, 지식, 커뮤니케이션 측면의 공백.
• 액션 아이템(Action items) – 표준화되고, 오너가 있고, 우선순위가 정해진 작업들.

시간이 지나면서 팀은 무엇이 가장 도움이 되는지에 따라 이 템플릿들을 계속 다듬을 수 있다. 목표는 관료주의가 아니라, **마찰 없는 학습(frictionless learning)**이다.

포스트모템을 팀 문화에 심기

한 번 잘 진행된 포스트모템도 물론 유익하다. 하지만, 포스트모템을 당연하게 여기고 가치 있게 여기는 문화는 조직을 완전히 바꿔놓는다.

포스트모템이 문화에 녹아들었다는 것은 대략 다음과 같은 모습을 말한다.

• 모든 의미 있는 인시던트에는, 정해진 기간 안에 포스트모템을 진행한다.
• 리더들이 참여해 블레임리스 대화를 직접 보여준다.
• 포스트모템 인사이트가 팀 간에 공유되고, 사일로에 갇히지 않는다.
• 인시던트에서 얻은 교훈이 로드맵, 용량 계획, 설계 리뷰에 반영된다.
• 신규 입사자가 온보딩 과정에서 과거 인시던트를 학습한다.

시간이 지나면 조직의 관점도 이렇게 달라진다.

• “이번에 큰 장애가 났다.” → “값진 학습 기회를 얻었다. 같은 방식으로 다시 물리지 않도록 이렇게 바꿨다.”

그 결과는 이렇다. 같은 유형의 실패가 줄어들고, 문제가 생겨도 더 빨리 복구하며, “신뢰성은 모두의 책임”이라는 공감대가 자리 잡는다.

결론: 연필로 그린 뒤, 실천으로 다시 쓰기

모든 장애를 예방할 수는 없다. 시스템은 복잡하고, 환경은 변하고, 사람은 개입된다. 하지만 각 장애에서 얼마나 잘 배우느냐는 선택할 수 있다.

구조화된 포스트모템, 명확한 타임라인, 솔직한 근본 원인 분석, 블레임리스 리뷰, 표준화된 액션 아이템, 재사용 템플릿으로 구성된 연필로 그린 인시던트 타임머신은 다음을 가능하게 한다.

• 기억이 아니라, 실제 있었던 일을 재구성한다.
• 개인을 탓하는 대신, 시스템의 약점을 찾아낸다.
• 각 장애를 장기적인 신뢰성 투자로 전환한다.

연필이 중요한 이유는, 그것이 “반복 수정을 전제로 한 도구”이기 때문이다. 기록하고, 고치고, 다듬고, 그 배움을 구체적인 개선으로 옮긴다.

어제의 장애를 막기 위해 과거로 돌아갈 수는 없다. 하지만 그 장애를 충분히 정교하게 “다시 재생”해, 내일의 장애가 전혀 다른 양상으로 흘러가게 만들 수는 있다.

연필을 집어 들자. 타임머신을 그리자. 그리고 그것으로 아직 일어나지 않은 미래의 실패를, 미리 다시 써놓자.