A/B테스트 실무 알아보기(2)
A/B 테스트는 어떻게 실무에서 적용되는가
지난 글에서는 A/B 테스트의 기본 개념에 대해서 알아보았다.
이번 글에서는 A/B테스트를 실제 실무에서 어떻게 활용하는지 알아보자.
A/B 테스트 환경 구축하기
가장 기본이면서도, 어떤 PM에게는 가장 어려운 부분이지 않을까 싶다.
A/B 테스트를 하려면 당연히 우리 제품에 A/B 테스트를 할 수 있는 환경이 구축되어 있어야 한다. 쿠팡, 토스와 같이 규모가 큰 기업들은 대개 이런 환경이 잘 구축되어있지만, 규모가 크지 않은 회사의 제품이라면 높은 확률로 이런 환경이 구축되어 있지 않을 가능성이 높다.
만약 A/B 테스트 환경을 구축이 되어 있지 않다면 어떻게 해야 하는가? 그렇다면 당연히 환경을 구축해야 한다. 환경을 누가 구축하는가? 당연히 PM이 해야 한다. 물론 이것이 PM이 직접 코드를 짜서 A/B 테스트 환경을 만들라는 것이 아니다. 우리가 왜 A/B 테스트 환경이 필요하고, 만들어지면 어떤 임팩트를 가져다 줄 것이고 앞으로 어떻게 활용할 수 있을지 등을 바탕으로 팀과 회사를 설득해야 한다.(잊지 마라. PM은 팀이 승리하게끔 만드는 데 필요한 모든 일을 해야 한다!)
엔지니어들과 ground-zero에서부터 A/B 테스트 환경을 구축할 수 있지만, 제품 규모가 크지 않은 회사라면 소중한 개발 리소스를 거기에 쓰는 것보다 솔루션을 돈 주고 구매해오는 것이 훨씬 저렴하다.(대부분의 경우 솔루션 비용은 개발 리소스보다 훨씬 저렴하다는 사실을 기억하자) 국내에서는 '핵클'이라는 회사가 a/b 테스트 플랫폼을 제공하는 것으로 유명하다
다만 크진 않더라도 비용이 계속 발생하고, 솔루션을 우리 제품에 심고 유지 보수하는데 조금의 개발 리소스는 발생하므로 도입을 위한 충분한 검토를 거치고 팀에 제안하자. 다음과 같은 내용들을 준비해서 제안하면 팀과 회사를 설득하는 데에 큰 도움이 될 것이다.
- A/B 테스트로 어떤 임팩트를 낼 수 있을까?
- A/B 테스트를 한다면, 우리 제품(또는 회사)가 앞으로 얼마나 잘 활용할 수 있을까?
- A/B 테스트의 사용이 예상되는 우리 제품의 주요 유즈케이스는 무엇인가?
A/B 테스트 목표와 지표 셋업하기
여기서부터는 A/B 테스트를 하기 위한 충분한 환경이 갖추어져 있다는 사실을 전제로 작성한다.
A/B 테스트를 하기 전 가장 중요한 것은, 뭐니뭐니 해도 실험의 목표와 지표를 설정하는 것이다. 즉 우리가 이 실험을 왜 해야 하는지, 실험을 통해 얻고자 하는 결과가 무엇인지?를 확인하는 것이다.
가장 쉽게 가는 방법은, '이 실험을 통해 변화를 측정하고 싶은 단 하나의 지표는 무엇인가?'라는 질문에 답을 하는 것으로부터 시작하는 것이다. 주문/결제 담당자라면 결제 전환율, 평균 주문 금액 상승 등일 것이다. 운영 담당자라면 VOC 인입률, 홈 영역 담당자라면 핵심 서비스로의 트래픽 전환율(CTR) 등일 것이다. 대부분 우리 제품의 핵심 지표와 겹칠 가능성이 높다.(그렇지 않다면, 특수한 상황이 아니고서야 무의미한 실험일 가능성이 높다)
여기서 중요한 것은 지표가 측정 가능해야 한다는 것이다. 결제 전환율, 주문 금액, 클릭률 등과 같이 A안 대비 B안이 얼마나 변화폭이 있는지를 추적해야 하기 때문이다.
A/B 테스트로 움직이고자 하는 지표는 success metric(성공 지표)이라 부른다. 이름 그대로 이 실험이 '성공'했는지 여부를 판단하는 지표를 의미하고, 가장 핵심이 되는 지표다.
성공 지표만큼이나 중요한 것은 guardrail metric(가드레일 지표)이다. 가드레일 지표는 이 실험의 진행 여부와 관계 없이 지켜져야 하는 지표이다. 자동차가 잘못된 길로 빠지지 않도록 도로에 가드레일이 설치되어 있는 경우를 연상하면 쉽다.
예컨대 결제 화면에서, 카드 결제보다 계좌 결제를 유도하는 실험을 한다고 생각해보자. 이를 위해 결제 수단의 디폴트를 계좌 결제로 해두고, 카드 결제를 숨기는 실험이다. 이것의 success metric은 당연히 전체 결제의 결제 수단 중 계좌 결제의 점유율 상승(카드 결제의 점유율 하락)일 것이다.
그러나 다음 시나리오를 생각해보자. 유저는 카드 결제의 간편함을 느끼고 있고, 계좌 결제를 위해 계좌를 새롭게 등록해야 하는 허들이 높아서 -> 기존 카드 결제 유저가 계좌 결제를 이용하는 대신 아예 결제를 끝마치지 않고 이탈할 수도 있다!
이런 경우는 결제 전환율이 guardrail metric이 되어야 한다. 즉 이 실험에서 얻을 수 있는 최고의 결과물은 '결제 전환율이 하락하지 않으면서(guardrail metric) 계좌 결제의 점유율을 높이는 것(success metric)'일 것이다.
A/B 테스트의 결과 검증하기
A/B 테스트를 했더니, 실험안의 결과물이 기존안보다 좋게 나타나고 있다! 일단 축하한다. 결과가 좋게 나타나고 있다는 것은 좋은 신호다.
하지만 축포를 너무 일찍 터뜨리는 것은 위험하다. 지난 글에서도 이야기했듯, 이게 '우연히' 결과가 잘 나오는 것인지 '통계적으로 검증된' 결과인지를 확인해보아야 하기 때문이다.
이것을 통계적 유의성을 확보하는 작업이라고 한다.
실험 결과의 통계적 유의성이 확보되려면 딱 한 가지만 기억하면 된다. 이 실험에 충분히 많은 수의 고객들이 참여했는지이다. 충분히 많은 수라는 것이 어느 정도인지 궁금할 것이다. 이것은 실험에 따라 다르다. 다만 구하는 공식이 있기 때문에 우리는 공식만 사용하면 된다. 좋은 소식은 이미 이것을 대신 계산해주는 사이트도 있다는 것이다.
위 사이트에서 우리 테스트의 a안과 b안에 각각 사용자가 얼마나 유입되었는지, 그 중 전환된 유저가 각각 얼마인지를 입력하면 이것이 통계적으로 유의한 결과인지 아닌지 나타난다. 통계적 유의성을 확보할 정도로 충분히 큰 수라면, 위 사진처럼 significant test result라는 결과를 볼 수 있다. 이는 우리의 실험 결과가 우연일 가능성이 상당히 낮다(결과가 통계적으로 유의하다)는 것을 말해주며, 이 결과를 얻었다면 결과를 기쁘게 어나운스하고 실험안을 전체 배포하면 된다.(물론 가드레일 지표가 떨어지지 않았는지를 이중 확인하라)
반면 통계적 유의성이 확보되지 않은 상태라면 결과가 위와 같이 나타난다. 이는 결과는 좋게 나왔지만, 이것이 우연에 의한 가능성임을 배제할 수 없다는 의미이다. 이를 해결하기 위해서는 숫자를 더 모아야 한다. 실험 기간을 늘리거나, 실험 대상자를 더 많이 편입시켜야 한다.
A/B 테스트 만능설을 경계하라
A/B 테스트는 확실히 매우 강력한 도구다. 불확실성이 가득한 PM의 세계에서 빠른 실행과 A/B를 통한 검증만큼 불확실성을 확실하게 줄여주는 도구는 없다. 그러나 A/B 테스트가 만능은 아니다.
모든 것을 A/B테스트로 결정하려 하지 마라.
PM이 가장 쉽게 빠지는 함정은, PM이 아이템에 대한 충분한 자신감으로 팀을 설득하는 대신, A/B 테스트로 의사결정을 미루는 것이다. A/B 테스트는 우리가 하고자 하는 아이템이 효과적일까를 검증하는 것이지, PM의 의사결정을 뒤로 미루기 위한 툴이 아니다. PM의 우유부단함을 A/B 테스트로 방어하려고 해선 안 된다.
A/B 테스트도 비용이다. 일단 셋업하고 실험하는 데에 있어서 팀 리소스가 소요된다. 때문에 '닥치고 실험'과 같이 무분별하게 실험 자원을 소요하는 것은 비효율적이다. 아이템에 대한 확신이 있다면 실험 없이 그냥 전체배포하는 방법도 충분히 좋다.
가장 큰 문제는 버킷 사이즈이다. 쿠팡이나 토스와 같이 대규모 트래픽을 가지고 있는 제품이 아니라면, 실험에 참여할 수 있는 고객의 수는 한정적일 수밖에 없다. 고객 한 명은 우리 제품에서 하나의 실험에만 참여해야 한다. 여러 개의 실험을 동시에 적용받을 경우, 다른 실험의 결과가 우리 실험에 영향을 주고 있을 가능성을 배제할 수 없기 때문이다. 여러 개의 실험이 동시에 진행된다면, 자연스럽게 하나의 실험에 참여 가능한 고객의 수는 줄어든다. 당연히 통계적 유의성 확보에 필요한 필요한 실험 기간은 늘어난다. (쿠팡, 토스와 같이 대규모 트래픽을 가지고 있는 회사도, 그만큼 실험도 많이 진행되고 있기 때문에 이 버킷 사이즈 문제로부터 완전히 자유롭지도 않다)
A/B 테스트가 불가한 경우: one-way door
고객 수가 충분히 많고, 임팩트가 충분하다고 예상되더라도 A/B 테스트 적용이 불가능한 경우가 있다.
이것은 우리의 의사결정이 one-way door일 경우이다. One-way door 혹은 one-way decision이라 부르는데, 쉽게 말해 돌이킬 수 없는 의사결정을 의미한다.
가령 B2B 서비스에서 핵심 제품의 가격을 내리는 것이 신규 구독에 유의미한 영향을 주는지를 검증해보고자 한다고 하자. 가격을 낮추는 a/b test를 할 수 있을까? 어찌어찌 가능은 하겠지만 불가능에 가깝다. 가장 먼저 떠오르는 기존에 사용하고 있던 고객들의 저항이다. 그들은 이미 기존에 비싼 돈을 주고 구독하고 있었기 때문에, 가격 할인이 달갑지 않을 것이다. 가격을 낮추었는데 기대만큼의 효과가 나타나지 않았다면? 가격을 다시 올리는 것은 또다른 저항에 직면한다.
즉 이런 경우는 one-way decision에 가까우며 직접적으로 a/b test를 수행하는 것이 어렵다. 때문에 간접적으로 결과를 뒷받침할만한 근거를 찾아 나서는 노력을 해야 한다.(가령 '쿠폰 이벤트'를 하는 것처럼 한다든지)
마치며
이러니 저러니 해도 PM에게 A/B 테스트만큼 강력한 도구를 찾기 어렵다. PM 포트폴리오를 보다 보면 충분한 A/B 테스트 경험이 있는 PM과 그렇지 않은 PM의 인사이트 차이는 상당하다. 물론 B2B 도메인과 같이 A/B 테스트 도입이 어려운 영역도 있을 수 있겠으나, 만약 B2C 도메인 근무 중인 PM이라면 A/B 테스트에 대한 충분한 결과물을 시도해보기를 권장한다.
