장애 관리 용어집

장애 관리(Incident Management)란?

장애 관리는 서비스 중단을 체계적으로 처리하고 해결하는 조직화된 프로세스입니다. 성숙한 장애 관리 체계는 다음을 최소화합니다:

탐지 시간 (MTTD): 문제를 얼마나 빨리 발견하는가
대응 시간 (MTTR): 팀이 얼마나 빨리 개입하는가
해결 시간 (MTTR): 서비스가 얼마나 빨리 복구되는가
영향 지속 시간: 사용자가 얼마나 오래 문제를 경험하는가

목표: 팀의 건강을 보호하고 학습을 가능하게 하면서 서비스를 신속히 복구하는 것.

인시던트 심각도 분류

인시던트는 비즈니스 영향도에 따라 분류하여 대응 우선순위를 결정합니다:

SEV-1 (Critical / P1) — 치명적

전체 서비스 중단 또는 전체/대부분의 사용자에게 영향을 미치는 심각한 성능 저하.

여러 리전이 다운됨
핵심 기능이 완전히 사용 불가
매출에 영향을 주는 서비스 장애
데이터 손실 또는 데이터 손상

대응 시간: 즉시 개입, 수분 내 경영진 통보

예시: “모든 사용자에게 결제 API 완전 중단”

SEV-2 (High / P2) — 높음

많은 사용자 또는 핵심 기능에 영향을 미치는 상당한 서비스 성능 저하.

하나의 리전/서비스에 영향 (다른 것은 정상)
핵심 기능이 심각하게 저하되었지만 대체 경로 존재
전체 사용자의 약 25~75% 영향
성능 SLA 위반

대응 시간: 5~15분 이내 대응

예시: “DB 쿼리 성능 저하로 결제 10배 이상 지연”

SEV-3 (Medium / P3) — 중간

일부 사용자 또는 비핵심 기능에 영향을 미치는 눈에 띄는 서비스 문제.

부수적 기능 장애
전체 사용자의 약 5~25% 문제 경험
우회 방법 존재
비핵심 기능 사용 불가

대응 시간: 30~60분 이내 대응

예시: “일부 리전에서 프로필 사진 로딩 안 됨; 결제는 가능”

SEV-4 (Low / P4) — 낮음

최소한의 사용자 영향, 표시 오류, 또는 정보성 문제.

로깅 문제 (나중에 디버깅 가능)
표시(Cosmetic) 버그
매우 적은 비율의 사용자 (<5%) 영향
인시던트로 잘못 분류된 기능 개선 요청

대응 시간: 업무 시간 중, 다음 영업일 우선순위로 처리

예시: “검색 제안이 평소보다 조금 느림; 검색은 정상 작동”

탐지 및 대응 메트릭

Mean Time to Detect (MTTD) — 평균 탐지 시간

인시던트 시작 → 모니터링 시스템 또는 사용자 신고로 탐지까지의 시간

MTTD = 탐지 시각 - 인시던트 시작 시각

좋은 MTTD 목표:

SEV-1: 5분 미만
SEV-2: 15분 미만
SEV-3: 1시간 미만
SEV-4: 다음 영업일

개선 전략:

리전 전반의 분산 모니터링
주요 트랜잭션에 대한 합성 모니터링
사용자 facing 오류 탐지
비즈니스 메트릭 모니터링 (매출, 주문, 가입)

Mean Time to Respond (MTTR) — 평균 대응 시간

탐지 → 대응자가 조사 및 조치를 시작하기까지의 시간

MTTR = 첫 조치 시각 - 탐지 시각

좋은 대응 목표:

SEV-1: 5분 미만 (온콜에 이미 페이징됨)
SEV-2: 15분 미만
SEV-3: 30분 미만

개선 전략:

자동화된 온콜 알림 시스템
명확한 에스컬레이션 절차
짧은 지연의 알림 채널
온콜 알림 노이즈 감소 (알림 조율)

