Conversation Design은 모호성을 숨기지 않고 다음 질문으로 바꾼다

대화형 시스템에서 clarification은 실패 안내가 아니다. 시스템이 아직 확정할 수 없는 것을 정직하게 드러내고, 사용자가 가장 적은 노력으로 그 빈칸을 채우게 하는 질문 설계다. 이를 LLM의 직감에 맡기면 같은 상황에서도 어떤 때는 묻고 어떤 때는 임의로 선택하는 흔들림이 생긴다. 더 안정적인 구조는 모호함을 데이터 상태로 판정하고, LLM은 그 상태를 사람이 답하기 쉬운 문장으로 바꾸게 하는 것이다.

---

무엇을 물어야 하는지는 후보가 말해 준다

예를 들어 A사라는 별칭에서 두 고객이 남았다고 하자.

후보 1: A 주식회사 — 이름 점수 0.91, 지난주 incident 6건
후보 2: A솔루션 — 이름 점수 0.90, 지난주 incident 5건

점수 차이는 0.01이다. 둘 다 고객 조직이고, 둘 다 문장과 양립한다. 이 경우 top-1 점수가 높다는 이유만으로 고르면 위험하다. 시스템이 물어야 할 것은 “더 자세히 말씀해 주세요”가 아니라 후보를 구분할 수 있는 사실이다.

A 주식회사와 A솔루션 중 어느 고객사를 말씀하시나요?

사용자가 “민지 담당 고객”이라고 답하면, Knowledge Graph의 담당자 관계를 통해 A 주식회사로 확정할 수 있다. 질문과 답은 대화용 문장이면서 동시에 후보 상태를 갱신하는 이벤트다.

---

작동 예제: 같은 문장에 두 종류의 모호함

입력:

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

시스템의 중간 상태:

entity candidates: [A 주식회사, A솔루션]
entity margin: 0.01 → clarify 필요
ticket criterion: "많다"
policy threshold: 미정 → clarify 또는 기본 정책 제시 필요
order state: Pending, Processing → ontology로 해소됨

여기에는 서로 다른 질문 두 개가 숨어 있다. A사가 누구인가는 엔터티 모호성이다. ‘많다’가 얼마인가는 업무 정책의 공백이다. 둘을 한 질문으로 뭉치면 사용자가 무엇에 답해야 하는지 알기 어렵다.

좋은 흐름은 우선순위를 둔다.

1. 결과를 완전히 바꾸는 고객 후보를 먼저 해소한다.

2. 그 다음 수치 판단 기준을 물어보거나, 조직의 기본 기준을 명시한다.

3. 이미 ontology로 해소된 상태 범위는 다시 묻지 않는다.

대화는 다음처럼 진행될 수 있다.

시스템: A 주식회사와 A솔루션 중 어느 고객사를 말씀하시나요?

사용자: 민지 담당 고객.

시스템: A 주식회사로 확인했습니다. ‘문의가 많다’는 지난주 장애 티켓 5건 이상 기준으로 볼까요?

사용자: 응.

시스템: 지난주 장애 문의는 6건으로 기준 이상이고, 미처리 주문은 2건입니다.

이때 두 번째 질문은 사용자를 시험하지 않는다. 시스템의 정책을 공개하고 승인받는다. 만약 조직의 공통 기준이 이미 있다면 “5건 이상 기준으로 조회했습니다”라고 알려 주고 바로 실행할 수도 있다.

---

Clarify 정책은 결정론적으로 둔다

간단한 정책은 다음처럼 표현할 수 있다.

validCandidates = 0 → fallback
validCandidates = 1 → resolve
validCandidates > 1 AND margin < 0.15 → clarify
validCandidates > 1 AND strong context evidence → resolve with evidence
policy missing → clarify or present default

여기서 candidate count, score margin, ontology compatibility, 대화 문맥 증거는 모두 관찰 가능한 값이다. 반면 자연스러운 질문의 어조와 선택지 설명은 LLM이 잘할 수 있는 영역이다. 역할을 이렇게 나누면, LLM이 모호함을 느낀다는 불투명한 방식 대신 시스템이 왜 질문했는지 추적할 수 있다.

---

대화 상태는 다음 질문의 자산이다

clarification의 결과를 단순 텍스트 로그로만 남기면 다음 턴에 다시 같은 질문을 하게 된다. 대신 다음처럼 상태를 갱신한다.

grounded organization: customer:acme-corp
evidence: user said "민지 담당 고객"
incident threshold: 5
unresolved states: Pending, Processing
valid until: current conversation

이제 “그 주문 상세도 보여줘”는 다시 A사를 묻지 않아도 된다. 단, 사람이 다른 고객을 언급하거나 세션이 끝나면 이 상태가 언제까지 유효한지 분명히 해야 한다. Conversation Design은 친절한 문장을 고르는 작업을 넘어서, 무엇을 알고 무엇을 모르는지와 그 지식의 유효기간을 관리하는 작업이다.

다음 글에서는 지금까지의 발화, 그래프, ontology, 질의, 대화 정책이 하나의 운영 흐름으로 어떻게 만나는지 정리한다.

---

좋은 clarification을 평가하는 기준

대화 질문은 답변 완성도와 별도로 측정해야 한다. 운영 로그에서 다음을 보면 개선 지점을 찾을 수 있다.

• 사용자가 한 번의 답으로 후보를 해소했는가

• 같은 정보를 다시 묻지 않았는가

• 선택지가 실제로 결과를 바꾸는가

• 사용자가 수정하거나 거절한 비율은 얼마인가

• 질문 후 실행 성공률이 높아졌는가

“어느 A사인가요?”보다 “민지 담당 A 주식회사와 재 담당 A솔루션 중 어느 곳인가요?”가 나은 이유는 선택지가 구별 가능하기 때문이다. 반대로 내부 ID나 시스템별 상태 코드를 묻는 것은 사용자가 알기 어려운 비용을 떠넘긴다.

clarification은 최소 질문 원칙을 따라야 하지만, 무조건 한 번에 하나만 묻는다는 뜻은 아니다. 독립적이고 사용자가 쉽게 답할 수 있는 두 선택지는 함께 제시할 수 있다. 다만 고객 후보와 정책 기준처럼 인지 종류가 다른 항목은 순서를 나누는 편이 대화 상태와 오류 복구에 유리하다.