디지털 인사이트님의 아티클 더 보기

트렌드

사용자의 모든 상황을 고려해야 한다, AI VUX 입문자를 위한 실전 Tip

음성인식 스피커의 음성 인터페이스를 설계한 프로젝트를 진행하며 풀어낸 ‘AI VUX 입문자를 위한 실전 Tip’을 통해 사례를 살펴보자.

음성인식 서비스를 자연스럽게 사용하기 위해선 사용자 관점에서 서비스를 구현해야 한다. VUX는 바로 이런 관점에서 음성인식 서비스를 적용하기 위한 접근이다. 그렇다면, UI·UX 기획자는 실질적으로 어떻게 접근해야 할까. 김호준 라이트브레인 가치UX그룹 수석이 음성인식 스피커의 음성 인터페이스를 설계한 프로젝트를 진행하며 풀어낸 ‘AI VUX 입문자를 위한 실전 Tip’을 통해 사례를 살펴보자.

들어가며

지난겨울, 한창 휴가를 즐기던 중 새로운 프로젝트가 시작됐다는 소식에 마지막 여행코스를 돌지 못하고 급히 복귀했다. 당시 만나게 된 새 프로젝트는 음성인식 스피커의 음성 인터페이스를 설계하는 것이었고 이에 필자는 잠시 머릿속이 텅 비는 경험을 했다.

사실 Voice UX(이하, VUX)는 생소한 것이 아니라 예전부터 있었다만 왜 과거 피처폰 시절에 스마트폰 UI를 설계해야 했을 때처럼 생소하고 또 당황했을까?(필자만 그렇다면 이 글을 읽는 당신은 이미 입문자가 아니다)

왜 안 그랬겠는가. 그동안 각종 고객센터의 ARS 서비스나 ATM기기, 건물 출입문 등의 음성 지원 서비스들은 진작부터 있었어도 대단한 관심과 집중을 받진 않았다. 때문에 기존 VUX는 메인이 아니라 서브, 주체가 아니라 보조 역할로 인식돼 그것을 설계하는 데에도 딱 그 정도만 하면 되겠다는 선입견(기존 VUX를 무시하는 것이 아니라 AI를 적용한 VUX에 대한 두려움이 그만큼 상대적으로 컸다는 것이다)이 존재했었다. 그러다 ‘인공지능’이라는 글자가 접두사처럼 붙으면서 사람의 ‘뇌’를 탑재시켜야 한다는 강박이 생기게 됐고 무언가 엄청난 기술과 복잡한 알고리즘을 이해해야 할 것 같았던 것이다.

애플의 ‘시리(Siri)’, 아마존 ‘알렉사(Alexa)’, 구글 ‘구글 어시스턴트(Google Assistan)’, MS ‘코타나(Cortana)’, SKT의 ‘누구(NUGU)’, KT ‘기가지니(GiGA Genie)’, 삼성 ‘빅스비(Bixby)’ 등 굴지의 IT기업들이 쏟아내는 수많은 음성인식 서비스에 ‘인공지능’이 강조되고 있는 것도 그런 두려움에 일조했다.

굴지의 IT기업들이 쏟아내는 수많은 음성인식 스피커

이런 환경에서 UI·UX 기획자로서 어떻게 접근하면 될까? 나에게 VUX를 고려한 VUI를 그려내라고 하면 어떻게 하지? 과거 클릭, 스크롤을 통해 제어하는 설계를 하다가 터치와 플리킹 UI를 정의하고 있는 우리는 그럼 이러한 상황에서 어떻게 하면 되는 것일까?

‘인공지능’과 ‘음성인식’에 대한 동향과 전망, 역할에 대한 자료는 검색엔진에서 간단하게 찾을 수 있을 정도로 이미 차고도 넘친다. 때문에, 이번 글에서는 직접 그 UI를 그려내야 하는 기획자의 입장에서 도움이 될 만한 Tip을 풀어내려 한다. VUI를 처음 시작할 때 기억했으면 하는 몇 가지 포인트를 설명하고, VUI 설계 예시를 작성해봤다.

염두에 둘 것

VUI라고 해서 기본적인 업무 수행 과정이 Display UI와 크게 다르진 않다. 다만, 사용자의 행동과 반응이 달라(UX) 고려할 부분이 달라지는 것이다. 다음 ‘상황’을 가정하고 VUI를 그리기 위해 어떤 것을 염두에 두어야 할지 살펴보자.

