휴대폰용 음성 사용자 인터페이스를 해보겠노라고 동분서주할 때다. 아직 휴대폰에 터치스크린을 붙인다는 생각은 "대표적인 실패사례"로 꼽히고 있었고, "그게 단가가 얼만지 아느냐"며 이미 십여개 붙어있는 버튼에 하나를 더 추가하는 것도 위아래로 줄줄이 윤허를 받자와야 하던 무렵. 당시 나에게 소원이 하나 있다면 음성인식 전용의 버튼을 하나 넣는 거 였다.


(1) EPD Techniques
음성인식의 적확율을 좌우하는 것 중 가장 큰 것이 음성명령의 맨앞과 맨뒤를 찾아내는 작업, 즉 EPD(End-Point Dectection)이다. 아무리 좋은 음성인식 엔진도 앞뒤로 요상한 음운이 들어가 버리면 엉뚱한 결과를 낼 수밖에 없기 때문이다.

(1-1) Pause Detection
EPD를 기술적으로 해결하는 대표적인 방식은 역시 말이 없는 순간(pause)을 잡아내는 거다. 아무래도 사람은 무슨 말이 "명령"이라고 생각할 때 앞뒤로 pause를 넣게 되니까. 하지만 주변이 시끄럽다든가 하면 이 pause가 인식되지 않을 수도 있고, 무엇보다 굳이 명령을 하지 않더라도 말하다보면 수시로 발생하는 게 pause다. (노홍철씨는 예외적인 경우로 치자 -_- )

(1-2) Magic Word Detection
그래서 나온 것이 소위 magic word 방식. 무식하게 철저하지만 오직 한 단어만을 인식하는 인식기를 한켠에 돌리고 있다가, 그 단어가 인식되면 그 이후 일정기간 동안 입력된 음성을 명령으로 보고 검증하는 것이다. 최근 Microsoft Kinect에서 음성인식을 플랫폼 범위로 적용하면서 "엑스박스"를 매직워드로 설정한 게 이 경우에 해당한다. 음성명령을 내릴 때마다 같은 단어를 말해야 한다는 사실이, 안 그래도 (의외로) 수고스러운 음성인식 작업에 짜증을 가중시키기는 한다.

(1-3) Prompt Sound
조금 더 수동적인 해결안으로는 prompt 방식이 있다. 음성명령을 받아야 할 때마다 "삐ㅡ" 소리를 넣어서 사용자가 발화를 시작해야 하는 시점을 알려주는 것이다. 초기의 음성인식 ARS 시스템(혹은, IVR 시스템)이 이런 방식을 많이 썼다. 사용자 입장에서도 오랫동안 익숙해진 자동응답기와의 대화("삐 소리가 나면 녹음하세요.")와 유사한 멘탈모델을 제공해 주었기 때문에 큰 거부감 없이 받아들였지만, 사실 말하고 싶은 것이 머릿속에 빙빙 도는 데 허가(프롬프트)가 떨어질 때까지 말하지 못하는 것은 나름 상당히 괴로운 일이다. (여기에 사용되는 sound prompt를 어떻게 만드느냐도 이 음성대화 시스템의 사용성에 큰 영향을 미치는데, 이 글은 버튼에 대한 내용이니 일단 넘어가기로 하자.)

(1-4) Others
정확한 EPD를 위해서 시도된 방법들 중에는, 사용자 관점에서 지켜봐야 하는 사람에게는 참 당혹스러운 게 많았다. 심지어 음성명령 직전에 박수를 친다든가, 매직워드를 앞뒤로 넣는다든가 하는 방식도 정확한 인식에 도움은 됐을지 몰라도, 사람을 기술에 끼워 맞추는 전형적인 방법이고 일종의 '고문'에 가까왔다.


(2) "Voice" Button
그런 온갖 기법들을 한편으론 직접 시도해보거나 어깨너머로 보면서, 개인적으로 내린 최적의 EPD 기법은 어이없게도 그냥 누르는 버튼이다. 정확히는 Push-to-talk 버튼. 예전 워키토키처럼, 말하고 싶은 동안 누르고 있다가 말이 끝나면 떼면 되는 방식이다. 앞에서 말한 자동응답기보다 오래된 멘탈모델이고, 큰 회의실에서 발언권을 얻을 때 아직도 사용되고 있으며, 또 실제로 적용해봐도 꽤 자연스러운 방식이다.

그냥 버튼이 눌린 동안만 음성을 받으면 되는 것이니 EPD라고 논할 건 없어 보이는 게 사실이다. 하지만 실제 사용자들의 행동에서는 버튼이 눌리고 음성인식 엔진이 구동되는 그 짧은 순간을 앞질러 말하거나, 마지막 말의 음운이 마무리되기 전에 버튼에서 손을 떼는 경우가 많기 때문에 앞뒤로 약간의 buffer를 주고 여기에 기존의 EPD 기술(1-1)을 적용하는 게 좋다. 이 방식을 주장했을 때 가장 큰 장애물은 그 기술적 난이도가 아니라, 오히려 "그건 내노라할 기술이 아니다"는 거였다. 물론 조직의 목적에 따르자면 어쩔 수 없는 반응이었지만.

