ServiceNow CSDM 입문 — Common Service Data Model 의 5 도메인과 CMDB 레이어 (CSDM 4.0 기준 · 5.0 대응)

개요

CSDM(Common Service Data Model, 공통 서비스 데이터 모델)은 ServiceNow 가 ITSM(IT Service Management, IT 서비스 관리) · ITOM(IT Operations Management, IT 운영 관리) · ITAM(IT Asset Management, IT 자산 관리) 전반에 걸쳐 데이터를 일관된 구조로 다루기 위해 정의한 표준 데이터 모델이다. 단순히 “서비스 분류 체계”가 아니라, “어떤 테이블에 어떤 데이터를 저장하고, 도메인 간에 어떻게 연결할 것인가”를 규정하는 데이터 모델 표준에 가깝다. CMDB Deep Dive 4글 시리즈(#1 의미·역할 · #2 Class Hierarchy · #3 CI Relationship · #4 IRE)가 쌓아 온 CI 데이터·관계 모델·파이프라인 위에, CSDM 은 비즈니스 서비스 의미 레이어를 얹는다.

버전 정리부터 하자. Foundation / Design / Build / Manage Technical Services / Sell, Consume 5개 도메인으로 구성된 CSDM 4.0 이 오랫동안 생산 인스턴스의 사실상 기준이었고, CSDM 5.0 이 2025년 5월(Knowledge)에 출시되어 현재 최신 버전이다. 5.0 은 Ideation & Strategy / Design & Planning / Build & Integration / Service Delivery / Service Consumption / Manage Portfolios 를 포함한 7 도메인으로 재편됐지만, 기존 4.0 자산을 버리는 마이그레이션이 아니라 그 위에 얹히는 additive·backward-compatible 설계다. 그래서 많은 조직이 여전히 4.0 기반 위에서 5.0 을 점진 채택한다. 본 글은 이해의 토대로 4.0 의 5 도메인 구조를 중심으로 가르치되, 5.0 의 7 도메인 재편과 도메인 리네이밍을 §1 끝과 §4 에서 대응시켜 표기한다.

CMDB Deep Dive 시리즈의 맥락에서 짚으면, cmdb_ci 와 그 하위 CI class들(#2 Class Hierarchy), cmdb_rel_ci 양방향 관계 그래프(#3), IRE 파이프라인(#4)은 모두 CSDM 의 Build 및 Manage Technical Services 도메인 영역에서 실질적으로 동작한다. CSDM 은 이 인프라 레이어 위에 Business Application · Application Service · Service Offering 이라는 의미 레이어를 추가로 정의한다.

OOTB(Out-of-the-Box, 기본 제공) Australia 기준입니다. CSDM 적용 범위·테이블 구성·도메인 경계는 인스턴스 버전, 활성화된 플러그인, 조직의 채택 단계에 따라 달라질 수 있습니다.

---

§1 — CSDM 4.0 의 5 도메인

CSDM 4.0 은 서비스 관련 데이터를 다음 5개 도메인으로 분리한다. 각 도메인은 “어떤 관점의 데이터를 어느 테이블에 담는가”를 규정하며, 도메인 간 연결 방식도 함께 정의한다.

CSDM 5.0 은 이를 7 도메인 (Foundation / Ideation & Strategy / Design & Planning / Build & Integration / Service Delivery / Service Consumption / Manage Portfolios) 으로 재편한다. 핵심 변화는 Manage Technical Services → Service Delivery, Sell·Consume → Service Consumption 리네이밍과 Ideation & Strategy·Manage Portfolios 신설이다. 다만 5.0 은 4.0 위에 얹히는 additive·backward-compatible 설계라, 아래 §2~§5 의 도메인 역할과 테이블 매핑은 5.0 인스턴스에서도 화면의 도메인 라벨만 대응시키면 그대로 유효하다 — 세 핵심 엔터티(Business Application·Application Service·Service Offering)의 경계 역시 4.0→5.0 에서 안정적이다. 5.0 이 7 도메인으로 무엇을 더했고 4.0 인스턴스가 점진적으로 무엇을 해야 하는지는 CSDM 5.0 진화 글 에서 따로 깊이 다룬다.

---

§2 — 핵심 테이블과 CMDB Deep Dive 시리즈와의 연결

CSDM 의 실질적인 구현은 다음 핵심 테이블들을 중심으로 이루어진다. 모두 cmdb_ci 의 하위 class로 존재하므로, #2 Class Hierarchy 에서 다룬 table extension 메커니즘이 그대로 적용된다 — 부모 테이블 쿼리 시 자동 포함, sys_class_path STARTSWITH 패턴 활용 가능.

테이블명	CSDM 개념	도메인
cmdb_ci_business_app	Business Application — 비즈니스 목적의 애플리케이션 단위	Design
cmdb_ci_service_auto	Application Service — 자동 채움 서비스의 부모 테이블 (자식 클래스 레코드를 모아 보여줌, 직접 생성 대상 아님)	Manage Technical Services
cmdb_ci_service_discovered	Mapped Application Service — Service Mapping 의 top-down 매핑이 생성	Manage Technical Services
cmdb_ci_service_calculated	Calculated Application Service — cmdb_rel_ci 관계 traversal 로 자동 계산	Manage Technical Services
cmdb_ci_infra_service	Infrastructure Service — 인프라 레이어 서비스 단위	Manage Technical Services
service_offering	Service Offering — 거래·계약 단위 서비스 상품	Sell, Consume
cmdb_ci_service	(legacy) 구버전 generic service bucket — CSDM 분리 권장	—

cmdb_ci_service 는 CSDM 이전 generic bucket — 4.0 이후 위 5 테이블로 분리 권장 (§4 마이그레이션 참조). CI 간 연결은 #3 cmdb_rel_ci 양방향 그래프 — Depends on::Used by, Runs on::Runs type 쌍이 Business App → Application Service → Infrastructure 계층 연결에 활용. 안전한 채움은 #4 IRE 가 게이트키핑.

---

§3 — Service 흐름: Business Application → Application Service → Infrastructure

CSDM 은 비즈니스 → 기술 구현 → 인프라 의미 흐름을 4 레이어로 분리한다. Business Application (cmdb_ci_business_app) 은 비즈니스 관점 단위 (ERP·HR 포털 등). Application Service (cmdb_ci_service_auto, Calculated 권장) 는 실제 실행 단위로 cmdb_rel_ci 의 Runs on::Runs 등 type 으로 인프라와 연결. Infrastructure Service (cmdb_ci_infra_service) 는 서버·DB 클러스터 같은 인프라 단위로 구체 CI (cmdb_ci_server 등) 와 cmdb_rel_ci 로 연결. Service Offering (service_offering) 은 SLA·가격이 결합된 거래·계약 단위 (ITSM 포털 카탈로그, CSM 고객 계약). 이름이 비슷한 이 세 엔터티를 실무에서 어떻게 구분하고 “이 CI 를 무엇으로 모델링할지” 판단하는지는 세 엔터티 구분 글 에서 결정 트리와 흔한 오설계까지 따로 깊이 다룬다.

이 4 레이어 흐름에서 중요한 실전 포인트가 있다. Application Service 레이어는 부모 테이블 cmdb_ci_service_auto 아래 여러 자식 클래스로 구현되고, 어떤 클래스로 채우느냐가 CMDB 데이터 품질에 직접 영향을 준다. Calculated Application Service(cmdb_ci_service_calculated)는 cmdb_rel_ci 관계를 traverse 해 CI Association 을 자동 계산하므로 관계가 자동 반영된다. 반면 Mapped Application Service(cmdb_ci_service_discovered)는 Service Mapping 의 top-down 매핑이 생성하는데, OOTB 기본 동작으로는 cmdb_rel_ci 관계를 직접 만들지 않고 endpoint 와 CI Association(svc_ci_assoc)을 채운다 — 그래서 Service Map 이 정상으로 보여도 cmdb_rel_ci 는 비어 있어 관계 기반 CMDB Health Compliance 계산이 누락될 수 있다(#3 CI Relationship §4). Service Mapping 이 Application Service 를 ‘실제로 어떻게’ 채우는지 — entry point·pattern·svc_ci_assoc·IRE 메커니즘 — 는 Service Mapping 이 CSDM Application Service 를 채우는 방법 에서 따로 깊이 다룬다.

---

§4 — CSDM 채택의 함정·트레이드오프

---

§5 — Crawl/Walk/Run 단계적 채택

CSDM 을 한 번에 전사 적용하려는 시도는 대부분 범위 과부하로 좌초된다. ServiceNow 가 권장하는 Foundation → Crawl → Walk → Run 단계는 가치 입증과 범위 확장을 교대로 반복하는 접근이다.

MVP 대안 — thin vertical slice: 전사 적용 전 한 product 만 Foundation→Run 수직으로 완성. 작은 scope 에서 가치 입증 후 iterative 확장. 전사 동시 접근보다 리스크 낮음.

---

학습 허브

이 글은 ServiceNow CMDB 완전 정리 학습 허브의 비즈니스 서비스 레이어(CMDB Deep Dive 위에 얹히는 단계)다. 클래스 계층·관계·IRE 가 쌓은 기술 CI 위에 CSDM 을 어떻게 올리는지 전체 경로를 허브에서 따라갈 수 있다.

---

참조

• ServiceNow Docs — CSDM Framework overview (Australia)
• ServiceNow Docs — CSDM Implementation Phases
• ServiceNow CSDM 4.0 White Paper
• Plat4mation — CSDM 4.0 Domain Guide
• Plat4mation — Your A-Z guide to CSDM 5.0 — 7 도메인 재편·리네이밍 (2025-05 출시)
• CloudPeople — CSDM Implementation Guide
• ServiceNow Community — CSDM Forum