실험 조직으로 거듭나기: ② 검증할 ‘만’한 가설은?

[실험 조직으로 거듭나기] 시리즈 보러 가기 ▼

실험 조직으로 거듭나기: ① 실험 툴 도입하기

이런 분들께 이 글을 추천합니다. 그로스(Growth)와 실험 문화를 팀에 도입하고 싶은 분, '무엇'을 '어떻게' 검증해야 할지 헷갈리는 분, 가설 검증 사례를 알고 싶은 분. 이 중 하나라도 해당된다면 재밌게 읽을 수 있습니다. 오늘은 실험 조직으로 거듭나기 2편으로, 가설의 뼈대를 만드는 방법을 살펴보겠습니다.

가설 검증, 이런 식으로 진행됩니다.

‘린 스타트업’에선 문제와 아이디어를 검증하고 학습하는 과정을 반복해가면서 '진짜 문제'를 찾는다. 이전 글에서 실험 환경을 만드는 법에 대해 이야기했다. 이제 실험 환경이 만들어졌으니, 가설을 검증하는 방법에 대해 알아보자!

가설 검증 프로세스는 크게 아래의 과정을 따른다. 먼저, 어떤 가설을 검증할지 결정하고 이를 어떤 방식으로 검증할지 결정한다. 이때 AB 테스트, FGI 등 다양한 가설 검증 방법이 존재하는데, 검증 방식에 따라서 수집 가능한 데이터도 달라진다. 가령 FGI 등 정성적 방식은 정성 데이터를, AB 테스트 등 정량적 방식은 정량 데이터를 얻을 수 있다. 수집 가능한 데이터를 기준으로, 가설의 참/거짓을 평가할 수 있도록 검증 지표와 목표 수치를 정한다. 만약 실험이 끝나는 날에 검증 지표가 목표 수치에 도달했다면, 가설은 '참'이라고 말할 수 있다. 이제 이 검증 지표 데이터를 충분히 수집할 수 있는 실험 기간을 정하고 실험을 진행한다. 실험이 끝나는 날, 데이터를 분석해 가설을 검증하고 학습한다. 실험 환경은 디폴트이므로 딱히 언급하지 않았다. 세부 순서는 바뀔 수 있으나 큰 결은 비슷하다.

시간이 없다! 이런 가설'만' 검증하자

가설을 검증하는 과정은 생각보다 많은 리소스가 소비된다. 어떤 가설을 검증할지 논의하고, 실험 환경을 구축하며, 가설 검증을 위한 데이터가 충분히 모일 때까지 기다려야 한다. 그리고, 이렇게 수집한 데이터를 분석하는 시간도 필요하다. 그렇다고 여러 개의 가설을 동시에 검증할 수도 없다. 여러 가설을 동시에 검증하다 보면 서로에게 영향을 주어서 실험 변수를 통제할 수 없기 때문이다. 결과적으로, 주어진 시간 동안 검증할 수 있는 가설의 수는 한정된다.

검증할 수 있는 가설의 수가 한정된 상태에서 아무 가설이나 검증할 수 없는 노릇이다. 여러 가설 사이에서 우선순위를 매기고, 가장 가치가 높아 보이는 가설부터 검증을 해야 한다. 이를 위해, 우리는 2가지 기준을 적용해 가설의 임팩트를 평가하고 우선순위를 결정했다.

1. 현재 상황을 개선하는가?

린 프로세스는 (1) 직면한 상황을 분석해 문제를 찾고 (2) 이 문제를 일으킨 근본 원인을 찾는다. (3) 이와 관련된 아이디어를 구현 및 배포하고, (4) 고객 반응을 통해 문제나 아이디어를 검증한다. (5) 앞선 과정에서 배운 것을 학습하는 과정을 반복한다. 일련의 과정을 보면 알 수 있듯, 문제를 찾기 전에 상황 분석이 선행된다. 지금의 상황을 되돌아봐야지, 비로소 무엇이 문제인지 알 수 있기 때문이다. 이때 사용하는 게 OKR이다.

OKR은 크게 2가지 역할을 하는데 (1) 구성원 모두가 따르는 판단 기준이자 (2) 이정표를 제시하는 마일스톤이다. OKR를 구성하는 요소인 KR(Key Result)는 정량적 기준을 제시해 현재의 상태를 객관적으로 되돌아보게 만든다. KR의 목표 수치와 현재 달성치의 비교를 통해 조직이 어떤 상황에 있고, 직면한 문제는 무엇인지 알 수 있다. 가령, 특정 KR의 달성 수치가 목표치보다 훨씬 낮다면, 이는 주목해야 할 상황이자 문제이다.

이렇게 발견한 문제 상황이 바로 가설 대상이 되지는 않는데, 대다수가 '원인'보다 '현상'에 가깝기 때문이다. 이때 5 Whys나 어피니티 다이어그램 등을 활용해 근본 원인을 찾을 수 있다. 최종적으로 발견한 근본 원인은 현재 상황에서 검증해야 할 가설 대상이다.

2. Actionable한가?

<Product Owner>라는 책에서는 ‘Actionable’한 데이터를 강조한다. 여기서 Actionable은 '다음 행동을 제시할 수 있는가?'를 뜻한다. 가설 검증에도 Actionable이 필요하다. 즉, ‘이 가설을 검증했을 때, 우리가 다음에 어디로 가야 하는지 알 수 있을까?’를 고민해야 한다. 우리가 반복적으로 가설 검증을 하는 이유는 학습을 통해 올바른 방향을 얻기 위함이다. 마치 꼬리 물기처럼 이번 가설 검증은 다음 번 가설에 인사이트를 줘야 한다. 그렇지 않으면, 이번 가설 검증은 학습의 의미가 없는 셈이다.