이렇게 음성버튼을 채용할 때 가질 수 있는 최대의 장점은, 기존의 GUI나 다른 조작과 병렬적으로 사용할 수 있다는 것이다. 이를테면 일상적인 전화번호부 화면을 띄워놓고 작업하다가, 음성검색이 필요할 때에 별도의 GUI 조작을 하지 않고 바로 버튼을 눌러 음성을 입력할 수 있다.

또한, 버튼을 누르고 "있어야" 한다는 것은 Jef Raskin이 주창한 바 있는 일명 quasimode로, 모드 분리에 따른 사용자의 인식오류 문제를 대부분 해결할 수 있는 장점도 있다.

... 그렇게 Graphical UI와 Voice UI를 자유자재로 오가면서 사용할 수 있는 multi-modal interaction을 입에 달고 지냈던 때가 있었다.


(3) Voice Button FAIL
하지만 앞에서 말한 바와 같이, 버튼 하나 더 우겨넣기 힘든 게 현실이었기 때문에 결국 기존에 있는 버튼을 길게 누르는 것으로 음성인식 "모드"를 넣는 것으로 되었고, 결국 사용성 문제를 발생시키는 대표주자인 이 "모드" 덕택에 음성버튼 컨셉은 안그래도 천덕꾸러기 신세였던 음성UI와 함께 그냥 사그라져 버렸다. 달랑 하나의 모델에만 적용되는가 싶더니 그대로 소리소문없이 사장되어 버렸으니까.


(4) Voice Button on Motorola Droid Pro
모토롤라에서 미국과 유럽에 Droid Pro, 혹은 Motorola Pro라는 모델을 출시한다고 한다. 업무용 휴대폰이면서도 개인용도의 사용을 동시에 고려했다고 하는데, 화면이 크면서도 블랙베리에서 보던 방식의 키보드를 채용했다. ... 아니, 정확히 말하자면 블랙베리 키보드에 버튼을 하나 더 추가했다.

Voice Button on Motorola Pro

저 위치의 마이크 버튼은 분명 이전에 안드로이드 폰들에서 발견된 터치스크린용 가상키보드의 음성인식 아이콘을 따라한 것이다. 그러니 십중팔구 그 기능도 앞에서 상상한 것처럼 아무때나 음성인식을 할 수 있기보다는 그냥 특정한 음성인식 모듈을 띄워주는 형태가 되리라 생각한다. 아무래도 안드로이드 기본 UI와의 충돌도 고려해야 할테고.

혹시 물리적인 QWERTY 키보드가 달린 안드로이드 휴대폰들에는 원래 음성인식 키가 들어가 있었던 건가 싶어서 이전 모델들을 닥치는대로 찾아봤지만, 화면상의 버튼이 아닌 물리적인 음성버튼을 채용한 것은 아마도 이 휴대폰이 최초인 것같다. Voice UI에 관심을 가진 입장에서는 나름 고무적인 사건이 아닐 수 없다! :)


어쨋든 이 버튼을 보자마자, 이제 휴대기기에서의 음성인식 버튼이 이런 식으로 "통화"나 "홈" 버튼만큼 일반화되고, 기기를 사용하는 중에 음성 UI를 사용할 수 있는 순간이 오면 저 마이크 모양에 불이 들어오고, 그럴 때는 버튼을 누른채로 말 한마디해서 쉽게 주소록 검색이나 일정 입력을 할 수 있으면 좋겠다... 뭐 그런 생각이 들어서 반가운 마음에 예전 기억을 주절주절 늘어놔 봤다.


이건 뭐 뒷방노인네도 아니고... 비맞은 중도 아니고... ㅡ_ㅡa;;;
저작자 표시 비영리 변경 금지
신고
Posted by Stan1ey

Voice Search in Korean

2010.06.20 01:46
지지난 주에 다음 커뮤니케이션에서 아이폰용 Daum 앱에 음성검색 기능을 포함시켰다기에 이게 웬일이냐..하고 있는데, 지난 주에는 구글 코리아에서도 모바일 음성검색의 한국어 버전이 안드로이드 앱으로 (아이폰용도 업데이트할 예정) 발표되고, NHN에서도 올해 안에 음성검색 모바일앱을 내놓겠다고 한다.

Daum Voice Search on iPhone AppGoogle Voice Search in Korean on Android App

누가 먼저 시작했는지는 모르겠지만, 이 일련의 음성검색 발표 러쉬에는 업계의 경쟁심리가 작용했을 것이다. 그렇지만 다음도 일찌감치 음성인식 앱을 준비하고 있음을 홍보한 적이 있고, 구글 음성검색이야 진작에 출시되어 있었던 만큼 준비들은 오래전부터 해왔을 테고, 그래선지 음성인식의 적확률에 대해서도 다음의 앱이나 구글의 앱이나 기대 이상이라는 반응이다. 특히 안드로이드 OS는 초창기부터 음성인식을 위한 고려가 포함되어 있을 정도였으니까.

일전에도 구글 음성검색의 두번째 언어가 중국어가 됐다는 소식을 전하면서 한국어는 몇번째로 구현이 될지 궁금해 한 적이 있는데, 결국 예상한 대로 프랑스어가 사용자가 상대적으로 많은 한국어보다 먼저 구현이 되었고, 한국어는 8번째로 구현된 언어라고 한다. 뭐 솔직히 생각보다는 빨리 구현해 줬다. -_-a;;

