4편 · 약 25분

인시던트 관리와 포스트모텀: 장애 대응의 체계적 접근

장애는 언제나 온다

아무리 잘 설계된 시스템이라도 장애는 발생한다. 하드웨어가 고장나고, 네트워크가 끊기고, 배포가 예상치 못한 동작을 만든다. 문제는 장애가 오는가가 아니라 왔을 때 팀이 얼마나 빠르고 질서있게 대응하는가다.

준비 없이 장애를 맞으면 이런 일이 생긴다. 여러 사람이 동시에 같은 것을 확인한다. 누가 무엇을 하는지 모른다. 슬랙 채널이 추측으로 가득 찬다. 고객 대응이 늦다. 한참 뒤에야 원인을 찾는다.

인시던트 관리(Incident Management)는 이 혼란을 구조화한다. 역할을 정하고, 커뮤니케이션 채널을 단일화하고, 탐지에서 완화, 원인 분석, 재발 방지까지의 흐름을 명확히 한다.

인시던트란 무엇인가

인시던트(Incident)는 사용자나 비즈니스에 영향을 주는 서비스 저하 또는 중단이다. 심각도에 따라 등급을 나눠 대응 수준을 조정한다.

일반적인 심각도 분류(조직마다 다름):

등급	정의	대응 속도	예시
P0 / SEV1	전체 서비스 중단 또는 데이터 손실 위험	즉시 (24/7)	DB 전체 다운, 결제 불가
P1 / SEV2	핵심 기능 저하, 다수 사용자 영향	30분 이내	검색 응답 5배 지연, 주요 API 에러율 상승
P2 / SEV3	일부 기능 영향, 우회 가능	업무 시간 내	특정 리포트 생성 오류, 배치 지연
P3 / SEV4	경미한 이슈, 사용자 영향 없거나 미미	정기 티켓	성능 소폭 저하, 비핵심 모니터링 실패

심각도 분류의 핵심은 일관성이다. 같은 증상에 어제는 P1, 오늘은 P2를 붙이면 대응 팀이 혼란스럽고 사후 분석이 어렵다.

인시던트 커맨드 시스템(ICS)

인시던트 커맨드 시스템은 대형 재난 대응에서 발전한 역할 분리 모델이다. Google SRE와 많은 기술 조직이 이를 채용했다.

인시던트 커맨드 시스템 구조

인시던트 커맨더(IC)

가장 중요한 역할이다. IC의 임무는 기술적 문제를 직접 푸는 것이 아니라 대응 전체를 조율하는 것이다.

현재 가설과 행동 계획을 파악하고 유지한다
결정이 필요한 순간 빠르게 결정한다
진행 상황을 주기적으로 요약하여 브리핑한다
작업이 막히면 더 많은 자원을 투입하거나 방향을 바꾼다
각자가 무엇을 하는지 파악하고 중복 작업을 방지한다

IC가 직접 로그를 뒤지고 쿼리를 실행하기 시작하면 지휘 공백이 생긴다. 기술 작업은 운영 리드와 SME에게 위임한다.

운영 리드(Operations Lead)

기술적 조사와 완화를 실행한다. 필요한 SME를 호출하고 기술적 결정을 내린다. IC에게는 요약과 선택지를 보고한다.

커뮤니케이션 리드(Communications Lead)

대응 팀 외부와의 소통을 담당한다.

내부: 경영진, 영업, 고객지원팀 업데이트
외부: 상태 페이지(status page) 업데이트, 고객 이메일
업데이트 주기: 최소 30분~1시간 간격으로 상황 공유

커뮤니케이션이 없으면 "지금 뭐 하고 있어?"라는 질문이 대응 채널을 방해한다.

서기(Scribe)

인시던트 타임라인을 실시간으로 기록한다. 누가 언제 무엇을 했고 어떤 결정을 내렸는지를 남긴다. 이 로그가 포스트모텀의 기반이 된다.

인시던트 대응 흐름

탐지
알림·보고 → 심각도 분류
P0/P1/P2… → IC 선정
역할 배정 → 조사
가설·데이터 → 완화
롤백·우회 → 해소
서비스 복구

