장애 회고 영상 녹화: 장애를 팀의 자산으로 바꾸는 법

모든 팀은 장애가 발생하면 포스트모템 문서를 작성합니다. 하지만 그 문서를 끝까지 읽는 사람은 훨씬 적습니다. 대시보드 링크와 로그 조각으로 가득한 타임라인은 읽는 사람에게 장애 상황을 머릿속으로 재구성하라고 요구합니다. 대부분은 대충 훑어보고 고개를 끄덕인 뒤 넘어가죠.

짧은 화면 녹화는 이 상황을 바꿉니다. 새벽 2시 14분의 에러율 그래프가 어땠는지 글로 설명하는 대신 직접 보여주면 됩니다. 근본 원인을 찾아낸 쿼리를 설명하는 대신 그 자리에서 실행해 보이면 됩니다. 이 가이드에서는 팀이 실제로 시청하는 장애 회고 영상을 만드는 방법과, 몇 달 뒤에도 유용하게 남기는 방법을 알아봅니다.

왜 포스트모템을 녹화해야 할까

• 설명보다 증거: 그래프, 트레이스, 로그는 본질적으로 시각적입니다. 스크린샷은 급격한 변화를 한눈에 보여주는 전후 움직임을 담아내지 못합니다
• 제작이 더 빠름: 이미 열려 있는 화면을 설명하며 녹화하는 것이 잘 다듬은 문장을 쓰는 것보다 시간이 적게 듭니다
• 신규 입사자에게 효과적: 6분짜리 장애 요약 영상 한 편이 위키 문서보다 시스템의 실패 양상을 훨씬 빠르게 이해시켜 줍니다
• 판단 과정 보존: 문서는 무슨 일이 일어났는지 기록하지만, 영상은 대응자가 각 단계에서 왜 그렇게 생각했는지를 담아냅니다
• 비동기 친화적: 분산된 팀이 시간대를 맞춰 또 다른 회의를 잡지 않고도 리뷰를 소화할 수 있습니다

무엇을 녹화하고, 무엇을 생략할까

포스트모템 녹화는 장애 전체를 재현하는 것이 아닙니다. 글보다 보는 것이 나은 부분에만 집중하세요.

녹화할 것:

• 감지 순간 — 알림, 대시보드, 첫 사용자 제보
• 장애 구간의 영향도를 보여주는 핵심 그래프
• 범위를 좁혀간 조사 단계(막다른 길을 포함해서)
• 장애를 유발한 정확한 코드, 설정, 쿼리
• 수정이 적용되고 지표가 회복되는 장면

생략할 것:

• 배포나 데이터 로딩을 기다리는 긴 구간
• 진단과 무관한 내부 대화
• 나레이션 한 문장으로 설명할 수 있는 모든 것

녹화 전 준비

장애 대응 도구에는 공유 영상에 담기면 안 되는 것들이 많습니다. 5분만 투자해 준비하세요.

1. 탭을 미리 열어두기: 올바른 시간 범위의 대시보드, 관련 로그 쿼리, 풀 리퀘스트, 알림
2. 시간 범위 고정: 대시보드를 장애 구간에 고정해 시청자가 같은 화면을 보게 하세요
3. 민감한 화면 닫기: 고객 정보, 개인정보가 담긴 내부 티켓, 개인 DM, 자격 증명 관리자
4. 알림 끄기: 진지한 포스트모템 도중 점심 알림이 뜨는 것만큼 몰입을 깨는 것도 없습니다
5. 세 줄 개요 작성: 영향, 근본 원인, 재발 방지. 나머지는 이 세 가지에 딸려 옵니다

대시보드가 브라우저 창 하나에 들어 있다면 전체 화면 대신 윈도우 캡처를 사용하세요. 다른 것이 화면에 새어 나오지 않도록 하는 가장 간단한 방법입니다.

효과적인 구성

영상 길이는 5~10분이 적당합니다. 검증된 구성은 다음과 같습니다.

1. 영향부터 (30초): 누가, 얼마나 오래, 얼마나 심하게 영향을 받았는지. 대부분의 시청자가 가장 궁금해하는 내용이니 먼저 말하세요
2. 타임라인 설명 (2~3분): 감지, 에스컬레이션, 완화, 해결 과정을 실제 대시보드 위에서 보여주기
3. 근본 원인 (2~3분): 실제 코드 경로, 설정 변경, 쿼리를 보여주세요. 문제가 된 줄을 확대해서
4. 무엇이 어려웠는가 (1분): 누락된 알림, 혼란스러운 로그, 불명확한 담당자 — 문서에서는 흔히 뭉개지는 부분입니다
5. 후속 조치 (1분): 각 항목을 담당자와 함께 소리 내어 말하고, 설명란에 링크를 남기세요

