MWC 행사 덕택에 짧게라도 생각을 정리할만한 글꺼리가 자꾸 생긴다. 긴 글 때문에 복잡해진 머리를 식힐 겸 또 정리해 보자.
Voice UI 디자인에 대해서 고민하면서, 내 멋대로 다음과 같은 표를 그려본 적이 있다. (이게 정확히 맞는지 모르겠지만, 뭐 기억하기엔 이렇다.) 지금도 크게 다르지 않지만, Voice UI와 관련된 다른 비슷한 개념들 간에 영역을 좀 정해보자는 의도였다.
위 표를 들고 다니면서 자주 언급했던 부분은 '언어 language'만을 대상으로 하는 Speech UI와 '준언어 paralanguage'까지도 대상으로 하는 Voice UI를 구분함으로써 VUI에서 고려해 할 점은 이런저런 것까지를 포함한다... 뭐 그런 거 였다. 물론 준언어에 몸짓이 포함되고, Non-Verbal Audio(NVA)도 물론 대상으로 들어가고 어쩌고 하는 문제가 많은 영역구분이지만, 그래도 '왜 내가 이걸 다른 용어가 아닌 VUI라고 부르나'를 설명하는 데에는 나름 유용했다.
이 구분을 만들고 나면 자연스럽게 음성인식(voice recog.)과 발화인식(speech recog.) 사이에도 구분이 들어가게 되는데, 거기서 거기처럼 보이는 이 둘 사이의 차이점을 안다는 것은 더 많은 범위의 음성 입출력을 고려할 수 있게 해준다.
이번에 MWC에 나온 Microsoft Recite도 그런 사례로 삼게 되지 않을까 싶다. 우선 데모 동영상을 보면 (앞의 것이 설명은 잘 되어 있고, 실제 상황은 뒤의 동영상이다.) 다음과 같은데, 간단히 설명하자면 왼쪽 버튼을 눌러서 음성메모를 녹음하고, 오른쪽 버튼을 눌러서 그 메모를 음성으로 검색하는 것이다.
공식 웹사이트를 가보면 어느 정도 설명이 있지만, 결국 이건 일반적으로 말하는 음성인식(음성에서 특징점을 찾아서, 인식대상 문자열을 발화할 때의 일반적인 특징점과 비교함으로써, 가장 잘 맞는 문자열을 찾아내는 것)에서 '문자'에 대한 부분을 들어낸 기능이다. 결국 녹음된 음성의 특징점과 입력된 음성의 특징점만을 비교해서, 그 음성이 무슨 내용(문자열)인지와 상관없이 그냥 잘 맞는 내용을 제시하는 거랄까.
이런 방식은 이미 대량의 음성정보(라디오 뉴스 등)의 archive에서 특정 내용을 검색해 내려는 프로젝트에서도 사용되기도 했었으니(미국 워싱톤 근처 어디랑 관련이 있었는데 검색어가 떠오르질 않는다 -_ㅜ 그냥 치매일 뿐) 완전히 새로운 개념은 아니다. 문자열에 따른 특징점을 일반화/DB화 과정이 없으니 같은 사람이 같은 어조로 같은 단어를 말했을 경우에는 적확률이 꽤 높다는 장점이나, 같은 단어라고 해도 다른 사람이 말한 내용은 검색이 잘 안 된다는 단점은 이미 잘 알려져 있기도 하다.
그런데 위 동영상을 보면, 음성과 음성의 특장점을 그냥 일대일로 맞춘 것이 아니라, 검색 음성명령의 특정한 부분 - "What is...?" 라든가 - 은 잘라내고 나머지 부분만으로 matching을 수행하고 있는 걸 볼 수 있다. 이전까지의 voice matching/search가 단순히 특징점 비교였고, 구글의 음성검색이 음성을 문자로 바꿔서 검색하는 거 였다면, 이건 그 중간쯤의 안전한 지역을 선택했다고나 할까. 검색어를 골라내는 것은 음성인식(Speech-to-Text)의 기술을 이용하고, 정작 검색은 적확률이 높은 voice matching을 사용하고 있다.
이 Microsoft Recite는 Voice UI를 디자인할 때 무엇을 고민해야 하고, 어떻게 해결해야 하는지를 보여준 또 하나의 사례라고 생각한다. 비록 휴대기기 안에서만 사용할 수 있다거나 음성메모의 활용성이라든가 하는 단기적인 취약점이 보이긴 하지만, 상정한 범위 안에서 강력한 힘을 발휘하는 게 오히려 HTI의 나아갈 길이라는 점에서는 꽤 의미가 있어 보인다.
Voice UI 디자인에 대해서 고민하면서, 내 멋대로 다음과 같은 표를 그려본 적이 있다. (이게 정확히 맞는지 모르겠지만, 뭐 기억하기엔 이렇다.) 지금도 크게 다르지 않지만, Voice UI와 관련된 다른 비슷한 개념들 간에 영역을 좀 정해보자는 의도였다.
| Scope | Auditory UI | ||
|---|---|---|---|
| Speech UI | Sound UI | ||
| Voice UI | |||
| Target | Language | Paralanguage | Audio |
| Verbal | Non-verbal | ||
(아놔. 오랫동안 HTML에서 손을 뗐더니 표 하나 그리는데 이게 왠 뻘짓이냐. ㄷㄷ)
위 표를 들고 다니면서 자주 언급했던 부분은 '언어 language'만을 대상으로 하는 Speech UI와 '준언어 paralanguage'까지도 대상으로 하는 Voice UI를 구분함으로써 VUI에서 고려해 할 점은 이런저런 것까지를 포함한다... 뭐 그런 거 였다. 물론 준언어에 몸짓이 포함되고, Non-Verbal Audio(NVA)도 물론 대상으로 들어가고 어쩌고 하는 문제가 많은 영역구분이지만, 그래도 '왜 내가 이걸 다른 용어가 아닌 VUI라고 부르나'를 설명하는 데에는 나름 유용했다.
이 구분을 만들고 나면 자연스럽게 음성인식(voice recog.)과 발화인식(speech recog.) 사이에도 구분이 들어가게 되는데, 거기서 거기처럼 보이는 이 둘 사이의 차이점을 안다는 것은 더 많은 범위의 음성 입출력을 고려할 수 있게 해준다.
이번에 MWC에 나온 Microsoft Recite도 그런 사례로 삼게 되지 않을까 싶다. 우선 데모 동영상을 보면 (앞의 것이 설명은 잘 되어 있고, 실제 상황은 뒤의 동영상이다.) 다음과 같은데, 간단히 설명하자면 왼쪽 버튼을 눌러서 음성메모를 녹음하고, 오른쪽 버튼을 눌러서 그 메모를 음성으로 검색하는 것이다.
공식 웹사이트를 가보면 어느 정도 설명이 있지만, 결국 이건 일반적으로 말하는 음성인식(음성에서 특징점을 찾아서, 인식대상 문자열을 발화할 때의 일반적인 특징점과 비교함으로써, 가장 잘 맞는 문자열을 찾아내는 것)에서 '문자'에 대한 부분을 들어낸 기능이다. 결국 녹음된 음성의 특징점과 입력된 음성의 특징점만을 비교해서, 그 음성이 무슨 내용(문자열)인지와 상관없이 그냥 잘 맞는 내용을 제시하는 거랄까.
이런 방식은 이미 대량의 음성정보(라디오 뉴스 등)의 archive에서 특정 내용을 검색해 내려는 프로젝트에서도 사용되기도 했었으니(미국 워싱톤 근처 어디랑 관련이 있었는데 검색어가 떠오르질 않는다 -_ㅜ 그냥 치매일 뿐) 완전히 새로운 개념은 아니다. 문자열에 따른 특징점을 일반화/DB화 과정이 없으니 같은 사람이 같은 어조로 같은 단어를 말했을 경우에는 적확률이 꽤 높다는 장점이나, 같은 단어라고 해도 다른 사람이 말한 내용은 검색이 잘 안 된다는 단점은 이미 잘 알려져 있기도 하다.
그런데 위 동영상을 보면, 음성과 음성의 특장점을 그냥 일대일로 맞춘 것이 아니라, 검색 음성명령의 특정한 부분 - "What is...?" 라든가 - 은 잘라내고 나머지 부분만으로 matching을 수행하고 있는 걸 볼 수 있다. 이전까지의 voice matching/search가 단순히 특징점 비교였고, 구글의 음성검색이 음성을 문자로 바꿔서 검색하는 거 였다면, 이건 그 중간쯤의 안전한 지역을 선택했다고나 할까. 검색어를 골라내는 것은 음성인식(Speech-to-Text)의 기술을 이용하고, 정작 검색은 적확률이 높은 voice matching을 사용하고 있다.
이 Microsoft Recite는 Voice UI를 디자인할 때 무엇을 고민해야 하고, 어떻게 해결해야 하는지를 보여준 또 하나의 사례라고 생각한다. 비록 휴대기기 안에서만 사용할 수 있다거나 음성메모의 활용성이라든가 하는 단기적인 취약점이 보이긴 하지만, 상정한 범위 안에서 강력한 힘을 발휘하는 게 오히려 HTI의 나아갈 길이라는 점에서는 꽤 의미가 있어 보인다.
반응형