포스트모텀
작성 ← 타임라인
재구성 ← 대응 리뷰
무엇이 잘됐나 ← 인시던트
종료 선언

인시던트 대응 생명주기

탐지(Detection)

인시던트는 두 가지 방식으로 탐지된다.

자동 탐지: 모니터링 알림, 번 레이트 알림, SLO 위반 알림
수동 보고: 고객 CS, 내부 직원 보고, 소셜 미디어

자동 탐지가 이상적이다. 고객이 먼저 알게 되는 것은 모니터링이 불충분하다는 신호다.

초기 완화 우선

조사와 완화는 동시에 진행하되, 완화를 조사보다 우선한다. 원인을 100% 알기 전에라도 롤백, 트래픽 전환, 기능 플래그 비활성화로 사용자 영향을 줄이는 것이 먼저다.

완화 우선 원칙:
"완벽한 원인 분석을 기다리느라 장애를 2시간 연장하지 말라.
 먼저 끄고, 나중에 이해한다."

커뮤니케이션 주기

인시던트가 진행되는 동안 IC는 정해진 주기로 상황을 업데이트해야 한다.

P0/P1 인시던트 커뮤니케이션 주기:
  - 첫 10분: 인시던트 선언, 심각도, 초기 영향 범위 공유
  - 이후 30분마다: 현재 상태, 진행 중 액션, 예상 해소 시간(ETA)
  - 해소 시: 완화 내용, 임시 우회 방법 공유

포스트모텀: 장애에서 배우는 방법

포스트모텀(Postmortem)은 장애 후 무슨 일이 일어났는지, 왜 일어났는지, 다시 발생하지 않으려면 무엇을 해야 하는지를 체계적으로 분석하는 문서다.

SRE 문화에서 포스트모텀의 목적은 비난(blame)이 아닌 학습(learning)이다.

비난 없는 문화(Blameless Culture)

장애 원인을 "ㅇㅇ이 실수했다"로 끝내면 두 가지 문제가 생긴다.

첫째, 다음에 같은 실수를 한 사람이 숨긴다. 처벌이 예상되면 에스컬레이션이 늦어진다.

둘째, 개인을 교체해도 시스템 취약점은 그대로 남는다. 누가 같은 상황에 놓이면 같은 결과가 반복된다.

비난 없는 포스트모텀은 "왜 그 사람이 그 행동을 그 시점에 합리적으로 선택했는가?"를 묻는다. 장애는 개인 실수가 아니라 시스템이 한 사람의 실수를 견디지 못한 취약점이다.

포스트모텀 작성 기준

모든 장애가 포스트모텀을 요구하지는 않는다. 일반적인 기준은 다음과 같다.

P0, P1 인시던트는 필수
에러 버짓을 10% 이상 소비한 인시던트
이전에 발생한 적 있는 패턴
대응이 특히 잘 됐거나 특히 나빴던 경우
팀 내 학습 가치가 있는 경우

포스트모텀 작성 기한은 일반적으로 인시던트 해소 후 2~5 업무일 이내다. 기억이 흐려지기 전에 작성해야 정확한 타임라인을 남길 수 있다.

포스트모텀 구조

좋은 포스트모텀은 다음 섹션을 갖는다.

1. 요약(Summary)

2~3문장으로 무슨 일이 있었는지, 얼마나 영향을 줬는지, 어떻게 해소됐는지 요약한다. 바쁜 독자가 전체 문서를 읽기 전 핵심을 파악할 수 있어야 한다.

2. 영향(Impact)

- 기간: 2026-07-05 14:32 ~ 15:48 KST (1시간 16분)
- 영향 범위: 주문 API 에러율 23% (정상 0.1%), 결제 불가
- 영향 사용자: 약 12,000명 (추정)
- 에러 버짓 소비: 28일 SLO의 18% 소진

3. 타임라인(Timeline)

서기가 기록한 내용 + 모니터링 로그를 결합하여 시간 순서로 정리한다.

