온톨로지를 깔면 에이전트가 똑똑해질 거라 믿고 몇 주를 쓴다. 객체 타입을 정의하고, 링크를 잇고, 다이어그램은 근사하게 나온다. 그런데 "이번 분기에 이탈한 고객이 몇이야"라고 물으면 숫자가 이상하다. CRM의 '김철수’와 결제 시스템의 ‘김 철수’, chulsoo@a.com으로 가입했다가 chulsoo@work.com으로 결제한 사람이 서로 다른 노드로 앉아 있다. 에이전트는 한 사람을 둘로 세고, 이탈률을 두 배로 부풀린다. 모델이 틀린 게 아니다. 그래프의 노드가 현실의 실체와 1:1이라는 보장이 애초에 없었을 뿐이다.
온톨로지는 그래프가 아니라 '같음’의 판정 위에 선다
온톨로지의 매력적인 부분은 다 표면이다. 객체 타입, 속성, 링크 타입, 그리고 그 위에서 행동하는 에이전트. 하지만 이 구조 전체는 하나의 조용한 전제에 얹혀 있다. 하나의 노드는 정확히 하나의 실체에 대응한다. 이 전제가 깨지면 그 위의 모든 것이 거짓말을 한다. 같은 공급사가 세 개의 노드로 흩어져 있으면 "이 업체에 대한 총 발주액"은 3분의 1로 쪼개진 채 나오고, 같은 부품이 두 개의 SKU로 앉아 있으면 재고는 늘 안 맞는다.
그래서 Palantir Foundry의 온톨로지에서 시맨틱 레이어가 가장 먼저 하는 일이 ‘user’, ‘client’, 'individual’처럼 시스템마다 다르게 불리던 개념을 하나의 Person 엔티티로 화해시키는 것이다. 그리고 Palantir는 이 화해 작업을 온톨로지의 곁다리로 두지 않고, 아예 'Foundry Entity Resolution’이라는 별도 기능으로 판다. 문구는 정직하다 — 흩어진 레코드를 AI로 연결해 "중복이 제거된, 신뢰할 수 있는 데이터 기반"을 세운다는 것. 화려한 온톨로지 데모를 파는 회사가, 정작 그 아래에서 돈을 받는 지점은 '이 둘이 같은가’를 판정하는 지겨운 노동이라는 뜻이다.
'개체 해소’는 검색이 아니라 판정이다
이 블로그에서 앞서 두 가지 함정을 짚은 적이 있다. RAG는 '참’이 아니라 '비슷한 문단’을 물어오고, 텍스트-투-SQL은 '매출’이 하나로 정의돼 있지 않으면 매번 다른 숫자를 낸다. 개체 해소는 그보다 한 겹 더 아래에 있는 문제다. 두 레코드가 얼마나 비슷한가가 아니라, 같은 하나인가를 판정하는 일이다. 비슷함은 정도의 문제지만, 같음은 참·거짓의 문제다.
이 문제의 뼈대는 새것이 아니다. 1969년 통계청의 Fellegi와 Sunter가 확률적 레코드 링크의 틀을 세웠고, 반세기가 지난 지금도 Splink 같은 오픈소스 라이브러리가 그 모델 위에 돌아간다. 이 틀이 주는 핵심 통찰이 하나 있다. 두 레코드가 흔한 값에서 일치하는 것(이름이 둘 다 ‘김민수’)보다 희귀한 값에서 일치하는 것(같은 상세 주소, 같은 사업자번호)이 훨씬 강한 '같음’의 증거다. 우연히 겹칠 확률이 낮기 때문이다. 즉 개체 해소는 단순 문자열 대조가 아니라, 각 필드가 신원을 얼마나 강하게 가리키는지를 가중치로 저울질하는 확률적 판정이다.
LLM은 이 문제를 공짜로 풀어주지 않는다
"임베딩이 있잖아, 'IBM’과 'International Business Machines’를 가깝게 놓을 텐데"라고 생각하기 쉽다. 하지만 임베딩의 가까움은 유사도이지 신원이 아니다. 한 그룹의 서로 다른 두 자회사가 임베딩 공간에서는 같은 회사의 오탈자보다 더 가까이 놓일 수도 있다. 가까움을 같음으로 착각하는 순간, 서로 다른 두 법인이 하나로 병합돼 회계가 뒤엉킨다.
게다가 규모가 붙으면 순진한 방법은 무너진다. 레코드 100만 개를 서로 다 비교하면 5,000억 쌍이다. 그래서 실무의 개체 해소는 '블로킹’으로 후보를 좁히고, 필드별 가중치를 매기고, 자동 병합·자동 분리·사람 검토의 임계값을 도메인마다 다르게 튜닝한다. 바로 이 튜닝에 도메인 지식이 박힌다. 의료에서 같은 환자를 판정하는 규칙과 이커머스에서 같은 셀러를 판정하는 규칙은 겹치지 않는다. 지겹고, 도메인마다 처음부터 다시 해야 하고, 그래서 남이 베낄 수 없다.
처방: 그래프를 그리기 전에 '같음’을 고정하라
에이전트에 온톨로지를 붙이려는 작은 팀이 가져갈 노선은 셋이다.
- 노드보다 식별자를 먼저 만들어라. 에이전트가 객체를 만들고 링크를 잇게 하기 전에, 핵심 엔티티(고객·공급사·제품)마다 시스템을 가로지르는 하나의 표준 ID(canonical ID)를 확정하라. 이 앵커가 없으면 그래프는 매 적재마다 중복을 새로 낳는다.
- 매칭을 유사도가 아니라 판정으로 다뤄라. '비슷하니 병합’이 아니라, 확률과 임계값으로 자동 병합·자동 분리·보류를 가른다. 애매한 쌍은 조용히 합치지 말고 검토 큐로 보내라. 잘못된 병합은 잘못된 분리보다 되돌리기 훨씬 어렵다.
- 개체 해소의 결정 이력을 자산으로 쌓아라. "이 둘은 같다 / 이 둘은 다르다"는 사람의 판정 하나하나가 곧 라벨이고, 그 라벨 더미가 다음 매칭 모델을 강화한다. 이게 시간이 갈수록 두꺼워지는 도메인 해자다.
온톨로지 다이어그램은 하루면 그린다. 그 아래에서 회사 데이터 전체에 걸쳐 '무엇이 무엇과 같은가’를 옳게 판정하는 일은 몇 달이 걸리고, 도메인마다 다르고, 경쟁사가 당신의 스키마를 통째로 복사해도 따라오지 못한다. 누구나 같은 모델과 같은 그래프 도구를 쓰는 시대에, 마지막까지 복제되지 않는 해자는 화려한 노드와 엣지가 아니다. 당신 회사만 옳게 아는 '이 둘이 같은 실체다’라는 판정, 그 지겨운 노동의 축적이다.