A/B테스트가 정답은 아닙니다.

A/B테스트는 데이터 기반 의사결정의 기준으로 자리 잡고 있습니다. 특히 기업들이 제품 주도형 로드맵으로 전환하며 이젠 버튼 색상, 헤드라인, 기능 출시 까지 모두 과학적 실험을 거쳐야 할 것 처럼 보입니다.

하지만 문제는 모든 의사결정이 A/B를 필요로 하는것은 아닙니다.(A/B는 이제 테스트라고 치환) 무작정 테스트를 돌리다보면 속도는 느려지고 리소스는 낭비되며 심지어 잘못된 결론을 낼 수 있습니다.

다름에 또 하나의 시험을 론치 전 아래 10가지 이유를 고민하세요

 

1. 트래픽이 부족할 경우

테스트는 충분한 트래픽이 있어야 통계적으로 유의미한 결과를 얻을 수 있습니다. 트래픽이 적다면 테스트 결과가 나오기까지 오랜 시간이 걸릴겁니다. 실험을 시작하기 전에 표본 크기 계산기를 사용해 필요한 사용자 수를 추정하세요.

많은 팀이 아이디어에 들떠서 테스트를 시작하겠지만 나중에서야 결과를 얻기까지 예상보다 훨씬 오래 걸린다는 사실을 깨닫곤 합니다. 예를 들어, 월간 사용자 500명 규모의 스타트업이 있다고 가정합시다. 전환율이 2%이고, 두가지 버전을 테스트하고 5% 향상을 감지하려면 1,254일이 걸립니다.

 

2. 뭘 해야할지 모르겠으니 다변량 테스트하자

다변량 테스트는 가장 비용이 많이 드는 실험 방식 중 하나입니다. A/B/C 테스트를 돌린다는 것은 디자인, 개발, 데이터 팀이 모두 결과를 만들고 분석하는데 시간을 쓰게 된다는 뜻이죠.

모든걸 한번에 테스트 해야 할까요? 아니면 순차적으로 해야할까요?

대부분의 경우 구조적이고 단계적인 접근이 적은 리소스로 더 나은 인사이트를 줍니다.

3. 명확한 가설이 없는 경우

테스트를 시작하기 전 이렇게 물어보세요

• 성공하면 무엇을 배우는가?
• 실패하면 무엇을 배우는가?

가설없이 테스트를 하면 결과를 해석하기 어려워지고, 시간과 자원이 낭비될 수 있습니다.

Posthog에서 이메일 가입 대신 소셜 로그인 버튼을 테스트 했을 때, 소셜 로그인을 통한 가입은 늘었지만 전체 가입수는 변하지 않았습니다. 이 실험은 소셜 로그인이 더 나은지에 대한 명확한 학습을 주지 못했습니다.

 

4. 기술 부채 누적

테스트는 장기적으로 기술 부채를 쌓을 수 있습니다. 테스트를 위해 작성된 코드가 제대로 정리되지 않으면 코드베이스가 복잡해져 향후 개발속도가 느려지고 오류 가능성이 커집니다.

특히 중요한 경로에 얽힌 테스트 코드는 나중에 정리하기가 매우 어렵습니다. 실제로 어떤 회사에서는 온보딩전환율 개선 테스트를 진행했는데, 3년이 지나도록 테스트 코드를 정리하지 못했습니다.

 

5. 변화가 너무 미미한 경우

단어 하나 바꾸는 수준의 작은 수정도 성과를 낼 수있지만 모든 사소한 변경을 테스트하기 시작하면 개발 속도가 떨어지고 직관적 의사결정을 회피하게 됩니다. 테스트는 중요한 결정을 검증하는데 써야지, 직관을 완전히 대체하는 도구가 되어선 안됩니다.

 

6. 위험 부담이 너무 큰 경우

가격 변경, 홈페이지 전면 개편처럼 잘못하면 사용자 신뢰를 훼손할 수 있는 변화는 테스트를 시도하기 위험합니다. 예를 들어 유료 상품이 갑자기 프리미엄 모델을 실험한다면 기존 유저 반발과 이탈을 불러올 수 있습니다. 이런 경우엔 정성조사나 단계적 롤아웃이 더 안전합니다. 일부 변화는 한번 가면 되돌릴 수 없는 문이므로 더욱 신중해야 합니다.

 

7. 한번에 너무 많은 변수를 변경한 경우

한 실험에 너무 많은 요소를 바꾸면 어떤 변경이 결과에 영향을 준건지 알 수 없습니다. Airbnb가 디자인언어, 홈페이지, 메시징, 네비게이션을 한번에 변경한 경우, 예약이 감소하면 무엇때문인지 알기 어려워집니다. 테스트는 가설 하나에 맞춰 설계하고 변경 범위를 제한해야합니다.

 

8. 실험간 간섭

동시에 너무 많은 테스트를 돌리면 서로 영향을 주어 결과 해석이 어려워집니다. 같은 화면, 같은 지표를 목표로 하는 테스트라면 오디언스를 분리해야 합니다. 그렇지 않으면 특정 실험의 효과를 단정짓기 어렵습니다.

도어대쉬는 이런 간섭을 줄이기 위해 정교한 트래픽분배와 실험 스케줄링을 합니다.

 

9. 위원회식 의사결정 회피

팀이 결정을 못내려 테스트로 밀어버리는 경우가 있습니다. 이건 실험을 학습 도구가 아니라 회피 수단으로 만드는 겁니다. 테스트를 하기 전, 팀이 정말 어떤 가설과 방향성을 갖고 있는지 먼저 정리해야합니다. 가능성이 너무 많다면 우선순위를 좁히는게 학습의 핵심입니다.

 

10. 계절성 무시

많은 제품이 계절에 따라 지표 변동을 겪는데, 이를 고려하지 않고 실험을 진행하는 경우가 많습니다. 

페이스북은 연말에 트래픽이 급증해 테스트 결과가 왜곡될 수 있습니다. 12월에 성공한 버전이 2월에도 통할거란 보장은 없습니다.

B2B의 경우 예산 배정 시기에 따라 구매패턴이 변하므로 이런 시기에 실험하면 편향될 수 있습니다.