iPhone 5 Wishlist

2011.10.04 06:13
애플의 "Let's talk iPhone" 행사가 코앞으로 다가왔다. 매번 새로운 OS 버전이 발표될 때마다 내심 혁신에 대한 기대를 하게 하는 아이폰이지만, 이제 모바일 상황에서 쓸 수 있는 센서들은 대충 (2개 빼고) 다 들어갔고 MobileMe에서 환골탈태한 iCloud 서비스의 새로운 윤곽도 많이 알려진 터라 뭐 또 새로운 게 나올까 싶긴 하다. 요컨대 출시하기 전부터 새로운 기능들이 식상해지고 있는 희한한 형국인데, 주요 업데이트인 만큼 큰 변화들이 많아 그 와중에 별로 주목을 받지 못하고 있는 소소하지만(?) 재미있는 기능들이 많다.

실제 발표가 되기 직전이니만큼 조금 무모한 포스팅이지만, 그래도 그런 기능들에 개인적인 소망-_-을 담아보자면 이렇다.


Magic Home Button

iPhone 5 CAD Drawing - Wider Home Button
아이폰의 홈버튼이 커지고, 제스처 기능이 들어간다는 건 이제 기정사실화 되어있는 것같다. 이 이야기는 소문만 있는 게 아니라 이미 아이폰 케이스를 만드는 업체를 통해서 도면까지 나왔는데, 결국 어떤 동작이 사용되느냐에 대해서는 어째 그다지 구체적인 소리가 없다. 동작이라는 힌트를 바탕으로 멋대로 추측성 "소설"을 써보자면 (요새 이게 유행이라면서 -_- ), 아마도 애플은 이미 Mighty Mouse와 Magic Mouse에서 보여줬던 물리 버튼과 터치센서의 조합을 보여주지 않을까 싶다.

Touch Sensor Layout inside Apple's Mighty Mouse

처음 나왔던 "마이티마우스"는 멀티터치 동작을 지원하는 매직마우스와 달리 (저렴하고) 단순한 기술의 조합이었는데, 하나의 플라스틱 표면에서 어느 부위에 손가락이 닿아있는냐에 따라 왼쪽 클릭과 오른쪽 클릭을 구분하고, 몸통 전체가 통채로 버튼 역할을 함으로써 물리적인 입력을 가능하게 했다. (왼쪽 그림을 보면 좌우로 한쌍의 터치센서가 펼쳐져 있음을 볼 수 있다.)

그리고 유출된 아이폰5의 넓다란 홈버튼에도, 딱 손가락 3개 폭만큼의 터치센서를 올릴 수 있어 보인다. 3개의 영역만 구분되면 좌우로 쓸기(swipe) 동작은 인식할 수 있을테고, 그렇다면 이런 식의 활용이 가능하지 않을까? 내멋대로 이름하여 유치찬란한 "매직홈버튼"이다. ㅎㅎ


Magic Home Button for iPhone 5
요컨대 기본적으로 홈버튼 위의 세 영역 중 한 곳에 손가락을 얹고 누르면, 그 위치에 따라 다른 동작을 하는 조작이 가능할 것이다. 여기에 추가로 버튼을 누르기 전이나 후에는 좌우쓸기 동작을 이용해서 몇가지 변용을 추가할 수 있겠다.

  • 홈버튼을 눌러서 화면을 켜고 홈스크린이 나오면, 홈버튼 자체에서 "slide to unlock" 동작을 할 수 있다.
  • 멀티태스킹을 지원하는 상황에서 버튼에 손을 올리면, 오래전부터 소문만 많았던 Mac OS의 Expose 같은 화면을 보여주다가 좌우쓸기로 불러올 기능을 선택할 수 있다.
  • Springboard나 웹브라우저 등 여러 페이지를 앞뒤로 넘길 수 있는 상황에서는, 이 좌우쓸기 동작이 페이지 넘김과 연동될 것이다.
  • 홈버튼을 클릭해서 자주 쓰는 기능을 구동하는 기능은, 버튼의 어느 영역에 손가락을 올리고 눌렀느냐에 따라 다르게 수행될 수 있다. 한번 눌러 홈스크린을 띄우거나 첫페이지/검색페이지로 가는 기능은 어떨지 몰라도, 두번 혹은 세번 누르는 기능은 이로 인해서 몇 배로 다양한 기능을 할 수 있게 된다.
... 아님 말고.


Voice UI
Voice UI Setting for iOS5, partnered with Nuance
iOS5에서 음성 UI를 본격적으로 지원한다는 것 또한 사실상 확정된 것같다. 애플은 이미 MacOS와 iOS에 구현된 VoiceOver 기능을 통해서 검증된, 쓸만한 음성합성 엔진을 갖고 있다. 하지만 음성인식 분야에서는 그닥 눈에 띄는 활동이 없었는데, 지난 몇달간 그 분야의 일인자라고 할 수 있는 Nuance사와 온갖 소문이 다 났다. Apple와 Nuance는 이전에도 협력관계에 있기는 했지만, 한때는 애플이 아예 뉘앙스를 사버린다는 소문도 있다가, 결국은 그냥 어느 정도 선에서 합의한 모양이다. (사실 애플이 실제로 뉘앙스를 가져가 버렸다면, 뉘앙스 외에는 구글의 Android를 쓰는 것 말고 딱히 음성인식 대안이 없는 휴대폰 제조사들로선 청천벽력같은 상황이 될 수도 있었다. -- 뭐 VUI에 대해서 신경이나 쓴다면 말이지만.)

어쨋든 저 앞의 설정화면에 드러난 대로라면, 관련된 옵션이 새로 최소한 3개는 들어가는 것 같다. 우선 가장 흥미있는 것은, Android에서 구현되어 몇번 언급했던 가상 키보드의 "음성 버튼"이다. "Mic on space key"라고 묘사된 저 기능은 왠지 스페이스(공백) 키 자체에 마이크를 표시하고 이를 길게 누르거나, 심지어 누르고 있는 동안(push-to-talk; PTT) 음성인식을 할 수 있도록 할 것같다.