<상황>
뚜벅이이고 도산사거리 BMW 전시장 앞에 있다. 도산 안창호 기념관을 가고 싶다.

① Display UI·UX의 개념을 버려라

제시한 상황에서 Display UX와 Voice UX의 현저한 차이가 눈에 보이는가?

화면이 있는 웹이나 앱에서는 클릭 또는 터치의 동작을 빼도 크게 5단계를 거쳐야 결과값을 받을 수 있지만, 음성으로 요구할 때는 단 2단계로 끝난다.

“저기요~”와 “OOO 어떻게 가요?”

심지어 응답자를 호출하는 “저기요~”를 제외하면 실제 요구를 전달하는 내용은 1단계면 된다. 이 한 번의 음성 발화(發話)로 요구자는 자신의 의도를 전달하고 목적하는 결과를 얻고자 한다는 것을 잊어서는 안 된다.

이것은 Display 환경에서는 결과까지 가는 과정을 시각적 요소(메뉴, 네이밍, 버튼, 텍스트 안내 등)로 프로세스화해 이끌어갈 수 있지만, Voice 환경에서는 그런 보조적인 장치가 없는 상황(모두 없는 것은 아니나 대체적으로 없는 경우가 많다).

즉, 요구자의 의도를 잘 알아듣고 원하는 결과를 찾아내야 한다는 뜻이다.

또한, Display 환경에서는 결과값을 보여주고 나면 그 결과가 맞든 틀리든 기능이 종료되지만 Voice 환경에서는 요구 전달은 짧으나 1차 피드백 이후의 과정이 다양하게 진행된다.

한번 생각해보자. 위의 예시 상황에서 요구자가 길을 물어봤을 때 일어날 수 있는 다양한 상황들을. 응답자가 다시 한번 ‘어디라고요?’ 하고 되물을 수도 있고 그에 따라 요구자는 다시 한번 설명을 해야 할 수도 있다. 심지어 응답자가 초행이라(아니면 귀찮아서) 대답을 거부하는 상황이 생길 수도 있다.

이러한 Voice 환경에서의 행태들을 잘 기억해 둬야 한다. 결과가 맞든 틀리든 요구자가 혼자 더듬고 찾아가는 게 아니라는 걸.

② 요구자와 응답자로 빙의해보자

VUX의 차이를 봤다면, 실제 그 상태에서의 요구자와 응답자로 빙의해 보는 것이 답을 찾아가는 유용한 방법이다.

앞서, 요구자는 단 한 번의 발화로 의도를 전달하고 싶어 한다고 언급했었다. 응답자가 이 의도를 이해하기 위해서는 요구자의 다양한 표현방법이 동일한 요구라는 데이터가 있어야 한다. 즉, 다양한 요구 pool을 가지고 있어야 한다는 뜻이다.

Display 환경에서라면 지도 서비스에서 ‘장소명’ 입력으로 목적하는 바가 명확히 표현되지만, Voice 환경에서는 다양한 표현에 같은 목적이 있다는 걸 이해할 수 있어야 하기 때문이다. 그럼 요구자가 돼 보자. 위 예시 상황에서 요구자는 주위를 둘러보며 도움을 청할 사람을 찾을 것이다. 이렇게.

“실례합니다, 잠깐만요, 저기요, 길 좀 여쭐게요…”

그다음엔

“(도산 기념관) 어떻게 가나요? 어디에 있나요? 가고 싶은데요. (방향을 가리키며) 이쪽이 맞나요? 가는 길 좀 알려주세요…”

요구자의 이 의도(길을 묻는다는)를 응답자가 이해했다고 하면 이때 응답자는 Display 환경에서처럼 ‘짜잔~’하고 지도를 펼쳐 위치를 바로 찍어서 보여줄 수 있을까? 이번엔 응답자가 돼 보자. 우선 못 알아 들었을 수 있다. 이때는 “어디라고요?”라 되물을 것이다. 다시 말한 그 장소의 다양한 표현 또는 유사 표현을 모를 수도 있다.

“도산공원은 아는데 도산 기념관은…”
“도산공원에 안창호 기념관이 있긴 한데 거기 말인가요?”

이렇게 목적지에 대한 재확인도 흔하게 있을 수 있다. 여튼 목적지를 응답자가 알아들었고, 응답자가 아는 길에 다행히 거리도 가깝고 경로도 쉬울 경우 방향을 손짓으로 가리키며 간단히 설명해 줄 수 있을 것이다.

