위기 커뮤니케이션

준비가 없는 팀에서 사고가 나면 대응보다 회의가 먼저 시작됩니다. 서비스에 영향을 준 사고를 인시던트라고 하는데, 인시던트가 터졌을 때 기술적인 복구는 당번이 바로 시작하는 반면 밖에 알리는 일은 아무도 자기 몫이라고 생각하지 않습니다. 알려도 되는지, 누구 이름으로 나가야 하는지, 어디까지 써도 되는지가 정해져 있지 않기 때문입니다.

새벽 2시에 문서 저장이 멈춘 상황을 놓고 보면 이렇게 흘러갑니다. 대화방에서 "이거 공지해야 하지 않나요" 라는 말이 나오고, 마케팅 담당자는 자다 일어나 상황을 모르고, 법무 검토를 받아야 하는 것 아니냐는 의견이 붙습니다. 40분이 지나는 동안 공지는 한 줄도 나가지 않았는데, 그사이 사용자들은 이미 소셜에 글을 올리고 서로 "나도 안 된다" 를 확인하고 있습니다. 회사가 첫마디를 꺼냈을 때는 이미 사용자가 만든 설명이 자리를 잡은 뒤입니다.

문제는 사고 자체보다 침묵이 만드는 해석에 있습니다. 아무 말이 없으면 사람들은 최악을 가정합니다. 저장이 잠시 안 되는 것뿐인데 데이터가 날아갔다는 이야기가 돌고, 그 이야기를 되돌리는 데는 장애를 고치는 것보다 긴 시간이 듭니다. 위기 커뮤니케이션은 이 시간을 줄이려고 판단을 미리 끝내 두는 일입니다.

순서는 사실 확인에서 시작해 종료 공지로 끝나고, 중간에 공지가 정해진 간격으로 반복됩니다.

1. 사실 확인 — 무엇이 언제부터 안 되고 있고 누가 영향을 받는지를 먼저 좁힙니다. 전체 사용자인지 특정 지역인지, 데이터가 사라진 것인지 보이지 않는 것뿐인지에 따라 다음 문장이 완전히 달라집니다.
2. 심각도 판정 — 사고가 서비스에 끼치는 영향의 크기를 심각도라고 하고, 여기서 공지 수준이 갈립니다. 상태 페이지에만 올릴 일인지, 전체 사용자에게 메일을 보낼 일인지, 언론 질의까지 대비할 일인지가 이 단계에서 정해집니다.
3. 첫 공지 — 감지 후 30분에서 1시간 안에 내보냅니다. 들어가는 것은 넷입니다. 지금 무슨 일이 일어나고 있는지, 어디까지 파악했고 무엇을 아직 모르는지, 사용자가 당장 무엇을 하면 되는지, 다음 소식을 언제 내놓을지입니다.
4. 후속 공지 — 앞선 공지에서 약속한 시각을 지킵니다. 진전이 없어도 냅니다. "아직 원인을 찾는 중이고 다음 소식은 한 시간 뒤" 라는 한 줄이 침묵보다 낫습니다. 이 약속을 한 번 어기면 그다음 공지부터는 아무도 시각을 믿지 않습니다.
5. 종료 공지 — 복구된 시각과 영향 범위를 확정해 알립니다. 여기서 보상이나 환불 기준이 있으면 함께 밝힙니다.
6. 사후 정리 — 사고를 되짚어 원인과 개선을 적은 기록인 포스트모템을 만들고, 기업 고객이 있는 제품이라면 그중 공개할 수 있는 부분을 정리해 내놓습니다.

사람은 네 자리가 필요하고, 각자 들어오는 시점이 다릅니다.

