장애 보고서 PPT 작성 예시
가상의 테이블 주문 서비스가 토요일 점심 47분 장애를 사후 검토 회의에 올리는 7장으로 영향 숫자, 타임라인, 5 Whys 원인 분석, 담당·기한을 붙인 재발 방지 대책 쓰는 법을 정리했습니다.

장애 보고서는 서비스가 멈췄던 일을 분 단위로 되짚어 누가 얼마나 피해를 봤는지, 왜 일어났는지, 그날 무엇을 했고 같은 일을 어떻게 막을지를 한 문서로 묶은 것입니다. 사후 검토 회의에 띄울 PPT라면 요약, 영향, 타임라인, 원인 분석, 즉시 조치와 고객 대응, 재발 방지 대책, 결정 요청의 7장이면 됩니다. 사고 보고서나 재발 방지 대책 보고도 뼈대는 같습니다. 쓰다가 멈추는 곳은 원인과 대책 칸입니다. 원인 칸에는 '배포 담당자 확인 소홀'처럼 사람이 들어가고, 대책 칸에는 '모니터링 강화', '배포 시 주의'처럼 누가 언제까지 무엇을 바꾸는지 없는 문장이 들어가기 쉽습니다. 그러면 회의에서 "다음에 같은 쿼리가 또 배포되면 무엇이 막아 주나요?", "그건 언제 끝나요?"라는 질문에 답하지 못하고, 몇 달 뒤 다른 장애 보고서에 같은 대책이 다시 적힙니다.
MOVO에는 장애 당일 대응 채널에서 내보낸 대화 기록(TXT), 모니터링 화면에서 받은 1분 단위 오류율(CSV), 영향을 받은 매장 목록 엑셀을 손대지 않고 첨부하고, 장애 뒤 원인과 대책을 정리한 사후 분석 메모(워드)를 함께 붙입니다. 요청에는 "원인은 사람 이름 대신 절차와 구조에서 멈춰", "대책마다 담당 한 명과 기한을 붙여"처럼 이 보고서에서 지킬 규칙을 적습니다. '빠른 생성'으로 보내면 슬라이드가 그려지기 전에 7장의 제목·상세 내용·비주얼 설명이 카드로 먼저 나오니, 타임라인 카드의 시각이 채널 기록과 같은지, 대책 카드에 기한이 빠지지 않았는지 그 자리에서 고칩니다. 이 글은 가상의 음식점 테이블 주문 서비스가 토요일 점심에 겪은 47분 장애를 사후 검토 회의에 올리는 7장을 따라가며 장 순서, 영향 숫자, 타임라인, 5 Whys 원인 분석, 즉시 조치와 재발 방지 대책을 정리하고, MOVO로 만드는 과정과 고쳐 쓸 템플릿을 보여 드립니다.

장애 보고서 PPT는 어떤 순서로 만드나요?
검토 회의에서 질문이 나오는 순서대로 놓습니다. 무슨 일이었나 → 누가 얼마나 영향을 받았나 → 언제 알았고 언제 고쳤나 → 왜 일어났나 → 그날 무엇을 했나 → 같은 일을 어떻게 막나 → 무엇을 정해 주면 되나 순서입니다. 아래는 손님이 매장 태블릿으로 직접 주문·결제하는 테이블 주문 서비스를 운영하는 직원 64명 회사가 2026년 10월 21일(수) 오전 장애 검토 회의에 올린 보고서입니다. 장애는 나흘 전인 10월 17일(토) 점심에 났고, 대표·CTO·CS팀장·영업팀장이 듣고 그날 대응을 지휘한 백엔드 리드가 발표합니다. 회사와 숫자, 장애는 모두 지어낸 예시입니다.
| 장 | 회의에서 나올 질문 | 테이블 주문 예시의 슬라이드 제목 |
|---|---|---|
| 1. 요약 | 무슨 일이었나 | 10월 17일 점심 테이블 주문이 47분 멈췄습니다 |
| 2. 영향 | 누가 얼마나 영향을 받았나 | 매장 1,240곳에서 주문 요청 13,120건이 실패했습니다 |
| 3. 타임라인 | 언제 알았고 언제 고쳤나 | 감지 14분, 판단 19분, 복구 14분이 걸렸습니다 |
| 4. 원인 분석 | 왜 일어났나 | 주문과 점주 조회가 DB 연결 100개를 나눠 썼습니다 |
| 5. 즉시 조치·고객 대응 | 그날 무엇을 했나 | 되돌린 뒤 인덱스를 더해 10월 20일 다시 배포했습니다 |
| 6. 재발 방지 대책 | 같은 일을 어떻게 막나 | 재발 방지 대책 6건을 11월 20일까지 끝냅니다 |
| 7. 결정 요청·이행 점검 | 회의에서 무엇을 정하면 되나 | 복제 DB 월 48만 원과 보상 409만 원을 승인해 주세요 |