“이쪽으로 가서…저쪽으로”

하지만 요구자가 어려워한다면 또 다른 방법이나 경로를 설명해 줄 수도 있을 것이다. 어쨌든 이 경우는 어렵지 않게 설명만으로 도움을 줄 수 있는 상황이다. 그러나 거리는 가깝지만 경로가 복잡하다면? 사람에 따라 다르기는 하지만, 친절하고 시간적 여유가 있는 사람이라면 목적지나 근처까지 또는 쉽게 찾아갈 수 있는 위치까지 데려다줄 수도 있다.

“저를 따라오세요. 근처까지 같이 가 드릴게요.”

그런데, 경로도 경로지만 거리가 멀다면? 응답자는 길을 설명하기보다 다른 방법을 권할 것이다.

“거기까지 걸어서 가시게요? 에이~힘들고, 찾아가기 어려워요. 그냥 택시 타세요.”

앞서 말한 Display와 Voice 환경에서의 차이가 이제 좀 더 잘 보이지 않는가? Display 환경과는 달리 Voice 환경에서는 요구 전달 후 원하는 결과를 받을 때까지의 과정이 상당히 다양하고 길어질 수 있다는 점이 그 특징이다. VUI는 바로 이런 사람들 사이에서의 다양한 행태들을 그려내는 것이다.

③ 응답자에 캐릭터를 입혀보자

요구자와 응답자로의 빙의가 서비스를 제공하기 위한 필수요소를 점검하기 위한 것이라면, 응답자에게 캐릭터를 입히는 것은 서비스의 방향과 콘셉트에 완성도를 높이기 위한 것으로 생각하면 된다.

캐릭터는 응답자 자체에 성별이나 성향을 부여하거나 요구자와의 관계를 설정해 만들 수도 있지만, 요구자와 서비스의 성격에 호응할 수 있는 캐릭터를 적용하는 것이 가장 적절할 것이다. 상황에 따라 캐릭터를 입히지 않을 수도, 서비스에 따라 캐릭터를 입혀도 큰 차이가 없을 수는 있다.

하지만, 설정한 캐릭터에 따라 요구자의 응답에 반응하는 말투나 제시 범위도 다르게 구성할 수 있으므로, 같은 기능을 가진 서비스라 하더라도 다른 느낌과 다른 효과를 줄 수 있다.

예를 들어, 앞선 예시 상황의 요구자가 여성이며 길치라고 가정해보자(여성비하가 아니다. 필자의 현실이다). 라이트브레인 본사가 있는 도산사거리 BMW 건물 앞에서 도산 안창호 기념관을 가는 길은 그리 멀지 않고 어려운 경로도 아니다(앞서 첨부한 지도 참고). 그러나 길치라면 겨우 방향전환 2번(도산공원으로 들어가는 코너 포함)도 전환해야 할 포인트를 제대로 인지하지 못해 엉뚱한 방향으로 가기 일쑤다.

그래서 말로만 설명해주면 난감해진다. 최소한 첫 번째 전환 포인트를 손으로 가리켜 제대로 알려주거나 아니면 근처까지라도 직접 가주길 바라게 된다. 이때 응답자가 전혀 모르고 굉장히 바쁜 사람이라면? 또는 여유가 있고 굉장히 친절하지만, 말을 장황하게 하는 사람이라면? 친절하지만 필요한 부분만 조리 있게 잘 설명하는 사람이라면? 혹시 남자친구라면?

아마도 요구자의 상황과 응답자의 캐릭터는 세심한 부분에서 또는 서비스 콘셉트에서부터 차이를 보일 수 있을 것이다. 기회가 된다면 다양한 캐릭터를 적용해보고 가장 적합한 모델이 어떤 것일지 판단해 보시길 바란다.

VUI 설계 예제

자, 그럼 예제를 통해 VUI를 그려보겠다. 실제 VUI를 설계할 때 요구자가 원하는 것이 ‘정보’인지, ‘지시’인지, ‘대화’인지, 응답자의 피드백이 ‘음성’인지, ‘텍스트’인지, 수행내용이 Display UI 제어인지, 기기의 운전인지, 자체 연산인지, VUI를 적용할 장치가 어떤 것인지, 메인장치 외에 보조기구나 수단(시각적 요소 포함)이 지원되는지 혹은 필요로 한지 등에 따라 다를 수밖에 없다.

