사용자의 발화는 아직 시스템의 질문이 아니다

사내 사용자가 “지난주 장애 문의가 많았던 A사, 아직 미처리 주문도 있어?”라고 말했을 때, 사람은 대체로 바로 답을 기대한다. 하지만 사내 시스템에 이 문장은 아직 질문이 아니다. CRM, 고객지원, 주문 시스템 어느 곳에도 이 문장 그대로의 필드는 없기 때문이다.

이 사실을 인정하는 순간, 대화형 시스템의 첫 번째 임무가 달라진다. 답을 찾는 것이 아니라 말을 질문 가능한 의미 구조로 바꾸는 것이다.

---

문장에는 이미 여러 종류의 일이 섞여 있다

위 문장을 시스템이 처리하려면 최소한 다음을 분리해야 한다.

• 대상: “A사”는 어떤 고객 조직인가

• 기간: “지난주”는 어느 날짜 구간인가

• 사건: “장애 문의”는 어떤 티켓 유형인가

• 판단 기준: “많았던”은 몇 건 이상인가

• 추가 조건: “미처리 주문”의 상태는 무엇인가

• 요구 결과: 두 조건을 동시에 만족하는지, 각각의 수치를 알려 달라는지

자연어에서는 이 모든 정보가 한 문장에 자연스럽게 압축된다. 반면 시스템은 각 조각이 어떤 데이터와 연결되는지 알아야 한다. A사는 고객명일 수 있지만, 영업 DB에는 A 주식회사, 지원 DB에는 A Corp., 주문 DB에는 고객 ID C-1042로 저장돼 있을 수 있다. “지난주”도 대화가 일어난 날짜를 기준으로 계산해야 한다. “많다”는 고객지원팀이 정한 기준이 없다면 사실 값이 아니라 정책의 빈칸이다.

그러므로 발화 분석은 단순한 키워드 추출보다 넓다. 이 과정의 결과는 다음 같은 의미 프레임이어야 한다.

customer: mention="A사"
period: relative="지난주"
support_ticket: category="장애", aggregation=count, comparison="많다"
order: state="미처리"
answer_shape: ticket_count, unresolved_order_count, judgement

이 프레임도 아직 실행 명령은 아니다. 다만 “어떤 질문을 만들어야 하는가”를 드러낸다. 이 중 대상 조직은 실체를 찾아야 하고, 장애와 주문은 사내 개념에 연결해야 하며, ‘많다’는 기준을 확인하거나 물어야 한다.

---

작동 예제: 한 문장이 바로 SQL이 되면 왜 위험한가

입력은 다음과 같다.

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

성급한 시스템은 customer_name LIKE A, ticket_type=장애, order_status≠완료 같은 쿼리를 만들 수 있다. 하지만 이것은 조용히 틀릴 가능성이 크다. A사가 두 곳이면 어떤 조직을 선택했는지 알 수 없고, “미처리”가 결제 대기만 뜻하는지 출고 전도 포함하는지도 불분명하다. 더 나쁜 점은 사용자가 답을 믿을 수 있다는 것이다.

의미 프레임을 먼저 만든 시스템은 상태를 이렇게 남긴다.

entity candidates: A 주식회사 / A솔루션
time range: 2026-08-03 ~ 2026-08-09
ticket filter: category=incident
order filter: state=unresolved
missing policy: “많다”의 기준

여기서 바로 답을 내는 대신, 해소 가능한 것과 해소되지 않은 것을 구분할 수 있다. 두 조직 후보가 모두 살아 있으면 다음 대화로 넘어가고, 조직 하나가 계약·담당자·최근 대화 문맥으로 유일해지면 그때 질의할 수 있다.

이 차이는 LLM의 문장력이 아니라 시스템의 책임 경계다. LLM은 A사와 장애 문의를 의미 후보로 읽어 내는 데 도움을 줄 수 있다. 그러나 어떤 대상 조직을 확정했고, 무엇이 미정인지, 어떤 추가 질문이 필요한지는 구조화된 상태로 남아야 한다.

---

발화를 질문으로 만드는 세 단계

첫째, 표면 표현을 뽑는다. 조직명, 기간, 상태, 수량, 비교 표현처럼 문장에 있는 단서를 수집한다.

둘째, 각각을 사내 개념의 후보로 연결한다. 이 단계에서 장애 문의는 지원 티켓의 분류값일 수 있고, 미처리 주문은 주문의 여러 상태를 아우르는 업무 용어일 수 있다.

셋째, 실행에 필요한 빈칸을 판정한다. 후보가 하나인지, 날짜가 계산 가능한지, 기준이 정의되어 있는지 확인한다. 이 판정이 있어야 대화는 ‘검색 실패’와 ‘질문이 모호함’을 다른 방식으로 다룰 수 있다.

사용자의 말이 시스템 질문이 되는 것은 번역 한 번으로 끝나지 않는다. 후보를 모으고, 문맥을 붙이고, 사내의 의미와 제약을 통과시키는 과정이다. 다음 글에서는 그중 문맥을 붙잡는 역할을 Knowledge Graph가 어떻게 맡는지 살펴본다.

---

운영에서 확인할 질문

발화 분석 결과를 검토할 때는 추출 정확도만 보지 말고 다음을 함께 본다.

• 이 값은 문장에 실제로 있었는가, 추론으로 보완된 것인가?

• 확정된 값과 후보 값이 구분되어 있는가?

• 정책이 필요한 표현을 사실처럼 취급하지 않았는가?

• 답이 아니라 clarification으로 가야 하는 이유가 기록되어 있는가?

예를 들어 “A사 주문”은 조직 후보 문제지만, “급한 주문”은 업무 정의 문제다. 전자는 이름·관계·문맥 증거로 좁힐 수 있다. 후자는 SLA, 출고 마감, 담당 조직의 정책을 확인해야 한다. 둘을 같은 점수 모델로 해결하려 하면 설명이 흐려진다.

발화 프레임은 따라서 일회성 파싱 결과가 아니라 이후 단계가 공유하는 계약이다. 후보 생성은 이 프레임을 읽고, ontology 검증은 어떤 슬롯이 실행 가능한지 판정하며, 대화 정책은 비어 있는 슬롯을 질문으로 바꾼다. 이 공통 상태가 없으면 각 구성요소가 같은 문장을 서로 다르게 해석하게 된다.