장애 보고서 작성법: 1보·중간·최종 보고에 무엇을 써야 할까

시스템이 멈추면 담당자는 두 가지 일을 동시에 해야 합니다. 문제를 해결하는 일과, 지금 무슨 일이 일어나고 있는지 알리는 일입니다.

전산 업무를 오래 하다 보면 두 번째 일이 생각보다 어렵다는 걸 알게 됩니다. 원인도 아직 모르는데 "언제 되냐"는 질문이 쏟아지고, 복구가 끝나면 이번에는 보고서를 써 달라는 요청이 옵니다. 이때 무엇을 써야 할지 정해져 있지 않으면 보고서가 기술 용어로 가득한 작업 일지가 되거나, 반대로 "조치 완료했습니다" 한 줄로 끝나 버립니다.

장애 보고는 한 번에 끝나는 문서가 아니라 시점에 따라 세 번 나눠서 쓰는 편이 현실적입니다.

장애 보고는 1보, 중간 보고, 최종 보고로 나눈다

구분	언제	목적	분량
1보	장애를 인지한 직후	상황 공유, 업무 대응 판단	3~5줄
중간 보고	원인 파악 중·복구 진행 중	진행 상황과 예상 시간 공유	5~10줄
최종 보고	복구 완료 후	원인, 조치, 재발 방지 기록	1~2장

회사마다 이름은 다를 수 있습니다. 긴급 보고, 경과 보고, 결과 보고라고 부르는 곳도 있습니다. 중요한 건 이름보다 시점마다 읽는 사람이 궁금한 것이 다르다는 점입니다.

1보: 원인보다 영향부터 쓴다

1보를 받는 사람은 대부분 기술 담당자가 아닙니다. 팀장, 관련 부서, 경우에 따라 경영진입니다. 이 사람들이 먼저 알고 싶은 건 원인이 아니라 "업무에 어떤 영향이 있는가"입니다.

1보에는 이 다섯 가지면 충분합니다.

• 언제부터: 발생 또는 인지 시각
• 무엇이: 어떤 시스템이나 기능이 안 되는지
• 누구에게: 영향을 받는 사용자나 부서, 대략적인 범위
• 지금 하는 일: 원인 확인 중, 우회 방법 안내 등
• 다음 보고: 언제 다시 알릴지

예를 들면 이런 식입니다.

[1보] 09:40부터 사내 결재 시스템 접속 불가
- 영향: 전 직원 결재 상신·승인 불가 (조회도 안 됨)
- 조치: 서버 상태 확인 중, 원인 미확인
- 긴급 결재는 담당 부서에 유선 요청 바랍니다
- 10:10에 경과를 다시 공유하겠습니다

원인을 모르는 상태에서 추측을 적지 않는 것이 중요합니다. "네트워크 문제로 보입니다"라고 썼다가 나중에 원인이 달라지면, 보고 자체를 신뢰하기 어려워집니다. 모르면 "원인 확인 중"이라고 쓰면 됩니다.

중간 보고: 예상 시간은 약속이 아니라 판단 근거로 쓴다

중간 보고에서 가장 곤란한 질문은 "언제 복구되나요?"입니다.

정확한 시간을 모르는데 "30분 내 복구 예정"이라고 쓰면, 30분이 지나는 순간 다시 보고해야 하고 신뢰도 떨어집니다. 그렇다고 "미정"으로만 쓰면 받는 쪽에서 업무 계획을 세울 수 없습니다.

그래서 예상 시간은 근거와 함께 쓰는 편이 좋습니다.

[중간 보고] 10:10 기준
- 원인: DB 서버 디스크 용량 부족으로 확인
- 조치: 불필요한 로그 파일 정리 중
- 예상: 정리 후 서비스 재기동까지 약 30분, 재기동이 실패하면 추가 시간 필요
- 다음 보고: 10:40 또는 복구 즉시

이렇게 쓰면 받는 사람이 "30분은 기다리고, 안 되면 다른 방법을 준비하자"는 판단을 할 수 있습니다. 중간 보고의 역할은 결국 상대방이 자기 업무를 결정할 수 있게 해 주는 것입니다.

최종 보고서: 원인은 두 단계로 나눠서 쓴다

복구가 끝나면 최종 보고서를 씁니다. 이 문서는 당장 읽는 사람뿐 아니라, 몇 달 뒤 같은 문제가 생겼을 때 다시 찾아볼 기록이기도 합니다.

최종 보고서의 기본 항목은 다음과 같습니다.

항목	쓸 내용
개요	발생·복구 일시, 장애 시간, 영향 범위
경과	시간순으로 인지, 조치, 복구 과정
원인	직접 원인과 근본 원인
조치 내용	임시 조치와 영구 조치 구분
재발 방지 대책	담당자와 완료 예정일 포함

여기서 가장 많이 부족해지는 부분이 원인입니다.

"디스크 용량 부족"은 직접 원인입니다. 그런데 왜 용량이 부족해졌는지, 왜 미리 알아채지 못했는지가 빠지면 같은 장애가 또 납니다. 로그를 지우는 설정이 없었고, 용량 경고 알림이 없었다면 그게 근본 원인입니다.

