MDM #5. 지식 그래프 기반 엔티티 해상도: 중복 탐지와 오병합을 함께 줄이는 설계
기업의 마스터 데이터에는 같은 실체가 서로 다른 이름과 코드로 존재하는 경우가 많습니다.
예를 들어 한 공급업체가 여러 ERP와 구매시스템에서 다음처럼 표현될 수 있습니다.
Supplier B — 한울테크(주)
Supplier C — HANUL TECH
Supplier D — Hanul Technology Vietnam Co., Ltd.
앞의 세 레코드는 같은 법인을 가리킬 수도 있습니다.
하지만 네 번째 회사는 같은 기업집단에 속하면서도 별도 법인일 수 있습니다.
이 차이를 잘못 판단하면 두 종류의 오류가 발생합니다.
| 오류 | 의미 | 결과 |
|---|---|---|
| False Non-Match | 같은 Entity를 서로 다른 Entity로 판단 | 중복 Customer·Supplier·Product가 계속 존재 |
| False Merge | 서로 다른 Entity를 하나로 통합 | 계약·지급·리스크·분석 Context가 잘못 결합될 수 있음 |
전통적인 중복 제거 논의에서는 첫 번째 문제에 집중하기 쉽습니다.
그러나 Enterprise MDM에서는 두 번째 문제가 더 위험할 수도 있습니다.
Entity Resolution의 목표는 중복을 0으로 만드는 것이 아닙니다. 동일 Entity를 최대한 찾아내면서도 서로 다른 Entity를 잘못 합치는 위험을 Business가 허용할 수준으로 통제하는 것입니다.
Knowledge Graph는 이 문제를 해결하는 중요한 도구가 될 수 있습니다.
하지만 그래프를 사용한다고 자동으로 정확도가 높아지는 것은 아닙니다.
그래프가 제공하는 핵심 가치는 문자열뿐 아니라 Entity가 누구와 어떤 관계를 맺고 있는가를 추가 evidence로 사용할 수 있다는 점입니다.
1. Entity Resolution은 Duplicate Detection보다 넓은 개념이다
Entity Resolution은 여러 레코드가 실제 세계의 동일 Entity를 나타내는지를 판단하는 과정입니다.
실제 MDM에서는 다음 과정이 서로 구분되어야 합니다.
비교할 가능성이 있는 레코드 찾기
↓
MATCHING
동일 Entity일 가능성 평가
↓
DECISION
Match · Potential Match · Not a Match
↓
MERGE / LINK
실제 통합 또는 관계 연결
↓
SURVIVORSHIP
어떤 Attribute를 Operational Value로 사용할지 결정
따라서 다음 용어를 같은 의미로 사용해서는 안 됩니다.
| 개념 | 역할 |
|---|---|
| Deduplication | 중복으로 판단된 레코드를 정리하는 과정 |
| Record Linkage | 서로 다른 Source의 레코드를 동일 Entity와 연결 |
| Entity Resolution | 동일한 실제 Entity인지 판단하는 전체 과정 |
| Merge | 동일하다고 판단한 Entity를 논리적 또는 물리적으로 통합 |
| Survivorship | 여러 Source Value 중 어떤 값을 사용할지 결정 |
Reltio 역시 matching과 merging을 구분하고 있으며, 완전히 확신할 수 없는 레코드는 Potential Match로 분류해 Data Steward가 검토할 수 있도록 합니다.
Reltio — Review Potential Matches
2. Exact Matching은 낡은 기술이라서가 아니라 적용범위가 다르다
Entity Resolution을 설명할 때 Exact Matching을 구식 방식으로, AI나 Knowledge Graph를 항상 더 발전된 방식으로 표현하기 쉽습니다.
하지만 실제 운영에서는 그렇지 않습니다.
신뢰할 수 있는 Legal Identifier가 있다면 Exact Match가 가장 강력한 evidence가 될 수 있습니다.
예를 들어 검증된 사업자 식별번호가 동일하고 해당 번호가 Entity별로 unique하다는 Business Rule이 확립되어 있다면 복잡한 AI 모델이 필요하지 않을 수 있습니다.
→ Use Deterministic Evidence First
Weak / Missing Identifier
→ Add Fuzzy, ML and Relationship Evidence
AWS Entity Resolution도 현재 Rule-Based Matching과 Machine Learning-Based Matching을 별도 방식으로 지원합니다.
Rule-Based Matching은 설정 가능한 기준으로 exact 또는 fuzzy condition을 사용할 수 있고, ML-Based Matching은 불완전하거나 형태가 다른 데이터에서 더 넓은 Match를 찾기 위해 사용할 수 있습니다.
AWS — Entity Resolution Matching Workflows
3. Fuzzy Matching이 틀린 것이 아니라 Evidence가 부족할 수 있다
Fuzzy Matching은 이름·주소·전화번호처럼 표기가 달라질 수 있는 Attribute를 비교할 때 유용합니다.
하지만 문자열이 비슷하다고 반드시 같은 Entity인 것은 아닙니다.
예를 들어:
Hanul Tech Vietnam Co., Ltd.
는 이름이 매우 비슷하지만 서로 다른 Legal Entity일 수 있습니다.
반대로:
HNL TECH
처럼 문자열 유사도는 낮지만 동일 회사일 수도 있습니다.
즉 Entity Resolution은 하나의 Similarity Score보다 여러 Evidence를 결합하는 문제에 가깝습니다.
4. Knowledge Graph가 추가하는 것은 Relationship Evidence다
Knowledge Graph의 핵심가치는 모든 Master Data를 Graph Database로 바꾸는 데 있지 않습니다.
Entity와 Entity 사이의 관계를 명시적으로 표현하고 탐색하기 쉬워진다는 데 있습니다.
예를 들어 Supplier Entity를 다음처럼 표현할 수 있습니다.
├─ HAS_LEGAL_ID → Legal Identifier
├─ LOCATED_AT → Address
├─ USES_DOMAIN → Website Domain
├─ HAS_PHONE → Phone
├─ SUBSIDIARY_OF → Parent Company
├─ SUPPLIES → Material
└─ REGISTERED_IN → Country
두 Supplier Record의 이름이 다르더라도 동일한 validated legal identifier, address, domain 또는 다른 Entity와의 관계를 공유한다면 추가 Match Evidence를 얻을 수 있습니다.
Neo4j의 Graph Data Science Node Similarity는 두 Node가 공유하는 Neighbor를 기반으로 Jaccard, Overlap 또는 Cosine similarity를 계산할 수 있습니다.
Neo4j Graph Data Science — Node Similarity
5. 그러나 관계가 많다고 같은 Entity는 아니다
Graph Matching에서 가장 위험한 오해 중 하나가 “관계가 유사하면 동일 Entity”라는 생각입니다.
예를 들어 두 회사가:
같은 Address
같은 Website Domain
같은 Procurement Category
를 공유할 수 있습니다.
하지만 서로 다른 자회사일 수 있습니다.
따라서 Graph Relationship은 Identity를 결정하는 추가 Evidence이지, 자동적인 `sameAs` 선언이 아닙니다.
sameAs와 relatedTo를 구분해야 한다
| Relationship | 의미 |
|---|---|
| SAME_ENTITY_AS | 두 레코드가 동일한 실제 Business Entity를 표현 |
| SUBSIDIARY_OF | 별도 Entity이지만 기업집단 관계 |
| LOCATED_AT | 같은 주소를 공유할 수 있으나 동일 Entity라는 뜻은 아님 |
| SHARES_CONTACT | 전화·이메일 등을 공유하지만 동일 Entity 여부는 추가검증 필요 |
| SUPPLIES_SAME_MATERIAL | Business Pattern이 비슷하다는 의미일 뿐 Identity Evidence는 약할 수 있음 |
Graph Model의 품질이 Entity Resolution 성능만큼 중요한 이유입니다.
6. Rule, Fuzzy, ML, Graph는 대체관계가 아니라 Evidence Layer다
실제 Enterprise Entity Resolution은 여러 접근을 조합하는 편이 현실적입니다.
Validated Legal ID · Internal Master ID
↓
LEVEL 2 — ATTRIBUTE SIMILARITY
Name · Address · Phone · Email
↓
LEVEL 3 — ML / EMBEDDING
Multilingual Name · Unstructured Description · Semantic Similarity
↓
LEVEL 4 — GRAPH CONTEXT
Shared Identifiers · Relationships · Neighbors · Corporate Structure
↓
DECISION POLICY
Auto Match · Steward Review · Not a Match
이 구조에서 Knowledge Graph는 기존 Rule과 Fuzzy Matching을 제거하는 기술이 아닙니다.
기존 Evidence로 결정하기 어려운 Entity에 Relationship Context를 추가하는 기술로 보는 편이 적절합니다.
7. 가장 중요한 설계는 Candidate Generation이다
수백만 건의 Master Record에서 모든 레코드 조합을 서로 비교하는 것은 비효율적일 수 있습니다.
따라서 먼저 Match 가능성이 있는 Pair를 줄여야 합니다.
이를 Blocking 또는 Candidate Generation이라고 합니다.
↓
Candidate Blocking
Country · Domain · Postal Area · Identifier Prefix · Name Token
↓
POTENTIAL PAIRS
↓
Detailed Matching
Blocking을 너무 엄격하게 하면 실제 Duplicate가 Candidate에 들어오지 못해 Recall이 낮아집니다.
반대로 너무 넓게 잡으면 Pair 수와 처리비용이 크게 증가합니다.
따라서 Entity Resolution의 정확도는 최종 Matching Model뿐 아니라 Candidate Generation 단계에서도 결정됩니다.
8. Knowledge Graph를 도입하기 전에 Gold Set을 만들어야 한다
새로운 Matching 방식의 성능을 검증하려면 정답 데이터가 필요합니다.
이를 Labelled Gold Set 또는 Evaluation Set으로 구성할 수 있습니다.
예를 들어 Data Steward와 Business SME가 실제 데이터의 Candidate Pair를 검토해 다음과 같이 Label합니다.
| Pair | Gold Label | 근거 |
|---|---|---|
| A ↔ B | Same Entity | 동일한 검증된 법인 식별값 |
| A ↔ C | Same Entity | 다국어 명칭·주소·Domain 및 Source Evidence 확인 |
| A ↔ D | Different Entity | 동일 Group이지만 별도 Legal Entity |
이 Gold Set에 동일한 Candidate Pair를 넣고 Rule, Fuzzy/ML, Graph-Assisted Model을 비교해야 합니다.
9. 동일 데이터셋에서 세 가지 방식을 비교해야 한다
“Knowledge Graph가 더 정확하다”는 주장은 실제 Validation Dataset에서 검증되어야 합니다.
| Metric | Rule | Fuzzy / ML | Graph-Assisted |
|---|---|---|---|
| Precision | Match라고 판단한 Pair 중 실제 Same Entity 비율 | ||
| Recall | 실제 Same Entity 중 시스템이 찾아낸 비율 | ||
| False Merge | Different Entity를 Same Entity로 잘못 판단한 건수 | ||
| False Non-Match | 실제 Same Entity를 놓친 건수 | ||
| Review Rate | Data Steward에게 보내야 하는 Candidate 비율 | ||
| Processing Cost | Batch 또는 Incremental Matching을 운영하는 비용·시간 | ||
표에 임의의 숫자를 넣지 않은 이유는 중요합니다.
Rule, ML, Graph의 성능은 Entity Type, 데이터 품질, Label 품질, 언어, Candidate Generation, Feature와 Threshold에 따라 달라지기 때문입니다.
따라서 각 기업이 동일한 Gold Set에서 직접 측정해야 합니다.
10. Precision과 Recall을 동시에 봐야 한다
Entity Resolution에서는 “정확도 95%” 같은 하나의 숫자보다 Precision과 Recall의 Trade-off가 중요합니다.
Recall = True Match / All Actual Matches
Threshold를 높이면 일반적으로 Auto-Merge 대상으로 들어오는 Candidate가 줄면서 False Merge 위험을 낮출 수 있지만, 실제 Duplicate 일부를 놓칠 수 있습니다.
Threshold를 낮추면 더 많은 Duplicate 후보를 찾을 수 있지만 잘못된 Match와 Review 부담이 증가할 수 있습니다.
따라서 최적 Threshold는 수학적으로 하나가 정해지는 것이 아니라 Business Risk에 따라 달라집니다.
11. Customer와 Supplier는 같은 Threshold를 사용할 필요가 없다
예를 들어 Consumer Marketing Customer의 중복을 놓쳤을 때와 Supplier Legal Entity를 잘못 Merge했을 때의 Business Impact는 다를 수 있습니다.
| Domain | 주요 Risk | Matching Policy Implication |
|---|---|---|
| B2C Customer | 고객 Profile이 분산되거나 서로 다른 사람을 잘못 통합 | Privacy·Identity 특성을 고려한 Domain별 검증 필요 |
| Supplier | 서로 다른 Legal Entity의 계약·지급·Risk Context가 통합 | High-impact merge는 더 강한 Evidence 또는 승인 요구 가능 |
| Material | 서로 다른 Specification의 부품을 같은 자재로 판단 | Technical Specification과 Manufacturer Context가 중요 |
12. Confidence Score는 확률처럼 보이지만 항상 실제 확률은 아니다
Matching Engine이 0.97이나 97이라는 Score를 반환한다고 해서 반드시 “동일 Entity일 확률이 97%”라는 의미는 아닙니다.
Score가 실제 probability로 해석될 수 있는지는 모델과 calibration 방법에 따라 다릅니다.
따라서 운영정책을 다음처럼 단순 고정하면 위험할 수 있습니다.
80~95% → Human Review
< 80% → New Entity
이 숫자들은 보편적인 기준이 아닙니다.
보다 나은 접근은 실제 Labelled Validation Set을 이용해 Threshold별 False Merge, Recall과 Steward Review Volume을 측정하는 것입니다.
13. Decision Band는 Business Risk로 설계한다
→ Eligible for Automated Resolution
UNCERTAIN
→ Potential Match / Steward Review
HIGH IMPACT OR CONFLICTING EVIDENCE
→ Mandatory Human Decision
CLEAR NON-MATCH
→ Keep Separate
이 Decision Band 구조는 Digital Future & Strategy practitioner framework입니다. 실제 Threshold는 Validation Data와 Business Risk를 사용해 설정해야 합니다.
14. Human Review는 AI가 실패했다는 뜻이 아니다
Entity Resolution의 목표를 “100% 자동화”로 설정하면 애매한 Case를 억지로 자동결정하게 될 수 있습니다.
실제 MDM 제품에서도 중간 영역을 별도로 운영합니다.
Reltio는 Match Rule에 의해 완전한 Match로 판단되지 않는 후보를 Potential Match로 분류하고 Data Steward가 Match / Not a Match를 결정할 수 있도록 합니다.
Reltio — Potential Match Review
Informatica 역시 Match Rule이 Similar Record를 찾을 수 있지만 similar하다는 것만으로 duplicate임을 의미하지 않으며, 필요한 경우 Data Steward가 검토하도록 설명합니다.
Informatica — Multidomain MDM Documentation
15. Steward Review를 줄이는 것이 아니라 가치 높은 Review만 남겨야 한다
Steward Queue가 수십만 건이면 운영이 어려워집니다.
그렇다고 모든 Candidate를 자동 Merge하는 것도 해결책이 아닙니다.
보다 성숙한 운영방식은 Low-Value Review를 줄이는 것입니다.
→ Automated if Policy Allows
Clear Non-Match
→ Automatically Separate
Ambiguous + Low Impact
→ Prioritized Queue
Ambiguous + High Impact
→ Expert Steward / Owner Review
즉 자동화의 KPI는 단순 Auto-Merge 비율이 아니라:
False Non-Match
Review Volume
Review Aging
Unmerge Rate
Repeated Match Dispute
를 함께 보는 것이 더 유용합니다.
16. Merge는 반드시 되돌릴 수 있어야 한다
Matching Rule이나 Source Data는 시간이 지나면서 변할 수 있습니다.
과거에는 같은 Entity로 보였던 두 레코드가 새로운 Evidence에 의해 별도 Entity임이 확인될 수 있습니다.
따라서 Enterprise MDM에서 중요한 것은 Merge뿐 아니라 Unmerge와 Provenance입니다.
Reltio는 변경된 Source Attribute나 Match Rule에 따라 Entity가 더 이상 Match 조건을 충족하지 않을 경우 자동 또는 수동 Unmerge를 지원합니다.
Reltio — Automatically Unmerge Entity Records
Merge Audit에 남겨야 할 Evidence
| Entity IDs | 어떤 Source Entity들이 통합되었는가 |
| Decision Evidence | 어떤 Identifier·Attribute·Relationship이 Match에 기여했는가 |
| Rule / Model Version | 어떤 Matching Logic으로 판단했는가 |
| Decision Type | 자동결정인지 Human Approval인지 |
| Timestamp | 언제 통합되었는가 |
| Reversibility | 원래 Source Entity와 Attribute Provenance를 복구할 수 있는가 |
17. Knowledge Graph 기반 Entity Resolution의 권장 아키텍처
ERP · CRM · SCM · SaaS · External Data
↓
STANDARDIZATION
Name · Address · Identifier · Language
↓
CANDIDATE GENERATION
Blocking · Search · Existing Crosswalk
↓
EVIDENCE LAYER
Deterministic · Fuzzy · ML · Embedding · Graph Relationship
↓
MATCH DECISION
Match · Review · Non-Match
↓
MDM CONTROL
Merge · Link · Survivorship · Stewardship
↓
AUDIT & REVERSIBILITY
Provenance · Rule Version · Unmerge
↓
GOVERNED MASTER ENTITY
중요한 점은 Knowledge Graph가 MDM 전체를 대체하지 않는다는 것입니다.
Graph는 Relationship Context를 표현하고 Matching Evidence를 강화할 수 있지만, 다음은 여전히 MDM Governance가 필요합니다.
Authoritative Source
Merge Authority
Survivorship
Business Hierarchy
Stewardship
Audit
Distribution
18. 전체 AI/Graph Stack을 처음부터 구축할 필요는 없다
현재 공개본처럼 Graph Database, Vector Database, Embedding, GNN, LLM을 모두 Entity Resolution의 필수 구성요소로 보면 과도한 Architecture가 될 수 있습니다.
문제의 난이도에 따라 필요한 기술을 단계적으로 추가하는 편이 좋습니다.
| Problem | 가능한 접근 | Graph 필요성 |
|---|---|---|
| Reliable Legal ID 존재 | Deterministic Rule | 낮을 수 있음 |
| Name·Address Variation | Normalization + Fuzzy / ML | 상황에 따라 선택 |
| 다국어·비정형 Description | Embedding / ML Evidence | Relationship이 중요하면 추가 |
| 복잡한 Corporate Relationship | Attribute + Relationship Graph | 높은 가치가 있을 수 있음 |
| Fraud / Network Identity | Graph Analytics + Other Evidence | 관계구조가 핵심일 수 있음 |
19. Graph Database와 Knowledge Graph도 같은 말은 아니다
Graph Database는 Node와 Relationship을 효율적으로 저장·탐색하기 위한 기술입니다.
Knowledge Graph는 일반적으로 Entity, Relationship, 의미와 Context를 구조적으로 표현하는 더 넓은 개념입니다.
Knowledge Graph 구현에 Graph Database를 사용할 수 있지만, 두 용어를 동일하게 취급할 필요는 없습니다.
Neo4j 역시 Knowledge Graph를 connected data를 구조적으로 표현하는 방식으로 설명하며, Entity-Resolved Knowledge Graph를 구축할 때 중복 Node를 해결하는 과정의 중요성을 별도로 다룹니다.
Neo4j — Entity-Resolved Knowledge Graphs
20. Implementation Roadmap은 기간이 아니라 Evidence Gate로 설계한다
“1~2개월 분석, 2~4개월 Pilot, 4~8개월 자동화”와 같은 고정 일정은 모든 기업에 적용할 수 없습니다.
데이터량, Entity Type, Label Availability와 System Complexity가 다르기 때문입니다.
대신 다음 단계가 더 유용합니다.
| Stage | 핵심작업 | Exit Evidence |
|---|---|---|
| Define | Entity Definition과 False Merge Risk 정의 | Same / Different 기준을 Business가 합의 |
| Label | 대표 Candidate를 전문가가 검토 | 신뢰 가능한 Gold Set 확보 |
| Benchmark | Rule / Fuzzy / ML / Graph 비교 | Precision·Recall·False Merge·Review Volume 측정 |
| Pilot | 실제 Domain에서 Steward Workflow 적용 | 운영 가능한 Review Volume과 Quality 확인 |
| Automate | Low-Risk Decision부터 자동화 | False Merge와 Unmerge가 허용범위에서 안정 |
| Scale | 다른 Source와 Domain 확대 | Domain별 별도 Validation과 Governance 준비 |
21. 운영환경에서는 Drift도 관리해야 한다
좋은 Matching Model도 영원히 같은 성능을 유지한다고 가정해서는 안 됩니다.
다음 변화가 발생할 수 있습니다.
새 국가·언어 추가
Address 품질 변화
기업 인수·분할
Identifier Policy 변경
새로운 Product Naming Convention
Match Rule 변경
따라서 Entity Resolution도 지속적으로 재검증해야 합니다.
특히 새로운 Source System이 추가될 때 기존 Threshold를 그대로 사용할 수 있는지 확인해야 합니다.
22. 운영 KPI는 중복률 하나로 끝내지 않는다
| Metric | 질문 |
|---|---|
| Duplicate Creation Rate | 새 중복이 계속 유입되는가? |
| Precision / Recall | Labelled Validation Set에서 성능이 유지되는가? |
| Potential Match Backlog | Steward가 처리할 수 있는 수준인가? |
| Review Aging | 중요 Candidate가 장기간 미결 상태인가? |
| Unmerge Rate | 과거 Merge가 얼마나 자주 잘못된 것으로 판정되는가? |
| False Merge Incident | 잘못된 Merge가 Business Process에 영향을 주었는가? |
23. AI와 LLM은 Entity Resolution을 보조할 수 있지만 최종 Authority는 아니다
LLM과 Embedding은 다음 영역에서 유용할 수 있습니다.
Abbreviation 해석
비정형 Description 정규화
문서에서 Identifier 추출
Candidate 설명 생성
Steward Review 지원
Neo4j도 LLM을 사용해 비정형 데이터에서 Entity와 Relationship을 추출하고 Knowledge Graph를 만드는 방법을 제공하고 있습니다.
Neo4j — Creating Knowledge Graphs from Unstructured Data
하지만 LLM이 두 Entity가 법적으로 동일한 회사인지 추론했다고 해서 그것만으로 High-Impact Merge를 실행하는 것은 별개 문제입니다.
Legal Identifier, Source Evidence, Business Rule과 승인정책이 함께 필요합니다.
24. Entity Resolution 설계 시 확인할 12가지 질문
1. 이 Domain에서 “같은 Entity”의 정확한 Business Definition은 무엇인가?
2. False Merge와 False Non-Match 중 어느 오류의 Business Impact가 더 큰가?
3. 신뢰할 수 있는 Deterministic Identifier가 있는가?
4. Candidate Generation 단계에서 실제 Match를 놓치고 있지는 않은가?
5. Fuzzy 또는 ML만으로 해결되지 않는 Relationship Context가 실제로 존재하는가?
6. Graph Relationship 자체의 품질과 Source는 신뢰할 수 있는가?
7. Rule·ML·Graph를 동일한 Gold Set에서 비교했는가?
8. Precision·Recall·False Merge를 각각 측정하는가?
9. Confidence Threshold가 외부 사례가 아니라 자사 Validation Data에서 결정되었는가?
10. Ambiguous Match를 검토할 Steward Workflow가 있는가?
11. Merge Decision의 Evidence와 Model Version이 Audit 가능한가?
12. 잘못된 Merge를 안전하게 Unmerge할 수 있는가?
중복 제로보다 중요한 것
“Zero Duplicate Data”는 매력적인 목표입니다.
하지만 현실의 Enterprise Master Data에서 모든 중복을 제거하겠다는 목표는 자칫 더 위험한 결과를 만들 수 있습니다.
Duplicate를 하나 더 찾아내기 위해 Threshold를 계속 낮추면 서로 다른 Entity를 잘못 Merge할 가능성도 증가할 수 있기 때문입니다.
따라서 성숙한 Entity Resolution은 다음 균형을 설계합니다.
+
ATTRIBUTE SIMILARITY
+
ML / SEMANTIC EVIDENCE
+
GRAPH RELATIONSHIP CONTEXT
+
BUSINESS RISK POLICY
+
HUMAN REVIEW
+
REVERSIBLE MERGE
=
TRUSTED ENTITY RESOLUTION
Knowledge Graph의 역할은 문자열 비교를 완전히 대체하는 것이 아닙니다.
이름과 주소만으로는 판단하기 어려운 Entity에 대해 관계와 Context라는 새로운 Evidence를 추가하는 것입니다.
그리고 최종 성공은 Graph Database를 도입했는지가 아니라 다음으로 판단해야 합니다.
잘못된 Merge는 줄었는가?
Steward Review 부담은 관리 가능한가?
결정을 설명하고 되돌릴 수 있는가?
Business Process가 더 신뢰할 수 있는 Entity를 사용하게 되었는가?
좋은 Entity Resolution은 가장 많은 레코드를 Merge하는 시스템이 아닙니다. 같은 Entity와 다른 Entity를 Business가 감당할 수 있는 오류수준 안에서 구분하고, 애매한 판단은 검토하며, 잘못된 판단은 되돌릴 수 있는 시스템입니다.
Sources & Further Reading
- AWS — Entity Resolution Matching Workflows
- AWS — Machine Learning-Based Matching
- Neo4j — Entity-Resolved Knowledge Graphs
- Neo4j Graph Data Science — Node Similarity
- Neo4j — Graph Data Science for Entity Resolution
- Reltio — Review Potential Matches
- Reltio — Automatic Unmerge
이 글은 Knowledge Graph 기반 Entity Resolution을 일반적인 MDM Matching 전략의 한 구성요소로 분석합니다. Rule-Based, Fuzzy, ML 및 Graph 접근의 성능 우위를 보편적으로 가정하지 않으며, 실제 성능은 Entity Type, Source Data, Candidate Generation, Label Quality, Feature, Matching Rule 및 Threshold에 따라 달라집니다. 기존 글에 포함되어 있던 일반적인 5~30% 중복률, 특정 산업의 95% 자동통합, 15%→2% 중복감소, 62% Supplier 통합, 10~15% 비용절감 등의 미검증 수치는 제거했습니다. Gold Set Benchmark, Decision Band, Entity Resolution Evidence Layer, Merge Audit Evidence 및 Evidence-Gated Roadmap은 Digital Future & Strategy practitioner frameworks입니다. 실제 Auto-Merge Threshold는 Domain별 False Merge Impact와 검증 데이터에 근거해 설정해야 합니다.
Reviewed: September 2026
MDM Strategy Series
Part 1 — AI & Agentic MDM
MDM #4. Self-Healing Master Data
MDM #5. 지식 그래프 기반 엔티티 해상도: 중복 탐지와 오병합을 함께 줄이는 설계
MDM #6. DX는 왜 데이터 단계에서 막히는가
Global English Companion
글로벌 독자를 위한 영문판에서는 Knowledge Graph 기반 Entity Resolution의 기본 구조와 기술적 적용을 별도로 다룹니다.
MDM #5. Knowledge Graph-Based Entity Resolution: The Pursuit of Zero Duplicate Data
본 한국어판은 영문판의 단순 번역이 아니라 Precision·Recall, False Merge, Gold Set Benchmark, Steward Review, Unmerge와 운영 통제에 더 초점을 둡니다.
이전 글: Self-Healing Master Data
다음 글: DX는 왜 데이터 단계에서 막히는가
Comments
Post a Comment