그림의 템플릿은 이슈 기록을 검토하는 보고서라 장애 보고서 전용은 아니지만, 장애 보고서에 필요한 칸 모양이 이미 들어 있습니다. 03 '세 가지 빈칸'의 큰 숫자 세 칸은 2장 영향으로, 05 '대조할 원본'의 네 줄은 5장 즉시 조치로, 04 '원본부터 다음 담당까지'의 여섯 칸은 6장 재발 방지 대책 목록으로, 08 '다음 대조'는 7장 이행 점검으로 씁니다. 표지는 1장 요약으로 바꾸고, 시간축이 필요한 3장과 '왜'를 이어 적는 4장은 새로 더합니다.
- 1장 제목에 무엇이 얼마나 멈췄는지 씁니다. '10월 17일 장애 보고'라는 제목으로는 대표가 표지만 보고 아무것도 알 수 없습니다. 예시는 1장 아래에 장애 시간·영향 매장·실패한 주문 요청 숫자 세 개를 두고, 원인 한 줄과 대책을 끝낼 날짜를 붙였습니다.
- 기술 상세는 부록으로 뺍니다. 쿼리 실행 계획이나 DB 연결 수 그래프는 CTO가 물을 때만 엽니다. 대표와 영업팀장이 같은 자리에 있으니 본문은 매장과 주문 숫자로 말합니다.
- 정해진 양식이 있으면 그 파일 위에서 씁니다. 정보보호팀이 돌리는 장애 보고 양식이 PowerPoint 파일이라면, 대시보드 입력창 위 'PPTX 불러오기'를 눌러 그 양식을 편집할 수 있는 새 프로젝트로 엽니다. 숨긴 장까지 세어 50장, 용량 20MB를 넘지 않아야 하고, 양식에 쓴 글꼴 가운데 에디터에 없는 것은 Pretendard로 대신 보일 수 있습니다.
영향은 어떤 숫자로 적나요?
영향 장에는 얼마 동안, 몇 곳에서, 몇 건이 실패했는지를 숫자로 적고 숫자마다 어디서 셌는지 붙입니다. 같은 장애라도 '주문 요청'과 '완료된 주문'과 '손님'은 서로 다른 숫자라서, 무엇을 셌는지 적어 두지 않으면 회의 시간이 숫자 맞추기로 흘러갑니다.

