장애 대응과 인시던트 관리: 온콜부터 포스트모템까지

장애는 막을 수 없으므로, 대응 속도와 복구 체계로 손실을 줄인다.

개요

장애는 상용 서비스에서 피할 수 없으므로, 중요한 것은 대응 속도와 복구력이다. 사이트 신뢰성 엔지니어링(Site Reliability Engineering, SRE)의 결론도 같다. 실패를 방지하기보다 실패로부터 빠르게 복구하는 것이 핵심이다. 이 글은 인시던트 생명주기, 인시던트 커맨드 시스템(ICS), 런북, 포스트모템, 카오스 엔지니어링까지 장애 대응 전반을 다룬다.

2026년 현재 AI 기반 인시던트 관리 플랫폼이 늘면서, MTTR(평균 복구 시간)이 줄었다는 보고가 나온다. SolarWinds의 2025 State of ITSM Report는 생성형 AI를 도입한 조직의 평균 인시던트 처리 시간이 도입 전 대비 17.8% 줄었다(건당 4.87시간 단축)고 집계했다. 이 보고서는 2,000개 이상 ITSM 시스템과 6만여 데이터 포인트를 분석했다. 다만 이는 ITSM 티켓 처리 시간 기준이며, 감소폭은 워크로드와 구현 수준에 따라 달라지므로 일반화하기 어렵다. AI는 인간의 판단을 대체하지 않고, 탐색 범위를 좁히고 반복 작업을 자동화하여 온콜 엔지니어를 보조하는 방향으로 쓰인다.

인시던트 관리 생명주기

탐지 (Detection)
    ↓
트리아지 (Triage)
    ↓
대응 (Response)
    ↓
완화 (Mitigation)
    ↓
복구 (Recovery)
    ↓
사후 분석 (Post-Mortem)
    ↓
개선 (Improvement)

온콜과 알림 관리

온콜 체계

온콜(On-Call)은 지정된 시간 동안 시스템 장애에 즉각 대응하는 책임을 가진 엔지니어 체계이다.

건강한 온콜 체계의 원칙:

1. 로테이션: 최소 8명 이상의 엔지니어로 순환 (1주 단위 권장)
2. 에스컬레이션 경로: 1차 → 2차 → 관리자 → 경영진 순서
3. 보상: 온콜 수당 또는 대체 휴일 보장
4. 알림 품질: 실행 가능한(Actionable) 알림만 발송
5. 토일 예산: 온콜 시간의 50% 이상이 반복 작업이면 자동화 필요

알림 라우팅과 심각도 분류 (Severity Classification)

알림 피로(Alert Fatigue) 방지:

• 실행 가능하지 않은 알림 제거
• 관련 알림 자동 그룹핑
• 알림 억제(Suppression) 규칙 설정
• 유지보수 윈도우(Maintenance Window) 동안 알림 뮤트

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

개념

대규모 인시던트 발생 시, 명확한 역할 분담과 의사결정 체계를 통해 효율적으로 대응하는 프레임워크이다. 원래 산불 진화 등 재난 대응에서 유래했으며, 기술 기업에서 채택하여 활용하고 있다.

핵심 역할

인시던트 대응 프로세스

1. 알림 수신 → 온콜 엔지니어 확인 (5분 이내)
2. 초기 평가 → 심각도 분류 (SEV1-4)
3. SEV1/SEV2 → 인시던트 선언 → 전쟁방(War Room) 개설
4. 역할 배정 → IC, Tech Lead, Comms Lead, Scribe
5. 조사 및 완화 → 근본 원인 발견 전이라도 증상 완화 우선
6. 커뮤니케이션 → 정기적 상태 업데이트 (15-30분 간격)
7. 해결 → 서비스 정상 확인 → 인시던트 종료 선언
8. 사후 분석 → 48-72시간 이내 포스트모템 작성

런북과 플레이북

런북 (Runbook)

특정 알림이나 장애 상황에 대한 단계별 대응 절차를 문서화한 것이다.

# Runbook: 데이터베이스 연결 고갈 (DB Connection Pool Exhaustion)
 
## 알림 조건
- 활성 DB 연결 수 > 최대 풀 크기의 90%
 
## 초기 진단
1. 현재 활성 연결 수 확인: `SELECT count(*) FROM pg_stat_activity;`
2. 오래 실행 중인 쿼리 확인: `SELECT * FROM pg_stat_activity WHERE state = 'active' AND duration > interval '30 seconds';`
3. 연결 대기 큐 확인
 
