이번 글에서는 AI 스피커로 시작되어 업계에 큰 관심을 받는 음성인식 기술 기반의 음성봇(Voicebot) 구조를 챗봇 구조와 연계해 설명해 드리겠습니다. 

음성봇과 챗봇은 닮은 점이 많다?

앞서 챗봇의 구조는 대화 의도(Intent)를 추출하는 것과 의도 속에 담긴 중요한 개체(Entity)를 추출하는 과정이 중요하다고 말씀드렸습니다. 챗봇에서 AI 기술은 사용자의 수많은 대화 방식 속에서 사용자 의도와 개체를 정확하고 빠르게 추출하는 데 활용이 되는 것이죠. 물론 추출된 의도와 개체로 주문이나 예약, 고객 서비스와 같이 서비스를 제공하기 위해 대화 흐름을 코딩이나 별도 운영 툴(Tool)을 이용해서 구현해야 합니다.

그렇다면 음성봇은 어떤 구조로 되어 있을까요? 음성봇의 구조를 정리하면 다음과 같습니다.

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)가 등장하게 됩니다.

일반적으로 빌더는 아래와 같은 역할을 합니다.

1. 의도 이해 

음성에서 텍스트로 전환되든, 텍스트로 바로 입력되든 자연어 이해(NLU) 기능으로 의도(intent)와 개체(Entity)를 추출해줍니다. 물론 대화 의도를 정확하게 추출할 수 있도록 학습 데이터로 사용자 대화 예문을 등록하거나 중요 개체를 사전에 학습할 수 있게 등록 인터페이스를 제공해줍니다.

2. 대화 흐름 

대화 흐름은 빌더 내에서 코딩으로 직접 구현하거나, 웹훅(Webhook)으로 외부 서버에 연동하여 던져진 의도에 따라 답변을 받을 수 있게 외부와 통신하는 구조를 제공해줍니다.

아래의 그림은 빌더의 대표 격인 구글 다이얼로그플로우(Google Dialogflow)의 서비스 흐름을 정리한 것입니다. 위 설명과 매우 유사한 구조로 되어 있음을 알 수 있습니다.

그래서 대부분의 빌더는 메뉴 구조가 의도나 개체라는 메뉴가 상단에 위치해 있습니다. 그만큼 챗봇 서비스를 제공하는 데 있어서 중요하기 때문이죠.

이러한 챗봇 빌더는 최근에 많이 등장했습니다. 앞서 설명해 드린 구글 다이얼로그플로우, 네이버 CEK(Clova Extension Kit), 카카오i Open Builder, IBM Watson이 대표적인 챗봇 빌더 플랫폼이라 할 수 있습니다. 물론 이런 빌더 플랫폼은 스마트폰이나 AI 스피커에 연동될 수 있게 음성봇 서비스도 함께 개발할 수 있는 특징을 가지고 있습니다. LG CNS도 사내벤처가 만든 단비(danbee.AI)를 시작으로 DAP 플랫폼에 챗봇 및 음성봇을 위한 빌더 플랫폼이 제공되고 있습니다.

빌더 플랫폼을 구분하는 중요한 요소 중 하나는 바로 ‘빌더 플랫폼 사업자가 강력한 사용자 채널(사용자 접점이 되는 디바이스나 어플리케이션)을 보유하고 있는가?’입니다. 스마트폰 채널을 보유하고 있는 사업자로는 구글(Assistant), 카카오(카카오톡)가 대표적이겠죠.

AI 스피커 채널을 보유하고 있는 사업자는 대표적으로 네이버(프렌즈)와 구글(홈 스피커)을 들 수 있습니다. 사용자가 쉽게 접근할 수 있는 채널은 플랫폼의 효용성도 높일뿐더러 채널 인터페이스를 챗봇 플랫폼과 긴밀하게 연동시켜 플러그인 모듈을 제공함으로써 강력한 서비스가 될 수 있기 때문이죠. 

플랫폼의 파편화에 따른 기업의 고민

챗봇과 음성봇을 위한 빌더의 등장은 기업들이 자체 개발 및 구축을 하지 않아도 초기 투자 없이 챗봇 서비스를 빠르게 구현할 수 있는 가치를 제공하고 있습니다. 그렇지만 채널이 다양화되면서 특정 채널에 국한된 챗봇 빌더로 인해 플랫폼의 파편화 문제가 심화되고 있는 것은 기업 측면에서 비용 리스크를 높이는 악영향을 끼치고 있습니다. 그러다 보니 기업 시장에서 챗봇 서비스가 활성화되지 못하는 부작용도 발생하고 있습니다.

물론 자체적인 챗봇 빌더를 구현 후 아마존, 구글, MS, 네이버, 카카오와 같은 AI 플랫폼 사업자의 AI 기술(음성인식 API 및 음성합성 API)을 활용하여 음성봇 서비스를 자체 앱에 구현할 수도 있습니다. 다만 이때는 이전 글에서 설명해 드린 바와 같이 앱(App)이라고 하는 공간적 특성과 봇(Bot)이라고 하는 시간적 특성에 기인한 UX를 잘 고민해야겠죠.

그래서 다음 편에서는 ‘UX 측면에서 바라본 챗봇과 음성봇의 공통점과 차이점’을 주제로 써보겠습니다.

글 l LG CNS 미래신사업담당

[‘부상하는 비즈니스 마케팅 채널! 챗봇(Chatbot)’ 연재 현황]

[1편] 모바일 메신저 ‘챗봇(Chatbot)’이란 무엇일까?
[2편] 챗봇을 활용한 서비스 사례
[3편] 챗봇으로 만든 대화형 커머스 ‘톡 주문’
[4편] 서비스 운영 경험으로 본 챗봇
[5편] 문답으로 알아보는 챗봇
[6편] 챗봇. 어떤 로직을 구현할 것인가?
[7편] 지능형 챗봇, 기업 현장에 어떻게 도입할 것인가?
[8편] 4차 산업혁명에서 지능형 챗봇의 역할
[9편] 왜 지능형 챗봇인가? 왜 지금인가?
[10편] 운영자 관점에서 바라본 챗봇의 현재 모습
[11편] 기업을 위한 챗봇 빌더, DanBeeAi
[12편] 챗봇은 산업을 뒤흔들었을까?
[13편] 챗봇을 넘어 음성봇으로