다음과 구글의 음성검색 기능에서 Voice UI를 비교해 보려고 했지만, 우리나라 앱을 설치할 수 있는 안드로이드 폰을 구할 방법이 없어서 통과. 그리고 나름대로의 방법으로 이미 이 둘을 비교한 기사는 이미 올라와 있다.

Speech Recognition Result 1, Daum Voice SearchSpeech Recognition Result 2, Daum Voice SearchSpeech Recognition Result 2, Daum Voice Search

아이폰용으로 우선 출시된 Daum 앱의 경우, 음성인식 결과는 기본 설정에서는 바로 검색결과를 보여주며, 그와 함께 "음성인식결과 더보기" 기능을 통해서 N-Best 결과를 추가로 볼 수 있게 되어 있다. 보다 일반적인 방식으로 음성인식 결과의 대안들을 먼저 보고나서 그 중에서 인터넷을 검색할 어휘를 선택하려면, "설정" 메뉴에서 "음성인식 결과보기" 옵션을 켜면 위의 오른쪽 그림과 같이 다섯가지 대안결과가 팝업창으로 나타나고 원하는 결과가 없을 경우 바로 재시도할 수 있다.

음성인식의 오인식 확률을 생각하면 보다 전통적인 후자의 방식이 기본으로 제공돼야 한다고 해야 하겠다. 배경잡음이 없는 상태에서의 인식률은 상당한 편일지 몰라도, 인식이 잘 되던 구절을 몇가지 소음환경(화이트 노이즈, 배경음성 등)에서 똑같이 시도했을 때에는 여전히 인식이 거의 되지 않았고, 그런 상황에서 바로 음성입력을 다시 할 수 있도록 해주는 것은 중요한 기능이기 때문이다. 하지만 사실 그러면 또 음성인식의 가장 큰 문제를 부각시키는 모양새가 될테니 어쩔 수 없다고 할까.



이래저래 다루기 쉽지 않은 음성인식 서비스를 출시하려니 고심이 많았다는 건 그렇다고 해도, 역시 Voice UI 관점에선 아쉬운 점이 눈에 띄지 않을 수 없다.

No Network Error in Daum Voice Search
우선 두 회사 모두 모바일 기기에서는 입력된 음성 데이터에서 비교를 위한 특징만을 찾아 보내고 음성인식 기능 자체는 고성능/대용량/실시간 서버에 맡기는, 분산 인식 방식을 채용하고 있다. 일전에 구글의 음성인식을 써봤을 때도, 또 이번 다음 앱의 경우에도 인터넷 연결이 안 될 경우엔 기능 자체가 실행되지 않는다. 비록 사용에 제한이 따르고 경우에 따라 통신요금까지 부과되는 형식이긴 하지만, 음성인식의 성능을 위해서는 어쩔 수 없는 선택이라고 생각한다. 그렇지만 분산인식을 선택한 경우에는 또 그 나름의 장점이 있을 수 있는데, 그걸 제대로 살리고 있는지는 잘 모르겠다.

Input Too Loud Error in Daum Voice Search
Daum 음성검색을 사용해 보다가 발견한 왼쪽 오류창은, 음성입력이 너무 클 경우 서버에 데이터를 보내기 이전에 나오는 장면이다. 이렇게 전처리 과정이 모바일 모듈 안에 있다면, 사실 할 수 있는 일이 좀 더 많을 것이다. 잘못된 음성인식 결과를 단순히 출력하거나 실제로는 별 의미 없는 "검색어를 말할 때 정확히 발음하여 주세요" 같은 안내문을 보여주기 보다, 음성 명령어 구간을 판정하는 EPD 작업 후에 배경소음과 음성명령어를 비교해서 "조용한 곳에서 인식이 더 잘 됩니다"라든가, "주변 사람들의 이야기하지 않을 때 더 잘 됩니다"라든가, "조금 더 큰 소리로 말씀해 주세요" 등의 안내문을 '상황에 맞게' 보여줄 수 있기 때문이다.

실제로 이런 방식을 적용했을 때, 이런 오류가 비록 정확하게 선택될 수는 없더라도 어느 정도 임의로 출력했을 경우 최종 인식률과 사용자의 만족도에는 큰 차이가 있었다. 인간과 같이 말을 알아들으면서도 사실은 스위치만큼이나 멍청해 보이는 장치가 아니라, 음성인식이라는 범주 안에서는 어느 정도 의사소통이 되는 상대방으로 인정받게 되는 것이다. 음성인식이라고 하면 그 인식엔진 안에서 일어나는 UI 디자인과 관련없는 일로서만 여기게 되지만, Voice UI 설계의 관점에서 주변 데이터에도 좀더 관심을 갖고 해당 기능을 사용하는 정황을 좀더 고민했다면 좋지 않았을까 하는 아쉬움이 든다.


또 하나 언급해둘 만한 것은, 음성인식 기능을 여전히 다른 GUI기반 기능과 동떨어진, 그냥 장식적인 feature로만 생각하고 있는 것 같다는 점이다. 음성인식은 제대로 동작할 경우, 키보드 입력을 대체하거나 최소한 보완할 수 있는 도구이다. 위에 링크한 기사들에서도 하나같이 비슷한 이야기들은 하고 있지만, 사실 판에 박힌 음성인식기술의 홍보문구 이상도 이하도 아니다. 그 관점을 실제로 UI 디자인에 적용한다면 어떻게 될까.



