내 가설을 성공으로 증명하는 방법
제품 개발 환경에서 거의 치트키에 가까운 도구가 있는데, 그것은 바로 A/B 테스트이다. IT 업계에 종사하는 사람이라면 PM이 아니더라도 A/B 테스트라는 이름 정도는 한 번 쯤은 들어보았을 것. 오늘은 실제의 제품 개발 현장에서 A/B 테스트를 어떻게 사용하는지 그 실무를 알아보자.
A/B 테스트는 특정 개선안이 기존안 대비 개선 효과가 실제로 있는지를 검증하기 위한 방법이다. 기존안과 개선안을 A안 B안 비교하듯 한다고 하여 A/B 테스트라는 이름이 붙었다.
A/B 테스트의 아이디어는 간단하다.
예컨대 우리 제품에서 결제 영역에 대한 개선안을 내려고 하는데 이것이 기존안 대비 효과가 있는지 없는지 궁금하다고 해보자. 이것을 측정할 수 있는 방법은 무엇일까? 결제 영역의 개선 목표는 결제 전환율, 주문강 결제 금액 등일 것이다. 여기서는 결제 전환율이 목표라고 해보자.
이를 측정하기 위해 고객이 우리 웹사이트의 결제 영역에 들어올 때 랜덤하게 어떤 고객은 기존의 결제 페이지를(A안), 나머지 고객은 새로운 결제 페이지(B안)를 보도록 만든다. 이런 상태를 충분히 긴 시간 동안 유지한 다음, 결과를 측정한다. 결과는 다음 3가지 중 하나에 속할 것이다.
1. 기존안 대비 개선안의 결과가 더 좋음(A<B)
개선안이 기존안 대비 효과가 더 좋다면 개선안을 기쁘게 도입할 수 있다. 승리를 자축하고, 개선안이 얼마나 효과가 있었고 무엇 때문에 효과가 있었는지를 내부 분석하자.
2. 기존안과 개선안의 결과에 유의한 차이가 없음(A=B)
대개 다소 맥빠지는 결과이지만 훌륭한 PM이라면 여기에서도 많은 것을 얻을 수 있다. 개선안에서 변화점을 주고자 했던 것이 무의미했다는 인사이트다. 즉 팀/회사 입장에서 중요하다고 생각했던 것이 실제 고객에게는 전혀 중요하지 않았다는 의미이다.
3. 개선안의 효과가 기존 대비 더 안좋음(A>B)
마찬가지로 맥빠지는 결과이지만, 우리가 생각한 주 변화점이 고객 입자에서 치명적인 요소였다는 것을 증명한다. 예컨대 개선안이 기존안 대비 결제수단에서 카드결제의 순서를 뒤로 미뤄둔 것이 핵심이었다면, 고객은 결제수단에서 카드결제를 굉장히 중요하게 생각한다는 시그널일 수 있다.
A/B 테스트의 멋진 점은 단순히 개선안이 효과가 있었는지를 증명하는 것 뿐만 아니라, 얼마나 효과가 있었는지도 정확히 추정할 수 있다는 것이다. 예컨대 결제 전환율이 기존의 5%에서 5.5%로 개선되었다면 기존 대비 10%(0.5%p) 상승했다는 것까지도 정확히 알 수 있다.
A/B 테스트는 꼭 해야 하는가?에 대한 생각도 있을 수 있다. 개선안을 전체 배포한 다음에, 기존 대비 데이터가 어떻게 변화했는지를 측정하면 되는 것이 아닌가라 생각할 수도 있다.
다음 사례를 보자.
예컨대 우리가 여행 플랫폼을 담당하는 PM이라고 해보자. 여름 휴가철을 맞아 대대적인 개선안을 출시했고, 이를 통해 여행 상품 구매율이 상승할 것으로 예상된다. 그리고 개선안을 출시했더니 출시 시점 이후로 실제로 구매율이 크게 상승했다.
구매율이 상승했으니 개선안이 성공적이었다고 말할 수 있을까? 그렇지 않다. 정확히 말하자면 개선안이 효과가 없는 것이 아닌, 효과가 있다고 확신할 수 없다.
여행 플랫폼이고 배포 시점이 여름 휴가철이었으니 고객들의 여행 상품 구매 니즈가 평소 대비 크게 증가했을 것이다. 즉 개선안이 구매율 상승이 여름 휴가철 때문에 상승한 것인지, 우리의 개선안이 효과가 있어서 상승한 것인지 알기 어렵다. 심지어 개선안이 오히려 역효과를 내여, 아무런 액션을 하지 않았을 때 휴가철 때문에 구매율이 100만큼 올라갔을 것이 50만큼만 올라갔을 수도 있다!(이런 경우 실제로는 나쁜 결과였는데 수치가 올라간 것만 보고 winning case로 잘못 선정되는 가장 끔찍한 결과다)
이런 상황을 시즈널리티(seasonality) 이슈라고 한다. 시즈널리티는 말 그대로 계절성 이슈로, 위 사례처럼 여름에 휴가를 많이 가거나 겨울에 난방기구가 많이 팔리는 것을 생각하면 쉽다. 이름은 계절성이지만 계절만 해당하는 것은 아니고, 연휴철(휴가 상품)이나 대학교 방학(원룸 임대) 등과 같이 주기적으로 반복되어 충분히 예상 가능한 이슈들을 통칭한다.
A/B 테스트의 핵심 장점 중 하나가 바로, 제품 개선안의 효과를 측정할 때 이러한 시즈널리티 이슈를 제거해주는 것이다. A/B 테스트가 고객을 랜덤 분배하는 것은 동일한 기간에 이루어지기 때문에, 시즈널리티 이슈의 영향을 받더라도 기존안과 개선안이 모두 적용받게 되기 때문이다.
시즈널리티 이슈 외 A/B 테스트의 다른 핵심 장점 중 하나는 다른 변인의 통제이다
일반적으로 어느 정도 규모 이상의 회사라면, 제품 내에 수많은 액션들이 동시에 병렬적으로 진행되고 있다. 마찬가지로 우리 팀에서 개선안을 내어 결제 전환율이 올라가고 있다고 해보자. 그러나 알고봤더니 마케팅 팀에서 우연히 같은 기간에 대규모 쿠폰 할인 이벤트를 진행하고 있었다. 이런 경우 결제 전환율의 상승이 나의 개선안 덕분인지, 마케팅 팀의 쿠폰 이벤트 때문인지 정확히 측정하기 어렵다. A/B 테스트를 진행하게 되면 마찬가지로 이와 같은 변인들도 통제할 수 있다. 기존안과 개선안 모두 쿠폰 이벤트가 진행되는 시즌에 동일하게 이루어지기 때문이다.
이 외에도 A/B 테스트의 장점은 셀 수 없을 정도로 많지만, PM 입장에서는 A/B 테스트를 해야 하는 핵심 이유들은 이 정도로만 알아도 충분하다.
이름은 A/B 테스트이지만, 꼭 기존안과 개선안 2개만 테스트하라는 법은 없다. 개선안이 여러가지가 있다면 시안의 수를 틀려보아도 좋다. 예컨대 개선안이 3개라면 유저를 4그룹(기존안, 개선안1, 개선안2, 개선안3)으로 나누어 진행할 수도 있다.
A/B 테스트를 설계할 때 알아둬야 할 가장 중요한 것은 충분히 큰 수의 고객들을 확보해야 한다는 것이다.
예컨대 다음 상황을 생각해보자.
기존안 대비 개선안의 결제 전환율 결과가 좋게 나타났다. 그런데 개선안으로 배정된 고객들을 봤더니 우연히 첫 구매 할인 쿠폰을 받은 고객들이 유난히 많았다. 이 경우 결과 자체는 개선안이 좋았지만, 개선안이 실제 효과가 있었다기보다는 우연히 첫 구매 할인 쿠폰을 받은 고객들이 더 많이 배정되었기 때문에 결과가 좋았을 개연성이 훨씬 더 크다.
고객은 기존안과 개선안으로 랜덤 배정되지만, 랜덤인만큼 낮은 확률이지만 이런 경우는 충분히 발생 가능하다. 그렇다면 우리가 우연 요소는 배제할 수 없으므로, A/B 테스트의 결과가 좋게 나오더라도 항상 의심해봐야 할까?
다행인 점은 그렇지는 않다는 것이다. A/B테스트에 충분히 큰 숫자의 고객들이 들어와, 통계적 유의성이 확보된다면 그 실험 결과는 '통계적으로' 신뢰해도 된다. 이것의 원리를 통계적으로 더 자세히 설명하는 것은 중심극한정리(Central Limit Theorem)인데, 통게를 설명하는 글은 아니므로 간단한 원리만 설명하고자 한다.
위 사례로 돌아가 첫 구매자는 첫 구매 할인 쿠폰을 받는다고 해보자. 랜덤으로 분배한다고 해도 이 케이스처럼 개선안에 이러한 첫 구매자가 '우연히' 더 많이 배정될 수도 있다. 하지만 랜덤 분배되는 고객의 수가 '충분히' 커지게 된다면 이렇게 우연이 더 많이 배정되는 경우도 줄어들게 되어 이러한 우연 효과가 제거된다. 동전던지기를 할 때 앞면이 나올 확률은 50%이다. 그러나 처음 몇 번 던질 때는 앞면만 더 많이 나오거나, 뒷면만 더 많이 나올 수 있다. 그러나 동전던지기를 더 많이 하면 할 수록 그 확률은 50%에 가까워지는 것을 생각하면 쉽다.
A/B 테스트도 이러한 통계적 개념을 활용한다. 즉 기존안과 실험안에 충분히 많은 숫자의 고객이 랜덤 분포한다면, 우연 효과가 제거되어 각 집단의 특성이 균질하게 된다. 즉 첫 구매자도 기존안, 실험안 모두 비슷하게 분포된다는 것이다. (통계적 유의성을 확보하는 데 '충분히 큰 수'가 얼마인지에 대해서는 다음 글에서 설명하도록 하겠다)
이상으로 A/B 테스트의 기본 개념에 대해서 알아보았다. 다음 글에서는 A/B 테스트가 실무에서 어떻게 쓰이는지, 어떤 점들을 주의해야 하는지 등에 대해서 알아보도록 하겠다.