출시할 때 이름이 바뀌긴 할테지만, 그 외에 "Nuance Dictation"이나 "Nuance Long Endpoint Detection"이라는 옵션들은 감히 "받아쓰기(dictation)"를 언급했다는 게 특히나 놀랍다. 사실 이미 구글은 물론 우리나라의 인터넷 포털까지 자유발화를 통한 음성검색을 지원하고 있는 마당에, 사실 더이상 빼기도 뭐 했을게다. 남은 건 과연 이 음성인식을 어느 범위로 지원하냐는 건데, 과연 아이폰 내의 기능으로 제한될지, 음성을 통한 인터넷 검색까지 지원할지, 아니면 기왕 Dictation을 넣은 김에 새로 들어가는 iMessage나 이메일의 음성 받아쓰기를 포함시킬지, 혹은 심지어 모든 키보드 입력 상황에서 음성입력의 대안을 제공하는 소위 "Hybrid VUI"까지 구현할지 말이다. 아니 기왕 꿈을 꾸는 김에, 일전에 인수한 대화형 검색엔진 Siri의 기능을 몽땅 아이폰에 넣어서 제대로 된 대화(nested adjacent pair 등을 포함한) 로 대부분의 PIMS를 이용할 수 있도록 한다면? ㅎㅎ (물론 보통 이런 상황에서는, 애플은 보수적인 접근을 택해서 나를 실망시키곤 한다.)

끝으로 "Long EPD"라는 옵션도 아마 PTT 기능과 관련해서, 버튼을 누르고 떼는 순간과 음성발화에 공백이 있는 순간을 비교해서 음성인식에 유리한 발화를 선택하는 기능이 아닐까 싶다. 실제로 그렇게 된다면 '그런데 그 일이 정말 일어났습니다!' 라는 느낌일 듯 하지만.

한가지 확실한 것은, 만일 이 기능들이 출시되는 iPhone 5에 그대로 들어간다면 더이상 장애인 접근성에 포함되지 않을 거라는 거다. 그렇게 된다면 -- 안드로이드에 이어 아이폰에까지 주요 사용방식으로 음성이 적용된다면 -- Voice UI도 사용자 인터페이스의 주류에 들어갔다고 말할 수 있겠지.

... 하지만 역시, 그런 일이 일어날까나. -_-a;;


Assistive Touch
iOS에서의 장애인 접근성 기능 중에도 추가되는 기능이 있다. 이전 버전에서는 다이얼을 돌리는 동작을 하면 그 상대적인 회전 각도에 따라 다른 기능을 실행시키는 Rotor라는 기능이 있었는데, 이 방식은 상하좌우가 비슷하게 생긴 iPhone이나 iPad에서는 특히 전맹인(全盲人)을 고려할 때 꽤 괜찮은 접근이었다고 생각한다. 그런데, 이번 방식은 반대로 장치의 방향을 안다는 전제 하에, 특정 위치에 손가락을 댄 후에 화면 중앙에서 상하좌우의 미리 설정한 방향으로 손가락을 움직이면 해당 기능을 선택할 수 있다.

Assistive Touch in iOS5



위 동영상에서 볼 수 있듯이, 손가락을 움직여서 구동시킬 수 있는 기능 중에는 멀티터치 기능도 있어서 여러 손가락을 자유롭게 움직일 수 없는 지체장애인의 경우에도 멀티터치 동작명령을 쓸 수 있게 해준다.

Assistive Touch in iOS5 - Custom gesture
유출된 왼쪽의 설정화면에 따르면, 이 기능을 쓰기 위해서 처음 터치해야 하는 지점(adaptive accessory?)은 미리 설정된 터치 제스처(가로 지그재그)로 활성화시킬 수도 있는 것같다. 이 동작은 사용자가 바꿀 수도 있는데, 어쩌면 그 동작이 다음에 뜨는 pie menu의 방향성을 결정할 수도 있겠다. Pie menu는 최대 8개까지의 기능을 설정할 수 있는데, 이런 방향 버튼의 조합은 다양한 장애인 보조기술(assistive technology)에서 지원하고 있는 입력으로 접근가능한 웹사이트 UI 설계 지침에도 들어가는 대목이기도 하다.

사실 장애로 인한 니즈가 없는 일반 사용자의 경우에도, 이 방식은 주머니 속에 손을 넣은 채 주요 기능을 사용하게 해줄 수 있을 것같다. 어쩌면 Universal Design의 개념과 맞물려 좋은 사례가 되어줄지도...?


Deep touch
설마 하니 아닐 거라고 생각하긴 하지만 -_-, 어쩌면 이번 아이폰5에는 터치 이전에 손가락의 감지를 느낄 수 있거나, 터치 이후에 압력 혹은 클릭을 느낄 수 있는 방법이 들어가지 않을까. 화면 자체는 아니더라도, 앞서 말한 방식의 터치방식의 홈버튼이 구현된다면 터치와 클릭/압력을 조합해서 제한된 범위나마 딥터치가 구현될지도 모르겠다.

Deep Touch

Apple Mighty Mouse

앞에서 적었듯이 "마이티마우스"의 기술이 아이폰의 홈버튼에 들어간다면, 사실 누군가는 그 제품에서 별로 빛을 보지 못한, 하지만 사실은 꽤 중요한 기술을 재검토했을지 모른다. 바로 마이티마우스의 양쪽에 있는 압력센서. 아이폰5의 홈버튼이 단순한 물리 스위치가 아니라 압력센서를 겸하는 것이라면 그것도 재미있는 딥터치 사례가 되겠다. 실제로 그 마이티마우스의 사례처럼, Expose 화면들의 축소 정도가 압력에 따라서 결정된다면 사용자는 화면을 완전히 전환하지 않고도, 자신이 필요로 하는 만큼만 정보를 훔쳐볼 수 있을 것이다. ... 하지만 다른 버튼도 아니고 홈버튼에 그런 불안한 아날로그 센서를 넣으리라는 기대는 나로서도 좀 무리. =_=

... 이러나 저러나, 역시 이건 그냥 개인적인 소망일 뿐이다.


NFC/RFiD
이게 언제부터 나오던 이야긴데 아직도 안 넣냐. -_-;; 루머에 따르면 애플에서는 아직 그 상품화 필요성을 못 느끼고 안 넣으려고 하는 것같지만, 이미 안드로이드 스마트폰에서는 이를 이용한 어플리케이션을 이용해서 아이폰과 차별화가 이루어지고 있고, 얼마전에는 Google Wallet이라는 서비스가 나오면서 이 방식이 아예 주류 통신채널 중 하나로 급부상하고 있다.