예시 회사의 2장에 들어간 숫자입니다.
| 숫자 | 값 | 센 곳 |
|---|---|---|
| 장애 시간 | 47분(11시 48분~12시 35분) | 주문 API 오류율 1분 단위 기록 |
| 영향 매장 | 1,240곳(이용 매장 2,860곳 중) | 장애 시간에 주문 요청이 한 건이라도 들어온 매장 |
| 실패한 주문 요청 | 13,120건(같은 손님의 재시도 포함) | 주문 API 로그 |
| 완료된 주문 | 8,350건(한 주 전 같은 시간 21,400건의 39%) | 주문 DB |
| 고객센터 문의 | 412건(평소 토요일 하루 60건 안팎) | 상담 시스템 '주문 오류' 태그 |
| 개인정보 | 유출 없음 | DB 연결이 모자라 생긴 장애로, 외부 접근 기록 없음 |
- 실패 요청 수를 잃은 주문 수로 쓰지 않습니다. 13,120건에는 손님이 같은 주문을 두세 번 누른 재시도가 섞여 있습니다. 잃은 주문을 묻는다면 한 주 전과 비교한 감소분 13,050건(21,400 − 8,350)을 '많아야'라는 말과 함께 씁니다. 그 시간에 직원이 POS로 직접 받은 주문은 테이블 주문 DB에 남지 않아서, 실제로 놓친 주문은 이보다 적습니다.
- 비교 기준은 같은 요일 같은 시간으로 잡습니다. 토요일 점심 47분을 평일 평균과 견주면 피해가 실제보다 작아 보입니다. 예시는 10월 10일(토) 11시 48분~12시 35분 값을 기준으로 썼습니다.
- 개인정보가 새어 나갔는지 한 줄로 적습니다. 예시 장애는 DB 연결이 모자라 생긴 것이라 외부 접근이 없었고, 2장 맨 아래에 '개인정보 유출 없음'이라고 적었습니다. 유출이 있었다면 보고 일정부터 달라집니다. 개인정보 보호법 시행령 제39조는 유출 등을 알게 된 때부터 72시간 이내에 정보주체에게 알리도록 하고, 제40조는 1천 명 이상의 정보가 유출됐거나, 민감정보·고유식별정보가 유출됐거나, 외부의 불법적인 접근으로 유출된 경우 72시간 이내에 개인정보 보호위원회나 한국인터넷진흥원에 신고하도록 정합니다.
타임라인은 어떻게 적나요?
타임라인에는 분 단위 시각, 그때 일어난 일, 그 시각을 확인한 기록을 한 줄씩 적습니다. 그리고 첫 오류부터 정상화까지를 감지·판단·복구 세 구간으로 나눠 구간마다 몇 분 걸렸는지 붙입니다. 어느 구간에서 시간이 샜는지 보여야 대책이 그 구간을 겨눕니다.

예시 회사의 3장 타임라인입니다.
| 시각 | 일어난 일 | 확인한 기록 |
|---|---|---|
| 10월 16일(금) 18:40 | 점주 앱에 '시간대별 매출 요약' 기능 배포 | 배포 기록 |
| 10월 17일(토) 11:30 | 점심 영업 전에 점주들이 매출 요약 화면을 열기 시작 | 조회 API 로그 |
| 11:48 | 첫 주문 오류(DB 연결을 5초 안에 얻지 못함) | 주문 API 로그 |
| 11:55 | 고객센터 첫 문의 | 상담 시스템 |
| 12:02 | 경보 울림(오류율 5% 이상이 10분 이어짐), 당직 개발자 확인 | 경보 기록 |
| 12:09 | 장애 선언, 백엔드 리드가 대응 지휘 | 대응 채널 |
| 12:14 | 점주 앱 배너와 문자로 'POS로 주문 받기' 안내 | 문자 발송 기록 |
| 12:21 | 전날 배포를 원인 후보로 보고 되돌리기 결정 | 대응 채널 |
| 12:29 | 되돌리기 완료 | 배포 기록 |
| 12:35 | 주문 오류율 0.3%로 평소 수준 회복, 장애 종료 | 오류율 기록 |
- 세 구간에 분을 붙입니다. 감지(첫 오류 → 경보) 14분, 판단(경보 → 되돌리기 결정) 19분, 복구(결정 → 정상화) 14분, 합계 47분입니다. 가장 긴 판단 19분은 전날 배포를 의심하기 전에 DB 서버 이상부터 살피느라 쓴 시간이었고, 이 구간을 줄이는 대책이 6장에 따로 들어갔습니다.
- 시각은 기록에서만 옮깁니다. 기억으로 적은 시각은 사람마다 몇 분씩 어긋납니다. 예시는 대응 채널 메시지 시각, 배포 기록, 경보 기록에 남은 시각만 썼습니다.
- 첫 오류보다 앞선 시각도 넣습니다. 11시 48분부터 적으면 전날 저녁 배포와 11시 30분의 조회 증가가 빠져, 왜 하필 토요일 점심이었는지 설명할 수 없습니다.
원인은 5 Whys로 어떻게 좁히나요?
눈에 보인 현상에서 시작해 '왜?'를 다섯 번쯤 물으며 한 단계씩 내려가고, 사람의 실수가 아니라 그 실수를 막지 못한 절차나 구조에서 멈춥니다. 대책은 절차나 구조가 드러난 단계마다 하나씩 겁니다.

