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

ServiceNow CSDM — Business Application · Application Service · Service Offering 구분과 모델링 결정 트리

이름이 비슷하고 일부가 같은 base class(cmdb_ci_service)를 공유해 가장 자주 혼동되는 세 CSDM 엔터티. 도메인 위치, ITOM·SPM 두 계층이 같은 클래스를 쓰면서도 직접 상호작용하지 않는 함정, 관계 그래프, '이 CI 는 무엇인가' 결정 트리, CSDM 5.0 리네이밍까지 실무 관점으로 정리.

· note cmdb

개요

CSDM 을 도입할 때 가장 자주 막히는 지점은 거창한 도메인 이론이 아니라 세 엔터티의 구분이다 — Business Application, Application Service, Service Offering. 이름이 서로 비슷한 데다, 일부는 같은 base class(cmdb_ci_service)를 공유하면서 의미와 소속 도메인은 완전히 다르다. 이 혼동을 그대로 둔 채 데이터를 채우면, BA 레이어가 비거나, ITOM 서비스와 SPM 서비스가 한 테이블에서 뒤엉키거나, Service Offering 의 stratification 을 표현하지 못하는 구조로 굳어진다.

이 글은 세 엔터티의 정의와 도메인 위치(§1), 같은 base class 가 만드는 두 계층 함정(§2), 셋이 연결되는 관계 그래프(§3), 실무에서 “이 CI 를 무엇으로 모델링할지” 판단하는 결정 트리(§4), 그리고 CSDM 5.0 의 도메인 리네이밍(§5)을 다룬다. CSDM 의 5 도메인 전체 구조와 채택 단계는 CSDM 입문 에서 먼저 정리했으므로, 이 글은 그 위에서 세 엔터티의 경계에 집중한다.

OOTB(Out-of-the-Box, 기본 제공) 기준입니다. 인스턴스 버전·플러그인·CSDM 버전(4.x/5.0)에 따라 도메인 명칭과 클래스 구성이 달라질 수 있습니다.

§1 — 세 엔터티의 정의와 도메인 위치

먼저 한 문장 정의와 소속 도메인이다. 도메인 명칭은 CSDM 4.x 기준이며, 5.0 변경은 §5 에서 다룬다.

엔터티도메인 (CSDM 4.x)한 문장 정의대표 테이블
Business ApplicationDesign비즈니스 기능을 수행하는 소프트웨어/시스템의 논리적 표현 — 사람이 “그 앱”이라고 부르는 것 (예: SAP, 사내 HR 시스템)cmdb_ci_business_app
Application ServiceManage Technical Services배포되어 실제 동작하는 애플리케이션 스택의 논리적 표현. Service Mapping 이 토폴로지를 채운다cmdb_ci_service 하위 (cmdb_ci_service_auto / cmdb_ci_service_discovered 등)
Service OfferingSell/Consume (Business SO) · Manage Technical Services (Technical SO)서비스를 소비자·기술 관점으로 stratify 한 변형 — 지역·환경·가격·가용성·SLA·지원그룹 같은 commitment 를 담는 단위service_offering

핵심은 셋이 서로 다른 추상화 수준에 있다는 점이다. Business Application 은 “무엇을 쓰는가”(비즈니스가 인식하는 시스템), Application Service 는 “그것이 어떻게 배포되어 돌아가는가”(기술 스택의 실체), Service Offering 은 “그것을 어떤 조건으로 제공·소비하는가”(commitment 가 붙은 제공 단위)를 표현한다.

Application Service 가 어떤 클래스(cmdb_ci_service_auto vs cmdb_ci_service_discovered)로 구현되느냐에 따라 cmdb_rel_ci 자동 채움 동작이 달라지는데, 이 부분은 CSDM 입문 에서 다뤘으므로 여기서는 반복하지 않는다.

§2 — 가장 흔한 함정: 같은 base class, 다른 계층

