ServiceNow CMDB CI Relationship vs Reference Field — cmdb_rel_ci 양방향 그래프와 단방향 참조 (CMDB Deep Dive #3)

개요

CMDB Deep Dive #1 에서 “Missing relationships → Service Map 무의미”를 4가지 cascading 함정 중 하나로 예고했다. 그 함정의 근원은 단순하다. CI 는 존재하는데 CI 간의 연결이 없으면 CMDB 는 고립된 점들의 집합일 뿐, 의미 있는 그래프가 되지 않는다. #2 에서는 cmdb_ci 의 table extension 메커니즘과 class hierarchy 라는 데이터 모델 토대를 다뤘다. 본 #3 는 그 토대 위에서 CI 간 관계를 표현하는 두 가지 방식의 전체 그림을 다룬다.

두 가지 방식의 핵심 차이는 방향성이다. cmdb_rel_ci 기반의 CI Relationship 은 양방향 그래프 모델로 forward type 과 reverse type 을 단일 레코드에 쌍으로 저장한다. Reference Field 는 단방향 — A 레코드에서 B 레코드를 가리키는 포인터 하나로, B 에서 A 를 찾으려면 별도 역방향 조회가 필요하다.

Service Mapping 의 서비스 토폴로지는 cmdb_rel_ci 위에 구축된다. 하지만 Application Service 의 유형 선택(Calculated vs Mapped)에 따라 cmdb_rel_ci 가 실제로 채워지는지 여부가 달라진다. 이 차이를 모르면 Service Map 이 토폴로지를 표시하는 것처럼 보여도 cmdb_rel_ci 는 비어 있는 상태가 된다.

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

§1 — Reference Field 단방향

Reference Field 는 ServiceNow 의 가장 기본적인 관계 표현 수단이다. 한 테이블의 레코드가 다른 테이블의 레코드를 sys_id 로 가리키는 포인터 필드다. 예를 들어 incident.assigned_to 는 sys_user 레코드를 가리키고, cmdb_ci_computer.manufacturer 는 core_company 레코드를 가리킨다.

단방향이라는 의미는 이렇다. A 레코드가 B 를 참조할 때, A 에서 B 로 가는 경로는 직접 dot-walk 로 즉시 접근된다. 반대로 B 에서 A 를 찾으려면 “B 를 참조하는 A 가 무엇인가”라는 역방향 쿼리를 별도로 실행해야 한다 — getRefRecord() 또는 addQuery('reference_field', b_sys_id) 형태의 역조회다. Reference Field 는 1:N 모델이다. 한 필드는 한 레코드만 가리킨다. N:M 관계를 표현하려면 관계 테이블을 별도로 설계하거나 CI Relationship 을 사용해야 한다.

Reference Field 는 표준 reporting 과 단순 1:N 참조에 적합하다. 보고서 필터, Condition Builder, List View 에서 참조 필드는 인덱스 기반으로 빠르게 조회되고, 플랫폼 표준 UI 컴포넌트와 잘 맞는다. dependency 시각화나 영향 분석이 필요하지 않은 단순 연결이라면 Reference Field 로 충분하다.

§2 — cmdb_rel_ci 의 양방향 그래프

cmdb_rel_ci 의 각 레코드는 세 핵심 필드로 구성된다: parent(부모 CI의 sys_id), child(자식 CI의 sys_id), type(cmdb_rel_type 테이블 참조). 이 세 필드가 CI 간 관계 하나를 완전히 정의한다.

양방향이라는 특성은 type 필드에 있다. cmdb_rel_type 테이블의 각 레코드는 forward name 과 reverse name 을 쌍으로 가진다. 예를 들어 parent=Application CI, child=Server CI, type=Runs on::Runs 관계가 하나 있다면, Application → Server 방향에서는 “Runs on”, Server → Application 방향에서는 “Runs” 로 읽힌다. 단일 레코드가 두 방향을 모두 표현한다 — 반대 방향을 위한 별도 레코드가 생성되는 것이 아니다.

OOTB 에서 자주 사용하는 표준 type 쌍은 다음과 같다. Depends on::Used by, Runs on::Runs, Contains::Contained by, Hosts::Hosted on. 이 4가지는 대부분의 인스턴스에서 기본 제공되는 type 이지만, 전체 OOTB 목록은 인스턴스의 cmdb_rel_type 테이블에서 직접 확인하는 것을 권장한다 — 버전과 플러그인 구성에 따라 차이가 있을 수 있다.

§3 — Reference Field vs CI Relationship 선택 기준

어느 방식을 선택할지는 세 가지 상황으로 구분된다. 단순히 “더 나은 방식”이 있는 게 아니라, 목적과 사용 맥락에 따라 적합한 방식이 달라진다. CSDM(Common Service Data Model, 공통 서비스 데이터 모델) 2.0 가이드도 일부는 CI Relationship, 일부는 reference attribute 로 표현하도록 권장하는 선택적 혼합 전략을 취한다.

단방향 단순 참조 → Reference Field

A 에서 B 를 가리키는 1:N 참조, 표준 보고서 필터, Condition Builder 활용이 주목적일 때. 예: cmdb_ci_computer.manufacturer → core_company. dependency 시각화나 영향 분석 불필요.

N:M + 의미 있는 type → CI Relationship

여러 CI 가 서로 다른 방향·type 으로 연결되는 dependency 표현, Service Map 토폴로지 구성, Event Management 영향 분석 통합이 필요할 때. cmdb_rel_ci 의 type 필드가 관계의 의미(Runs on vs Depends on)를 구분한다.

CSDM 2.0 혼합 전략

CSDM 2.0 가이드는 Service ↔ Service Offering 관계는 CI Relationship 으로 dependency map 에 표현하고, CI 의 소유 조직 같은 단순 참조는 reference attribute 로 유지하도록 권장한다. 용도에 따른 선택적 혼합.

§4 — Service Mapping 토폴로지의 데이터 토대

Service Mapping 이 그리는 서비스 토폴로지는 cmdb_rel_ci 를 데이터 토대로 삼는다. CI 들이 어떻게 연결되어 있는지를 cmdb_rel_ci 의 parent-child-type 구조에서 읽어 그래프로 그린다. CMDB Deep Dive #1 에서 “Missing relationships → Service Map 무의미”를 예고한 근원이 이것이다. cmdb_rel_ci 가 비어 있으면 Service Mapping 은 그릴 토폴로지가 없다.

여기서 중요한 분기가 있다. Application Service 의 유형 — Calculated Application Service 와 Mapped Application Service — 에 따라 cmdb_rel_ci 가 실제로 채워지는지 여부가 달라진다.

Calculated Application Service 는 service association table 이 Application Service + CIs + relationships 를 기반으로 계산하여 자동으로 CI Associations 를 변환한다. 이 경우 cmdb_rel_ci 가 자동으로 채워지며, CMDB Health Compliance 계산과 영향 분석에 반영된다.

Mapped Application Service (Service Mapping 플러그인 사용) 는 Service Mapping 이 직접 토폴로지를 탐색하고 Service Map 을 그리지만, OOTB 기본 동작으로는 cmdb_rel_ci 에 CI Relationship 레코드를 자동 생성하지 않는 것으로 알려져 있다. 인스턴스 설정과 버전에 따라 동작 차이가 있을 수 있으므로 해당 인스턴스에서 직접 확인을 권장한다.

Service Map 은 이 cmdb_rel_ci 기반의 토폴로지를 summary view 로 표시한다. 모든 dependency 정보를 표시하지 않고 가장 의미 있는 연결을 요약해 보여주는 구조다 — 정보 과부하를 방지하기 위한 설계다. 따라서 Service Map 에 표시되지 않는 관계라도 cmdb_rel_ci 에는 존재할 수 있고, 역으로 Service Map 이 관계를 보여준다고 해서 반드시 cmdb_rel_ci 가 채워져 있는 것도 아니다.

§5 — 함정·트레이드오프

양방향 = 데이터 중복? — 단일 레코드 오해

”양방향이면 forward + reverse 두 레코드가 생기는 것 아닌가”라는 오해가 흔하다. cmdb_rel_ci 는 단일 레코드에서 type 의 forward/reverse 쌍으로 양방향을 표현한다. 데이터 중복 없이 양방향 읽기가 가능한 구조다. 다만 구체 구현은 인스턴스 정책에 따라 다를 수 있다.

Relationship Type 잘못 선택 → 토폴로지 왜곡

Application 이 Server 위에서 실행 중이라면 Runs on type 이 정확하다. 이 관계를 Depends on 으로 잘못 설정하면 Service Map 의 방향성 표현, Event Management 의 영향 계산이 달라진다. type 선택은 단순 라벨이 아니라 토폴로지 의미를 결정한다.

Reference Field + CI Relationship 동시 존재 — 중복 데이터

같은 관계를 Reference Field 와 CI Relationship 으로 동시에 표현하면 한쪽 값이 업데이트될 때 다른 쪽이 stale 상태가 된다. 동일 관계는 한 방식으로만 유지하는 것이 데이터 일관성 관리에 유리하다.

Mapped Application Service — cmdb_rel_ci 미채움 위험

Service Mapping 을 사용하는 Mapped Application Service 는 OOTB 기본 동작으로 cmdb_rel_ci 를 자동 채우지 않을 가능성이 있다. Service Map 이 정상적으로 보인다고 해서 CMDB Health Compliance 계산이나 영향 분석용 cmdb_rel_ci 가 실제로 채워져 있다고 단정하면 안 된다. 인스턴스에서 직접 확인 필수.

§6 — 다음 글 예고

다음 글 #4 는 CMDB Deep Dive 시리즈의 마지막으로, IRE(Identification and Reconciliation Engine, 식별·조정 엔진)와 Discovery 파이프라인을 다룬다. Discovery 가 CI 를 발견했을 때 IRE 가 기존 cmdb_rel_ci 데이터와 어떻게 조정하는지, Duplicate CI 를 어떻게 탐지하고 병합하는지, Identification Rule 과 Reconciliation Rule 의 설계가 실제 CMDB 데이터 품질에 어떤 영향을 주는지가 핵심 주제다.

본 #3 글의 핵심은 세 가지다. cmdb_rel_ci 의 CI Relationship 은 type 의 forward/reverse 쌍으로 양방향 그래프를 단일 레코드에 표현한다. Reference Field 는 단방향 1:N 포인터로 dependency 시각화보다 표준 참조·보고에 적합하다. Service Mapping 토폴로지는 cmdb_rel_ci 위에 구축되지만, Mapped Application Service 는 OOTB 기본 동작으로 cmdb_rel_ci 를 자동 채우지 않을 수 있으므로 인스턴스 정책 확인이 필수다.

학습 허브

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