주말에 뭘 올려야 하면 → 🚀긴급 배포 탭. 승인자·작업자·확인자 3명 + 롤백 방안 없으면 배포 금지
노란우산 앱 장애는 다릅니다 — 당일 배포 불가. 서버 우회 + 이용자 공지로 버팁니다
앱스토어 평점·리뷰도 점검 시각마다 확인 → ⭐앱 리뷰·안정화 탭
🗓️ 주말 전날 (금요일 또는 공휴일 전일)
여기서 준비가 끝나야 주말에 허둥대지 않습니다. 30분이면 됩니다.
1
당번 정하기한 주말에 6자리 — 1차 · 2차 · 배포 승인자 · 배포 작업자 · 배포 확인자 · 관리자
▶
1차 (지킴이) — 시간마다 점검하고 이상하면 알리는 사람. 직접 고치지 않아도 됩니다.
2차 (조치) — 실제로 원인 찾고 고치는 사람. 당번일에 전화를 반드시 받을 수 있어야 합니다.
관리자 — 2차가 못 풀 때 결정하는 사람.
🚀 긴급 배포 담당자 3역할 — 이 셋이 다 있어야 주말에 배포할 수 있습니다
배포 승인자 (PL / PM) — 배포해도 되는지 판단하고 승인하는 사람. 승인 없으면 배포 불가입니다. 롤백 방안을 확인한 뒤 승인합니다.
배포 작업자 — 백업하고 실제로 올리는 사람. 실패하면 롤백까지 이 사람이 합니다. 폐쇄망이라 현장에 있어야 합니다.
배포 확인자 — 올라간 게 정상인지 검증하는 사람. 배포 작업자와 반드시 다른 사람이어야 합니다. 혼자 올리고 혼자 확인하면 놓칩니다.
① 주말당번표⑩ 긴급·주말배포 → 1단계
💡 노란 칸만 채우면 됩니다. 한 사람에게 몰리지 않게 돌려가며 배정하세요. 배포 승인자는 PM·PL이 겸해도 됩니다.
2
연락처 채우기비어 있으면 주말에 전화할 곳이 없습니다
▶
역할별로 담당자 이름 + 연락처를 채웁니다. (PM · PL · 업무 · Front · Back · DB · Infra · 대외연계 · 배포 승인자 · 배포 작업자 · 배포 확인자 · 지원팀장 · 발주기관)
'대신할 사람'을 반드시 채우세요. 주 담당자가 전화를 안 받는 상황이 실제로 자주 생깁니다.
채운 뒤 각자에게 "주말에 연락 가능하신가요?" 한 번 확인하고, ①당번표의 비상연락 확인 칸에 기록합니다.
⑥ 비상연락망
💡 Dooray 대화방을 쓰기로 했으니, 'Dooray 기록안내' 시트 맨 위 '대화방 주소' 칸에 실제 대화방 이름·링크도 적어두면 좋습니다.
3
사전 점검 30항목 돌리기이게 진짜 핵심입니다
▶
서비스 / 시스템 / 연계 / 배치 / 변경사항 / 대응체계 / 리뷰 대응 — 7개 묶음 30항목에 O·△·X를 찍습니다.
맨 아래에서 X 건수가 자동으로 계산됩니다.
특히 챙길 것 → Rollback 버전 확보, DB Script 확보, 서버 접근권한. 이 셋이 없으면 주말에 장애가 나도 손을 못 씁니다.
⑨ 사전점검표
🚫 X가 1건이라도 있으면 주말에 들어가지 마세요. 먼저 해소하는 게 원칙입니다.
4
주말에 배포가 있나요?없으면 이 단계는 넘어가세요
▶
주말·공휴일 배포가 있을 때만 ⑩주말배포기준을 씁니다.
배포 전 7항목 (대상 확인 · 영향도 · Source Backup · DB Backup · Rollback 계획 · 테스트 결과 · 작업자 지정)
긴급 배포는 PL/PM 승인 후에만 수행합니다.
⑩ 긴급·주말배포
💡 롤백 방안이 없으면 배포하지 않습니다. 예외 없습니다. 자세한 절차는 🚀긴급 배포 탭을 보세요.
✅ 주말 당일 · 아무 일 없을 때
하루에 딱 3번, 시트 하나만 봅니다. 한 번에 10분쯤 걸립니다.
★
② 점검체크리스트 — 10:00 / 14:00 / 18:00이 시트가 주말 대응의 90%입니다
▶
날짜별로 블록이 하나씩 있습니다. 오늘 날짜 블록만 보면 됩니다.
점검 항목이 위에서 아래로 확인하기 쉬운 순서로 정렬돼 있습니다 — 서비스(모듈별) → 변경사항 → WEB/WAS → DB → 외부연계 → 배치 → 앱스토어.
'담당' 열에 모듈 담당자 이름이 이미 들어 있습니다. X가 나오면 그 사람에게 바로 연락하면 됩니다.
각 항목에 10:00 · 14:00 · 18:00 칸이 따로 있습니다. 해당 시각 칸을 클릭하면 O · △ · X 드롭다운이 나옵니다.
블록 맨 아래 X 건수는 자동 계산됩니다. 다 찍었으면 점검자 칸에 이름을 씁니다.
점검이 끝나면 이상이 없어도 Dooray 대화방에 [주말 점검 완료] 통본을 올립니다. "점검했다"는 기록이 남아야 합니다.
② 점검체크리스트
점검 대상 (모듈)
확인 내용
담당
노란우산(웹)
메인 URL 접속 · 로그인 · 주요 업무 1건 처리
노영주
노란우산(앱)
앱 실행 · 로그인 · 주요 화면 표시 · 푸시 수신
노영주
업무시스템
접속 · 로그인 · 주요 업무 조회/저장
정우진
제휴사
접속 · 제휴 연계 화면 정상
최윤서
자문위원포탈
접속 · 로그인 · 주요 화면 정상
권헌수
상담사/소방카
접속 · 상담 이력 조회 · 등록 정상
이지현
WEB / WAS
Process 기동 · WAS Instance 상태
곽종
Database
Slow Query · Tablespace 여유율
송국봉
외부연계
외부기관 API · 인증 / 문자 / 이메일
곽종
배치
주말 수행 배치 결과 · 실패 배치 재처리
—
앱스토어
평점 · 신규 리뷰 수 · 1점 비율 기록 (⭐앱 리뷰 탭)
리뷰 대응 담당
⚠️ 노란우산(앱)에서 X가 나오면 다르게 대응합니다. 앱은 스토어 심사 때문에 당일 고칠 수 없습니다 → 🚀긴급 배포 탭의 '모바일 앱' 부분을 보세요.
찍은 결과가 O가 아니면?
눌러서 확인하세요.
🚨 이상한 게 보인다 — 순서대로만 하세요
당황할 때 판단하려 하지 말고, 아래 순서를 그대로 따라가면 됩니다.
대원칙 — 원인 찾기보다 서비스 살리기가 먼저입니다.
"왜 이랬을까"는 서비스가 돌아온 다음에 봅니다. 재기동·롤백·기능 차단으로 먼저 살리세요.
1
알리기 (10분 안에)혼자 붙잡고 있지 마세요 — 가장 흔한 실수입니다
▶
Dooray 장애대응 대화방에만 올립니다. 전화·문자·개인 메신저로 흩어지면 상황 파악이 안 됩니다.
💬Dooray 기록 탭의 [장애 최초 보고] 통본을 복사해 붙이고 빈칸을 채웁니다. 9칸이라 1~2분이면 씁니다.
모르는 칸은 "확인 중"이라고 쓰고 일단 올리세요. 완벽하게 쓰려고 늦추는 게 더 나쁩니다.
Dooray 기록안내 → ①④ 시간대별대응
2
원인 찾기 — ③번 시트 순서대로위에서부터 훑으면 대부분 여기서 걸립니다
▶
① 서비스 — 접속 되나? 로그인 되나? API 응답 오나?
② 최근 변경사항 — 어제·오늘 배포한 게 있나? ← 실무에서 원인의 절반이 여기입니다
③ Application — Error 로그, Timeout, Connection Pool
④ WEB/WAS — 서버 떠 있나? CPU·메모리·디스크
⑤ Database — 접속, Lock/Deadlock, Slow Query
⑥ 외부 연계 — 외부기관 API, 인증, 문자
③ 장애분석순서
💡 위 단계에서 원인이 나오면 아래는 안 봐도 됩니다. 순서대로 훑는 게 요령입니다.
3
등급 정하고 연락하기등급에 따라 누구까지 부를지가 달라집니다
▶
아래 카드를 눌러 지금 상황에 해당하는 등급을 확인하세요.
⑥ 비상연락망⑤ 긴급지원방안참조
4
시간이 흐르면 — 10분 / 20분 / 30분④시간대별대응을 띄워두고 진행하세요
▶
10분 안 — 장애 여부 확인 · 영향 서비스 파악 · 담당자 호출 · 채널 공지 · 최근 배포 확인
20분 안 — 원인 범위 좁히기 · App/DB/Infra/Network 확인 · 등급 결정 · 발주기관 1차 보고 · 복구 방안 결정
30분 넘어가면 — 가장 빨리 살릴 수 있는 방법을 고릅니다: 롤백 · 재기동 · 기능 임시 차단 · 이전 버전 전환 · 우회 서비스
④ 시간대별대응
💡 폐쇄망이라 그 방법을 실제로 수행할 사람이 현장에 있는지 먼저 확인해야 합니다.
5
기록하기 — Dooray에 실시간으로기억으로 남기지 마세요
▶
조치할 때마다 Dooray 대화방에 그때그때 올립니다. 끝나고 몰아서 쓰면 시각이 빠지고 순서가 틀어집니다.
누구에게 · 몇 시에 연락했는지를 반드시 남기세요. 나중에 "누가 언제 알렸냐"로 문제가 되는 부분입니다.
운영환경을 건드렸다면(재기동·설정 변경·배포·롤백) 무엇을 · 몇 시에 바꿨는지 남깁니다.
복구되면 [장애 복구 보고] 통본을 올립니다.
엑셀 ⑦장애대장은 주말이 끝난 뒤 Dooray 내용을 옮겨 정리하는 용도입니다. 장애 중에 엑셀을 붙잡고 있지 마세요.
Dooray 기록안내⑦ 장애대장 (주말 종료 후)
🚀 긴급 배포 방법 (주말 · 공휴일)
장애를 고치려고 주말에 무언가를 올려야 할 때. 승인 → 준비 → 배포 → 확인 → 모니터링 순서를 건너뛰지 마세요.
절대 원칙 3가지
① 롤백 방안이 없으면 배포하지 않습니다. 예외 없습니다.
② 긴급 배포는 배포 승인자(PL / PM) 승인 후에만 수행합니다. 혼자 판단해서 올리지 않습니다.
③ 폐쇄망이라 배포 작업자가 현장에 있어야 합니다. 없으면 배포는 선택지가 아닙니다.
④ 모바일 앱은 위 규칙이 적용되지 않습니다. 스토어 심사 때문에 당일 배포가 아예 불가능합니다 → 아래 ★ 단계.
💡 주말 배포는 장애를 고치려다 더 큰 장애를 만드는 가장 흔한 경로입니다.
"지금 꼭 올려야 하나?"를 먼저 물어보세요. 월요일까지 버틸 수 있으면 버티는 게 낫습니다.
0단계 · 배포가 정말 답인가?
지금 상황에 맞는 카드를 눌러보세요. 배포보다 나은 방법이 있을 수 있습니다.
긴급 배포를 하기로 정했다면
아래 단계를 눌러 펼치고, 체크박스를 눌러가며 진행하세요.
1
담당자 3역할이 다 있는지 확인한 자리라도 비면 배포하지 않습니다
▶
🚀 긴급 배포 담당자 — 승인 · 작업 · 확인을 나눕니다
배포 승인자 (PL / PM)
배포가 정말 필요한지 판단 · 롤백 방안 확인 후 승인 · Critical·Major 시 발주기관 공유 결정 → 이 사람 승인 없이는 배포 자체가 불가입니다.
배포 작업자
Source Backup / DB Backup · 배포 실제 수행 · 실패 시 Rollback 수행 → 폐쇄망이라 현장에 있어야 합니다. 없으면 배포는 선택지가 아닙니다.
배포 확인자
배포 결과 확인 · Smoke Test · API/DB/Error Log 확인 · 정상 여부 최종 보고 → 배포 작업자와 반드시 다른 사람. 혼자 올리고 혼자 확인하지 않습니다.
⑩ 긴급·주말배포 → 1단계① 주말당번표⑥ 비상연락망
🚫 세 자리 중 하나라도 비어 있거나 연락이 안 되면 배포하지 않습니다. 기능 임시 차단으로 버티고 월요일에 정식 절차로 올립니다.
2
승인 받기승인 없는 긴급 배포는 사고입니다
▶
배포 승인자(PL / PM, 3단계) 승인을 받습니다. 구두 승인이라도 누가 · 몇 시에 승인했는지 Dooray 대화방에 남깁니다.
승인 요청 시 이 4가지를 같이 전달합니다 → 왜 지금 올려야 하는지 · 무엇을 바꾸는지 · 영향 범위 · 실패하면 어떻게 되돌리는지
Critical / Major 장애면 PM·PL이 복구 방안을 결정하고 발주기관에도 상황을 공유합니다.
승인 직후 Dooray 대화방에 [긴급 배포 알림] 통본을 올립니다. (💬Dooray 기록 탭에 복사 버튼 있음)
⑩ 긴급·주말배포 → 3단계Dooray 기록안내 → ②
🚫 승인이 안 나면 배포하지 않습니다. 기능 임시 차단이나 우회로 버티고 월요일에 정식 절차로 올립니다.
3
배포 전 준비 7항목하나라도 빠지면 되돌릴 수 없게 됩니다
▶
눌러서 체크하며 진행하세요.
배포 대상 확인
영향도 분석
Source Backup
DB Backup
Rollback 계획 작성
테스트 결과 확인
작업자 및 확인자 지정
⑩ 긴급·주말배포 → 4단계
💡 Rollback 계획과 DB Backup이 이 중 가장 중요합니다. 이 둘이 없으면 실패했을 때 돌아갈 곳이 없습니다.
4
배포 실행시각을 반드시 기록하면서
▶
배포 시작 시각을 Dooray 대화방에 먼저 알립니다. ("지금부터 OO 배포 시작합니다")
순서는 보통 → 서비스 차단(필요 시) → DB 스크립트 → 소스 배포 → 재기동 → 차단 해제
운영환경을 바꿀 때마다 무엇을 · 몇 시에 바꿨는지 그때그때 기록합니다. 나중에 몰아서 쓰면 빠집니다.
⑩주말배포기준의 수행 시각 · 수행자 칸을 채웁니다.
⑩ 긴급·주말배포 → 5단계Dooray 기록안내
🚫 배포 도중 예상과 다른 게 나오면 진행하지 말고 멈춥니다. 밀어붙이는 것보다 롤백이 낫습니다.
5
배포 후 확인 5항목"올라갔다"와 "정상이다"는 다릅니다
▶
눌러서 체크하며 진행하세요.
배포 결과 확인
주요 서비스 Smoke Test
API 정상 확인
DB 정상 확인
Error Log 확인
⑩ 긴급·주말배포 → 6단계
💡 고친 기능은 정상 케이스 + 비정상 케이스를 둘 다 테스트합니다. 정상만 확인하면 반쪽입니다.
6
집중 모니터링 6항목배포 직후가 가장 위험한 구간입니다
▶
신규 / 변경 기능 — 이번에 손댄 부분
로그인 / 인증 — 공통 모듈이라 엉뚱하게 같이 깨지는 곳
DB Connection — 재기동 후 Pool이 제대로 잡혔는지
API — 응답시간과 에러율
외부연계 — 외부기관 전문 송수신
Error Log — 배포 전에 없던 새 Error
⑩ 긴급·주말배포 → 6단계② 점검체크리스트
💡 다음 점검 시각(10시 / 14시 / 18시)에 ②점검체크리스트를 평소보다 꼼꼼히 돌립니다. 배포한 날은 △도 그냥 넘기지 마세요.
★
모바일 앱(노란우산 앱)은 절차가 다릅니다서버처럼 당일 배포할 수 없습니다 — 앱 장애면 여기부터
▶
왜 다른가
① 앱 수정본은 App Store / Google Play 심사를 거쳐야 하므로 주말 당일 반영이 불가능합니다.
② 이미 설치된 앱은 되돌릴 수 없습니다. 사용자 단말의 앱 버전을 강제로 내릴 수단이 없습니다.
→ 주말 앱 장애는 "앱을 고친다"가 아니라 "서버에서 우회한다 + 이용자에게 알린다"로 대응합니다.
📱 주말에 할 일 — 1 · 2 · 3번
1. 범위 확인
앱만 문제인가, 서버(API)도 문제인가 — 노란우산 웹이 정상인지 대조하면 금방 갈립니다.
영향 OS / 앱 버전 특정 (iOS · Android · 특정 버전만인지) · 영향 이용자 규모 추정
2. 서버사이드 우회 ← 앱 배포보다 항상 먼저
서버 API 응답·설정 변경으로 우회 가능한지 · 문제 기능을 서버에서 비활성/메뉴 숨김 가능한지 노란우산 웹으로 우회 안내가 가능한지 업무 담당과 확인 → 우회 적용은 위 3~6단계(서버 배포 절차)를 따릅니다.
3. 이용자 공지
앱 내 공지/팝업 또는 홈페이지 공지 게시 여부를 업무 담당·발주기관과 협의 · 공지 문구에 "언제까지" 우회해야 하는지 포함
고객센터·상담사에 응대 지침 전달
🗓️ 영업일에 할 일 — 4번 (주말에 하지 않습니다)
앱 수정 및 내부 테스트 (영향 OS·버전 모두)
스토어 심사 제출 — 심사 소요 시간 확인 (통상 1~3영업일, 반려되면 추가)
긴급 심사(Expedited Review) 요청이 필요한지 판단 — 사유 기재
강제 업데이트 적용 여부 결정 — 구버전 접속 차단 기준과 안내 문구
배포 후 구버전 이용자 비율 모니터링
⑩ 긴급·주말배포 → ★ 모바일 앱Dooray 기록안내 → ③ 모바일 앱 장애 대응
💡 스토어 계정·심사 담당자는 ⑥비상연락망의 '앱 스토어 배포' 행에 미리 채워두세요. 주말에 계정 접근이 안 되면 아무것도 못 합니다.
7
배포했는데 더 나빠졌다면망설이지 말고 되돌리세요
▶
원인 분석하지 말고 먼저 롤백합니다. 서비스 정상화가 원인 규명보다 우선입니다.
2단계에서 적어둔 Rollback 계획을 그대로 실행합니다. 즉흥적으로 하지 않습니다.
DB 스크립트를 올렸다면 DB도 같이 되돌려야 하는지 반드시 확인합니다. 소스만 되돌리면 정합성이 깨집니다.
롤백 완료 후 4단계 확인 5항목을 처음부터 다시 돌립니다.
Dooray 대화방에 롤백 사실과 시각을 알립니다. 조용히 되돌리지 않습니다.
⑩ 긴급·주말배포 → 7단계③ 장애분석순서 → 복구 방법
8
기록 남기기주말에 운영을 건드렸다는 사실 자체가 기록 대상입니다
▶
Dooray 대화방에 배포 완료(또는 롤백) 결과를 배포 확인자가 보고합니다.
⑩긴급·주말배포의 수행 시각 · 수행자 · 비고를 마무리합니다. 미완료 항목 수가 0이 되어야 완료입니다.
주말 종료 후 ⑦장애대장의 조치 내용에 "핫픽스 배포" 또는 "롤백"과 시각을 옮겨 적습니다.
Critical / Major였다면 ⑧장애보고서양식 3번 사후 장애보고서에 배포 내역을 타임라인으로 옮깁니다.
재발방지에 "왜 주말에 긴급 배포까지 가게 됐는지"를 적습니다. 이게 다음번을 줄여줍니다.
Dooray 기록안내⑩ 긴급·주말배포 → 8단계⑧ 장애보고서양식
💬 Dooray 대화방 기록 — 복사해서 붙이세요
장애 기록·보고의 1차 창구는 Dooray 장애대응 대화방입니다. 엑셀 ⑦·⑧ 시트는 주말이 끝난 뒤 정리·제출용 보조 문서입니다.
💡 기록 원칙 4가지
① 장애 인지 · 상황 공유 · 조치 내역 · 복구 보고는 모두 Dooray 대화방에. 전화·개인 메신저로 분산시키지 않습니다.
② 그때그때 올립니다. 끝나고 몰아서 쓰면 시각이 빠지고 순서가 틀어집니다.
③ 운영환경을 건드릴 때(재기동·설정 변경·배포·롤백)는 무엇을 · 몇 시에 했는지 반드시 남깁니다.
④ 엑셀 ⑦장애대장은 주말 종료 후 Dooray 내용을 옮겨 이력 정리 및 보고서 제출용으로 씁니다.
① 장애 최초 보고장애 인지 즉시 (10분 이내)
[장애 최초 보고]
· 발생일시 :
· 인지일시 :
· 대상 시스템 :
· 장애 서비스 :
· 장애 현상 :
· 사용자 영향 :
· 최초 확인 내용 :
· 현재 조치 :
· 담당자 :
승인자 · Rollback 방안 · 백업 여부가 비어 있으면 배포하지 않습니다. 이 세 칸이 핵심입니다.
③ 모바일 앱 장애 대응 알림노란우산 앱 장애 시 (앱은 당일 배포 불가)
[모바일 앱 장애 대응]
· 장애 현상 :
· 영향 OS / 앱 버전 :
· 영향 이용자 규모 :
· 웹(노란우산 웹) 정상 여부 : 정상 / 이상
· 서버사이드 우회 : 적용 / 검토중 / 불가
· 우회 내용 :
· 이용자 공지 : 게시 / 검토중 / 불필요
· 상담사 응대 지침 전달 : 완료 / 미완료
· 앱 수정 정식 배포 예정 :
· 스토어 심사 제출 예정일 :
· 강제 업데이트 여부 : 적용 / 미적용
앱은 스토어 심사 때문에 주말 당일 반영이 불가합니다. '서버 우회 + 공지'가 주말 대응의 실체입니다.
④ 장애 복구 보고서비스 정상화 확인 후
[장애 복구 보고]
· 장애명 :
· 장애 발생 :
· 장애 복구 :
· 장애 시간 : 분
· 장애 영향 :
· 장애 원인 :
· 조치 내용 :
· 현재 상태 : 정상 / 부분 정상 / 모니터링 중
· 추가 조치 :
참조 시트의 '장애 종료 판단 6조건'을 모두 충족한 뒤 올립니다. PM/PL이 최종 확인합니다.
⑤ 주말 점검 완료10:00 / 14:00 / 18:00 각 점검 후
[주말 점검 완료]
· 점검일시 : (10:00 / 14:00 / 18:00)
· 점검자 :
· 결과 : 정상 / 이상 / 미점검
· X 건수 :
· △ 항목 및 현상 :
· 조치 필요 사항 :
이상이 없어도 올립니다. '점검했다'는 기록이 남아야 합니다.
⚠️ Dooray 보고와 별개로, Critical / Major 장애는 복구 후 ⑧장애보고서양식의 사후 장애보고서를 작성해 제출해야 합니다. Dooray 기록만으로는 대체되지 않습니다.
⭐ 앱스토어 리뷰(악성 댓글) 대응 · 안정화 방향
시스템 장애는 아니지만 방치하면 평점·설치수에 바로 영향이 갑니다. 그래서 주말 점검 항목에 넣습니다.
가장 위험한 오판 — 진짜 장애를 "댓글부대"로 단정하는 것입니다.
리뷰에 장애 언급이 나오면 먼저 서버 로그·모니터링으로 실제 장애인지 확인한 뒤 분류하세요. 애매하면 장애로 취급합니다.
1
점검 시각마다 딱 3가지만 본다10:00 / 14:00 / 18:00 — ②점검체크리스트 마지막 줄
▶
확인 항목
어디서
이러면 아래 2번으로
평균 평점
App Store / Google Play 앱 페이지
전일 대비 0.3 이상 하락
1점 리뷰 몰림
스토어 콘솔 리뷰 목록
신규 리뷰의 절반 이상이 1점
같은 문구 반복
리뷰 본문 비교
유사 문구 3건 이상
⑫ 안정화방향·리뷰대응 → B② 점검체크리스트 → ⑦앱스토어
💡 임계치는 오픈 초기 실측값을 보고 조정하세요. 처음 1~2주 숫자를 적어두면 "평상시"가 얼마인지 알 수 있습니다.
2. 어떤 리뷰인지 먼저 가른다
분류에 따라 대응이 완전히 달라집니다. 눌러서 확인하세요.
3
③ 조직적 악성으로 판단했다면 — 주말엔 이 4가지만신고와 공유가 핵심. 논쟁이 아닙니다
▶
1. 증거 보전 — 화면 캡처
2. 내부 공유 — Dooray + PM/PL 보고
3. 스토어 신고 — 양쪽 스토어 모두
4. 재확인 — 다음 점검 시각에
💡 여기까지가 주말에 할 일 전부입니다. 답변 게시는 급할 때만 선택(아래 4번), 법적 검토·홍보 협의는 영업일에 PM/PL과 결정합니다.
⑫ 안정화방향·리뷰대응 → DDooray 기록안내 → ④
4
답변 문구 — 3가지 중에서 고른다직접 쓰지 마세요. 골라 쓰는 게 안전합니다
▶
① 실제 장애 (복구 완료)장애가 있었고 복구가 끝난 경우
불편을 드려 죄송합니다. 말씀해 주신 현상은 확인 후 조치를 완료했습니다.
앱을 최신 버전으로 업데이트하신 뒤 다시 이용해 주시기 바랍니다.
계속 같은 현상이 발생하면 고객센터로 알려주시면 확인하겠습니다.
사실만 씁니다. 원인이나 내부 사정은 쓰지 않습니다.
② 실제 장애 (조치 중)확인됐고 아직 복구 전인 경우
불편을 드려 죄송합니다. 말씀해 주신 현상을 확인하여 조치 중입니다.
조치가 완료되면 앱 공지로 안내드리겠습니다.
급한 업무는 홈페이지에서도 이용하실 수 있습니다.
복구 예정 시각을 약속하지 않습니다.
③ 그 외 모든 경우재현 안 됨 · 사실과 다름 · 기능 요청
말씀해 주신 내용을 확인해 보겠습니다.
사용하시는 기기와 앱 버전, 발생 시각을 고객센터로 알려주시면 자세히 확인하겠습니다.
반박·해명·약속을 하지 않습니다. 논쟁하지 않고 고객센터로 안내합니다.
⑫ 안정화방향·리뷰대응 → E
5
절대 하지 말 것하면 앱이 스토어에서 내려갈 수 있습니다
▶
🚫 이건 악성 리뷰보다 피해가 큽니다
긍정 리뷰를 직접 쓰거나 요청·대가 제공하지 않습니다.
Apple·Google 정책 위반입니다. 앱 삭제·개발자 계정 정지 사유이고, 발각되면 피해가 악성 리뷰보다 훨씬 큽니다.
리뷰어와 논쟁하지 않습니다. 답변은 1회로 종료. 반박·해명·특정인 지목·법적 조치 언급도 금지 — 대외 대응은 발주기관 판단 사항입니다.
실제 장애를 "악성 리뷰"로 단정하지 않습니다. 서버 로그·모니터링으로 확인한 뒤 분류합니다. 평점 방어용 무리한 앱 배포도 금지 (앱 배포는 🚀긴급 배포 탭 ★ 절차).
⑫ 안정화방향·리뷰대응 → F
6. 안정화 방향 — 구간별로 강도를 낮춰간다
계속 하루 3회를 유지하는 게 아니라, 조건을 채우면 다음 구간으로 넘어갑니다.
1구간 · 집중 대응
오픈 ~ 2주차 (주말 1·2주차)
시스템: 주말 1일 3회 + 평일 상시
리뷰: 1일 2회 (오전·오후)
보고: 일일
넘어갈 조건 : Critical/Major 0건 · 평점 하락 진정
2구간 · 안정화
3주차 ~ 4주차 (주말 3주차)
시스템: 주말 1일 3회 유지 (항목 축소 가능)
리뷰: 1일 1회
보고: 주 2회
넘어갈 조건 : 2주 연속 Major 이상 0건
3구간 · 정상 운영 전환
5주차 이후
시스템: 주말 1일 1~2회 또는 운영 이관
리뷰: 주 2~3회
보고: 주 1회
완료 조건 : 운영 조직 인수인계 완료
💡 구간 전환은 PM / PL이 판단합니다. 조건을 못 채우면 그 구간을 연장합니다.
🎯 안정화 기간 중점 관리 4가지
실제 장애 감소 — 같은 장애가 2회 이상 반복되면 재발방지 대책을 문서화합니다.
이용자 체감 개선 — 리뷰·고객센터에서 반복되는 불만은 장애가 아니어도 개선 과제로 등록합니다.
앱 내 피드백 창구 확보 — 앱 안에서 문의할 곳이 없으면 불만이 스토어 리뷰로 갑니다. 문의 경로를 앱 내에 노출하는 것이 가장 효과적인 리뷰 대책입니다.
운영 조직 이관 준비 — 점검 항목·연락망·절차를 운영 조직이 그대로 쓸 수 있게 유지합니다.
★ 하루 3번 여는 시트. 모듈 14항목(앱스토어 평점 포함) O·△·X + 담당자 이름 포함 + 점검자 서명
③ 장애분석순서
장애 시
원인을 어느 순서로 찾을지. ①서비스 → ⑥외부연계
④ 시간대별대응
장애 시
10분 / 20분 / 30분 시점에 뭘 할지 + 완료 체크
⑤ 긴급지원방안
연락 · 보고
4시간 이내 지원체계 3단계. 1차 → 2차 → 관리자
⑥ 비상연락망
연락 · 보고
역할 20개 — 모듈별(노란우산 웹/앱 · 업무시스템 · 제휴사 · 자문위원포탈 · 상담사/소방카) + DB · Infra · 대외연계 + 배포 3역할 + 앱 스토어 배포 · 리뷰 대응 담당 · 고객센터
Dooray 기록안내
Dooray 기록
★ 모든 장애 기록의 1차 창구. 복사해서 바로 붙일 통본 6종 (최초보고 · 긴급배포알림 · 모바일 앱 장애 대응 · 스토어 리뷰 이슈 · 복구보고 · 점검완료)
⑦ 장애대장
보조
1차 기록은 Dooray. 주말 종료 후 Dooray 내용을 옮겨 이력 정리 + 등급별 자동 집계
⑧ 장애보고서양식
보조
항목 누락 확인용. 사후 장애보고서(11항목)는 이 시트로 작성해 제출
⑨ 사전점검표
주말 전날
30항목 × 3주. X 1건이라도 있으면 주말 진입 금지. 앱 최신·직전버전 · 스토어 심사중 건 · 스토어 콘솔 로그인 · 표준답변 포함
⑩ 긴급·주말배포
배포
주말에 뭘 올려야 할 때. 담당자 3역할 지정 → 방법 판단 → 승인 → 배포 전/후 → 롤백 → 기록 8단계 + ★ 모바일 앱 별도 절차
⑫ 안정화방향·리뷰대응
리뷰·안정화
★ 오픈 후 주차별 안정화 로드맵 + 앱스토어 악성 리뷰(댓글부대) 대응. 리뷰 확인 3가지 · 리뷰 3분류 · 대응 4단계 · 표준답변 3종 · 금지 3가지
⑪ 대응조직·역할
참고용
누가 무엇을 확인하는지. 역할 중복·공백 방지 (배포 3역할 포함)
참조
참고용
등급 기준 · 연락 순서 · 종료 판단 6조건 · 대응 Flow
💡 노란 칸 = 채우는 칸 (파란 글씨로 입력) · 초록 줄 = 작성 예시 · 회색 글씨 = 안내문, 안 채워도 됩니다.
💡 엑셀 탭 색으로도 구분됩니다 — 빨강 = 매 주말 필수 · 하늘색 = Dooray 기록 · 보라 = 배포 · 초록 = 주말 전날 · 회색 = 보조·참고
❓ 자주 막히는 것
눌러서 펼쳐 보세요.
노란 칸을 다 채워야 하나요?
아니요. 지금 필요한 것만 채우세요. ①당번표 · ⑥비상연락망 · ②점검체크리스트의 모듈명 — 이 셋만 채우면 주말 운영이 됩니다. 나머지는 그 상황이 생겼을 때 채우면 됩니다.
②점검체크리스트의 '점검 대상'이 우리 모듈명이 아닌데요?
노란 칸이라 덮어써도 되는 예시입니다. 실제 모듈명으로 바꿔 쓰세요. 회색으로 적힌 '조회/확인 항목'은 매뉴얼 기준이라 그대로 두셔도 됩니다. 항목 수가 모듈 수와 안 맞으면 행을 삽입하거나 삭제해서 조정하세요.
O · △ · X를 직접 타이핑해야 하나요?
아니요. 그 칸을 클릭하면 드롭다운 화살표가 나옵니다. 골라서 선택하세요. △는 특수문자라 직접 입력하기 번거로우니 드롭다운을 쓰는 게 편합니다.
△인데 그냥 넘어가도 되나요?
넘어가도 되지만 비고 칸에 현상을 적어두세요. △는 "곧 X가 될 수 있다"는 신호를 잡기 위해 만든 단계입니다. 다음 점검 시각에 다시 확인해서 나빠지면 X로 올립니다.
장애 기록은 엑셀에 하나요, Dooray에 하나요?
장애가 진행되는 동안은 Dooray 대화방에만 기록합니다. 급할 때 엑셀을 열어 붙잡고 있으면 기록이 늦어집니다. 엑셀 ⑦장애대장은 주말이 끝난 뒤 Dooray 내용을 옮겨 이력을 정리하고 보고서를 제출하는 용도입니다. 통본은 💬Dooray 기록 탭에서 복사 버튼으로 가져가세요.
Dooray에 올렸으면 사후보고서는 안 써도 되나요?
아니요. Critical / Major 장애는 Dooray 기록과 별개로 ⑧장애보고서양식의 사후 장애보고서(11항목)를 작성해 제출해야 합니다. Dooray는 실시간 기록, 사후보고서는 제출 문서라 역할이 다릅니다.
긴급 배포 담당자가 왜 3명이나 필요한가요?
역할이 다르기 때문입니다. 승인자는 올려도 되는지 결정하고, 작업자는 실제로 올리고, 확인자는 올라간 게 정상인지 검증합니다. 특히 작업자와 확인자를 나누는 이유는 올린 사람은 자기 작업을 정상이라고 보기 쉬워서입니다. 매뉴얼 16장의 '작업자 및 확인자 지정' 기준이기도 합니다. 한 사람이 두 역할을 겸하면 안 되는 건 작업자·확인자 조합이고, 승인자는 PM·PL이 겸해도 됩니다.
X 하나 나왔는데 어디까지 연락해야 하나요?
먼저 2차(조치) 담당에게 연락합니다. 15~30분 안에 안 풀리면 관리자 / 지원팀장으로 올립니다. Critical이나 Major면 PM·PL이 바로 판단하고 발주기관에도 공유합니다. 판단이 애매하면 더 높은 등급으로 처리하는 편이 안전합니다.
X 건수 칸이 0인데 어떻게 바꾸나요?
건드리지 마세요. 자동 계산되는 칸입니다. 위쪽 점검 칸에 X를 넣으면 숫자가 알아서 올라갑니다.
Dooray 대화방은 어디에 적어두나요?
엑셀 'Dooray 기록안내' 시트 맨 위 '대화방 주소' 칸(노란색)에 실제 대화방 이름이나 링크를 적어두세요. 주말 당번이 바뀌어도 어디에 올려야 하는지 헷갈리지 않습니다.
당번표 날짜가 우리 일정과 다른데요?
8/8 주말부터 3주로 넣어둔 값입니다. 날짜 칸을 직접 수정하세요. ②점검체크리스트의 블록 제목과 ⑨사전점검표의 머리글 날짜도 같이 맞춰주면 좋습니다.
앱스토어에 1점 리뷰가 갑자기 쏟아져요. 어떻게 하나요?
먼저 진짜 장애인지 확인하세요. 리뷰에 적힌 증상을 실제로 재현해 보고 서버 로그·모니터링을 봅니다. 장애면 리뷰 대응이 아니라 장애 대응입니다. 장애가 아니고 짧은 시간에 1점 집중 + 문구가 서로 유사 + 이용 흔적 없는 내용이면 조직적 악성으로 보고 증거 캡처 → 스토어 신고 → Dooray·PM/PL·발주기관 공유 순으로 갑니다. ⭐앱 리뷰·안정화 탭에서 카드를 눌러 확인하세요.
우리 쪽에서 좋은 리뷰를 좀 써서 평점을 올리면 안 되나요?
절대 안 됩니다. Apple·Google 정책 위반이고 앱 삭제·개발자 계정 정지 사유입니다. 발각되면 피해가 악성 리뷰보다 훨씬 큽니다. 리뷰 대가로 경품·포인트를 주는 것도 같은 위반입니다. 평점을 지키는 정당한 방법은 실제 불만 원인을 개선하는 것과 앱 안에 문의 창구를 만들어 불만이 스토어로 가지 않게 하는 것입니다.
리뷰에 답글을 달았는데 또 반박 리뷰가 올라와요.
더 답하지 마세요. 1회 답변 후 종료가 원칙입니다. 반복 답변·해명은 상황을 키우고, 다른 이용자에게도 논쟁으로 보입니다. 계속 올라오면 답글 대신 스토어 신고 + 내부 공유로 처리하고, 대외 대응은 발주기관 판단에 맡기세요.
하루 3회 점검을 3주 내내 해야 하나요?
아니요. ⑫시트에 구간별 안정화 로드맵이 있습니다. 1구간(오픈~2주차)은 하루 3회, 2구간(3~4주차)은 하루 3회 유지하되 항목 축소 가능, 3구간(5주차 이후)은 하루 1~2회 또는 운영 조직 이관입니다. 구간 전환은 조건을 채웠을 때 PM/PL이 판단합니다.
노란우산 앱에 장애가 났어요. 앱을 고쳐서 올리면 되나요?
주말에는 안 됩니다. 앱 수정본은 App Store / Google Play 심사(통상 1~3영업일)를 거쳐야 하고, 이미 설치된 앱은 되돌릴 수도 없습니다. 주말에 할 일은 ① 범위 확인(웹은 정상인지 대조) ② 서버사이드 우회 ③ 이용자 공지 세 가지뿐입니다. 앱 수정·스토어 제출·강제 업데이트는 영업일에 정식 절차로 합니다. 🚀긴급 배포 탭의 ★ 단계를 보세요.
앱이 안 되는데 서버 문제인지 앱 문제인지 어떻게 구분하나요?
노란우산 웹으로 같은 기능을 해보세요. 웹도 안 되면 서버(API)·DB 문제이고, 그건 롤백·재기동·핫픽스로 풉니다. 웹은 되는데 앱만 안 되면 앱 쪽 문제이므로 ★ 모바일 앱 절차로 갑니다. 영향 OS와 앱 버전(iOS만? 특정 버전만?)도 같이 확인하세요.
주말에 급한데 승인 받을 사람이 전화를 안 받아요.
그러면 배포하지 않습니다. ⑥비상연락망의 '대신할 사람'으로 넘어가고, 그래도 안 되면 관리자 / 지원팀장으로 올립니다. 승인을 못 받는 동안은 기능 임시 차단이나 우회로 버티는 것이 정답입니다. 승인 없는 긴급 배포는 문제가 안 생겨도 문제가 됩니다.
롤백이랑 핫픽스 중에 뭘 골라야 하나요?
배포 직후에 장애가 났다면 무조건 롤백이 먼저입니다. 원인을 찾아 고치는 건 서비스가 돌아온 다음 일입니다. 핫픽스는 롤백·재기동·기능차단으로 안 되고 코드를 고쳐야만 풀릴 때만 씁니다. '긴급 배포' 탭의 0단계 카드를 눌러보세요.
배포했는데 더 나빠졌어요.
원인 분석하지 말고 바로 롤백합니다. 배포 전에 적어둔 Rollback 계획을 그대로 실행하세요. DB 스크립트를 올렸다면 DB도 같이 되돌려야 하는지 반드시 확인해야 합니다. 되돌린 뒤 확인 5항목을 처음부터 다시 돌리고, 롤백 사실과 시각을 채널에 알립니다.
이 문서는 누가 관리하나요?
유지관리(운영) 담당 조직이 소유·유지합니다. 담당자 이름과 모듈 정보는 그 조직에서 채워 관리합니다. 틀만 잡아둔 문서이므로, 채우고 굴리는 주체는 운영 조직입니다.
폐쇄망이라는 게 왜 계속 나오나요?
원격 접속이 안 되기 때문입니다. 즉 고칠 수 있는 사람이 현장에 없으면 아무것도 못 합니다. 그래서 당번을 짤 때 배포 권한자를 반드시 포함시키고, 사전점검에서 서버 접근권한을 확인하는 겁니다.