Mean Time to Resolution (MTTR) — 평균 해결 시간

인시던트 시작 → 전체 서비스 복구까지의 시간

MTTR = 완전 복구 시각 - 인시던트 시작 시각
     = MTTD + 대응 시간 + 조사 시간 + 수정 시간 + 배포 시간 + 검증 시간

목표 MTTR:

SEV-1: 1시간 미만 (이상적으로는 수분)
SEV-2: 4시간 미만
SEV-3: 8시간 미만

참고: MTTR은 “Mean Time To Recovery”로도 불리지만 같은 의미입니다.

개선 전략:

자동화된 인시던트 대응 및 롤백 (피처 플래그, 블루-그린 배포)
일반적인 인시던트에 대한 철저한 런북 준비
배포 마찰 감소
DB 페일오버를 위한 핫 스탠바이 레플리카 유지
프런트엔드 서비스 자동 페일오버

온콜 및 에스컬레이션

On-Call (온콜)

지정된 엔지니어가 정규 업무 시간 이후 또는 중요한 시기에 인시던트에 대응하기 위해 대기하는 의무 로스터 시스템.

일반적인 온콜 구조:

주간 로테이션 (주당 1명)
4주 이상 전에 일정 게시
응답하지 않는 온콜 엔지니어를 위한 에스컬레이션 체인
업무 시간 외 보상 (대체 휴가, 추가 급여)

Primary On-Call (주 온콜)

인시던트 알림을 첫 번째로 받는 사람. 초기 조사 및 대응을 담당.

책임:

합의된 SLA(보통 5분) 내에 페이지에 응답
인시던트를 신속히 진단
해결 불가 시 에스컬레이션/백업 호출

Escalation Backup (Secondary On-Call) — 보조 온콜

주 온콜이 응답하지 않거나 도움이 필요한 경우 에스컬레이션 체인에서 두 번째로 연락하는 사람.

트리거:

주 온콜이 5분 내에 확인하지 않음
주 온콜이 명시적으로 에스컬레이션
인시던트 심각도가 여러 대응자를 요구

Escalation Manager (에스컬레이션 매니저)

비즈니스 결정, 고객 커뮤니케이션, 재무 영향 관리를 위해 엔지니어링에서 리더십으로 에스컬레이션하는 시니어 엔지니어 또는 매니저.

책임:

고객 커뮤니케이션
경영진 업데이트
비즈니스 영향 결정
인시던트 후 프로세스 관리

On-Call Fatigue / Burden (온콜 과부하)

과도한 인시던트 부하로 인한 스트레스, 수면 방해, 팀 번아웃.

증상:

다음날 업무 성과에 영향을 주는 수면 부족
전화 알림에 대한 불안감
온콜 스트레스로 인한 팀원 퇴사

완화 방법:

온콜 근무를 월 1주로 제한
대체 휴가로 보상
잘못된 알림 감소 (알림 조율)
인시던트 복잡성을 줄이는 자동화/런북 투자

Alert Fatigue (알림 피로)

낮은 가치의 알림이 과도하게 발생해 팀이 알림을 무시하거나 무감각해지는 현상.

Alert Fatigue 효과:
하루 100개의 알림, 95%가 오탐
→ 팀이 알림을 무시하도록 훈련됨
→ 중요한 알림도 무시됨
→ 인시던트 미발견 (미탐)

결과:

실제 인시던트 미인지
MTTD 크게 증가
높은 심각도 인시던트가 낮은 우선순위로 처리됨

예방 전략:

알림 조율 (아래 참조)
알림 심각도 상관관계 설정
지능형 중복 제거
런북 자동화 (가능하면 자동 해결)

Alert Tuning (알림 조율)

다음 균형을 맞추기 위해 알림 임계값과 로직을 구성하는 프로세스:

민감도: 실제 문제 모두 포착 (미탐 최소화)
특이도: 오탐 회피 (오탐 최소화)

조율 방법:

