Cross-Source Person Entity Deduplication Contracts: Canonical IDs, Alias Merges, Tombstones, and Ghost-Node Prevention

Summary#

Cross-source person entity deduplication의 핵심 계약은 “한 사람을 대표하는 canonical person ID는 안정적으로 유지하고, 각 소스의 레코드 ID는 alias/link로 보존하며, merge·delete·unmerge 이벤트를 소비자가 재현 가능하게 전달한다”는 것이다.
MDM, entity-resolution, knowledge-graph, sync 시스템의 공통 실패 모드는 중복 인물 노드가 병합된 뒤에도 일부 소스·캐시·인덱스·동기화 대상에 과거 ID가 살아남아 ghost node가 재생성되는 것이다. 이를 막으려면 병합 결과만 저장하는 것이 아니라 alias map, tombstone, redirect, survivorship rule, merge audit log, idempotent sync contract를 함께 정의해야 한다.

Key Points#

Canonical ID는 “현재 우승자 ID”가 아니라 장기 식별자여야 한다.
person entity에는 내부 person_canonical_id를 부여한다.
Google Drive, Notion, CRM, 연락처, 지식그래프 노드 등 외부 시스템의 ID는 canonical ID가 아니라 source_record_id로 취급한다.
canonical ID를 바꾸는 merge는 downstream을 깨뜨리므로, 가능하면 canonical ID는 유지하고 alias table만 확장한다.
Alias map은 단순 별칭 목록이 아니라 cross-source identity contract다.
최소 필드:
- canonical_person_id
- source_system
- source_record_id
- source_person_key 또는 normalized key
- confidence
- match_rule_id
- status: active / merged / tombstoned / disputed
- valid_from, valid_to
동일한 이메일, 전화번호, 이름, 조직, URL, 문서 작성자 ID 등은 evidence로 저장하되, 하나의 증거만으로 영구 병합하지 않는 것이 안전하다.
Merge는 “B를 A로 덮어쓰기”가 아니라 이벤트여야 한다.
권장 이벤트:
- PersonCreated
- PersonAliasLinked
- PersonMerged
- PersonMergeReversed
- PersonTombstoned
- SourceRecordDetached
PersonMerged에는 다음을 포함한다:
- losing canonical ID 또는 duplicate node ID
- surviving canonical ID
- merge reason
- confidence
- operator / process
- timestamp
- affected source records
이렇게 해야 search index, graph projection, cache, vector store, downstream app이 동일한 merge를 재처리할 수 있다.
Survivorship rule을 명시해야 한다.
MDM에서 survivorship은 여러 중복 레코드 중 어떤 속성 값을 “golden record”에 남길지 정하는 규칙이다.
예:
- 이름: 가장 최근에 사용자가 직접 확인한 값 우선
- 이메일: verified source 우선
- 직함: 출처별 freshness와 신뢰도 기반
- 프로필 사진: 수동 승인된 값 우선
- 메모/관계/문서 링크: 합집합 보존
dedup 계약은 “어떤 ID가 이겼는가”뿐 아니라 “속성별로 어떤 값이 이겼는가”를 기록해야 한다.
Tombstone은 ghost-node prevention의 핵심이다.
병합으로 사라진 duplicate person ID를 즉시 물리 삭제하면, 오래된 소스가 다시 sync될 때 같은 노드가 재생성될 수 있다.
따라서 losing ID에는 tombstone을 남긴다:
- tombstoned_person_id
- redirect_to_person_id
- reason: merged / deleted / invalid / privacy_erasure
- created_at
- expires_at 또는 retention policy
sync consumer는 tombstone을 보면 새 노드를 만들지 말고 surviving canonical ID로 redirect해야 한다.
Ghost node는 주로 네 가지 경로로 발생한다. 1. 과거 source record가 재수집되었지만 alias map을 조회하지 않음. 2. merge 후 search index나 graph projection이 partial update되어 losing node가 남음. 3. 삭제 이벤트가 downstream에 전달되지 않음. 4. canonical ID가 바뀌었는데 consumer가 redirect/tombstone을 모름.
동기화 계약은 idempotent해야 한다.
동일한 merge event가 여러 번 전달되어도 결과가 같아야 한다.
merge_event_id 또는 deterministic event key를 둔다.
consumer는 “이미 처리한 merge인지”를 확인해야 한다.
out-of-order event를 대비해 event timestamp만이 아니라 monotonically increasing version 또는 sequence를 두는 것이 좋다.
Unmerge/reversal을 설계하지 않으면 운영 리스크가 커진다.
person entity resolution은 오탐이 가능하다.
병합 취소를 위해서는 merge 전 source-record membership과 속성 survivorship snapshot을 보존해야 한다.
manual review state를 둘 수 있다:
- candidate
- auto_merged
- human_confirmed
- disputed
- reversed
Knowledge graph에서는 edge migration도 계약에 포함해야 한다.
person node가 병합되면 다음이 필요하다:
- losing node의 outgoing/incoming edge를 surviving node로 이전
- 중복 edge collapse
- provenance 보존
- losing node를 redirect/tombstone node로 유지하거나, 완전히 삭제하더라도 redirect index 유지
단순히 노드 속성만 합치면 관계 그래프에 ghost relationship이 남을 수 있다.
권장 최소 스키마 ```text PersonCanonical
person_id
status: active | tombstoned | disputed
created_at
updated_at
version

PersonAlias - alias_id - person_id - source_system - source_record_id - normalized_identifier - confidence - status: active | merged | detached | tombstoned - valid_from - valid_to

PersonMerge - merge_id - winner_person_id - loser_person_id - reason - confidence - rule_id - actor - created_at - reversible: true | false

PersonTombstone - tombstoned_person_id - redirect_to_person_id - reason - created_at - retention_until ```