편집기로 가독성 높이기

날것의 장애 영상은 정보 밀도가 높습니다. Recorded의 편집기로 따라가기 쉽게 만들어 보세요.

• 줌 효과: 대시보드와 로그는 글씨가 작습니다. 급증 구간, 에러 메시지, 문제의 diff를 확대하세요. 시청자가 눈을 가늘게 뜨게 하지 마세요
• 속도 구간: 배포 파이프라인과 쿼리 실행은 빠르게 넘기고, 근본 원인이 드러나는 순간에는 정상 속도로 돌아오세요
• 텍스트 오버레이: 타임라인 설명에 타임스탬프(02:14 UTC — 첫 알림)를 표시해 영상과 문서를 대응시키세요
• 트리밍: 대시보드 시간 범위를 잘못 맞췄다가 다시 시작한 도입부는 잘라내세요
• 커서 효과: 재현 경로를 보여줄 때 클릭을 강조하세요

웹캠은 도입부와 마무리에만 사용하세요. 영향과 후속 조치를 말할 때는 얼굴이 톤을 전달하는 데 도움이 되지만, 로그를 분석할 때는 터미널을 가릴 뿐입니다.

비난 없는 톤 유지하기

영상은 문서와 달리 말투가 그대로 전달됩니다. 같은 문장도 전달 방식에 따라 분석으로 들릴 수도, 비난으로 들릴 수도 있습니다.

• 누가 배포했는지 언급하는 대신 “이 배포에서 유입되었습니다”라고 말하세요
• 당시에 알 수 있었던 정보를 기준으로 설명하세요: “이 시점에는 큐 깊이 지표가 아직 없었습니다”
• 막다른 길도 변명 없이 보여주세요. 시스템을 진단하기 어려웠다는 증거이고, 그 자체가 개선 과제입니다
• 도입부 녹음이 짜증 섞인 톤이라면 다시 찍으세요. 2분이면 되고, 영상을 볼 모든 사람의 분위기를 좌우합니다

문서와 함께 활용하기

영상은 포스트모템 문서를 보완하는 것이지 대체하는 것이 아닙니다. 문서는 검색하고, 링크하고, 훑어볼 수 있지만 영상은 그렇지 않습니다.

좋은 조합은 다음과 같습니다.

• 타임라인, 후속 조치, 담당자의 기준은 문서가 유지합니다
• 영상은 문서 상단에 임베드하고, 무엇을 다루는지 한 줄 요약을 덧붙입니다
• 설명란의 챕터 타임스탬프로 근본 원인 구간에 바로 이동할 수 있게 합니다
• 후속 조치는 영상이 아니라 이슈 트래커에 등록합니다

장애 아카이브 만들기

개별 녹화도 유용하지만, 모아 놓으면 가치가 훨씬 커집니다.

• 일관된 이름 규칙: 2026-09-28-checkout-latency-postmortem 형식은 정렬과 검색이 깔끔합니다
• 시스템별 태그: 관련 서비스별로 묶어 두면 신규 온콜 담당자에게 특정 컴포넌트 관련 자료를 통째로 넘길 수 있습니다
• 분기별 리뷰: 지난 분기 녹화를 한자리에서 몰아 보면 반복되는 실패 양상이 금방 드러납니다
• 온보딩 활용: 과거 장애 서너 건을 엄선해 두면 시스템이 실제로 어떻게 망가지는지 가장 빠르게 가르칠 수 있습니다

흔한 실수

• 장애 진행 중 녹화: 우선 복구에 집중하세요. 회고는 차분하게 설명할 수 있을 때 녹화합니다
• 편집 없이 공유: 편집하지 않은 40분짜리 화면 공유는 포스트모템이 아닙니다. 아무도 보지 않습니다
• 고객 데이터 유출: 공유 전에 반드시 한 번 시청하며 로그와 대시보드에 개인정보가 없는지 확인하세요
• 영향 요약 생략: 첫 1분만 보고 나가는 시청자도 가장 중요한 사실은 알고 가야 합니다
• 문서 대체: 반년 뒤 비슷한 장애가 시작됐을 때 영상은 검색되지 않습니다

마치며

포스트모템은 이해되기 위해서가 아니라 보관되기 위해 작성될 때 실패합니다. 영향을 앞세우고, 실제 증거를 화면에 담고, 비난 없이 설명하고, 명확한 후속 조치로 마무리하는 짧은 화면 녹화는 장애 하나하나를 팀 전체가 10분 만에 배울 수 있는 자산으로 바꿔 줍니다.

다음 포스트모템은 글로만 남기지 말고 녹화해 보세요. 얼마나 많은 사람이 더 관심을 갖는지 확인할 수 있을 겁니다.