사용자의 말과 사내 시스템은 ontology에서 만난다

사내 사용자가 회사의 시스템에 질문하는 순간, 실제로는 두 세계가 만난다. 한쪽에는 생략과 맥락, 말투와 모호함이 있는 사용자의 언어가 있다. 다른 한쪽에는 ID, 상태값, 권한, 시스템별 스키마와 원본 데이터가 있다. 둘 사이를 무리하게 직결하면 대화는 그럴듯해도 근거 없는 답을 하거나, 데이터는 정확해도 사용자의 표현을 이해하지 못한다.

Ontology는 이 둘이 만나는 중간의 약속이다. 사용자의 말을 그대로 데이터 컬럼으로 바꾸는 것도 아니고, 사내 데이터를 하나의 거대한 저장소로 합치는 것도 아니다. “어떤 대상을 무엇이라 부르고, 어떤 관계를 따라, 어떤 조건이면 이 질문에 답할 수 있는가”를 공동으로 정의하는 층이다.

---

하나의 질문이 지나가는 길

전체 흐름은 다음과 같다.

사용자 발화

→ 의미 프레임

→ 후보와 문맥의 Knowledge Graph

→ ontology의 타입·관계·정책 검증

→ SPARQL 또는 API 질의

→ 답변 또는 clarification

→ 갱신된 대화 상태

이 순서에서 어느 하나도 나머지를 대신하지 않는다.

발화 분석은 “A사”, “지난주”, “장애 문의”, “미처리 주문”을 찾아낸다. Knowledge Graph는 A사라는 이름으로 불리는 조직 후보와 담당자·계약·최근 사건의 문맥을 연결한다. Ontology는 그 후보가 Organization이고, incident 티켓과 order가 어떤 관계로 묶이며, 미처리의 범위가 무엇인지 결정한다. SPARQL은 이 약속을 실행 가능한 질문으로 바꾼다. 후보가 남거나 정책이 비어 있으면 Conversation Design은 답을 꾸며 내지 않고 다음 질문을 만든다.

---

작동 예제: 사용자의 말이 사내 질문이 되는 순간

입력은 평범하다.

민지 담당 A사 지난주 장애 문의가 많았던 곳 맞지? 미처리 주문도 확인해줘.

1. 발화 분석

대상=A사, 담당자=민지, 기간=지난주, 사건=장애 문의, 주문 상태=미처리, 수치 기준=많다.

1. Knowledge Graph의 후보 축소

A사는 A 주식회사와 A솔루션 두 후보를 가진다. 둘 중 민지가 담당자인 것은 A 주식회사다. 이 시점에 엔터티는 customer:acme-corp로 grounding된다.

1. Ontology와 정책 검증

A 주식회사는 Organization이다. Organization은 SupportTicket과 Order를 가질 수 있다. 장애 문의는 Incident, 미처리는 Pending과 Processing으로 해석된다. ‘많다’의 기본 기준은 최근 7일 5건 이상이다.

1. 질의 실행

incident 티켓을 기간으로 필터링해 집계하고, 같은 Organization의 미처리 주문을 집계한다.

1. 결과

지난주 장애 문의 6건, 미처리 주문 2건. 시스템은 “기준 이상인 6건의 장애 문의가 있었고, 미처리 주문은 2건입니다”라고 답한다.

이 답이 신뢰할 만한 이유는 문장이 자연스러워서가 아니다. 어떤 대상 조직을 대상으로 했는지, ‘지난주’가 어느 기간인지, ‘많다’의 기준이 무엇인지, 미처리의 상태 범위가 무엇인지 되짚을 수 있기 때문이다.

---

설계의 책임을 섞지 않는 원칙

이 구조를 운영하려면 각 층의 책임을 분명히 나누는 것이 좋다.

• Retrieval은 무엇일 가능성이 있는지 후보를 넓게 모은다.

• Knowledge Graph는 후보와 주변 사실, 대화 문맥을 연결한다.

• Ontology와 Rule은 무엇일 수 없는지 제거하고 업무 의미를 고정한다.

• SPARQL/API는 확정된 의미를 원본 시스템에 실행한다.

• Dialogue Policy는 지금 확정해도 되는지, 더 물어야 하는지를 결정한다.

• LLM은 발화 해석, 후보 표현 보조, 자연스러운 clarification과 결과 설명처럼 언어가 필요한 곳에 배치한다.

특히 LLM에게 “알아서 맞는 답을 골라라”라고 맡기지 않는 것이 중요하다. 후보가 복수라는 사실은 alias와 graph 구조에서 결정론적으로 드러날 수 있고, 확정 불가 상태도 정책으로 정의할 수 있다. LLM은 그 구조적 판단을 사용자가 이해할 수 있는 질문으로 바꾸는 역할을 맡을 때 가장 안전하다.

---

ontology는 대화 설계의 뒷부분이 아니다

Conversation Design을 화면 문구나 챗봇 톤으로만 보면 ontology와 멀어 보인다. 하지만 실제로는 가장 가까운 관계다. 어떤 선택지를 사용자에게 보여 줄 수 있는지, 이미 확정한 정보는 무엇인지, 어떤 질문이 답을 유의미하게 바꾸는지는 모두 엔터티·관계·제약을 알아야 결정할 수 있다.

반대로 ontology도 백엔드 문서로만 남으면 살아 움직이지 않는다. 사용자가 어떤 말로 개념을 부르는지, 어떤 모호함이 반복되는지, 어느 정책을 자주 물어보는지는 대화에서 계속 발견된다. 이 발견은 alias, relation, rule, clarification policy를 다시 개선하는 입력이 된다.

그래서 좋은 사내 ontology는 완성된 도감이 아니라 질문을 통해 자라는 운영 자산이다. 사용자의 말이 시스템의 질문으로 바뀌고, 답의 근거가 다시 다음 대화의 문맥이 되는 순환. 그 순환을 설계하는 일이 Knowledge Graph, ontology, SPARQL, Conversation Design을 하나의 제품으로 묶는다.

---

이 흐름을 시작할 때의 작은 로드맵

처음부터 완전한 그래프와 ontology를 만들 필요는 없다. 한 팀이 자주 묻는 교차 시스템 질문 하나를 고른다. 그 질문의 발화 예시를 30개 정도 모으고, 그 안의 별칭·상태·기간·정책 표현을 표시한다. 그 뒤 필요한 최소 엔터티와 관계, 원천 매핑, clarification 규칙을 만든다.

다음은 세 가지 지표로 개선할 수 있다.

• 후보는 충분히 회수되는가: retrieval의 recall

• 잘못된 확정 대신 적절히 질문하는가: grounding·clarification 정확도

• 답의 근거를 재현할 수 있는가: 질의·매핑·정책의 추적성

이 세 지표를 함께 보면 “답변이 자연스러운가”만으로는 보이지 않던 문제가 드러난다. 사용자의 표현을 놓친 것인지, 시스템의 의미 계약이 비어 있는 것인지, 데이터가 아직 연결되지 않은 것인지 구분할 수 있기 때문이다.

결국 ontology 중심의 대화 시스템은 한 번에 정답을 내는 마술이 아니다. 모르는 것을 구조적으로 보존하고, 확인할 것을 묻고, 확인된 의미만 실행하는 운영 방식이다. 그 방식이 쌓일수록 사용자의 말은 더 안전하게 사내 시스템의 질문이 된다.