하지만, 그 모든 케이스를 연습해볼 수 없으니 이번에는 ‘정보’ 서비스를 ‘음성’으로 제공하는 상황을 보기로 하겠다.

‘길안내’ 서비스의 VUI 설계라 가정하고, 다음의 조건을 두기로 한다(본 예제는 상용화된 사례가 아니라 이번 글의 설명을 위해 필자가 임의 발제 한 것이다).

  • 출발지 기준 반경 5km 이내의 ‘도보 길안내’ 서비스
  • 휴대폰에 AI 음성지원 에이전트 탑재
  • 블루투스 이어폰(헤드셋)으로 AI 음성지원 에이전트 제어 가능
  • 보행자용 네비게이션 기능 지원
    (단, 이번 예제에서는 보행자용 네비게이션 실행 시나리오는 제외)

그 외 실제 서비스를 구현하면서 협의가 필요한 정책적인 사항, 기술적 검토 요건 등 구체적인 몇 가지 사항은 이곳에서 따로 언급하지 않았다. 프로젝트 진행 시 협의와 검토 과정에서 시나리오는 상당히 많이 바뀌고 달라질 수 있기 때문에 이 글에서 미흡한 설명들은 예제 진행을 위한 어쩔 수 없는 배제이니 양해를 부탁드린다.

따라서, 본 글의 예제에서는 설계 과정상 핵심인 프로세스와 Voice 시나리오만 다루고, 여러 기능 중에서 ‘길안내’에 대해서만 적용해봤다.

<길안내 기능 프로세스>

프로세스 자체는 Display UI 설계 시의 그것과 다르지 않다. 다만, 아웃풋이 음성지원 에이전트를 통해 음성이나 기타의 반응으로 나오는 것에 대해 로직화했을 뿐이다. 위의 프로세스에 따라 Voice 시나리오를 작성해 봤다.

이외에 장소 정보가 없는 경우, 장소 정보가 4개 이상인 경우, 장소 정보가 3개 이하인 경우, 장소 정보가 1개인 경우에 따라 시나리오를 작성한다(자세한 시나리오는 라이트브레인 블로그에서 확인할 수 있다). Voice 시나리오는 연극이나 영화를 위한 대본을 만드는 것으로 생각하면 이해가 쉬울 것이다. 다만, 사람이 연기하는 것이 아니라 기기나 소프트웨어의 행동과 대사를 지시하고 규정하는 것이기 때문에 몇 가지 약속한 표현이 있다.

예제를 통해 서비스 범위와 기능에 대해 간단히 정의하고, 이에 따라 VUI 프로세스를 그리고, 실제 적용할 음성(TTS든 성우 녹음이든) 시나리오를 작성해봤다. 사용자의 조작이 손->입, UI의 피드백이 화면->음성으로 바뀌기 때문에 최종 산출물의 형태가 다를 수는 있지만, Display UI에서 화면설계를 하는 것과 그 목적과 의도가 다르지는 않다. 입문자라면 이 글의 마지막의 예시를 예제라 생각하고 직접 해보고 필자의 예시와 비교해보는 것도 좋을 것이다. 이 글과 예제가 얼마나 큰 도움이 될지는 모르겠으나, 앞으로 프로젝트로 만날지 모를 VUX와의 첫 대면에서 당황하고 기죽지 않기를 바라는 마음으로 본 글을 마친다.

  • Call Name Word: 앞서 응답자를 불러 세웠던 “실례합니다, 잠깐만요, 저기요, 길 좀 여쭐게요…”를 뜻한다. 이제 요구자가 응답자(음성 에이전트)에게 말(요구)을 할 거라는 시작 신호이고, 실제 사람에게 하듯이 여러 표현이 아니라 하나의 표현으로 약속하게 된다. 예를 들어, 애플의 “시리야~”, 구글의 “OK 구글”, SKT의 “아리아~”, 삼성의 “하이 빅스비”와 같이 말이다.
  • 대표 명령어: 요구자가 말하는 내용이 어떤 ‘요구’인지 에이전트가 이해할 수 있는 범주를 정의하는 것이다. 요구자가 어떤 ‘표현’을 했을 때 이번 예제의 ‘길안내’ 서비스를 시작할 것인지 그 대표적인 표현을 정의해야 동작이 가능해지니 말이다.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다