ServiceNow CMDB Health — 점수 계산 메커니즘, Data Certification, Remediation 루프
CMDB Health 의 Completeness·Correctness·Compliance 가 무엇인지(정의)는 따로 정리했고, 이 글은 그 점수가 실제로 어떻게 계산되는지(Xanadu 이후 failed/total 방식·임계값 제거·metric 당 100K cap·3개 scheduled job), 어느 sub-metric 이 점수를 끌어내리는지 찾아 개선하는 레버, Data Certification 과 Attestation 의 결정적 차이, 그리고 failed CI 를 실제로 교정하는 Remediation 루프까지 운영 관점으로 다룬다.
개요
CMDB Health 의 세 metric — Completeness / Correctness / Compliance — 이 무엇을 의미하는지 는 CMDB 의 의미와 역할 §3 에서 정의 수준으로 정리했다. 이 글은 그 다음 질문을 다룬다: 그 점수는 실제로 어떻게 계산되며, 무엇으로 움직이고, 떨어진 점수를 어떻게 다시 끌어올리는가.
이 구분이 중요한 이유는, Health 대시보드의 숫자를 “낮으니 데이터 정리해야겠다” 수준으로만 읽으면 정작 어느 CI 의 어느 항목 때문에 점수가 떨어졌는지, 그리고 그걸 누가 어떤 권한으로 고쳐야 하는지를 놓치기 때문이다. 점수 계산 메커니즘(§1), 점수를 움직이는 레버(§2), Data Certification 과 Attestation 의 차이(§3), Remediation 루프(§4) 순으로 본다.
OOTB(Out-of-the-Box, 기본 제공) 기준입니다. CMDB Health 의 계산 방식은 Xanadu(2024.2) 전후로 크게 바뀌었고, 인스턴스 버전·정책·custom 설정에 따라 세부 동작이 달라질 수 있습니다. 정확한 최신 수치는 자신의 인스턴스에서 확인하세요.
§1 — 점수가 계산되는 방식 (Xanadu 이후)
가장 먼저 짚어야 할 것은 Xanadu(2024.2) 를 기점으로 Health 점수 계산이 재설계됐다는 점이다. 그 이전의 임계값(threshold) 기반 설정 — “score 가 몇 % 미만이면 빨강” 식의 색상 임계값 — 은 제거됐고, 점수 자체가 단순하고 일관된 비율로 통일됐다.
| 항목 | Xanadu 이후 동작 |
|---|---|
| 기본 공식 | 각 sub-metric 단위로 (1 − failed CIs / total CIs) × 100. 즉 “검사 대상 CI 중 통과하지 못한 비율”을 100 에서 뺀 값 |
| 임계값(threshold) | 제거됨. 점수에 색상 임계값을 별도로 설정하던 구조가 사라지고, 점수는 순수 비율로만 표현 |
| 계산 범위 상한 | 한 metric 의 계산 대상이 과도하게 커지지 않도록 metric 당 약 100,000 CI 상한이 걸린다 (대규모 CMDB 에서 계산 폭주 방지) |
| 계산 주체 | 3개의 scheduled job — Completeness / Correctness / Compliance Score Calculation — 이 주기적으로 돌며 점수를 갱신. 실시간이 아니라 배치다 |
| 표시 위치 | CMDB Workspace 의 Health 대시보드 (Xanadu 이후 Health 운영의 기본 진입점) |
여기서 실무적으로 가장 자주 오해하는 두 가지가 있다.
첫째, 점수는 실시간이 아니다. scheduled job 이 돌기 전에는 방금 고친 CI 가 점수에 반영되지 않는다. “데이터를 고쳤는데 점수가 그대로”라면 대개 job 주기를 기다리거나 수동 실행해야 하는 상황이다.
둘째, failed/total 비율이라 분모(total)가 작은 class 는 CI 한 건이 점수를 크게 흔든다. CI 가 10건뿐인 class 에서 1건이 실패하면 그 sub-metric 은 90점이다. 전체 평균만 보면 묻히지만, class 단위로 내려가면 작은 모집단의 변동성을 반드시 감안해야 한다.
§2 — 점수를 움직이는 레버: 어느 CI 가 점수를 깎는가
짚어둘 점은, Xanadu 이후로는 세 metric 을 하나로 합친 단일 “종합 health score” 자체가 제거됐다는 것이다 — 대신 Completeness / Correctness / Compliance 세 KPI 점수를 각각 본다. 그리고 이 KPI 점수들은 “무엇을 고쳐야 하는가”를 바로 알려주지 않는다. 실제 개선은 KPI 점수 → sub-metric → failed CI 목록 → 개별 교정 으로 내려가는 drill-down 에서 일어난다.
| 단계 | 무엇을 보나 | 행동 |
|---|---|---|
| 1. KPI | Completeness/Correctness/Compliance 세 점수 중 어디가 낮은가 | 가장 낮은 metric 을 먼저 선택 |
| 2. sub-metric | 그 metric 안에서 Required Fields, Staleness, Orphan, Relationships 등 어느 항목이 fail 을 만드는가 | fail 기여가 큰 sub-metric 으로 진입 |
| 3. class 분해 | 어느 CI class 가 fail 을 집중적으로 발생시키는가 | 모집단 큰 class 우선 (분모가 커야 개선 효과 큼) |
| 4. failed CI 목록 | 실제로 어떤 CI 가, 어떤 필드/관계 때문에 fail 했는가 | 교정 대상 리스트 확보 → §4 Remediation 으로 |
개선 우선순위의 핵심 원칙은 “낮은 점수”가 아니라 “고쳤을 때 점수가 가장 많이 오르는 곳”을 먼저 잡는 것이다. §1 의 failed/total 구조 때문에 같은 노력이라도 분모가 큰 class 에서 fail 을 줄일 때 해당 KPI 점수가 더 크게 움직인다. 10건짜리 class 를 100점 만드는 것보다 5,000건짜리 class 의 fail 200건을 줄이는 쪽이 전체 health 에 훨씬 크게 기여한다.
또 하나의 흔한 레버는 Correctness 의 Staleness다. 갱신이 끊긴 CI(연관 글 CMDB 의 의미와 역할 §3 에서 기본 임계값 60일로 정리)는 시간이 지나면 자동으로 fail 로 빠지므로, Discovery 가 닿지 않는 CI 들이 누적되면 손대지 않아도 점수가 서서히 내려간다. 이 경우의 해법은 데이터 수정이 아니라 그 CI 가 여전히 실존하는가 를 확인하는 것 — 여기서 Data Certification 과 Remediation 이 등장한다.
§3 — Data Certification vs Attestation: 헷갈리는 두 검증
CMDB 데이터 품질을 사람이 직접 검증하는 두 메커니즘이 있는데, 이름이 비슷해 자주 혼동된다. 둘은 목적·권한·CMDB 변경 여부가 전부 다르다.
| 구분 | Attestation | Data Certification |
|---|---|---|
| 핵심 질문 | ”이 CI 가 현실에 실제로 존재하는가" | "이 CI 의 데이터가 정확한가” |
| 방식 | Survey(설문) 응답 — 담당자가 존재 여부/기본 사실을 확인 | CMDB 레코드를 직접 검토하고 수정하며 정확성 확인 |
| CMDB 편집 | 하지 않음 (확인만) | 함 (틀린 값을 직접 교정) |
| 필요 권한 | 특정 role 강제 없음 — 비전문 담당자도 응답 가능 | itil role 필요 (CMDB 레코드 편집 권한) |
| 대표 용도 | ”유령 CI” 색출, 자산 실존 주기 점검 | 필드 값·분류·관계의 정확성 보증 |
핵심 차이는 CMDB 를 건드리느냐다. Attestation 은 “있다/없다”를 묻는 가벼운 확인이라 현업 담당자 누구에게나 보낼 수 있고 CMDB 데이터를 바꾸지 않는다. Data Certification 은 데이터를 직접 고치는 작업이라 itil role 이 필요하고, 그래서 아무에게나 위임할 수 없다.
운영에서는 Data Manager 가 이 둘을 묶어 굴린다. Data Manager 가 정의한 정책에 따라 scheduled job 이 검증 task 를 생성하고, 담당자는 그 task 를 CMDB Workspace 의 “My Work” 에서 받아 처리한다. 즉 Health 점수(§1)가 어디가 나쁜지 를 보여주면, Certification/Attestation 은 그것을 사람이 검증·교정하는 작업으로 전환하는 통로다.
§4 — Remediation 루프: failed CI 를 점수에서 교정으로
Health 의 가치는 점수 자체가 아니라 failed CI 가 실제 교정 작업으로 이어지는 닫힌 루프에 있다. 점수만 보고 끝나면 대시보드는 그저 나빠지는 그래프일 뿐이다.
Health Score (§1, batch)
│ 낮은 metric 식별
▼
Drill-down (§2) → failed CI 목록 (class·필드·관계 단위)
│
▼
교정 경로 선택
├─ 데이터가 틀림 → Data Certification (itil, 직접 수정) §3
├─ 실존 여부 불확실 → Attestation (Survey 확인) §3
└─ 더 이상 없는 CI → Retire / Archive (CMDB 에서 제외)
│
▼
scheduled job 재계산 → Score 반영 (실시간 아님)세 갈래의 교정 경로를 구분하는 것이 실무의 핵심이다.
(a) 데이터가 틀린 경우 — 필드 값·분류·관계가 잘못됐다면 Data Certification 으로 직접 교정한다. 관계 누락(Compliance 를 깎는 대표 원인)이라면 CI Relationship vs Reference Field 에서 다룬 cmdb_rel_ci 모델에 맞춰 관계를 보강해야 점수가 회복된다.
(b) 실존 여부가 불확실한 경우 — 특히 Staleness 로 빠진 CI 는 “데이터가 틀린” 게 아니라 “아직 살아 있는지 모르는” 상태다. 먼저 Attestation 으로 실존을 확인한 뒤, 살아 있으면 Discovery 재연결, 없으면 (c)로 보낸다.
(c) 더 이상 존재하지 않는 CI — 폐기된 자산을 억지로 데이터만 채우면 안 된다. Retire / Archive 로 CMDB 운영 대상에서 제외해야 한다. 이렇게 빼는 것 자체가 Health 개선이다 — failed CI 가 total 에서 빠지므로 §1 의 비율이 정직해진다.
마지막으로, 중복 CI 가 fail 의 근원이라면 교정이 아니라 애초에 중복이 생기지 않게 막는 쪽이 근본 해법이다 — 이는 IRE 와 Discovery 조정 에서 다룬 Identification/Reconciliation 의 영역이다. Remediation 은 이미 생긴 문제를 닫는 루프이고, IRE 는 그 문제가 들어오지 못하게 하는 관문이다. 둘이 같이 돌아야 Health 가 일회성 청소가 아니라 유지되는 상태가 된다.
학습 허브
이 글은 ServiceNow CMDB 완전 정리 학습 허브의 데이터 품질 운영 편이다. 클래스 계층·관계·IRE 가 깨끗한 데이터를 만드는 단계였다면, CMDB Health 의 점수·검증·Remediation 은 그 품질을 지속적으로 측정하고 유지하는 단계다 — 허브에서 CMDB 구조 설계부터 품질 운영까지 전체 경로를 따라갈 수 있다.
참조
- CMDB 의 의미와 역할 §3 — Completeness·Correctness·Compliance 세 metric 의 정의 (이 글의 출발점)
- CI Relationship vs Reference Field — Compliance 의 Relationships sub-metric 이 검사하는
cmdb_rel_ci관계 모델 - CMDB IRE 와 Discovery 조정 — 중복 CI 를 애초에 막는 Identification/Reconciliation 관문
- ServiceNow 공식 CMDB Health Dashboard / Data Manager 문서 — 점수 계산·scheduled job·Certification 정책의 정확한 최신 동작은 자신의 인스턴스 버전에서 확인 권장