예시 회사의 4장에 들어간 다섯 단계입니다.
| 단계 | 질문 | 답 | 확인한 기록 |
|---|---|---|---|
| 왜 1 | 왜 주문이 실패했나 | 주문 API가 DB 연결을 얻지 못하고 5초 뒤 시간 초과로 끝났다 | 주문 API 로그 |
| 왜 2 | 왜 DB 연결을 못 얻었나 | 주문과 점주 조회가 같은 연결 100개를 나눠 쓰는데, 매출 요약 조회가 100개를 모두 잡고 있었다 | DB 연결 현황 |
| 왜 3 | 왜 조회가 연결을 오래 잡았나 | 전날 배포한 쿼리가 인덱스 없이 주문 4,100만 행을 읽어 한 번에 평균 8초 걸렸고, 점주 1,900명이 점심 전에 화면을 열었다 | 쿼리 실행 계획, 조회 API 로그 |
| 왜 4 | 왜 배포 전에 몰랐나 | 스테이징 DB에는 운영의 50분의 1인 82만 행만 있어 같은 쿼리가 0.2초 만에 끝났다 | 스테이징 시험 기록 |
| 왜 5 | 왜 그 차이를 확인하지 않았나 | 배포 체크리스트에 '새 쿼리의 실행 계획을 운영 규모 데이터에서 확인'하는 항목이 없었다 | 배포 체크리스트 v1 |
- 사람 이름에서 멈추지 않습니다. 왜 4를 '개발자가 실행 계획을 보지 않았다'로 끝내면 대책은 '앞으로 주의하겠다'가 됩니다. 예시는 한 번 더 물어 체크리스트에 그 항목이 없었다는 데까지 내려갔고, 대책은 체크리스트 개정이 되었습니다. 발표에서도 배포한 사람의 이름은 말하지 않습니다.
- 갈래가 둘이면 둘 다 적습니다. 연결이 바닥난 데는 쿼리가 느렸던 것(왜 3~5)과 주문과 조회가 같은 연결을 나눠 쓴 구조(왜 2)가 함께 있습니다. 쿼리만 고치면 다음에 다른 느린 조회가 들어왔을 때 주문이 또 멈춥니다.
- 답마다 확인한 기록을 붙입니다. 기록을 대지 못하는 답은 추측입니다. 그런 칸에는 '확인 중'과 확인할 날짜를 적고, 회의 전에 채우지 못했으면 그대로 발표합니다.
즉시 조치와 재발 방지 대책은 어떻게 나눠 적나요?
그날 서비스를 되살리고 매장에 알린 일은 5장 즉시 조치에, 같은 원인이 다시 장애를 만들지 못하게 바꾸는 일은 6장 재발 방지 대책에 적습니다. 대책 한 줄에는 막는 원인, 담당 한 명, 기한, 끝났는지 확인할 기록을 붙입니다.
예시 회사의 5장 즉시 조치입니다.
| 언제 | 조치 | 담당 |
|---|---|---|
| 10월 17일 12:14 | 점주 앱 배너와 문자로 'POS로 주문 받기' 안내 | CS팀장 |
| 12:21~12:29 | 10월 16일 배포 되돌리기 | 백엔드 리드 |
| 10월 17일 16:00 | 영향 매장 1,240곳에 사과 문자 발송, 11월 이용료 3일분 감면(매장당 3,300원, 합계 409만 2,000원)은 21일 회의 승인 뒤 안내 | CS팀장 |
| 10월 20일(화) | 인덱스를 더한 매출 요약 재배포(운영 데이터 사본에서 잰 조회 시간 평균 8초 → 0.3초) | 백엔드 개발자 |

