챗봇으로 예약 받기, 자연어 예약 시나리오 기획

 

예약 서비스를 기획하다 보면 한 번쯤 이런 상상을 하게 됩니다.
고객이 폼을 채우는 대신 "다음 주 목요일 저녁에 두 명 자리 있어요?"라고 말하면 알아서 예약까지 이어지면 좋겠다는 상상이에요.
LLM을 공부하면서 이 상상이 꽤 현실적인 범위에 들어왔다고 느꼈고, 그래서 시나리오를 기획 문서 수준으로 한 번 그려봤습니다.
이 글은 제가 정리한 구조와, 그 과정에서 가장 중요하다고 느낀 책임 분리에 대한 기록입니다.

 

자연어로 예약을 받는 일을 분해해보면, 결국 필요한 정보를 모으는 일입니다.
예약 한 건이 성립하려면 최소한 어떤 서비스인지, 날짜와 시간은 언제인지, 몇 명인지, 누구에게 연락하면 되는지가 필요해요.
이 필요한 항목들을 흔히 슬롯이라고 부르고, 고객 발화에서 슬롯을 채워 나가는 방식을 슬롯 채우기라고 합니다.
예약 가능 시간을 계산할 때의 슬롯과 이름이 같아서 처음에는 헷갈렸는데, 여기서는 "대화에서 채워야 할 빈칸"이라는 뜻이에요.

가정 예시로 따라가 보겠습니다.
고객이 "목요일 저녁에 커트 예약하고 싶어요"라고 말하면, 서비스는 커트, 날짜는 이번 주 목요일, 시간대는 저녁까지 채워집니다.
하지만 정확한 시각과 연락처는 비어 있죠.
이때 챗봇이 비어 있는 항목을 이어서 물어보는 것이 슬롯 채우기 대화의 기본 모양입니다.

 

되묻기 설계에는 몇 가지 원칙이 필요하다고 느꼈습니다.
첫째, 한 번에 여러 가지를 물으면 고객이 답을 놓치기 쉬워서 가능하면 한 가지씩 묻습니다.
둘째, 이미 말한 정보를 다시 묻지 않아야 합니다.
셋째, 시간대가 "저녁"처럼 모호하면 선택지를 제시하는 편이 낫습니다.
"저녁이면 오후 6시, 7시, 8시에 자리가 있어요, 어느 시간이 좋으세요?"처럼 실제로 가능한 시간을 보여주면 고객은 고르기만 하면 됩니다.

모호한 표현은 생각보다 자주 나옵니다.
"다음 주 초", "주말쯤", "퇴근하고" 같은 말은 사람이 들으면 대충 알아듣지만, 시스템에는 해석 규칙이 필요해요.
오늘 날짜를 기준으로 "이번 주 목요일"과 "다음 주 목요일"을 가르는 규칙도 기획서에 적어야 하고, 헷갈릴 만하면 날짜를 풀어서 "10월 12일 목요일 맞으세요?"라고 확인하는 단계를 두는 게 안전합니다.

여러 슬롯이 한 문장에 한꺼번에 담겨 오는 경우도 있습니다.
"금요일 오후 두 시에 두 명이서 파마하고 싶은데요"라는 한 문장에는 날짜, 시간, 인원, 서비스가 다 들어 있어요.
이럴 때는 이미 채워진 값을 확인만 하고 바로 다음 단계로 넘어가야 대화가 쓸데없이 길어지지 않습니다.
반대로 고객이 중간에 "아 그냥 토요일로 할게요" 하고 값을 바꾸는 경우도 있어서, 이미 채운 슬롯을 덮어쓰는 규칙도 기획서에 적어두었습니다.

 

이번 정리에서 가장 중요하다고 생각한 원칙은 이것입니다.
모델은 고객의 말에서 의도와 정보를 뽑아내는 일을 맡고, 실제 예약 가능 여부 판단과 예약 확정은 예약 시스템이 책임져야 합니다.

LLM에게 "이 시간에 자리가 있다고 말해줘" 같은 판단을 맡기면, 환각이 생길 수 있고 같은 질문에도 답이 달라질 수 있어요.
그래서 구조를 이렇게 나눠봤습니다.
모델은 대화에서 서비스, 날짜, 시간, 인원 같은 값을 구조화된 형태로 뽑아냅니다.
시스템은 그 값으로 예약 가능 시간을 조회하고, 가능한 후보를 모델에게 돌려줍니다.
모델은 그 후보를 자연스러운 말로 고객에게 전달합니다.
예약을 확정하는 쓰기 동작은 시스템의 정해진 규칙을 통과해야만 실행됩니다.

이렇게 하면 모델이 잘못 알아들어도 시스템이 막아줄 수 있습니다.
예를 들어 모델이 존재하지 않는 서비스 이름을 뽑아내더라도 시스템 쪽에서 "그런 서비스는 없다"고 걸러낼 수 있어요.
LLM의 말솜씨와 예약 시스템의 정확성을 역할로 나눠 가진다고 생각하면 이해가 쉬웠습니다.

 

예약이 확정되기 직전에는 반드시 요약 확인 단계를 두려고 합니다.
"10월 12일 목요일 오후 7시, 커트 1명, 연락처 끝자리 1234로 예약할까요?"처럼 모든 슬롯을 한 번에 보여주고, 고객이 명시적으로 "네"라고 답해야 확정되게 하는 거예요.
이 단계가 없으면 "아니 그게 아니라"로 이어지는 잘못된 예약이 생기고, 취소와 알림 처리까지 줄줄이 따라옵니다.

실패 상황도 미리 적어두었습니다.
고객이 말한 시간이 이미 마감됐을 때는 가장 가까운 대안을 두세 개 제안합니다.
모델이 말을 못 알아들은 경우에는 두세 번 되묻고, 그래도 안 되면 "직접 예약 화면으로 이동하기" 링크를 제공합니다.
시스템 오류가 났을 때는 예약이 됐는지 안 됐는지 애매한 상태가 가장 위험하기 때문에, "예약이 완료되지 않았습니다"라고 분명히 알려주는 문구가 필요해요.
챗봇은 폼 예약의 대체가 아니라 또 하나의 입구이고, 막혔을 때 기존 입구로 돌아갈 길이 항상 열려 있어야 한다고 생각합니다.

 

자연어 예약은 화려한 기능처럼 보이지만, 기획해 보니 대화 설계보다 책임 분리와 예외 처리가 훨씬 큰 비중을 차지했습니다.
아직 남은 질문도 많습니다.

같은 슬롯에 두 사람이 거의 동시에 예약을 시도할 때 챗봇 대화 중 안내한 빈 시간을 어떻게 보장할지, 개인정보인 연락처를 대화창에서 받아도 되는지, 테넌트마다 필수 정보가 다를 때 슬롯 구성을 어떻게 설정하게 할지 같은 것들이에요.
이 부분은 개발자와 이야기하면서 하나씩 좁혀가 볼 생각입니다.