월요일 오전 9시 12분, 서비스데스크에 신고 세 건이 거의 동시에 들어옵니다.
- "전 직원이 그룹웨어 로그인이 안 됩니다." (전사, 지금 업무 중단)
- "회계팀 한 분이 엑셀 매크로가 가끔 느려요." (1명, 업무는 가능)
- "다음 달 결제 리포트 양식을 바꿔 주실 수 있나요?" (요청, 여유 있음)
신입 운영자는 들어온 순서대로 첫 번째→두 번째→세 번째를 처리하려 합니다. 옆자리 선임이 말립니다. "순서가 아니라 영향과 긴급도로 줄을 세워. 그룹웨어는 지금 전사가 멈춰 있어 — 나머지는 잠깐 기다려도 돼."
선임은 그룹웨어 건을 즉시 P1으로 올리고, 1선이 15분 안에 원인을 못 찾자 인증 서버 담당 2선으로 넘기고(기능적 에스컬레이션), 동시에 팀장에게 "전사 장애, SLA 시계 돌고 있음"을 **보고(계층적 에스컬레이션)**합니다.
차이는 손이 빨라서가 아닙니다. 먼저 끌 불을 고르고(우선순위), 제때 넘기는(에스컬레이션) 두 가지 판단을 알고 있느냐입니다. 이 모듈은 그 두 판단의 기준을 다룹니다.
- 1영향도(Impact)와 긴급도(Urgency)를 각각 정의하고, 들어온 인시던트를 두 축으로 평가할 수 있다
- 2영향도×긴급도 매트릭스로 우선순위(P1~P4)를 일관되게 도출할 수 있다
- 3Critical·Major·Minor 장애 등급을 정의·예시와 함께 구분할 수 있다
- 4기능적 에스컬레이션과 계층적 에스컬레이션의 목적 차이와 발동 트리거를 설명할 수 있다
- 5우선순위와 SLA(대응·해결 목표시간)의 연계를 이해하고 우선순위별 목표시간 표를 읽을 수 있다
우선순위는 '느낌'이 아니라 두 축의 조합이다
영향도 × 긴급도 — 왜 두 축인가
인시던트가 들어오면 가장 먼저 답해야 할 질문은 "이걸 언제, 누구보다 먼저 처리할까"입니다. 이걸 신고 순서나 목소리 큰 사람 기준으로 정하면, 정작 전사가 멈춘 장애가 뒤로 밀립니다. 그래서 ITSM은 우선순위를 두 개의 독립된 축으로 분해합니다.
- 영향도(Impact) — 이 장애가 얼마나 넓게/심하게 비즈니스에 영향을 주는가. "몇 명이, 어떤 서비스가, 매출·법규에 어떤 피해가."
- 긴급도(Urgency) — 이 장애를 얼마나 빨리 손대야 하는가. "지금 당장 업무가 멈췄는가, 우회로가 있는가, 마감이 임박했는가."
둘은 다릅니다. 영향이 작아도(1명) 긴급할 수 있고(그 1명이 오늘 마감하는 결산 담당자), 영향이 커도(전사) 덜 긴급할 수 있습니다(야간에만 쓰는 기능). 그래서 영향도와 긴급도를 곱해 우선순위를 정합니다.
| 축 | 묻는 질문 | 등급 예시 |
|---|---|---|
| 영향도(Impact) | 얼마나 넓게/심하게 피해를 주나 | 전사 / 다수(부서·팀) / 일부(소수) / 개인(1명) |
| 긴급도(Urgency) | 얼마나 빨리 손대야 하나 | 즉시 / 높음 / 보통 / 낮음 |
| 우선순위(Priority) | 영향도 × 긴급도의 결과 | P1 / P2 / P3 / P4 |
핵심은 우선순위를 직접 정하지 않는다는 것입니다. 영향도와 긴급도를 먼저 판정하고, 그 조합이 우선순위를 자동으로 결정하게 만듭니다. 그래야 사람마다, 기분마다 달라지지 않습니다.
우선순위 매트릭스 — 산출물 ①
영향도 × 긴급도 → P1~P4 매핑
아래가 이 모듈의 첫 번째 산출물, 우선순위 매트릭스입니다. 가로축은 긴급도, 세로축은 영향도이며, 각 칸이 우선순위입니다. 조직마다 칸 수(3×3, 4×4)는 다르지만 사고방식은 같습니다.
| 영향도 ＼ 긴급도 | 즉시 | 높음 | 보통 | 낮음 |
|---|---|---|---|---|
| 전사 | P1 | P1 | P2 | P3 |
| 다수(부서) | P1 | P2 | P2 | P3 |
| 일부(소수) | P2 | P3 | P3 | P4 |
| 개인(1명) | P3 | P3 | P4 | P4 |
읽는 법:
- P1 (최우선): 영향이 넓고(전사·다수) 긴급도도 높은 칸. "지금 당장, 가용 자원 총동원." 전사 그룹웨어 전면 중단이 전형적인 P1.
- P2 (높음): 영향이 넓지만 긴급도가 한 단계 낮거나, 다수에 즉시 영향이지만 우회로가 있는 경우.
- P3 (보통): 영향이 좁거나 긴급도가 낮은, 표준 처리 흐름으로 충분한 경우.
- P4 (낮음): 개인·소수에 영향이고 업무가 계속 가능한 경우. 기록은 남기되 줄 뒤에 세웁니다.
이 표가 있으면 신입이든 선임이든 같은 신고에 같은 우선순위를 매깁니다. 우선순위가 사람 따라 흔들리지 않는 것 — 그게 매트릭스를 쓰는 이유입니다.
확대
그림: 영향도×긴급도 매트릭스가 우선순위를 자동 결정하고, 각 우선순위는 SLA 목표시간으로 이어진다.
장애 등급 — Critical · Major · Minor
우선순위와 짝을 이루는 '심각도' 언어
우선순위가 "언제 처리할까"의 언어라면, 장애 등급(Severity)은 "이 장애가 얼마나 심각한가"를 한 단어로 표현하는 언어입니다. 보고·소집·커뮤니케이션에서 "Critical 떴습니다" 한마디가 모두를 같은 긴장 수준으로 정렬시킵니다.
| 등급 | 정의 | 예시 | 통상 우선순위 |
|---|---|---|---|
| Critical | 핵심 서비스가 전면 중단되거나 다수에게 즉각적·중대한 피해. 매출·법규·안전 직결 | 결제 전면 불가, 전사 인증 서버 다운, 고객 데이터 유출 | P1 |
| Major | 중요 기능이 손상됐으나 우회로가 있거나 일부에 국한. 방치 시 확대 위험 | 결제 일부 카드사만 실패, 한 부서 그룹웨어 지연 | P2 |
| Minor | 영향이 좁고 업무 지속 가능. 불편하지만 우회 가능 | 1명의 프린터 연결 오류, 특정 화면 오타 | P3~P4 |
- Critical은 거의 항상 즉시 대응팀 소집 + 경영진 보고(계층적 에스컬레이션) + 사후 메이저 인시던트 리뷰 대상입니다.
- Major는 빠른 대응이 필요하지만 전 인력을 멈추진 않습니다. 다만 "확대되면 Critical로 승격"이라는 감시가 따릅니다.
- Minor는 표준 절차로 처리합니다.
주의: 등급과 우선순위는 밀접하지만 동일하지 않습니다. 보통 Critical→P1로 매핑되지만, 야간에만 쓰는 시스템의 전면 중단은 등급은 Critical급이어도 긴급도가 낮아 P2가 될 수 있습니다. 등급은 '심각도', 우선순위는 '처리 순서'라는 점을 기억하세요.
확대
에스컬레이션 — 두 방향으로 넘긴다
기능적(수평) vs 계층적(수직)
혼자 또는 한 팀이 모든 인시던트를 끝까지 처리할 수는 없습니다. 그래서 적절한 시점에 넘깁니다(escalate). 넘기는 방향이 두 가지인데, 이걸 섞으면 "팀장한테 보고했는데 정작 기술자는 안 붙은" 사고가 납니다.
- 기능적 에스컬레이션(Functional, 수평) — 전문성을 기준으로 더 적합한 기술 그룹으로 넘깁니다. 1선(서비스데스크) → 2선(애플리케이션·인프라 전문팀) → 3선(개발팀·아키텍트) → 벤더(제조사 기술지원). 목적은 "이 문제를 풀 수 있는 손"을 찾는 것.
- 계층적 에스컬레이션(Hierarchical, 수직) — 관리·의사결정을 기준으로 위로 보고합니다. 담당자 → 팀장 → 부서장 → 경영진. 목적은 "추가 자원 승인", "우선순위 재조정", "대외 커뮤니케이션 결정", "SLA 위반 책임 인지".
| 구분 | 기능적(수평) | 계층적(수직) |
|---|---|---|
| 기준 | 기술 전문성 | 관리 권한·의사결정 |
| 방향 | 1선 → 2선 → 3선 → 벤더 | 담당자 → 팀장 → 경영진 |
| 목적 | 문제를 풀 손을 찾는다 | 자원·판단·커뮤니케이션을 확보한다 |
| 전형 트리거 | 현재 그룹의 역량·권한 초과 | SLA 초과 임박, 영향 확대, 경영 판단 필요 |
중요한 건 둘은 동시에 일어날 수 있다는 점입니다. P1 전사 장애에서는 2선으로 기능적 에스컬레이션을 하면서 동시에 팀장·경영진에게 계층적 보고를 합니다. 하나가 다른 하나를 대체하지 않습니다.
확대
그림에서 보듯 두 경로의 계기가 다릅니다. 기능적은 "이 팀 지식으로는 못 푼다"일 때 옆으로 넘기고, 계층적은 "SLA가 임박했다·영향이 커진다·결정 권한이 필요하다"일 때 위로 올립니다. 그래서 P1에서는 3선으로 넘기면서(기능적) 동시에 매니저에게 보고하는(계층적) 일이 자연스럽게 같이 일어납니다.
발동 트리거 — 언제 넘기는가
에스컬레이션은 "느낌상 어려워서"가 아니라 정해진 트리거로 발동해야 합니다. 그래야 늦지 않고, 또 남용되지 않습니다.
- 시간 초과(가장 흔함): 우선순위별 대응·해결 목표시간(SLA)의 일정 비율(예: 50%, 80%)이 경과하면 자동 알림 → 에스컬레이션. "P1인데 30분째 진전 없음" 같은 임계.
- 역량·권한 초과: 현재 그룹이 진단·수정할 수 없는 영역(예: 1선이 DB 내부를 못 건드림) → 기능적 에스컬레이션.
- 영향 확대: 1명→1부서→전사로 번지거나, Minor→Major로 승격될 조짐 → 계층적 보고 동반.
- 외부·대외 영향: 고객 공지, 규제 신고, 언론 노출 가능성 → 경영진 계층적 에스컬레이션.
- 반복·재발: 같은 인시던트가 또 발생 → 인시던트 처리와 별개로 문제관리(Problem)로도 연결.
핵심: 트리거를 티켓 시스템에 규칙으로 박아 두면(SLA 타이머·자동 알림), 바쁜 와중에 "넘길 타이밍"을 놓치지 않습니다.
우선순위 × SLA — 산출물 ②
우선순위별 대응·해결 목표시간
우선순위는 단지 줄 세우기가 아니라 **"언제까지"라는 약속(SLA)**과 직결됩니다. 두 번째 산출물은 우선순위별 SLA 목표시간 표입니다. 여기서 두 시간을 구분합니다.
- 대응(응답) 목표시간: 신고 접수 후 담당이 붙어 대응을 시작하기까지의 약속 시간.
- 해결 목표시간: 서비스가 정상으로 복구되기까지의 약속 시간.
| 우선순위 | 등급 | 대응(응답) 목표 | 해결 목표 | 에스컬레이션 기준 |
|---|---|---|---|---|
| P1 | Critical | 15분 이내 | 4시간 이내 | 즉시 2선+경영진 동시, 30분 무진전 시 상향 |
| P2 | Major | 30분 이내 | 8시간(영업) 이내 | 해결목표 50% 경과 시 2선 |
| P3 | — | 4시간(영업) 이내 | 2영업일 이내 | 해결목표 80% 경과 시 알림 |
| P4 | Minor | 1영업일 이내 | 5영업일 이내 | 통상 자동 처리, 지연 시 알림 |
(시간 값은 조직·계약마다 다릅니다 — 여기서 외울 것은 숫자가 아니라 구조입니다.)
읽는 법:
- 우선순위가 높을수록 목표시간이 짧아집니다. P1은 분 단위, P4는 영업일 단위.
- 대응과 해결을 나누는 이유: "아직 못 고쳤지만 누군가 붙어 보고 중"과 "아무도 안 본 채 방치"는 전혀 다릅니다. 대응 SLA는 후자를 막습니다.
- 에스컬레이션 기준이 SLA에 묶여 있습니다. "해결목표 50% 경과"처럼, 시간이 우선순위 처리의 신호등 역할을 합니다.
이 표가 있으면 고객에게 "이건 P2라 8시간 내 복구를 목표로 하며, 지금 2선이 보고 있습니다"처럼 약속을 숫자로 말할 수 있습니다. ITSM에서 신뢰는 이 약속과 그 이행에서 나옵니다.
언제 어떻게 처리할지 — 판단 기준
직접 해보기 — 분류표를 채워 본다
아래 4건을 표 형식으로 평가해 보세요. 각 건마다 (1) 영향도, (2) 긴급도, (3) 매트릭스상 우선순위(P1~P4), (4) 장애 등급, (5) 필요한 에스컬레이션 종류를 적습니다. 정답은 ObserveBlock에 있습니다.
A. 전사 결제 시스템 전면 불가, 고객 주문 전부 실패 중. (오전 11시, 매출 직결)
B. 영업부 한 팀(12명) 사내 메신저만 지연, 메일·문서는 정상. (우회 가능)
C. 디자인팀 1명, 특정 폰트가 깨져 보임. 작업은 가능. (불편 수준)
D. 1선이 A 건을 25분째 붙들었으나 인증 서버 로그 접근 권한이 없어 진단 불가.
평가 직관: 먼저 영향 범위(몇 명/어떤 서비스/매출·법규)와 긴급도(지금 멈췄는가/우회로 있는가)를 따로 판정한 뒤, 매트릭스에서 우선순위를 읽어 냅니다. 에스컬레이션은 "풀 손이 없나(기능적)"와 "윗선 판단이 필요한가(계층적)"를 따로 묻습니다.
평가: 영향도 / 긴급도 → P? / 등급 / 에스컬레이션- A = 영향도 전사 / 긴급도 즉시 → P1 / Critical. 즉시 2선(기능적)+경영진(계층적) 동시 발동, 매출 직결로 대외 커뮤니케이션 검토
- B = 영향도 다수(한 팀) / 긴급도 보통(우회 가능) → P2~P3 / Major. 빠른 대응하되 전 인력 소집은 불필요
- C = 영향도 개인(1명) / 긴급도 낮음(작업 가능) → P4 / Minor. 기록은 남기되 줄 뒤에, 표준 절차로
- D = 1선의 권한·전문성 초과 상황 → 기능적 에스컬레이션(인증 서버 2선으로). 동시에 A가 P1이므로 계층적 보고도 병행
- 핵심 감각: 우선순위는 영향×긴급도에서 자동으로 나오고, 에스컬레이션은 방향(전문성=수평 / 권한=수직)을 먼저 구분한다
- 함정 점검: B를 "메신저 안 되니 P1"으로 올리지 않았는가? 우회로가 있고 일부 팀이면 P1이 아니다 — 목소리가 아니라 매트릭스로 줄을 세운다
현장에서 자주 보는 함정
증상: (1) 사용자마다 자기 건이 가장 급하다고 해서 우선순위가 사실상 '신고자 목소리 크기'로 정해집니다. P1이 남발되니 진짜 P1이 묻힙니다. (2) "팀장님께 보고드렸습니다"는 했는데, 시간이 흘러도 서비스는 그대로입니다 — 보고만 위로 올라가고 기술 인력은 안 붙었습니다.
원인:
- 우선순위를 영향도·긴급도로 분해하지 않고 한 번에 "급함/안 급함"으로 정함 → 기준이 주관적이라 흔들림.
- 에스컬레이션의 두 방향을 구분하지 못함 → 계층적 보고(윗선)만 하고 기능적 이관(2선·3선)을 빠뜨림. 보고는 자원을 확보할 뿐, 보고 자체가 장애를 고치지는 않음.
해결 방향:
- 우선순위를 매트릭스로 강제합니다. 신고 접수 시 영향도·긴급도를 각각 드롭다운으로 받아 우선순위를 시스템이 계산하게 합니다. "급해요"라는 말이 아니라 "전사인가/지금 멈췄나"라는 사실로 정해집니다.
- 에스컬레이션을 두 트랙으로 명시합니다. 티켓에 '기능적 이관 대상 그룹'과 '계층적 보고 대상'을 각각 필드로 둡니다. P1이면 둘 다 자동 발동되도록 규칙화합니다.
- SLA 타이머를 켭니다. 대응·해결 목표시간의 50%·80% 경과 시 자동 알림 → "넘길 타이밍"을 사람 기억에 맡기지 않습니다.
우선순위와 에스컬레이션은 '센스'가 아니라 표와 규칙입니다. 표를 만들어 두면 바쁜 9시 12분에도 같은 판단이 재현됩니다.
심화 — 지표가 목표가 되는 순간, 매트릭스는 두 방향으로 휜다
심화: VIP 레인과 하향 재분류 — 우선순위 체계가 형식화되는 신호
우선순위 매트릭스는 만드는 것보다 지키는 것이 어렵습니다. 한국 SI·SM 현장에서 매트릭스는 두 개의 힘을 만납니다 — 하나는 조직 서열, 하나는 계약 지표입니다. 이 둘이 매트릭스를 서로 반대 방향으로 휘게 만듭니다.
- 위로 굴절 — 'VIP 레인'의 비공식 운영: 발주사 임원실에서 온 신고는 영향도 칸에 '전사' 대신 사실상 '직급'이 들어갑니다. 임원 노트북 한 대의 문제가 P1으로 올라가면, 그 시간 동안 진짜 다수 영향 건이 뒤로 밀립니다. 이걸 "매트릭스대로 P4입니다"라고 정면으로 막는 건 현실적으로 어렵습니다. 현실적인 처방은 공식화입니다 — 'VIP 지원'을 우선순위 체계 바깥의 별도 트랙(전담 창구·별도 지표)으로 분리해, 인시던트 우선순위 데이터를 오염시키지 않는 것입니다.
- 아래로 굴절 — 지표 방어형 하향·보류: SLA 준수율이 운영 대금의 감액 조건이나 협력사 평가와 연동되면, 마감이 임박한 P1이 P2로 재분류되거나 '사용자 회신 대기'로 보류 처리돼 SLA 시계가 멈추는 관행이 생깁니다. 담당자 개인의 악의가 아니라, 감액을 피하려는 조직의 합리적 적응이라는 점이 문제를 어렵게 만듭니다.
- 형식화가 진행 중이라는 신호 3가지: ① P1이 몇 달째 0건 — 전사 시스템을 운영하면서 통계적으로 부자연스러운 '깨끗함'입니다. ② 재분류(하향) 이력이 SLA 잔여 시간 20% 미만 구간에 몰려 있습니다. ③ 보류 상태 비율이 월말·평가 직전마다 급증합니다.
- 처방은 규칙이 아니라 가시화: 재분류·보류 전환에 사유 입력을 필수화하고 감사 로그를 남깁니다. 월간 보고에 준수율 옆에 재분류율·보류율을 병기합니다. 시계 정지(clock-stop)가 허용되는 조건을 계약 부속서에 열거해, '회신 대기'가 만능 정지 버튼이 되지 않게 합니다.
우선순위 체계의 건강도는 매트릭스 표가 아니라 재분류 로그에서 읽힙니다. 표가 아무리 정교해도, 로그가 월말마다 요동친다면 그 조직의 우선순위는 이미 지표 방어의 도구가 된 것입니다.
상황: 월간 운영 보고회. 준수율 그래프는 6개월 연속 99%대인데, 발주사 운영부장이 티켓 번호 하나를 짚습니다. "이 건, 우리 팀이 결제 조회 안 돼서 이틀을 기다렸어요. 그런데 보고서엔 SLA 준수로 잡혀 있네요?" 회의실이 조용해지고, 다음 주까지 최근 3개월 티켓 원본과 상태 변경 이력을 제출하라는 요구가 나옵니다.
원인: SLA 준수율이 운영 대금 감액 조건과 직결되어 있었습니다. 운영 파트장은 마감이 임박한 티켓을 '사용자 회신 대기'로 전환해 시계를 멈추고, 일부는 P2→P3로 하향 재분류하도록 팀에 관행처럼 지시해 왔습니다. 누가 조작하자고 결의한 적은 없습니다 — 감액을 피하려는 압박이 매달 반복되면서, "일단 보류 걸어 둬"가 자연스러운 업무 언어가 된 것입니다.
진단: 티켓 시스템 감사 로그를 추출해 보니 최근 3개월 하향 재분류 47건 중 41건이 SLA 잔여 시간 20% 미만 시점에 발생했고, 보류 전환 건의 약 70%는 사용자에게 회신 요청 메일을 보낸 이력 자체가 없었습니다. '회신 대기'라는 상태와 실제 회신 요청 증적이 어긋난다는 것 — 이것이 지표 방어의 결정적 흔적입니다.
해결: 발주사와 합의해 규칙을 다시 세웠습니다. (1) 보류 전환은 회신 요청 발송 증적이 첨부될 때만 가능, (2) 하향 재분류는 사유 필수 입력 + 주간 운영회의에서 샘플 리뷰, (3) 월간 보고서에 준수율과 함께 재분류율·보류율을 병기, (4) 감액 조건을 준수율 단일 지표에서 현업 만족도·재발률을 포함한 복합 지표로 조정. 핵심은 사람을 문책하는 게 아니라 조작할 유인 자체를 줄이는 것입니다 — 단일 지표에 돈이 걸려 있는 한, 같은 굴절은 다른 형태로 반복됩니다.
국내 운영(SM) 현장에서 이 모듈의 내용은 곧 계약과 평가의 언어입니다. 발주사·원청과 맺은 SLA에는 "P1은 응답 15분·복구 4시간" 같은 목표시간이 명시되고, 월간 보고서에는 우선순위별 인시던트 건수와 SLA 준수율이 KPI로 들어갑니다. 운영 담당자는 신고가 들어온 순간 영향도·긴급도를 판정해 우선순위를 매기고, SLA 시계를 의식하며 제때 에스컬레이션을 발동해야 합니다.
특히 협력사(하도급) 구조에서는 기능적 에스컬레이션 경로가 조직 경계를 넘습니다 — 1선은 운영사, 2선·3선은 개발사나 솔루션 벤더인 경우가 흔합니다. 이때 "언제, 누구에게, 어떤 정보를 담아 넘기는가"가 명확하지 않으면 책임 공방으로 시간을 흘려보내고 SLA를 위반합니다. 그래서 관리자는 우선순위 매트릭스와 에스컬레이션 매트릭스(누가 몇 분 안에 받는가)를 계약 부속서·운영 매뉴얼로 문서화해 두고, 장애 회고에서 "우선순위가 맞았나, 에스컬레이션이 늦지 않았나"를 점검합니다. 기술을 아는 관리자는 1선이 "2선으로 넘겨야 할 건"을 붙들고 있는지, "P2인데 P1처럼 대응 중"인 낭비가 없는지를 짚어 냅니다.
실전 랩으로 손에 익히기: 인시던트 트리아지 실습 — 영향×긴급으로 P1~P4를 산출하고 에스컬레이션·동시다발 지휘를 판단합니다.
관련 모듈로 더 깊이:
- 인시던트 관리 — 우선순위·에스컬레이션이 놓이는 인시던트 라이프사이클 전체 흐름
- 메이저 인시던트와 워룸 — P1·Critical로 판정된 큰불이 실제로 터졌을 때의 지휘 체계
다음 모듈에서는 이 P1·Critical 장애가 실제로 터졌을 때 — 여러 팀이 한 곳에 모여 동시에 대응하는 메이저 인시던트와 워룸(War Room) 운영, 인시던트 커맨더의 역할과 커뮤니케이션 흐름을 다룹니다.