예시 회사의 6장 재발 방지 대책입니다.
| 대책 | 막는 원인 | 담당 | 기한 | 끝났는지 확인할 기록 |
|---|---|---|---|---|
| 금요일 15시 이후와 주말 배포 금지(긴급 수정은 CTO 승인) | 점심 피크 전날 저녁 배포 | CTO | 10월 19일(월)부터 | 배포 기록에 해당 시간 배포 0건 |
| 주문 오류율 경보를 '5%가 10분'에서 '2%가 2분'으로 | 감지 14분 | 인프라 담당 | 10월 22일(목) | 시험 경보가 2분 안에 울린 기록 |
| 대응 절차에 '배포 뒤 24시간 안의 장애는 직전 배포 되돌리기부터 검토' 추가 | 판단 19분 | 백엔드 리드 | 10월 23일(금) | 대응 절차 개정본 |
| 배포 체크리스트에 '새 쿼리 실행 계획을 운영 규모 데이터에서 확인' 추가 | 왜 5 | 백엔드 리드 | 10월 23일(금) | 다음 배포 1건의 확인 기록 |
| 스테이징 DB를 개인정보를 지운 운영 사본으로 매주 월요일 갱신 | 왜 4 | 인프라 담당 | 11월 6일(금) | 스테이징 주문 테이블 행 수 |
| 점주 조회를 읽기 전용 복제 DB로 분리 | 왜 2 | 인프라 담당 | 11월 20일(금) | 조회 부하 시험 중 주문 오류율 |
- '모니터링 강화'라고 쓰지 않습니다. 무엇을 몇으로 바꾸는지 적어야 끝났는지 가릴 수 있습니다. 예시의 경보 대책은 기준을 숫자로 적었기 때문에, 10월 22일에 시험 경보를 한 번 울려 보는 것으로 완료 여부가 갈립니다.
- 대책마다 원인 하나를 겨눕니다. 막는 원인 칸이 빈 대책은 이번 장애와 상관없던 숙원 과제일 때가 많습니다. 예시는 5 Whys의 왜 2·4·5, 타임라인의 감지·판단 구간, 피크 전 배포에 대책을 하나씩 걸었습니다.
- 돈이 드는 대책은 7장 결정 요청으로 올립니다. 복제 DB는 월 48만 원(연 576만 원)이 들어 인프라 담당 혼자 정할 수 없습니다. 매장 보상 409만 2,000원도 17일에는 사과 문자만 먼저 보내고, 금액은 복제 DB와 함께 7장에서 대표 승인을 받은 뒤 매장에 알립니다.
- 이행 점검 날짜를 적습니다. 마지막 기한인 11월 20일(금) 다음 주 금요일, 11월 27일에 대책 6건이 끝났는지 기록으로 확인하는 자리를 7장에 넣었습니다. 이 날짜가 없으면 대책 표는 회의가 끝나는 순간 잊힙니다.
MOVO로 장애 보고서를 만들면 무엇이 다른가요?
- 대응 기록을 그대로 첨부: 대응 채널에서 내보낸 TXT, 모니터링의 오류율 CSV, 영향 매장 엑셀(.xlsx), 사후 분석 메모 워드(.docx)를 한 요청에 붙입니다. TXT·CSV와 워드·엑셀에서 읽어 낸 글자는 첨부 전체를 합쳐 500KB까지라, 채널 기록은 배포 시각부터 매장 사과 문자까지(10월 16일 18시~17일 17시)만 잘라 붙입니다. 2026년 11월 1일 기준으로 무료 요금제는 파일 3개(파일당 5MB)까지, Pro·Max 요금제는 10개(파일당 20MB, 합계 50MB)까지 받으니, 예시처럼 네 파일을 한 번에 붙이려면 Pro·Max가 필요합니다.
- 시각과 기한을 카드에서 먼저 맞추기: 슬라이드보다 장별 제목·상세 내용·비주얼 설명 카드가 먼저 나와서, 3장 카드의 시각이 채널 기록과 같은지, 6장 카드의 대책마다 기한이 붙었는지 이 단계에서 고칩니다. 4장 비주얼 설명에 '왜 다섯 칸을 화살표로 잇는다'처럼 모양을 적어 두면 AI가 그 장 배치를 잡을 때 참고합니다.
- 틀린 숫자는 그 장만 고치기: 2장을 고르고 AI 창에 숫자를 읽어 달라고 하면 입력칸에 '슬라이드 2 선택됨'이 붙고 그 장이 요청과 함께 넘어갑니다. 덱을 만들 때 붙인 파일은 AI 창이 다시 읽지 않으니 바꿀 숫자는 요청 문장에 그대로 씁니다. 열 줄짜리 타임라인 표처럼 글이 많은 장은 캔버스 아래 '레이아웃 검사'로 겹치거나 잘린 글을 찾습니다.
- 7장 생성과 파일 형식: 무료 요금제에서 AI가 생성 한 번에 그리는 장 수는 5장이라, 7장을 한 번에 받으려면 Pro·Max 요금제가 필요합니다. 그 전에 틀만 잡으려면 아래 1번 템플릿을 내 프로젝트로 복사해 숫자를 바꿉니다. 복사는 요금제와 상관없습니다. CTO가 부록을 덧붙일 원본은 PowerPoint(PPTX)로 Pro·Max에서 받고, 매장에 보낼 안내는 PDF로 받습니다. PDF·PNG는 모든 요금제에서 받지만 무료 요금제 파일에는 MOVO 워터마크가 들어갑니다.
MOVO로 장애 보고서 PPT를 만드는 과정
1. 대응 기록과 사후 분석 메모를 붙이고 보고서 규칙을 적습니다
대시보드 입력창에 네 파일을 첨부하고, 입력창 왼쪽 위 '빠른 생성'이 선택된 채 '슬라이드 수'를 7장으로 둡니다. 구성 카드에서 시각과 기한을 먼저 봐야 하니 '대화로 만들기'가 아니라 '빠른 생성'으로 보냅니다. 사후 분석 메모에는 5 Whys마다 확인한 기록, 10월 20일 재배포 결과, 대책 6건의 담당과 기한, 매장 보상안(3일분 감면 409만 2,000원), 주문 DB와 상담 시스템에서 센 숫자(이용 매장 2,860곳, 그날 완료 주문 8,350건과 한 주 전 21,400건, 고객센터 문의 412건)를 적어 두었습니다. 요청에는 회의 날짜와 함께 원인과 대책을 적는 규칙을 쓰고, 복제 DB 비용처럼 파일에 없는 숫자는 직접 적습니다.