이를테면, 위 HTC의 Voice UI에서처럼 키보드와 음성인식을 대등하게 다루고, 키보드 입력을 하려다가 음성인식을 하거나, 음성인식이 실패할 경우 바로 키보드를 통해 보완할 수 있도록 하면 될 것이다. 아이폰이나 안드로이드나 앱에서 OS의 기본 키보드 위에 버튼을 추가할 수 있게 되어 있는데, 이미 좋은 선례가 있음에도 불구하고 이러한 관점을 살리지 못한 부분은 아쉬운 일이다.

... 그나저나 위 동영상에서는 단순히 검색어 몇 음절을 인식하는 수준이 아니라 받아쓰기 dictation 수준의 음성인식 기술을 보여주고 있는데, 이 놀라운(!) 기술수준의 차이에 대해서는 일단 넘어가기로 하자. UFO라도 주웠나보지 뭐.



뭐 어쨋든 간에, 몇차례의 뼈저린 실패에도 불구하고 슬금슬금 다시 고개를 들기 시작한 음성인식 기술이 이번에는 제법 주목을 받고 있다. 이 기회에 제대로 된 Voice UI 디자인에 대한 관심도 좀 생겼으면 좋겠는데, 적어도 결과물만으로 판단하기에는 아직 쉽지 않은 모양. 하지만 언제나 그렇듯이 또 이러다가 눈 깜박하는 순간에 주류가 되어 당연시되거나, 아니면 흔적도 없이 사라져 버리겠지.

외유 중인 인간은 굿이나 보고 떡이나 먹기로 하겠다. 이기는 편 우리 편! =8-P
저작자 표시 비영리 변경 금지
신고
Posted by Stan1ey
이 프로젝트가 드디어 iPhone App으로 출시가 되었다. 무료.



여기에 대해서 뭐라뭐라 글을 쓰기엔, 내가 요새 좀 지쳤다. 아니 굳이 그렇지 않더라도, 십년도 더 된 일이니 이제 와서 키보드를 두드리기가 민망하다고 하는 게 올바른 고백이겠다. :$

Siri VPD Website

그러니 그냥 동영상이나 하나 더 올리고 마무리.



보란듯이 잘 됐으면 좋겠다. 현실적으로 문제가 없지 않겠지만, 그래도 이젠 슬슬 꿈꾼 보람이 있어야 하지 않을까.

나도 한 우물 열심히 파면서 살아야 하는데, 어느새 여기까지 와 버린 건가... ;d
신고
Posted by Stan1ey
1년 전쯤 삼성 휴대폰 인스팅트(Instinct)가 미국에 Sprint 망으로 출시되면서, iPhone(당시 2G)과의 비교광고를 대대적으로 했던 모양이다. 스프린트에서 올린 동영상들을 뒤늦게 발견했는데, 비교광고에 익숙하지 않아서 그런지, 광고의 뉘앙스 ("쟤네는 이거 안 되요~ 메롱메롱") 때문인지, 그다지 잘 만든 광고 캠페인이라는 생각은 안 든다. (사실은 그냥 애플 빠심이 발동 ;ㅁ; )

흥미로운 것은 모두 5편의 동영상 중에 Voice UI가 두 편이나 나온다.

우선 첫번째는 음성명령 기능. 음성으로 전화를 거는 모습을 보여주면서, iPhone은 없지롱..이라고 하고 있다.



삼성 휴대폰에 통화 관련된 음성인식 기능이 들어간 건 꽤 역사가 오래 됐고, 해외에서 출시되는 휴대폰에는 거의 대부분 포함되어 있다. 그래봐야 이제는 매뉴얼에서 반페이지나 차지할까 싶게 무시당하는 기능인데 이때는 또 이렇게 부각시켜서 나서던 때가 있었나보다. 참 감개무량하고 결국 달면 삼키고 쓰면 뱉고.. 그런 게 당연한가 싶기도 하고 그렇다. 여전히 다른 기능으로 확대하기 위한 노력은 무산되고 있는 것 같은데 말이지. 게다가 여기에서 보여주고 있는 음성명령기를 만든 VoiceSignal사(지금은 Nuance에 합병)는 재작년에 이미 아이폰에서 음성명령/검색을 개발하기도 했다.

여기에 자극을 받았는지 어쨌는지, iPhone도 3GS부터는 "Voice Control"이라는 이름으로 음성명령을 지원하고 있다. 통화 뿐 아니라 음악재생과 관련된 기능까지를 포함해서.



VUI와 (조금 억지로) 관련될만한 다른 동영상은 GPS 기능이다. 인스팅트에서는 음성 가이드가 나오는데, 아이폰에서는 나오지 않는다는 걸 부각시키고 있다.



우리나라에서도 같은 사례가 있어서, 모 회사에서 음성 안내를 넣으면서 Voice UI라고 주장하던 시절이 있었다. (과연 이걸 과거형으로 말해도 될지는 자신이 없다.) 마치 그래픽 화면이 들어갔으니 GUI 라는 격이랄까. 뭐 예전의 GUI는 실제로 그렇게 이야기하기도 했으니까 어쩌면 발전의 단계일지도.

