A/B 테스트가 필요한 순간과 필요 없는 순간

 

A/B 테스트를 알게 되면 한동안은 모든 결정을 테스트로 하고 싶어집니다.
저도 그랬어요.
버튼 문구도, 아이콘 모양도, 배너 순서도 일단 둘로 나눠서 돌려보자는 생각이 들더라고요.
그런데 하다 보니 테스트가 오히려 일을 느리게 하거나, 아무 결론도 못 내는 경우를 몇 번 만났습니다.
오늘은 테스트를 하는 것이 맞는 순간과 하지 않는 편이 나은 순간을 나눠서 정리해 봅니다.

 

먼저 테스트가 제 몫을 하는 경우입니다.

첫째, 결과를 되돌리기 어렵거나 영향이 큰 변경일 때입니다.
가입 과정을 통째로 바꾸거나 결제 화면의 흐름을 바꾸는 것처럼 수익이나 핵심 지표에 크게 닿는 변경은 일부 사용자에게 먼저 시험해 보는 것이 안전합니다.

둘째, 팀 안에서 의견이 팽팽하게 갈릴 때입니다.
서로 다른 안이 모두 그럴듯하고 근거가 비슷하다면 실제 사용자의 반응이 가장 공정한 심판이 됩니다.
가정해 보면 두 안의 문구가 "지금 시작하기"와 "무료로 둘러보기"인데 어느 쪽이 주저하는 마음을 덜어 줄지 의견이 반반인 경우예요.

셋째, 작은 차이가 큰 숫자가 되는 곳일 때입니다.
방문자가 많은 화면에서 전환율이 조금만 올라도 전체 결과가 달라진다면, 작은 개선을 정확히 측정하는 가치가 있습니다.

넷째, 감으로 한 번 해 본 개선이 정말 효과가 있었는지 확인하고 싶을 때입니다.
개선 후 숫자가 오르면 기쁘지만, 마침 그 주에 이벤트가 있었다면 개선의 효과인지 알 수 없습니다.
같은 시기에 나눠서 비교하면 이런 혼란이 줄어요.

 

 

테스트가 필요 없는 순간 첫째, 트래픽이 부족할 때

 

가장 흔한 경우가 이것입니다.
가정해 보겠습니다. 어떤 화면의 하루 방문자가 50명이고, 전환율이 5퍼센트 안팎이라고 해요.
이 화면을 둘로 나누면 한 그룹에 하루 25명 정도입니다.
전환이 하루에 한두 명 생기는 수준에서는, 어느 한쪽에서 몇 명이 더 가입했다는 차이가 우연인지 아닌지 가려내려면 몇 달이 걸릴 수도 있어요.
그 기간 동안 서비스도 사용자 구성도 계속 변하기 때문에 결과가 있어도 믿기 어려워집니다.

이런 경우에는 테스트 대신 사용자 몇 명을 직접 만나 관찰하는 쪽이 훨씬 빠르고 많은 것을 알려 줍니다.
다섯 명 정도만 지켜봐도 같은 지점에서 반복해서 막히는 문제는 대부분 드러나더라고요.

 

 

테스트가 필요 없는 순간 둘째, 개선이 명백할 때

 

누가 봐도 고쳐야 하는 문제는 테스트하지 않고 그냥 고치는 것이 맞습니다.

예를 들어 모바일 화면에서 버튼이 너무 작아 손가락으로 누르기 어렵다거나, 오타가 있다거나, 눌러도 아무 반응이 없는 링크가 있다면 그것은 가설이 아니라 오류예요.
이런 것을 두 갈래로 나눠서 일부 사용자에게는 오류를 그대로 보여 주는 것은 오히려 사용자에게 미안한 일이라고 생각합니다.

접근성이나 법적으로 필요한 안내처럼 반드시 해야 하는 일도 마찬가지입니다.
하지 않는 쪽이 선택지가 될 수 없는 변경은 테스트의 대상이 아니에요.

 

 

테스트가 필요 없는 순간 셋째, 비용 대비 얻는 것이 작을 때

 

테스트에는 눈에 보이지 않는 비용이 들어갑니다.
두 가지 안을 만드는 디자인과 개발 시간, 설정과 검증 시간, 결과를 기다리는 시간, 끝난 뒤 한 가지 안을 정리하는 시간이 모두 비용이에요.

가정해 보면, 이 모든 과정에 두 주가 걸렸는데 얻을 수 있는 최대 효과가 방문자가 거의 오지 않는 화면의 아주 작은 개선이라면 투자가 맞지 않습니다.
이럴 때는 더 영향이 큰 곳에 시간을 쓰는 것이 낫습니다.

또 하나, 되돌리기 쉬운 변경이라면 일단 바꾸고 숫자를 지켜보는 방법도 충분히 쓸 만합니다.
문제가 보이면 다시 돌리면 되니까요.
다만 이때는 전후 비교의 한계를 알고 해석해야 합니다.

테스트를 하지 않기로 했다고 해서 아무 확인도 하지 않는다는 뜻은 아닙니다.
트래픽이 적을 때는 변경 전후의 숫자를 기록해 두고, 사용자 몇 명의 반응을 곁들여 판단하는 가벼운 방식도 괜찮은 선택이에요.
중요한 것은 "확인하지 않고 넘어가는 것"과 "더 가볍게 확인하는 것"을 구분하는 일입니다.

한 가지 장면을 더 가정해 볼게요.
팀에서 상세 화면의 후기 영역을 위로 올릴지 아래에 둘지 의견이 갈렸고, 방문자는 하루 수천 명이라고 합니다.
이런 경우는 표본이 충분하니 테스트로 가려 보기에 좋은 주제입니다.
반대로 같은 팀이 방문자가 거의 없는 소개 페이지의 문구를 두고 같은 논쟁을 한다면, 저는 테스트를 권하지 않고 그냥 한쪽으로 정해서 가 보자고 말할 것 같아요.
같은 도구라도 어떤 화면에 쓰느냐에 따라 가치가 이렇게 달라집니다.

 

저는 테스트를 할지 말지 고민될 때 이런 질문을 던져 봅니다.

1. 이 변경이 틀렸을 때 피해가 큰가요?
2. 의견이 정말 갈리고 있나요, 아니면 이미 답이 보이나요?
3. 정해진 기간 안에 의미 있는 표본이 모일 수 있나요?
4. 결과에 따라 실제로 내가 다르게 행동할 건가요?

마지막 질문이 특히 중요해요.
어느 쪽이 이겨도 어차피 같은 안을 쓸 예정이라면 테스트는 시간 낭비입니다.

 

테스트는 좋은 도구이지만, 모든 결정을 대신해 주는 도구는 아닌 것 같습니다.
오히려 언제 쓰지 않을지를 아는 것이 도구를 잘 쓰는 첫걸음이라는 생각이 들어요.

남은 질문은 이것입니다.
트래픽이 부족한 초기 서비스에서 정성 관찰만으로 결정하는 것이 얼마나 위험한지, 그리고 그 위험을 줄이는 방법은 무엇인지 앞으로 더 사례를 보며 정리해 보려고 합니다.