야메의 이상(理想)한 생각과 공감(共感)

오늘의 어플기획 십계명은 바로 '사용자의 시간을 예측하라!!' 입니다.  사용자의 시간을 예측하라니... 다소 뜬금없는 이야기 일 수 있는데.. 여기서 이야기하고자 하는 시간의 예측이란, 하루나 일주일.. 혹은 한달 간 사용자가 스마트폰을 사용하며 우리가 개발한 어플리케이션을 하루에 몇 분이나 이용할 것인가 혹은, 일주일에 몇 회나 이용하게 할 것인가? 와 같이 사용자의 이용 사이클을 반영한 포지션 설정을 의미 합니다.


그런데 이 같은 포지션 설정을 왜 해야 할까요? 

이는 바로.. 스마트폰 유저의 일반적인 이용 사이클이 생각보다 폭넓지 않기 때문인데.. 이러한 사이클은 멀리 생각할 필요도 없이, 스마트폰을 사용하시는 여러분들의 케이스를 살펴보면 바로 답이 나오는데 이 시점에서 이런 질문을 한 번 던져볼까 합니다.

 

유료이던 무료이던 사용자가 어플리케이션을 다운로드 받는 과정이나 전체 다운로드 횟수도 물론 중요하지만 사용자가 다운받은 수 많은 어플 중 여러분들이 개발한 어플이 사용자의 스마트폰에서 이용되는 비중이 몇 퍼센트 인가가 어찌보면 더 중요한 요소일 수도 있습니다. 특히나 다운로드 이후 사용자의 어플리케이션 이용이 매출이나 트래픽에 직, 간접적으로 영향을 미치는 서비스라 한다면 보다 더 중요한 이슈로 분류되어야 하며.. 충분한 사용자 패턴 분석을 통해 적절한 기획과 개발범위, 마케팅 계획이 수립되어야 합니다.

여기서.. 사용자의 이용패턴을 예측하기 위해서는 이용타깃이라 생각되는 사용자들의 평균적인 이용사이클을 리서치 등의 도구를 활용해서 조사할 필요성이 있는데.. 작게는 성별이나 연령대부터 넓게는 지역과 학력까지 세분화된 분류로 나누어 이들의 평균 사이클. 즉 스마트폰 이용시간이나 자주 사용하는 어플리케이션 등을 조사하면, 여러분들이 만들어야 할 어플리케이션의 큰 틀을 정의 할 수 있으며, 이 방향을 근간으로 어플리케이션을 기획할 경우, 그만큼 시행착오를 줄일 수 있게 됩니다.



이러한 사용패턴에 대한 리서칭이 완료된 이후 세부적인 어플리케이션 기획을 위해, 다음 두 가지의 가정을 수립해야 하는데, 첫번째로 사용자들은 우리 어플리케이션을 얼마나 이용할 것인가? 입니다.  이는 사용자들의 일상적인 생활패턴에 기인하는데, 예를 들어 영화를 예매할 수 있는 어플리케이션을 개발한다고 가정했을 때, 일반적인 사용자들의 평균 영화관람 횟수를 고민해봐야 하며 이러한 고민 결과, 대략 월 한 번 정도 영화를 관람하는 것을 알 수 있는데, 이에 따라 어플리케이션을 개발하게 되면, 사용자들은 영화를 예매하기 위해 월 1회 정도 어플리케이션을 이용하게 될 겁니다.  

물론 이러한 가정은, 사용자들이 순수하게 여러분이 개발한 어플리케이션만을 사용한다고 봤을 때의 이야기고.. 실상, PC에서 예매하는 비율과 다른 영화 예매 어플리케이션을 이용할 수 있다는 경우의 수를 뺀 단순 수치이기 때문에 웹 상에서의 예매자나, 타 어플리케이션 상에서의 예매자를 우리 어플리케이션으로 흡수할 수 있는 방법을 고민하여 하며, 이는 곧 사용자에게 강하게 어필할 수 있는 우리 서비스 만의 차별화 요소를 도출해 내야 합니다.

여기서 사용자에게 어필할 수 있는 요소를 뽑아보면,

1. 혁신적이고 직관적인 유저인터페이스 (Innovative and intuitive User inteface)
2. 차별화 서비스나 컨텐츠 구성 (Differentiated Service or contents)
3. 중독성있는 이벤트 요소 (Events addictive)