iPhone에서의 GPS는 아직도 화면만 지원하고 있는데, 음성지원을 못해서 안 하는 건지 그냥 등떠밀려 개발한 GPS라 제대로 만들 생각이 없는 건지는 모르겠다.



어쨋든 굳이 이런 것도 voice 운운해 가면서 짚어 주었다니 우쭐해지는 마음이 없잖아 있지만, 그 내용을 보면 몇년이 지나도 확장되지 않은 Voice UI의 영역에 한켠이 씁쓸한 것도 사실이다.

점심시간 동안 후딱 적다보니 앞뒤가 없다. 원래 그냥 스크랩이나 해두려고 한 것일 뿐...이라고 애써 생각하기로 하자. ㅡ_ㅡa;;;
신고
Posted by Stan1ey

Emotional AI

2009.08.08 01:55
처음 회사생활을 시작해서 건드렸던 게 MS Agent 2.0 엔진을 이용한 대화형 에이전트를 만드는 거 였다. Visual Basic Script와 JavaScript를 혼합해서 인터넷 익스플로러와 넷스케이프에 연동하고 다른 프로그램에 연동하고 해 가면서, 주어진 과제 - 실제로는 완전하게 동작하지 않는 "사람과 대화하는 컴퓨터"를 그럴 듯 하는 게 구현하는 것 - 를 어떻게든 해보려고 노력했다. 그때는 그렇게 10년동안 연구하면 그 '그럴 듯한' 시스템이 실제로 만들어질 줄 알았지만, 10년이 지난 지금도 그 시스템을 만들려면 비슷한 수준의 인공지능과, 비슷한 수준의 구라를 조합해야 할 게다.

Microsoft Agent: James the Butler
당시 사용했던 MS Agent 모델 James

어쨋든 당시에는 거의 이론적인 수준으로만 존재했던 대화모델을 어떻게든 실재하는 것처럼 만들기 위해서 처음에는 이런저런 대사DB를 고심했지만, 결국 무슨 말을 하면 무슨 응답을 한다는 하나하나의 대응쌍(adjacent pair)이 밝혀지고 나면 전체 대화모델이 얼마나 방대한지와 상관없이 그 시스템은 뻔한 '바보'가 되어 버렸다. 지능의 수준은 그 지식의 정도가 아니라, 입출력의 패턴에 따라서 판정되었던 것이다. 인간이라면 대화 속의 미묘한 맥락이나 상대방 혹은 주변의 눈치를 살피며 그때그때 다르게 응답하겠지만, 당장 컴퓨터는 입력된 그런 입력이 제한되어 있는 것이다.

그래서 장난을 친 것이, 그냥 출력되는 대사를 여러가지 준비해서 그 중 아무거나 임의로 출력하도록 하되, 소극적으로 같은 내용을 다른 말로 바꾼 것뿐만 아니라 아예 다양한 내용으로 말을 만들었다. 이를테면 당시 사용했던 음성인식 엔진은 음성인식에 실패했을 때 그게 소음 때문인지 화자의 발성 때문인지를 확인할 수 없었는데, 오류 메시지는 "잘 안 들리네요. 주위 분들 조금만 조용히 해 주시겠습니까"와 "조금 더 또박또박 말씀해 주세요"를 몇가지 다른 말로 바꾸어 내보낸 것이다.

... 물론 이건 대화모델이나 음성인식을 연구하던 분들에 비하면 말 그대로 장난에 불과했지만, 그에 대한 사람들의 반응은 개인적으로 무척 인상에 남았다. 모두 합쳐봐야 예닐곱개 정도의 메시지를 임의로 뿌린 것 같은데, 사람들은 그걸 들으면서 이전보다 훨씬 더 자연스러운 대화가 가능해졌다고 느끼는 것이다.

한편으로는 그냥 재미있는 기억이기도 했지만, 비슷한 시기에 만들었던 대화형 홈페이지와 맞물려서 '과연 인공지능이라는 게 만들 필요가 있을까? 그냥 그럴싸하게 대꾸하면 사람이 낚여서 인공지능으로 여기는 거 아닐까?' 라는 고민을 하게 만들었던 기억이다.



얼마전 게임 관련 잡지인 <Develop>을 뒤적이다가, 전에 언급한 Project Natal 관련기사에서 재미있는 대목을 찾았다. Milo라는 야심(?) 넘치는(말그대로!) 프로젝트를 소개했던 Lionhead Studio 담당자와의 인터뷰다. 이 인터뷰에서는 뒷부분에 소위 "Emotional AI"라는 개념을 소개하고 있는데, 저 위에 폰카로 찍은 인용구 부분이 간단한 정리라고 하겠다.

Emotional AI: interview from Develop Magazine

다른 게임들과 비교해서 크게 차이가 나는지는 모르겠지만, 인터뷰 내용에 따르면 이제까지 Lionhead에서 만든 게임에 들어간 AI는 조금씩 발전을 거듭해 왔고, 그 결정판이 Milo에 들어갈 예정이라고 한다. 거기에 들어간 AI가 바로 "emotional AI"인데, 그 내용이 위와 같은 것이다.

