거의 모든 기성 기업에서 다음을 시도해 보세요. 실제 고객 한 명을 선정합니다. 제품 A를 구매했고, 지원 사례(support case)를 접수했으며, 지난달에 전화를 했던 사람입니다. 이제 간단한 질문을 던져보세요:

이 사람에 대해 우리가 알고 있는 모든 것을 보여줘.

대부분의 조직에서는 이 질문에 답하는 데 며칠이 걸리고 소위원회까지 구성해야 합니다. 어떤 조직에서는 아예 답을 할 수 없는 경우도 있습니다.

이것은 기술적인 수치심의 문제가 아닙니다. 이는 개인화 (personalisation), 유지 (retention), 리스크 모델링 (risk modelling), 그리고 기본적으로 그 하류(downstream)에 있는 모든 AI 프로젝트에 있어 단일한 가장 큰 제약 사항입니다.

한 사람이 어떻게 네 명의 낯선 사람이 되는가

기업은 제품 라인에 따라 성장하며, 시스템도 그에 따라 따라갑니다. 제품 A는 하나의 플랫폼에 있고, 제품 B는 다른 플랫폼에 있습니다. 결제(Billing) 시스템은 자체적인 고객 레코드를 가지고 있습니다. CRM은 또 다른 레코드를 가지고 있습니다. 지원(Support) 시스템은 또 다른 세 번째 레코드를 가지고 있으며, 키(key) 방식도 또 다릅니다.

따라서 "Rajesh Kumar, 42세, Pune"는 다음과 같이 존재합니다:

네 개의 레코드. 한 명의 인간. 이들을 신뢰성 있게 연결할 수 있는 것은 아무것도 없습니다. 왜냐하면 연결해야 할 이유가 전혀 없었기 때문입니다. 각 시스템은 단 하나의 기능을 잘 수행하기 위해 도입되었고, 실제로 그렇게 작동하고 있습니다.

데이터 웨어하우스가 해결하지 못하는 이유

많은 팀이 데이터 웨어하우스 (warehouse)를 보유하고 있음에도 여전히 이 질문에 답하지 못합니다. 왜냐하면 연결되지 않은 네 개의 레코드를 하나의 데이터베이스로 복사하는 것은, 하나의 데이터베이스 안에 연결되지 않은 네 개의 레코드를 갖게 하는 것에 불과하기 때문입니다.

단순히 한곳에 모으는 것(Co-location)은 해상도(resolution)가 아닙니다. 어려운 점은 저장(storage)이 아니라, 바로 _정체성 (identity)_입니다.

실제로 해결하는 방법

1. 제대로 수행되는 엔티티 해상도 (Entity resolution)

검사 가능한 규칙을 바탕으로 확률적으로(probabilistically) 이 레코드들이 동일 인물임을 결정하는 프로세스가 필요합니다. 신호(Signals)는 다음과 같습니다:

• 정규화된 이름 (phonetic + 편집 거리 (edit distance), 정확한 일치가 아닌 방식)
• 정규화된 주소 (문자열 일치가 아닌 실제 주소 파서 (address parser))
• 정규화된 이메일 및 전화번호
• 생년월일
• 공유 주소에 대한 가구 추론 (Household inference)

불리언(boolean) 값이 아닌 **매칭 점수 (match score)**를 출력하세요. 그 다음:

score >= 0.95  -> 자동 병합 (auto-merge)
0.80 - 0.95    -> 수동 검토 대기열 (human review queue)
score <  0.80  -> 별도 유지 (keep separate)

완벽할 수는 없습니다. 신뢰 구간 (confidence band)과 모호한 중간 영역을 위한 검토 경로 (review path)가 필요합니다. 100%를 보장한다는 벤더가 있다면, 그들은 데모 데이터셋 (demo dataset)을 설명하고 있는 것입니다.

2. 변화 속에서도 살아남는 안정적인 키 (stable key)