임계값 조정: 숫자 조정 (CPU > 85%, 80% 아님)
지속 시간 조건: X분간 임계값 초과 시에만 알림
다중 조건: 여러 신호 동시 발생 요구 (높은 CPU AND 높은 메모리)
컨텍스트 규칙: 예정된 유지보수 기간에는 알림 없음
중복 제거: 동일한 반복 알림을 단일 알림으로 통합

예시:

나쁜 예: CPU > 60%이면 1초 후 알림
→ 끊임없이 트리거됨, Alert Fatigue 유발

좋은 예: CPU > 85%가 5분 지속 AND 오류율 > 1%이면 알림
→ 실제 문제를 알리고, 오탐이 적음

인시던트 커뮤니케이션

Status Page (상태 페이지)

사용자/고객이 서비스 상태, 활성 인시던트, 유지보수 기간을 확인하는 공개 커뮤니케이션 채널.

핵심 정보:

현재 서비스 상태 (정상 / 성능 저하 / 중단)
최근 인시던트 타임라인
인시던트 중 상태 업데이트
예상 해결 시간(ETA)
인시던트 후 보고서 (교훈)

예시: Atlassian Status Page, AWS Service Health Dashboard, GitHub Status

Internal Status Updates (내부 상태 업데이트)

활성 인시던트 중 이해관계자(경영진, 고객 성공팀, 마케팅)에 대한 정기적 커뮤니케이션.

주기: SEV-1은 15~30분마다, SEV-2는 1시간마다

내용:

현재 상태
파악된 사실
조치 중인 내용
해결 예상 시간(ETA)

예시:

18:45 UTC: 인덱스 문제로 DB 쿼리 성능 저하
          사용자 요청의 약 30% 영향
          엔지니어링팀 쿼리 최적화 작업 중
          ETA: 19:30 UTC

19:15 UTC: 최적화 적용, 성능 개선 중
          요청 레이턴시 정상으로 복귀 중
          회귀 여부 면밀히 모니터링 중
          ETA: 19:25 UTC

19:22 UTC: 해결 완료 - 전체 서비스 복구 확인

Customer Communication (고객 커뮤니케이션)

인앱 알림, 이메일, SMS를 통해 영향받은 사용자에게 전송하는 업데이트.

타이밍:

초기 알림: 사용자 facing 영향 5분 이내
업데이트: 15~30분마다
해결: 수정 즉시
사후 분석: 24~48시간 후

내용:

무슨 일이 일어나고 있는가 (전문 용어 피하기)
누가 영향을 받는가
어떻게 조치하고 있는가
언제 해결될 예정인가
사과 및 보상 안내

인시던트 대응 프로세스

Incident Declaration (인시던트 선언)

인시던트가 발생 중임을 공식적으로 인정하고 인시던트 대응 절차를 시작하는 것.

트리거:

자동화된 알림이 온콜에 라우팅됨
고객 신고
내부 발견

조치:

인시던트 커맨더(주 온콜) 참여
인시던트 티켓 개설
인시던트 브릿지/워룸 시작
에스컬레이션 담당자 통보

Incident Bridge (War Room) — 인시던트 브릿지

모든 대응자가 모여 인시던트를 공동으로 진단하고 해결하는 동기식 협업 공간 (화상 회의, Slack 채널 등).

참가자:

인시던트 커맨더 (논의 주도)
도메인 전문가 (DB, 프런트엔드, 모바일 등)
스크라이브 (기록 담당)
고객/제품팀 담당자 (컨텍스트/영향도 파악)

규율:

한 번에 한 명만 발언
직접적이고 간결한 커뮤니케이션
관련 없는 논의 배제
인시던트 중 결정 번복 지양

Incident Commander (IC) — 인시던트 커맨더

인시던트 대응을 이끄는 시니어 엔지니어. 반드시 깊은 기술 전문가일 필요는 없으며, 오케스트레이터 역할.

책임:

조사할 사항 결정
조사 작업 배정
추가 리소스 에스컬레이션/투입
완화(Mitigation) vs. 수정(Fix) 접근법 결정
롤백/위험한 변경 승인
상태 업데이트 커뮤니케이션
해결 시 인시던트 브릿지 종료

필요한 역량:

압박 상황에서의 침착함
명확한 커뮤니케이션
시스템 사고 (결정이 어떻게 연쇄 영향을 미치는지)
판단 결정을 내리는 의지

Scribe (스크라이브)

사후 분석을 위해 인시던트 타임라인과 결정 사항을 기록하는 역할.

기록 내용:

이벤트 타임라인: “18:45 - DB 레이턴시 알림 트리거됨”
조사 결과: “18:52 - users 테이블에 인덱스 누락 확인”
취한 조치: “19:00 - 인덱스 생성 배포”
결정 사항: “19:05 - 문제 해결 확인, 브릿지 종료”
미결 질문: “왜 모니터링이 더 일찍 잡지 못했는가?”

인시던트 해결 방법

Mitigation (완화)

근본 원인을 반드시 수정하지 않더라도 서비스를 신속히 복구하는 조치.

예시:

최근 배포 롤백
백업 데이터베이스로 트래픽 전환
트래픽 감소를 위한 서킷 브레이커 활성화
손상된 캐시 초기화

소요 시간: 수분~15분

인시던트 예시: 30분 전 배포 코드에서 오류 발생

완화: 배포 롤백 (해결까지 5분)
근본 원인 수정: 코드 리뷰로 버그 찾아 수정 후 재배포 (완화 후 30분)

장점: 빠른 서비스 복구

단점: 제대로 수정하지 않으면 문제 재발 가능

Temporary Fix (임시 수정)

근본 원인이 해결되는 동안 문제를 우회하는 부분적 해결책.

예시:

인시던트: "orders 테이블 슬로우 쿼리"
임시 수정: DB 커넥션 풀 크기 증가
          (큐잉 감소, 일부 요청 빨라짐)
영구 수정: 슬로우 쿼리 최적화 (누락된 인덱스 추가)

소요 시간: 15~45분

Permanent Fix (영구 수정)

근본 원인을 해결하여 인시던트가 재발하지 않도록 하는 완전한 해결책.

필요 사항:

전체 근본 원인 분석
코드 변경 (보통)
테스트
배포
수정 모니터링

소요 시간: 수 시간~수 일 (서비스 복구를 막지 않음)

Failover (페일오버)

주 시스템 장애 시 백업/레플리카 시스템으로 서비스 트래픽을 전환하는 것.

유형:

자동 페일오버: 인간 개입 없이 즉시 발생 (로드 밸런서가 장애 감지)
수동 페일오버: 온콜 엔지니어가 백업으로의 전환 시작

RTO (복구 시간 목표): 자동 < 1분; 수동 5~10분

조건: 주 시스템과 동기화된 백업 시스템 필요

인시던트 후 활동

Root Cause Analysis (RCA) — 근본 원인 분석

인시던트가 발생한 이유를 체계적으로 파악하는 조사.

방법론:

5 Whys: “왜”를 반복해서 물어 근본 원인 도달
피쉬본 다이어그램: 기여 요인 매핑
결함 트리 분석: 다중 장애 경로 결합

“DB가 크래시됐다”가 아니라 “배포 후 로그 로테이션 크론 작업이 비활성화되어 디스크가 가득 차 DB가 크래시됐다”처럼 깊이 파고듭니다.

Blameless Postmortem (블레임리스 포스트모텀)

개인의 잘못을 지정하지 않고 인시던트를 분석하는 구조화된 회의. 개인이 아닌 시스템에 집중합니다.

철학:

엔지니어는 부주의하지 않다
시스템이 오류를 방지해야 한다
모든 인시던트에서 무언가를 배울 수 있다
솔직한 토론을 위한 심리적 안전감 필요

참가자:

인시던트 대응자
영향받은 팀의 엔지니어
선택적: 고객 성공팀 (영향 관점)
인시던트 커맨더 또는 매니저가 진행

문서 포함 내용:

무슨 일이 있었는가 (타임라인)
왜 일어났는가 (근본 원인)
잘 된 것 (좋은 대응 칭찬)
개선할 것 (액션 아이템)
기여 요인 (기술적 및 인적)

Five Whys Technique (5 Whys 기법)

증상에서 근본 원인까지 파고드는 반복적 질문 기법.

Level 1: 왜 API가 타임아웃됐나?
→ DB 쿼리가 10초 걸림

Level 2: 왜 쿼리가 느린가?
→ 큰 테이블에 인덱스 누락

Level 3: 왜 인덱스가 없는가?
→ 스키마 마이그레이션 롤백이 불완전함

Level 4: 왜 롤백이 실패했나?
→ 마이그레이션 스크립트에 down 마이그레이션이 없었음

Level 5: 왜 down 마이그레이션이 없었나?
→ 엔지니어가 마이그레이션에 양방향이 필요한지 몰랐음

근본 원인: 기술 문제가 아닌 프로세스/교육 문제

Action Items / Remedial Actions (액션 아이템)

인시던트 재발을 방지하기 위한 구체적 작업.

갖춰야 할 조건:

구체적: “users.email에 인덱스 추가”, “쿼리 개선”이 아님
측정 가능: “금요일까지 배포”, “곧”이 아님
담당자 지정: 포스트모텀 중 소유자 확인
우선순위화: 일부는 중요, 나머지는 선택적

추적: 이슈 트래커에 저장, 주간 회의에서 검토

액션 아이템 예시:

양방향 스키마 마이그레이션 프레임워크 구현 (중요 - 금요일까지)
인덱스 누락 모니터링 추가 (높음 - 다음 스프린트까지)
마이그레이션 모범 사례 문서화 (중간 - 이번 달 말까지)

런북 및 자동화

Runbook (런북)

특정 유형의 인시던트에 대응하기 위한 단계별 가이드.

구성 요소:

증상: 이 런북의 트리거는? “높은 DB 레이턴시”
빠른 확인: 이 문제가 맞는지? “쿼리 실행 시간 확인”
진단 단계: 원인 좁히기
완화: 서비스 복구를 위한 빠른 수정
근본 원인 조사: 발생 이유 찾기
예방: 향후 방지 방법
에스컬레이션: 온콜 매니저에 연락할 시점

형식: 마크다운, PDF, 또는 위키 페이지 (검색 가능, 버전 관리)

런북 예시:

# DB 레이턴시 높음 런북

## 증상
- DB 쿼리가 1초 이상 걸림
- 애플리케이션 응답 시간 저하
- 오류율 증가

## 빠른 확인
1. DB 모니터링 대시보드 확인
   - 쿼리 실행 시간 > 1초? → 이 문제일 가능성 높음
   - CPU > 85%? → 다른 문제일 수 있음

2. 슬로우 쿼리 로그 확인
   - 동일한 쿼리가 반복적으로 느린가?

## 진단 (5~10분)
1. 가장 느린 쿼리 식별
   - SELECT * FROM <테이블> 쿼리 플랜 확인
2. 최근 테이블 성장 여부 확인
   - 행 수? 디스크 사용량?
3. 인덱스 사용 여부 확인
   - 필요한 인덱스가 있는가?

## 완화 (슬로우 쿼리 발견 시)
1. 전체 테이블 스캔이면 LIMIT 절 추가
2. 쿼리 재구성 고려
3. 최후 수단으로: DB 리소스 증가 (임시)

## 근본 원인 수정
1. 쿼리 최적화: 적절한 인덱스 추가
2. 쿼리 검토: 대안을 위한 실행 플랜 분석
3. 프로덕션 수준의 데이터 볼륨으로 테스트