## 완화 조치
1. 오래 실행 중인 쿼리 종료: `SELECT pg_cancel_backend(pid);`
2. 필요시 유휴 연결 정리
3. 연결 풀 크기 일시적 증가 (PgBouncer 설정)
 
## 근본 원인 조사
- 느린 쿼리 로그 분석
- 최근 배포 이력 확인
- 트래픽 급증 여부 확인
 
## 에스컬레이션
- 30분 내 해결 불가 시: DBA 팀 호출

pg_stat_activity는 PostgreSQL의 현재 연결과 실행 중인 쿼리를 보여주는 뷰로, 활성 연결 수와 오래 걸리는 쿼리를 여기서 확인한다. pg_cancel_backend(pid)는 해당 프로세스 ID의 쿼리를 강제로 취소해 점유된 연결을 회수하는 완화 조치다.

플레이북 (Playbook)

런북보다 상위 수준의 대응 전략을 정의한다. 인시던트 유형별 대응 방법, 커뮤니케이션 절차, 에스컬레이션 기준 등을 포함한다.

포스트모템 (Post-Mortem)과 근본 원인 분석 (RCA)

비난 없는 문화 (Blameless Culture)

포스트모템의 핵심은 **"누가 잘못했는가?"가 아니라 "왜 시스템이 이를 허용했는가?"**를 묻는 것이다.

비난 없는 포스트모템의 원칙:

1. 사람이 아닌 시스템과 프로세스에 초점
2. 정보를 가진 사람이 안전하게 공유할 수 있는 환경
3. 실수는 학습의 기회이며, 처벌의 대상이 아님
4. 모든 포스트모템은 조직 전체에 공개

포스트모템 템플릿

# 포스트모템: [인시던트 제목]
 
## 요약
- 날짜: YYYY-MM-DD
- 심각도: SEV1
- 영향 시간: HH:MM ~ HH:MM (총 X분)
- 영향 범위: Y% 사용자의 Z 기능
 
## 타임라인
| 시간 | 이벤트 |
|------|--------|
| 14:00 | 배포 v2.3.1 시작 |
| 14:05 | 에러율 1% → 15% 급증 |
| 14:07 | 알림 발송, 온콜 엔지니어 확인 |
| 14:10 | 인시던트 선언 (SEV1), IC 배정 |
| 14:15 | 배포 롤백 결정 |
| 14:20 | 롤백 완료, 에러율 정상화 |
 
## 근본 원인
데이터베이스 마이그레이션 스크립트가 인덱스를 삭제하면서
주요 쿼리의 응답 시간이 10배 증가, 연결 풀 고갈로 이어짐
 
## 기여 요인
- 마이그레이션 스크립트 리뷰 부재
- 카나리 배포 없이 전체 배포
- DB 커넥션 풀 모니터링 알림 미설정
 
## 교훈
- 잘된 점: 빠른 롤백 결정 (10분 이내)
- 개선할 점: 마이그레이션 리뷰 프로세스, 카나리 배포
 
## 액션 아이템
| 번호 | 조치 | 담당자 | 기한 | 우선순위 |
|------|------|--------|------|----------|
| 1 | DB 마이그레이션 리뷰 체크리스트 작성 | DBA팀 | 1주 | P1 |
| 2 | 카나리 배포 필수화 | DevOps | 2주 | P1 |
| 3 | DB 커넥션 풀 알림 추가 | SRE | 1주 | P2 |

근본 원인 분석 기법

5 Whys (다섯 번의 왜):

왜 서비스가 중단되었는가?
  → 데이터베이스 연결 풀이 고갈되었기 때문
왜 연결 풀이 고갈되었는가?
  → 쿼리 응답 시간이 10배 증가하여 연결이 반환되지 않았기 때문
왜 쿼리 응답 시간이 증가했는가?
  → 인덱스가 삭제되어 Full Table Scan이 발생했기 때문
왜 인덱스가 삭제되었는가?
  → 마이그레이션 스크립트에 DROP INDEX가 포함되어 있었기 때문
왜 리뷰에서 발견되지 않았는가?
  → 마이그레이션 스크립트 리뷰 프로세스가 없었기 때문 (근본 원인)

Fishbone Diagram (이시카와 다이어그램): 원인을 범주별로 분류하여 시각화: 사람, 프로세스, 기술, 환경

