스마트 스피커나 음성 비서에게 말을 걸면 대답이 돌아오는 일이 이제 낯설지 않아요.
이런 서비스를 음성 대화 시스템, 영어로 Spoken Dialogue System이라 줄여서 SDS라고 부릅니다.
겉으로는 말하면 대답한다는 한 줄이지만, 속에서는 여러 단계가 이어져 움직이고 있어요.
기획자가 이 단계를 알고 있으면 어디에서 문제가 생겼는지 개발자와 같은 언어로 이야기할 수 있습니다.
이번 글에서는 SDS를 구성하는 다섯 단계의 흐름과 기획자가 챙겨야 할 포인트를 정리해 보겠습니다.
개발 세부 방식은 제품마다 다르니, 일반적인 구조로만 이해해 주세요.
사용자가 말하고 시스템이 대답하기까지의 흐름은 보통 이렇게 나눕니다.
- 음성 인식: 소리를 글자로 바꾼다
- 언어 이해: 글자에서 의도와 필요한 정보를 뽑는다
- 대화 관리: 지금 무엇을 해야 할지 결정한다
- 응답 생성: 말할 문장을 만든다
- 음성 합성: 문장을 소리로 바꾼다
이 다섯 단계는 앞 단계의 결과를 다음 단계가 받는 구조라서, 앞에서 생긴 실수가 뒤로 갈수록 커진다는 특징이 있어요.
이것을 흔히 오류 전파라고 부릅니다.
글자로 하는 챗봇에는 첫 단계가 없지만, 음성에서는 이 첫 단계의 품질이 전체 경험을 좌우하는 일이 많습니다.
또 하나 중요한 건 지연이에요.
단계가 많을수록 각 단계의 처리 시간이 더해져서, 사용자가 말을 마치고 대답을 듣기까지의 시간이 길어집니다.
사람과의 대화에서는 잠깐의 침묵도 길게 느껴지기 때문에, 기획자는 허용할 수 있는 대기 시간의 감각을 개발자와 맞춰 두어야 해요.
먼저 1단계인 음성 인식은 마이크로 들어온 소리를 텍스트로 바꾸는 단계입니다.
주변 소음, 말하는 속도, 억양, 마이크와의 거리에 영향을 많이 받아요.
딥러닝이 확산되면서 인식 정확도가 많이 좋아졌다고 알려져 있지만, 소음이 큰 곳이나 낯선 단어에서는 여전히 틀리는 일이 있습니다.
기획자가 챙길 점은 다음과 같아요.
- 서비스에서 자주 쓰는 고유명사(메뉴 이름, 지역 이름)를 잘 알아듣는지
- 인식이 틀렸을 때 사용자가 어떻게 바로잡을 수 있는지
- 인식하는 데 걸리는 시간이 대화 리듬을 깨지 않는지
인식 결과에는 얼마나 확신하는지를 나타내는 값이 함께 나오는 경우가 많다고 알고 있어요.
확신이 낮을 때 다시 말해 달라고 할지, 확인 질문을 할지를 정해 두면 오류가 뒤로 번지는 것을 줄일 수 있습니다.
이어지는 2단계인 언어 이해는 글자가 된 문장에서 사용자가 무엇을 원하는지, 즉 의도를 찾고 필요한 정보를 뽑는 단계입니다.
"내일 아침 일곱 시에 알람 맞춰 줘"라는 문장에서 의도는 알람 설정이고, 필요한 정보는 날짜와 시간이에요.
이 정보 조각을 슬롯이라고 부르는데, 필요한 슬롯이 비어 있으면 시스템이 되물어야 합니다.
사람은 같은 뜻을 여러 방식으로 말하기 때문에, 기획자는 사용자가 쓸 법한 표현을 최대한 모아 개발자에게 전달하는 일이 중요해요.
대화 관리는 SDS의 두뇌 역할을 합니다.
이해한 결과를 바탕으로 지금 되물을지, 바로 실행할지, 확인을 받을지를 결정해요.
이전 대화를 기억해서 "그럼 그걸로 해 줘" 같은 말을 알아듣는 것도 여기서 처리합니다.
기획자가 가장 많이 개입하는 단계이기도 해서, 시나리오와 예외 처리를 이 단계에서 정의한다고 보면 돼요.
특히 못 알아들었을 때의 폴백 흐름과 상담원 연결 같은 규칙은 이 단계의 설계에 들어갑니다.
되묻기도 여기서 설계해요.
정보가 부족하면 한 번에 하나씩 묻는 편이 사용자가 덜 헷갈리고, 같은 질문을 두 번 이상 반복하게 되면 다른 방법으로 넘기는 규칙을 두는 편이 좋습니다.
응답 생성은 시스템이 말할 문장을 만드는 단계예요.
미리 써 둔 문장 틀에 정보를 끼워 넣는 방식이 현업에서 흔하게 쓰입니다.
기획자는 말투와 길이를 정하는 사람입니다.
소리로 듣는 문장은 읽는 문장보다 짧아야 하고, 한 번에 전달하는 정보를 적게 해야 하기 때문이에요.
음성 합성은 완성된 문장을 소리로 바꾸는 마지막 단계로, 목소리의 톤과 속도가 서비스의 인상을 정합니다.
같은 문장이어도 어떻게 읽느냐에 따라 친근하게도, 딱딱하게도 들리니까요.
가정해서 카페 음성 주문 서비스를 떠올려 볼게요.
사용자가 "아이스 아메리카노 두 잔 주세요"라고 말합니다.
- 인식 단계에서 "두 잔"이 "한 잔"으로 잘못 들렸다
- 이해 단계는 한 잔 주문으로 정확히 이해했다
- 대화 관리는 "아이스 아메리카노 한 잔 맞으세요?"라고 확인한다
- 사용자는 "아니요 두 잔이요"라고 정정한다
이 사례에서는 확인 단계가 있었기 때문에 인식 오류가 주문 오류로 번지지 않았어요.
확인 질문 없이 바로 결제로 넘어가는 설계였다면 사용자는 잘못된 주문을 받았을 겁니다.
다섯 단계를 알면 오류를 어디서 잡을지를 설계할 수 있다는 점이 가장 큰 이득이었어요.
SDS를 단계별로 나눠 보면 기획자가 손댈 수 있는 영역이 생각보다 넓다는 걸 알게 됩니다.
기술을 직접 만들 수 없어도 시나리오, 문장, 확인 규칙으로 경험의 품질을 많이 높일 수 있어요.
남은 질문은 이 단계들을 하나로 합쳐 처리하려는 시도가 늘고 있다는 점이에요.
각 단계를 따로 만들던 방식이 앞으로 어떻게 바뀔지 지켜보며, 기획자가 봐야 할 지점도 함께 갱신해 나가겠습니다.