챗봇을 넘어 음성봇으로
부상하는 비즈니스 마케팅 채널! 챗봇(ChatBot)
이번 글에서는 AI스피커로 시작되어 업계에 큰 관심을 받고 있는 음성인식 기술 기반의 음성봇(Voicebot) 구조를 챗봇 구조와 연계 시켜 설명 드리겠습니다.
음성봇과 챗봇은 닮은 점이 많다?
앞서 챗봇의 구조는 대화의도(Intent)를 추출하는 것과 의도 속에 담긴 중요한 개체(Entity)를 추출하는 과정이 중요하다고 말씀 드렸습니다. 챗봇에서 AI기술은 사용자의 수많은 대화 방식 속에서 사용자 의도와 개체를 정확하고 빠르게 추출하는 데 활용이 되는 것이죠. 물론 추출된 의도와 개체로 주문이나 예약, 고객서비스와 같이 서비스를 제공하기 위해 대화흐름을 코딩이나 별도 운영 툴(Tool)을 이용해서 구현해야 합니다.
Figure 1. 챗봇의 일반적 구조로 의도추출-개체추출-시나리오가 주 구성요소이다.
그렇다면 음성봇은 어떤 구조로 되어 있을까요? 음성봇의 구조를 정리하면 다음과 같습니다.
1.사용자 인터페이스를 위한 디바이스
: 스마트폰, AI스피커, TV, 자동차 같은 접점 디바이스를 의미합니다. 이러한 디바이스는 대부분 인터넷/LTE이라는 데이터망을 통해 음성 데이터가 전달되기도 하지만, 전화를 기반으로 하는 ARS 음성망일 경우 서킷 망을 통해 음성 데이터가 전달되기도 합니다.
2.음성인식을 위한 클라이언트 어플리케이션
: 디바이스에서 음성 데이터를 입력 받아 네트워크를 통해 서버에 전송하여 음성변환(STT), 의도분석, 개체추출 등을 통해 적절한 답변(Response)를 음성화(TTS)해서 전달해주는 역할을 합니다. 사용자의 음성을 인식하기 위해서는 ‘오케이 구글’이나 ‘클로바’와 같이 Invoke keyword를 말하거나, 음성 아이콘을 눌러 음성을 입력 받는 경우가 많습니다.
AI스피커나 TV와 같이 Invoke Keyword로 음성인식이 실행되는 경우 Invoke keyword를 인식하는 기능은 디바이스 내에 임베디드로 구현됩니다. 그러다 보니 몇 가지의 특정 키워드로 고정될 수 밖에 없죠.
3.사용자 음성을 텍스트로 전환(Speech-to-Text, STT)
: 사용자가 음성으로 말한 신호를 딥러닝/머신러닝 기술을 통해 순수 텍스트로 변환하는 인공지능 기술이 적용되는 영역입니다. 음성인식 기술은 기술적 난이도가 가장 높은 영역으로 정확한 음성인식을 위한 학습데이터와 정밀한 인식알고리즘에 상당한 투자가 들어가게 됩니다. 음성AI를 한다면 대부분 이 영역이라고 보시면 되겠습니다.
음성인식은 언어, 대상, 영역에 따라 인식률의 편차가 매우 심하기 때문에 특정 영역에 인식이 잘되었다고 하여 다른 영역에도 동일한 결과를 가져올 수 없는 한계가 있습니다. 그래서 별도의 비용을 들여 음성인식 트레이닝을 해야 합니다.
4.전환된 텍스트에서 의도(Intent)/개체(Entity) 추출
: STT를 거쳐 전환된 텍스트 문장에서 딥러닝/머신러닝 기술을 통해 자연어 의도가 인식되는 과정입니다. 챗봇과 동일한 프로세스로 볼 수 있죠.
5.대화흐름(시나리오) 별 분기 및 데이터 추출
: 인식된 의도는 하나의 입력 값이기 때문에 서비스 제공에 필요한 대화 맥락에 따라 바로 답변을 구성하거나, 재질문을 하거나, 조건에 따른 분기를 하는 시나리오 흐름을 타게 됩니다. 이 영역은 대부분의 빌더가 코딩으로 구현되도록 되어 있습니다. 문제는 이러한 코딩이 대화 맥락에 따라 매우 복잡하기 때문에 유지보수에 상당한 어려움이 따를 수 있습니다. 특히 사용자의 다양한 대화 패턴을 코딩으로 구현하는 것은 개발 공수도 많이 들기도 하지만, 수정 및 변경에 필요한 유지보수 비용이 발생하게 됩니다.
6.대화흐름 내 응답문장(Response) 구성
: 사용자의 질문에 대한 답변이 텍스트로 구성됩니다. 예들 들어 ‘내일 날씨가 어떻게 돼?’라는 질문에 대해 ‘내일의 날씨는 25도로서 맑고 화창한 날씨입니다’를 답변 할 때 25도라는 온도 정보와 맑고 화창한 날씨라는 정보를 기상청과 같은 일기예보 시스템을 통해 가져오고 이를 하나의 자연스러운 문장으로 구성하는 것이죠.
음성의 경우 다양한 응답문장 포맷을 구성할 순 없으나, 메신저나 앱과 같이 챗봇 인터페이스에서는 이미지/URL/동영상/텍스트 등 다양한 UI를 구성할 수 있습니다.
7.텍스트를 음성으로 전환(Text-to-Speech, TTS)
: 응답 문장이 구성되어 이를 사람의 목소리로 변환하는 과정입니다. TTS는 이미 ARS나 다양한 디바이스에서 널리 쓰이던 기술이기도 하지만 최근 딥러닝/머신러닝 기술의 발달로 다양한 사용자의 목소리로 재생될 만큼 기술 진보가 많이 된 영역이기도 합니다.
기술의 원리를 간단하게 설명 드렸습니다. 이제 음성봇이 챗봇과 유사하다는 점을 발견하셨나요? 그림에서 보시다시피 음성인식/합성의 과정을 제외하면 의도추출/개체추출부터 응답문장 구성까지 매우 유사한 구조를 가지고 있습니다. 물론 대화흐름이 아닌 단답식의 답변(예를 들어, FAQ처럼 질문-답변 쌍으로 구성된 경우)을 AI가 자동으로 처리해주는 MRC(Machine Reading Comprehension)을 구성할 수도 있긴 합니다. 아무튼 기본적인 구조는 챗봇과 음성봇의 구조가 매우 유사하다는 점을 기억해두실 필요가 있습니다.
챗봇과 음성봇 서비스를 위한 클라우드 플랫폼 ‘빌더(Builder)’의 춘추전국시대
챗봇이 기업의 관심을 받는다고 하여 자연어 의도 이해를 위한 딥러닝/머신러닝 기술과 챗봇시스템을 직접 구축할 순 없을 것입니다. 직접 구축하려면 많은 비용이 들고 챗봇서비스의 품질에 대해 검증도 필요하기 때문이죠. 그러다 보니 이러한 고민을 가진 기업/개인 시장을 대상으로 챗봇 서비스와 음성인식 서비스를 쉽게 구현할 수 있는 서비스형플랫폼인 빌더(Builder)가 등장하게 됩니다.
일반적으로 빌더는 크게 3가지 역할을 합니다.
1.의도이해 – 음성에서 텍스트로 전환되든, 텍스트로 바로 입력되든 자연어이해(NLU) 기능으로 의도(intent)와 개체(Entity)를 추출해줍니다. 물론 대화의도를 정확하게 추출할 수 있도록 학습데이터로 사용자 대화 예문을 등록하거나 중요 개체를 사전에 학습할 수 있게 등록 인터페이스를 제공해줍니다.
2.대화흐름 – 대화흐름은 빌더 내에서 코딩으로 직접 구현하거나, 웹훅(Webhook)으로 외부 서버에 연동하여 던져진 의도에 따라 답변을 받을 수 있게 외부와 통신하는 구조를 제공해줍니다.
아래의 그림은 빌더의 대표격인 Google Dialogflow의 서비스 흐름을 정리한 것입니다. 위 설명과 매우 유사한 구조로 되어 있음을 알 수 있습니다.
그래서 대부분의 빌더는 메뉴 구조가 의도나 개체라는 메뉴가 상단에 위치해있습니다. 그만큼 챗봇 서비스를 제공하는데 있어서 중요하기 때문이죠.
Figure 2. 구글다이얼로그플로우는 지메일계정을 가진 사용자는 누구나 챗봇을 만들 수 있으며,
우측 상단에 보듯이 Google Assistant(Actions on Google)와의 연동이 잘되어 있다.
이러한 챗봇 빌더는 최근에 많이 등장했습니다. 앞서 설명드린 Google Dialogflow, 네이버 CEK(Clova Extension Kit), 카카오i Open Builder, IBM Watson이 대표적인 챗봇 빌더 플랫폼이라 할 수 있습니다. 물론 이런 빌더 플랫폼은 스마트폰이나 AI스피커에 연동될 수 있게 음성봇 서비스도 함께 개발할 수 있다는 특징을 가지고 있습니다. LG CNS도 사내벤처가 만든 단비(danbee.AI)를 시작으로 DAP 플랫폼에 챗봇 및 음성봇을 위한 빌더 플랫폼이 제공되고 있습니다.
Figure 3. LG CNS 사내벤처로 시작하여 18년 8월에 분사한 단비 플랫폼은 자연어인식 기반의 챗봇 빌더 플랫폼으로 개인과 기업이 직접 챗봇 서비스를 구현할 수 있는 서비스 플랫폼이다.
빌더 플랫폼을 구분하는 중요한 요소 중에 하나는 바로 ‘빌더 플랫폼 사업자가 강력한 사용자 채널(사용자 접점이 되는 디바이스나 어플리케이션)을 보유하고 있는가?’ 입니다. 스마트폰 채널을 보유하고 있는 사업자로는 구글(Assistant), 카카오(카카오톡)이 대표적이겠죠. AI스피커 채널을 보유하고 있는 사업자는 대표적으로 네이버(프렌즈)와 구글(홈스피커)을 들 수 있습니다. 사용자가 쉽게 접근할 수 있는 채널은 플랫폼의 효용성도 높일 뿐 더러 채널 인터페이스를 챗봇 플랫폼과 긴밀하게 연동시켜 플러그인 모듈을 제공함으로써 강력한 서비스가 될 수 있기 때문이죠.
Figure 4. 구글어시스턴트가 연동되는 구글 다이얼로그플로우는 음성인식이나 서비스측면에서 강점을 보유하고 있다.
플랫폼의 파편화에 따른 기업의 고민
챗봇과 음성봇을 위한 빌더의 등장은 기업들이 자체 개발 및 구축을 하지 않아도 초기 투자 없이 챗봇 서비스를 빠르게 구현할 수 있는 가치를 제공하고 있습니다. 그렇지만 채널이 다양화되면서 특정 채널에 국한된 챗봇 빌더로 인해 플랫폼의 파편화 문제가 심화되고 있는 것은 기업 측면에서 비용 리스크를 높이는 악영향을 끼치고 있습니다. 그러다 보니 기업시장에서 챗봇 서비스가 활성화되지 못하는 부작용도 발생하고 있습니다.
물론 자체적인 챗봇 빌더를 구현 후 아마존, 구글, MS, 네이버, 카카오와 같은 AI플랫폼사업자의 AI기술(음성인식API 및 음성합성API)을 활용하여 음성봇 서비스를 자체 앱에 구현할 수도 있습니다. 다만 이때는 이전 글에서 설명드린 바와 같이 앱(App)이라고 하는 공간적 특성과 봇(Bot)이라고 하는 시간적 특성에 기인한 UX를 잘 고민해야겠죠.
그래서 다음 편에서는 ‘UX측면에서 바라본 챗봇과 음성봇의 공통점과 차이점’을 주제로 써보겠습니다.