해상 (resolution)이 완료되면, 정체성 (identity)은 **레코드가 변경되어도 지속되는 내구성이 있는 ID (durable ID)**를 가져야 합니다. 만약 누군가 이사를 가거나 이름을 바꿨을 때 키가 깨진다면, 당신은 정체성이 아닌 스냅샷 (snapshot)을 구축한 것입니다. 사람들이 간과하는 부분이 바로 이것입니다. 키는 사람들의 레코드를 분산시키는 바로 그 이벤트들 속에서도 안정적이어야 합니다.

3. 출처 (provenance)가 있는 골든 레코드 (golden record)

네 개의 시스템이 주소에 대해 서로 다른 의견을 낼 때, 하나가 승리하게 됩니다. 이때 당신은 어떤 소스 (source)가 왜 승리했는지 말할 수 있어야 합니다. 이것은 결벽증적인 태도가 아닙니다. 이것이 레코드를 실행에 옮길 수 있을 만큼 신뢰할 수 있게 만드는 것이며, 누군가 그 레코드를 바탕으로 내려진 결정에 이의를 제기할 때 필요하게 될 요소입니다.

승리한 값뿐만 아니라, 패배한 후보군 (losing candidates)과 그 소스들을 함께 저장하십시오.

4. 결국에는 양방향 흐름 (bidirectional flow)

해상된 정체성은 소스 시스템 (source systems)이 시간이 지남에 따라 개선될 수 있도록 다시 피드백되어야 합니다. 그렇지 않으면 데이터 웨어하우스 (warehouse)는 상류 (upstream)의 누구에게도 도움이 되지 않는 조정 (reconciliation) 작업들의 무덤이 될 뿐입니다.

5. 첫날부터 시작하는 거버넌스 (governance)

여러 제품에 걸쳐 한 개인의 데이터를 통합하는 순간, 당신은 이전에는 존재하지 않았던 개인정보에 민감한 자산 (privacy-sensitive asset)을 생성한 것입니다. 액세스 제어 (access controls), PII 태깅 (PII tagging), 동의 추적 (consent tracking)은 부가 기능이 아닙니다. 이것들이 바로 통합된 뷰 (unified view)를 법적으로 사용할 수 있게 만드는 핵심 요소입니다.

완벽함이 아닌, 좁은 범위부터 시작하라

본능적으로는 2년짜리 "단일 고객 뷰 (single customer view)" 프로그램을 구상하게 됩니다. 그러지 마십시오.

두 개의 시스템 — 보통 중복이 가장 많은 두 시스템 — 을 선택하여 오직 그 사이의 정체성만 해상하십시오. 매칭률 (match rate)을 측정하십시오. 이전에는 볼 수 없었던 것을 한 팀에게 보여주십시오. 그것이 다음 단계의 예산을 확보해 줄 것이며, 작은 폭발 반경 (blast radius) 내에서 당신의 데이터가 가진 실제 특이점들을 학습하게 해줄 것입니다.

이것이 지금 더 중요한 이유

모든 에이전트형/AI (agentic/AI) 프로젝트는 당신이 비즈니스 전반에 걸쳐 한 개인을 식별할 수 있다고 가정합니다. 추천 (Recommendation), 이탈 예측 (churn prediction), 사기 그래프 (fraud graphs), 차기 최적 행동 (next-best-action) — 이 모든 것들은 암묵적으로 엔티티 해상도에 의존합니다. 데이터가 파편화되어 있다면, 이러한 모델들은 요란하게 실패하지 않습니다. 대신, 절반만 볼 수 있는 인물에 대해 확신에 찬 추천을 내놓을 뿐입니다.

화려하지는 않지만 고객 키 (customer key)는, 그 위에 구축된 모든 것이 제대로 작동할지 아니면 조용히 당신을 당혹스럽게 만들지를 결정하는 전제 조건입니다.

우리는 엔티티 해상도 (entity resolution)와 그 이면의 통합 데이터 기반을 구축합니다. 더 자세한 내용은 IntelliBooks에서 확인하세요.