배포 후 결제 버튼에서 오류 제보가 들어오면, 개발자는 로그를 열고 원인을 찾기 시작합니다. 그런데 고객은 로그를 볼 수 없습니다. 고객 화면에는 결제가 됐는지, 주문이 접수됐는지 모르는 상태만 남습니다.
이때 공지는 기술 조사와 별도의 작업으로 잡아야 합니다. 원인을 다 찾은 뒤 한 번에 설명하려고 하면, 정작 가장 불안한 시간에 아무 안내도 하지 못합니다. 아래는 가상의 결제 오류 상황에서 작은 팀이 쓸 수 있는 순서입니다.
첫 공지는 진단 보고서가 아닙니다
첫 메시지는 세 가지를 답하면 충분합니다.
- 확인된 범위: 결제 단계에서 오류가 확인됐는가, 모든 고객에게 해당하는가
- 지금 할 일: 재시도 전에 결제 내역을 확인해야 하는가
- 다음 안내: 언제, 어디서 업데이트할 것인가
“원인을 조사 중입니다”는 사실이지만 고객 행동을 알려주지 못합니다. 반대로 “곧 복구됩니다”는 근거 없는 약속이 될 수 있습니다. 확인된 것과 아직 모르는 것을 분리해 쓰는 편이 안전합니다.
운영자와 개발자의 타임라인을 나눠 보세요
개발자는 재현 조건, 결제 요청 기록, 영향 범위를 확인합니다. 운영자는 문의 창구를 한곳으로 모으고, 이미 결제를 시도한 고객에게 중복 시도 주의와 다음 안내 시각을 알립니다. 혼자 운영한다면 두 역할을 시간 순서로 나눠 메모해 두면 됩니다.
예를 들어 첫 15분에 “일부 결제 시도에서 오류가 확인됐습니다. 결제 내역을 먼저 확인해 주세요. 오후 3시에 다시 안내하겠습니다”라고 보낼 수 있습니다. 오후 3시에도 원인을 모른다면 조사 상태와 확인된 범위를 갱신합니다. 약속한 시각에 다시 알리는 것이 핵심입니다.
복구 확인이 끝나도 공지는 끝나지 않습니다
기능이 정상으로 돌아왔는지와 고객의 개별 주문이 정상 처리됐는지는 다른 질문입니다. 종료 공지에는 영향 시간, 주문 확인 방법, 누락이나 중복 결제 의심 시 문의 방법을 남겨야 합니다. 이 마지막 안내가 있어야 첫 공지에서 시작한 대화가 닫힙니다.
장애 공지는 미리 써 둔 문장 하나로 해결되지 않습니다. 대신 범위, 고객 행동, 다음 시각이라는 세 칸만 미리 정해 두면 실제 사고에서 빈 화면을 보는 시간을 줄일 수 있습니다.
Top comments (0)