ServiceNow Service Mapping 이 CSDM Application Service 를 실제로 채우는 방법 — entry point 에서 svc_ci_assoc·IRE 까지 populate 메커니즘
top-down/pattern·tag·traffic·ML 4가지 매핑 방식별 결과 클래스와 entry point 에서 시작하는 dependency chain 추적 방법, 결과가 cmdb_ci_service_discovered(Mapped Application Service)에 안착하는 경로, svc_ci_assoc 에 CI 멤버십이 자동 채워지는 원리, cmdb_rel_ci 와 svc_ci_assoc 의 역할 구분, IRE 통과 시 discovery_source 처리, Business Application 상향 링크는 수동 governance 대상임을 명확히 하는 경계, 그리고 populate 실패 6종 트러블슈팅까지 실무 관점으로 정리.
개요
CSDM 에서 Application Service 레이어를 어떻게 구분하고 모델링할지는 CSDM — Business Application · Application Service · Service Offering 구분이 정의·결정 트리·오설계까지 정리했다. 이 글은 그 위에서 ‘어떻게(HOW)‘로 넘어간다. Application Service 가 존재한다고 선언만 해서는 아무것도 채워지지 않는다 — Service Mapping 이 구체적으로 어떤 경로로 토폴로지를 만들어 채우는지, 그 결과가 어느 테이블에 어떤 형태로 안착하는지를 이 글이 다룬다.
시작하기 전에 가장 흔한 오해 두 가지를 선제 정리한다.
오해 (a) — “Service Mapping 이 cmdb_ci_service_auto 레코드를 만든다”
아니다. cmdb_ci_service_auto(라벨 ‘Application Service’, CSDM 5.0/Yokohama 에서 라벨이 ‘Service Instance’로 바뀌었으나 테이블명은 불변)는 부모(parent) 테이블이다 — 직접 레코드를 생성하는 대상이 아니라 자식 클래스의 레코드를 모아 보여주는 상위 테이블이다. top-down Service Mapping 이 실제로 생성하는 것은 그 자식 클래스인 **cmdb_ci_service_discovered(Mapped Application Service)**다.
오해 (b) — “Service Mapping 이 cmdb_rel_ci 관계를 직접 채운다”
아니다. top-down Service Mapping 은 cmdb_rel_ci 를 직접 생성하지 않고 endpoint 를 만들고 svc_ci_assoc(Service Configuration Item Association) 에 CI 멤버십을 채운다. cmdb_rel_ci 는 Service Mapping 이 traverse 하는 하위 CI 의존관계를 저장하는 별개 경로다.
이 두 정정을 기반으로 §1~§7 이 populate 메커니즘 전체를 연다.
OOTB(Out-of-the-Box, 기본 제공) Australia 기준입니다. Service Mapping 의 매핑 방식·entry point·
svc_ci_assoc채움 동작은 인스턴스 버전·플러그인(Service Mapping/Discovery/Predictive Intelligence)·CSDM 버전(4.x/5.0)에 따라 달라질 수 있으며, 정확한 클래스·필드·스케줄 job 명은 대상 인스턴스에서 확인을 권장합니다.
§1 — Service Mapping 의 4가지 매핑 방식
ServiceNow 는 공식적으로 ‘Choose method for discovering and mapping services’ 가이드에서 네 가지 매핑 방식을 제시한다. 방식마다 데이터 소스·대상 환경·결과 자식 클래스가 다르다.
| 매핑 방식 | 대상 환경 | 결과 자식 클래스 | 데이터 소스 |
|---|---|---|---|
| pattern-based(top-down) | on-prem/COTS(SAP·Oracle)/mission-critical | cmdb_ci_service_discovered | MID Server + credential + pattern |
| tag-based | cloud·가상화·컨테이너 | cmdb_ci_service_by_tags | cmdb_key_value 태그 |
| traffic-based | pattern-based 보완 | (cmdb_ci_service_discovered 와 결합) | TCP 연결(cmdb_tcp), netstat/lsof |
| Predictive Intelligence(ML) | traffic-based 연결 필터링 | (traffic-based 와 결합) | connection suggestion 모델 |
방식 선택 로직: on-prem/COTS 정밀 토폴로지에는 top-down, cloud·컨테이너에는 tag-based(entry point 불필요). traffic-based 는 독립 트랙이 아닌 pattern-based 보완 — raw TCP 연결의 노이즈를 Predictive Intelligence 가 필터링하고 admin review gate 를 거친다. 즉 traffic + ML 결합 출력이 현장의 ‘ML 기반 매핑’이다.
현행(2025–2026) 권장 조합은 태그+ML 로 대부분 커버, top-down 은 legacy/COTS 정밀 구간 예약하는 hybrid 병행이다 — 대체가 아니다.
§2~§6 은 top-down(pattern-based) 을 중심으로 populate 메커니즘을 분해한다.
§2 — top-down 런타임: entry point 에서 dependency chain 까지
top-down 의 시작점은 entry point 다 — top-down 전용 개념으로, tag-based·ML 에는 불필요하다. 표준 타입은 URL(HTTP/HTTPS, 가장 일반적)·TCP(host:port)·DB Connection String 이며, SAP·Exchange·Citrix 등 앱별 사전 구성 타입도 존재한다.
런타임 흐름은 반복 탐색이다. entry point CI 의 pattern 을 실행해 다음 CI 와의 connection 을 찾고, 새 connection 이 없어질 때까지 반복하면서 dependency chain(토폴로지)을 구성한다.
이 traversal 이 동작하려면 MID Server 가 경로상 모든 호스트에 도달 가능해야 하고 credential 이 구성돼야 한다. horizontal Discovery 가 활성화·운영 상태여야 한다는 전제도 있지만, horizontal Discovery 제품 라이선스는 별도 불필요 — Service Mapping 이 자체 vertical discovery 엔진을 내장한다. horizontal Discovery 와 top-down 의 역할 경계·IRE·source priority 상세는 CMDB IRE · Discovery · Reconciliation으로 위임한다.
§3 — 결과는 어느 클래스에 안착하나: cmdb_ci_service_auto ≠ 생성 대상
개요에서 정정한 오해 (a)를 더 구체적으로 분해한다. Application Service 관련 클래스 계층에서 populate 경로에 따라 결과 클래스가 달라진다는 점이 핵심이다 — 클래스 이름 자체보다 ‘어느 경로로 만들어지느냐’에 집중해야 한다.
| 자식 클래스 | 라벨 | populate 방식 | svc_ci_assoc 자동 채움 |
|---|---|---|---|
cmdb_ci_service_auto (부모) | Application Service | 직접 생성 없음 — 자식 레코드 통합 뷰 | — |
cmdb_ci_service_discovered | Mapped Application Service | top-down Service Mapping | 예 (discovery 실행 시 자동) |
cmdb_ci_service_calculated | Calculated Application Service | cmdb_rel_ci traversal (기본 3레벨, Service Mapping 아님) | 예 (traversal 결과) |
cmdb_ci_service_by_tags | Tag Based Application Service | tag-based Service Mapping | 예 (태그 기반) |
cmdb_ci_service_auto 는 부모이므로 이 테이블에 레코드를 “직접 넣는” 경로는 존재하지 않는다. 모든 Application Service 인스턴스는 위 자식 클래스 중 하나의 레코드다.
cmdb_ci_service_calculated 는 cmdb_rel_ci traversal(기본 3레벨)로 계산하는 별개 경로 — Service Mapping 이 아닌 관계 데이터를 소스로 삼는다. 클래스 정의·레이어 배치는 CSDM 입문과 CI Relationship vs Reference Field로 위임하고, 이 글은 ‘top-down 이 discovered 를 만든다’는 경로에 집중한다.
§4 — svc_ci_assoc: Application Service 는 관계가 아니라 CI Association 으로 동작
top-down Service Mapping 의 populate 결과를 이해하려면 cmdb_rel_ci 와 svc_ci_assoc 의 역할 분리를 정확히 알아야 한다.
cmdb_rel_ci — CI↔CI 의존 관계
서버·DB·LB 등 인프라 CI 사이의 양방향 의존관계를 저장. Service Mapping 이 traverse 하는 대상이다. ‘Depends on::Used by’, ‘Runs on::Runs’ 등 관계 타입이 붙는다.
svc_ci_assoc — 서비스↔멤버 CI flatten 인덱스
Application Service 와 그 서비스에 속한 CI 멤버십을 빠르게 조회하기 위한 flatten 테이블. impact 분석 성능을 위한 인덱스 역할이며, ‘cmdb_rel_ci 그래프’와는 별도로 유지된다.
핵심 명제: Application Service 의 서비스↔멤버 CI 바인딩은 cmdb_rel_ci 관계가 아니라 svc_ci_assoc 로 이루어진다. “Application Services 는 relationship 이 아니라 CI Association 으로 동작한다”는 말이 이것이다. CI Relationship vs Reference Field §4 에서 다룬 ‘Mapped Application Service 는 cmdb_rel_ci 자동 채움 안 됨’ 결론이 정확히 여기서 연결된다.
top-down(Mapped) 서비스의 svc_ci_assoc 는 Service Map discovery 실행 시 자동으로 populate 된다 — 탐색 결과를 기반으로 멤버 CI 목록이 채워진다. 수동 입력값은 재계산 시 덮어쓰일 수 있다(인스턴스 확인 권장). 관련 동기화 job 이 svc_ci_assoc 를 갱신하는 것으로 알려져 있으나 job 명은 인스턴스에서 확인하길 권장한다.
Calculated 의 경로도 최종적으로 svc_ci_assoc 로 귀결된다 — 방식에 관계없이 impact 분석·Service Map 뷰어는 svc_ci_assoc 를 읽는다. 레코드 존재 여부와 discovery_source 점검이 populate 검증의 첫 단계이며, CMDB Health 관점 검증은 CMDB Health 점수 · Certification · Remediation와 연결된다.
§5 — populate 된 데이터는 IRE 를 통과한다
Service Mapping 이 만든 CI 와 관계는 모두 IRE(Identification and Reconciliation Engine) 를 통과한다 — CMDB 에 직접 쓰지 않고 IRE 가 식별·중복 제거·조정한다. IRE 상세는 CMDB IRE · Discovery · Reconciliation으로 위임한다.
Service Mapping 특이 사항: discovery_source 가 ‘ServiceWatch’(구 제품명)로 stamp 되는 것으로 알려져 있다. horizontal Discovery 가 먼저 찾은 CI 가 service map 에 포함되면 이 값이 덮일 수 있으며, sys_choice 커스터마이징도 가능하다 — 인스턴스별 확인 권장. 충돌 시 source priority 결정은 IRE 글로 위임한다.
§6 — 자동화의 경계: Business Application 상향 링크는 populate 되지 않는다
Service Mapping 이 cmdb_ci_service_discovered 를 채우고 svc_ci_assoc 를 구성하더라도, Business Application(BA)과 Application Service(AS) 사이의 상향 링크는 Service Mapping 이 만들지 않는다.
BA↔AS 관계는 CI Relationship formatter(BA 폼)나 Application Service 관련 마법사, 또는 cmdb_rel_ci 직접 생성 등 수동 governance 로 구축해야 한다. 따라서 auto-mapping 만으로는 Application Service 가 어떤 Business Application 에도 연결되지 않은 채 남는다. OOTB ‘App Services Missing Business App Relationship’ 리포트가 존재하는 이유가 바로 이것이다.
관계 타입 주의: CSDM 4.x 에서는 Consumes::Consumed by 가 기본이다. CSDM 5.0 White Paper 는 Uses::Used by 로 변경됐다고 기술하나, 문서 내 자기모순 + 플랫폼 자동화는 여전히 Consumes 하드코딩으로 알려져 있다 — 5.0 인스턴스에서도 관계 타입은 직접 확인이 안전하다.
오해 — “auto-map 하면 BA 링크도 생긴다”
Service Mapping 은 AS 레이어까지만 자동으로 채운다. BA↔AS 연결은 자동화 범위 밖이다 — 수동 CI Relationship 또는 거버넌스 프로세스로 별도 구축해야 한다.
오설계 — entry point 를 BA 로 잘못 잡기
Business Application 을 Application Service 로 만들어 Service Mapping 에 직접 물리는 오설계는 BA 레이어를 비우고 비즈니스 관점 보고를 깨뜨린다. 상세는 세 엔터티 구분 글 §4 오설계 (a) 참고.
§7 — populate 실패 트러블슈팅
top-down Service Mapping 이 기대한 결과를 만들지 못하는 경우는 몇 가지 패턴으로 수렴된다.
① entry point 오설정
증상: service map 미생성 또는 불완전
top-down 은 entry point 정확 구성이 선결 조건이다. URL·host·port 가 잘못되거나 누락되면 탐색 자체가 시작되지 않는다. tag-based·ML 방식에는 entry point 가 필요 없다.
② credential / MID Server 누락
증상: credentialless CI, missing relationship
MID Server + host credential + application credential 이 모두 갖춰져야 한다. ‘Verify that Service Mapping is set up properly’ readiness check 가 OOTB 에 존재한다.
③ 중복 endpoint 에러
증상: “Duplicate records found while searching for possible matching endpoints”
기존 endpoint 와 매칭되는 entry point 를 추가하면 endpoint business rule 이 에러를 발생시킨다. 기존 service map 에 중복 entry point 가 있는지 먼저 확인한다.
④ pattern Identification 오설정
증상: CI not identified, 또는 IP·port 는 맞는데 이름이 틀림
pattern 의 Identification section 이 CI 를 정확히 식별하지 못하면 CI 가 잘못된 이름으로 생성되거나 미매핑된다. Debug Mode 로 pattern 실행 결과를 단계별로 추적할 수 있다.
⑤ 공유 CI map override
증상: 한 service map 변경이 다른 map 에 반영됨
두 service map 이 같은 CI(LB 제외)를 재사용하면 한 map 의 변경이 다른 map 에 영향을 준다. 상위는 같고 하위가 다른 구조에서는 나중에 실행된 map 이 이전 map 을 override 하는 것으로 알려져 있다.
⑥ cloud/dynamic 환경의 파편화
증상: 잦은 재배포 후 map 불일치
잦은 재배포·auto-scaling·컨테이너 환경은 top-down 이 따라가기 어렵다. tag-based 를 권장하며, 태그 불일치 시 map 이 파편화된다. top-down 대체가 아니라 hybrid 구성이 권장 방향이다.
최신 릴리스에서는 다중 소스 병합(Multi-Source Service Mapping) 등이 추가됐으며, 이에 대한 상세는 별도 후속 주제로 다룬다.
학습 허브
이 글은 ServiceNow CMDB 완전 정리 학습 허브의 populate 실행편이다. CI Relationship 레이어(CI Relationship vs Reference Field)·식별조정 레이어(CMDB IRE · Discovery · Reconciliation)·비즈니스 서비스 레이어(CSDM)가 교차하는 지점에서 Service Mapping 이 실제로 어떻게 Application Service 를 채우는지를 다룬다 — 허브에서 CMDB 구조부터 CSDM 채택·populate 메커니즘까지 전체 경로를 따라갈 수 있다.
참조
- ServiceNow Docs — Service Mapping get started (Australia)
- ServiceNow Docs — Choose method for discovering and mapping services (Australia)
- ServiceNow Docs — Entry points for Service Mapping (Australia)
- ServiceNow Docs — Service Mapping prerequisites and setup (Australia)
- ServiceNow Docs — CSDM Framework overview (Australia)
- ServiceNow CSDM White Paper (4.x / 5.0) — 관계 타입·클래스 구성의 정확한 정의는 해당 버전 White Paper 및 인스턴스에서 확인 권장
- ServiceNow Community — Application Services 및
svc_ci_assoc동작 관련 커뮤니티 포럼