직접 원인만 쓴 보고서는 "로그 정리함"으로 끝나고, 근본 원인까지 쓴 보고서는 "로그 보관 기간 설정, 용량 80% 경고 알림 추가"라는 대책으로 이어집니다.

재발 방지 대책은 담당자와 날짜가 있어야 한다

재발 방지 대책에서 흔히 보이는 문장이 있습니다.

• 모니터링을 강화하겠습니다
• 점검을 철저히 하겠습니다
• 유사 사례가 없도록 주의하겠습니다

읽을 때는 그럴듯하지만, 몇 달 뒤 확인해 보면 무엇이 바뀌었는지 알 수 없는 문장입니다.

대책은 누가, 무엇을, 언제까지 하는지가 보이도록 쓰는 편이 좋습니다.

대책	담당	완료 예정
로그 보관 기간 30일 자동 삭제 설정	시스템 담당	9월 20일
디스크 사용률 80% 초과 시 알림 추가	운영 담당	9월 25일
월 1회 용량 점검 항목에 추가	운영 담당	10월 점검부터

이렇게 표로 남겨 두면 다음 보고 때 완료 여부를 확인할 수 있고, 주간 업무보고에도 그대로 옮겨 쓸 수 있습니다. 주간 보고를 쓰는 순서는 주간 업무보고 작성 순서 글에 따로 정리해 두었습니다.

보고서를 쓸 때 주의할 점

책임 추궁 문서로 만들지 않는다. "담당자 부주의로"라는 표현은 원인을 설명하지 못합니다. 사람이 실수할 수 있는 구조가 무엇이었는지를 쓰는 편이 대책으로 이어집니다.

기술 용어는 한 번 풀어 쓴다. 읽는 사람이 모두 전산 담당자는 아닙니다. "DB 커넥션 풀 고갈"이라고만 쓰기보다 "동시에 접속할 수 있는 연결 수가 모두 차서 새 접속이 막힘"처럼 한 줄 설명을 붙이면 됩니다.

경과는 기억이 아니라 기록으로 쓴다. 복구 중에는 정신이 없어서 시각을 놓치기 쉽습니다. 메신저 대화, 서버 로그, 작업 메모에 남은 시각을 기준으로 정리해야 정확합니다. 평소 작업 기록을 남겨 두는 습관이 이럴 때 도움이 됩니다. 기록 습관에 대해서는 일 잘하는 사람의 공통점에서도 다뤘습니다.

개인정보나 내부 정보는 걸러서 공유한다. 장애 보고서에 사용자 이름, 계정 정보, 서버 접속 정보가 그대로 들어가는 경우가 있습니다. 공유 범위가 넓은 1보와 중간 보고에서는 특히 조심해야 합니다.

---

장애는 막으려고 해도 생깁니다. 다만 보고를 어떻게 하느냐에 따라 같은 장애라도 "대응이 빨랐다"는 평가를 받기도 하고, "무슨 일인지 아무도 몰랐다"는 말을 듣기도 합니다.

처음부터 완벽한 양식을 만들 필요는 없습니다. 1보에 쓸 다섯 줄만 미리 메모해 두어도, 다음 장애 때 훨씬 덜 당황하게 됩니다.

---

복사해서 쓰는 장애 보고 문장

1보: 사실만 빠르게 알릴 때

[장애 1보] ○시 ○분부터 ○○ 기능에서 오류를 확인했습니다. 현재 영향 범위와 원인을 확인 중이며, 다음 공유 예정 시각은 ○시 ○분입니다.

중간보고: 원인과 조치를 구분할 때

[장애 중간보고] 현재 ○○ 구간에서 오류가 발생한 것으로 확인했습니다. 임시 조치로 △△를 적용했으며, 정상 처리 여부를 ○건 단위로 확인하고 있습니다. 미확인 내용은 추정하지 않고 확인 후 다시 공유하겠습니다.

종료보고: 복구와 후속조치를 알릴 때

[장애 종료보고] ○시 ○분 서비스 복구를 확인했습니다. 장애 시간은 총 ○분이며 영향 범위는 ○○입니다. 누락·중복 처리를 점검 중이고, 재발 방지 항목과 담당 기한은 ○월 ○일까지 확정하겠습니다.

좋은 장애 보고의 원칙

• 확인된 사실과 추정 내용을 분리합니다.
• 장애 시작 시각, 영향 범위, 현재 조치, 다음 공유 시각을 포함합니다.
• 원인을 찾기 전 담당자 개인의 잘못으로 단정하지 않습니다.
• 복구 선언 전 실제 사용자 경로와 누락·중복 여부를 확인합니다.
• 개인정보, 계정 정보, 내부 주소는 보고서에서 마스킹합니다.

함께 보면 좋은 글

• ChatGPT·Claude 장애 시 업무 중단을 줄이는 실전 대응법
• 회의록 작성법과 실무 템플릿
• 인수인계서 작성법과 실무 체크리스트
• 주간업무보고 작성법과 예시