대략, 이 세 가지 정도가 스마트폰 어플리케이션 이용 유저들의 시선을 확 잡아 끌 수 있는 요소라 할 수 있는데, 첫번째 혁신적이고 직관적인 유저인터페이스는 기존에 사용자 경험성을 기반으로 한 정형화 된 어플리케이션 구조가 아닌, 매우 직관적이고 눈에 확 띌 수 있는 것을 의미하는데, 그래픽 인터페이스에 대한 폭넓고 심도깊은 지식을 갖지 못한 기획자가 시도하기에는 다소 무리가 따를 수 있으며 어설프게 시도했다가는 오히려 호평이 아닌 반감만 사게 될 가능성이 높습니다.


[그림. 2] GUI 전문에이전시 '아메바 디자인' (http://www.amoeba.co.kr)

때문에 이를 수행하기 위해서는.. 전문적인 GUI 설계 에이전시를 통해 인터페이스를 구축할 필요가 있으며, 다소간의 비용이 소요된다고 하더라도... 잘 만들어진 인터페이스는 유저의 손길을 이끌 수 있는 첫 번째 창구라는 점에서 그 가치는 충분하다고 생각합니다. 

두 번째 사용자 어필요소는 차별화된 서비스와 컨텐츠의 구성입니다..  여기서 차별화된 서비스와 컨텐츠는 철저히 어플리케이션을 이용하는 사용자의 시간을 우리 것으로 만들고자 하는데에 포커스가 맞춰져야 합니다.  이는 앞서 예로 들었던 영화예매 어플리케이션으로 설명할 수 있는데... 한 달에 한 번 정도 이용하게 하는 어플리케이션은 다른 경쟁사에게 쉽게 자리를 내줄 수도 있고, 또 잊혀지기도 쉽습니다. 

이를 보완하고 기회로 삼기 위해서는 사용자의 이용시간을 한 달에 한 번에서 일주일에 한 번 혹은 이틀에 한 번 수준으로 간격을 줄일 필요가 있으며, 이는 기존의 영화정보를 보고 영화를 예매하는데 중점적인 포커스를 두었던 기존의 서비스 구조에서 다른 서비스와의 융합을 통해, 해결할 수 있습니다.

예를 들어.. 이성과의 미팅서비스와 영화예매를 조합한 "우리 같이 영화봐요" 와 같은 서비스를 추가해보는 건 어떨까요. 아니면, 페이스북이나 트위터와 같은 SNS와 영화예매를 조합해서 실시간으로 영화평점을 매기고, 여기에 게임적인 요소를 추가해 보는 건 어떨까요.. 이러한 시도들은 직접적으로 영화예매 매출을 늘릴 수 있는 것과 함께 어플리케이션에 대한 사용자 관심도를 높이고.. 많이 사용하게 만듦으로써 어플리케이션의 순수 이용자를 높일 수 있는 중요한 수단이 될 수 있습니다. 


[그림. 3] 한 때 장안의 이슈였던 WeRule 게임 화면.

마지막 세번째 어필요소인 중독성 있는 이벤트요소는 사용자들로 하여금 중독적인 요소를 가미함으로써, 무의식적인 참여를 유도하는 장치인데, 한 때 엄청난 이슈가 되었던 소셜 게임인 위룰(We Rule)과 같이 씨앗을 뿌리고 일정시간이 지나면 과일이나 채소를 수확하고 시간이 오버되면 시들게 되는 장치를 만들어 둠으로써.. 학습효과를 바탕으로 하는 중독적인 요소나 렉션(Raction)이라는 이벤트 어플리케이션과 같이, 매일 오후 한 시에 단순히 스마트폰을 미친 듯이 흔들어주는 것 만으로도 이벤트에 참가할 수 있는.. 단순함에 기인한 중독적인 요소를 갖출 필요가 있습니다.

지금까지 사용자의 시간을 예측하고, 그 시간을 우리 것으로 만들기 위한 요소가 필요하다는 내용을 말씀 드렸는데요, 이러한 요소들을 바탕으로 사용자들에게 주목받고 이슈가 될 수 있는 어플리케이션을 만들어보시기 바랍니다.. 다음 번 어플기획 십계명에서는 어플리케이션을 만들기 이전에 선행되어야 할 벤치마킹에 대해 자세히 알아보도록 하겠습니다.


2011/01/25 - [어플기획 십계명] 웹이냐.. 앱이냐.. 그것이 문제로다..
2010/03/05 - [어플기획 십계명] 환경을 이해하라!! 1-2
2010/03/02 - [어플기획 십계명] 환경을 이해하라!! 1-1

어떤 부분에서나 테스트는 최종 관문에서 넘어야 할 마지막 고비가 되곤 하는데, 아이폰 어플의 개발에서도 테스트는 실제 서비스가 가능한가를 따지는 마지막 점검과정 입니다. 그런데 막상 테스트를 하려고해도 어떤 테스트를 해야 할지 막막하거나, 단순한 디자인적인 테스트에 그치는 경우가 대부분 입니다.

전문적으로 소프트웨어 기획이나 개발을 경험하신 분이라면, 어플리케이션을 테스트하기 위한 접근 방법을 어느정도 숙지하고 계시겠지만, 안타깝게도 이를 경험해보지 못하신 분들이 더 많으므로 테스트 진행을 위한 순서와 방법을 정리해보도록 하겠습니다.

우선 테스트의 순서는, 크리티컬한 문제를 야기할 수 있는 순서에 따라 진행됩니다.  즉... 음식을 만들 때 모양이나 색이 맛깔스러워 보이지 않는다고해도 음식을 파는데에는 아무런 문제가 없습니다. 맛으로 승부하면 되니까요.  하지만, 음식의 맛 자체가 없거나 음식을 먹고 식중독에 걸릴만큼 상해 있다면 이는 환불이나 형사 고발될 수 있는 매우 크리티컬한 요소이기 때문에, 음식을 하면 우선 맛부터 봐야 합니다.

어플리케이션 개발에도 이와 다를 바가 없는데 내용을 좀 더 체계적으로 정리해보면 대략 아래의 그림과 같은 순서도가 생기게 됩니다.


[그림. 1] 어플리케이션 테스트의 순서도



위의 테스트순서에서 프로세스 테스트나 사용성테스트는 순서가 바뀌거나 병행될 수 있으나 스트레스 테스트는 가장 우선적으로 진행되어야 하며 가장 많은 시간을 소요해야 하는 테스트가 되겠습니다.. 그럼 각 테스트 별 방법 좀 더 구체적으로 정리해 보도록 하겠습니다.  


■ 스트레스 테스트 (Stress Test)

사람도 스트레스를 받게 되면 폭발하게 마련이고 기계 역시도 다를 바 없습니다. 우리가 보통 웹을 만들게 될 경우, 여러가지 테스트를 하게 되는데 이 스트레스 테스트를 간과하고 넘어가는 경우가 있고, 그리 중요한 테스트 이슈는 아니라고 보는 경우들도 있지만, 어플리케이션의 경우는 모든 테스트 요소 중에 가장 중요한 포지션을 차지하고 있는 테스트 이슈가 바로 스트레스 테스트 이며, 이 테스트가 선행되지 않았거나 나중에 발견 되었을 경우, 어플 릴리즈가 늦춰지게 되거나 최악의 경우 어플을 다시 만들어야 하는 경우들도 있습니다.



어플리케이션의 스트레스 테스트를 하게 되는 가장 큰 이유는 바로, 사용자가 어플을 이용하던 도중 불규칙하게 어플이 튕겨져 나가는 경우를 최소화하는데 그 목적이 있습니다.

만일 일반사용자의 입장에서 잘 사용하던 어플리케이션이 갑자기 원인을 알 수 없는 이유로 인해 꺼진다거나 하면, 매우 당혹스럽거나 짜증이 날 수도 있을 겁니다.  뭐.. 한 두 번 정도야 너그러운 마음으로 이해하고 넘어갈 수도 있겠지만.. 그런 상황이 반복되면 사용자는 더 이상 그 어플리케이션을 이용하지 않을 것이며, 그와 유사한 다른 어플을 사용하게 됩니다. (아이폰 어플기획의 십계명 - 환경을 이해하라!! 1-2 편 참조.)

이렇게 크리티컬한 문제를 만들지 않기 위해서는, 개발 초기 단계부터 가장 많은 시간을 할애하여 테스트를 진행해야 하며, 개발자와의 적극적인 코웍을 통해 이를 해결해야 하는데 참고로 스트레스 테스트를 통해 발생하는 대부분의 문제는 메모리 관리 및 충돌로 인해 발생하는 만큼, 어떠한 단계에서 문제가 발생하는지를 구체적으로 개발자에게 전달해야 해결이 가능합니다.  그 예시로...
 
01. 상품 터치.
02. 상세페이지 이동.
03. 상품정보 로딩 중 back 버튼 터치.
04. 다시 동일 상품 터치.
05. 이 과정을 3회 반복하면 어플리케이션이 꺼짐.

이렇게 구체적인 정보를 개발자에게 제공함으로써, 개발 소스 중 어떤부분이 대략적인 문제를 가지고 있는 지 파악할 수가 있게 되는데, 소스의 수정을 통해 해당오류가 해결된다고 해도 그 수정으로 인해 또 다른 오류가 발생할 수도 있기 때문에, 스트레스 테스트는 개선 이슈가 발생했을 때 지속적으로 진행하는 것이 중요합니다.


■ 프로세스 테스트 (Process Test)

프로세스 테스트란, 어플을 사용하는 A 부터 Z까지의 과정을 점검하는 테스트 입니다.  즉, 가상으로 어플리케이션의 이용과정을 체크하는 것인데, 사전에 체크리스트 혹은 테스트 리스트를 만들어, 이를 기반으로 테스트를 진행하게 되는데, 실제 YES24 어플을 개발할 당시의 사례를 보시면 이해가 빠르실 겁니다.

[테스트 분류] 결제 > 휴대폰 결제
[테스트 범위] 카트와 휴대폰 결제를 통해 완료 체크 및 주문조회와의 연동 체크 

01. 투데이 페이지에서 오늘의 책을 터치.
02. 상세페이지에서 카트에 담기 버튼 터치.
03. 로그인 페이지로 이동.
04. 로그인 완료.
05. 카트 페이지로 이동.
06. 주문하기 버튼 터치.
07. 주문정보 입력 웹 페이지로 이동.
08. 주문정보 입력 후, 결제하기 버튼 터치.
09. 결제정보 웹 페이지로 이동.
10. YES24 포인트 사용 후, 휴대폰 결제 방식 선택 후, 결제하기 버튼 터치.
11. 휴대폰 결제 진행.
12. 결제완료 후, 카트로 이동해, 결제된 상품이 삭제되었는지 체크.
13. 주문조회 메뉴에서 해당 상품의 결제정보 체크.
14. 테스트 완료.

위의 내용과 같이.. 하나의 정형화 된 테스트를 프로세스 테스트라 하며 이 테스트를 통해 테스트 중 어색하거나 불필요한 과정을 수정하기도 하고, 과정 내에서 발생할 수 있는 버그들을 체크하게 됩니다. 


[그림. 2] 엄청난 버그 리스트 들... (매 회 테스트 당 60여 개씩은 쏟아지더군요..)



프로세스 테스트를 하기 위해서는 사전에 정리된 테스트 시트가 필요 합니다.  즉, 테스트 시트를 통해 각 과정들을 순서대로 정리하고 그 순서에 맞게 동작하는지를 판단하게 되며, 이 과정을 통해 기획된 프로세스의 정상여부를 판단할 수 있겠습니다.

이때 작성되는 테스트시트는 향후 최종 사용자 테스트에서도 사용될 수 있으므로, 모든 프로세스 내용을 시트에 포함될 수 있도록 정리하시면 되겠습니다.


■ 사용성/디자인 테스트 (UX/Design Test)

사용성 및 디자인테스트는 프로세스 테스트와 병행되기도 하는데 기획과정에서 놓쳤던 편의성이나 화면제어 및 입력방식을 실제 사용하기에 가장 적합한 UI나 UX인지를 검증하게 되는 테스트라고 할 수 있습니다.  이 테스트를 통해 버튼의 위치나 일관성을 맞추게 되는데 이 테스트 시점에서부터 해당 어플이 구동될 플랫폼에 경험이 많은 사용자가 같이 코웍(Co-work)하여 테스트해야 합니다.  

경험이 많은 사용자는 어플을 이용하는 과정에서 문제점을 발견해내기 보단 이용과정에서의 어색한 점이나 개선의 여지가 있는 인터페이스를 잡아내게 되고, 이 과정을 통해 보다 자연스러운 인터페이스나, 디자인의 구성이 가능해 집니다.

단 사용성 테스트는 프로세스 테스트 과정에서 병행되어 진행될 수 있으며 보다 명확한 테스트를 위해 대상이 되는 테스터에게 무엇을 테스트 해야 하는지를 정확히 집어주어야 의도한 결과를 얻어낼 수 있습니다.


■ 최종 사용자 테스트 (Final User Test) 

위의 세 가지 테스트가 완료되어.. 일정 퍼센트 이상의 만족도(보통은 95%를 기준으로 합니다.)를 확보한다면 릴리즈 시점 이전에 일반 사용자의 테스트를 진행해야 합니다. 

일반 사용자 테스트는 특정한 테스트 미션을 주지 않고 각각 자신의 이용패턴에 따라 자유로이 이용하게 하며 이를 통해, 일반 사용자의 이용패턴을 파악하고 기능적인 개선니즈가 발생할 경우 향후 업그레이드 버전 시에 패턴의 개선이나 기능 업그레이드에 참고하시면 되겠습니다. 


지금까지 총 네 가지에 대한 테스트 과정을 정리해 보았는데.. 상황에 따라서 한 두 가지 정도는 생략되고 진행되고 진행되기도 합니다만, 가급적 위의 네 가지 테스트 과정을 준수하시어, 보다 완성도 있는 어플리케이션을 개발하시기 바랍니다.