검토 회의용이라면 이렇게 적습니다.
첨부한 장애 대응 채널 기록, 주문 API 1분 단위 오류율, 영향 매장 목록, 사후 분석 메모만 사용해 10월 21일 장애 검토 회의에 올릴 10월 17일 테이블 주문 장애 보고서를 7장으로 만들어줘. 순서는 요약, 영향, 타임라인, 원인 분석, 즉시 조치와 고객 대응, 재발 방지 대책, 결정 요청과 이행 점검. 영향 숫자에는 센 곳을 붙이고 실패한 주문 요청과 완료된 주문을 나눠 적어줘. 타임라인은 채널 기록에 남은 시각만 쓰고 감지·판단·복구 구간마다 걸린 분을 붙여줘. 원인은 '왜'를 다섯 단계로 적되 사람 이름이 아니라 절차와 구조에서 멈추고, 재발 방지 대책은 대책·막는 원인·담당·기한·완료 확인 5열 표로 넣어줘. 복제 DB 비용은 월 48만 원이야. 장 제목은 결론 한 문장으로 쓰고, 파일과 이 요청에 없는 숫자는 만들지 마.
서비스 이름, 장애 날짜, 지표 이름만 바꾸면 결제 지연이나 로그인 장애의 보고서에도 같은 틀로 씁니다.
2. 구성 단계에서 대책 카드의 기한을 확인합니다
MOVO가 제안한 7장의 카드를 채널 기록과 나란히 놓고 봅니다. 3장 카드의 시각이 기록과 한 분이라도 다르면 기록 쪽으로 고치고, 6장 카드에서 '모니터링 개선'처럼 숫자 없는 대책이 보이면 바꿀 기준과 기한을 적어 넣습니다. 비주얼 설명 칸에 '5열 표'처럼 장의 모양이 적혔는지도 이때 봅니다.

3. 대표와 CTO가 함께 보는 회의에 맞춰 설정합니다
이 보고서는 비용 승인까지 받아야 하니 청중은 '경영진', 문체 톤은 '정중'을 고릅니다. 타임라인 표가 열 줄, 대책 표가 여섯 줄이라 디자인 밀도는 요소 사이 간격을 좁히는 '촘촘'으로 둡니다. 개발팀끼리 보는 기술 회고판을 따로 만든다면 청중을 '기술/전문가'로 바꿔 한 번 더 만듭니다.

