전사_배포공지 발송

규칙

이 여섯 줄이 전부다

스테이징·개발 환경 배포는 이 채널에 올리지 않는다. 여기는 운영(고객이 쓰는 것)만이다. 웹을 배포하면 앱 안의 웹 화면도 같이 바뀐다(앱을 완전히 끄고 다시 열면 반영). 앱(고객)·앱(선주)은 스토어에서 업데이트해야 바뀐다. 사장님앱은 앱(선주)로 쓴다. 이 문장은 대상을 고르면 글에 자동으로 붙는다.

CS는 이것만

• [장애] [되돌림] 중 아래에 [정상복구]가 아직 안 붙은 글이 있으면(며칠 전 글이라도) → 그 글의 고객 안내 문장을 그대로 읽는다.
• 그런 글이 없으면 정상이다. 이렇게 읽는다 · "지금 확인된 오류는 없습니다. 앱을 완전히 껐다 켜고 다시 시도해 주세요. 그래도 안 되면 다시 연락 주세요"
• [배포완료]가 방금 떴는데 "화면이 하얗다 / 버튼이 안 눌린다"는 제보면 → 그 글의 마지막 줄(반영 방법)을 보고 안내한다. 웹이면 새로고침, 앱 안의 웹 화면이면 앱을 완전히 껐다 켜기, 앱이면 스토어에서 업데이트. 그래도 안 되면 1건이라도 바로 알린다.
• 같은 증상 문의가 2건 넘으면 → 채널 설명에 적힌 CS 비상연락으로 바로 전화한다. 15분 안에 안 받으면 야간·주말 2차 연락처로.

발송

새 글 보내기

유형을 고르고 값을 채운 뒤 「발송」을 누르면 확인 창이 뜨고, 한 번 더 누르면 채널에 올라간다. 대상·앱·스토어는 해당하는 것을 여러 개 누를 수 있고, 셋 이상이면 제목은 「전체」로 줄고 본문에 목록이 나온다. 이름 칸은 자동완성이 뜨고 쉼표로 여러 명을 넣는다. 메모 같은 나머지 선택 항목은 「자세히」를 눌러 열고, 비워 두면 그 줄이 아예 안 나간다.

미리보기는 휴대폰 폭으로 보여 주고, 그 아래에 안 채운 칸과 확인할 점이 뜬다. 「막힘 ·」이 뜨면 발송이 안 된다 — 원글보다 이른 시각, 이미 지난 시각의 [배포예정], 스토어 배포 100%를 확인 안 한 강제 업데이트, 승인 없는 정산 변경, 선주 안내가 있던 글을 정정 문장 없이 취소·연기하는 후속이 여기 걸린다. 예시 문장이 그대로 남았거나, 알림이 안 가는 이름이거나, 선주 안내에 날짜가 없거나, 원글을 안 골랐으면 「확인 ·」 경고가 뜬다.

값이 「없음」인 「관련 항목」 줄은 글에서 통째로 빠진다. 고객·선주 안내가 둘 다 「없음」이면 한 줄로 접힌다. 대상을 셋 이상 고르면 제목은 「전체」로 줄고 본문 첫 줄에 목록이 나온다.

아래에 아직 안 끝난 건이 뜬다 — ① [정상복구]가 안 붙은 [장애]·[되돌림] ② 예정 시각이 지났는데 안 닫힌 [배포예정]·점검·「아직 안 함」 상태의 설정 변경·강제 업데이트(앱 심사 제출은 3일 기준) ③ 확인 기한이 지났는데 후속 「정상」·「이상」이 안 올라온 글. 비어 있으면 열린 건이 없다는 뜻이다.

닫는 방법 · 예정 글은 그 건의 완료 글을 올릴 때 「이 배포의 예정 글」에서 고르면 닫힌다. 안 하기로 했으면 후속 「취소」. 연기했으면 새 [배포예정]을 올리고 옛 글은 후속 「취소」로 닫는다. 「아직 안 함」으로 올린 설정 변경·강제 업데이트는 실제로 적용한 뒤 그 글의 후속 「끝」으로 닫는다. [장애]·[되돌림]은 [정상복구] 새 글이나 후속 「끝」으로만 닫힌다(후속 「정상」으로는 안 닫힌다).

후속

후속 보내기

이미 올린 글에 이어지는 소식. 원글을 고르면 제목과 링크가 자동으로 붙는다. 예정대로 진행되면 「시작」만 보낸다. 장애·되돌림이 끝났을 때는 후속이 아니라 [정상복구]를 새 글로 올린다.

채널 설명

스페이스 설명에 넣는 문안

스페이스 설정의 「설명」 칸에 한 번 넣는다. 새로 들어오는 사람이 이것만 본다.

설명

이 채널이 돌아가는 방식

배포 하나는 이렇게 흘러간다. 예정 글 하나, 완료 글 하나, 그 사이는 후속이다. 유형 앞의 그림(🗓 🛠 ✅ ⏪ 🔴 🟢)이 곧 상태 표시이고, 후속은 상태별로 ▶️ ⏳ ⛔ ☑️ ✅ ⚠️ 🟢 가 붙는다.

