우리가 A/B 테스트에 대해 잘못 알고 있는 것들
Myths about A/B test
제품개발에 있어서 A/B 테스트는 Sanity Check(온전성 검사)의 목적이 가장 큽니다. 실제로 새롭게 출시 (또는 변경) 되는 기능이 기존 안 대비, 좋은 효과를 가지는지를 확인하고, 만약 그렇지 않다면, 출시를 연기하고 개선을 하는 것이죠. 이런 A/B 테스트라는 제품 개발 방법론을 설명하며 가장 많이 들었던 오해 3가지에 대하여 소개 드리려 합니다.
1.A/B 테스트는 A(기존 안)보다 B(신규 안)로 종료되어야 효과가 있다.
“A/B 테스트를 했는데 A(기존 안) 대비 B안 (신규 안)의 결과가 좋지 않게 나와서, A/B 테스트를 잘못한 거 같아요”. 이와 같은 오해는 가장 빈번하게 접하는 오해입니다. A/B 테스트를 사용하는 목적은 정확하게 반대입니다. 신규 안의 결과가 기존보다 좋지 않은 경우를 체크하고, 이를 신규 안을 개선하기 위해 사용하는 것이죠.
A/B 테스트를 하지 않았을 경우를 생각해 보면 이유가 분명해집니다. A/B 테스트 없이 신규 기능 (또는 변경)을 적용할 경우, B 안은 A 안과 비교 없이 출시가 됩니다. 이와 같은 무조건적인 출시는 B 안이 A 안보다 좋았을 경우에는 문제가 되지 않지만, 그 반대일 경우에는 조직의 목표 달성을 방해하는 요인이 되죠. 이런 경우를 확인하고 출시를 연기하고, 수정할 지점을 찾기 위해서 A/B 테스트가 사용되는 것이죠. 따라서, A/B 테스트를 이용하였을 때, 기존 안이 신규 안보다 더 좋은 지표를 보이는 경우가 많다면 A/B 테스트를 통하여, 더 많은 효과를 보시고 있는 것입니다. 서비스가 고도화될 수록, 신규 출시 기능이 한 번에 A/B 테스트를 통과하고 출시될 확률은 낮아집니다. 굉장히 고도화된 서비스들의 경우 이런 확률이 20% 내외에 불과하죠.
2. A/B 테스트를 하면 리소스가 더 들어간다.
이 질문에 대한 “답은 그럴 수 있다 하지만 꼭 필요한 과정이다 입니다. 많은 분들께서 A/B 테스트를 하려면 테스트를 위한 시안들을 만들어야 한다고 생각합니다. 하지만, A/B 테스트에 원래 목적이 신규로 출시하기로 했던 기능이 실제로 기존 안 보다 좋은지를 확인하는 것이라는 점을 고려하면, A/B 테스트를 위하여 새롭게 만들 시안은 존재하지 않습니다. 즉 테스트 자체가 목적이 되지 않는 한, 추가로 투입해야 할 리소스는 거의 없는 거죠.
단, 리소스가 더 투입될 수 있는 경우는 테스트를 진행했을 시, 새로운 안 (신규로 개발한 기능)이 기존 안보다 결과가 좋지 않게 나오는 경우에 발생합니다. 결과가 좋지 않은 신규 기능, 디자인, Business logic 등을 그대로 배포하지 않고, 다시 내부로 가져와 수정을 하게 되죠. 이에 따라, 수정에 필요한 리소스가 추가로 투입되게 되고, 기능 출시는 늦어집니다. 하지만, 회사의 중요한 지표들에 나쁜 영향을 주는 신규 안을 수정을 해서 출시해야 하는 건 당연하다고 생각됩니다.
3. A/B 테스트를 할 때는, 신규안을 하나로만 한정해야 한다.
테스트 안의 숫자 제한은 없습니다. 10개를 동시에 하셔도, 100개를 동시에 하셔도 괜찮습니다. 실제로 Google은 클릭 Button의 색상에 대한 테스트를 50가지 안으로 진행한 것으로 알려져 있습니다. 여러 가지 안을 테스트할 때 고려할 점은 2가지입니다.
첫째, 여러 가지 안을 동시에 테스트하면 traffic이 분산되어, 통계적 유의미성에 도달하는 시간이 증가할 수 있다. Traffic이 많은 서비스라면 이와 같은 점은 문제가 아닐 수 있지만, traffic이 많지 않은 서비스 또는 특정 page에서의 실험이라면 traffic의 분산은 실험을 방해하는 요소가 됩니다. 두 번째, 개발 또는 디자인 리소스가 추가로 너무 많이 들어가면 안 된다. 테스트는 Sanity Check가 주요 목적이 되어야지, 테스트 자체가 목적이 되면 안됩니다. Google의 버튼색상 변경테스트를 50가지 안으로 진행한 이유도 이런 2가지 고려사항에서 큰 문제가 없었기 때문입니다.