신뢰성 메트릭 (Reliability Metrics)

MTBF = MTTF + MTTR
 
가용성 = MTTF / MTBF = MTTF / (MTTF + MTTR)
 
예시: MTTF = 720시간, MTTR = 0.5시간
가용성 = 720 / 720.5 = 99.93%

카오스 엔지니어링과 Game Day

Game Day

계획된 장애 시뮬레이션 이벤트로, 팀이 실제 장애 상황을 연습하고 대응 능력을 검증한다.

Game Day 진행 절차:

1. 시나리오 설계: "주 데이터베이스가 5분간 응답하지 않는다면?"
2. 폭발 반경 제한: 비프로덕션 환경 또는 제한된 트래픽
3. 관찰자 배치: 모니터링 대시보드, 알림 시스템 감시
4. 실험 실행: 장애 주입
5. 대응 평가: ICS 활성화, 런북 사용, 커뮤니케이션 효과 평가
6. 회고: 발견된 약점과 개선점 도출

프리모템 (Pre-Mortem) 분석

장애가 발생하기 전에 "이 프로젝트가 실패했다면 왜 실패했을까?"를 상상하여, 잠재적 위험을 사전에 식별하는 기법이다.

가정: "6개월 후, 이 시스템에서 대규모 장애가 발생했다."
질문: "무엇이 잘못되었을까?"
 
팀원들이 독립적으로 실패 시나리오를 작성하고 공유:
- "DB 샤드 간 불균형으로 핫스팟 발생"
- "서드파티 결제 API 장시간 장애"
- "캐시 스탬피드로 DB 과부하"

인시던트 관리 도구 (2026)

주요 플랫폼

AI SRE 에이전트 (2026 트렌드)

AI SRE는 자동화된 사이트 신뢰성 엔지니어로서, 인시던트를 자율적으로 조사하고 근본 원인을 식별하며 수정을 제안하거나 실행한다.

Multi-Agent AI 접근 (2026 최신): 여러 AI 에이전트가 온콜 엔지니어를 대체하지 않고 함께 조사하는 방식으로:

• 탐색 범위 축소
• 반복적 단계 자동화
• 판단이 필요한 결정은 인간에게 위임

AIOps의 SRE 역할 변화: AI 기반 IT 운영(AIOps)이 인시던트 대응, 알림 처리, 모니터링 등 반복 작업을 자동화하면서, SRE의 시간은 반복 운영에서 신뢰성 설계와 자동화 개선 쪽으로 옮겨가고 있다.

SRE 문화와 실천

Google SRE의 핵심 원칙

1. 토일 제거 (Eliminating Toil): 수동 반복 작업을 자동화
2. 에러 버짓 (Error Budget): 혁신과 안정성의 균형 → 모니터링 및 관측 가능성
3. 점진적 롤아웃: 한 번에 전체 배포하지 않음 → 배포 전략
4. 포스트모템: 모든 SEV1/SEV2 인시던트에 대해 수행
5. 단순성 추구: 복잡성은 장애의 원인

SRE와 DevOps의 관계

DevOps = 문화와 철학 (무엇을 해야 하는가)
SRE    = 구체적 구현 (어떻게 해야 하는가)
 
"SRE는 DevOps 철학의 특정 구현이다" - Google

정리

장애 대응의 목표는 실패를 없애는 것이 아니라 탐지부터 복구, 사후 분석까지 이어지는 흐름을 짧고 반복 가능하게 만드는 것이다. 온콜 로테이션과 심각도 분류는 누가 언제 어디까지 대응할지를 정하고, ICS는 대규모 장애에서 역할과 의사결정 권한을 분리한다. 런북과 플레이북은 대응을 개인 기억이 아닌 문서로 옮겨 재현 가능하게 만든다. 비난 없는 포스트모템과 MTTR 같은 신뢰성 메트릭은 같은 장애가 반복되지 않도록 시스템과 프로세스를 고치는 근거가 된다. 카오스 엔지니어링과 Game Day는 실제 장애 전에 대응 체계의 약점을 미리 드러낸다.

다음 글에서는 같은 시리즈의 테스트 자동화를 다룬다.

참고 자료

• Site Reliability Engineering - Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Murphy (Google)
• Incident Management for Operations - Rob Schnepp, Ron Vidal, Chris Hawley
• The Phoenix Project - Gene Kim, Kevin Behr, George Spafford
• PagerDuty Incident Response Guide: https://response.pagerduty.com