14:28 — 배포 v2.4.1 완료 (자동화 배포 파이프라인)
14:32 — Prometheus 알림: 주문 API 에러율 5% (임계값 1% 초과)
14:35 — 온콜 엔지니어 알림 수신, 조사 시작
14:40 — 에러율 23%로 상승, P1 선언, IC 지정
14:42 — 커뮤니케이션 리드: 내부 슬랙 채널 공지, 상태 페이지 업데이트
14:55 — 가설: v2.4.1 배포와 연관 (이전 버전 정상)
15:02 — v2.4.0으로 롤백 시작
15:08 — 에러율 1% 미만으로 감소
15:20 — 롤백 완료, 서비스 정상 확인
15:48 — P1 해소 선언

4. 근본 원인 분석(Root Cause Analysis)

표면적 원인(배포가 에러를 일으켰다)을 넘어 왜 그것이 가능했는지를 묻는다.

5-Why 기법:

Q1. 왜 에러율이 올랐는가?
A1. v2.4.1 배포가 DB 연결 풀 설정을 잘못 변경했다.

Q2. 왜 잘못된 설정이 배포됐는가?
A2. 스테이징 환경에서 테스트하지 않은 설정값이 프로덕션에 반영됐다.

Q3. 왜 스테이징 테스트를 통과했는가?
A3. 스테이징 DB의 최대 연결 수가 프로덕션보다 10배 낮아 문제가 드러나지 않았다.

Q4. 왜 환경 불일치가 있었는가?
A4. 스테이징 환경의 DB 설정 동기화 프로세스가 없었다.

근본 원인: 스테이징과 프로덕션의 DB 파라미터 불일치가 배포 전 감지되지 않는 구조.

5. 기여 요인(Contributing Factors)

근본 원인 외에 장애를 악화시킨 요인을 나열한다.

- 에러율 알림 임계값이 1%로 설정되어 있어 5% 초과 후 3분이 지나서야 발동
- 배포 롤백 절차가 런북에 없어 담당자가 직접 찾아야 했음 (7분 지연)
- 커뮤니케이션 리드 역할이 미리 지정되지 않아 IC가 직접 상태 페이지를 업데이트함

6. 액션 아이템(Action Items)

재발 방지를 위한 구체적 행동 계획이다. 소유자와 기한이 없는 액션 아이템은 없는 것과 같다.

#	액션	소유자	기한	유형
1	스테이징 DB 파라미터를 프로덕션과 동기화하는 자동 검증 추가	@인프라팀	+2주	예방
2	배포 롤백 런북 작성 및 CI 체크 추가	@SRE팀	+1주	완화
3	에러율 번 레이트 알림으로 전환 (현재 단순 임계값 → MWMBR)	@SRE팀	+3주	탐지
4	인시던트 커뮤니케이션 리드 자동 배정 절차 수립	@SRE팀	+2주	대응

액션 아이템은 예방(재발 방지), 탐지(더 빨리 알기), 완화(더 빨리 끄기) 세 유형으로 분류하면 어디에 투자가 부족한지 파악하기 쉽다.

포스트모텀 리뷰 회의

포스트모텀 문서를 작성한 후 팀 전체가 참여하는 리뷰 회의를 연다. 목적은 두 가지다.

첫째, 문서의 정확성을 검증한다. 당사자들이 타임라인과 분석을 확인하고 누락된 정보를 추가한다.

둘째, 학습을 공유한다. 이 인시던트에서 배운 것을 팀 전체가 이해하도록 한다.

좋은 포스트모텀 회의의 기준:

비난이 없다. "누가 실수했냐"는 질문이 아니라 "시스템에서 무엇을 바꿀 수 있는가"가 질문이다.
액션 아이템이 합의된다. 회의 후 소유자와 기한이 명확하다.
모든 참석자가 이 인시던트에서 배울 점이 있었다고 느낀다.

포스트모텀 운영의 함정

포스트모텀이 작성되지 않는다. 인시던트가 해소되면 다음 작업으로 빠르게 넘어간다. 포스트모텀을 강제하는 프로세스가 없으면 학습이 쌓이지 않는다. P1 이상은 포스트모텀 필수라는 명확한 정책이 필요하다.

