서비스 장애 대응 매뉴얼: 감지부터 고객 보상까지

코드를 고치는 것보다 먼저 해야 할 일이 있다.

한 줄 요약

장애 대응의 순서는 영향도 파악 → CS 안내 → 고객 보상 결정 → 복구다. 원인 분석은 그다음이다. 이 글은 실제 장애 회고에서 나온 지적을 바탕으로, 각 단계에서 무엇을 기록하고 무엇을 결정해야 하는지 정리한다.

---

1. 장애 대응이란

장애 대응(Incident Response)은 이상을 감지한 순간부터 복구와 재발 방지까지를 관리하는 활동이다.

Google SRE 문서와 ITIL이 공통으로 강조하는 원칙은 세 가지다.

 

하나. 역할을 나눈다.
지휘자, 기술 조치자, 커뮤니케이션 담당자를 분리한다. 한 사람이 세 역할을 겸하면 반드시 하나는 빠진다.

 

둘. 영향도가 원인보다 먼저다.
누가 몇 명이나 피해를 보고 있는지 모르면, 어떤 속도로 대응해야 할지도 알 수 없다.

 

셋. 시각을 남긴다.
기록되지 않은 시점은 나중에 복원할 수 없다.

 

용어 정리

용어	뜻
SRE	서비스 안정성을 공학적으로 관리하는 방법론
Incident Commander	장애 상황의 의사결정을 총괄하는 단일 책임자
MTTD	장애 발생부터 감지까지 걸린 평균 시간
MTTR	감지부터 복구까지 걸린 평균 시간

 

왜 중요한가

고객의 신뢰는 장애 유무가 아니라 대응 속도와 안내 품질로 갈린다.

복구가 늦어도 상황을 제때 안내받은 고객과, 아무 연락 없이 보름을 기다린 고객이 회사를 보는 눈은 전혀 다르다.

---

2. 응급실과 같은 구조

장애 대응은 응급실 절차와 구조가 같다.

응급실	장애 대응
환자 분류(Triage)	심각도 등급 판정
담당 의사 지정	Incident Commander 지정
보호자 안내	고객·CS팀 공지
응급 처치	롤백, 우회 조치
정밀 검사	근본 원인 분석

응급실에서 환자가 몇 명인지 세지 않고 수술방부터 들어가는 경우는 없다.

몇 명이 피해를 보고 있는지 모른 채 코드부터 여는 것은 순서가 뒤집힌 것이다.

---

3. 타임라인 기록

장애 보고서의 뼈대는 시간이다. 다음 일곱 개 시각을 빠짐없이 남긴다.

시각	기준
장애 발생	실제 문제가 시작된 시점 (로그 기준)
유입 버전 배포	문제를 유발한 릴리즈의 배포 일시
최초 인지	알람 발생 또는 첫 고객 문의 접수
최초 보고	담당자가 조직에 알린 시점
대응 착수	실제 조치를 시작한 시점
고객 안내	공지 또는 개별 안내를 발송한 시점
복구 완료	정상 동작이 확인된 시점

이 중 두 구간을 따로 계산한다.

• 감지 지연 = 발생 → 인지
• 보고 지연 = 인지 → 보고

두 값이 크다면 원인은 개발자 역량이 아니라 모니터링과 보고 체계에 있다.

---

4. 영향도 파악 (최우선)

코드를 열기 전에 아래를 확정한다.

피해 규모

숫자로 답할 수 있어야 한다.

• 영향받은 고객 수 — 전체 대비 비율까지
• 영향받은 건수 — 실패한 요청·주문·결제
• 금전 손실 추정액 — 매출 손실 + 환불 + 보상 비용
• 누적 장애 시간 — 최초 발생부터 복구 완료까지 실제 서비스 불능 시간

 

재현 조건

구분	확인 항목
앱	발생 버전, OS 종류·버전, 기기
웹	브라우저 종류·버전
서버	배포 버전, 특정 리전·인스턴스 한정 여부
사용자	요금제, 권한, 데이터 조건 한정 여부

가장 먼저 답해야 할 질문은 하나다.

전체 고객인가, 특정 조건의 일부인가?

이 답에 따라 심각도 등급과 투입 인력이 결정된다.

심각도 등급 (예시)

등급	기준	대응
P1	전체 중단, 결제·데이터 손실	즉시 전원 투입, 경영진 즉시 보고
P2	핵심 기능 장애, 다수 고객 영향	담당팀 즉시 투입, 1시간 내 보고
P3	일부 기능 이상, 우회 가능	정규 프로세스 처리