"Emotional AI isn't real AI - you couldn't write a paper about it. It's how you use weak learning to make people think something is going on there."

관련해서 검색해 보니 이번 뿐만 아니라 몇번이나 언급한 개념인 모양이고, 다른 회사에서도 미들웨어를 개발한다고 나서기도 했다. 대놓고 사용자를 현혹시키기 위한 프로그램을 개발하고, 게다가 이름을 붙여 홍보까지 하다니... 게임 업계란 가끔 UI 쟁이에게 도의적인 갈등을 느끼게 한다. 특히 실제로 AI를 연구한 분들이 본다면 경을 칠 노릇이지만, 사실 인공지능 학계 내부적으로도 "안 되는 분야"라고 인정하고 있는 분위기에서 이런 식으로라도 실용화를 향한 명맥을 유지할 수 있다면 오히려 다행일지도.

그나저나 저 Emotional AI라는 분야, 그냥 뻔한 변수들의 조합에 랜덤함수만 열심히 넣은 게 아니었으면 좋겠는데. 실제로 Milo가 나와준다면 - 비록 내 허접한 영어발음은 못 알아듣더라도 - 얼마나 끝내주겠냐는 말이다.
신고
Posted by Stan1ey
얼마전에 올라온 것 같은 이 MS Office 2010 홍보 동영상을 이제서야 보게 됐다.



비교적 열성과 전문성이 보이는 홈페이지 내용에 비해서, 이 동영상은 마치 고등학생들이 만든 프로젝트 영상 같달까... 어중간한 프로의식에 일단 흉내는 냈지만 도통 공감이 가지 않는 재치있는(?) 내용들이 거슬린다. 게다가 실제로 의미있는 장면이나 대사는 없고, 그냥 헐리웃 영화 예고편에 대해서 순수하게 풍자하고자 만든 영상이라면 오히려 수긍이 가겠다.


... 사실대로 말하자면, 내 입장에서는 내용이 아주 없지도 않았다.

Rest In Peace, Clippy (1997-2004)
Rest In Peace, Clippy (1997-2004)

비록 실패했지만, 개인적으로 대화형 Human Interface Agent를 적용한 Social UI의 의미있는 시도로 기억하고 있는 Clippy가 주인공(?)의 죽어버린 친구로 나온다. 여기에 따라붙는 대사는 "이제는 그만 잊고 보내줘야해!"라는, 무려 '아픈 과거를 가진 캐릭터' 패턴. 아놔. ㅡ"ㅡ

이건 뭐 한두번도 아니고, 뭔가 울궈먹을 일이 있을 때마다 부관참시하고 있으니 좀비가 되어서 살아나고 싶어도 무서워서 그냥 누워있을 듯.

이러다가 나중에 대화모델링이나 음성인식이나 준자연어 분야의 연구가 갑자기 발전해서 다시 에이전트를 하게 되면 면목 없어서 어쩌려고들 이러는지 모르겠다. 진짜 그쪽은 결국 다다르게 되어 있다니깐.
신고
Posted by Stan1ey
MWC 행사 덕택에 짧게라도 생각을 정리할만한 글꺼리가 자꾸 생긴다. 긴 글 때문에 복잡해진 머리를 식힐 겸 또 정리해 보자.


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.) 사이에도 구분이 들어가게 되는데, 거기서 거기처럼 보이는 이 둘 사이의 차이점을 안다는 것은 더 많은 범위의 음성 입출력을 고려할 수 있게 해준다.


Microsoft Recite - Instruction

이번에 MWC에 나온 Microsoft Recite도 그런 사례로 삼게 되지 않을까 싶다. 우선 데모 동영상을 보면 (앞의 것이 설명은 잘 되어 있고, 실제 상황은 뒤의 동영상이다.) 다음과 같은데, 간단히 설명하자면 왼쪽 버튼을 눌러서 음성메모를 녹음하고, 오른쪽 버튼을 눌러서 그 메모를 음성으로 검색하는 것이다.





공식 웹사이트를 가보면 어느 정도 설명이 있지만, 결국 이건 일반적으로 말하는 음성인식(음성에서 특징점을 찾아서, 인식대상 문자열을 발화할 때의 일반적인 특징점과 비교함으로써, 가장 잘 맞는 문자열을 찾아내는 것)에서 '문자'에 대한 부분을 들어낸 기능이다. 결국 녹음된 음성의 특징점과 입력된 음성의 특징점만을 비교해서, 그 음성이 무슨 내용(문자열)인지와 상관없이 그냥 잘 맞는 내용을 제시하는 거랄까.

이런 방식은 이미 대량의 음성정보(라디오 뉴스 등)의 archive에서 특정 내용을 검색해 내려는 프로젝트에서도 사용되기도 했었으니(미국 워싱톤 근처 어디랑 관련이 있었는데 검색어가 떠오르질 않는다 -_ㅜ 그냥 치매일 뿐) 완전히 새로운 개념은 아니다. 문자열에 따른 특징점을 일반화/DB화 과정이 없으니 같은 사람이 같은 어조로 같은 단어를 말했을 경우에는 적확률이 꽤 높다는 장점이나, 같은 단어라고 해도 다른 사람이 말한 내용은 검색이 잘 안 된다는 단점은 이미 잘 알려져 있기도 하다.

