장애 대응과 인시던트 관리

서론

새벽 3시, 핸드폰이 미친 듯이 울리고 온라인 서비스가 완전히 마비되었습니다 — 당신은 어떻게 하시겠습니까? 모든 인터넷 팀에게 장애는 "발생할 것인가"의 문제가 아니라 "언제 발생할 것인가"의 문제입니다. 훌륭한 팀은 장애가 발생하지 않는 팀이 아니라, 장애가 발생했을 때 빠르게 대응하고 효율적으로 복구하며, 그로부터 학습하여 재발을 방지하는 팀입니다.

이 글에서 무엇을 배우게 될까요?

이 장을 마치면 다음을 얻게 됩니다:

등급 인식: P0~P4 인시던트 심각도 등급 기준 파악
대응 프로세스: 발견부터 복구까지의 전체 인시던트 대응 타임라인 이해
조직 협업: 인시던트 커맨드 체계의 역할 분담과 협업 메커니즘 이해
알림 체계: 알림 에스컬레이션 전략을 파악하여 핵심 문제가 누락되지 않도록 보장
포스트모템 방법: "5 왜(5 Whys)" 분석법으로 근본 원인을 파악하고 가치 있는 포스트모템 보고서를 작성

장	내용	핵심 개념
제1장	심각도 등급	P0~P4, 영향 범위 평가
제2장	대응 타임라인	발견→대응→복구→포스트모템
제3장	커맨드 체계	IC, 커뮤니케이션 담당자, 기술 리드
제4장	알림 에스컬레이션	등급별 알림, 단계적 에스컬레이션
제5장	포스트모템	5 왜, 비난 없는 문화

0. 전체 그림: 장애는 최고의 스승

Netflix에는 Chaos Monkey라는 유명한 도구가 있습니다 — 프로덕션 환경의 서버를 무작위로 종료합니다. 미친 것 같지만, 배경의 논리는 명확합니다: 장애가 찾아오기를 기다리는 것보다, 능동적으로 장애를 만들어 팀의 대응 능력을 단련하는 것이 낫다.

인시던트 대응은 즉흥 연기에 의존하는 것이 아니라 프로세스, 역할, 도구 3위일체의 체계적 구축에 의존합니다. 소방대가 화재가 발생했을 때야 조직하는 것이 아니듯 — 그들은 평소에도 훈련하고, 훈련하고, 장비를 유지보수합니다.

인시던트 대응의 네 가지 핵심 요소

빠른 발견: 완전한 모니터링과 알림 체계로, 문제가 사용자가 인지하기 전에 발견되도록 보장
효율적 협업: 명확한 역할 분담과 소통 메커니즘으로 혼란 속에서의 중복 업무 방지
빠른 복구: 근본 원인을 찾는 것보다 서비스 복구를 우선. 먼저 지혈하고, 그 다음에 치료
지속적 개선: 매번의 장애는 학습 기회이며, 포스트모템을 통해 시스템과 프로세스를 지속적으로 개선

1. 심각도 등급: 모든 장애에 "전원 소집"이 필요한 것은 아닙니다

버튼 색상 오류와 전체 결제 시스템 마비는 분명 같은 수준의 문제가 아닙니다. 인시던트 등급 분류의 목적은 팀이 적절한 수준의 대응력으로 적절한 수준의 문제에 대응하게 하는 것입니다 — 과도한 반응으로 리소스를 낭비하지도 않고, 문제를 가볍게 여겨 손실을 키우지도 않게 합니다.

Critical Incident

Definition

Core business is completely unavailable, many users are affected, and there is serious financial loss or data loss risk.

Response time

Immediate response, staffed within 5 minutes

Notification channels

PhoneSMSChatEmail

Examples

Primary database is down and all reads/writes fail

Payment system is unavailable and users cannot order

Large-scale user data leakage

Response requirements

✓Incident commander joins within 5 minutes

✓Update management every 15 minutes

✓All relevant teams cancel leave and assist immediately

✓Complete postmortem within 24 hours

Level Comparison

Level	User impact	Response time	On-call requirement
P0	All users	Immediate response, staffed within 5 minutes	All hands
P1	Many users	Respond within 15 minutes	Core team
P2	Some users	Respond within 1 hour	On-call engineer
P3	Very few users	Acknowledge today, handle this week	Normal planning
P4	No direct impact	Schedule by priority	No on-call needed

등급	명칭	영향 범위	대응 요구	예시
P0	치명적	핵심 비즈니스 완전 사용 불가	즉시 대응, 전원 대기	결제 시스템 마비, 데이터 유출
P1	심각	핵심 기능 심각한 손상	15분 내 대응	로그인 실패율 > 50%, API 대규모 타임아웃
P2	중요	일부 기능 비정상	1시간 내 대응	검색 결과 부정확, 일부 페이지 500 에러
P3	일반	비핵심 기능 비정상	업무 시간 내 처리	프로필 이미지 로딩 실패, 비핵심 알림 지연
P4	경미	경험 문제	반복 계획에 편성	UI 어긋남, 텍스트 오타