## 예방
- 코드 리뷰에서 N+1 쿼리 패턴 잡기
- 실제 데이터 볼륨으로 성능 테스트
- 인덱스 사용률 모니터링

Automated Incident Response (자동화된 인시던트 대응)

인간 개입 없이 인시던트 발생 시 자동으로 조치하는 시스템.

예시:

오토스케일링: 트래픽 급증으로 스케일링 정책 트리거, 서버 추가
서킷 브레이커: 서비스에서 오류 반환 시, 빠른 실패를 위해 서킷 오픈
자동 페일오버: 주 DB 사용 불가 시, 레플리카 승격
캐시 초기화: 손상된 캐시 감지 시 자동 삭제
피처 플래그 킬 스위치: 플래그 뒤에 있는 기능에 문제 발생 시 자동 비활성화

이점:

서브초 대응 (사람의 반응보다 빠름)
일관성 있고 반복 가능한 절차
사람이 복잡한 결정에 집중 가능

위험:

자동화 로직이 틀리면 연쇄 장애 가능
자동화 실패 시 수동 오버라이드 능력 필요

인시던트 예방

Monitoring & Observability (모니터링 및 관측 가능성)

문제를 선제적으로 감지하기 위한 시스템 상태의 지속적 측정.

세 기둥:

Metrics (메트릭): 수치 측정값 (레이턴시, 처리량, CPU)
Logs (로그): 디버깅을 위한 상세 이벤트 기록
Traces (트레이스): 분산 시스템 전반의 요청 흐름

모니터링으로 인시던트가 감지될 때: MTTD < 5분

Redundancy (이중화)

단일 장애로 서비스 중단이 발생하지 않도록 중요 컴포넌트를 복제.

유형:

Active-Active: 양쪽 시스템 모두 트래픽 처리
Active-Passive: 대기 시스템이 장애 시 인수
리전: 여러 지리적 리전에 서비스 배포

투자: 인프라 비용 증가, 그러나 가용성 영향 감소

Testing for Failure (장애 테스트)

재해 시나리오에 대한 선제적 테스트:

카오스 엔지니어링: 의도적으로 시스템을 파괴해 약점 발견
재해 복구 훈련: 페일오버 절차 연습
부하 테스트: 시스템이 피크 부하를 처리하는지 검증

연구 결과: 심각한 인시던트의 75%는 테스트로 발견할 수 있었음

업계 표준 및 프레임워크

ITIL (IT Infrastructure Library)

인시던트 관리를 포함한 IT 서비스 관리 모범 사례.

ITSM (IT Service Management)

인시던트 절차를 포함한 IT 시스템 관리에 대한 광범위한 접근법.

SLA / SLO / SLI

SLA (Service Level Agreement): 계약상 약속 (99.9% 업타임)
SLO (Service Level Objective): SLA보다 엄격한 내부 목표 (99.95% 업타임)
SLI (Service Level Indicator): 실제로 측정하는 것 (오류율, 레이턴시)

세 가지가 함께 작동하여 서비스 신뢰성을 정의하고 추적합니다.

핵심 교훈

✅ 심각도 등급 정의 — 대응 긴급도에 대한 명확한 기준

✅ 탐지에 투자 — 빠른 수리보다 낮은 MTTD가 더 중요

✅ 알림 조율 — 피로를 방지하기 위한 민감도와 특이도의 균형

✅ 블레임리스 포스트모텀 — 처벌하지 않고 배우고 개선

✅ 런북 및 자동화 — 수동 작업 및 인적 오류 감소

✅ 이중화 — 더 빠른 대응만이 아닌 인시던트 예방

❌ 포스트모텀 생략 — 학습이 인시던트 관리의 가치

❌ 개인 비난 — 인시던트는 시스템 장애이지 개인의 실패가 아님

❌ Alert Fatigue 무시 — 더 깊은 문제의 초기 경고 신호

이 가이드를 내 서비스에 직접 적용해 보세요.

TestForge 무료 스캔 시작 →