Knowledge Graph는 답을 저장하는 곳이 아니라, 발화의 문맥을 붙잡는 장치다

“A사”라는 말은 데이터베이스의 키가 아니다. 누군가에게는 A 주식회사이고, 다른 화면에서는 A Corp.이며, 계약 시스템에서는 C-1042일 수 있다. 사용자 발화를 다루는 시스템에서 Knowledge Graph가 필요한 이유는 모든 답을 그래프에 복사해 넣기 위해서가 아니다. 흩어진 이름과 사건, 관계를 연결해 지금 이 말이 가리키는 문맥을 놓치지 않기 위해서다.

---

그래프가 잡는 것은 정답보다 연결이다

앞 글의 발화로 돌아가 보자.

지난주 장애 문의가 많았던 A사, 아직 미처리 주문도 있어?

검색 단계는 A사에 대해 다음 후보를 만든다.

A사
├─ customer:acme-corp   label="A 주식회사"
└─ customer:asolution   label="A솔루션"

이때 Knowledge Graph는 A사 = A 주식회사라고 성급히 덮어쓰지 않는다. 대신 각 후보 주변의 사실을 잇는다.

customer:acme-corp
├─ hasAlias → "A사", "A Corp."
├─ hasAccountManager → user:minji
├─ hasSupportTicket → ticket:1842
└─ hasOrder → order:7781

customer:asolution
├─ hasAlias → "A사"
├─ hasAccountManager → user:jae
└─ hasSupportTicket → ticket:2910

여기서 지난주 장애 문의라는 후속 단서는 두 후보를 가르는 근거가 된다. acme-corp에 지난주 incident 티켓이 6건, asolution에는 0건이라면, 첫 후보의 문맥 적합도가 높아진다. 반대로 둘 다 해당된다면 그래프는 모호함을 숨기지 않고 유지해야 한다.

---

Knowledge Graph와 Ontology는 같은 말이 아니다

둘을 자주 한 덩어리로 부르지만 역할은 다르다. Knowledge Graph는 “현재 연결된 사실”에 가깝다. 어떤 고객이 어떤 담당자와 연결되는지, 어떤 티켓과 주문이 있는지, 명칭이 어떻게 쓰였는지를 담는다. Ontology는 그 사실을 해석하는 공통 약속에 가깝다. 고객 조직이 무엇인지, 티켓과 주문이 어떤 관계를 가질 수 있는지, 속성의 범위와 제약이 무엇인지를 정의한다.

간단히 말하면 그래프는 A사가 무엇과 이어져 있는가를 보여 주고, ontology는 무엇을 고객·주문·티켓이라고 부를 것인가를 정한다. 그래프만 있으면 관계가 제각각이라 질문을 일관되게 만들기 어렵고, ontology만 있으면 실제 고객의 별칭과 사건 문맥을 잡기 어렵다.

---

작동 예제: 후보를 지우지 않고 문맥을 더한다

다음은 시스템 내부에서 가질 수 있는 작은 후보 스키마다.

mention: "A사"
candidates:
- id: customer:acme-corp
    lexicalScore: 0.91
    graphEvidence: ["지난주 incident 티켓 6건", "현재 대화의 담당자 민지와 연결"]
- id: customer:asolution
    lexicalScore: 0.90
    graphEvidence: ["지난주 incident 티켓 0건"]

두 이름 유사도는 거의 같다. 하지만 문장 전체와 그래프의 관계를 함께 보면 acme-corp가 더 적합하다. 중요한 것은 점수 0.91이라는 숫자가 아니라, 왜 그 후보가 살아남았는지 설명할 증거가 남는다는 점이다.

사용자가 “민지 담당 고객 맞아”라고 답하면 hasAccountManager → user:minji 관계가 새 문맥 증거가 되어 후보는 하나로 좁혀진다. 반대로 어느 쪽인지 말하지 않았다면 그래프는 임의 선택의 근거가 되어서는 안 된다. 후보가 둘이라는 사실 자체가 다음 대화를 설계할 정보다.

---

그래프를 작게 시작하는 법

처음부터 전사 데이터를 거대한 그래프로 옮길 필요는 없다. 질문이 자주 지나는 경로부터 시작하면 된다.

• 고객의 여러 이름과 고객 ID

• 고객–담당자–계약의 관계

• 고객–지원 티켓–주문의 관계

• 최근 대화에서 확정된 엔터티와 근거

이 네 종류만으로도 “누구의 어떤 사건을 묻는가”는 크게 안정된다. 원본 데이터는 기존 CRM, ERP, 지원 시스템에 남겨 둬도 된다. 그래프는 그것을 대체하는 저장소가 아니라, 발화와 시스템 사이의 연결층이기 때문이다.

다음 단계는 이 연결에 공통 의미를 부여하는 일이다. 어떤 시스템의 고객과 다른 시스템의 거래처가 같은지, 미처리의 범위가 무엇인지 정하지 않으면 그래프가 모은 후보도 일관된 질문이 되지 않는다. 그 약속을 만드는 것이 ontology다.

---

그래프의 증거에는 출처와 시간도 붙인다

관계 자체만 저장하면 오래된 문맥이 새 판단을 오염시킬 수 있다. “민지가 담당자다”라는 사실에는 CRM의 레코드 ID와 유효 시작·종료 시점을 붙이는 편이 좋다. 티켓 수 역시 실시간 집계인지 하루 전 스냅샷인지 구분해야 한다.

customer:acme-corp hasAccountManager user:minji
source=crm, validFrom=2026-07-01, confidence=verified

이런 provenance가 있으면 왜 후보를 선택했는지뿐 아니라, 어느 원천의 어느 시점 사실을 사용했는지도 되짚을 수 있다. 그래프는 단순 연결 그림이 아니라 candidate scoring과 설명 가능한 grounding을 위한 근거 레이어다.

또한 alias는 1:1 사전으로 만들지 않는 편이 안전하다. “A사” → 여러 entity라는 N:M 연결을 보존해야 나중의 문맥과 ontology 제약이 후보를 줄일 여지가 생긴다. 별칭 하나를 초기에 canonical entity로 고정하는 순간, 시스템은 자신이 모르는 모호함을 잃어버린다.