# 2026-09-28 서비스 장애 고객 공지 작성법

## 발행 상태와 검색 의도

- 상태: canonical과 일부 외부 채널 공개 발행 검증 완료. 아래 실행 기록에 없는 채널이나 활동은 완료로 간주하지 않는다.
- 기본 검색어: 서비스 장애 고객 공지 작성법
- 보조 검색어: 서비스 오류 안내문, 장애 첫 공지, 복구 안내 메일, 고객 공지 예시
- 독자: 제품이나 예약, 결제, 문의 서비스를 혼자 운영하며 오류가 생겼을 때 고객에게 먼저 무엇을 말해야 할지 정해야 하는 대표
- 독자가 완료할 일: 확인된 영향과 다음 안내 시각을 담은 첫 공지를 작성하고, 복구 뒤 검증 결과를 알린다.
- 단계: 운영 중 고객 신뢰 관리
- canonical 후보 slug: `service-incident-customer-notice`
- 기존 글과 구분: `solo-business-customer-response-time-policy`는 평상시 문의 응답 시간을 정하는 글이고, 이 글은 실제 서비스 영향이 확인된 상황에서 공지의 내용과 갱신 순서를 정한다.
- 내부 연결 후보: `https://officialsite.kr/blog/solo-business-customer-response-time-policy`
- 제품 언급 범위: 고객에게 보낼 공식 발신 주소의 역할만 설명한다. 오피셜메일이 상태 페이지나 장애 탐지 기능을 제공한다고 쓰지 않는다.

## 사실 확인 자료