즉 이 대목에서 애플이 iOS에 NFC를 포함시키지 않는다면 안드로이드 기기와 비교될 수 밖에 없을테고, 따라서 그런 결정은 내리지 않을꺼라고 기대하고 있다. 애플 입장에서는 소위 "iTunes 생태계(eco-system)"에 다른 결제 방식이 끼어드는 것을 싫어하는 게 당연하다. 그래서 In-App 결제니 뭐니 만들면서 앱에서 직접 결제하려고 할 때마다 어떻게든 막아왔는데, 이제 와서 전자지갑이니 앱을 통한 인증이니 결제니 하면서 통제할 수 없는 돈의 흐름이 생기는 게 내키지는 않겠지.

... 그래도 이것만큼은, 이번에도 안 들어간다면 애플이 너무 욕심이 많은 거다.



여기까지. 사실 이런 예측... 혹은 제목에 적었듯이 희망사항들(wishlist)이 얼마나 애플의 의사결정권자들의 생각과 맞을지는 모른다. 저번에 그랬듯이 대박 틀릴 수도 있겠지. 단지 정식으로 공개되기 전까지는, 내 생각을 한번 정리해 보고 싶었다.

이건 그저, 후견지명의 오류에 빠지지 않으려는 애플 빠돌이의 몸부림일 뿐이다.
저작자 표시 비영리 변경 금지
신고
Posted by Stan1ey
HTML5 규약에 음성인식이 추가된 것을 이제 와서 굳이 언급할 건 없겠지만, 그래도 데모 웹사이트를 본 이후 개인적으로는 처음, 이 HTML5 음성인식 태그를 실제로 적용시킨 웹사이트를 발견했다.

Isohunt.com with Voice Search (for Chrome)


쿨럭... 뭐 애당초 자바스크립트를 penthousemag.com 소스를 분석해가며 배운 사람으로서 새삼스럽지만, 어쨋든 그닥 자랑할만한 웹사이트는 아니긴 하다. 그러고나서 대충 구글링해 보니 어느새 개인 블로그를 중심으로 음성인식 태그를 적용시킨 사례가 눈에 띄게 늘어나고 있는 듯하다.

... 그래서, 그냥 나도 해 봤다.

Voice Search for the rest of us


이 블로그를 구글의 크롬(Chrome) 브라우저나 크롬OS를 통해서 들어왔다면(구글이 현재로선 HTML 규약을 가장 발빠르게 적용하고 있기도 하고, 사실 브라우저 만드는 회사 중에서 흔치 않게 자체적인 음성인식 솔루션을 보유하고 있기 때문에 가능한 기능일게다), 본문 위 오른쪽의 검색 입력창에 마이크 아이콘이 나타나 있을 거다. 그걸 클릭하고 검색하고 싶은 단어를 "말하면" 된다. 노트북에 내장되었거나 헤드셋에 달려있는 마이크를 써야 하는 건 당연하겠고. 아무 언어나 그냥 자연스럽게 말하면 된다.

그냥 잘 된다. ㅡ_ㅡ;;;

다른 블로그에 나와있는 걸 보고 티스토리 블로그 형태에 맞춰서 적당히 수정했을 뿐인데, 그냥 바로 적용이 되어 버리는 걸 보고 내가 오히려 놀랐다. 10초만에 이 블로그 -- Voice UI에 대해서 기회가 될 때마다 징징거리는 -- 가 음성검색이 가능한 블로그가 되어 버렸다. 쿠헐. 쫌 허무할 정도다.

Voice Search UI - Closeup in Korean


이제 인터넷에서 음성인식을 통해서 뭔가를 입력한다는 것은, 비록 Voice UI 자체의 제약조건 등은 여전히 유효하겠지만, 비교적 간단하고 당연한 일이 되어 버렸다. 위에 링크한 규약을 보면 단순한 음성검색 외에도 VUI의 기본적인 설계에 필요한 이런저런 내용이 정의되어 있어서, 화면에 표시되는 정보와의 공조라든가 음성안내(합성음 혹은 미리 녹음된 음성을 이용한)에 대한 내용까지도 포함되어 있다.

그동안 수많은 사람들이 힘겹게 힘겹게 물을 대서 말라죽지 않게 해왔던 음성 UI에, 이제 날개가 달린 셈이다. 과연 음성 사용자 인터페이스라는 것이 될성푸른 떡잎이었는지 아니면 애당초 글러먹은 쭉쩡이였는지 드러나는 순간이 드디어 오고야 말았다. 참으로 반갑고, 두려운 마음이다.


혹시나 참고가 될까해서... 티스토리 블로그에 음성검색을 부가하려면, 관리자 메뉴에서 스킨의 HTML 편집에 들어가서 아래 코드를 찾은 후 파란색 글자 부분을 추가하면 된다. 아직은 구글 Chrome에서만 검색이 된다는 점에 유의할 것.

<input type="text" name="##_search_name_##]" value="##_search_text_##]" onkeypress="if (event.keyCode == 13) { ##_search_onclick_submit_##] }" class="input" x-webkit-speech="" x-webkit-grammar="builtin:search" onwebkitspeechchange="##_search_onclick_submit_##]" />

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