2. 대응 타임라인: 발견부터 포스트모템까지의 전체 프로세스

한 번의 인시던트 대응은 릴레이 경주와 같아서, 각 단계마다 명확한 목표와 인계점이 있습니다. 명확한 타임라인이 팀이 혼란 속에서도 질서를 유지하게 합니다.

Detect

T+0

Triage

T+5min

Mitigate

T+15min

Resolve

T+1h

Postmortem

T+48h

인시던트 대응의 5단계

감지(Detection): 모니터링 알림, 사용자 피드백 또는 내부 순찰을 통해 이상 발견. 목표: 가능한 한 빨리 발견하여 MTTD(평균 감지 시간) 단축.
대응(Response): 인시던트 확인, 심각도 평가, 대응팀 소집, 소통 채널 구축. 목표: 빠르고 효과적인 대응력 조직.
완화(Mitigation): 배포 롤백, 백업 노드 전환, 속도 제한/성능 저하 등 임시 조치로 서비스 복구. 목표: 먼저 지혈하고 사용자 경험 복구.
해결(Resolution): 근본 원인을 찾아 완전히 수정. 목표: 숨은 위험을 제거하고 재발 방지.
포스트모템(Postmortem): 전체 과정을 검토하고 근본 원인을 분석하며 개선 조치 수립. 목표: 장애로부터 학습하여 시스템을 더 견고하게.

지표	의미	최적화 방향
MTTD	평균 감지 시간	모니터링 범위 확대, 알림 임계값 낮추기
MTTR	평균 복구 시간	자동화 복구, 플랜 드릴
MTBF	평균 장애 간격	시스템 신뢰성 향상, 단일 장애점 제거

3. 커맨드 체계: 이 "전투"에서 누가 지휘하는가?

대규모 인시던트에서 가장 두려운 것은 기술적 난제가 아니라 혼란입니다 — 열몇 명이 동시에 조사하고, 다른 사람이 무엇을 하고 있는지 모르며, 핵심 정보가 각 그룹에서 파편화되어 전달됩니다. 인시던트 커맨드 체계(Incident Command System)가 바로 이 문제를 해결하기 위한 것입니다.

🎖️

Incident Commander

📢

Communications Lead

🔧

Operations Lead

💻

Development Lead

🎖️Incident Commander

Core responsibilities

1Coordinate the entire incident response

2Make key decisions such as rollback, traffic shifting, and degradation

3Keep roles collaborating without confusion

4Control response rhythm and synchronize progress regularly

Key skills

Big-picture viewDecision makingCoordinationStress management

Typical phrase

"Current status: payment service is unavailable. Ops checks the database, backend prepares rollback, comms updates every 10 minutes."

Scenario: P0 Payment System Incident

14:02MonitoringPayment success rate drops from 99.9% to 12%, triggering P0 alert.

14:03CommanderConfirms P0 incident, opens incident channel, gathers roles.

14:05CommsNotifies management and updates status page to degraded service.

14:08OpsFinds primary DB CPU at 100% and connection pool exhausted.

14:10DevIdentifies yesterday slow query release as root cause.

14:12CommanderDecision: rollback yesterday change and perform DB failover immediately.

14:15OpsDatabase failover complete and connections recover.

14:18DevCode rollback deployment complete.

14:20CommsPayment success rate recovers to 99.8%; service recovery announced.

세 가지 핵심 역할

인시던트 커맨더(Incident Commander, IC): 전체 인시던트 대응의 총괄 책임자. 의사결정, 리소스 조율, 페이스 컨트롤. IC가 반드시 기술이 가장 뛰어난 사람일 필요는 없지만, 가장 차분하고 가장 전체적인 시야를 가진 사람이어야 합니다.
커뮤니케이션 담당자(Communication Lead): 외부 소통 담당 — 상태 페이지 업데이트, 고객 통지, 경영진 동기화. IC와 기술 담당자가 문제 해결에 집중할 수 있도록 소통 업무가 중단되지 않게 합니다.
기술 리드(Tech Lead): 기술적 측면의 조사와 수정을 담당. 기술 담당자의 분업 협업을 조직하고, IC에게 진행 상황과 방안을 보고.

4. 알림 에스컬레이션: 핵심 문제가 누락되지 않도록 보장

알림 시스템은 인시던트 대응의 "눈"입니다. 하지만 알림이 너무 적으면 누락이 발생하고, 너무 많으면 "알림 피로"가 발생합니다 — 매일 수백 개의 알림을 받으면, 정말 중요한 알림이 묻히기 쉽습니다. 알림 에스컬레이션 전략이 바로 이 문제를 해결하는 핵심입니다.

📡

Monitoring detects issueT+0s

Prometheus detects exhausted DB connection pool and query timeouts.

