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

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

ServiceNow CSDM (Common Service Data Model) 4.0 의 5 도메인 구조, 핵심 테이블 (Business Application, Application Service, Service Offering), Crawl/Walk/Run 단계적 채택, CMDB Deep Dive 시리즈 위에 CSDM 이 어떻게 얹히는지 specialist 시각으로 정리.

· note cmdb
검증 인스턴스: OOTB Australia · 검증일 2026-05-27

개요

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 은 비즈니스 서비스 의미 레이어를 얹는다.

CSDM 의 현재 주류 버전은 CSDM 4.0으로, Foundation / Design / Build / Manage Technical Services / Sell, Consume 5개 도메인으로 구성된다. 이후 CSDM 5.0이 Ideation & Strategy / Design & Planning / Build & Integration / Service Delivery / Service Consumption / Manage Portfolios 를 포함한 7 도메인 구조로 진화 중이지만, 2026년 5월 기준 실제 생산 인스턴스의 채택 중심은 CSDM 4.0이다. 본 글은 CSDM 4.0 중심으로 다루며, 5.0 진화 방향은 필요한 지점에서 짧게 언급한다.

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개 도메인으로 분리한다. 각 도메인은 “어떤 관점의 데이터를 어느 테이블에 담는가”를 규정하며, 도메인 간 연결 방식도 함께 정의한다.

Foundation

Companies/Locations/Users/Groups referential data. CMDB 관계 그래프 미참여.

Design

APM (Application Portfolio Management) 테이블. 비즈니스 애플리케이션 포트폴리오·전략 계획.

Build

DevOps 가시성, SDLC (Software Development Lifecycle) 컴포넌트. 빌드·배포 파이프라인.

Manage Technical Services

ITOM·ITAM 관점 Technical Service. 인프라·기술 서비스를 CMDB CI 와 연결, 운영·모니터링 맥락.

Sell, Consume

ITSM·CSM (Customer Service Management) 관점 Business Service / Service Offering. 계약·소비·지원 단위.

CSDM 5.0 은 이를 7 도메인 (Foundation / Ideation & Strategy / Design & Planning / Build & Integration / Service Delivery / Service Consumption / Manage Portfolios) 으로 재편 — Sell·Consume 분리 + 포트폴리오 독립. 4.0→5.0 전환은 데이터 매핑 재작업 수반, 채택 로드맵 없는 조직은 서두를 필요 없음.


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

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

테이블명CSDM 개념도메인
cmdb_ci_business_appBusiness Application — 비즈니스 목적의 애플리케이션 단위Design
cmdb_ci_service_autoCalculated Application Service — Service Mapping 자동 계산 (권장)Manage Technical Services
cmdb_ci_service_discoveredMapped Application Service — 수동 유지, 일반적으로 비권장Manage Technical Services
cmdb_ci_infra_serviceInfrastructure Service — 인프라 레이어 서비스 단위Manage Technical Services
svc_offeringService 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_ciRuns on::Runs 등 type 으로 인프라와 연결. Infrastructure Service (cmdb_ci_infra_service) 는 서버·DB 클러스터 같은 인프라 단위로 구체 CI (cmdb_ci_server 등) 와 cmdb_rel_ci 로 연결. Service Offering (svc_offering) 은 SLA·가격이 결합된 거래·계약 단위 (ITSM 포털 카탈로그, CSM 고객 계약).

Business Applicationcmdb_ci_business_appDepends on::Used byApplication Servicecmdb_ci_service_auto (권장)Runs on::RunsInfrastructure Servicecmdb_ci_infra_serviceService Offeringsvc_offering거래·계약 단위

이 4 레이어 흐름에서 중요한 실전 포인트가 있다. Application Service 레이어의 선택이 CMDB 데이터 품질에 직접 영향을 준다. cmdb_ci_service_auto(Calculated Application Service)를 선택하면 Service Mapping 이 CI Associations 를 자동으로 계산하고 cmdb_rel_ci 를 채운다. 반면 cmdb_ci_service_discovered(Mapped Application Service)를 수동으로 유지하면 cmdb_rel_ci 가 자동으로 채워지지 않을 수 있어 CMDB Health Compliance 계산이 누락된다 — #3 CI Relationship §4 에서 다룬 Mapped Application Service 의 cmdb_rel_ci 미채움 위험과 동일한 함정이다.


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

cmdb_ci_service legacy 함정

CSDM 이전 generic bucket 을 그대로 두고 CSDM 테이블을 얹으면 서비스 데이터가 양쪽에 분산. 보고서·포털 일관성 깨짐. 마이그레이션 계획 필수.

Mapped Application Service 위험

cmdb_ci_service_discovered 는 수동 유지로 staleness 위험 + cmdb_rel_ci 자동 채움 안 됨 (#3 cross-ref). cmdb_ci_service_auto (Calculated) 권장.

Custom CI class 신설

#2 over-classification 경고가 CSDM 에도 적용. 표준 테이블 attribute 추가가 Custom class 보다 장기 비용 낮음.

4.0 → 5.0 마이그레이션 부담

7 도메인 전환 시 데이터 매핑·보고서 재작업. 5.0 전환 계획 있다면 4.0 정합성 먼저 확보가 선행 조건.


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

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

Foundation

Companies/Locations/Users/Groups referential data 정비. 부실 시 이후 단계 데이터 정합성 흔들림.

Crawl

Business Applications + Application Services + 최소 IPC(Incident/Problem/Change) 연결. 영향 분석 첫 루프.

Walk

Technical Services + Technical Service Offerings 추가. ITOM·ITAM 연결 강화, Service Map 토폴로지 의미 있어짐.

Run

Business Services + Service Offerings (svc_offering) sell/consume 완성. ITSM 포털·CSM 계약 연결.

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


학습 허브

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


참조