위기 초기에는 정보가 부족하지만 이용자는 즉시 무엇을 해야 하는지 알아야 합니다. 모든 사실이 확정될 때까지 기다리기보다 확인된 범위, 보호 조치와 다음 업데이트 시각을 먼저 알리는 편이 낫습니다.
빠른 공지와 추측성 공지는 다릅니다. 기술, 법무, 운영과 현지 커뮤니케이션 담당자가 같은 사실표를 사용해야 언어와 채널마다 설명이 달라지는 문제를 막을 수 있습니다.
사건 등급과 의사결정자를 먼저 확정합니다
자산 손실 가능성, 이용 중단 범위, 개인정보 영향과 외부 보도 여부를 기준으로 사건 등급을 나눕니다. 등급마다 공지 승인자, 기술 확인자와 이용자 지원 책임자를 미리 지정합니다.
한국 시간대에 본사 담당자가 부재한 상황도 고려해야 합니다. 긴급 공지를 승인할 수 있는 대리 권한과 연락 순서를 문서로 남깁니다.
최초 공지에는 이용자 행동을 우선합니다
발생 시각, 영향받는 기능, 현재 조치, 이용자가 해야 할 일과 다음 업데이트 시점을 포함합니다. 원인이 확인되지 않았다면 추정하지 말고 조사 중인 범위를 분명히 씁니다.
- 영향받는 체인·제품·사용자 범위
- 중단하거나 피해야 할 행동
- 공식 지원 및 신고 창구
- 다음 상태 업데이트 예정 시각
하나의 사실표와 업데이트 로그를 유지합니다
채널 담당자가 각자 기술팀에 질문하지 않도록 사건 번호가 있는 공통 문서를 운영합니다. 확인된 사실, 미확인 질문, 외부 공개 가능 여부와 승인자를 항목별로 기록합니다.
이전 공지를 조용히 덮어쓰지 말고 변경된 내용을 시간순으로 남깁니다. 잘못 안내한 부분이 있다면 수정 이유와 영향을 명확하게 설명하는 것이 신뢰 회복에 도움이 됩니다.
복구 공지는 원인·영향·재발 방지를 구분합니다
서비스가 재개됐다는 말만으로 사건이 끝나지는 않습니다. 실제 피해 범위, 보상 또는 지원 절차, 남은 제한과 이용자가 확인할 사항을 안내해야 합니다.
상세 사후 보고서는 검증 가능한 기술적 원인과 개선 일정에 집중합니다. 책임을 단정하기 어려운 단계에서는 조사 기관과 법률 자문 결과를 기다리며 확정되지 않은 표현을 피합니다.
실행 체크리스트
- 사건 등급과 공지 승인자를 지정했다.
- 영향받는 이용자와 기능의 범위를 확인했다.
- 최초 공지에 이용자 행동과 다음 업데이트 시각을 넣었다.
- 확인된 사실과 추정을 문서에서 분리했다.
- 한국어 공식 채널과 지원 창구를 일치시켰다.
- 복구 후 원인·영향·재발 방지 계획을 구분해 공개했다.
자주 묻는 질문
원인이 확인되지 않아도 공지해야 하나요?
이용자 자산이나 행동에 영향이 있다면 확인된 사건 범위와 임시 보호 조치를 먼저 알리는 것이 좋습니다. 원인은 조사 중이라고 분명히 밝히고 다음 업데이트 시간을 약속해야 합니다.
텔레그램 공지만으로 충분한가요?
중요 공지는 프로젝트가 통제하는 공식 웹사이트나 상태 페이지에도 남겨야 합니다. 각 SNS와 커뮤니티에는 같은 원문으로 연결해 사칭과 문구 불일치를 줄이는 편이 좋습니다.