Cautions#

공개 문서들은 MDM, entity resolution, delta sync, 삭제 tombstone, knowledge graph merge를 각각 설명하지만, “Notion/Google Drive/개인 지식관리 시스템의 person entity dedup contract”를 하나로 표준화한 단일 공개 규격은 확인되지 않는다. 따라서 본 초안은 여러 공개 패턴을 조합한 아키텍처 계약안이다.
canonical ID를 외부 소스 ID로 삼으면 소스 이전, 계정 병합, 앱 재연동 시 ID 안정성이 깨질 수 있다. 내부 canonical ID와 외부 source ID를 분리해야 한다.
tombstone 보존 기간은 개인정보 삭제 요구와 충돌할 수 있다. privacy erasure와 dedup redirect tombstone은 다른 정책으로 다뤄야 한다. 개인정보를 지운 tombstone은 최소한의 redirect hash 또는 non-PII merge marker만 남기는 설계가 필요할 수 있다.
자동 병합은 false positive가 더 위험한 경우가 많다. 특히 동명이인, 공유 이메일, 조직 대표 계정, 가족 연락처, 이전 직장 이메일은 사람 식별 증거로 신중히 사용해야 한다.
vector search나 LLM 기반 entity matching은 보조 신호로는 유용하지만, canonical merge의 단독 근거로 쓰면 재현성과 감사 가능성이 낮다. merge rule, evidence, confidence, reviewer를 남겨야 한다.

Sources#

https://learn.microsoft.com/en-us/graph/delta-query-overview
https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_getdeleted.htm
https://www.ibm.com/docs/en/imdm
https://moj-analytical-services.github.io/splink/
https://www.wikidata.org/wiki/Help:Merge
https://www.w3.org/TR/prov-o/

Sagwan Revalidation 2026-07-16T16:29:03Z#

verdict: ok
note: 개념·계약·이벤트 권장안 모두 현재 practice와 부합한다.

Sagwan Revalidation 2026-07-18T17:26:19Z#

verdict: ok
note: 최신 MDM/ER 관행과 부합하며 수치·링크 의존도 없어 재사용 가능

Sagwan Revalidation 2026-07-20T18:38:29Z#

verdict: ok
note: ID 안정성·alias·tombstone·이벤트 계약 권장은 여전히 최신 practice와 부합.