ServiceNow CMDB IRE & Discovery — Identification Rules, Reconciliation, Discovery Source Priority (CMDB Deep Dive #4, 시리즈 종결편)

개요

CMDB Deep Dive 시리즈 종결편이다. #1 에서 “Duplicate CI — 영향 분석 오류”를 cascading 함정으로 예고하면서 IRE(Identification and Reconciliation Engine, 식별·조정 엔진)가 해결하는 핵심 케이스임을 언급했다. #2 에서는 cmdb_ci table extension 과 class hierarchy 데이터 모델 토대를, #3 에서는 cmdb_rel_ci 양방향 그래프와 Reference Field 단방향 포인터의 선택 기준을 다뤘다. 이 세 글이 쌓은 토대 위에서 실제 데이터가 안전하게 들어오고 중복 없이 유지되도록 게이트키핑하는 엔진이 바로 IRE 다.

IRE 는 두 축으로 분리된다. Identification 은 “이 payload 가 기존 CI 인가, 새 CI 인가”를 판단한다 — insert vs update 의 결정이다. Reconciliation 은 “여러 소스에서 같은 필드 값이 들어올 때 어느 소스를 우선하는가”를 결정한다. Discovery 자동 스캔, Integration Hub 외부 연동, 수동 입력 모두 IRE 를 거친다. 소스마다 신뢰도와 갱신 주기가 다르기 때문에 식별 단계와 데이터 통합 단계를 분리하는 것이 더 정밀한 제어를 가능하게 한다.

Discovery Source Priority 는 Reconciliation 의 핵심 결정 변수다. 여러 소스가 같은 필드를 동시에 채울 때 어느 값을 최종 CI 에 반영할지를 결정하는 우선순위 체계다. CMDB Workspace 의 Duplicate Dashboard 는 이 메커니즘이 놓친 중복 CI 를 사후 탐지·병합하는 운영 도구다.

OOTB(Out-of-the-Box, 기본 제공) Australia 기준입니다. 인스턴스 버전·플러그인 구성에 따라 동작이 달라질 수 있습니다.

§1 — IRE 의 역할: Identification + Reconciliation 두 단계

IRE 의 진입점은 createOrUpdateCi() API 다. Discovery, Integration Hub, 수동 import — 어느 경로로 CI 데이터가 들어오든 IRE 를 통과하는 경우 이 API 가 payload 를 받아 처리한다. 인자·반환값 시그니처는 인스턴스 API 문서에서 확인을 권장한다.

1단계 — Identification: payload 가 들어오면 IRE 는 “이 CI 가 이미 CMDB 에 존재하는가”를 먼저 판단한다. Identification Rules 에 정의된 식별 속성(lookup attribute) 조합으로 기존 레코드를 검색한다. 일치하는 레코드를 찾으면 update, 찾지 못하면 create 경로로 분기한다.

2단계 — Reconciliation: CI 가 식별된 이후(update 경로) 에는 어느 소스의 값을 CMDB 에 반영할지를 결정한다. Reconciliation Rules 의 scope(어떤 필드를)와 Discovery Source Priority(어느 소스가 우선인지)가 최종 값을 결정한다. 두 단계를 분리한 덕분에 식별 기준과 데이터 우선순위를 독립적으로 설계할 수 있다.

#1 에서 예고한 “Duplicate CI 함정”은 Identification 단계가 실패할 때 발생한다. 동일 자산이 두 번 입력됐는데 Rule 이 같은 CI 로 인식하지 못하면 별도 레코드로 create 된다. 이 중복이 누적되면 Incident Affected CI 선택 오류, Service Map 분기, Performance Analytics 지표 왜곡으로 이어진다.

§2 — Identification Rules: 식별 속성 조합과 priority

Identification Rules 는 CI class 별로 정의되며, 하나의 CI identifier 가 여러 identifier entries 를 가진다. 각 entry 는 priority 값(낮은 숫자가 먼저 평가)과 lookup attribute 목록으로 구성된다.

표준 예시로 cmdb_ci_computer 의 priority 1 entry 는 Serial Number + Serial Number Type 조합으로 식별한다. 이 조합이 payload 에 존재하고 CMDB 에서 일치 레코드를 찾으면 update 된다. lookup attribute 가 하나라도 비어 있으면 IRE 는 다음 priority entry 로 넘어가고, 모든 entries 를 평가해도 일치를 찾지 못하면 신규 CI 로 create 된다.

핵심 한계는 lookup attribute 가 비어 있을 때 다. Discovery 가 Serial Number 를 수집하지 못하는 환경(일부 가상화 플랫폼, 특정 펌웨어)에서는 가장 강력한 식별자가 무력화된다. 다음 entry 가 IP Address + Host Name 으로 폴백되지만, IP 변경·호스트명 중복 가능성도 있다. Rule 설계 시 “어떤 환경에서 어떤 속성이 신뢰할 수 없는가”를 함께 고려해야 한다.

§3 — Reconciliation Rules + Discovery Source Priority

Identification 이 “같은 CI 인지”를 결정했다면, Reconciliation 은 “어느 소스의 데이터를 반영할지”를 결정한다. Reconciliation Rules 는 CI class 또는 field 단위로 정의하며, parent class 와 child class level 둘 다 정의할 수 있다. child class rule 이 parent class rule 보다 우선 적용된다.

같은 필드를 여러 소스가 동시에 업데이트하면 Discovery Source Priority 레코드가 최종 값을 결정한다. IRE 는 이 결정을 위해 cmdb_datasource_last_update 테이블을 참조하고, CI 와 소스의 조합은 cmdb_multisource_data 테이블에 저장된다. 두 테이블명은 검증된 사실이지만 인스턴스 구성에 따라 존재 여부를 확인하는 것을 권장한다.

ServiceNow Discovery

MID Server 를 통해 네트워크를 자동 스캔하여 CI 를 탐지·갱신. 일반적으로 가장 높은 precedence 를 받는 소스. 정기 스캔 주기에 따라 값이 갱신된다.

ITOM Visibility / Service Mapping

클라우드·컨테이너 환경 CI 와 서비스 토폴로지를 탐지. ServiceNow Discovery 와 별도 소스로 등록되어 필드별 precedence 를 독립적으로 설정할 수 있다.

3rd-party 소스 (예: Tanium, BigFix)

Integration Hub 또는 직접 API 로 연동되는 외부 도구들. 인스턴스 환경에 따라 소스명이 다르므로 실제 소스 목록은 인스턴스의 Discovery Source 설정에서 확인 필요.

Reconciliation Rules 설계 시 주의점이 있다. 같은 필드에 대해 parent class 와 child class rule 이 서로 다른 소스 우선순위를 정의하고 있다면 child class rule 이 우선 적용된다. 설계 후 의도한 소스가 실제로 값을 채우고 있는지 cmdb_multisource_data 를 통해 검증하는 것이 좋다.

§4 — Duplicate CI 탐지·병합 + IRE 한계

IRE 의 Identification 이 완벽하게 동작하면 Duplicate CI 는 원천 차단된다. 하지만 현실에서는 IRE 가 자동 탐지하지 못하는 케이스가 존재한다.

IRE 가 탐지하지 못하는 Duplicate 원인:

Identification Rule 미완성: lookup attribute 가 비어 있거나 rule 이 class 에 정의되지 않은 경우. IRE 는 create 를 선택한다.
다중 소스 분리 입력: 서로 다른 소스가 같은 자산을 약간 다른 이름·IP 로 각각 create 하면 Rule 이 같은 CI 로 인식하지 못한다.
수동 입력 + Discovery 혼재: 수동 생성 CI 가 있는 상태에서 Discovery 가 같은 자산을 탐지하면 두 레코드가 연결되지 않을 수 있다. dedup 로직 없는 외부 import 도 동일한 위험을 가진다.

이런 케이스를 사후에 처리하는 OOTB 도구가 CMDB Workspace 의 Duplicate Dashboard 다. Yokohama 이후 정식 도구로 제공되며, OOTB 템플릿과 Custom 템플릿으로 중복 CI 후보를 탐지한다. 탐지된 항목은 Remediate Duplicate Tasks 로 연결되어 Deduplication Templates 기반으로 병합한다. 가용 여부는 인스턴스 플러그인 구성에 따라 다를 수 있으므로 직접 확인을 권장한다.

#1 의 “Duplicate CI — 영향 분석 오류” 함정을 직접 회수하자. 동일 자산이 두 레코드로 분리되면 Incident Affected CI 선택이 엇갈리고 Service Map 이 분기된다. Identification Rules 가 1차 방어선이고, Duplicate Dashboard 가 2차 운영 방어선이다. 이 두 레이어를 함께 운영해야 CMDB Health Correctness score 를 안정적으로 유지할 수 있다.

§5 — CMDB Deep Dive 시리즈 wrap-up

4글로 이루어진 CMDB Deep Dive 시리즈의 종결편이다. 각 글이 쌓아 온 토대를 한 줄로 압축하면 다음과 같다.

#1 — 의미·역할

CMDB 는 ITIL 4 SCM 의 system of record 로, ServiceNow 전체 ITSM·ITOM·Service Mapping·Analytics 가 의존하는 dependency 그래프 척추다. 부실하면 모든 모듈이 함께 부실해진다.

#2 — 데이터 모델

Class Hierarchy 의 table extension 으로 자식이 부모 필드를 상속하고, sys_class_path STARTSWITH 패턴으로 하위 트리를 단일 쿼리로 매칭한다. Custom class 신설은 데이터 모델 차이·라이프사이클 분리·Discovery Rule 분기 기준으로 결정한다.

#3 — 관계 모델

cmdb_rel_ci 는 type 의 forward/reverse 쌍으로 양방향 그래프를 단일 레코드에 표현한다. Reference Field 는 단방향 1:N. Service Mapping 토폴로지는 cmdb_rel_ci 위에 구축된다.

#4 — IRE (이 글)

IRE 는 Identification(insert vs update 결정) + Reconciliation(소스 우선순위 결정) 두 단계로 데이터 입력의 게이트키퍼 역할을 한다. Duplicate Dashboard 가 2차 운영 방어선.

CMDB 운영의 다음 단계로는 세 가지 영역이 주로 언급된다. CMDB Health 모니터링 — Completeness·Correctness·Compliance score 를 지속 추적하고 staleness CI 를 정기 정리. CSDM(Common Service Data Model, 공통 서비스 데이터 모델) 적용 — Business Application, Technical Service 등 표준 레이어로 CMDB 데이터를 서비스 관리 전반에서 일관되게 활용할 수 있도록 정리. Governance — CI 등록·변경·폐기 정책, Identification Rule 과 Reconciliation Rule 의 변경 통제, Discovery Source 추가 시 우선순위 재설정 프로세스. 이 세 영역은 본 시리즈의 향후 확장 가능 주제다.

학습 허브

이 글은 ServiceNow CMDB 완전 정리 학습 허브의 4단계(식별·조정 — IRE & Discovery)다. CMDB 데이터 구조·관계 모델 위에서 데이터 품질을 지키는 단계이며, 전체 경로를 허브에서 순서대로 따라갈 수 있다.