본문으로 건너뛰기
Paul's Dev Notes

ITSM Incident State 모델 정리 — 5개 상태와 SLA 영향

ServiceNow ITSM incident의 5개 state(+Canceled) 정의, 전이 규칙, On Hold sub-state, 그리고 SLA pause/종료 메커니즘을 입문자 관점에서 정리합니다.

· note itsm
검증 인스턴스: OOTB Australia · 검증일 2026-05-15

개요

ServiceNow ITSM의 incident는 OOTB(Out-of-the-Box, 기본 제공) 기준으로 5개 핵심 상태(+Canceled) 를 거친다. 입문자가 가장 자주 헷갈리는 포인트는 세 가지다. (1) On Hold의 4가지 sub-reason, (2) Resolved와 Closed의 차이, (3) 어떤 상태에서 SLA가 멈추는가. 이 글은 이 셋을 한 번에 정리한다.

OOTB 기준 설명입니다. 인스턴스에 따라 state 추가·숫자 변경·전이 규칙이 달라질 수 있습니다.

1. 5개 state + Canceled

incident_state 필드에 저장되는 정수값이다. value 4·5는 OOTB 기본 설치에서 비어 있고, 커스텀 state를 끼워넣을 여지로 남겨둔 자리다. 단 인스턴스/버전에 따라 4 = Awaiting User Info 같은 매핑이 이미 들어간 경우도 있으니 본인 환경에서 재확인하자.

valuelabel의미 (한 줄)
1New티켓이 막 열림. 아직 담당자가 없음
2In Progress담당자가 잡고 처리 중
3On Hold외부 요인으로 일시 정지
6Resolved담당자가 해결 마킹. 사용자(caller) 확인 대기
7Closed최종 종료. 필드 변경 불가(read-only)
8Canceled잘못 열린 티켓(중복·오류 등)

2. State 전이 규칙

아래 다이어그램은 OOTB 기본 흐름을 나타낸다. 실선 화살표는 일반 전이, 점선 화살표는 자동 전이다.

Newvalue = 1In Progressvalue = 2On Holdvalue = 3Resolvedvalue = 6Closedvalue = 7Canceledvalue = 87일 후Reopen일반 전이자동/선택적 전이

OOTB 핵심 규칙 네 가지를 기억하자.

  • Closed → 어디로도 못 간다. 재오픈이 필요하면 새 incident를 열거나, 인스턴스에 별도 reopen 정책이 있어야 한다.
  • Resolved → Reopen 시 In Progress로 돌아간다. 단, 인스턴스 정책에 따라 New나 별도 Reopened state로 가기도 한다.
  • On Hold ↔ In Progress 는 자유롭게 왕복 가능하다.
  • In Progress 진입 조건 — assigned_to 또는 최소 assignment_group 이 채워져 있어야 한다. OOTB BR(Business Rule, 비즈니스 규칙)이 이를 강제한다.

3. On Hold 상세 — hold_reason sub-state

incident_state = 3 (On Hold) 일 때 hold_reason 필드로 4가지 사유를 구분한다. UI에선 드롭다운으로 보이지만 백엔드는 정수값이다. 이 sub-state가 SLA 동작을 좌우하므로 정확히 선택하는 게 중요하다.

hold_reason = 1

Awaiting Caller

사용자(caller)에게 추가 정보를 요청해두고 답을 기다리는 상태. 정보 도착 시 In Progress로 복귀.

hold_reason = 2

Awaiting Change

관련 Change 레코드가 먼저 진행되어야 다음 단계로 갈 수 있는 상태. Change 승인·배포 완료 후 재개.

hold_reason = 3

Awaiting Problem

관련 Problem 레코드 해결을 기다리는 상태. 근본 원인 파악 전까지 개별 해결이 어려운 경우.

hold_reason = 4

Awaiting Vendor

외부 벤더(서드파티 SaaS, 하드웨어 공급사 등) 응답을 기다리는 상태. 내부에서 더 할 수 있는 게 없는 경우.

4. SLA에 미치는 영향

SLA(Service Level Agreement, 서비스 수준 협약)는 incident가 어떤 state에 있냐에 따라 타이머가 멈추거나 종료된다. 입문자가 가장 많이 틀리는 부분이기도 하다.

중요한 사실 — SLA 동작은 incident_state 필드 자체가 결정하는 게 아니다. SLA Definition 레코드 안의 Pause conditions 와 Stop conditions 가 결정한다.

PAUSE

On Hold (3) 진입 시 → SLA 타이머 일시정지

On Hold를 벗어나면 타이머가 재개된다. 남은 시간부터 다시 카운트.

STOP

Resolved (6) / Closed (7) / Canceled (8) → SLA 타이머 종료

Resolution Time SLA가 이 시점에 측정된다. Closed는 이미 종료 후라 추가 의미 없음.

OOTB Priority 1 SLA Definition을 열어보면 조건이 아래처럼 설정되어 있다.

Pause condition: Incident State IS On Hold
Stop condition:  Incident State IS one of [Resolved, Closed, Canceled]

“On Hold면 SLA가 멈춘다”는 말은 정확히는 OOTB SLA Definition이 그렇게 설정되어 있기 때문이다. 커스텀 SLA를 만들 때 Pause conditions를 빼먹으면, On Hold로 보내도 SLA 카운터가 계속 돈다. 이 설정은 아래 경로에서 확인할 수 있다.

System Definition > SLA Definitions > [해당 SLA] > Conditions 탭

5. 자주 만나는 함정

함정 1. Resolved → Closed 자동 전이 (기본값 7일) OOTB Scheduled Job Auto Close Resolved Incidents 가 매일 실행되어, resolved_at + 7일 이 지난 incident를 자동으로 닫는다. “분명히 아무도 안 건드렸는데 왜 갑자기 닫혔지?”의 원인이 이것이다. 대기 기간 변경은 system property glide.ui.autoclose.time 에서 한다 (property 명·단위는 인스턴스 버전에 따라 달라질 수 있으니 본인 환경에서 명칭을 확인하자).

함정 2. Reopen 시 어디로 가는가 OOTB는 Resolved → In Progress 복귀가 기본이다. 그러나 인스턴스마다 정책이 다르다 — New로 돌아가거나 별도 Reopened state를 커스텀하기도 한다. 본인 인스턴스의 Incident Reopen 관련 BR(Business Rule)을 먼저 확인하자.

함정 3. assigned_to 비어 있으면 In Progress 진입 차단 OOTB UI Action과 BR이 막는다. 자동화로 New에서 바로 In Progress로 보내려면 assignment 필드부터 채워야 한다. Flow Designer에서 흔히 만나는 첫 번째 벽이다.

함정 4. Canceled vs Closed 혼동 Canceled는 “처음부터 incident가 아니었다”는 의미다(중복·잘못 접수). Resolution이 기록되지 않으므로, 운영 리포트에서 Closed와 분리해 집계해야 정확한 해결률이 나온다.

마무리

state 모델은 ITSM의 기초지만, SLA·자동화·리포팅의 출발점이라 한 번 정리해두면 두고두고 참조하게 된다. 다음 글 Flow Designer로 ITSM Incident 자동 라우팅 에서 이 state 흐름 위에 자동화 3가지 — assignment_group 자동 할당, On Hold 진입 시 caller 알림, Resolved 시 만족도 설문 트리거 — 를 얹는다.