장애 회고 발표 자료 만들기: 시간순 기록·영향·개선안을 정확하게 설명하기

장애 회고 발표에서는 사용자가 어떤 불편을 겪었는지, 서비스를 어떻게 복구했는지, 장애 원인에 관해 무엇이 확인됐는지, 다음으로 어떤 개선이 필요한지를 설명합니다. 장애 대응 채널의 대화를 처음부터 다시 읽는 자리가 아닙니다. 슬라이드 구성이 매끄럽다는 이유로 조사 중인 원인이 확정된 것처럼 보이게 해서도 안 됩니다.

먼저 내용을 검토한 장애 기록을 준비하세요. 발표 자료는 영향을 받은 작업과 사용자, 신규 처리의 복구와 밀린 작업의 완료, 관찰한 사실과 원인에 대한 설명을 구분하는 데 쓰면 좋습니다. 아래 가상 사례를 통해 이 차이를 슬라이드에 어떻게 담을 수 있는지 살펴보겠습니다.

이번 회고에서 결정할 질문부터 정하기

슬라이드를 만들기 전에 회의에서 답해야 할 질문을 적어 보세요. 서비스 운영팀이라면 “릴리스를 재개할 만큼 장애를 이해했는가? 어떤 후속 작업을 먼저 해야 하는가?”가 될 수 있습니다. 고객에게 설명하는 자리라면 영향 범위와 다음 안내 일정이 더 중요할 수 있습니다. 해당 청중에게 공유하도록 승인된 내용을 사용하세요.

Google의 SRE 가이드는 회고 기록에 영향, 완화 조치, 원인, 후속 작업을 담고, 개인을 탓하기보다 당시 판단에 영향을 준 조건을 살피도록 설명합니다. 발표 준비에도 같은 순서가 도움이 됩니다. 기록을 먼저 모으고 그 내용을 설명하세요. 슬라이드가 장애 조사 자체를 대신할 수는 없습니다.

특정 장애가 아니라 일상적인 진행 상황을 보고한다면 주간 업무 보고 구성이 더 적합합니다. 일반 현황 보고를 회고에 모두 섞으면 장애에 관해 아직 풀지 못한 질문이 묻힐 수 있습니다.

가상 사례: 보고서 생성 실패부터 밀린 작업 완료까지

다운로드용 보고서를 생성하는 서비스를 예로 들어 보겠습니다. 설명을 위해 만든 가상 사례이며, 모든 시각은 같은 장애 발생일의 UTC 기준입니다.

보충 기록에는 장애 중 워커가 알 수 없는 상태 값을 오류로 남겼다는 내용이 있습니다. 다만 어느 구성 요소가 그 상태 값을 만들었는지, 릴리스 전 점검에서 왜 발견하지 못했는지는 아직 확인되지 않았습니다. 180건은 중복을 제외한 작업 ID 수입니다. 중복을 제외한 고객 수나 사업상 손실액은 검증되지 않았습니다.

빈칸을 추측으로 채우지 않아도 이 기록만으로 필요한 논의를 할 수 있습니다. 로그의 참조 위치는 남기되, 민감한 페이로드, 접근 토큰, 고객 정보를 발표 화면에 그대로 붙이지 마세요.

신규 처리 복구와 밀린 작업 완료를 구분하기

“27분간 서비스가 중단되어 고객 180명이 영향을 받았다”라고 시작하면 간단해 보입니다. 하지만 두 부분 모두 고쳐야 합니다. 이 사례에서 확인한 것은 보고서 생성 작업의 실패이지 서비스 전체 중단이 아닙니다. 집계 단위도 사람이 아니라 작업입니다. 한 사람이 여러 작업을 요청했을 수 있습니다.

“보고서 생성 작업의 실패가 27분간 관찰됐으며, 영향을 받은 것으로 식별한 180건은 10:00까지 대조하여 완료를 확인했다”가 더 정확합니다. 그 아래에 두 구간을 나눠 표시하세요.

• 09:00–09:27: 기록상 첫 실패부터 새 작업이 정상 완료되기까지의 구간.
• 09:27–10:00: 영향을 받은 작업 전체의 완료를 대조하기까지 남은 33분.

신규 처리가 정상으로 돌아왔더라도 보고서를 기다리는 사람에게는 뒤의 33분도 중요합니다. 그렇다고 모든 작업이 한 시간씩 지연됐다고 말할 수는 없습니다. 지연 시간을 계산하려면 개별 작업의 요청·완료 시각이 필요합니다. 마찬가지로 ‘작업 완료’만으로 모든 보고서 내용이 정확하거나 데이터 손실이 없었다고 단정할 수 없습니다.

슬라이드에는 가로 타임라인을 두고 신규 처리 복구와 밀린 작업 완료를 서로 다른 지점에 표시하세요. 축 옆에는 시간대도 적습니다. 실제 장애에서 첫 실패 시각이 추정치라면 그 불확실성을 드러내세요. 편리하다는 이유로 릴리스 시작 시각을 대신 넣어서는 안 됩니다.

근거를 중심으로 7장 구성하기

이 사례는 다음 7장으로 시작할 수 있습니다. 사실관계가 단순하면 줄이고, 의견이 갈리는 부분을 자세히 확인해야 한다면 보충 자료를 추가하면 됩니다.

