CMDB 의 의미와 역할 — Configuration Item, ITIL 4 Service Configuration Management, ServiceNow 실전 위치 (CMDB Deep Dive #1)

개요

ServiceNow 를 처음 접할 때 CMDB(Configuration Management Database, 구성 관리 데이터베이스)는 “자산 목록을 저장하는 DB” 정도로 이해되는 경우가 많다. 하지만 실제로는 ServiceNow 전체 플랫폼의 dependency 그래프 척추 역할을 한다. ITSM(IT Service Management, IT 서비스 관리) 의 영향 분석, ITOM(IT Operations Management, IT 운영 관리) 의 Discovery, Service Mapping 의 서비스 토폴로지, Performance Analytics 의 CI 단위 지표 — 이 모든 모듈이 CMDB 의 데이터 정확도에 직접 의존한다. CMDB 가 부실하면 각 모듈도 부실해진다.

ITIL 4 는 이 영역을 Service Configuration Management(SCM, 서비스 구성 관리) practice 로 정의한다. CMDB 는 별도의 독립 practice 가 아니라 SCM practice 의 system of record — 즉 SCM 이 관장하는 구성 정보를 lifecycle 동안 저장하고 관계를 유지하는 데이터 저장소다. ServiceNow OOTB(Out-of-the-Box, 기본 제공) 는 이 개념을 cmdb 테이블 위의 계층 구조로 구현한다. 어떤 계층 구조인지는 다음 글(#2 Class Hierarchy)에서 깊이 다룬다.

본 글은 CMDB Deep Dive 4글 시리즈의 첫 번째다. #1(이 글)은 CMDB 의 의미·역할·맥락을 specialist 시각으로 정리한다. #2 는 CI(Configuration Item, 구성 항목) Class Hierarchy 와 Schema 설계 원칙을, #3 은 CI Relationship 유형과 Service Mapping 연동을, #4 는 IRE(Identification and Reconciliation Engine, 식별·조정 엔진)와 Discovery 파이프라인을 다룬다.

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

---

§1 — CMDB 의 정의를 specialist 시각으로

ITIL 4 는 Service Configuration Management(SCM) practice 의 목적을 다음과 같이 정의한다: “accurate and reliable information about the configuration of services and the CIs that support them is available when and where it is needed.” SCM 은 구성 정보가 필요한 시점과 장소에서 정확하고 신뢰할 수 있는 형태로 제공되도록 보장하는 practice 다.

CMDB 의 공식 정의는 이렇다: “A database used to store configuration records throughout their lifecycle. It also maintains the relationships between configuration records.” 핵심은 두 가지 — lifecycle 동안의 레코드 저장, 그리고 레코드 간 관계 유지다. CI 하나만 정확히 저장하는 것이 아니라, CI 들이 서로 어떻게 연결되어 있는지를 보존하는 것이 CMDB 의 고유 역할이다.

ServiceNow OOTB 에서는 이 개념을 cmdb base table 위에 Class 계층으로 구현한다. 모든 CI 는 cmdb_ci 를 최상위로 하는 상속 구조 안에서 자신의 class 에 속한다 — cmdb_ci_server, cmdb_ci_application, cmdb_ci_network_adapter 같은 구체 class 로 분화된다. 이 class 구조의 설계 원칙과 함정은 #2 글에서 전체적으로 다룬다.

---

§2 — CMDB 가 ServiceNow 전체에 영향을 주는 5가지 경로

CMDB 의 데이터 품질이 실제로 영향을 미치는 경로는 5가지다. 각 경로를 이해하면 CMDB 투자의 우선순위를 잡을 수 있다.

(1) ITSM — Incident / Change / Problem 의 영향 분석: Incident 레코드의 “Affected CI” 필드, Change Request 의 CI 연결이 CMDB 데이터를 참조한다. CI 가 정확하게 등록되어 있어야 “이 CI 가 다운되면 어떤 서비스, 어떤 사용자가 영향받는가”를 즉각 조회할 수 있다. CI 데이터가 부정확하거나 관계가 끊어져 있으면 영향 분석 자체가 동작하지 않는다.

(2) Service Mapping — 서비스 토폴로지 실시간 구성: sn_itom_pattern 플러그인(Discovery and Service Mapping Patterns)을 활용한다. OOTB 에서는 5가지 매핑 방식을 제공한다 — top-down(서비스 엔트리 포인트에서 하향 탐색), tag-based(태그 기반 그룹화), traffic-based(네트워크 트래픽 분석), service mesh(서비스 메시 통합), dynamic CI groups(동적 CI 그룹화). 이 5가지 방식 모두 CMDB 에 이미 존재하는 CI 데이터를 실시간으로 활용하여 서비스 토폴로지를 구성한다. CI 가 부실하면 Service Map 자체가 불완전한 그래프가 된다.

(3) ITOM Discovery — CMDB 자동 채움의 역방향 의존: Discovery 가 네트워크를 스캔해 CI 를 CMDB 에 자동으로 채운다. 하지만 역방향 의존도 존재한다 — Discovery 의 Identification Rule 이 어떤 CI class 로 분류할지 판단할 때 기존 CMDB 데이터를 참조한다. CMDB 가 부실하면 중복 CI 생성(Duplicate CI) 위험이 높아지고, IRE(#4 글)의 조정 작업이 어려워진다.

(4) Performance Analytics — CI 단위 지표: 특정 application CI 의 가용성, 특정 서버 CI 의 MTTR(Mean Time to Repair) 같은 CI 기반 지표는 CMDB 의 CI 레코드가 정확히 존재해야 계산된다. CI 가 중복이거나 잘못 분류되어 있으면 지표 계산 자체가 왜곡된다.

(5) ITAM — 자산 vs CI 의 연결: ITAM(IT Asset Management) 의 자산(alm_asset)은 재무·계약 관점, CMDB 의 CI(cmdb_ci)는 서비스 제공 관점으로 분리되어 있다. 두 테이블의 연결 설계는 ITAM 의 핵심 판단 지점.

---

§3 — CMDB Health 3 metric

CMDB 의 데이터 품질을 측정하는 OOTB 프레임워크는 3개 metric — Completeness / Correctness / Compliance — 으로 구성된다. Xanadu(2024.2) 이후 CMDB Workspace 로 이동하며 KPI 계산 방식이 failed CIs / total CIs 비율로 변경됐고, 임계값 기반 설정은 제거됐다. OOTB 기본 설계 기준이며 인스턴스 정책에 따라 차이 가능.

---

§4 — CMDB 가 잘못 설계됐을 때의 cascading 함정

CMDB 설계 실수는 한 영역에 그치지 않고 ITSM·ITOM·Service Mapping 으로 연쇄 파급된다. 4가지 대표 패턴은 다음과 같다. (1)·(2) 는 시리즈 다음 글에서 깊이 다룰 주제다.

---

§5 — 무엇을 CI 로 박을지의 결정 기준 (실전 가이드)

CMDB 설계의 첫 번째 질문은 “무엇을 CI 로 등록할 것인가”다. 모든 자산을 CI 로 박는 것이 직관적으로 안전해 보이지만, 그것 자체가 over-classification 의 원인이 된다. 실전에서 유효한 세 가지 기준을 제시한다.

“변경 통제 대상” 기준: 누군가 이 자산을 변경할 때 추적과 승인이 필요한가. Change Management 의 Affected CI 로 등록될 가치가 있는 단위라면 CI 로 박아야 한다. 반대로 소모품이나 변경 이력을 추적할 필요가 없는 자산은 CI 가 아니라 자산(Asset)으로만 관리하는 것이 적절하다.

“서비스 영향 단위” 기준: 이 자산이 다운되거나 변경되면 어떤 서비스가 영향받는가. 서비스 토폴로지에서 노드로 의미 있게 존재할 수 있는지가 핵심이다. 독립적으로 서비스에 영향을 줄 수 없는 부속품 수준의 항목은 CI 보다는 관련 CI 의 필드 값으로 관리하는 것이 더 효율적인 경우가 많다.

“라이프사이클 추적” 기준: 이 자산의 install, move, add, change, dispose(IMACD) 단계가 각각 의미 있는 추적 대상인가. 라이프사이클을 추적할 실질적 필요가 없는 항목은 CI 로 박더라도 데이터가 빠르게 staleness 상태로 빠진다 — CMDB Health Correctness score 를 끌어내리는 원인이 된다.

Anti-pattern: “일단 다 넣고 나중에 정리하자” — CMDB 규모가 커질수록 IRE 조정·Discovery scan·Health score 개선 비용이 모두 늘어난다. 초기 설계에서 위 3 기준으로 등록 범위를 좁히는 것이 장기 비용이 낮다.

---

§6 — 시리즈 다음 글 예고

다음 글 #2 (Class Hierarchy + Schema) 에서는 cmdb_ci 상속 계층의 실제 구조, Custom CI class 를 언제 만들고 언제 만들지 않아야 하는지의 판단 기준, sys_class_path 와 테이블 상속이 GlideRecord 쿼리 성능에 미치는 영향을 다룬다. Over-classification 과 Under-classification 사이의 균형점을 잡는 것이 핵심 주제가 될 것이다.

본 #1 글의 핵심 메시지는 이것이다: CMDB 는 단독으로 존재하는 DB 가 아니다. ITIL 4 의 Service Configuration Management practice 를 구현하는 system of record 로서, ServiceNow 의 ITSM/ITOM/Service Mapping/Performance Analytics/ITAM 이 모두 여기에 의존한다. CMDB 의 Completeness·Correctness·Compliance 가 무너지면 각 모듈도 함께 무너진다. CMDB 에 투자하는 이유는 CMDB 자체를 위해서가 아니라, 그 위에 쌓인 모든 것들이 의미 있게 동작하도록 하기 위해서다.

---

학습 허브

이 글은 ServiceNow CMDB 완전 정리 학습 허브의 1단계(의미·역할)다. 클래스 계층 → 관계 그래프 → IRE 조정 → CSDM 레이어로 이어지는 전체 경로를 허브에서 순서대로 따라갈 수 있다.

---

참조

• ITIL 4 — Service Configuration Management practice
• ServiceNow Docs — CMDB overview
• ServiceNow Docs — CMDB Health Dashboard
• ServiceNow Docs — Service Mapping overview
• ServiceNow Docs — CMDB CI Class Manager
• ServiceNow Community — CMDB best practices