기준은 조직마다 다르다. 장애가 나기 전에 문서로 합의해 둔다.

---

5. CS팀에 넘길 문서

개발팀이 원인을 찾는 동안, CS팀은 이미 전화를 받고 있다. CS팀용 문서는 별도로 준비한다.

담아야 할 여섯 가지

1. 현상 요약 — 고객 입장에서 무엇이 안 되는지, 기술 용어 없이
2. 영향 대상 — 어떤 조건의 고객이 해당되는지
3. 임시 우회 방법 — 고객이 지금 할 수 있는 조치
4. 예상 복구 시점 — 확정 불가면 "확인 중, O시 재공지"로 명시
5. 답변 스크립트 — 문의 유형별 표준 문구
6. 에스컬레이션 기준 — 어떤 문의를 개발팀으로 넘길지

예상 복구 시점을 비워두지 않는다. 모르면 모른다고 쓰되, 다음 공지 시각은 반드시 준다.

---

6. 보상안은 복구 전에 정한다

복구가 끝난 뒤 보상을 논의하기 시작하면 이미 늦다.

 

정할 것

• 대상 범위 — 영향받은 전 고객인가, 피해를 신고한 고객인가
• 보상 형태 — 환불, 이용 기간 연장, 크레딧, 쿠폰
• 산정 기준 — 장애 시간 비례인가, 정액인가
• 안내 시점과 채널

계약에 SLA(가동률 등을 계약으로 보장하는 문서)가 있다면, 계약서상 보상 조항을 먼저 확인한다.

---

7. 앱은 심사 기간이 복구 시간에 포함된다

앱 서비스는 코드를 고쳐도 바로 끝나지 않는다.

수정 완료 ≠ 고객 복구 완료

 

• Apple App Store와 Google Play 모두 긴급 심사 요청 절차가 있다. 소요 시간은 사전에 확정할 수 없으므로, 접수는 지연 없이 즉시 한다.
• 심사 없이 조치할 방법이 있는지 먼저 본다. 원격 설정이나 기능 플래그로 끌 수 있는 항목이면 심사를 기다릴 이유가 없다.

 

기능 플래그(Feature Flag): 코드 배포 없이 기능을 켜고 끌 수 있게 하는 설정값

 

심사 대기가 길어질수록, CS 안내와 보상안의 무게는 그만큼 커진다.

---

8. 회고에서 던져야 할 다섯 질문

책임자가 있었는가?
지휘자가 없으면 모두가 조치하고 아무도 결정하지 않는다.

 

감지까지 얼마나 걸렸는가?
릴리즈 후 감지가 늦었다면 모니터링과 알람이 없다는 뜻이다.

 

긴박함이 공유되었는가?
조치가 쉽다는 이유로 대응 속도를 늦추지 않는다. 난이도와 시급성은 별개다.

 

피해 규모를 숫자로 답할 수 있는가?
"많은 것 같다"는 파악하지 않은 것과 같다.

 

고객은 언제 알았는가?
고객이 먼저 문의했다면 감지 체계가 작동하지 않은 것이다.

---

핵심 정리

• 대응 순서는 영향도 파악 → CS 매뉴얼 배포 → 고객 안내·보상 결정 → 원인 분석·복구다.
• 유입·발생·인지·보고·착수·안내·복구, 일곱 시각을 모두 남겨야 개선 지점이 보인다.
• 피해 규모는 고객 수, 건수, 금액, 재현 조건까지 숫자로 확정한다.
• CS팀에는 기술 설명이 아니라 응대 스크립트와 다음 공지 시각을 준다.
• 앱은 심사 기간이 복구 시간에 포함되므로, 긴급 심사와 서버 사이드 우회를 동시에 검토한다.
• 심각도는 조치 난이도가 아니라 고객 영향으로 판단한다. 고치기 쉬운 장애일수록 대응이 느슨해진다.

---

참고 자료
- Google SRE Book — Managing Incidents (장애 지휘 체계와 역할 분리)
- ITIL 4 — Incident Management 프로세스
- Apple App Store / Google Play Console 공식 문서 — 긴급 심사(Expedited Review) 절차

 

 

주의사항

• 심각도 기준, 보상 정책, 에스컬레이션 규칙은 조직마다 다르다. 위 표는 예시이며 사내 합의 기준을 우선한다.
• 앱 스토어 긴급 심사의 승인 여부와 소요 시간은 공식적으로 보장되지 않는다.