• 사실을 대는 사람 — 장애 연락을 받기로 한 당번인 온콜 담당자가 맡습니다. 감지 즉시 들어와 무엇이 어디까지 영향을 주는지를 확인해 줍니다.
• 문구를 쓰는 사람 — 홍보 담당자가 맡고 첫 공지 초안부터 들어옵니다. 기술 용어를 사용자 언어로 바꾸고 밝힐 것과 아닌 것의 선을 지킵니다.
• 대외 창구 — 언론과 파트너의 연락을 한 사람이 받습니다. 평소 미디어 관계, 그러니까 기자와 쌓아 둔 관계를 담당하던 사람이 그대로 맡는 편이 좋습니다. 창구가 둘이면 회사가 서로 다른 말을 한 것으로 기록됩니다.
• 최종 승인자 — 대표나 그에 준하는 사람입니다. 심각도가 높은 사고에서는 회사 이름으로 사과하고 보상을 약속할 권한이 필요한데, 이 결정을 실무자가 대신할 수 없습니다.

시점은 감지 시각을 0분으로 놓고 잡습니다. 15분 안에 네 자리가 한 대화방에 모이고, 30분에서 1시간 사이에 첫 공지가 나가고, 그 뒤로는 약속한 간격을 지킵니다. 사고 대응은 급한 과제를 위해 임시로 모이는 체제인 워룸의 전형입니다. 이 체제를 사고가 난 뒤에 짜려고 하면 사람을 찾는 데만 30분이 갑니다.

"지금 원인을 몰라도 첫 공지는 나가야 해요. 모른다는 것까지 쓰면 됩니다."

완성된 설명을 기다리느라 공지를 미루지 말자는 말입니다.

"이건 상태 페이지로 충분한 건이에요. 전체 메일까지 갈 심각도는 아닙니다."

알리는 채널을 사고 크기에 맞추자는 판단입니다.

"언론 문의는 전부 저한테 돌려주세요. 개별 답변 나가면 말이 갈립니다."

대외 창구를 하나로 묶자는 요청입니다.

페이지덱에서 문서 저장이 20분 동안 멈춘 적이 있습니다. 태오가 감지하고 10분 만에 대화방이 열렸고, 현우가 첫 공지를 써서 25분 시점에 내보냈습니다. 원인은 그때까지도 몰랐지만 "저장이 실패하고 있고, 작성 중인 내용은 브라우저에 남아 있으니 창을 닫지 말아 달라" 는 두 문장이 들어갔습니다.

수아는 같은 내용을 유료 고객사 담당자들에게 따로 돌렸습니다. 공지를 보고 먼저 연락해 오는 것과 회사가 먼저 알려 주는 것은 그 뒤 대화가 다릅니다. 규원은 복구 다음 날 원인과 재발 방지책을 공개 글로 냈습니다.

원인을 다 밝힌 뒤에 한 번에 알리는 것이 정확한 대응이라고 보는 경우가 가장 많습니다. 확인되지 않은 말을 내보내면 안 된다는 생각 자체는 맞습니다. 하지만 공지의 목적은 원인 설명이 아니라 지금 무엇을 하면 되는지 알려 주는 데 있습니다. 원인 파악에 여섯 시간이 걸리는 동안 침묵하면, 그 여섯 시간 동안 사용자는 자기들끼리 원인을 지어냅니다. 나중에 정확한 설명을 내놓아도 이미 퍼진 이야기를 되돌리는 쪽에 훨씬 큰 비용이 듭니다.

사과하면 책임을 인정하는 셈이니 문장을 모호하게 써야 한다는 오해도 흔합니다. 법적 위험을 줄이려는 판단이라 회사 안에서는 설득력을 갖기 쉽습니다. 그런데 "일부 사용자에게 불편이 있었을 수 있습니다" 같은 문장은 아무것도 부인하지 못하면서 신뢰만 깎습니다. 읽는 사람은 회사가 무언가 숨기고 있다고 받아들이고, 신뢰가 무너져 사업이 타격을 받는 평판 위험은 사고 자체보다 이런 문장에서 더 커집니다. 확인된 사실은 분명하게 쓰고 확인되지 않은 것은 확인되지 않았다고 쓰는 쪽이 법적으로도 더 안전합니다.