ServiceNow CMDB 완전 정리
ServiceNow CMDB(Configuration Management Database)는 ITSM·ITOM·Service Mapping·ITAM 이 함께 의존하는 구성 데이터의 중심 저장소다. 문제는 대부분의 자료가 CMDB 를 “CI 를 담는 테이블 하나”로만 다룬다는 점이다. 실전에서 CMDB 가 무너지는 지점은 거의 항상 구조 — 클래스 계층을 잘못 잡거나, 관계 모델을 reference 필드로 흉내 내거나, IRE 조정 규칙 없이 Discovery 를 돌려 중복 CI 가 쌓이는 곳이다.
이 페이지는 CMDB 를 단일 테이블이 아니라 클래스 계층 → 관계 그래프 → 식별·조정 파이프라인 → 비즈니스 서비스 레이어로 이어지는 하나의 데이터 모델로 이해하기 위한 학습 허브다. 아래 7개 글을 순서대로 따라가면 cmdb_ci 의 내부 구조부터 CSDM 채택과 Service Mapping populate, 그리고 CMDB 트리를 실제로 쿼리하는 스크립팅까지를 specialist 시각으로 연결할 수 있다.
CMDB 를 “레이어”로 보는 관점
CMDB 설계 사고는 아래로 갈수록 의미가 쌓이는 4개 레이어로 정리하면 흔들리지 않는다.
- 데이터 구조 레이어 —
cmdb_ci의 table extension 과 클래스 계층. 어떤 CI 를 어느 클래스에 둘지가 이후 모든 dot-walking·쿼리·리포트의 토대다. - 관계 레이어 —
cmdb_rel_ci양방향 그래프. Reference 필드의 단방향 연결과는 근본적으로 다른 모델이며, Service Mapping 토폴로지가 여기서 나온다. - 식별·조정 레이어 — IRE(Identification and Reconciliation Engine). 여러 Discovery Source 가 같은 CI 를 서로 다르게 보고할 때 무엇을 진실로 삼을지 결정한다.
- 비즈니스 서비스 레이어 — CSDM. 위 3개 레이어가 쌓아 올린 기술 CI 위에 “이게 어떤 비즈니스 서비스인가”라는 의미를 얹는다.
CMDB 의 의미·역할 자체(ITIL 4 맥락, CMDB Health metric, 잘못된 설계의 cascading 함정)는 학습 경로 1번 글에서 깊게 다룬다. 이 허브는 각 레이어를 어떤 순서로, 어떤 질문을 들고 읽으면 되는지를 안내한다.
학습 경로 (7단계)
1. CMDB 의 의미와 역할 — 왜 척추인가
CMDB 의 의미와 역할 (CMDB Deep Dive #1) 은 CMDB 가 ITSM·ITOM·Service Mapping 의 척추인 이유를 ITIL 4 의 Service Configuration Management 정의와 ServiceNow OOTB 구현으로 연결한다. CMDB Health 3 metric 과 잘못 설계된 CMDB 가 만드는 함정까지 — “왜 구조를 신경 써야 하는가”의 출발점.
2. Class Hierarchy 와 sys_class_path — 데이터 구조의 뼈대
CMDB Class Hierarchy 와 sys_class_path (CMDB Deep Dive #2) 는 cmdb_ci 의 table extension 메커니즘, sys_class_name 의 dot-walking 영향, sys_class_path 를 이용한 자식 클래스 매칭 쿼리를 다룬다. Custom CI class 를 신설할지 기존 클래스를 쓸지의 판단 기준 — over-/under-classification 의 균형이 핵심.
3. CI Relationship vs Reference Field — 관계 그래프 모델
CI Relationship vs Reference Field (CMDB Deep Dive #3) 은 cmdb_rel_ci 양방향 그래프와 Relationship Type 의 의미, 그리고 reference 필드 단방향과의 결정적 차이를 짚는다. Service Mapping 토폴로지가 왜 reference 필드가 아니라 관계 테이블 위에 서는지를 이해하는 단계.
4. IRE & Discovery — 식별·조정 파이프라인
IRE & Discovery (CMDB Deep Dive #4, 종결편) 는 Identification Rules 의 lookup attribute 조합, Reconciliation Rules 의 Discovery Source Priority, 중복 CI 탐지·병합을 다룬다. 여러 소스가 같은 CI 를 다르게 보고할 때 CMDB 가 일관성을 유지하는 메커니즘 — 데이터 품질의 마지막 관문.
5. CSDM 입문 — 비즈니스 서비스 레이어
CSDM 입문 — 5 도메인과 CMDB 위의 레이어 는 CSDM 4.0 의 5 도메인(Foundation·Design·Build·Manage Technical Services·Sell/Consume) 구조와 핵심 테이블(Business Application, Application Service, Service Offering), Crawl/Walk/Run 단계적 채택을 정리한다. 1~4번이 쌓은 기술 CI 위에 비즈니스 의미를 얹는 방법.
6. Service Mapping 이 Application Service 를 채우는 방법 — populate 실행
Service Mapping 이 CSDM Application Service 를 채우는 방법 은 5번이 정의한 Application Service 가 “실제로 어떻게” 채워지는지를 다룬다 — top-down entry point 에서 dependency chain 추적, 결과가 cmdb_ci_service_discovered(부모 cmdb_ci_service_auto 아님)에 안착, svc_ci_assoc(관계가 아닌 CI Association) 자동 채움, IRE 통과, Business Application 상향 링크는 수동이라는 경계까지. 관계(3번)·IRE(4번)·CSDM(5번) 레이어가 교차하는 populate 실행편.
7. Reference Qualifier 와 cmdb_ci 트리 — 실전 쿼리
Reference Qualifier — Simple/Dynamic/Advanced 와 cmdb_ci 트리 함정 은 CMDB 트리를 실제로 필터링·쿼리할 때 부딪히는 부모-자식 필터링, 순환 참조, N+1 문제를 다룬다. 구조를 이해한 뒤 그 위에서 CI 를 안전하게 선택·제한하는 스크립팅 실전편.
이 경로를 마치면
cmdb_ci클래스 계층을 보고 어디에 CI 를 둘지, custom class 가 필요한지 판단할 수 있다.- 관계는
cmdb_rel_ci그래프로, 단순 연결은 reference 필드로 — 둘을 의식적으로 구분해 설계할 수 있다. - IRE 식별·조정 규칙을 읽고 중복 CI 의 원인을 Discovery Source Priority 관점에서 추적할 수 있다.
- CMDB 위에 CSDM 을 단계적으로 얹는 채택 경로(Crawl/Walk/Run)를 그릴 수 있다.
- Service Mapping 이 Application Service 를 어느 클래스·테이블(
svc_ci_assoc)에 어떻게 채우는지, 자동화의 경계(BA 상향 링크는 수동)를 설명할 수 있다.