같은 고객이 세 명으로 보일 때: 온톨로지 엔터티 해소 설계

2026년 8월 29일 기준 데이터 책임자는 중복 고객을 삭제하지 말고 근거별로 연결해야 합니다. 자연키가 충돌하면 자동 병합을 멈춰야 합니다.

같은 이름의 행 세 개는 삭제 후보가 아니라 동일성 가설 세 개입니다. 엔터티 해소는 가장 닮은 행을 고르는 작업이 아니라 식별 근거의 강도에 따라 연결·검수·분리를 결정하고, 그 이유와 원본을 남기는 과정입니다.

지금 맡은 역할에 따라 첫 결정을 바꾸십시오#

• 데이터 책임자가 고객 마스터를 정리한다면 시스템별 식별자와 자연키의 생성·변경 규칙부터 확인합니다.
• CRM 운영자가 이름·주소 표기의 흔들림을 다룬다면 원문과 별칭을 보존한 채 정규화 규칙을 검증합니다.
• AI 제품 책임자가 유사도 후보를 자동화한다면 실제 데이터로 처리 경계를 검증하기 전까지 사람 검수로 보냅니다.

같은 고객 판단은 어떤 근거로 나누나요?#

아래 표는 2026년 8월 29일 알파카랩스의 D등급 관측 가설입니다. 자동 처리의 보편 임계값이 아니라 조직별 데이터와 위험 수준으로 검증할 경계표입니다.

후보 탐지와 병합 결정을 분리하십시오#

1. 사업자등록번호·사번·고객번호처럼 키 종류별 정규화 규칙을 따로 둡니다.
2. 자연키 일치와 의미 유사도를 서로 다른 후보 탐지 근거로 기록합니다.
3. 근거가 충분한 후보와 사람이 확인할 후보, 분리할 후보를 나눕니다.
4. 병합은 원본 행을 삭제하는 대신 동일성 관계와 대표 식별자를 기록합니다.
5. 오병합 때 관계를 끊고 대표 식별자를 다시 계산하는 병합 해제 절차를 시험합니다.

고객 시스템 전환까지 함께 검토한다면 커스텀 CRM 마이그레이션 절차를 참고할 수 있습니다. 온톨로지 범위는 Ontokit 소개에서 확인하고, ERP의 용어·출처·권한을 먼저 정하는 흐름은 ERP 데이터 AI 에이전트 구축 가이드와 이어서 볼 수 있습니다.

내부 구현에서 확인한 증거는 어디까지인가요?#

C 자기표기, 2026년 8월 29일 확인. Ontokit 내부 구현은 자연키 일치와 임베딩 유사도를 후보 탐지 방식으로 구분합니다. 사업자등록번호, 사번, 품목 코드와 한국어 법인명에는 서로 다른 정규화 규칙을 적용하고 후보 쌍의 순서를 고정해 중복 생성을 막습니다.

병합 서비스는 원본 객체를 지우지 않고 SAME_AS 관계와 대표 식별자를 기록하며 병합 해제를 지원합니다. 내부 테스트에는 자연키 후보 처리, 검수 라우팅, 같은 요청의 중복 실행, 원본 보존, 병합 해제와 트랜잭션 롤백이 포함돼 있습니다.

이 증거는 제품 코드와 테스트의 존재를 확인한 C등급 자기표기입니다. 실제 고객 데이터의 정확도, 적정 처리 경계, 처리량, 비용 절감과 운영 성과는 공개 검증되지 않아 미확인입니다.

이름 유사도만으로 삭제 병합하면 왜 실패하나요?#

이름이 같아도 다른 고객일 수 있고, 이름이 달라도 같은 법인의 표기 변형일 수 있습니다. 단일 유사도 점수는 이 두 경우를 함께 설명하지 못합니다. 자연키가 충돌하거나 원문 출처가 모순되면 자동 병합을 멈추고 사람이 근거를 확인해야 합니다.

규제 대상 고객이나 권리·지급에 영향을 주는 마스터 데이터라면 자동 병합을 쓰지 않고 모든 후보를 사람이 검수하는 선택도 타당합니다. 자동화 비율보다 잘못 합쳤을 때의 피해와 복구 가능성을 먼저 비교해야 합니다.