액션 아이템이 완료되지 않는다. 문서는 잘 작성되었지만 액션 아이템이 티켓에 등록되지 않거나, 등록은 됐지만 우선순위에서 밀린다. 포스트모텀 리뷰 회의에서 지난 포스트모텀의 액션 아이템 현황을 확인하는 루틴이 필요하다.

비난이 숨어든다. "비난 없음"을 선언했지만 실제 문서에 "ㅇㅇ이 실수한 배포"가 등장하거나 회의에서 개인을 지목하는 질문이 나온다. 리더가 의식적으로 시스템 관점 질문으로 방향을 돌려야 한다.

같은 인시던트가 반복된다. 액션 아이템이 표면적 완화에만 집중하고 근본 원인이 해결되지 않는다. 3개월 후 같은 패턴의 인시던트가 재발한다.

데이터베이스·데이터 플랫폼 관점의 인시던트 특성

DB와 데이터 파이프라인 인시던트는 일반 서비스 인시던트와 다른 특성이 있다.

복구가 느리다. 대용량 DB 복구는 시간이 걸린다. 100GB InnoDB 테이블의 crash recovery는 몇 분에서 수십 분이 걸린다. PITR 복구는 더 길다. 복구 시간 예측이 커뮤니케이션에서 중요하다.

데이터 손실 가능성이 있다. 스토리지 장애, 복제 지연, 잘못된 DDL은 데이터 손실로 이어질 수 있다. P0 선언 기준에 "데이터 손실 위험"을 명시적으로 포함해야 한다.

영향 범위가 넓다. DB 장애는 의존하는 모든 서비스에 영향을 준다. 조사 초기에 "이 DB를 사용하는 서비스 목록"을 파악하는 것이 커뮤니케이션에서 필수다.

파이프라인 장애는 지연 탐지가 많다. 배치 파이프라인 오류는 다음날 아침 데이터가 없어지기 전까지 탐지되지 않을 수 있다. freshness SLI와 completeness SLI를 모니터링하는 것이 중요하다.

실무 체크리스트

인시던트 대응 준비:

심각도 분류 기준이 문서화되어 있는가?
인시던트 커맨더 역할을 수행할 수 있는 사람이 팀 내 3명 이상 있는가?
온콜 런북이 최신 상태인가? (6개월 이내 검토)
롤백 절차가 CI 파이프라인 또는 런북에 있는가?
커뮤니케이션 채널(상태 페이지, 내부 슬랙)이 준비되어 있는가?

포스트모텀 운영:

P1 이상 인시던트 후 5 업무일 이내 포스트모텀이 작성되는가?
포스트모텀 액션 아이템이 프로젝트 트래커에 등록되는가?
이전 포스트모텀 액션 아이템 완료율을 분기마다 검토하는가?
포스트모텀 문서에 개인 비난 표현이 있으면 수정하는 리뷰 과정이 있는가?
반복 발생하는 인시던트 패턴을 추적하는 방법이 있는가?

References

Google SRE Book, "Managing Incidents," https://sre.google/sre-book/managing-incidents/
Google SRE Book, "Postmortem Culture: Learning from Failure," https://sre.google/sre-book/postmortem-culture/
Google SRE Workbook, "Postmortem Culture," https://sre.google/workbook/postmortem-culture/
Google SRE, "Incident Management Guide," https://sre.google/resources/practices-and-processes/incident-management-guide/
Rootly, "SRE Incident Management Best Practices," https://rootly.com/sre/sre-incident-management-best-practices-boost-reliability
Rootly, "How to Run Effective Blameless Postmortems," https://rootly.com/incident-postmortems/blameless
Hyperping, "Incident Post-Mortems: The Complete, Blameless Guide," https://hyperping.com/blog/incident-post-mortem
Incident.io, "SRE Incident Post-Mortem Best Practices," https://incident.io/blog/sre-incident-postmortem-best-practices
Pluralsight, "How to Conduct Blameless Postmortems After an Incident," https://www.pluralsight.com/resources/blog/tech-operations/how-conduct-blameless-postmortems-incident
KodeKloud, "Blameless Postmortem Culture," https://notes.kodekloud.com/docs/Fundamentals-of-SRE/Incident-Management/Blameless-Postmortem-Culture/page