심각도와 우선순위: 인시던트 처리 기준을 분리하는 방법

같은 이슈를 서로 다른 축으로 판단해야 하는 이유

운영 티켓에서 심각도와 우선순위를 같은 뜻으로 취급하면 판단이 흔들린다. Severity는 서비스 기능, 가용성, 데이터 무결성에 미치는 기술적 영향의 크기와 범위를 나타낸다. 반면 Priority는 계약상 SLA, 고객 영향, 규제 요구, 마감 일정처럼 외부 조건까지 반영해 무엇부터 처리할지 정하는 기준이다.

즉 Severity는 “문제가 얼마나 큰가”에 답하고, Priority는 “지금 무엇을 먼저 처리할 것인가”에 답한다. ITSM, DevOps, SRE, CS 운영에서 두 값을 분리해 두어야 기술 판단과 리소스 배분을 함께 관리할 수 있다. 이를 위해 Sx–Py 매핑 매트릭스를 운영 기준으로 둘 수 있다.

기술 영향과 업무상 긴급도를 따로 본다

Severity는 영향 사용자 수, 기능 상실 정도, 데이터 손상과 보안 영향을 중심으로 산정한다. 초기 트라이애지에서 빠르게 결정하며, 새로운 근거가 확보되면 재평가할 수 있지만 변경 빈도는 낮은 편이다.

Priority는 SLA 준수 여부, 고객 등급과 시장 영향, 규제·감사 리스크, 비즈니스 데드라인을 함께 고려한다. 고객 이슈나 캠페인, 감사 일정이 달라지면 수시로 바뀔 수 있으므로 일일 또는 주간 리플래닝 리듬이 필요하다.

Severity 판단은 온콜 엔지니어와 SRE가 모니터링 알람, 에러 버짓, 로그·트레이스 데이터를 바탕으로 맡는다. Priority는 제품, 비즈니스, CS 리더와 계정 매니저의 판단에 규제·법무 입력을 더해 결정한다. 기술 주도 판단과 비즈니스 주도 판단을 분리한 이중 채널이 필요한 이유다.

구분	심각도(Severity)	우선순위(Priority)
의미	기술적 영향도의 크기·범위	처리 순서와 긴급도에 대한 비즈니스 결정
중심 관심사	시스템 안정성, 데이터·가용성	고객·수익·규제·계약 준수
결정 주체	엔지니어링/SRE	제품/비즈니스/CS/규제
산정 근거	영향 사용자 수, 기능 상실, 무결성·보안	SLA, 고객 등급, 마감 일정, 평판 리스크
변경 빈도	낮음, 근거 기반 재평가	높음, 외부 요인에 따라 수시 조정
예시	결제 전체 중단 = S1	감사 D-2 규제 보고 = P1
판단 오류의 위험	S1을 P3로 둔치, SLA 위반·평판 하락	S3를 P1로 과대, 리소스 왜곡
연결 지표	MTTR, 안정성 지표	SLA Breach, 백로그 회전율

매핑 규칙은 예외까지 포함해 운영한다

기본 가이드라인으로는 S1인 전사 영향 이슈를 P1으로, S2를 P2로, S3를 P3로 연결할 수 있다. 다만 규제 이슈, VIP 고객, SLA 임박 상황에서는 이 기본 매핑을 넘는 Override가 필요할 수 있다. 이때는 승인 사유를 남기고 감사 로그를 보존해야 한다.

같은 우선순위의 이슈가 여러 건이라면 고객 영향 규모, 복구 리드타임, 번들 처리 가능성을 기준으로 순서를 가른다. 판단 기준, 예시, 체크리스트, 에스컬레이션 경로, 승인 권한을 문서화해 두면 담당자마다 다른 결론이 나는 일을 줄일 수 있다.

운영 결과는 MTTA/MTTR, SLA Breach Rate, Backlog Age, 고객 만족도(CSAT)와 연결해 본다. 주간 리뷰에서는 매핑이 일관되게 적용됐는지, Override가 남용됐는지, 지연된 건의 원인이 무엇인지를 확인한다.

트라이애지에서 드러나는 판단 차이

결제 API의 5xx가 급증해 전체 결제 실패율이 30%라면 Severity는 S1으로 설정한다. 대체 결제수단으로 우회할 수 있더라도 대형 프로모션을 하루 앞둔 상황이라면 Priority는 P1으로 유지하고, 온콜 페이징과 워 룸을 가동한다. 30분 내 임시 복구를 위한 우회를 적용하고 4시간 내 영구 수정 계획을 세운다.

특정 VIP 고객 계정에서만 UI 렌더 오류가 발생했다면 기능 일부 문제로 Severity S3가 될 수 있다. 그러나 계약 벌금 조항과 매출 영향이 크다면 Priority는 P1로 올리고 핫픽스 슬롯을 배정한다.

라이브러리 취약점의 CVSS가 9.8이라면 Severity는 S2 이상으로 판단한다. 변경 윈도우가 제한되고 회귀 테스트가 필요하다면 Priority P2로 계획할 수 있으며, WAF 룰로 임시 완화 조치를 적용한 뒤 주 릴리스에 병합한다.

분류부터 종결까지 이어지는 트라이애지 흐름

⤢✕

운영 체계가 만들 수 있는 변화

Severity와 Priority를 분리하고 매핑 규칙을 운영하면 MTTR은 1530% 단축되고, SLA 위반율은 2040% 감소하며, 긴급 핫픽스 남용은 25% 감소할 수 있다. 백로그 평균 체류일도 10~20% 개선될 수 있다.

의사결정 과정이 투명해지고 엔지니어링과 비즈니스의 역할 경계가 선명해진다. 고객 신뢰도와 내부 판단의 일관성도 함께 높아진다. 다만 조직 성숙도, 모니터링 품질, 변경관리 체계에 따라 편차가 존재하며, 벤치마크 수치는 참조값이다.