A/B Test, 강력한 제품 검증 도구
위험을 줄이면서 제품을 테스트해볼 수 있다면?
제품을 만드는 과정에서 늘 질문하게 되는 구간이 있다. “이건 정말 해결할 필요가 있는 문제일까?”, “개선할 필요가 존재하는 문제인가?”, “임팩트가 클 것인가?” 즉 문제와 아이디어를 정의하고 검증하는 과정에서 질문하게 된다. 또는 “괜히 이 기능/디자인을 적용했다가 사용자가 이탈하면 어쩌지?”, “매출이 감소하게 되는 건 아닐까?”, “제품에 사용자가 적응하지 못하면 어떻게 하지?”와 같이 아이디어를 제품에 적용하였을 때 두려워하게 되는 지점을 마주하게 된다. 그런 경우에 우리는 A/B Test라는 도구를 활용해보면 좋다. A/B Test는 늘 질문하게 되는 부분들을 리스크를 최소화하면서 해결하고 검증해볼 수 있기 때문이다.
이번 글은 A/B Test에 대해서 적어본 글이다. 글의 순서는 아래와 같다.
1. A/B Test는 무엇일까?
2. A/B Test 종류와 차이
3. A/B Test 설계하기
A/B Test는 무엇일까?
의사결정 과정에서 “데이터"의 중요성은 점차 커지고 있다. 사실 커지고 있다는 말은 잘못된 표현일 수 있다. 최근에는 “데이터”가 모든 것을 결정하는 기준이 될 수 있을 것이라고 생각되기도 한다. A/B 테스트는 데이터를 근거로 하는 대표적인 정량적 테스트 기법이다. 새로운 기능, 새로운 디자인, 새로운 사용자 행동을 매우 간단한 방법으로 테스트해볼 수 있는 도구다. 일부 사용자에게 “A”에 해당하는 기능 혹은 디자인을 보여주고, 다른 사용자에게는 “B”에 해당하는 기능 혹은 디자인을 보여주고, 두 그룹의 데이터를 비교 분석하는 것이다. 이를 토대로 더 좋은 결과가 나왔거나 유의미한 결과를 보여주는 것을 채택하여 제품에 적용하는 것을 말한다.
A/B Test를 진행하는 것의 장점은 앞서 이야기한 것처럼 리스크를 최소화하면서 우리의 아이디어가 실제 효과가 있는지를 검증할 수 있게 해주는 것이다. 또한 사용자는 본인이 A와 B 중 어떤 것을 보고 있는지 모르고 사용하기 때문에 우리는 보다 정확하고, 명확한 데이터를 확보할 수 있다.
물론 데이터가 전부는 아닐 수 있다. 그리고 데이터를 잘못 해석하는 경우가 발생할 수도 있다. 또는 우리가 최초에 설정한 가설이 전혀 맞지 않게 된다거나 우리가 예상했던 결과와 전혀 상관없는 결과가 나와 당황스럽게 만드는 경우도 존재한다. 하지만 이 모든 것들조차 데이터가 우리에게 제공하는 새로운 가치, 우리가 생각하지 못했던 새로운 지점을 발굴하게 되는 긍정적인 요인이 될 수 있다.
A/B Test 종류와 차이
A/B Test는 두 가지의 환경에서 각기 다른 방법으로 적용할 수 있다. 앞서 가치를 사용자에게 전달하는 방법에서 소개한 것처럼 Discovery(제품 발견 단계)와 Delievery(제품 실행 단계) 환경이 그것이다. 두 가지는 개념적으로는 동일하다. 차이점은 A/B Test를 진행하는 수준이나 적용 그룹에서 나타난다.
일반적으로 Discovery 단계에서의 A/B Test는 큰 기능 단위에서 Test가 진행되거나 제품의 구조 및 사용자 행동이 큰 폭으로 변화하게 되는 경우를 말한다. 당연히 위험도가 높기 때문에 Test 그룹을 1 : 99 또는 10 : 90으로 적용해보고 서서히 적용 범위를 넓혀가는 방식으로 진행한다. 가령 기존에는 존재하지 않았던 새로운 가치를 기능으로 만들어서 출시한다거나 제품의 레이아웃이나 디자인을 대폭 변경하여 출시해보는 것들을 말한다. 이러한 종류의 A/B Test는 제품 발견 A/B Test라고 부른다.
반면 Delivery 단계에서의 A/B Test는 비교적 작은 단위 또는 표면적인 개선 등을 테스트해보는 경우를 말한다. Discovery에 비해서 위험도가 낮기 때문에 Test 그룹을 50 : 50으로 나눠서 진행하는 분할 테스트를 진행하는 경우가 많다. 이 경우 때에 따라서는 C, D와 같이 테스트 내용을 추가할 수 있다. 물론 테스트 환경이 많아지면 많아질수록 수집되는 데이터 또한 분산되기 때문에 정확하게 해석하거나 명확한 결론을 도출하기 어려워 추천하지는 않는다. Delivery의 예시로는 버튼의 색을 변경한다거나, 아이콘을 변경한다거나, 문구나 이미지를 다르게 바꿔본다거나 하는 것들이 있다. 이러한 종류의 A/B Test는 제품 최적화 A/B Test라고 부른다.
A/B Test 설계 문서 작성하기
A/B Test는 “왜” 진행해야 하며, “어떤 가설”을 검증하기 위해서 “어떻게" 만들어야 하는지, “어떤 목표"를 달성하고 싶은지, “실험 진행 및 데이터”는 어떻게 수집할지 메이커들에게 명확하게 전달해줄 수 있어야 한다. PRD의 형태와 유사하게 설계 문서를 작성할 수 있다. A/B Test 설계문서에 주로 포함하는 내용은 아래와 같다.
1. 개요 : A/B Test를 진행하는 배경을 설명합니다.
- 기능 정의 : A/B Test가 어떤 내용인지를 정의합니다.
- 문제 정의 : A/B Test가 어떤 문제를 해결하기 위한 것인지 문제를 정의합니다.
2. 핵심 지표 : A/B Test의 임팩트와 가설을 설정합니다.
- 목표 : A/B Test를 통해 달성하고자 하는 임팩트를 정의합니다.
- 가설 : A/B Test를 통해 검증하고자 하는 가설을 정의합니다.
3. 요구 사항 : A/B Test 세부 내용을 설정합니다.
- ex 1) 기능 / 디자인 설명
- ex 2) 기능 / 디자인 동작 Logic
4. 실험 설계 : 데이터는 어떻게 수집할지, 어디에 데이터를 쌓을지 등을 설정합니다.
- 이벤트 설정 : 데이터를 어떤 방식으로 수집하고, 쌓을지 설정합니다.
- 유저 배분 계획 설정 : 각 그룹별 유저 배분 계획을 설정합니다.
- 테스트 계획 : 데이터를 얼마의 기간 동안 축적하며, 언제 분석을 진행하고, 결과를 언제 확인할지 설정합니다.
한 가지 유의할 점은 이러한 문서를 작성할 때 PM이나 기획자가 다 작성하고 메이커들에게 전달하기보다는 시작부터 메이커들과 함께 작성하는 것이 좋다. 가령 PM이 요구하는 요구사항들이 구현 가능한 것인지, 구현이 가능하다면 어떤 방식으로 유저를 배분할 수 있을지, 데이터는 어떻게 수집할지와 같은 내용들은 개발자와 함께 논의하면서 실험을 설계하는 것이 좋다.
또는 요구사항을 어떤 방식으로 사용자에게 노출할 것인지, 어떤 부분에서 변화가 이루어졌을 때 사용자가 반응할 것으로 예상되는지와 같이 디자인이나 UX와 관련한 부분은 디자이너와 함께 논의하면서 실험을 설계하는 것이 좋다.
결론
A/B Test는 매우 효과적이고 강력한 도구임은 분명하다. 하지만 상황에 따라서 A/B Test를 사용하기 어렵다고 얘기하는 경우가 있다. 트래픽이 충분히 발생하지 않는다거나, 리소스가 너무 제한된다거나 하는 이유가 있을 수 있다. 하지만 A/B Test는 충분히 어떤 상황에서든 진행해볼 수 있다. 트래픽의 양, 가용 가능한 리소스, 위험을 감수할 수 있는 수준에서 차이가 있을 수는 있지만 A/B Test를 진행하지 못하는 상황이 존재하는 경우는 존재하지 않는다.
한편 리소스가 없고, 시간이 없고, 트래픽이 없다고 이야기하는 경우가 오히려 A/B Test를 진행하기에 최적의 조건일 수 있다. 리소스와 시간이 없기 때문에 우리가 어디에 이 소중한 리소스와 시간을 사용해야 할지 선정할 수 있고, 트래픽이 없기 때문에 위험부담 없이 더 많은 실험을 해볼 수 있는 것이다. 또한 그렇게 실험을 하다가 오히려 트래픽이 증가하는 A-Ha Moment를 발견할 수도 있다.
데이터는 늘 우리가 생각하지 못했던 포인트를 발굴하게 만들어주고 때로는 우리가 전혀 의도하지 않았던 부분에서 좋은 결과를 가져다주어 제품이 더 성장하거나 피봇 하게 만드는 계기를 만들어준다. 이러한 이유로 인해 A/B Test를 실행하면서 팀이 항상 실험을 통해서 인사이트를 발굴하고, 고객의 데이터를 통해 의사결정을 하는 문화를 형성할 수 있다면 더할 나위 없이 좋은 팀이 될 것으로 생각한다.