- [Atlassian Statuspage, Incident communication tips](https://support.atlassian.com/statuspage/docs/incident-communication-tips/): 영향이 확인되면 일찍 알리고, 상황에 맞는 간격으로 갱신하며, 각 채널에서 일관된 설명을 사용하라고 안내한다. 2026-09-28 확인.
- [Atlassian, Learn incident communication with Statuspage](https://www.atlassian.com/incident-management/tutorials/incident-communication): 조사 중, 원인 확인, 조치 관찰, 해결의 상태를 구분하고 첫 안내에서 다음 갱신 시각을 제시하는 예시를 제공한다. 2026-09-28 확인.
- [Google Cloud, Incident communication](https://docs.cloud.google.com/service-health/docs/incident-communication): 영향 범위에 따라 공개 상태 화면과 해당 고객 대상 안내의 역할을 나누는 운영 사례를 설명한다. 문서 마지막 갱신일 2026-09-24, 2026-09-28 확인.
- 아래의 시간, 주문, 고객 사례는 모두 작성 방법을 보여 주는 가상의 예시다. 실제 오피셜메일 장애, 복구 시간, 고객 수, 사용 결과를 뜻하지 않는다.

## canonical 원고

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

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

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

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

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

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

| 항목 | 첫 공지에 쓸 수 있는 표현 | 확인 전 피할 표현 |
| --- | --- | --- |
| 영향 | 일부 고객의 결제 완료 화면이 열리지 않습니다 | 결제 시스템 전체가 중단됐습니다 |
| 데이터 | 현재 주문 저장 여부를 확인 중입니다 | 주문 정보는 모두 안전합니다 |
| 원인 | 원인을 조사하고 있습니다 | 외부 업체 문제로 보입니다 |
| 시간 | 오후 3시에 다음 상황을 알리겠습니다 | 곧 복구됩니다 |

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

## 2. 첫 안내는 다섯 칸으로 씁니다

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

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

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

> 제목: 결제 완료 화면 오류를 확인하고 있습니다
>
> 일부 고객에게 결제 완료 화면이 열리지 않는 현상을 확인했습니다. 주문과 결제 기록이 정상 반영됐는지 확인 중이므로, 같은 주문을 반복 결제하지 말아 주세요. 확인된 내용은 이 공지에서 오후 3시에 다시 안내하겠습니다. 개별 주문 상태가 급히 필요하면 주문 시 사용한 이메일 주소로 고객지원에 문의해 주세요.

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

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

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

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

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

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

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

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

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

사건이 끝나면 공지 문구만 보관하지 말고 첫 신고 시각, 영향이 확인된 시각, 첫 공지 시각, 갱신 약속 이행 여부, 복구 검증 시각을 함께 적습니다. 이 기록은 책임을 피하기 위한 자료가 아니라 다음에 고객이 기다린 시간을 줄이기 위한 자료입니다.

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

평상시 문의에 답할 시간을 정하는 일도 함께 필요합니다. [고객 응답 시간을 미리 설계하는 기준](https://officialsite.kr/blog/solo-business-customer-response-time-policy)을 정해두면 장애 중 긴급 문의와 일반 문의가 한 받은편지함에서 섞이는 일을 줄일 수 있습니다.

## 바로 복사해 둘 첫 공지 틀

> 제목: [영향받는 기능]에서 [고객이 겪는 현상]을 확인 중입니다
>
> [확인된 영향]을 [확인한 시각]부터 확인하고 있습니다. [아직 확인 중인 사항]은 조사 중입니다. 고객께서는 [안전하게 할 수 있는 일 또는 피해야 할 재시도]를 확인해 주세요. 다음 상황은 [날짜와 시각, 시간대]에 [공식 공지 위치]에서 안내하겠습니다. 개별 확인이 필요한 경우 [공식 문의 경로]를 이용해 주세요.

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

## 자주 묻는 질문

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

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

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

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

### 복구 뒤 원인 분석이 끝나지 않았으면 어떻게 쓰나요?

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

## 외부 채널 재작성 방향

- Blogger: 혼자 운영하는 대표가 첫 공지를 10분 안에 작성하는 흐름으로 축약. 가상의 주문 예시와 복사 가능한 다섯 칸을 중심으로 구성.
- WordPress.com: 고객이 첫 공지에서 확인하려는 질문 네 가지를 도입에 두고, 조사 중과 복구 확인의 차이를 사례로 설명. 카테고리는 `운영 인사이트` 후보.
- Tistory: 첫 공지, 1차 갱신, 복구 안내를 같은 가상 사건의 시간 순서로 길게 전개. 복사 가능한 세 문안, 영향 구분 표, 갱신 기록표, Tistory 전용 이미지 세트를 배치. `docs/content/templates/tistory-reference-style.html`에 맞춘 전체 HTML 아티팩트를 별도로 만든 뒤 에디터 네이티브 광고 블록 1개와 공개 스타일 QA를 검증.
- Naver Blog: 공식 공지가 늦어지는 대표의 고민으로 시작하고, 가상의 결제 오류 사례를 4~6개 소제목에 걸쳐 전개. 전용 가로 이미지 2개, 중앙 인용, 네이티브 목록, 설명형 원문 링크.
- DEV.to: 개발자가 원인 분석을 시작하는 순간 고객은 결제 성공 여부를 묻는다는 차이에서 시작. 상태 전환과 검증 시나리오를 중심으로 한국어 기술 운영 글 작성.
- Medium: "복구 시간은 몰라도 다음 안내 시간은 말할 수 있다"는 운영 판단을 도입에 두고, 상태 문구를 갱신하는 방법을 서사로 설명.
- Disquiet: 제품 운영자의 첫 공지 결정에 집중한 한국어 아티클과 별도 오피셜메일 프로덕트 포스트. 같은 본문을 두 번 발행하지 않고 각각의 공개 URL과 제품 연결 상태 확인.
- X: 280자 무료 계정 제한, 링크 포함 260자 이하의 단일 한국어 게시물. 전용 가로 이미지 1개.
- RocketPunch: 고객이 묻는 세 질문을 중심으로 한 짧은 한국어 운영 노트. 전용 이미지와 설명형 원문 링크.
- Instagram: 본문 문안과 같은 메시지의 전용 1122:1402 카드 한 장, 해시태그 정확히 5개. Threads 계정 선택 상태는 별도 확인.
- Reddit: 워밍업 조건과 30개 승인 커뮤니티의 당일 규칙이 확인되기 전에는 이 주제를 홍보 게시물로 배포하지 않는다. 참여할 때는 자연스러운 영어로 비홍보 답변만 작성.

## 발행 전 확인

- 오늘의 관리자 목록, 각 플랫폼 공개 목록, 예약 목록과 30일 활동 이력을 다시 조회한다. 이 파일은 발행이나 예약 완료의 증거가 아니다.
- canonical과 지원 언어 `ko`, `en`, `zh`, `ja`, `vi`, `ru`의 저장 및 공개 화면을 검증한다.
- 각 플랫폼의 독립 원고, 이미지, 설명형 원문 링크, 렌더링, 공개 URL을 검증한다.
- Tistory는 전용 HTML 아티팩트, 네이티브 광고 블록 1개, 공개 스타일 검사, RSS 반영을 검증한다.
- Threads 당일 큐는 실제 한국 시각과 기존 예약을 읽은 뒤 별도로 작성하며, 최근 30일 이내의 날짜 있는 1차 출처가 각 문구의 사실 전제를 뒷받침해야 한다.
- 모든 공개 문구에서 가운데점 문자를 제거한다.

## 2026-09-28 실행 기록

아래 주소는 각 플랫폼의 공개 화면에서 제목과 본문을 확인한 결과다. 각 외부 채널은 원문을 그대로 복제하지 않고 별도 문안으로 작성했다. 장애와 결제 오류는 설명을 위한 가상 상황이며 실제 오피셜메일 장애 공지가 아니다.

| 채널 | 검증된 공개 주소 | 검증 범위 |
| --- | --- | --- |
| Official Mail | https://officialsite.kr/blog/service-incident-customer-notice | 제목, 소제목, 이미지, 내부 링크, 공개 상태 |
| Blogger | https://officialmail-blog.blogspot.com/2026/09/blog-post_28.html | 전용 문안, 이미지, 소제목, 원문 링크 |
| WordPress.com | https://officialmailkr.wordpress.com/2026/09/28/service-incident-customer-notice/ | 전용 문안, 이미지, 소제목, 목록, 원문 링크 |
| Tistory | https://blog.officialsite.kr/15 | 전용 장문 문안, 이미지, 목록, 표, 네이티브 광고 블록, 공개 스타일 검사, RSS |
| Naver Blog | https://blog.naver.com/kavenix/224424620437 | 네이티브 소제목, 인용, 목록, 전용 이미지 2개, 설명형 원문 링크 |
| DEV.to | https://dev.to/officialmailkr/gyeolje-jangaereul-gocineun-dongan-gogaeg-gongjineun-nuga-sseunayo-2md0 | 전용 문안, 표지 이미지, 소제목, 목록, 원문 링크 |
| Medium | https://medium.com/@officialmailkr/서비스가-멈춘-날-고객은-복구보다-다음-안내를-기다립니다-7ee59e36b1fd | 전용 문안, 소제목, 전용 이미지, 대체 텍스트, 설명형 원문 링크 |
| Disquiet 프로덕트 포스트 | https://disquiet.io/posts/veCZpq | 오피셜메일 프로덕트 연결, 한국어 본문, 목록, 인용, 설명형 원문 링크 |
| Disquiet 아티클 | https://disquiet.io/articles/nMsGOo | 오피셜메일 작성자, 별도 한국어 문안, 소제목 4개, 네이티브 목록, 설명형 원문 링크 |
| X | https://x.com/official__mail/status/2104408808584089992 | 무료 계정 글자 수 범위, 전용 이미지와 대체 텍스트, 원문 링크 |
| Instagram | https://www.instagram.com/p/Dd0PS1fCe4c/ | 오피셜메일 계정, 전용 세로 카드 이미지, 본문, 해시태그 5개, 공개 상태 |

- Tistory 공개 검사: `npm run qa:tistory-public -- https://blog.officialsite.kr/15 --artifact docs/content/tistory/2026-09-28-service-incident-customer-notice.html` 통과. 광고 블록은 글쓴이 이미지로 오인하지 않도록 검사기를 수정했다.
- 지원 언어 ko, en, zh, ja, vi, ru의 제목, 설명, 본문, 표, 예시 문안, FAQ, 설명형 내부 링크와 이미지 설명을 별도 로캘 데이터에 추가하고 slug를 로캘 목록에 한 번만 등록했다. TypeScript와 ESLint 검사를 통과했다. 2026-09-28 배포 후 en, zh, ja, vi, ru의 공개 페이지에서 언어별 제목과 본문, 설명형 내부 링크, 1672픽셀 이미지와 번역된 대체 텍스트, canonical 및 7개 언어 대체 링크를 확인했다. zh 본문에 남았던 한국어 제품명은 수정해 재배포하고 한국어 잔존 여부를 다시 검사했다. 사이트맵에도 이 글의 로캘 주소가 반영됐다.
- Tistory 모바일 서식은 390픽셀 화면에서 본문 18픽셀, 줄간격 1.88, 소제목 24픽셀과 3픽셀 하단 선, 요약 및 목차의 안쪽 여백, 표의 별도 가로 스크롤을 확인했다. 광고 로딩 뒤 화면을 다시 검사했을 때 문서 전체의 가로 넘침은 없었다.
- Naver의 모바일 전용 주소는 인앱 브라우저 안전 차단으로 열 수 없었다. 공개 데스크톱 화면은 확인했지만 모바일 전용 렌더링 검증은 미완료다.
- Disquiet 아티클의 첫 편집본에서 본문 중복이 생겨 전체 내용을 다시 입력하고 공개 화면의 본문 구조와 링크를 확인한 뒤 발행했다. 위 표의 공개 주소만 완료로 센다.
- RocketPunch는 `@officialmail` 프로필이 보이지만 `AGENTS.md`가 요구하는 소유자 이름 `이상현`을 확인할 수 없어 초안 게시 및 활동을 보류했다.
- Medium의 첫 시도에서 편집 내용이 손상되어 미발행 초안으로 남았다. 위 표의 두 번째 새 초안만 공개 발행했으며, 이전 초안을 공개 글로 세지 않는다.
- Threads 첫 예약은 14:09 KST 예정이었으나, 담당자가 그보다 앞선 13:43 KST에 같은 예약 건에서 `지금 게시`를 눌렀다. 자동 발행 실패의 증거는 아니다. 공개 [Threads 글](https://www.threads.com/@official__mail/post/Dd0WppVCRo4)의 `time` 요소에서 실제 발행 시각 2026-09-28 13:43:37 KST를 확인했다. 관리자 달력은 이 글의 원래 예약 시각 14:09를 계속 표시하므로 실제 발행 간격 계산에 사용하지 않는다.
- 남은 오피셜메일 Threads 전용 예약 8건은 실제 첫 발행 시각을 기준으로 한국 시각 14:36, 15:32, 16:53, 17:56, 19:14, 20:19, 21:43, 22:41로 같은 예약 레코드의 시각만 수정했다. 첫 실제 발행부터의 간격은 53, 56, 81, 63, 78, 65, 84, 58분이다. Kavenix 달력에서 8건 모두 `예약됨`과 `official__mail`을 확인했으나, 이는 공개 발행 증거가 아니다. 각 예약은 텍스트 전용, 이미지, 링크, 해시태그, 주제 입력 없음. 다음 발행부터 공개 프로필과 개별 URL을 대조하도록 당일 임시 후속 점검을 설정했다.
- Threads 문안의 사실 전제를 검증한 날짜 있는 공식 자료: [VS Code 1.139, 9월 23일](https://code.visualstudio.com/updates/v1_139), [Vercel Sandbox 메모리 관찰 기능, 9월 25일](https://vercel.com/changelog/vercel-sandbox-now-supports-memory-observability), [GitHub Copilot 주간 변경, 9월 18일](https://github.blog/changelog/2026-09-18-github-copilot-weekly-releases-september-14/), [Cloudflare Rules 사전 검증, 9월 17일](https://developers.cloudflare.com/changelog/post/2026-09-17-rulesets-dry-run-validation/), [Vercel Sandbox Drives, 9월 23일](https://vercel.com/changelog/drives-for-vercel-sandbox-are-now-in-public-beta), [Vercel CLI 변경 기록 검색, 9월 9일](https://vercel.com/changelog/you-can-now-read-and-search-changelogs-from-the-cli), [VS Code 1.140 Insiders, 9월 24일](https://code.visualstudio.com/updates/v1_140), [GitHub Copilot 자동 모델 선택, 9월 14일](https://github.blog/changelog/2026-09-14-configure-cost-and-quality-in-copilot-auto-model-selection/), [Cloudflare Logpush 변경 기록, 9월 18일](https://developers.cloudflare.com/changelog/product/logpush/). 공개 문안에는 출처 링크를 넣지 않았다.
- Reddit 및 플랫폼별 타인 게시물 활동은 이 기록 시점에 검증된 완료 실적이 없다. 중복 액션 방지를 위해 시도나 계획을 완료로 기록하지 않는다.