1. 무슨 일이 있었고 무엇을 결정해야 하는가. 확인된 영향 범위, 현재 서비스 상태, 아직 정하지 못한 릴리스 결정을 제시합니다.
2. 무엇 또는 누가 영향을 받았는가. 중복 없는 작업 180건, 영향을 받은 업무 흐름, 아직 모르는 고객 수를 표시합니다. 모르는 값을 그럴듯한 추정치로 바꾸지 않습니다.
3. 어떤 순서로 진행됐는가. 기록된 다섯 시각을 보여 주되 알림, 롤백, 복구, 밀린 작업 완료를 구분합니다.
4. 현재 근거로 어디까지 설명할 수 있는가. 알 수 없는 상태 값이 관찰됐다는 사실 옆에 조사할 질문을 놓습니다. 롤백 전후의 순서는 관련 근거지만, 이것만으로 장애의 전체 발생 원리가 입증되는 것은 아닙니다.
5. 대응을 도운 것과 늦춘 것은 무엇인가. 기록으로 뒷받침되는 구체적인 정보, 도구, 협업 문제를 다룹니다. 슬라이드의 균형을 맞추려고 ‘교훈’을 만들어 넣지 않습니다.
6. 어떤 변경을 제안하는가. 예방 조치와 대응 개선을 구분하고 담당자와 완료를 확인할 근거를 제시합니다.
7. 이 자리에서 무엇을 합의할 것인가. 우선순위, 아직 필요한 근거, 릴리스를 재검토할 조건을 확인합니다.

상세 로그, 시험 조건, 작업 대조의 정의는 보충 자료에 둡니다. 다양한 이해관계자가 참석한다면 첫머리에 요약을 넣어 전체 상황을 안내할 수 있습니다. 보고 내용을 추리는 방식은 성과 보고서의 구성 예시에서도 참고할 수 있지만, 장애 요약에서는 ‘처리 복구’와 ‘사용자에게 남아 있는 영향’을 반드시 구분해야 합니다.

조사 중인 원인을 확정된 것처럼 설명하지 않기

“누군가 잘못된 변경을 배포했다”는 설명으로는 다음 엔지니어가 문제를 알아보거나 예방하기 어렵습니다. 이 사례에서 필요한 질문은 작업을 보내는 구성 요소와 워커가 각각 어떤 버전이었는지, 어떤 상태 값을 처리할 수 있었는지, 릴리스 점검이 실제로 무엇을 시험했는지입니다.

슬라이드를 관찰한 사실, 가능한 설명, 더 필요한 근거로 나누세요. 여기서 관찰한 사실은 알 수 없는 상태 값 오류입니다. 호환성 불일치는 해당 버전과 재현 결과가 뒷받침하기 전까지 가설입니다. 다음 조사에서는 버전 조합을 비교하고 적절한 시험 환경에서 실패한 조건을 재현하는 것이 도움이 됩니다.

두 출처의 시각이 다르면 차이를 해소하는 동안 두 기록을 모두 보존하세요. 검토자가 원인 설명에 이의를 제기하면 제목을 확인된 사실의 범위로 좁힙니다. 발표는 조사를 계속하자는 결정을 지원할 수도 있습니다. 회의의 가치를 증명하려고 완결된 원인 이야기를 만들어 낼 필요는 없습니다.

‘더 주의하기’보다 구체적인 개선안 만들기

이 가상 장애에서는 다음 두 조치를 논의할 수 있습니다. 이미 끝낸 수정이나 담당 팀이 수락한 약속이 아니라 검토할 후보입니다.

담당자, 우선순위, 일정은 책임지는 팀과 합의하세요. 먼저 대응한 엔지니어라는 이유만으로 그 사람의 이름을 계획에 넣지 않습니다. “다시는 발생하지 않는다”는 약속도 피하세요. 시험이나 절차 하나만으로 재발 가능성 전체를 없앴다고 입증할 수는 없습니다. 각 조치가 어떤 실패나 지연을 줄이기 위한 것인지 설명하는 편이 정확합니다.

검토한 기록을 Presenti에서 발표 초안으로 만들기

민감한 정보를 제거한 작성 메모에 영향의 정의, 시간순 기록, 출처, 확인된 사실, 열린 질문, 제안 조치를 담으세요. Presenti의 텍스트로 프레젠테이션을 만드는 기능을 사용해 이 메모를 7장 구성으로 정리할 수 있습니다. 09:27과 10:00을 서로 다른 시점으로 남기고, 고객 수는 미확인 상태로 유지하도록 요청하세요.

디자인을 고르기 전에 개요부터 검토하세요. ‘호환성 불일치 가능성’이 ‘근본 원인 확인’으로 바뀌었다면 슬라이드를 더 꾸미기 전에 문장을 바로잡습니다. 편집 가능한 초안에서는 타임라인의 글자가 잘 보이도록 공간을 확보하고, 각 개선안 옆에 완료 확인 근거를 둡니다. Presenti는 설명을 정리하는 데 도움을 주지만 장애 로그를 검증하거나 릴리스가 안전한지 판단하지는 않습니다.

장애 회고 작성 메모와 7장 구성안을 다운로드하거나 아래 작성 지시문을 활용하세요.

제공한 기록으로 장애 회고 발표 초안을 작성하세요. 영향, 감지, 롤백, 신규 작업 복구, 영향받은 작업의 대조를 구분하세요. 관찰한 사실과 가설을 나누고, 미확인 사항·출처·시간대를 보존하세요. 영향받은 고객 수, 금전적 손실, 원인, 담당자의 수락, 조치 완료 여부를 만들어 넣지 마세요.

회의를 마칠 때 실제로 합의한 내용과 아직 필요한 근거를 기록하고 다음 검토에서 이어서 다루세요. 회고 자료가 도와야 할 일은 장애를 더 정확하게 설명하고 다음 변경을 근거에 따라 선택하는 것입니다. 같은 장애가 절대 반복되지 않는다고 선언하는 슬라이드가 아닙니다.