그런데 위 동영상을 보면, 음성과 음성의 특장점을 그냥 일대일로 맞춘 것이 아니라, 검색 음성명령의 특정한 부분 - "What is...?" 라든가 - 은 잘라내고 나머지 부분만으로 matching을 수행하고 있는 걸 볼 수 있다. 이전까지의 voice matching/search가 단순히 특징점 비교였고, 구글의 음성검색이 음성을 문자로 바꿔서 검색하는 거 였다면, 이건 그 중간쯤의 안전한 지역을 선택했다고나 할까. 검색어를 골라내는 것은 음성인식(Speech-to-Text)의 기술을 이용하고, 정작 검색은 적확률이 높은 voice matching을 사용하고 있다.

이 Microsoft Recite는 Voice UI를 디자인할 때 무엇을 고민해야 하고, 어떻게 해결해야 하는지를 보여준 또 하나의 사례라고 생각한다. 비록 휴대기기 안에서만 사용할 수 있다거나 음성메모의 활용성이라든가 하는 단기적인 취약점이 보이긴 하지만, 상정한 범위 안에서 강력한 힘을 발휘하는 게 오히려 HTI의 나아갈 길이라는 점에서는 꽤 의미가 있어 보인다.
신고
Posted by Stan1ey

며칠 전에 iPhone에서 구동되는 무료 HTI 어플들을 정리했는데, 한메일에 들어갔다가 한 블로거가 음성인식 어플을 소개해 놓은 동영상을 퍼다놓은 걸 보게됐다. 역시 놓친 게 있었던 듯. ㅎㅎ 이미 김은 새버렸으니 굳이 주절주절 적을 기운은 없고, 유투브에 들어가 보니 이 회사(AppStore에는 Excuse Me Services라고 되어 있고, 프로그램 첫 화면에는 Dial Directions 라고 되어 있다. 어느 쪽이냐 -_-; )에서 올린 동영상이 몇개나 있다. 현재는 Say Who라는 음성 다이얼링 서비스만 AppStore에 올라와 있는데, Say Where도 곧 올라올 듯. 유투브 동영상들 중 각각의 어플에 대한 동영상 설명은 다음과 같다.

Say Who (주소록 음성 검색 및 "번호인식")



Say Where (구글 맵 주소 검색)


음성인식의 데모 동영상은 늘 왠지 사람을 시니컬하게 만드는 것 같다 -_-;;;

전에 소개했던 Cactus Voice Dialer에 비해서 좋은 점이라면 역시 Say Who에서 음성으로 숫자인식이 된다는 거겠다. 숫자란 게 대부분 짧고, 그러다보니 상대적으로 비슷비슷한 발성들이 있을 수 있다. (우리말의 경우엔 "일"과 "이"와 "오", "삼"과 "사" 등이 그렇다) 따라서 인식오류도 많을 수 밖에 없고, 게다가 입에 익지 않은 숫자열을 기억해내며 발화하는 게 얼마나 어려운 일인지 생각해보면, 키패드와 비교해서 장점이 거의 없다고도 할 수 있겠다. 그럼에도 누구나 생각하는 기능인지라 휴대폰에 음성인식을 탑재하면서 늘상 고민이 많이 됐고, 몇가지 다른 방식이 비교되기도 한다. ... 이거 오래 이야기하자면 끝이 없다. -_ㅜ

어쨋든 그래서 한번 해봤다.

Say Who by Dial Directions, Splash ScreenSay Who by Dial Directions, Press While SpeakingSay Who by Dial Directions, Network Error???

... 어이. -_-;;; 왜 '네트워크' 에러인 거냐고. Say Where라면야 구글 맵과 연동해야 하니까 그렇다고 해도, Say Who는 로컬에서 돌리는 게 아니었나? -_- 아니었나보다. 이 소프트웨어는 아마도 한때 꽤나 회자되던 distributed speech recognition 모델을 사용하는 것 같다. iPhone에 설치된 소프트웨어는 (어째 용량이 작다 했건만) 음성에서 특징(feature vector)만 잡아서 작은 양의 디지털 정보로 바꿔 서버로 전송하고, 그 전처리된 정보를 방대한 DB - 이를테면, 미국내의 도시 이름 목록 - 와 비교해서 적합한 목록을 뽑아내는 건 빵빵한 성능을 가진 서버가 하는 거다.

흠... 우선은 Say Who에서도 그러고 있는 거라면 내 개인 주소록 정보가 서버로 흘러가고 있는 건 아닌지 우려가 되고, Say Where만 생각하더라도 이 어플이 무료로 풀릴 경우 (Say Who는 무료 어플이다) 그 막대한 서버부하를 감당할 수 있을런지가 의심스러운 대목이다. 게다가 비록 지금은 1년동안 네트워크를 무료로 사용하는 약정이 되어 있지만 (영국 신규사용자의 경우), 그 이후엔 그 네트워크 비용 때문에 자주 쓰지 않게 되지 않을까... 싶기도 하고.