3을 올릴 때 「이 배포의 예정 글」에서 1을 고르면 대상·무엇·문의가 그대로 넘어오고, 글 머리에 원글 링크가 붙는다. 작은 배포(문구·이미지 수정)는 3만 올린다. 앱은 심사가 있어서 1과 3 사이가 며칠 벌어지고, 그 사이 심사 결과를 1의 후속 「승인」·「반려」로 보낸다. 예정에서 뭔가 바뀌면 1의 후속으로 변경·연기·취소를 보낸다.

문제가 생기면 [되돌림] 또는 [장애]를 새 글로 올린다. 되돌림은 방금 내보낸 것이 문제라서 배포 전으로 돌리는 것이고, 장애는 배포와 상관없이 고객이 쓰던 기능이 안 되는 것이다. 둘 다 끝나면 [정상복구]를 새 글로 올린다. 장애를 올린 뒤 원인이 배포로 밝혀지면, 장애 글을 지우지 말고 [되돌림]을 새 글로 올린 다음 장애 글에는 후속 「이상」으로 "원인은 14:18 배포. 되돌림 글로 이어집니다"를 남긴다. 이때 장애 글은 아직 열려 있으므로, 복구가 끝나면 되돌림 글에 [정상복구]를 올리고 장애 글에도 후속 「끝」을 남겨 둘 다 닫는다.

유형이 뜻하는 것

대상 표기

웹은 웹사이트. 웹을 배포하면 앱 안의 웹 화면도 같이 바뀐다(앱을 완전히 끄고 다시 열면 반영). 앱(고객)은 고객이 쓰는 앱, 앱(선주)는 사장님앱. 둘 다 스토어에서 업데이트해야 바뀐다. 서버·API는 서버만 바뀌는 것이라 고객이 따로 할 일은 없지만, 배포 중 잠깐 끊기는지는 「서비스 영향」에 적는다. 어드민은 내부 관리 화면이다. 다만 어드민에서 바꿨어도 고객이 보는 값이 바뀌면 대상은 고객이 보는 쪽(웹·앱)으로 고른다 — 쿠폰율 변경이 그렇다. 한 번에 여러 곳이 바뀌면 해당하는 것을 다 눌러서 웹, 앱(고객)처럼 나가게 한다.

누가 뭘 보나

왜 이렇게 하나

• 후속을 원글 링크로 보내는 이유 — 구글챗은 스레드 답글로 접으면 채널만 보는 사람에게 안 보이고, 고정은 고정 목록을 열어야 보인다. 후속은 채널에 새 글로 올라오면서 원글 제목과 링크가 붙어서, 채널만 훑어도 흐름이 보인다.
• 장애·되돌림 종료를 후속이 아니라 새 글로 하는 이유 — 후속 글은 제목이 원글 제목이라 훑어보면 장애 글이 하나 더 늘어난 것처럼 보인다. "장애가 없으면 정상"이라는 CS 규칙이 성립하려면 종료가 눈에 띄는 새 글이어야 한다.
• [배포완료]를 사후에만 올리는 이유 — 이 글이 "고객 화면이 바뀐 시각"의 기준이다. 미리 올리면 운영이 하루 먼저 안내한다. 미리 알릴 건 [배포예정]으로.
• 고객 안내·선주 안내를 항상 쓰는 이유 — "없음"이라도 적혀 있어야 운영과 영업이 매번 되묻지 않는다. 문장이 있으면 그대로 읽는다. 사내 지시는 안내 문장에 섞지 말고 영업 할 일·운영 할 일에 따로 쓴다. 그래야 그대로 복사해서 선주에게 보낼 수 있다.
• 되돌림에 승인이 없는 이유 — 결제 오류가 뜨는 14:35에 승인을 기다리면 그 사이 실패 건이 쌓인다. 되돌리는 건 담당이 바로 하고, 고치는 배포만 승인받는다.
• 잘못 보냈을 때 — 지우지 말고 그 글의 후속 「취소」로 "앞 글은 오발송입니다"를 보낸다. 웹훅으로 올라간 글은 회수가 안 되므로, 발송 버튼을 누르기 전 확인 창을 반드시 읽는다.
• 안 한 일을 했다고 쓰지 않는 이유 — 「스토어 100% 확인」이나 「실패 건 처리 완료」는 고정 문장이 아니라 눌러서 고르는 값이다. 안 누르면 "아직 확인 전"으로 나간다. 전사와 외부 협업자가 보는 글에 하지 않은 확인이 적히면 나중에 그 글이 근거가 된다.
• 고객·선주 안내에 회사의 약속을 기본값으로 안 넣는 이유 — 이중 결제 정리 같은 문장은 실제로 그 일을 하는 사람(서비스운영)이 있어야 지켜진다. 그래서 그 문장은 「예시 문장 채우기」로만 들어가고, 넣으면 「운영 할 일」이 비었는지 경고가 뜬다.
• 오류 제보를 여기서 안 받는 이유 — 제보와 재현 얘기는 모니터링_9월9일 론칭의 건 채널이 이미 하고 있다. 두 방에서 같은 얘기가 돌면 둘 다 안 읽힌다. 빌드·배포 로그도 여기 오지 않는다. 이 방은 고객 영향만 올린다.