예를 들어 CRM에는 ‘김철수’, 결제 시스템에는 ‘김 철수’로 등록된 고객이 있다고 해보자. 이메일도 개인 주소와 회사 주소로 다르다. 이 기록을 별개의 고객으로 집계하면 고객 수나 구매 이력을 잘못 계산할 수 있다.
데이터의 객체와 관계를 정의하는 작업에 앞서, 서로 다른 기록이 같은 대상을 가리키는지 확인해야 한다. 이를 개체 해소 또는 엔티티 해상도 분석(entity resolution)이라고 한다.
같은 개념과 같은 대상을 구분한다
여러 시스템의 ‘고객’을 하나의 공통 객체 유형으로 정의해도 개별 기록의 중복이 자동으로 해결되지는 않는다. 두 기록이 모두 고객이라는 것과 두 기록이 같은 고객이라는 것은 다른 판단이다.
같은 공급사가 여러 ID로 등록돼 있으면 발주액을 합산할 때 누락할 수 있다. 반대로 이름이 비슷한 서로 다른 법인을 합치면 매출과 계약을 잘못 연결할 수 있다. 중복을 줄이는 것과 잘못된 병합을 막는 것을 함께 고려해야 한다.
어느 필드가 일치했는지 본다
이름이 같은 두 사람보다 이름과 연락처, 주소가 함께 일치하는 두 기록이 동일인일 가능성이 높을 수 있다. 흔한 이름의 일치는 희귀한 값의 일치보다 약한 증거일 수 있다. 다만 가족이 연락처를 공유하거나 회사 주소가 바뀌는 경우도 있어 필드별 한계를 알아야 한다.
Splink의 공식 설명은 고유 식별자가 없는 데이터에서 확률적으로 기록을 연결하는 방법을 다룬다. 기반이 되는 Fellegi–Sunter 방식은 일치하는 기록과 다른 기록에서 각 관측값이 나타날 가능성을 비교한다. 문자열이 닮았는지 하나만 보는 접근보다 풍부한 근거를 사용할 수 있다.
모든 쌍을 비교할 필요는 없다
기록 100만 개를 서로 모두 비교하면 약 5천억 쌍이 된다. 그래서 지역이나 정규화한 이름 등으로 비교 후보를 먼저 좁히는 블로킹을 사용한다. 후보를 너무 좁히면 실제로 같은 기록을 놓칠 수 있으므로 속도와 누락률을 함께 봐야 한다.
후보를 찾은 뒤에는 자동 연결할 범위와 검토할 범위를 정한다. 애매한 기록을 억지로 합치지 않고 보류할 수 있어야 한다. 사람이 확인한 판정과 근거는 다음 평가에 활용할 수 있다.
원본과 연결 이력을 보존한다
공통 ID를 정할 때 기존 시스템의 ID를 없애기보다 대응 관계를 남긴다. 어떤 기록을 언제 연결했고 어떤 근거를 사용했는지 알 수 있어야 잘못된 연결을 수정할 수 있다.
이름이나 이메일을 바꾼 고객, 합병한 법인처럼 시간에 따라 관계가 바뀌는 사례도 있다. 현재의 연결 결과와 과거 시점의 기록을 구분해 보존하면 분석 기준을 설명하기 쉽다.
온톨로지와 AI를 도입해도 이 확인 작업은 남는다. 모델이 참고하는 대상부터 일관되게 식별해야 그 위에서 계산하고 실행한 결과를 신뢰할 수 있다.