서비스 장애 고객 공지 작성법: 원인을 모를 때도 먼저 알리는 5단계

고객이 결제 화면에서 계속 오류를 본다면 개발팀의 원인 분석보다 먼저 알고 싶은 것이 있습니다. 지금 어떤 작업이 안 되는지, 자신의 주문이 남아 있는지, 언제 다시 안내받을 수 있는지입니다.

첫 공지는 원인 보고서가 아닙니다. 확인된 영향, 아직 모르는 부분, 고객이 지금 할 수 있는 일, 다음 안내 시각을 짧게 약속하는 문장입니다. 복구 시각을 모르더라도 이 네 가지는 말할 수 있습니다.

오류 메시지보다 고객이 멈춘 일을 적습니다

관리 화면에 500 오류가 보인다는 설명만으로는 고객이 자기 상황을 판단하기 어렵습니다. 먼저 영향을 받는 행동을 한 문장으로 바꿉니다. 예를 들어 “일부 고객이 결제를 완료하지 못하고 있습니다”는 “결제 API에서 오류가 발생했습니다”보다 고객의 다음 행동에 가깝습니다.

범위가 확인되지 않았다면 “모든 고객”이라고 확대하지 마세요. 반대로 확인된 영향이 있는데 “일시적인 불편”처럼 작게 쓰지도 마세요. 확인된 사실과 조사 중인 항목을 나누면 됩니다.

• 영향: “일부 고객의 결제 완료 화면이 열리지 않습니다”라고 확인된 범위만 적습니다.
• 데이터: 저장 여부를 확인 중이라면 안전하다고 단정하지 않습니다.
• 원인: 확인 전에는 외부 업체 탓으로 추측하지 않습니다.
• 시간: “곧 복구” 대신 다음 상황을 알릴 시각을 적습니다.

위 문장은 가상의 예시입니다. 실제 공지에서는 관찰된 범위와 시각을 확인한 뒤 바꿔 써야 합니다.

첫 안내는 다섯 칸으로 씁니다

길게 사과문부터 쓰면 정작 필요한 정보가 뒤로 밀립니다. 제목과 본문에 다음 다섯 칸을 채우세요.

1. 어떤 기능에 영향이 있는가
2. 고객에게 어떤 현상이 보이는가
3. 확인한 사실과 아직 확인 중인 것은 무엇인가
4. 고객이 지금 해야 하거나 피해야 할 일은 무엇인가
5. 다음 안내는 언제, 어디에서 볼 수 있는가

가상의 예시로 주문은 접수됐을 수 있지만 완료 화면만 실패하는 상황을 생각해 봅시다. 이때 무조건 다시 결제하라고 안내하면 중복 결제 위험을 만들 수 있습니다. 주문 저장 여부를 확인하기 전에는 재시도를 권하지 않고, 문의 경로와 다음 갱신 시간을 알려주는 편이 안전합니다.

이 역시 가상의 문안입니다. 개별 서비스의 실제 영향 범위, 문의 주소, 갱신 시간으로 교체한 뒤 사용해야 합니다.

갱신 시각은 복구 약속이 아니라 소식 약속입니다

“오후 3시에 다시 안내”는 “오후 3시에 고치겠다”는 뜻이 아닙니다. 해결되지 않았더라도 그 시간에 무엇을 확인했고, 영향이 달라졌는지, 다음 안내는 언제인지 알려야 합니다.

혼자 운영한다면 지나치게 짧은 갱신 간격을 약속하지 마세요. 실제로 지킬 수 있는 간격을 정하고, 조치 담당자와 공지 담당자가 같은 사실 목록을 보게 합니다. 새 사실이 없어도 정해진 시각에 “영향 범위는 현재까지 동일하며, 원인을 계속 확인하고 있습니다”처럼 상태를 갱신할 수 있습니다.

공개 상태 화면, 고객 이메일, 소셜 계정을 함께 쓴다면 표현과 시각을 맞춥니다. 한 채널에는 복구라고 쓰고 다른 채널에는 조사 중이라고 남겨두면 고객은 어느 쪽을 믿어야 할지 모릅니다. 공식 공지 한곳을 기준 기록으로 정하고, 다른 채널은 그 기록을 가리키게 합니다.

복구 공지는 기능 확인 뒤에 냅니다

오류 알림이 사라졌다고 바로 “정상화”라고 쓰면 같은 고객 행동에서 다시 실패할 수 있습니다. 실제로 막혔던 흐름을 다시 수행해 보세요. 결제라면 테스트 주문의 접수, 완료 화면, 알림, 기록 반영을 순서대로 확인합니다. 테스트에는 승인된 환경과 절차를 사용합니다.

복구 안내에는 영향을 받았던 기능, 정상 동작을 확인한 시각, 남아 있는 후속 작업, 도움이 필요한 고객의 연락 경로를 적습니다. 원인을 아직 확정하지 못했다면 “원인 분석은 계속 진행 중”이라고 분리해서 쓰면 됩니다. 복구 상태와 원인 분석 상태는 같지 않습니다.

다음 번을 위해 공지 기록을 남깁니다

사건이 끝나면 첫 신고 시각, 영향 확인 시각, 첫 공지 시각, 갱신 약속 이행 여부, 복구 검증 시각을 함께 적습니다. 이 기록은 다음에 고객이 기다린 시간을 줄이기 위한 자료입니다.

첫 공지가 늦었다면 기술적 원인과 별도로 이유를 봅니다. 공지 권한이 누구에게 있었는지, 영향 범위를 알기 전에는 아무 말도 할 수 없다고 생각했는지, 고객에게 보낼 공식 주소와 상태 기록 위치가 준비돼 있었는지를 확인하세요.

평상시 문의에 답할 시간을 정하는 일도 함께 필요합니다. 고객 응답 시간을 미리 설계하는 기준을 정해두면 긴급 문의와 일반 문의가 한 받은편지함에서 섞이는 일을 줄일 수 있습니다.

바로 복사해 둘 첫 공지 틀

빈칸을 모두 채울 수 없어도 첫 공지를 무기한 미룰 필요는 없습니다. 확인되지 않은 내용을 추측으로 메우지 말고, 그 사실을 확인 중이라고 쓰세요.

자주 묻는 질문

원인을 모르면 공지해도 되나요?

고객에게 영향이 확인됐다면 원인과 복구 예정을 모르더라도 현재 현상, 확인된 범위, 다음 안내 시각을 먼저 알릴 수 있습니다.

모든 고객에게 이메일을 보내야 하나요?

영향 범위와 고객이 해야 할 행동에 따라 결정합니다. 전체 공개 상태 안내와 영향받은 고객 대상 이메일의 역할을 나누고, 두 채널의 내용이 어긋나지 않게 관리하세요.

복구 뒤 원인 분석이 끝나지 않았다면요?

기능이 정상 동작한다는 검증 결과와 원인 분석 상태를 분리해서 알립니다. 원인이 확정되지 않았다면 추정 원인을 사실처럼 쓰지 않습니다.