Automatically triggers P0 alert.

📱

On-call engineerT+30s

Phone, SMS, and chat notify the on-call DBA at the same time.

👥

Team leadsT+5min

Automatically escalates to database and backend team leads.

🎖️

Engineering directorT+15min

Issue is not mitigated, so it escalates to director.

🏢

VP / CTOT+30min

Major incident escalates to executives for external communication.

Escalation Rules

P3/P4 alerts: notify only the on-call engineer; no escalation needed.

P2 alerts: escalate to team lead if not acknowledged within 15 minutes.

P1 alerts: escalate after 5 minutes unacknowledged, then to director after 30 minutes unresolved.

P0 alerts: notify the whole chain immediately; escalate to VP/CTO if not mitigated within 15 minutes.

알림 에스컬레이션의 3계층 메커니즘

1선 대응(L1): 알림 트리거 후, 먼저 당직 엔지니어에게 통지. 15분 내 미확인 시 자동 에스컬레이션.
2선 에스컬레이션(L2): 팀 리더와 관련 분야 전문가에게 통지. 30분 내 미해결 시 계속 에스컬레이션.
3선 에스컬레이션(L3): 기술 총괄과 경영진에게 통지, 전면적인 비상 대응 시작.

5. 포스트모템: 장애로부터 배우기

서비스가 복구된 후 가장 중요한 단계는 포스트모템(Postmortem)입니다. 포스트모템은 책임을 추궁하기 위한 것이 아니라 시스템적인 개선 기회를 찾기 위한 것입니다. Google, Meta 등 기업은 모두 "비난 없는 포스트모템" 문화를 실천합니다 — "이 에러를 시스템이 왜 허용했는가"에 집중하고, "누가 이 에러를 저질렀는가"에 집중하지 않습니다.

SymptomDepth 0 / 4

💡Payment system was completely unavailable for 18 minutes during peak traffic.

Postmortem Template

1Incident summary+

2Timeline+

3Impact assessment+

4Root cause analysis+

5Improvements+

6Lessons learned+

"5 왜(5 Whys)" 분석법

표면적 현상에서 출발하여 "왜"를 연속적으로 추궁하여 근본 원인을 찾습니다:

왜 서비스가 다운되었는가? → 데이터베이스 연결 풀 고갈
왜 연결 풀이 고갈되었는가? → 슬로우 쿼리가 연결을 점유하고 반환하지 않음
왜 슬로우 쿼리가 발생했는가? → 인덱스가 없어 풀 테이블 스캔 발생
왜 인덱스가 없는가? → 새 테이블 온라인 시 DBA 리뷰가 없었음
왜 리뷰가 없었는가? → 필수 SQL 리뷰 프로세스가 없었음

근본 원인은 "누군가 인덱스 추가를 잊었다"가 아니라 "SQL 리뷰 프로세스가 없었다"는 것입니다. 근본 원인을 수정해야 재발을 방지할 수 있습니다.

요약

장애 대응과 인시던트 관리는 모든 기술 팀의 필수 역량입니다. 영웅주의적 개인의 활약이 아니라 체계적인 프로세스, 명확한 역할 분담, 지속적인 포스트모템 개선에 의존합니다.

핵심 포인트 복습:

등급별 대응: P0~P4 등급 분류로 적절한 수준의 대응력으로 적절한 수준의 문제에 대응
명확한 타임라인: 감지→대응→완화→해결→포스트모템, 각 단계의 목표가 명확
커맨드 체계: IC + 커뮤니케이션 담당자 + 기술 리드, 분업 협업으로 혼란 방지
알림 에스컬레이션: 등급별 알림 + 자동 에스컬레이션으로 핵심 문제가 누락되지 않도록 보장
비난 없는 포스트모템: "5 왜"로 근본 원인을 파악하고, 개인 추궁이 아닌 시스템 개선에 집중

더 읽어보기

Google SRE Book - Incident Response - Google의 인시던트 관리 실무
PagerDuty Incident Response Guide - PagerDuty의 오픈소스 인시던트 대응 가이드
Atlassian Incident Management - Atlassian의 인시던트 관리 모범 사례
Learning from Incidents - 인시던트로부터 배우는 커뮤니티 리소스
Chaos Engineering (O'Reilly) - 카오스 엔지니어링 원리와 실무

장애 대응과 인시던트 관리 ​

0. 전체 그림: 장애는 최고의 스승 ​

1. 심각도 등급: 모든 장애에 "전원 소집"이 필요한 것은 아닙니다 ​

2. 대응 타임라인: 발견부터 포스트모템까지의 전체 프로세스 ​

3. 커맨드 체계: 이 "전투"에서 누가 지휘하는가? ​

4. 알림 에스컬레이션: 핵심 문제가 누락되지 않도록 보장 ​

5. 포스트모템: 장애로부터 배우기 ​

요약 ​

더 읽어보기 ​