4. 이슈 보고서 스타일을 고릅니다
'문서 종류'를 '보고 /분석형'으로 좁히고 목록 아래 '더 불러오기'를 한 번 누르면 '레드 레일 이슈 보고서'가 나옵니다. 흰 종이 면에 긴 빨간 선과 큰 제목을 두고 범위·지표·후속 조치를 나눠 보여 주는 스타일이라, 숫자 세 칸과 대책 목록이 들어가는 장애 보고서에 맞습니다. 'Pro' 표시가 없어 무료 요금제에서도 고를 수 있고, 고른 뒤 '프레젠테이션 생성하기'를 누릅니다.

5. 영향 숫자와 타임라인 시각을 기록과 맞춥니다
덱이 만들어지면 2장 영향부터 엽니다. 그 장을 고른 채 왼쪽 AI 창에 세 칸의 숫자를 읽어 달라고 하고, 주문 API 로그와 주문 DB 집계를 옆에 띄워 13,120건과 8,350 ÷ 21,400 = 39%를 한 줄씩 맞춥니다. 템플릿에서 출발했다면 '세 가지 빈칸' 장을 골라 세 칸의 이름과 숫자를 장애 숫자로 바꿔 달라고 적습니다. 3장 타임라인도 같은 방법으로 시각을 맞추고, 숫자를 바꾼 장은 '레이아웃 검사'로 겹치거나 잘린 글이 없는지 봅니다.

6. 회의용 PPTX와 매장 안내용 PDF로 내보냅니다
회의 뒤 CTO는 쿼리 실행 계획과 DB 연결 수 그래프를 부록으로 붙이고, 승인된 금액을 7장에 고쳐 적습니다. 그래서 원본은 PowerPoint(PPTX, Pro·Max 요금제)로 내보냅니다. 매장에 보낼 안내는 슬라이드 목록에서 1·2·5장을 '슬라이드 복제'로 하나씩 복사하고, 복사한 장을 자주 묻는 질문의 매장용 안내처럼 고친 뒤 '범위'의 '페이지 선택'에서 그 세 장만 골라 PDF로 받습니다. PPTX에는 글꼴이 들어가지 않으니, 내보내기 창 '사용된 글꼴'에 나온 Pretendard를 CTO 컴퓨터에도 설치하게 알려 줍니다.

장애 보고서에 고쳐 쓸 템플릿 3가지
세 템플릿 모두 장애 보고서 전용은 아니지만, 1번에는 큰 숫자 세 칸과 여섯 칸 목록이, 2번에는 네 점을 가로선 위아래로 잇는 장이, 3번에는 다섯 줄짜리 4열 표 장이 있어 영향·타임라인·대책 장으로 옮겨 쓰기 좋습니다. 템플릿 속 팀 이름과 숫자는 지어낸 예시이니 우리 장애 기록으로 바꿔 넣습니다.
1. 이슈 기록의 빈칸과 다음 담당 대조 (8장)
가상 이슈 기록 30건을 검토하는 보고서로, 네 줄로 범위를 밝히는 장, '30건 중 12건'처럼 분모를 붙인 큰 숫자 세 칸, 아이콘이 붙은 여섯 칸 목록, 상태를 바꾸기 전에 지킬 규칙을 모은 장이 들어 있습니다. 위 예시에서 영향 숫자와 즉시 조치, 재발 방지 대책 목록을 담는 틀로 썼습니다.

2. 구매 요청의 원본 기록과 후속 검토 (8장)
구매 요청을 검토하는 보고서로, 여섯 단계를 한 줄로 잇는 흐름 장과 '확인 01~04'를 가로선 위아래에 번갈아 놓는 장이 두 번 나옵니다. 가로선 장 하나는 타임라인으로, 다른 하나는 대책을 기한 순서로 늘어놓는 장으로 바꿔 씁니다. 템플릿 아래에 가로 간격은 기간을 나타내지 않는다는 안내가 있으니, 장애 시각처럼 간격이 고르지 않은 값은 점마다 시각을 적어 둡니다.