(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
이미 제품의 외형이며 어떤 부품이 들어가는지까지 속속들이 드러나 버린 상태에서 이만한 관심을 끄는 제품도 없을 거다. 새로운 아이폰이 드디어 공식발표되고 웹사이트에 관련 내용이 올라왔길래, 한번 훑어보니 역시 짧은 키노트에 모두 포함되지 못한 내용이 좀 있다. 사실 키노트의 내용 중 많은 부분(이를테면 HD영상 녹화, 화상통화)은 오히려 하드웨어를 보고 예상할 수 있는 부분이었기 때문에 조금은 김이 빠져 있었는데, 발표에서 빠진 내용을 보면서 "역시 애플은 대단해..."이라는 덕심이 다시 한번 치솟는 기분을 느꼈다.

iPhone 4의 발표 소식(?)에 대해서는 이미 여기저기서 많이들 올라와 있을테니, 난 HTI 관점에서 직접적인 발표내용 외에 주목할만한 내용들, 그리고 누군가 열심히 UX 개선을 위해서 애쓴 흔적이 눈물겹도록 보이지만, 솔직히 물건을 파는 데 크게 도움이 되지 않아서 발표에서 제외된... 그런 내용이나 좀 정리해 보려고 한다. 서로 돕고 살아야지. (무슨 도움이 되겠다는 건지는 모르겠다만 -_- )

(1) Gyro Sensor
Gyro Sensor in iPhone 4

아 물론 자이로 센서가 포함된다는 사실 자체는 발표 내용에 대대적으로 포함됐다. 근데 이게 무슨 의미를 가질까? 잡스가 보여준 데모는 젠가라는 보드게임이었는데, 사실 휴대폰을 돌리면 화면이 돌아가는 정도는 기존의 가속도 센서로도 거의 불편함을 느끼지 못한 것이기 때문에 조금은 고개를 갸우뚱하게 한다. 이미 관련 블로그에도 그 의미에 대해서 의구심을 표시하고 있기도 하고. 사실 젠가 게임은 순수하게 자이로 센서의 특성을 보여주기에는 좋은 사례일지 모르지만, 실상 가장 강조되어야 할... 위 사진의 맨 아래에 등장하는 6축 동작인식이라는 부분이 잘 드러난 것 같진 않다. 자이로 센서가 들어감으로써, 기존 가속도 센서를 이용했던 회전 감지에 비해서 나아지게 되는 건 뭘까? 

기존에 들어있던 가속도계는 원래 상하좌우로의 직선운동을 잡아내는 물건이다. 마침 지구에는 중력가속도라는 게 있는 덕택에, 아래로 떨어지려는 움직임(정확히는 그 반작용)의 방향을 상하좌우 센서의 입력값을 비교함으로써 알아내고, 그걸 바탕으로 기기의 자세(가로/세로)를 알아내거나 매시각 비교함으로써 상대적인 회전을 찾아내는 것이다. 이렇게 직선운동을 잡아내는 물건으로 회전운동을 찾아내려다 보니, 직선운동과 회전운동을 둘 다, 실시간으로 구분해서, 함께 인식하기가 어렵다는 문제가 있다.

이제 순수하게 회전을 담당할 자이로 센서가 들어감으로써 아이폰은 회전과 직선운동을 동시에 알아낼 수 있게 된 것이다. 이건 단지 잡스의 데모에서처럼 사용자가 폰을 들고 제자리에서 돈다는 정도가 아니라 3차원 공간에서의 자유로운 위치와 자세 변화를 (상대적으로) 인식할 수 있다는 거다. 한동안 유행했던 증강현실(AR)을 예로 들자면, 이제 기준이 되어 줄 AR-Tag가 없이도 임의의 공간을 상정하고 그 주변으로 아이폰을 움직이면서 그 공간에 떠 있는 가상의 물체를 관찰할 수 있을 것이다. 아니 심지어 공중에 직접 3차원 그림을 그리는 건 어떨까. 3차원 그림을 그리고 감상하는 어플도 충분히 가능하리라 생각한다. (가속도 센서와 자이로 센서의 악명높은 오류 누적 문제는 일단 덮어두자. -_- )

사실 이제까지 회전인식을 도와주던 게 3GS부터 들어가 있던 전자나침반인데, 이건 주변 자기장의 변화에 따라 초기화를 시켜주지 않으면 제멋대로 돌아가 버리는 아주 심각한 문제를 가지고 있다. 그렇다고 지도 서비스에서 동서남북을 알아낼 수 있는 기능을 버릴 순 없으니, 결국 다소 중복되는 것 같더라도 자이로 센서를 다시 추가했음을 짐작할 수 있다.

이로서 아이폰에는 자세를 알아내는 센서만 3개다. 이 센서값들을 개발자에게 어떻게 활용하기 쉽게 제공할지가 관건이 되겠지만, 이제 사실 더이상 넣을 센서도 없게 된 만큼 iPhone 4는 뭔가 궁극의 입력장치가 되지 않을까 기대하고 있다. 특히 닌텐도 Wii의 MotionPlus 리모트가 가속도 센서와 자이로 센서, 그리고 적외선 마커를 이용한 기준위치(화면)를 알아내서 정밀한 움직임을 측정하고 있다는 걸 생각해 보자. 아이폰은 이제 시각적 마커를 카메라로 알아낼 수도 있고, 심지어 나침반과 GPS 정보로 마커를 대신할 수 있게 됐다. 이상적으로 말하자면, 아이폰은 지구상 어디서 어떤 위치/높이에 어떤 자세로 어떤 움직임으로 사용되고 있는지를 완벽하게 계산할 수 있게 된 것이다. ... 어떻게 보면 좀 무섭다. ㄷㄷㄷ


(2) FaceTime using Rear Camera
FaceTime on iPhone 4
뒷면 카메라를 이용한 화상통화. 이것 역시 키노트에서 발표된 주요 내용 중 하나이긴 하지만, UX 관점에서는 꽤 신선한 느낌이다. 사실 화상통화(WiFi를 이용해서만 된다니 화상채팅?)는 거는 사람이나 받는 사람이나 다소 부담스러울 수 있는 상황이고, 사실 얼굴이야 서로 잘 알고 있을테니 얼굴만 봐도 좋은 연인 사이가 아니라면야 그보다 내가 지금 보고 있는 장면을 공유하면서 화제로 삼는 게 좀더 유용한 화상통화의 활용방법일 수 있겠다.

사실 이런 식의 활용에 대해서는 예전에 좀 들여다 본 적이 있는데, 이 특허 - 화상통화를 하면서 전면 카메라와 후면 카메라를 전환할 수 있는 - 는 국내 L모사가 6년전 쯤에 출원했던 것으로 기억한다. 결국 그게 특허로 등록이 되었는지, 그리고 그 특허가 혹시나 이번에 FaceTime을 굳이 WiFi 버전으로만 내는 데에 어떤 영향을 미쳤는지는 모를 일이다. (사실 애플이 언제 특허 신경 썼나... 아마 전송되는 화상의 품질 때문에 내린 결정이라고 보는 게 더 타당할꺼다.)

이 기술은 기존에 3G 망을 통해서 할 수 있었던 화상통화와 전혀 다르지 않아 보이기 때문에 처음 발표를 접한 사람들도 "남들은 이미 다 하고 있었다"면서 시큰둥한 반응이 있기는 했지만, 전화통화 상대방과 전화망 외의 ad-hoc IP 네트워크 연결을 순간적으로 해준다는 건 꽤 혁신적인 발상이다. 다른 네트워크(3G 등)으로 확장하는 것도 어렵지 않은 방식이긴 하지만, 사실 굳이 화상통화를 WiFi로 제한한 것은 아이폰 덕택에 기하급수적으로 늘어나는 통신사의 데이터 통신망의 부하를 어떻게든 줄여주고자 하는 제스처 아니었을까. 이런 식이라면 화상통화를 하면서도 통신사의 데이터망은 건드리지 않을 수 있을테니까.

이게 만일 MSN 메신저와 같은 방식으로 어딘가에서 각 통화자들의 IP를 연계해주는 화상채팅 중계 서버가 있는 거라면 여러가지로 문제가 되겠지만... 굳이 "zero set up"을 강조하고 "open standard"로 추진하는 걸로 봐서는 그냥 폰과 폰이 직접 P2P로 IP를 주고받고 화상망을 구축하는 방식인 듯 하다. (만일 따로 중계서버가 있어서 아이폰 사용자의 화상통화 상황을 알 수 있다면... ㄷㄷㄷ )


(3) The Second Camera
Front Camera on iPhone 4
화상통화와 함께, 드디어 결국 전면카메라가 들어갔다. 이미 지난 수년간 디지털 카메라에 들어간 얼굴인식/미소인식 등의 영상인식 기술이 특허침해 같은 거 검토하지 않고 무작위로 App으로 등장하고 있는 와중에, 전면카메라가 갖는 의미는 각별하다. 이를테면, 아래와 같은 걸 아이폰에서 볼 수 있게 된 것이다!



혹은 이전에 소개했던, 전면카메라를 활용한 NDSi의 (조금은 우스꽝스러운) 게임들은 어떨까. 앞의 자세 인식 센서들과 함께 전면카메라의 사용자 얼굴인식 기능이 합쳐진다면, 이건 뭐 어떤 괴물 앱이 나와도 이상하지 않겠다. 키노트 내용에 따르면 전면 카메라에 대한 API도 개방될 것 같으니, 개발자들이 어떤 사고를 쳐줄지 두근두근 기다려 보자.


(4) Dual Mic

마이크가 위아래로 2개 들어간다는 소리가 나오는 순간 눈이 번쩍 떠졌다. 전화를 표방하는 기기에서 마이크가 2개 들어간다면, 이유는 뻔하다. 발표 내용에도 나왔듯이, 배경의 잡음을 없애 깨끗한 음성을 보내기 위함이다. 양쪽 마이크에 입력되는 음의 파형을 시간축으로 미리 설정한만큼 평행이동 하면, 아래쪽 마이크 가까이 있고 위쪽 마이크에는 어느 정도 떨어져 있는 (즉, 음성이 전달되기까지 시간이 좀 걸리는) 사용자의 음성이 겹쳐지게 된다. 나머지 음향정보는 사용자 음성이 아닌 주변 잡음이기 때문에 신호를 줄여버리면, 깨끗한 음성만 보낼 수 있는 거다.

사실 이 기술은 2년전쯤 "알리바이폰"이라는 명칭으로 국내에도 상품화된 적이 있으니, 새롭다고 하긴 어렵다. 기술에 붙인 이름이 좀 위험스러워서인지 마이크 하나 더 붙이는 단가가 부담스러웠는지, 어쨋든 "깨끗한 통화"라는 본래의 취지가 무색하게 이후의 휴대폰에서 이 기술이 적용된 사례는 찾아보기 어렵다. :(

어쨋든 dual mic의 채용에 반색하는 개인적인 이유는, 물론 음성인식률의 향상을 기대하기 때문이다. 여러 개의 마이크(mic array)를 이용해서 음성명령의 공간 상의 위치(방향/거리)를 파악하고 나머지 음향을 소음으로 여길 수 있다거나, 심지어 여러 명이 동시에 말하는 내용을 따로따로 구분할 수 있다는 기술만큼은 아니겠지만... 그래도 이 마이크 입력을 이용하면 통화나 음성인식 뿐만 아니라 박수소리의 방향/거리를 알아낸다든가 동영상 녹화 시에 배경음을 녹음할지 녹화자의 음성을 녹음할지 선택할 수 있다든가 하는 기능도 구현할 수 있을 것이다. 단지 이 마이크들에 대한 API에 대해서는 따로 언급이 없었고, 무엇보다 이런 신호처리를 하려면 그냥 주어진 조건(귀옆에 대고 통화하는)에 맞춰서 하드웨어에 프로그램을 박아 버리는 게 편하기 때문에 과연 그 정도의 자유도가 개발자에게 주어질지는 모르겠다. 그냥 위 조건에 맞춰진 잡음제거 기능의 강도를 조정하는 정도가 아닐까?


(5) N-Best Type Correction
Type Correction on iPhone 4
터치스크린의 잦은 오입력을 보완하기 위해서 아이폰을 필두로 많은 스마트폰은 어절 수준에서 오류를 인식하고 자동으로 수정해 주는 방식을 채택하고 있다. 어절을 기준으로 한 수정방식이 한글이나 조사/어미를 갖는 다른 언어들에 맞지 않는다는 점은 차치하더라도, 기존의 방식은 띄어쓰기나 마침표 등을 입력할 때 무작정 오류(라고 생각한) 입력을 지우고 대안으로 바꿔버리기 때문에 자주 쓰지 않는 단어를 입력할 때마다 사용자가 아차하는 순간에 의도하지 않은 내용이 입력되는 경우가 많다. 사실 이건 모든 인공지능 입력 기술이 가지고 있는 공통적인 인식률의 문제이기도 하고.

그런데 이번에 공개된 내용 중 한 페이지에는 다른 부분과 달리 오타로 추측되는 어절을 분홍색으로 표시한 후 사용자가 터치하면 몇가지 대안(인식기술 쪽에서는 N-Best라는 표현을 쓰는, 사실은 가장 흔한 방식이다.) 중 하나를 선택할 수 있게 해 주는 내용이 나와 있다. 문자 메시지의 경우에는 안 되고 이메일에만 되는 기능이라면 사용자의 혼란이 있을 것도 같은데, 어쨋든 이렇게 사후수정 방식이라면 터치스크린과 잘 어울리기도 하고, 의도하지 않은 수정을 없애거나 다시 복구하기 쉽게 만들 수 있을 듯 하니 반가운 일이다. 터치스크린의 오터치 보완 방식이 조금은 인간을 위해 겸손해진 느낌이랄까.


(6) Faces and Places
Faces - Face Recognition on iPhone Photo Album on iPhone 4Places - Location-based Photo Album on iPhone 4

이미 iPhone OS 4 (이젠 iOS 4가 됐다)의 개발자 버전을 통해서 많이 누설됐지만, 데스크탑용의 Mac OS에서 구동되는 iPhoto를 통해서 가능했던 Faces와 Places 사진정리 기능이 아이폰으로 들어왔다. 어찌나 반갑던지. :)

설명을 보면 Faces 기능은 iPhoto와 함께 사용할 수 있다고 되어 있는데, 이거 iPhoto에서 얼굴인식한 내용을 가지고 모바일에서 보여주기만 한다는 건지, 아니면 그냥 얼굴인식은 각자 하고 그 meta-tag를 공유한다는 얘긴지 모르겠다. 작년에 보여준 iPhoto의 얼굴인식 및 등록 기능은 아이폰에서 똑같이 만들기에 사용자 입장에서도 기술적으로도 어려워 보이지 않았으니 전자는 아니라고 생각하지만, 그렇다면 왜 굳이 iPhoto를 언급했을까... 이 부분은 조만간 개발자 버전을 깐 사람들이 규명해 주리라 생각한다.



그리고...

ASL Users using FaceTime on iPhone 4
아래의 나머지는 늘 굳이 내세워 발표하지 않는, 장애인을 고려한 확장된 접근성에 대한 부분이다. 애플은 위 FaceTime을 홍보하는 동영상에도 수화로 대화하는 연인을 넣을 정도로 장애인에 대해서 고려하고 있으면서, 절대로 그걸 크게 부각시키는 법이 없다. 어쩌면 "특정 사용자 전용이 아닌, 더 많은 사용자에게 편리한" universal design의 철학에 가장 걸맞는 모범을 보이고 있다고나 할까.


(7) Gesture-based Voice Browsing
Gesture-based Voice Browsing on Safari, iPhone 4
우선 첫번째는 웹 브라우저. 이미 들어가 있던, 웹페이지 내용을 음성으로 읽어주는 기능에 더해서, 웹페이지의 특정부분에 손가락을 대면 바로 그 부분의 텍스트를 읽어주는 기능을 추가했다. (왼쪽 그림에서는 오른쪽 아래 광고(?) 영역을 선택해서 듣고있는 상태)

기존의 screen reader 프로그램들은 HTML 코드를 내용 부분만을 잘라내어 처음부터 줄줄이 읽어주는 게 고작이었고, 일부러 시각장애인을 고려해서 코딩하지 않는다면 어디까지가 메뉴고 어디부터가 본문인지도 알기 힘들었다. 그런데 이렇게 모바일 기기의 터치스크린의 장점을 살려서 손에 들고 있는 페이지의 특정 위치를 항행할 수 있게 한다는 것은 정말 혁신적인 장점이 되리라 생각한다.


(8) Rotor Gesture

이 기능은 3GS부터 있던 기능이라는 것 같은데, 왜 이제서야 눈에 띄었는지 모르겠다. 화면 상에 실제로 뭔가를 표시하는 건 이번이 처음인 것 같기도 하고... 어쨋든 이 기능은 두 손가락을 이용해서 회전식 다이얼(로터)를 돌리는 듯한 동작을 하면, 아마도 그 각도변화에 따라서 몇가지 음성항행 모드 중 하나를 선택해 준다. 이를테면 목록을 읽을 때 제목만 읽기라든가, 바로 기사 본문으로 가기라든가, 링크된 영역만 읽기라든가... 기존의 음성 웹 브라우징은 키보드 단축키를 통해서 이런 모드를 지원했는데, 이 로터 제스처는 터치스크린에 맞춘 나름의 좋은 해법인 것 같다.


(9) Braille Keyboard Support
iPhone 4 Supports Braille Keyboards via Blutooth
말 그대로, 블루투쓰를 통한 25개 언어의 점자 키보드를 지원한단다. 휴... 이건 정말 쉬운 결정이 아니었을 듯. 점자 키보드라는 게 얼마나 표준화가 잘 되어 있는지 모르겠지만, 경쟁사의 다른 무선 키보드와도 연동하기 까다롭게 만들어 놓기로 유명한 애플사다. 이렇게 점자 키보드를 위한 입력을 열어놓으면 분명히 제한없이 공개되어 있을 그 방식을 적용한 비장애인용 키보드 제품이 쏟아질 건 자본주의의 이치. 비록 악세사리라고는 해도 독점이 가능한 키보드도 팔고 있으면서 이런 결정을 내린 사람들은 도대체 어떤 경영진, 어떤 책임자, 어떤 월급쟁이일까. 어쨋든 훌륭한, 심지어 존경스럽기까지 한 결정이다.



이상. 사실 별다른 관심이 없던 발표여서 신나는 내용이 많기는 했지만, 왠지 개인적으로 다음 달에 판매한다는 iPhone 4를 바로 구매할 만한 큰 계기는 찾지 못했다. 무엇보다 루머의 RFiD도 안 들어갔고... 지금 쓰고 있는 아이폰을 1년반 넘게 썼으니, 2년을 채우고 고민해 봐야 할 듯 하다.
저작자 표시 비영리 변경 금지
신고
Posted by Stan1ey
이 프로젝트가 드디어 iPhone App으로 출시가 되었다. 무료.



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

Siri VPD Website

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



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

나도 한 우물 열심히 파면서 살아야 하는데, 어느새 여기까지 와 버린 건가... ;d
신고
Posted by Stan1ey
아이폰 앱으로 트위터를 들여다보다가, 한켠의 광고가 눈길을 끌었다.

Hate Speling? - from Google Voice Search

많은 단점에도 불구하고 Voice UI의 장점으로 이야기할 수 있는게 몇가지 있는데, 거기에 철자를 몰라도 된다는 점도 추가해야 할 듯. 요새 인터넷에 올라오는 글들을 보면 우리말도 철자가 변용이 점점 다양해지는 것 같은데, 어쩌면 그게 음성인식 UI를 채용해야 하는 당위성을 좀더 높여주지는 않을까.

... 안 될꺼야 아마. -.-



어쨋든, 그냥 스크랩이나 해두려고 굳이 캡춰해서 애니메이션으로 만들어 봤다. :P

신고
Posted by Stan1ey
Google Mobile App in Mandarin ChineseGoogle Mobile App in Mandarin Chinese

이제까지 영어로만 제공해오던 구글의 음성 인터넷 검색이, 어느새 중국어 서비스를 시작했다고 한다. 다음은 이 소식을 전한 기사의 한 대목.

According to the Google blog post where the Mandarin service was first announced, the search giant decided on Chinese after looking “carefully at demographics and Internet populations.”

결국 많은 사람들이 사용하는 언어이기 때문에 중국어를 '간택'하셨다는 이야기가 되겠다. 이런이런.

이 블로그에서만 벌써 몇번 언급한 것 같지만, 한국어는 그 언어를 쓰는 사람들, 즉 시장이 너무 좁아서 많은 돈과 시간을 투자해야 하는 음성관련 기술들을 연구하기 어렵다고 한다. 기업 연구소는 물론이고 정부출연 연구소조차도 이 시장성 없는 기술 개발에 투자할 생각이 없는 것 같으니, 우리는 Nuance나 Google이 각각의 언어를 많이 쓰는 순서대로 개발해주는 순서가 돌아올 때까지 손가락 빨며 기다려야 하나보다. 그것마저도 위키피디아에 나온 순서에 의하면 그래도 한국어는 프랑스어보다 많이 사용되고 있지만, 한국어 음성검색 서비스가 프랑스어보다 빨리 나오리라는 생각이 전혀 들지 않는 이유가 뭘까나. ㅡ_ㅡ;;;

Google Mobile Voice Search - English and Chinese
위에 링크한 구글 블로그에는 서비스를 유머러스하게 소개한 동영상도 포함되어 있는데, 마지막 부분에 나타나는 왼쪽 장면이 눈에 띄어서 캡춰해 두었다. 결국 영어와 중국어라는. 그래도 각 지역별 사투리를 어느 정도는 반영해 두었으니 이런 소리를 하고 있는 거겠지?







... 그나저나, 구글의 이 서비스 덕택에 통화 버튼을 길게 눌러서 음성검색을 수행하는 방식이 표준화되고 있는 것 같다. 훗. 휴.
신고
Posted by Stan1ey
한국 출시에 대한 이런저런 낯뜨거운 논란 끝에, 드디어 아이폰의 출시가 임박한 모양이다. 지난 몇달간 네티즌과 통신사와 제조사와 정부기관의 간접적인 대화를 보고 있노라니, 우리나라의 IT 인력은 세계 최고일지 모르지만 나머지 국가 시스템은 IT 후진국이라고 해도 되겠다는 생각이 든다. "IT 기술은 일자리를 줄인다"는 사람이 있는가 하면 '소프트웨어 기술자 신고제' 따위를 입안하는 사람들이 담당부서라면 뭐 말해봐야 입만 아프고 시간이 아깝다. 그 와중에 동서양의 IT 환경 비교에 한국이 자주 등장하는 걸 보면 대견할 지경이다.

어쨋든.

그럼, 아이폰 자체는 어떨까? 아이폰은 한국시장에 출시될 준비가 되어 있을까? 나름 UI 한다는 관점에서 말하자면, 아이폰의 그 멋진 UI, 과연 한국에 맞는 지역화 작업 localizing 은 잘 되어 있을까? 라는 점이 되겠다.


(1) Voice Control - 한국어/음성언어

우선 내가 늘 관심을 갖고있는 Voice Control 기능. 전부터 이 기능의 우리말 명령이 어떻게 설정되어 있는지 VUI 관점에서 궁금해 하고 있었는데, 사용 중인 3G 모델에서는 음성명령이 적용되지 않아서 (도대체 왜~!!! ㅠ0ㅠ ) 그냥 궁금해하고만 있었다. 그러다가 인터넷에서 아래 동영상을 발견.



일단 한국어 음성인식/합성이 되고 있다는 것 자체는 반가운 일이지만, 음성명령들은 확실히 좀 어색하다. 동영상에서 보여준 음성명령들이 실제로 한국어 명령으로 사용설명서에 나와있는건지, 아니면 이렇게 명령해도 어쨋든 인식은 된다는 사례인지는 사실 모르겠다. 일단 사용된 명령만을 대상으로, 각각 대응하는 영어 명령을 아이폰 사용설명서에서 찾아 비교해 보면 다음과 같다.

한국어 명령 영어 명령
노래 재생- Play
- Play music
일시정지 - Pause
- Pause music
누가 부른 곡입니까 - Who sings this song
- Who is this song by
틀기 이승환 가수- Play artist 이승환
- Play Songs by 이승환(?; 소개 동영상에는 나오는데, 사용설명서에는 없는 음성명령)
비슷한 노래 재생 - Play more like this
- Play more songs like this
- Genius
다음 노래 Next Song

흠... 실제로 한글판 iPhone 사용설명서가 나오기 전까지는 뭐라고 말하기 어렵지만, 일단 한국어에 맞춰 바꾸려는 노력이 좀 부족했던 것 같기는 하다. "틀기 이승환 가수"라니. ("틀기 가수 이승환"이나 "재생 가수 이승환"이어도 마찬가지. 어순 자체가 뒤집혔잖아. -_-;; ) 대체로 단어나열 수준의 음성명령을 쓰다가 갑자기 "누가 부른 곡입니까"라고 깍듯이 말하기도 참 어색한 게 사실이고.

누가 한국어 음성명령을 설계했는지는 몰라도, 이게 Voice UI를 설계한다는 개념이 있었다든가, 한국 말에 대한 이해를 바탕으로 자연스럽게 말할 수 있는 문장구조와 단어를 일관적으로 적용하려고 한 것 같지는 않다.


(2) Keyboard Typo Correction - 한글/문자언어

한국어 음성의 지역화 수준이 이렇다면, 한글에 대한 키보드 입력오류 보정은 어떨까? 사실 비슷한 수준이다. 그동안 아이폰을 쓰면서 좀 이해가 가지 않는 오류보정 메시지를 몇 가지 캡춰해 봤다.

Korean Typo Correction on iPhone - 김성재Korean Typo Correction on iPhone - 김수로Korean Typo Correction on iPhone - 김삼순

... 도대체 무슨 데이터베이스를 쓴거야! 라는 소리가 저절로 나온다. 왠 영화배우 이름이 우르르 나오는가 싶더니, 심지어 드라마 주인공 이름까지... 네이버의 검색어 순위를 학습시키기라도 한 걸까. 뭔가 한국의 아이폰 사용자가 입력할 법한 내용을 사용해서 학습시키지 않은 것만은 확실하다.

Korean Typo Correction on iPhone - 조사/어미
영어가 보통 각 단어가 어절로 독립되고 과거형이나 복수형 정도의 변이만 있는 것에 비해서, 조사나 어미를 중첩해서 사용함으로써 변이가 자유롭다는 것이 한글의 특징이라고 할 수 있겠다. 그런데 아이폰으로 한글을 입력하다 보면 왼쪽과 같은 순간이 자주 나타난다.

마치 어미를 강요당하는 기분이랄까. 원래는 "말이지"에서 끝내려고 했는데, 이 순간 띄어쓰기(이 조차도 "간격"이라고 번역되어 있다 -_-;;; )나 마침표 등을 입력하면 "말이지요"가 되어 버린다. 결국 아이폰이 학습하지 않은 어미의 조합을 입력하려고 할 때마다 매번 (x)표시를 눌러 자동 오타수정을 취소해야 했다. 물론 몇번 수정해주고 나면 같은 조합에 대해서는 더이상 이런 제안을 하지 않는데, 어차피 어근+어미, 단어+조사의 조합을 고려한 학습기능은 없으므로 다른 어근/단어를 사용하면 똑같이 학습을 시켜줘야 한다. 최소한 자주 사용되는 어미/조사에 대해서 예외조건을 넣을 수 있었다면 이런 상황에서 보다 적절한 UI가 나올 수 있지 않았을까 하는 아쉬움이 있다. 매번 맘대로 바꿔대는 조사를 그때그때 수정해야 한다는 건 정말 짜증나는 경험이다.




지금은 아이폰이 한국에 출시되느냐 아니냐만 가지고 논란이 되고 있지만, 일단 출시가 되고 난 후에는 이렇게 무성의하게 localizing된 UI에 대한 불만을 피할 수 없을 거라고 생각한다. 일반적으로 아무리 큰 회사라도 한국어만을 위해서 담당자를 두지는 않았을 거라고 생각하지만, 그래도 오타수정을 위한 학습 DB를 좀 더 정성들여서 '일반적인 내용으로' 고른다든가, 영어와 다른 어순을 갖는 언어들을 위해서 예외조건을 위한 여지를 따로 만들어 놓는 정도는 해주면 좋았을텐데.

한국어 음성인식/합성을 연구하던 분들과 이야기할 때 늘 이야기하던 것이, 한국어는 시장 자체가 좁아서, 한국 회사든 외국 회사든 돈을 들여서 깊이 연구하려고 하지 않는다는 현실이었다. 제대로 공들여 만들기 위해서는 언어를 잘 아는 연구팀이 적지 않은 시간을 들여야 하는데, 대부분 연구기관은 그 정도를 투자할 재량이 없고, 그런 여유가 있는 회사는 어차피 전세계를 대상으로 생각하므로 좁은 한국시장에 투자하게 되지 않는다는 것이다.

결국 한국어 음성엔진은 단순히 기존 어떤 언어에도 적용할 수 있는 음소나 자판입력 수준에서 패턴을 학습/매칭하는 것에서 더이상 발전하기 힘들거라는 한숨섞인 예측을 하곤 했는데, 아이폰에서 보여주는 한국어의 문제를 보면 그 부정적인 시각이 정확했던 모양이다.

아쉽지만, 대안은 없을 듯. 국책연구소에서조차도 단기간 내에 돈 되는 성과를 내지 못하면 팀이 없어지는 판국이니 뭐. ㅡ_ㅡa;;;



P.S.
혹시나 일본어는 좀더 신경써서 만들었을까 하고 iPhone의 일본판 사용설명서를 찾아봤다. 일본어는 우리말과 어순이나 조사/어미가 비슷하지만 아무래도 국제사회에서 좀더 대접받은 언어이기 때문에, 일본어 Voice Control 기능이 제대로 구현되고 있고 한국어가 잘 안 되어 있다면 순전히 한국어의 정치적 영향력 때문이라고 푸념할 근거가 되기 때문이다.

결과는 일본어도 마찬가지. 결국 영어 어순에 맞춰서 명령만 치환한 정도다. 음성엔진 자체의 한계이거나, 애당초 Voice UI를 설계한 사람이 비영어권의 어순 따위는 신경쓰지 않았던 듯.

iPhone Voice Control Commands - English vs. Japanese

그런데, 영어/일본어 사용설명서에서 캡춰한 위 명령어 목록을 비교해 보면 눈에 띄는 게 하나 있다. 바로 일본어 음성명령 목록에만 등록되어 있는 "수정하기" 명령. 음성인식이 잘못 되었을 때 그걸 수정할 수 있는 - 아마도 추출된 N-best 목록 중에서 다음 인식결과 대안을 선택하는 기능인 듯 - 명령어가 있는 것이다. 일본어 음성인식은 영어와 다른 엔진을 쓰는 걸까?

게다가 이 기능을 위해서 "틀렸어"라는 명령어 외에 "이건 아니잖아(これじゃない)"라는 코믹한 구어체 명령이 포함된 게 재미있다. 일본어 담당자가 명령어를 정하다가, 온통 딱딱한 문어체에 지쳐서 비교할 영어 명령이 없는 항목에 장난을 친 건지도 모르겠다. 펜탁스에서 출시한다는 '이건 아니잖아 버전' 카메라가 생각나기도 하고. ^^*
신고
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

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.