국내 1호 데카콘이 된 쿠팡, 2호 데카콘을 준비하고 있는 토스 덕분일까요? 아니면 핵클 때문일까요? 핵클이 창업한 2020년 이래로 국내 기업들이 제품 고도화 전략으로 A/B 테스트를 도입하고, 동시에 많은 테스트를 실행하기 위해 자체적으로 실험 플랫폼을 구축했다는 소식이 곳곳에서 들려옵니다.
글로벌 시장에서 A/B 테스트 플랫폼을 선도하고, 국내에 테스트 문화를 정착 시키고자 노력하는 핵클에게 너무 행복한 소식입니다. 하지만 때로는 A/B 테스트 플랫폼을 너무 쉽게 생각하는 것은 아닌가 라는 생각이 들기도 합니다. 그리고 섣부르게 도입한 실험 문화 탓에 오히려 실패와 손실만 경험한 채 실험에 대한 잘못된 인식이 퍼지는 것은 아닌가라는 생각도 듭니다.
A/B 테스트 잘못하면 어떤 손실이 발생하고, 오해가 쌓이는지 살펴볼까요?
모두가 A/B 테스트를 제대로 해서 쿠팡과 토스가 경험한 후퇴 없는 빠른 성장 여러분도 경험해 보기를 바랍니다.
조직의 리소스는 유한합니다. A/B 테스트에 소요되는 시간은 다른 곳에 사용할 수 없기 때문입니다. 조직은 유한한 시간을 어떻게 잘 사용하느냐에 따라 성장 궤도가 결정 됩니다. A/B 테스트는 위험(손실)을 회피하고 안정적으로 성장할 수 있는 전략이지만 리소스를 가장 효율적으로 활용하는 방법은 아닐 수 있습니다.
이렇게 생각하는 이유는 무엇일까요? 제품에 하나의 신규 기능이 출시 되기까지 많은 단계를 거치게 되는데, 이 과정에 실험을 포함한다면 실험 기간만 최소1~2주 소요 되기 때문입니다. 병렬적으로 많은 실험을 한번에 진행할 수 있다면 실험에 소요되는 시간이 낭비라고 생각되지 않겠지만, 일반적으로 실험을 처음 시도하는 조직에서는 하나의 실험을 시작하고 모니터링 단계를 거쳐 의사결정을 하고 나서야 비로소 새로운 실험을 설계하기 시작합니다.
이런 상황은 실험을 위한 개발에 추가로 투입되는 리소스 뿐만 아니라 데이터를 수집하고 집계해서 그 결과를 분석하는데 많은 시간이 소요 되기 때문입니다. 이를 해소하기 위해서는 반복되는 것들은 최대한 자동화 하는 것 입니다.
A/B 테스트의 80%는 실패한다고 합니다. 즉 대부분의 전환 (conversion) 테스트는 실패하고 실적이 저조한 변형 (treatment group)으로 인해 실행 중에 전환이 손실 된다는 것입니다. 하지만 A/B 테스트 단계를 거치면 손실은 “처치 그룹의 트래픽 / 전체 트래픽 x 손실 비율 x 실험 기간” 만큼 이지만, 테스트를 거치지 않고 즉시 기능이 릴리즈 되었다면 손실은 “전체 트래픽 x 손실 비율 x 기능이 유지된 전체 기간”이라는 사실을 잊지 않기를 바랍니다. 그리고 실패는 대조 그룹과 처치 그룹 사이의 차이 없음을 포함합니다. 여기서 주목해야 하는 것은 우리의 직관이 그만큼 믿을게 못 된다는 사실 입니다.
제 개인적인 경험을 이야기 하면, 제대로 테스트를 진행 했다면 80%이상 성공합니다. 왜 누구는 80%실패를 하고 누구는 80% 성공하는 걸까요?
그 차이는 가짜 실패에 있습니다.
A/B 테스트를 도입할 때 가장 먼저 걱정하는 것은 실험 때문에 사이트가 느려지고 이로 인해 궁극적으로 사용자 경험이 나빠져 제품에 부정적인 영향을 줄 수 있다는 것 입니다. 이것은 A/B 테스트가 진행되는 동안 실험에 참여한 사용자를 어떤 그룹에 할당(분배)할지를 결정하고, 일관되게 한 개의 그룹에만 할당되도록 유지하는 것을 어떻게 처리하는지에 따라 맞는 이야기 일 수도 있고, 틀린 이야기 일 수도 있습니다. 핵클의 경우 사용자를 할당할 때 별도의 서버 호출 없이 핵클에서 제공하는 SDK에서 처리하여 A/B 테스트 실행으로 인한 지연 이슈를 해결 하였습니다. 자체 플랫폼을 구축해 사용한다면 Latency를 측정하여 실험으로 인해 서비스 제공에 지연이 발생하지 않는지 꼭! 확인하기 바랍니다.
A/B 테스트가 사내 문화로 자리 잡게 되면 한 회사 내에서도 여러 팀이 여러 개의 테스트를 병렬적으로 진행하게 됩니다. 이 경우 각 팀들은 테스트 간에 상호작용이 발생하기 때문에 테스트 결과 = 효과를 확인하기 어렵다고 문제를 제기 할 수 있습니다. 하지만 각각 테스트의 효과 확인을 위해 한 영역에서 하나의 실험만 하도록 제약을 두는 것은 매우 비효율적이고, 수많은 팀들이 매번 서로 테스트 계획을 커뮤니케이션 하는 것도 현실적으로 불가능합니다. 이에 핵클에서는 개별 테스트 간에 상호작용 효과를 원천 차단할 수 있는 상호 배타 기능을 제공하고 있습니다.
뿐만 아니라 고객 서비스 측면에서는 고객이 어떤 단계에서 어떤 실험에 어떤 그룹에 속해 있는지 알지 못해 고객에게 적절한 대응을 하는데 어려움을 겪을 수 있습니다. 매번 고객 서비스 팀에게 어떤 실험이 진행 중인지 교육을 하는 것은 또 다른 비용입니다. 핵클의 개별 사용자가 진행 중인 실험에서 어떤 그룹에 배정 됐는지 조회할 수 있는 사용자 조회 기능 또한 제공하고 있습니다.
A/B 테스트는 조직의 의사 결정 속도를 늦춘다고 이야기를 합니다. 특히 초기단계 스타트업의 경우 트래픽이 적기 때문에 유의미한 테스트 결과를 얻기까지 시간이 오래 걸린다고 생각합니다. 하지만 이것은 A/B 테스트 경험이 적고, 의사결정 속도를 높일 수 있는 기법을 모르는 사람들이 하는 이야기 입니다.
저 역시 전 직장에서 음식 배달 신사업을 론칭하는 경험을 하지 않았다면 트래픽이 적은 상황에 (초창기 서울 송파구, 강남구에서만 서비스) 테스트가 무슨 의미가 있냐라고 이야기 했을 것 입니다. 하지만 초기 단계에 있는 서비스일 수록 사용자들이 서비스에 익숙해지기 전이기 때문에 작은 변화에도 지표들이 큰 폭으로 민감하게 변화합니다. 그리고 트래픽이 적은 상황에서 데이터 정확도를 높이기 위해 고려할 수 있는 기법들이 꽤 발전되어 있어 실험 비용과 조직의 리소스를 절약할 수 있습니다.
핵클에서는 p-value 외에 베이지안 확률, 극단치 제거, AI를 활용한 위너 그룹 추천, CUPED 등을 제공하여 보다 빠른 의사 결정을 내릴 수 있도록 지원하고 있습니다.
*AI를 활용한 위너 그룹 추천, CUPED는 베타 서비스로 일부 고객사에만 제공되고 있습니다.
조직들이 갖고 있는 리소스는 시간을 포함해 모든 것이 유한합니다. 이 유한한 리소스를 어떻게 효율적으로 활용해 매년 몇 개의 기능을 릴리즈하고 얼마나 서비스를 개선할 수 있는지 그 역량이 조직의 성장 궤적에 큰 영향을 미칩니다.
A/B 테스트는 분배하고 집계하고 이 두 가지가 끝 아니야? 라고 생각하실 수 있습니다. 그래서 그런지 핵클 SDK를 열어보고, 핵클 플랫폼을 벤치마크한 인하우스 A/B 테스트 플랫폼을 심심치 않게 만나곤 합니다. 하지만 이 두 가지로 실험 플랫폼을 구축했다는 것에 만족해서는 안됩니다.
아래와 같은 것들을 전혀 고려 하지 않았거나, 고민하고 있지 않다면 1~5 각각의 항목에 대해 엄청난 비용을 지금 지출하고, 실패를 위한 실험을 하고 있다는 사실을 명심해야 합니다.
핵클에는 이미 수년간 인하우스 A/B 테스트 플랫폼을 활용하며 수백 수천 건의 실험을 활용해 데이터 기반 의사 결정을 해온 PO와 데이터 사이언티스트가 있습니다. A/B 테스트를 도입하는 조직들이 우리가 이미 겪었던 시행착오를 한걸음 한걸음 따라 오지 않고 지름길로 한번에 가는데 이 포스팅이 도움이 되길 바랍니다.
.png)
.jpg)
.jpg)