3. 사내 문서 승인 기록과 다음 검토 (8장)
문서 승인 기록을 검토하는 흑백 보고서로, 번호·검토 항목·근거 상태·다음 확인 4열 표가 두 장, 접수·대조·검토·갱신 네 단계 화살표 장, 현재 기록과 다음 검토를 둘로 나눈 장이 있습니다. 표 장 하나는 재발 방지 대책 표로, 다른 하나는 11월 27일 이행 점검 때 대책별 완료 여부를 적는 표로 씁니다.

자주 묻는 질문
사고 보고서와 장애 보고서는 무엇이 다른가요?
이 글에서는 서비스나 시스템이 멈춘 일을 장애 보고서로, 제품 불량이나 설비 고장처럼 현장에서 생긴 일을 사고 보고서로 나눴습니다. 요약, 영향, 경위, 원인, 조치, 재발 방지로 이어지는 순서는 같고 영향 장의 숫자가 다릅니다. 제조 불량이라면 '실패한 주문 요청' 대신 해당 생산 묶음(로트) 번호, 출하 수량, 회수 수량을 적습니다. 사람이 다친 일이라면 회사 안전관리자가 따르는 신고 절차부터 확인합니다.
원인을 아직 모를 때 첫 보고는 어떻게 하나요?
장애 중이나 직후에는 원인 칸 없이 언제부터, 무엇이, 얼마나, 지금 상태, 다음 보고 시각 다섯 가지만 메시지로 먼저 보냅니다. 예시 팀은 10월 17일 12시 15분에 대표에게 "11시 48분부터 테이블 주문 실패, 매장 약 1,200곳, 매장에 POS 주문 안내 보냄, 원인은 확인 중, 12시 45분에 다시 보고"라고 보냈습니다. 추측한 원인을 적으면 나중에 고칠 일이 생기니 '확인 중'으로 둡니다. 7장 보고서는 로그를 다시 읽은 뒤에 만듭니다.
매장이나 고객사에 보내는 장애 안내에는 무엇을 빼나요?
내부용 7장에서 1·2·5장만 남기고, 4장 원인 분석은 '전날 추가한 기능의 조회가 주문 처리에 쓸 자원까지 써 버렸다'처럼 한 문장으로 줄입니다. 담당자 이름, DB 연결 수, 비용 승인 요청은 뺍니다. 대신 매장이 알아야 할 것 두 가지, 보상은 11월 이용료에서 저절로 빠진다는 것과 주말에는 배포하지 않기로 했다는 것을 한 줄씩 넣습니다.
5 Whys 말고 다른 원인 분석 방법도 쓰나요?
원인이 한 줄로 이어지지 않고 여러 갈래로 얽혀 있다면 사람·절차·도구·환경처럼 칸을 나눠 원인 후보를 늘어놓는 특성요인도(피시본 그림)를 씁니다. 예시처럼 갈래가 두 개(느린 쿼리, 연결을 나눠 쓴 구조)라면 5 Whys를 두 줄로 나눠 적어도 충분합니다. 어느 방법이든 칸마다 확인한 기록을 붙입니다.
짧게 끝난 장애도 7장을 다 만들어야 하나요?
몇 분 만에 끝나고 영향 범위가 좁은 장애라면 요약·영향·원인·대책을 한 줄씩 담은 한 장 보고로 충분합니다. 어디부터 7장을 쓸지 기준을 미리 정해 두면 됩니다. 예시 회사는 '영향 매장 100곳 이상이거나 30분 이상 이어진 장애'면 7장 보고서를 쓰기로 대응 절차에 적어 두었습니다.
정리
장애 보고서 PPT는 요약, 영향, 타임라인, 원인 분석, 즉시 조치, 재발 방지 대책, 결정 요청의 7장이면 됩니다. 영향 숫자에는 센 곳을 붙여 실패 요청과 잃은 주문을 나누고, 타임라인은 기록에 남은 시각으로 적어 감지·판단·복구 구간에 분을 붙입니다. 원인은 '왜'를 이어 묻되 사람이 아니라 절차와 구조에서 멈추고, 대책 한 줄마다 막는 원인·담당·기한·완료 확인 기록과 이행 점검 날짜를 붙입니다. 대응 채널 기록과 오류율 파일이 있다면 MOVO에 첨부해 타임라인 카드부터 맞춰 보세요.