세 엔터티를 둘러싼 혼란의 뿌리는 하나다. cmdb_ci_service(base Service)를 ITOM 계열과 SPM/CSM 계열이 동시에 상속한다는 사실이다.

  • ITOM 계층: Application Service(cmdb_ci_service_auto 등) — Service Mapping·Event Management 가 쓰는 기술 스택의 표현.
  • SPM/CSM 계층: Business Service·Service Offering — Service Portfolio Management·Customer Service Management 이 쓰는 포트폴리오·제공 표현.

둘은 같은 base class 를 공유하므로 스키마상 한 가족처럼 보이지만, 실제로는 서로 다른 계층이고 직접 상호작용하지 않는다. cmdb_ci_service 를 generic bucket 처럼 쓰면서 ITOM Application Service 와 SPM Service 를 같은 테이블에 섞으면, 관계가 꼬이고 어느 쪽 도구도 데이터를 신뢰할 수 없게 된다.

여기서 파생되는 두 가지 흔한 오해를 명확히 정리한다.

오해 (a) — “Application Service 도 서비스의 한 종류 아닌가”

아니다. 이름에 ‘Service’ 가 들어가 서비스의 한 변형처럼 들리지만, Application Service 는 본질적으로 배포된 시스템/스택이다 — Service Mapping 이 산출하는 인프라 CI 묶음의 논리적 표현이지, 소비자에게 제공되는 “서비스”가 아니다.

오해 (b) — “Business Application = Business Service = Service Offering”

셋 다 다르다. Business Application 은 시스템(Design 도메인), Business Service 는 비즈니스가 인식하는 서비스(Sell/Consume), Service Offering 은 그 서비스의 제공 변형(commitment 포함)이다. 이름의 유사성에 끌려 하나로 뭉뚱그리면 포트폴리오 계층이 무너진다.

§3 — 셋이 어떻게 연결되나 (관계 그래프)

세 엔터티는 reference 필드가 아니라 cmdb_rel_ci 양방향 관계로 연결된다 (관계 모델 자체는 CI Relationship vs Reference Field 참고). 레이어 흐름으로 그리면 다음과 같다.

[Sell/Consume]        Business Service ──▶ Business Service Offering
                                                   │ consumes
                                                   ▼
[Manage Tech Svc]     Technical Service ──▶ Technical Service Offering
                                                   │ relates to
                                                   ▼
                                          Application Service (배포 스택)
                                                   ▲
                                       Depends on │ (Used by)
[Design]                              Business Application
                                                   │ Depends on / Runs on
                                                   ▼
                                          Infrastructure CIs

읽는 방향은 두 갈래다.

  • 위에서 아래(소비 → 기술): Business Service 의 Business Service Offering 이 Manage Technical Services 도메인의 요소를 consume 한다. Technical Service 는 Technical Service Offering 으로 stratify 되고, 그 offering 이 하나 이상의 Application Service 에 연결된다.
  • 아래에서 위(시스템 → 스택): Business Application 은 그것을 실제로 구현하는 Application Service 에 Depends on::Used by 로 연결된다. 즉 “이 비즈니스 앱은 어떤 배포 스택으로 실현되는가”가 이 관계로 표현된다.

관계 타입(Depends on::Used by 등)의 정확한 OOTB 명칭과 방향은 인스턴스에서 확인하는 편이 안전하다. 핵심은 세 엔터티가 한 테이블의 평면이 아니라 도메인을 가로지르는 그래프로 연결된다는 점이다.

§4 — 모델링 결정 트리: “이 CI 는 무엇인가”

실무에서 가장 자주 받는 요청은 추상적이다. “SAP 를 CMDB 에 넣어 주세요.” 이때 SAP 를 BA·AS·SO 중 무엇으로 만들지가 첫 갈림길이다. 다음 순서로 판단한다.

  1. 비즈니스가 “쓰는 시스템”으로 인식하는 대상인가? → Business Application 을 만든다 (cmdb_ci_business_app). “우리는 SAP 를 쓴다”의 SAP 가 여기.
  2. 그 시스템이 배포되어 동작하는 구체 스택(앱 인스턴스 + 인프라)을 토폴로지로 표현해야 하는가? → Application Service 를 만든다 (Service Mapping). “운영계 SAP ERP 스택”이 여기. Business Application 과는 Depends on 으로 연결.
  3. 그 서비스를 소비자에게 commitment(지역·환경·SLA·가격·지원그룹)와 함께 ‘제공’하는 단위가 필요한가? → Service Offering 을 만든다 (service_offering). “SAP ERP — APAC 운영, 24x7, Gold SLA”가 여기.

