장애 진행 상황 공지, 확인한 사실과 다음 갱신을 전하기
기준일 2026-10-21 · AZET 운영팀 작성
이 글은 AZET 운영팀이 장애 중 공지 문안을 정리한 참고용 안내입니다. 등장하는 오류와 시각은 모두 가상 예시입니다. AZET에서 발생한 장애나 현재 운영 상태를 보고하는 글이 아닙니다.
작업이 멈춘 고객에게 “확인 중입니다”만 전달하면 기다려도 되는지, 다른 업무를 해야 하는지 판단할 근거가 부족합니다. 장애 진행 상황 공지에는 현재 확인된 증상, 영향을 받는 작업, 미확인 사항, 다음 갱신 시점을 담습니다. 원인 규명 전에도 전달할 수 있습니다.
관찰한 현상부터 공지합니다
가상 상황으로 자료 저장 요청에서 오류가 확인됐다고 해 보겠습니다. 첫 안내는 ‘자료 저장 시 오류가 발생하는 현상을 확인했습니다’처럼 관찰 사실에서 시작합니다. 근거 없이 서버 과부하나 외부 업체 문제를 원인으로 적지 않습니다.
| 정보 구분 | 가상 공지 내용 | 표현 전 확인할 점 |
|---|---|---|
| 확인된 증상 | 자료 저장 중 오류 발생 | 실제로 관찰한 작업 |
| 영향 범위 | 특정 작업 공간에서 확인 | 전체 범위를 조사했는지 |
| 미확인 사항 | 시작 시점과 원인 조사 중 | 아직 판단할 수 없는 부분 |
| 현재 대응 | 저장 요청 기록 확인 중 | 실제 진행 중인 조치 |
| 다음 갱신 | 14:30 KST에 진행 상황 안내 | 갱신할 담당자와 게시 위치 |
표의 시각은 완료 예측이 아니라 정보를 다시 제공할 시점입니다. 담당자가 지킬 수 있는 갱신 주기를 정하고, 원인을 찾지 못했더라도 약속한 시각에 현재 상태를 알립니다. ‘곧 해결’처럼 근거 없는 표현으로 빈칸을 채우지 않습니다.
확인 시각과 발생 시각을 나눕니다
14:05에 현상을 확인했다는 사실만으로 14:05부터 장애가 시작됐다고 쓰면 안 됩니다. 최초 확인 시각과 추정 영향 구간을 별도로 적고, 시작 시점이 밝혀지면 갱신합니다. 영향 대상도 처음 확인한 집단과 전체 조사 결과를 구별합니다.
가상 안내에서 일부 작업 공간만 조사했다면 그 범위에서 오류를 확인했다고 설명합니다. 다른 작업 공간이 정상이라는 결론은 별도 확인이 필요합니다. 추가 확인 중인 대상을 밝혀 전체 영향이 미확인 상태임을 알립니다.
공지에 마지막 갱신 시각과 시간대를 표시하고, 새로 확인한 항목을 구분해 다시 읽는 고객이 찾기 쉽게 합니다. 영향 범위를 잘못 알렸다면 해당 문장을 조용히 지우기보다 정정한 내용과 시점을 남깁니다.
임시 대응도 검증한 범위에서 안내합니다
새로고침이나 반복 제출이 도움이 되는지 확인하지 않았다면 일괄적으로 권하지 않습니다. 특히 저장 결과가 불명확한 작업은 중복 처리 가능성을 살펴야 합니다. 가상 예시로 결과 목록에서 반영 여부를 확인할 수 있을 때에만 그 경로를 먼저 안내합니다.
별도 해결 방법이 없다면 중단할 작업과 계속할 수 있는 작업을 구분합니다. 문의를 받는 경우에는 발생 시각과 작업 이름 등 확인에 필요한 정보를 제시하되, 공개 댓글에 고객 자료를 붙이지 않도록 전달 경로를 안내합니다.
변화가 없는 갱신도 의미가 있습니다. 새로 확인된 내용이 없다는 점, 계속 조사 중인 항목, 다음 안내 시점을 적습니다. 담당자가 바뀌어도 게시 위치를 유지해 진행 흐름을 연결합니다.
자주 묻는 질문(FAQ)
Q1. 원인을 알기 전에는 공지를 미뤄야 하나요? 고객의 업무 영향이 확인됐다면 증상과 확인 범위부터 전달할 수 있습니다. 원인과 복구 예상 시점은 확인되지 않았다고 분리해 씁니다.
Q2. 한 번의 성공으로 복구됐다고 안내해도 되나요? 한 번의 결과는 확인 범위가 좁습니다. 필요한 작업과 대상의 상태를 더 확인하고, 복구 범위가 정리된 뒤 완료 안내를 별도로 작성합니다.
AZET 관련 안내는 azet.io에서 확인하세요.