iPhone Apps - Say Who
뭐 그럼에도 불구하고... iPhone 어플 중에 음성인식을 지원하는 또 다른 어플이 있다는 것, 게다가 그게 숫자인식을 지향하고 있고, (어쩌면) 다른 인식모델을 지원해서 장단점을 비교할 수 있는 환경이 되었다는 건 꽤 흥미로운 일이다. Cactus에 비해서 옵션이 적다는 건 단점이 되겠지만, 그만큼 그냥 단순히 사용할 수 있도록 만든 어플이라는 의미도 되니까. 부가적이지만 말하기 버튼을 눌렀을 때 화면 전체가 뻘개진다는 것도 마음에 든다. Cactus에서는 손가락에 눌려 가려진 버튼이 눌렸는지 어쨌든지를 확인하기가 어려웠거든.

iPhone VUI Apps - Say Who & Cactus (as of 19 Oct 2008)



자... 하지만 내가 기대하는 건, 만일 모바일 음성인식 시장이 진짜라면 당연히 그 시장을 잡아먹으려고 덤빌 주요 회사들의 등장이다. (이미 VoiceSignal은 어플이 완성되어 있는 걸 알고 있는데 -_-+ ) 그 회사들이 AppStore에 떠서 실질적인 시장 형성이 시작돼야 VUI가 유용한지 어떤지에 대해서 엄정한 판정을 받을 수 있을 것 같으니까 말이지. 어쩌면 모바일 음성인식의 final round가 될지도 모르지만, 어쨋든 아직은 음성과 대화의 힘을 믿는 마음으로 기다리는 중이다.



이 글을 쓰고나서 하루이틀 후에, Say Who가 업데이트되었다. 글 다 썼는데 고쳐야 하나... 하면서 보니 non-alphabetical character 때문에 문제가 생겼다고 그걸 고쳐서 업데이트했다고 하는데, 조금 다른 오류메시지도 종종 나오지만 전반적인 오류현상은 똑같다. 이뭥미. 오히려 같은 조건(=똑같이 영어 못하는 주인)에서 테스트했을 때는 현재는 Cactus가 훨씬 낫다. 인식률 20% 정도로. ㅡ_ㅡa;;;;


좀 더 테스트해본 후에 말 바꾸기:
정정. 안정적인 WiFi가 연결된 상태에서 테스트해보니, Say Who의 인식률은 대략 80% 정도? (앞의 테스트는 출퇴근 길에 한 거라서, 3G 네트워크의 문제일 수도 있다.) 종종 'network timeout' 오류는 났지만 인식되기만 하면 꽤 정확하게 응답하고 있었다. 혹시나 해서 iPhone을 비행기 탑승 모드(모든 네트워크 차단)로 바꾸고 테스트해보니 음성명령이 끝나기가 무섭게 바로 'network problem'을 보고한다. (아래 첫번째 화면) 확실히 분산형 인식을 쓰는 건 맞는 것 같은데, 그렇다면 어느 정도의 개인정보는 항상 서버로 흘러가고 있다는 거다. 어쩌면 Apple에서 '원격삭제' 기능을 발동할지도 모르겠는 걸...

Say Who - with Possible Privacy Violence?Say Who - with Possible Privacy Violence?Say Who - with Possible Privacy Violence?

그렇게 가까스로 본 결과화면(두번째 화면)은 조금 더 아이폰 UI 스럽게 되어 있는 점은 마음에 들지만, 인식이 된 경우에도 휴대폰 정보가 없으면 마치 오류 메시지같은 팝업 창이 뜨는 점(세번째 화면)은 확실히 초보적인 실수처럼 보인다.

어쨋든 인식률에 대해서는 분명히 정정해야 하겠지만, 그건 역시 서버의 도움을 받을 수 있는 분산형 인식의 장점으로 봐야 할 거다. 순수하게 UI 관점에서 보면 사실은 둘 다 엉망이지만 -_-a;; VUI 관점에서 인식기술의 장단점을 좀더 잘 반영한 것은 역시 Cactus Voice Dialer의 손을 들어주고 싶다.

(장점)
- 인식결과 옵션이 충분하다. (인식대안 표시, 대표번호, 바로 걸기)
- 말하기 버튼이 모든 화면에 있어 오류 시 바로 다시 재시도할 수 있다.
- (UI 이슈는 아니지만) Embedded 인식엔진이므로 개인정보가 안전하다.

(단점)
- 버튼이 작고 손가락에 가려 눌렸다는 피드백이 잘 보이지 않는다.
- 인식률이 (많이 -_- ) 떨어진다.
- UI의 시각적 완성도가 (심히 -_- ) 떨어진다.
- (UI 이슈는 아니지만) 숫자음 인식이 제공되지 않는다.

이상 아무도 원한 적 없는 장단점 정리. ㅡ_ㅡa;;;

결론이 오락가락한다고 뭐라기 없기. 개인 블로그니까 주인장 맘바뀌면 내용 바뀌는 건 지극히 정상이라고나 할까... ㅋㅋ
신고
Posted by Stan1ey

BLOG main image
by Stan1ey

카테고리

분류 전체보기 (347)
HTI in General (45)
User eXperience (11)
Voice UI (50)
Vision UI (14)
Gesture UI (25)
Tangible UI (28)
Robot UI (14)
Public UI (9)
Virtuality & Fun (56)
Visual Language (15)
sCRAP (70)

글 보관함



www.flickr.com
This is a Flickr badge showing public photos and videos from Stan1ey. Make your own badge here.