세 질문의 답은 배타적이지 않다 — 같은 SAP 가 BA 1건, Application Service 여러 건(환경별), Service Offering 여러 건(지역·SLA별)으로 동시에 존재하는 게 정상이다. 흔한 오설계는 이 다대다 구조를 무리하게 눌러 담을 때 발생한다.

오설계 (a) — Business Application 을 Application Service 로 만들어 Service Mapping 에 직접 물림: BA 레이어가 비고, 비즈니스 관점 보고(어떤 앱이 영향받았나)가 깨진다. 시스템 인식 대상은 BA 로 두고, 스택은 별도 Application Service 로 분리해야 한다.

오설계 (b) — Service 와 Service Offering 을 1:1 로 강제: offering 의 본질은 stratification(같은 서비스를 지역·환경·SLA 로 변형)이다. 1:1 로 묶으면 “APAC Gold” 와 “EMEA Silver” 를 구분할 자리가 사라진다.

오설계 (c) — SPM 의 Business Service 와 ITOM 의 Application Service 를 동일시: §2 의 두 계층 혼용이다. 같은 cmdb_ci_service 후손이라는 이유로 한 덩어리로 다루면 Service Mapping 과 포트폴리오가 서로의 데이터를 오염시킨다.

§5 — CSDM 5.0 현행성과 채택

위 도메인 명칭은 CSDM 4.x 기준이다. CSDM 5.0(2025년 5월 출시) 에서 구조가 7 도메인으로 확장되며 명칭이 다음과 같이 재편됐다.

  • Manage Technical Services → Service Delivery
  • Sell/Consume → Service Consumption
  • 신규 도메인 추가(Ideation & Strategy, Manage Portfolios 계열) 및 Technical Service 계열 용어가 Technology Management Service 로 정리되는 흐름.

중요한 점은, 세 엔터티(Business Application · Application Service · Service Offering)의 역할과 경계는 4.x→5.0 에서 안정적이라는 것이다. 바뀐 것은 주로 도메인 명칭이므로, 5.0 인스턴스에서 “Service Delivery” 도메인을 보더라도 위 §1~§4 의 구분과 결정 트리는 그대로 적용된다. (자신의 인스턴스가 4.x 인지 5.0 인지에 따라 화면의 도메인 라벨만 대응시키면 된다.)

채택 순서는 CSDM 입문 에서 다룬 Crawl/Walk/Run 을 따른다 — Foundation 데이터와 Business Application↔Application Service 매핑부터 채우고(Crawl), Service Offering 의 commitment·SLA 모델링은 Walk/Run 단계로 미루는 것이 안전하다. 세 엔터티를 한 번에 완벽히 채우려다 §4 의 오설계로 빠지는 경우가 많다.

학습 허브

이 글은 ServiceNow CMDB 완전 정리 학습 허브의 비즈니스 서비스 모델링 편이다. 클래스 계층·관계·IRE 가 쌓은 기술 CI 위에 CSDM 의 세 핵심 엔터티를 어떻게 구분해 얹는지를 다룬다 — 허브에서 CMDB 구조부터 CSDM 채택까지 전체 경로를 따라갈 수 있다.

참조

  • CSDM 입문 — 5 도메인과 CMDB 레이어 — 도메인 전체 구조·6 테이블·Crawl/Walk/Run 채택
  • CI Relationship vs Reference Field — 세 엔터티를 잇는 cmdb_rel_ci 양방향 관계 모델
  • ServiceNow 공식 CSDM Framework 문서 및 CSDM 5 Whitepaper — 도메인 명칭·클래스·관계 타입의 정확한 최신 정의는 자신의 인스턴스 CSDM 버전에서 확인 권장