행사에 몸소 참석하는 분이든, 가까운 곳에서 열리는 뷰잉 파티에 참석하는 분이든, 집에서 동영상으로 보는 분이든, Google I/O와 같은 이벤트를 최대한 활용한다는 것은 일종의 도전입니다. Actions on Google 팀은 어시스턴트 액션을 통해 이벤트 현장에 가시는 분과 동영상 시청자 모두에게 똑같이 유익한 경험을 줄 수 있는 기회를 발견했습니다. 더 많은 분들이 행사를 만끽할 수 있도록 Google 어시스턴트 액션을 만들고 싶었습니다. 이 게시물에서는 어시스턴트 액션을 만들 때 마딱드린 주요 과제와 이를 해결하기 위한 결정 사항을 비롯하여, 액션을 설계하는 과정에 중점을 두고 설명하겠습니다. 이어질 다음 게시물에서는 기술적 구현에 관해 상세히 다룰 예정입니다.
왜 대화인가?
대화 디자인은 강력한 접근 방식이지만, 모든 사례에 적합한 것은 아닙니다. 예를 들어 대화는 어떤 레스토랑의 영업 시간을 찾는 작업에는 효과적이지만, 저녁 메뉴를 찾아보기에는 좀 거추장스럽게 느껴집니다. 우리는 어시스턴트 액션이 제공하는 대화가 속도, 단순성, 편재성을 통해 사용자에게 확실히 가치를 부가하도록 하고 싶었습니다. 대화가 적합할 것이라 생각한 이유는 다음과 같습니다.
- 이벤트에 대한 대화는 직관적입니다. 사용자는 어떤 이벤트가 어디서 있을 예정인지에 대해 이벤트 플래너 및 관련 스태프와 대화하는 멘탈 모델을 이미 가지고 있습니다.
- 사용자가 이벤트에 관해 물어볼 수 있습니다. 사용자는 질문을 통해 자신이 정확히 원하는 바(예: 일정 정보, 세션 주제, 가는 길 등등)를 빠르게 확인할 수 있습니다.
- 사용자가 멀티태스킹을 해야 합니다(특히 이벤트에 참석할 때). 사용자가 잠시 다른 일을 해야 하거나 뭔가에 시선을 빼앗길 수도 있습니다. 또는 이동할 일이 생길 수도 있습니다.
- 이벤트에 대한 세부 사항을 묻는 것처럼 개인적 궁금증이 아닌 사항을 물어봐야 할 때, 사용자는 대화나 타이핑으로 질문하는 걸 편하게 느낍니다.
사용 사례의 확정
위의 전제로부터 어떻게 다음 단계로 나아갈 수 있을까요? 어떤 소프트웨어 프로젝트에서나 마찬가지로, 우선 요구 사항 수집부터 시작했습니다. 특히 다음과 같은 사용 사례에 집중하고 싶었습니다.
- 이벤트 참석자와 참석하지 못한 사람을 포함한 대부분의 사용자 포괄
- I/O에 관해 사용자가 가장 자주 묻는 질문과 궁금증 해결
- 특히 이벤트 참석자를 위해 빠른 속도 강조
- 이벤트 이전, 도중, 이후에 사용자가 갖는 다양한 목표 존중
이러한 모든 목표에 맞춘 디자인 시도는 엄청나게 도전적인 과제였습니다. 우리는 I/O 이전, 도중, 이후에 여러 사용자 프로필에 걸쳐 다양한 사용 사례에 적합한 단일 솔루션을 만들어야 했습니다. 하지만 개발자를 위해 액션의 구현 소스를 공개하는 것이 제2의 목표였기에, 더 많은 기능을 탑재하려고 높은 품질 기준을 낮추고 싶진 않았습니다. Android IOSched 앱의 전통을 유지하면서 우리의 솔루션이 Actions on Google 개발자를 위한 도구이자 모델이 될 수 있기를 바랐습니다.
사용자가 가장 자주 묻는 질문을 파악하기 위해, 1) I/O ’17 액션에 대해 Dialogflow 분석을 통해 얻은 데이터와 2) 전에 I/O에서 일한 적 있는 Google 직원과 대화를 나누었습니다.
I/O ’17 액션은 기조연설, 행사 장소 등에 대한 몇 가지 기본적인 질문에 답해주었고, 사용자가 관심 영역별로 알맞은 세션을 찾을 수 있게 해주었습니다. 수집한 사용 데이터를 보면, 세션 찾기 기능이 꽤 많이 사용되었고 사용자들이 일단 해당 대화 경로에 들어오면 큰 오류없이 작업을 잘 마무리 하는 것으로 확인되었습니다. 대부분의 사용자는 기조연설이나 사은품 증정에 대해 물었고 여러 가지 발표, I/O Extended 등에 대해 미리 준비된 다른 답변은 찾지 않았습니다. 이를 바탕으로, 우리는 세션을 찾아 더 구체적인 정보를 알아내고 이벤트에 대한 FAQ의 검색 기능을 향상하기 위한 사용자 환경 개선에 초점을 맞추고 싶었습니다.
I/O에서 일한 Google 직원들과 대화를 나눠본 결과, 참석자들이 묻는 질문에는 다음과 같은 4가지 주요 범주가 있는 것으로 나타났습니다.
- 일반적인 길 안내(예: 화장실은 어디죠?)
- 개인적 길 안내(예: 내가 다음으로 참석할 세션은 어디서 열리죠?)
- 이벤트 세부 정보(예: 점심시간은 몇 시예요?)
- 위치별 이벤트 세부 정보(예: 이 방에서 다음에 진행되는 세션은 무엇인가요?)
이러한 조사 결과를 바탕으로 이벤트 현장에서 쉽게 길을 찾고 원하는 세션에 참가할 수 있도록 네비게이션에 대한 지원을 추가하고 싶었습니다. 또한 사용자가 이동 중에도 빠르게 네비게이션에 액세스할 수 있도록 사용자의 일정에도 연결하고 싶었습니다. 이런 기능을 실제로 구현하려면 기능마다 일정 부분 절충해야 할 사항이 있습니다(파트 2에서 자세히 다룰 예정임).
페르소나 만들기
다음으로, 사용자와 상호 작용하는 페르소나 디자인에 초점을 맞췄습니다. 페르소나를 만드는 목적은 사용자가 마치 사람과 대화하고 있다고 여기게끔 하려는 게 아니라, 먼저 학습한 커뮤니케이션 시스템을 활용하여 최선의 대화를 파악하기 위한 것입니다. 특히 다음과 같은 특성에 초점을 맞추었습니다.
- 실용적이고 직접적임
- 기술에 정통함
- 열정적임
- I/O 전문가임
우리는 GDE(Google Developer Expert)가 이러한 특성을 구현한 캐릭터의 훌륭한 예라고 판단했습니다. GDE는 개발자 커뮤니티에서 개방성과 전문성을 갖춘 호기심 많고 창의성이 풍부하며 열정적인 존재입니다. 이 시점에서 우리는 사는 이야기, 동기 부여, 기술적 선호도를 비롯하여, 한 페이지 분량에 걸쳐 가상 사용자의 일대기를 작성하는 실수를 범했습니다. 너무 의욕이 앞섰던 거죠. 애초에 생각했던 페르소나는 대화 내용을 작성할 때 쉽게 마음속에 떠오를 정도로 단순해야 하는데 말이죠. 그래서 그 내용을 짧은 한 단락으로 줄였습니다. 우리가 만든 가상 사용자를 Keeper of I/O-Specific Knowledge라고 불러 게임의 대가와 같은 느낌을 자아내고 싶었습니다. 신규 사용자의 경우 환영 인사의 일부로 이 이름을 들려줍니다. 이름의 첫 글자를 따면 KIOSK가 됩니다. 꽤 그럴듯하지 않습니까?
다음으로 이 가상 사용자에게 생명력을 불어넣어 줄 목소리를 선택해야 했습니다. 음성 오디오 녹음이 사용자 환경 개선에는 이상적인 방법이었겠지만, 문자열의 변동을 고려하면 막상 그렇게 구현할 경우 무척 지루해졌을 것입니다. 대신 Actions on Google 카탈로그에서 사용 가능한 음성을 살펴보았습니다. 사용 가능한 미국 영어용 TTS 음성 중에서 '실용적'이고 '기술에 정통'하며 '직접적인' 속성에 대해 'Female 2'에 최고 점수를 주었습니다.
샘플 대화 만들기
화자(사용자와 가상 사용자)와 대화 주제(사용 사례)를 분명히 정하고 나니 대화 작성을 시작할 수 있었습니다. 이를 통해 코드 표기, 복잡한 흐름도, 인식-문법 문제 등의 복잡한 기술적 처리 과정을 생략하고 음성 및 액션이 주는 대략적인 느낌을 확인하기 위한 실험을 할 수 있습니다. 행사 참가자(Anna)가 현재 I/O에 참석 중인데 그날의 나머지 세션에 대한 정보를 원하는 대화로 시작해봤습니다.
먼저 1) 사용자에게 환영 인사를 건네고, 2) 기대 수준을 조절하고, 3) 사용자가 통제권을 갖도록 하는 방식으로 환영 인사를 작성했습니다. 'Google I/O 18'이라는 이름은 액션이 할 수 있는 일을 제대로 나타내지 못하기 때문에, 이 액션을 '론치패드'로 설명했습니다. 결정적으로, 참석자와 비참석자가 서로 다른 목표(예: 가는 길 파악과 라이브스트림 시청)를 생각하고 있으므로 각 사용자 환경에 맞춰 조정하고 싶었습니다. 그래서 범위를 좁혀가는 질문(이 경우에는 예/아니요 질문)을 던졌습니다. 이때 넓은 범위의 질문(예: 어떤 게 필요하세요?)을 하기 전에 가상 사용자의 명칭(Keeper of I/O-Specific Knowledge)을 활용하는 것 외에도 사용자에게 몇 가지 추천 항목(예: 일정 관리, 할 일 찾기, 길 안내 받기 등)을 제시했습니다. 사용자는 추천 항목 중 하나를 선택하거나 액션이 지원하는 다른 항목(예: 기조연설 또는 세션 찾아보기)으로 바로 갈 수 있었습니다.
이 샘플 대화의 나머지 부분에서 지원하고 싶은 다양한 사용 사례로 사용자를 안내하는 메뉴를 만들었습니다. 사용자가 액션과 대화를 시작할 때 어떤 내용을 물을 수 있을지 자동으로 알지는 못할 것이므로 이는 유용한 기능입니다. 그와 동시에, 사용자에게 너무 많은 옵션을 제시해 혼란스럽게 만들고 싶지 않았으므로, 옵션을 직관적인 범주로 분류하려 했습니다. 예컨대 9가지 옵션을 그냥 나열한 메뉴를 제시하기보다는 다음과 같은 3가지 범주로 분류했습니다.
전문가에게서 배우기
데모
휴식 및 기타
이를 기반으로 각각 다른 사용 사례에 초점을 맞춘 10가지 샘플 대화를 더 만들었습니다.
디자인 구체화
몇몇 샘플 대화를 만든 후, 대화의 상위 레벨 흐름과 로직을 요약하기 시작했습니다. 이런 작업을 수행하는 과정에서, 대화 구조가 다차원이라는 점이 분명해졌습니다. 즉, 대화의 변화는 단지 한두 가지의 사용자 특성이 아니라 다음 세 가지 요소에 종속되어 있다는 점을 깨달았습니다.
- 사용자가 액션의 신규 사용자인지, 아니면 기존 사용자인지 여부
- 현재 세션 날짜가 I/O 이전, 도중 또는 이후인지 여부
- 사용자가 I/O에 참석 중인지 여부
이를 통해 다음과 같은 도식을 도출했습니다.
근본적으로 다음과 같은 사용 사례를 다루었습니다.
- 이벤트에 대한 일반적인 정보 관련 질문(날짜, 위치, 기조연설 등)
- 이벤트에서 할 일 또는 길 찾기(참석자의 경우)
- 일정 찾아보기
- 자신의 일정 찾아보기
일반적인 이벤트 관련 질문은 상당히 간단하게 다룰 수 있습니다. 기조연설, 사은품, 음식 등에 관련된 각 질문에 대해 이벤트와 관련된 날짜를 기준으로 미리 준비된 답변을 내놓았습니다. 각각의 답변이 TTS(텍스트 음성 변환)에서 렌더링되는 것을 청취하고 필요에 따라 SSML(Speech Synthesis Markup Language)을 사용했습니다. 대체로 대화 구문이 더욱 자연스럽게 들리도록 하려고 묵음 구간을 추가함으로써 가상 사용자가 실제 사람이 말할 때처럼 '호흡하느라 잠시 쉬어가며' 말하도록 했습니다.
예를 들어 사용자가 I/O에서 입을 옷에 대해 물어볼 때 다음과 같이 답변하도록 디자인했습니다.
각 프롬프트에 대해 여러 가지 조건을 고려했다는 점에 유의하세요. 또한 사용자가 한 눈에 내용을 파악할 수 있도록 가급적 내용을 압축해서 표현했습니다. 덕분에 다중 모달 대화로 디자인을 확장할 시점이 되었을 때, 음성 프롬프트를 쉽게 재사용할 수 있었습니다.
일정 찾아보기 사용 사례의 경우, I/O ’17 액션용으로 빌드된 흐름을 확장하여 사용자가 세션 시간도 찾아보도록 할 수 있었습니다. 또한 더욱 스마트한 찾아보기 환경을 제공하여 I/O 이전, 도중, 이후에 변화하는 사용자의 요구를 충족시키겠다는 더 어려운 과제에도 도전했습니다. 예를 들어 이벤트가 열리기 전에 사용자에게 모든 옵션을 제시하고 싶을지 모릅니다. 하지만 이벤트 도중에는 당일 진행될 세션만 제시함으로써 사용자가 당일 세션 목록을 모두 확인해야만 다음날의 세션을 찾아볼 수 있도록 하고 싶을 수도 있을 것입니다.
사용자가 어시스턴트와 상호 작용하는 데 사용하는 기기에 화면이 있는지 여부에 따라서도 대화 환경을 적절히 조정했습니다. 사용자가 Google Home과 대화하고 있다면 사용자에게 지나치게 많은 옵션을 제시하지 않도록 대화 프롬프트에 (총 17개 중) 임의로 6개 항목만 표시합니다. 사용자가 휴대폰을 사용하고 있다면 화면을 활용해 17개 항목을 전부 사전순으로 표시합니다. 다양한 프롬프트를 활용하고 표준어 대신 준말과 같이 좀 더 자연스러운 음성을 사용한다는 점에도 주목해 보세요. 디자인 단계에서는 한껏 큰 야심을 품기도 했지만, 구현 단계에서는 일정 부분 절충하고 타협해야 했습니다. 하지만 어떤 상황에서도 사용자가 충분히 납득할 수 있는 수준으로 만들었습니다.
길 안내를 받고 자신의 일정을 찾아보는 사용 사례는 주로 구현에 종속되었으므로, 이 단계에서는 밑그림을 그리기 어려웠습니다. Android IOSched 앱(Android에서 사용자를 위해 공개하기로 결정한 경우)과 스케줄링 백엔드에 의존적인 부분도 있었습니다. 어시스턴트용 Google 로그인이 프리뷰 버전으로 제공되고 있었지만, 이 액션에는 사용할 수 없었습니다. 이런 요소가 더 명확해질 때까지는 대화에서 이 부분을 열린 상태로 두었습니다.
골격이 제법 그럴듯하게 갖춰졌다는 생각이 들자, 나머지 세부적인 부분을 디자인할 때라고 판단했습니다. 즉, 뭔가 잘못될 수 있는 사례를 최대한 많이 다루어야 하는 시점이었다는 뜻입니다. 아마 상상하실 수 있듯이, 문제가 무척 복잡해졌습니다. 여러 가지 논리적 결정 지점, 오류 및 거부 처리, 메뉴 내부의 메뉴 등등 복잡한 디자인 문제가 남아 있습니다. 알 수 없는 답변(또는 대체 답변), 거부, 허용, 시스템 장애 등을 포함한 모든 프롬프트에 대한 모든 사용자 반응을 고려했습니다. 뿐만 아니라, 스마트 스피커부터 휴대폰까지 각각의 어시스턴트 표면에 알맞게 각각의 대화 경로와 프롬프트를 맞춤 제작해야 했습니다. 우리는 사용자가 전에 경험한 적이 있는 것과 유사한 결정 지점에 와 있음을 알아차릴 경우, 주어진 대화 상태로 '재진입'하기 위한 특정 프롬프트를 만들었습니다. 한 올 한 올 빈틈없이 뜨개질하듯이, 이 모든 과정을 거치며 액션을 만들어야 한다는 점을 기억해 주세요.
액션 전체에 걸쳐 몇 가지 똑같은 패턴을 활용할 수 있었습니다. 예를 들어 오류 처리 전략은 대부분 대화 내내 똑같이 유지했습니다. 보통은 다음과 같이 마지막으로 물어본 질문의 맥락을 기준으로 조정된 변형이었습니다.
TTS에서 알맞게 렌더링되도록 하기 위해 '4 0 4'를 세 개의 숫자로 발음했다는 점에 주목해 주세요. 실용적이고도 직접적인 톤을 유지하면서도 기술과 관련해서는 가벼운 농담을 포함하여, 우리는 오류 프롬프트를 작성할 때도 계속 페르소나를 염두에 두고 작성했습니다.
이때 야심 차고 종합적인 디자인을 계획했습니다. 기술적 종속성을 고려하여 약간의 공간은 남겨두고 의도한 모든 사용 사례와 가능한 한 많은 극단적 사례를 포괄했습니다. 문제는 그걸 실제로 빌드해야 했다는 거죠…
이 게시물의 두 번째 부분도 읽어보시기 바랍니다. 위에서 설명한 모든 것을 어떻게 구현했는지 설명한 글입니다.
