본질은 잃은 UI의 몰락 - 첫 번째 이야기
UX를 잃고 표류했던 9년간의 음성인식 이야기
(본 칼럼에 표시되는 이미지는 웹 검색을 통해 다운로드된 이미지이며, 상업적인 용도로 사용할 수 없습니다.)
필자는 UI 기획 9년 차이다. 관점에 따라서 짧은 시간일 수도 있고, 긴 시간일 수도 있다. 이 글은 9년의 시간 동안, 그리고 지금도 근근이 진행하고 있는 하나의 기능을 설계한 UI 에 대한 몰락 과정을 설명하고자 한다. 부끄러운 이야기이며, 괴롭고 안타까운 내용이지만 관련 업계의 종사자분들이 한 번쯤은 되돌아보는 그런 이야기였으면 한다.
좀 있어 보이는 자동차 음성인식 UI 기획자
지금은 O2O나, IoT로 많이 이슈가 전환되었지만, 한동안 뜨거웠던 자동차에 대한 UI 기획을 하고 있다. 그중에서 너무나 생소한 음성인식에 대한 UI를 기획한다. 음성인식이라... 참 멋지지 않은가? 그리고 자동차에서 이 얼마나 매력적인 기능(인터랙션)인가?
실제로 하는 일도 꽤나 있어 보인다. 사람들이 해야 할 말을 예측/정의하고, 그 말을 했을 때 여러 가지 조건들을 판단하여 안내를 해주고 원하는 기능을 실행하도록 시나리오를 설계한다.
음성인식, 꽤나 있어보이지 않는가?사람들이 기대하는 음성인식은 무엇일까?
음성인식이라는 부분의 본질(UX)을 생각해 보자. 많이들 머릿속에 그려지는 것은 영화 ‘아이언맨’의 ‘자비스’, 영화 ‘Her’의 ‘사만다’, 그리고 조금 과거로 돌아가자면 ‘키트(전격 Z작전)’ 일 것이다. 이들의 공통점은 주인공의 ‘비서’ 역할을 한다는 것이다. 그것도 아주 훌륭하게…
이들은 말도 잘 알아듣고, 지시를 성실히 수행하고 오류도 거의 없다. 오류가 있는 것이라고는 ‘이해할 수 없는 부분이니 다시 설명을 부탁’ 하는 정도이다. 거기에 주인공의 행동을 예측해서 준비도 해 준다.
아이언맨의 Jarvis(좌), Her의 사만다(우)기술적으로 보자면 ‘음성을 인식하는 것’과 ‘적합한 결과를 제공해 주는 것’은 다른 영역이다. ‘음성을 인식하는 것’은 순수하게 음성을 있는 그대로 인식하는 것이고 이는 100%에 이르는 성능을 보여준다. 반면 ‘적합한 결과는 제공해 주는 것’은 알파고 와 같은 인공지능(AI)의 영역으로 많은 양의 데이터와 사용자의 특성을 분석하는 것으로 사람에 따라서 10%도 되지 않는 성능을 보여준다.
어찌 됐던 사람들이 생각하는 ‘음성인식’은 이 두 가지를 모두 합한 것이다.
현실에서의 음성인식
아이폰을 가지고 계신 분들이라면 가운데 HOME 버튼을 길게 눌러보자. 마이크 모양의 버튼이 있는 화면이 하나 나올 것이다. 그리고 뭔가 아무렇게나 말을 하면 적당한 답을 들려줄 것이다. 이것이 Apple의 음성비서 ‘Siri(시리)’인데, 이것저것 말하면 괜찮은 대답을 해 줄 때도 있고 그렇지 않을 때도 있다.
안드로이드 폰을 가지고 계신 분들도 HOME 버튼을 길게 누르면 비슷한 무엇인가 실행된다. 삼성의 경우 S-Voice라는 음성비서 서비스, LG의 경우 Q-Voice라는 음성비서 서비스이고 Apple의 Siri와 유사한 콘셉트이다. (이것 말고 Amazon의 ECHO, Microsoft의 Cortana도 있다.)
Apple Siri(좌), 삼성 S-Voice (중), LG Q-Voice(우)신기해서 이것저것 써 보면, 이러한 서비스도 완벽하지 않다는 것을 알게 될 것이다. 대부분의 결과는 서버에 있는 데이터와 사용자의 정보들을 분석해서 도출되는데 영화에서처럼 멋진 목소리로 가장 적합한 결과를 표시해 주지 않는다.
필자가 설계하는 음성인식
9년 전부터 설계하고 있는 음성인식은 스마트폰(아이폰, 안드로이드 폰 등)의 그것보다 더욱 제한적이다. 스마트폰은 아무렇게나 말해도 이해를 했던 못했던 뭔가 대답을 한다. 그러나 설계된 음성인식은 정해진 단어 또는 문장을 말해야 하는 것이다(이를 ‘명령어’라 한다). 더욱 심각한 것은 ‘정해진 단어/문장’이 아닌 것을 말해도 그것이 ‘정해진 것인지 아닌지’ 알지 못한다. 이유인즉슨 인터넷이 연결되지 않는 상황에서도 되어야 하기 때문에 음성을 서버로 보낼 수가 없고, 판단을 위한 시스템 성능이 받쳐주지 못하기 때문이다.
이렇게 기술적 제약이 심각한 상황에서 UI를 설계해야만 했다.
필자가 기획한 UI가 현실화 된 제품기술적인 한계를 끌어안고, 개선을 해야한다.
어찌 보면 당연할 것 같은 부분들이 기술적인 한계에 부딪히면서, 제품 출시 후 사용자들로부터 많은 질타를 받게 되었다. 이것은 당연한 것으로, 사람들은 이미 아이언맨의 자비스 수준의 음성인식을 떠올리고 있었다. 이러한 현실 속에서 사용자들의 불만요소(사용성)를 개선하라는 요청이 쇄도했다.
어떠한 개선이던 시작은 일단 벤치마킹이다. 자동차에서 사용되는 음성인식이니 경쟁 회사 자동차를 미친 듯이 벤치마킹했다. 그리고 무엇인가 발견할 수 있을 것이라는 실낱 같은 희망으로 밤낮으로 애썼다. (일주일의 시간 동안 12대 자동차를 벤치마킹한다면, 정말이지 살인적인 일정이다.)
진짜 열심히 했던 기억이다. 이것은 누군가 지시해서라기 보다는 UI기획자로써의 자존심이 발동해서인지, 뭐든 해결해 보려 애썼다. (그런데, 벤치마킹을 해도 다들 같은 문제를 가지고 있더라)
첫 번째 개선,
사람들은 모두 말하는 방법이 다르다. 일상 언어처럼 만들어라.
회사의 비밀이라 벤치마킹에 대한 내용을 공유할 수가 없지만, 첫 번째 개선은 ‘일상 언어처럼’ 이었다. 사람들이 말하는 방식은 그 패턴이 없으며, 각각 다른 방식으로 말한다. 이를 ‘자연어’라고 하는데, 예를 들자면 ‘홍길동에게 전화 걸어’, ‘홍길동 전화걸기’, ‘홍길동에게 전화 걸어줄래?’ ‘전화 홍길동’ 등과 같은 것이다.
앞에서 설명한 것처럼 시스템은 ‘정해진 단어/문장’만 인식 가능하도록 한계가 정해져 있다. 따라서 ‘일상 언어처럼’ 만들어내려면 예상되는 모든 방식을 ‘정해진 단어/문장’으로 넣어야 한다. 엄청난 양의 명령어가 생기고 그것을 처리해야 하는 시스템의 속도가 현저하게 느려졌다.
‘홍길동에게 전화 걸어’라고 말했는데, 5초 있다가 전화를 건다면 그 기분이 어떻겠는가?
명령어가 실행될 때 까지...결국 이 개선은 실패로 돌아갔고, 엄청난 양으로 추가된 명령어는 대부분 다시 삭제되었다.
두 번째 개선,
사람들이 사용 가능한 명령어를 모른다. 명령어를 알려줘라
첫 번째 개선이 실패로 돌아가면서 여전히 ‘자연어’에 대한 문제점이 남았다. 시스템은 정해진 단어밖에 인식할 수 없는데, 실제 사람들은 ‘자연어’로 말한다는 것이다(당연한걸...). 그래서 다음 개선은 ‘사용 가능한 명령어가 뭔지 알려주자’는 것이다. 아이디어는 합리적이었으나 문제는 그것을 현실화하는 방법이었다.
나는 사용 가능한 명령어를 화면에 보여주자고 주장했고, 다른 의견은 음성안내로 명령어를 알려주자는 것이었다. 시각과 음성정보의 특성(시각정보-운전 중에 주의력 분산이 강함, 음성 정보- 휘발성이 강해서 기억하기 어려움)을 알고 있는 입장으로써 화면에 표시하는 것을 강력하게 주장했건만, 지면에 표현할 수 없는 몇 가지 이유로 인해 결국 음성안내로 명령어를 알려주도록 개선이 착수되었다.
이때 너무나도 답답했던 것은 반대의견 이었다. ‘자동차에서의 음성인식은 운전 중에 화면을 보지 않고도 가능해야 하기 때문에 화면에 표시하면 안 된다’ 가 그 의견인데, 음성안내는 다음과 같이 더욱 심각하게 만들어지게 되었다.
“사용 가능한 명령어는 A, B, C, D, E, F입니다. 명령어를 말씀해 주세요”
운전 중에 A~F를 기억하고 있다가 그중 하나를 말해야 한다.
운전을 하면서 듣기 평가 보는 것과 무엇이 다른가?
운전하면서도 듣기평가를 해야겠어?세 번째 개선,
음성인식을 실행하고 말할 때, 유의해야 하는 부분을 자세히 설명해줘라.
두 번째 개선도 답답해 미치겠는데, 같은 방법으로 음성인식에 대한 실행 방법이나 명령어를 말할 때의 유의사항들을 설명해 줘야 했다. 그것도 음성안내로...
일반적으로 상세한 안내는 사용자 매뉴얼이나 유튜브 동영상 등으로 제공해 주는 방식을 사용한다. 시스템에서 사용 빈도도 극히 낮을뿐더러, 사용자가 해결하기 어려운 문제에 봉착했을 때에 찾게 되는데 운전 중에 이런 안내를 제공한다는 것 자체가 문제였다.
결국... 3-5분간 떠들어대는 음성안내 설명을 만들어버렸다.
(꼭 정해진 명령어만 말하셔야 하고요, 가급적 창문을 닫고 말하셔야 하고요, 음성인식 버튼을 누르고 '삐'소리가 난 후에 말하셔야 하고요...)
난 듣기 싫다고네 번째 개선,
사용자가 말한 음성에 대한 인식률이 떨어진다. 인식을 하면 맞는지 확인하는 절차를 넣어라.
여지까지의 개선도 괴로운 시간이었지만, 네 번째가 가장 최악이 아니었나 싶다.
명령어를 알려주고, 사용 방법도 알려줬는데 사용자 불만이 계속됐다. “음성인식이 잘 안 된다”가 그 불만사항이다. 결국 사용자가 말한 명령어를 다르게 인식해서 엉뚱한 결과가 실행된다고 판단해 버리고, 방어장치를 만들어야 했다.
(사용자에게 ‘정확히 어떤 부분이 잘 안 되는지’ 물어볼 필요는 없다. 그들은 ‘몇 번 해봤는데 잘 안 되는 것’ 뿐이지 자세히 물어봐도 원인을 모른다.)
그 방어장치는 사용자가 말하면, 말한 내용이 맞는지 “예/아니오”를 되묻고 ‘예’라는 대답이 들어와야 실행하는 것이다.
당신이라면, ‘홍길동에게 전화 걸기’라고 말했을 때, 매번 ‘홍길동에게 전화를 걸까요?’ 라고 되묻고 ‘예’라고 답을 해야 한다면 그것을 사용할 의향이 있겠는가?
이거, 되게 귀찮지 않을까?새로운 설계…그러나…
다음 글로 이어가겠습니다.
※ Post Script!!
분명 이 글을 여기까지 읽지 않고 Facebook에서 "좋아요"를 눌러주시는 분들도 있을 것이다.
공감하신다면, 응원의 댓글과 공유 하나가 작가에게는 큰 힘이 됩니다.
Facebook : https://www.facebook.com/anitooni
E-Mail : anitooni@gmail.com
