ITIL 4 자격을 따도 막상 현업에서 "이건 인시던트인가 변경인가"를 헷갈리면 무용지물입니다. 시험은 용어를 묻지만, 운영 현장은 장애가 났을 때 누가 무엇을 먼저 하느냐를 묻습니다. ITIL 4의 핵심 실무 관행(practice) 중 가장 자주 쓰이는 두 가지, 인시던트 관리와 변경 관리를 현업 흐름으로 풀어 봅니다.
인시던트 vs 변경 — 가장 헷갈리는 구분
둘 다 "서비스에 손대는 일"이지만 목적이 정반대입니다.
| 구분 | 목적 | 트리거 | 핵심 지표 |
|---|---|---|---|
| 인시던트 관리 | 끊긴 서비스를 빨리 복구 | 장애 발생 | 복구 시간(MTTR) |
| 변경 관리 | 변경을 안전하게 반영 | 계획된 배포·설정 변경 | 변경 성공률 |
핵심은 "인시던트는 정상으로 되돌리는 것이지 근본 원인을 캐는 게 아니다"입니다. 새벽에 결제가 죽으면, 원인 분석보다 이전 버전으로 롤백해 일단 서비스를 살리는 것이 인시던트 관리입니다. 근본 원인 규명은 그 뒤 문제 관리(problem)의 몫입니다. 이 구분을 흐리면 복구가 늦어집니다.
인시던트 우선순위는 영향도×긴급도
장애가 동시에 여러 건 터지면 어디부터 손대야 할까. ITIL은 우선순위를 **영향도(얼마나 넓게)와 긴급도(얼마나 빨리)**의 조합으로 정합니다.
| 상황 | 영향도 | 긴급도 | 우선순위 |
|---|---|---|---|
| 결제 전체 중단 | 높음 | 높음 | P1 |
| 특정 리포트 화면 깨짐 | 낮음 | 낮음 | P3 |
"VIP가 요청했으니 P1"이 아니라 비즈니스 영향으로 판단하는 것이 원칙입니다. 우선순위 기준을 미리 표로 합의해 두면 장애 한복판에서 감정적 판단을 피할 수 있습니다.
변경 관리 — 표준 변경을 적극 활용한다
변경 관리에서 가장 흔한 실수는 모든 변경을 똑같이 무겁게 취급하는 것입니다. ITIL 4는 변경을 세 종류로 나눕니다.
- 표준 변경(standard) — 위험이 낮고 반복적이라 사전 승인된 변경(예: 정형화된 패치). 매번 승인받지 않습니다.
- 일반 변경(normal) — 평가·승인 절차를 거치는 변경. CAB(변경자문위원회) 검토 대상.
- 긴급 변경(emergency) — 장애 대응처럼 빠른 승인이 필요한 변경.
자주 하는 안전한 작업을 표준 변경으로 등록해 두면 배포 속도와 통제를 동시에 잡습니다. 모든 걸 일반 변경으로 돌리면 승인 병목으로 팀이 마비됩니다.
요점 정리
- 인시던트는 빠른 복구, 변경은 안전한 반영 — 목적이 반대다.
- 우선순위는 직급이 아니라 영향도×긴급도로 정한다.
- 반복·저위험 작업은 표준 변경으로 등록해 승인 병목을 없앤다.
인시던트·변경 흐름을 한국 기업 운영 사례로 익히는 학습은 IT 서비스·프로젝트 관리 트랙에서, 자격 준비 순서는 자격증 로드맵에서 회원가입 없이 무료로 볼 수 있습니다.