아무개 씨도 할 수 있는 검증 방법

무엇을 검증할지 정의했다면 이제 어떤 방식으로 검증할지 결정해야 한다. 다양한 가설 검증 방법이 있고 절대적으로 옳은 가설 검증 방법은 없다. 자신의 취향 혹은 주어진 상황에 따라 맞는 걸 선택하면 된다.

1. 비교해서 검증하자! AB 테스트

AB 테스트는 서로 다른 시안을 비슷한 사용자 군에게 동시에 노출시켜서 유의미함을 판단하는 실험이다. 쉽게 말하면 비교를 통한 가설 검증이다. 예를 들어, 구현한 기능이 반영이 안 된 프로덕트(A안)와 반영된 프로덕트(B안)를 유저에게 보여주고 반응을 비교 분석해서 가설을 검증하는 것이다.

여기서 유의해야 할 점은 '비슷한 사용자군'과 '동 시간의 노출'이다. AB 테스트에서 중요한 건 변수의 통제로, 시간과 사용자도 통제 변수가 된다. 시간이나 사용자 자체에 따라서도 프로덕트를 이용하는 패턴이 바뀌기 때문이다. 실험에 영향을 주는 건 AB 테스트를 위해 설정한 변수뿐이어야만 한다. 그래야 명확한 가설 검증이 가능하다.

최근 몇 년 동안 그로스(Growth) 문화가 강조됨에 따라, 많은 기획자들이 AB테스트를 사용하기 시작했다. 아직 AB 테스트를 시도해보지 않은 기획자라면 한 번 도전해 보길 권유한다. Google Optimize를 도입한다면, 비주얼 편집기로 코딩 없이 AB 테스트를 쉽게 진행할 수 있다.

비주얼 편집기로 코딩 없이 진행한 AB 테스트

2. 전후 고객 반응을 비교하자! 실험 전후 검증

실험 전후 검증은 실험이 진행되기 전과 후의 고객 반응을 비교해서 가설을 검증하는 방법이다. 예를 들어, 새로운 기능이 구현된다면 이를 배포하기 전과 후의 고객 데이터를 비교한다. 이 방식은 가설 설정이 매우 쉬운 편이나, 유의미성을 갖기 어렵다. 실험에서 변수가 적절하게 통제돼야 하는데 이 방법은 통제할 수 없는 변수가 많다. 가령 커머스 프로덕트의 경우, 공휴일의 영향을 많이 받는다. 만약 저번 주에 연휴가 있고, 이번 주에 없다면 유저의 사용 패턴은 매우 다를 것이다. 이 다른 패턴을 보인 유저를 같은 대상으로 보고 서로 비교해도 괜찮을까? 따라서, 되도록 AB 테스트를 하는 걸 추천한다.

데이터 툴에서 전후 비교를 쉽게 할 수 있다.

3. 고객 행동을 말해보자! XYZ 가설 검증

 XYZ 가설 검증은 책 <아이디어 불패의 법칙>에서 소개된 방법이다. 실험 전후 검증과 결은 비슷하지만, 고객 행동을 정량적으로 접근하는 차이가 있다.

예를 들어, 어떤 가설로부터 기능을 구현한다고 했을 때, "재방문 유저의 20%는 기능을 5분 동안 사용할 것이다."라는 식으로 정할 수 있다.

XYZ 가설 검증을 사용하는 이유는 애매모호함을 없애기 위함이다. 예를 들어, ‘기존 유저에게 이 기능을 제공하면 더 만족할 것이다.’ 라고 가설을 설정했다고 해보자. 여기서 '만족'은 추상적 단어이기 때문에, 팀원 각자가 지닌 경험과 지식에 의해 다르게 해석할 여지가 있다. 따라서, 이러한 애매모호함을 없애기 위해 모두가 동일하게 해석할 수 있는 정량적 기준을 적용한다. 가령 "이 기능을 제공하면, 기존 유저의 20%는 이 기능을 2분 이상 사용할 것이다”. 라는 식으로 바꿀 수 있다.

XYZ 가설 검증 예시.

'어떤 가설'을 '어떤 방식'으로 검증할지 결정했다면, 가설 설정의 뼈대를 완성한 셈이다. 이제 남은 일은 이 뼈대에 어떻게 살을 붙이느냐 다. 참/거짓을 어떤 데이터를 보고 판단할지, 얼마나 실험을 진행해야 하는지 등을 결정한다면, 바로 검증을 위한 실험을 진행할 수 있다. 이 완성된 뼈대에 살을 붙이는 방법을 다음 글에서 알아보자

<참고 자료>

스타트업이 일하는 법, 린 프로세스 도입하기 https://yozm.wishket.com/magazine/detail/1084/

팀이 린하게 일하는 법_OKR, 이렇게만 해보자! https://brunch.co.kr/@famelee/10

5 Whys로 '진짜' 문제 찾기 https://yozm.wishket.com/magazine/detail/1079/

이번 아이디어, 성공할 수 있을까? https://brunch.co.kr/@carpediem7760/19

내 사업은 '될 놈'일까? 3가지 꼼수로 미리 알아보자 https://brunch.co.kr/@positive-kim/41

실패를 통해 배우는 AB테스트 https://blog.gangnamunni.com/post/AB-test-Baisc/

A/B테스트에서 하면 안되는 7가지 실수 https://mindthelog.com/2017/08/ab-testing/?fbclid=IwAR05GRD8paIFpQEDovM7LmwMgZVyQ7_fM2oBq70aNeGiPvt55E7bAhNKWPQ

아이디어 불패의 법칙 http://www.yes24.com/Product/Goods/89707566

프로덕트 오너 http://www.yes24.com/Product/Goods/89553345