골리앗에게 이기는 싸움을 하려면 게임의 룰을 꾸준히 바꿔야 합니다.
지난달에 지인의 부탁으로 국내 스타트업 기업의 베타프로그램에 잠시 참여해서 의견을 준 경험이 있었습니다.
프로덕트 아이디어에 대한 설명을 듣고 실제 베타테스트에 참여한 날, 단 20여 분 만에 10개 이상의 이슈가 발견되었고, 그 이슈 중에는 도저히 바깥에 공개하면 안 될 정도의 심각한 이슈가 많았습니다. 도저히 베타라고 생각할 수 있는 품질이 아니었고, 이슈를 에스컬레이션할 통로도 없었기에 그냥 나름대로 정리해서 주었는데 그것이 진행되는 과정도 투명하지 않고, 모든 것이 미흡하다고 느꼈습니다.
지인을 통해서 왜 이렇게 된 상황인가에 대해 물었더니 답은 아주 단순하게 “스타트업이라 인원도, 비용도, 시간도 다 부족해서”라고 합니다. 이해가 안 되는 것은 아니지만, 스타트업이라는 이유만으로 ‘품질 Quality’를 환경의 ‘부족’과 연결하는 것은 부적절하다고 생각합니다. 그래서 제가 몇 년 전부터 꾸준히 진행해 오고 있는 ‘게릴라 테스트‘의 장점에 대해 이야기해 보는 것이 좋겠다는 생각이 들었습니다.
0. 들어가며
80년대와 90년대 많은 남성이 열광적으로 좋아했던 지극히 통속적인 할리우드 영화가 있었습니다. 실베스터 스탤론이 주연을 했던 ‘람보’ 시리즈와 아널드 슈워제네거가 주연한 ‘코만도’라는 영화였지요. 거의 단독으로 일개 부대 정도는 거뜬히 해치우는 슈퍼 파워를 보여줬는데, 그 통쾌함에 열광했었죠. 사실 그런 전투 상황은 지금 생각하면 참으로 황당무계했던 것 같습니다.
여하튼 그때 그 주인공들이 사용했던 전법은 모두 우리가 잘 아는 ‘게릴라 전법’ 입니다. 상대적으로 화력과 병력이 열세인 소규모 비정규군이 변칙적인 전투 방법으로 상대의 허를 찌르는 전투 방법으로 정의할 수 있습니다. 게릴라 전법은 단순히 허를 찌를 뿐 아니라 그 효과에 따라 치명상을 입힐 수도, 전세를 바꿀 수도 있는 전투 방법입니다. 하지만 정정당당한 페어플레이를 강조하는 우리 사회에서 ‘게릴라’라는 용어는 좋은 뜻보다는 부정적인 의미로 많이 사용됩니다.
요즘의 웹 애플리케이션 프로덕트/서비스나 모바일 프로젝트를 진행할 때 실 개발 작업이 들어가기 전에 사용자 리서치와 사용자 편의성(Usability) 혹은 사용자 경험(User Experience) 테스트에 집중해야 한다는 사실은 거의 필수 사항입니다. 사용자 편의성과 UX 테스트를 수행하는 방법은 많지만 대부분의 방법은 리소스 집약적이고 시간이 많이 소요되므로, 즉 전체 비용(time, money, effort)이 많이 들기에 실제 개발 작업 중의 테스트를 제외하고는 프로젝트 초기의 프로토타입에 대한 테스트는 중단하거나 아예 무시하기 일쑤입니다.
하지만 지금은 아주 운이 좋게도 다윗이 골리앗을 이길 수 있고, 람보가 일개 부대를 상대할 수도 있게 스타트업이 기존 플레이어들에게 도전장을 내밀 수 있게 하는 사용자 경험을 개선하는 쉬운 기술이 있습니다. 프로덕트/서비스를 개발하는 팀은 저렴한 비용과 빠른 속도로 그들이 프로토타입에 설정한 중요한 가정을 검증(혹은 무효화)할 수 있습니다. 그 방법을 게릴라 테스트라고 합니다.
오늘의 글에서는 게릴라 테스트는 무엇이고 어떻게 진행하는지를 이야기해 볼까 합니다. 프로덕트/서비스가 가진 디자인과 기술의 약점을 빨리 파악하거나 최소화하는 방법을 배우고 이후의 리서치와 테스트 계획을 개선합니다. 먼저 게릴라 테스트가 무엇인지 이야기해 보겠습니다.
1. 게릴라 테스트란?
게릴라 테스트는 사용자 편의성과 경험과 관련해서 알고 싶은 질문에 빠르게 답을 얻을 수 있도록 하는, 저비용이 소요되는 테스트 방법입니다. 이 방법은 사무실이나 다른 갇힌 공간으로부터 나가서, 짧지만 귀한 시간 동안 여러분이 현재 계획하고 있는 프로덕트/서비스의 잠재적인 미래 사용자들과 만나게 해줍니다.
게릴라 테스트는 여러 면에서 전담 테스터를 내부에 두고 테스트플랜, 액션, 피드백하는 심화 테스트와는 다릅니다. 심화 테스트의 목적은 미묘한 통찰력과 세심한 개선점을 발견하기 위함인데 이것은 시간, 노력 그리고 스타트업에는 매우 치명적인 재정적 부담이 많이 듭니다. 게릴라 테스트는 절대로 심화 테스트를 대체할 수는 없습니다. 즉 정규군의 화력과는 비교가 안 된다는 뜻입니다. 하지만 준비만 철저히 한다면 비용 대비 고효율의 효과를 경험할 수 있습니다.
아래 그림의 비용과 학습 시간에 따른 적절한 테스트 방법 표를 보십시오. 비용의 부담이 덜하다면, 심화 사용자 편의성 테스트(Usability Testing)를 하는 것이 맞을 텐데, 스타트업 사정은 그렇지 않습니다.
기본적으로 게릴라 테스트는 커피숍과 같은 다른 공공장소에 가서 불특정 다수의 사람에게 여러분이 디자인하고 개발 계획 중인 프로토타입에 대한 간단한 테스트와 피드백/의견을 구하는 행동을 의미합니다. 실제 사용자 피드백을 받을 수 있으면서도 저렴한 비용이 소모되는 간단한 테스트입니다. 간단한 테스트이지만 목표는 매우 명확합니다. 빠르게 장애나 개선 사항을 찾아서 수정하는 것입니다.
1) 특성
- 테스트 참가자는 채용되는 것이 아닌, 과정을 진행하는 디자이너나 리서쳐가 직접 물색합니다. 혹은 테스트 참가를 요청하는 표시를 하고 참가자를 기다리기도 합니다.
- 일반적으로 세션은 10~15분으로 짧게 진행되고, 테스트하고자 하는 특정 태스크를 중심으로 구성됩니다.
- 테스트 결과물은 양보다는 질을 추구합니다. 이 테스트는 타깃 대상에게 얼마나 효율적으로 동작을 하는지 또는 특정 기능이 예상대로 작동하는지 여부를 신속하게 검증하는 데 큰 도움이 됩니다.
- 게릴라 테스트에 적합한 사람은 지금 그 장소에서 바로 이용할 수 있는 사람입니다. 이 특성은 게릴라 테스팅을 극도로 간결(lean)하고 빠르게(agile) 만듭니다. 즉 군더더기 없고, 두꺼운 보고서가 필요 없습니다. 몇 시간이면 중요한 인사이트를 얻을 수 있습니다.
2) 게릴라 테스팅이 적합한 경우
- 프로덕트/서비스 디자인의 라이프사이클 초기 즉 아래 그림과 같이 아이디어(ideate)를 모아 프로토타입(prototype)을 만들고 결정(validate)을 하는 시기에 중요한 사용 편의성 문제를 찾아내고자 할 때 유용합니다. 그러나 게릴라 테스트는 모든 단계에서 사용 가능한 테크닉입니다.
- 게릴라 테스트는 디자인 스프린트 동안 ‘만약 이런 사용자라면…’, ‘이런 상황에 처했을 때는…’ 등의 가설과 가정을 검증하고 검증 체크 포인트를 생성하는 쉬운 방법이 될 수 있습니다.
- 테스트 시나리오가 특정 사전 지식이 필요하지 않은 평균 사용자의 디지털 지식 범위에 있는 경우에 효율적입니다.
- 경쟁 프로덕트/서비스가 이미 충분히 노출되어 있어서 게릴라 테스터에게 함축된 설명이 짧은 시간에 가능한 경우(물론 이 경우엔 차이점과 구별점을 반드시 강조해야 합니다)
3) 진행 방법
A. 테스트 사전 작업
가. 검증할 태스크 리스트 만들기
예를 들어서 국민 메신저 ‘카카오톡’ 출시 전에 게릴라 테스트를 준비한다고 가정하고 검증할 태스크를 다음과 같이 설정해 보았습니다.
- 사용자 계정 만들기
- 친구 추가하기
- 프로필 사진 바꾸기
- 그룹 톡 하기
- 영상 통화 하기
이것들을 자신이 해보는 것이 무엇보다 중요합니다. 그래야 어느 정도의 시간과 노력이 드는지, 실제 게릴라 사용자 테스트 후에 측정해 볼 수 있습니다. 게릴라 테스트에서 중요한 사실은 ‘end-to-end’ 테스트는 하지 않는다는 것입니다. 즉 계정을 만들어 프로필을 등록하고, 메시지를 보내고 받고 영상 통화까지 해보는 이런 전체 시나리오는 사용자도 부담스러울 뿐더러 정보를 전달하거나 분석하기도 어렵습니다.
나. 태스크의 우선순위 정하기
위에서 만든 태스크 리스트의 우선순위 점수를 부여해 봅니다. 예를 들어
- 앱/서비스를 이용할 시에 매번 사용하는 기능에는 5점
- 앱/서비스를 이용할 시 매번은 아니지만 정기적 혹은 자주 사용하는 경우는 3점
- 어떤 특별 상황(예를 들어 카톡 친구 생일)이 발생했을 때 사용하는 경우엔 1점
을 부여하여 총합계를 내 봅니다. 2점과 4점을 부여하지 않는 이유는 기능을 추가하거나 다시 리뷰해 보면 1점보다는 중요하고 3점보다는 덜 중요한 기능들, 5점에는 못 미치는 기능들을 발견하기 때문에 추후 리스트 업데이트를 위해 비워 두는 것이 제 경험 상 현명했습니다.
다. 태스크를 시나리오로 변환
테스트 대상 게릴라 사용자가 실제 읽고 그 기능을 수행할 시나리오를 작성합니다. 시나리오 작성 시 주의 사항을 잘 지켜야 합니다. 예를 들어 그 앱/서비스만 사용하는 단어라든지 전문 용어라든지, 지나치게 길게 쓴다든지 해서 시나리오가 해석하기 어려워진다고 느끼면 모두 읽기 쉽게 바꾸어야 합니다. 사용자가 읽는 도중 해석하는 과정이 필요하고 테스트를 진행하는 테스터나 디자이너에게 되묻게 하는 시나리오는 잘못된 것입니다.
B. 테스트 시작하기
테스트가 시작되면 거침없이, 자신 있게 나아가야 합니다. 본인 성격이 ‘샤이’하다고 머뭇거리지 마십시오. 여러분이 지금 하고자 하는 테스트에 따라 프로덕트/서비스 아니면 더 나아가 우리 회사의 운명이 달려있다는 마음가짐이 필요합니다. 그렇지만 게릴라 사용자를 맞는 얼굴엔 무엇보다 호감을 줄 수 있는 미소와 밝은 말투가 떠나지 말아야 합니다. 여러분이 평소에 잘 봐 두었던 카페나 공원 같은 장소로 이동합니다. 단순히 불특정 다수보다는 여러분들의 프로덕트/서비스 잠재적 사용자의 프로필(성별, 연령 등)에 맞는 곳이면 더욱 좋습니다.
가. 자신을 알리는 표식하기
아무 표식도 없는 상태에서 상대에게 접근하는 것은 무모한 일입니다. 밑의 사진에서 보듯 적절하게 본인을 밝히고 게릴라 테스터가 다가오기를 기다리거나, 다가갈 수 있습니다. 표식에는 자신의 소개뿐 아니라 게릴라 테스트에 참여해줬을 때의 보상을 매우 명확하게 기재해야 합니다. 커피나 음료, 간단한 디저트 정도를 제공하는 것이 적절합니다.
나. 자신을 소개하고 제품 테스트에 참여하고 싶은지 물어보십시오.
동의하면 기본 정보를 얻으십시오. 기본 정보는 개인정보가 아닙니다. 여러분이 잠재적 타깃 사용자라고 정했던 것들처럼 연령대, 직업군(성별은 바로 파악이 가능하겠죠) 등 게릴라 테스터가 거부감이 없을 정도의 정보로 충분합니다.
다. 위의 <A-다>에서 작성한 시나리오를 제공합니다.
10~15분에 게릴라 테스트가 끝날 정도의 시나리오면 충분합니다. 반복하지만 end-to-end로 진행되는 시나리오는 안됩니다. 짧은 시간에 게릴라 테스터가 숙지하기에 무리가 될뿐더러, 이런 상황에서 나온 피드백은 어렵다는 지점에 대한 기억이 가장 크게 남게 되는 피크 엔드(the peak-end rule) 편향을 나타내어 좋은 데이터로 남지 않습니다.
라. 이제 내 역할은 이 사용자의 행동을 관찰하는 일입니다.
여러분의 프로덕트 특성에 따라 옆자리나 앞자리에 있어도 되고, 물리적으로 약간 떨어진 위치에 있어도 상관없습니다. 떨어져서 관찰하는 과정을 “fly on the wall(벽에 붙은 파리)”이라고 부릅니다. 이제부터 여러분은 벽에 붙은 파리처럼 게릴라 테스터를 관찰하는 것입니다. 이때 또 중요한 점이 있습니다. 절대로 상황을 보면서 수첩을 꺼내어 적는다든지, 노트북이나 휴대폰에 메모하고 있어서는 안 됩니다. 이것은 게릴라 테스터에게 내 행동이 관찰되고 있음에 대한 부담을 주고, 그것에 따라 행동의 변화를 가져오는 호쏜 효과 편향을 보여줍니다.
예를 들어 관찰되고 있다고 느끼면, 최대한 실수를 줄이기 위해 평소보다 훨씬 긴 시간을 할애하여 사용합니다. 이런 사용자는 실제 상황과는 매우 동떨어진 결과를 보여주게 됩니다. 그러기에 최대한 잘 기억을 하되 메모는 해당 게릴라 테스터가 떠난 다음에 해야 합니다. 최근의 디자인 프로토타입 툴은 이런 상황을 위해서 테스터의 행동을 모두 자동으로 기록해 주어서 나중에 취합 분석하는 데 큰 도움이 됩니다. 이런 툴의 사용을 적극적으로 검토해 보시기 바랍니다.
마. 테스팅이 끝나면 ‘사용자 경험’이 어땠는지 정중히 묻고 친절하게 응대합니다.
대화의 기술이 필요한 부분이지만 설득이나 해명, 설명은 필요 없습니다. 대부분의 초보 리서쳐나 디자이너의 실수는 테스터가 불만이나 실망감을 표현했을 때 그것에 대한 해명에 지나치게 집중한다는 것입니다. 게릴라 테스터는 그런 해명에 관심이 없습니다. 오직 관심이 있는 것은 이 사람들이 내 목소리와 경험에 귀를 기울이고 있느냐, 그 태도는 좋은가에만 관심이 있을 뿐입니다.
여러분이 해명과 설명을 하면 할수록 여러분은 여러분의 미래 고객이 될지도 모르는 사용자를 잃는 것뿐입니다. 이때는 수첩이나 노트북, 핸드폰에 메모를 할 수 있습니다. 오히려 적극적으로 메모하는 모습은 긍정적으로 보일 수 있습니다. 게릴라 사용자의 피드백에 적절하게 동의를 해 주는 대화의 기술이 그 사용자의 실제 내면을 더욱더 적극적으로 끌어내 주게 됩니다. 이런 진정한 사용자 경험이 프로덕트/서비스의 진짜 인사이트가 될 가능성이 매우 높습니다.
바. 참여에 대한 감사와 보상
조사에 의하면 게릴라 테스터가 출시될 프로덕트/서비스에 대해 가장 인상 깊게 기대를 갖게 되는 단계입니다. 약속했던 보상(커피/음료/디저트 비용 지불)을 진정한 감사의 마음과 표정, 태도로 표현해야 합니다. 또한 이때 해당 게릴라 테스터에게 “다음에 또 이런 기회가 있다면 우리 프로덕트/서비스에 대한 테스트에 참여해 줄 수 있느냐”라는 질문을 통해 테스트 집합 군을 확보할 좋은 기회를 적절하게 이용해야 합니다. 확정되지 않은 보상 플랜을 지금 당장 이야기할 필요는 없습니다. 오늘의 테스트 참여가 프로덕트/서비스의 품질 개선에 얼마나 많은 도움이 될 수 있는지에 대해서만 충분히 감사의 말을 전달하면 됩니다.
또한 해당 게릴라 테스터에게 주위 친구나 지인들과 함께 테스트를 진행해 줄 수 있는지에 대한 가능성도 타진해 볼 수 있습니다. 긍정적인 반응을 얻은 경우에는 기본적인 개인정보를 수집할 수 있으나, 이 개인정보 이용의 한계에 대해서는 매우 명확하게 설명을 하고 간단한 서명을 받는 것 역시 바람직한 접근 방법입니다.
2. 첫 번째 글 마무리
이번 글에서는 게릴라 테스트가 무엇이고 어떤 특성이 있으며, 어떻게 진행하는 것인지에 대해 설명을 하였습니다. 다음 글에서는 왜 스타트업이 게릴라 테스트에서 승부를 봐야 하는지에 대한 5가지 이유를 설명해 드릴까 합니다. 단순히 비용이 적게 들고 시간이 빠르게 진행된다는 통속적인 설명은 모두 빼고, 이 게릴라 테스트가 어떤 장점이 있고 조직과 기업에 어떤 이익을 돌려주는지에 대해 설명할 예정입니다.
오늘도 힘든 과정 가운데 좋은 세상을 만들기 위해서 피 땀 눈물로 애쓰고 계신 모든 분들에게 응원의 박수를 보내 드립니다.
감사합니다.
‘IT 아웃소싱 플랫폼, 위시켓과 함께 만든 콘텐츠입니다. 위시켓에서 빠르고 안전한 외주를 경험해보세요.’
김영욱님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
