2019년 화두가 된 대화형 UI, 챗봇 설계는 뭐가 다른가

2019년 들어 여기저기서 "대화형 UI"라는 단어가 부쩍 많이 들립니다.
저희 회사도 신규 서비스 기획 회의 때마다 "이건 챗봇으로 만들면 어떨까요"라는 이야기가 한 번씩은 꼭 나와요.
그런데 실제로 대화형 UI를 기획해보면, 화면 기반 UI를 설계할 때와는 완전히 다른 감각이 필요하다는 걸 느낍니다.
이번 글에서는 화면 UI 기획자가 대화형 UI를 처음 맡을 때 반드시 부딪히는 차이점들을 정리해봤습니다.

 

화면은 공간이고, 대화는 시간이다

 

화면 기반 UI를 기획할 때는 한 화면 안에 정보를 어떻게 배치할지가 핵심입니다.
버튼 위치, 정보 계층, 시선의 흐름을 신경 쓰죠.
그런데 대화형 UI는 이 모든 걸 시간 순서로 풀어야 합니다.
한 화면에 다 보여줄 수 있던 정보를 대화로 풀면, 사용자가 몇 번의 턴을 거쳐야 필요한 정보에 도달할 수 있는지가 관건이 됩니다.

저희 팀에서 처음 만든 예약 챗봇이 이 문제로 크게 고생했어요.
기존 화면에서는 날짜, 인원, 옵션을 한 화면에서 동시에 선택할 수 있었는데, 챗봇으로 옮기면서 "날짜를 먼저 물어볼지, 인원을 먼저 물어볼지"부터 팀 내에서 의견이 갈렸습니다.
결국 사용자 인터뷰를 다시 돌려서, 사람들이 예약을 생각할 때 "언제 갈지"를 가장 먼저 떠올린다는 걸 확인하고 순서를 정했어요.
화면에서는 순서가 크게 중요하지 않았던 정보인데, 대화에서는 순서 자체가 UX를 좌우한다는 걸 이때 배웠습니다.

 

 

"모든 경우의 수"를 상상해야 한다

 

화면 UI는 사용자가 누를 수 있는 버튼이 정해져 있어서 예외 케이스가 제한적입니다.
그런데 대화형 UI, 특히 자유 입력을 허용하는 챗봇은 사용자가 무엇을 입력할지 예측하기가 훨씬 어려워요.
저희가 초기에 만든 FAQ 챗봇은 "환불"이라는 단어 하나로만 의도를 분류했는데, 실제 사용자들은 "환불", "취소하고 돈 돌려받고 싶어요", "결제 취소는 어떻게 해요" 등 표현이 제각각이었습니다.
로그를 뽑아보니 같은 의도인데 표현이 다른 문장이 40가지 넘게 나왔어요.

그래서 대화형 UI를 기획할 때는 화면 기획에서보다 훨씬 더 많은 "표현 변형"을 미리 준비해야 합니다.
저는 이후로 신규 의도를 설계할 때 최소 스무 개 이상의 예상 표현 문장을 미리 뽑아두고, 개발팀과 NLU 담당자에게 넘기는 걸 규칙으로 만들었어요.
이렇게 해도 실제 런칭 후에는 예상 못 한 표현이 계속 나오지만, 최소한의 커버리지는 확보할 수 있었습니다.

 

 

성공/실패의 기준이 다르다

 

화면 UI는 클릭률, 전환율처럼 명확한 지표로 성공을 판단하기 쉽습니다.
대화형 UI는 "대화가 잘 끝났는가"를 정의하는 것부터 애매해요.
사용자가 원하는 답을 얻고 대화를 끝냈는지, 아니면 답을 못 찾고 그냥 나가버렸는지 구분하기가 쉽지 않습니다.

저희는 이 문제를 풀기 위해 대화 종료 시점마다 짧은 만족도 확인(엄지척 버튼)을 붙였는데, 응답률이 8%도 안 나와서 데이터로 쓰기 어려웠어요.
결국 명시적 피드백보다 행동 데이터를 더 신뢰하게 됐습니다.
대화가 3턴 이내에 종료되고 이후 같은 주제로 재문의가 없으면 "성공"으로 간주하는 식으로, 간접 지표를 조합해서 성공 여부를 추정하는 방식으로 바꿨어요.
완벽하진 않지만, 사용자에게 매번 피드백을 요구하지 않으면서도 개선 방향을 잡을 수 있는 최소한의 기준이 됐습니다.

 

 

말투와 페르소나도 설계 대상이다

 

화면 UI에서는 버튼 문구 하나 정도로 톤을 신경 쓰지만, 대화형 UI는 챗봇의 "말투" 자체가 브랜드 경험이 됩니다.
저희 프로젝트 초반에는 개발자, 디자이너, 기획자가 각자 다른 말투로 응답 문구를 작성해서, 같은 챗봇인데 어떤 대답은 딱딱하고 어떤 대답은 지나치게 친근한 문제가 있었어요.
이후로는 페르소나 가이드 문서를 따로 만들어서 "존댓말을 쓸지, 이모지를 쓸지, 사용자를 어떻게 부를지"를 미리 정의하고, 모든 응답 문구를 이 가이드에 맞춰 리뷰하는 절차를 추가했습니다.

 

 

설계 문서의 형태도 달라야 한다

 

화면 기획서는 와이어프레임과 화면 흐름도로 충분했지만, 대화형 UI는 이걸로는 부족합니다.
저는 결국 대화 흐름을 트리 구조의 시나리오 문서로 다시 그리기 시작했어요.
사용자 발화, 챗봇 응답, 분기 조건, 폴백 처리까지 한 장의 표로 정리하니 개발팀과의 커뮤니케이션이 훨씬 수월해졌습니다.
처음엔 이 문서를 만드는 데 화면 기획서보다 시간이 두 배는 더 걸렸는데, 나중에 시나리오가 30개, 50개로 늘어날수록 이 표 없이는 관리가 불가능했겠다는 생각이 들었어요.

대화형 UI는 화면 UI의 연장선이 아니라 완전히 다른 설계 감각을 요구하는 영역이라는 걸 이번 프로젝트를 거치며 절실히 느꼈습니다.

2019년 한 해 동안 이 감각을 익히는 데 꽤 많은 시행착오를 겪었는데, 내년에는 이 경험을 바탕으로 좀 더 체계적인 설계 템플릿을 만들어보고 싶습니다.