A/B 테스트 설계 시 흔한 실수

 

A/B 테스트를 처음 돌려봤을 때는, 그냥 두 버전을 나눠서 보여주고 숫자가 높은 쪽을 고르면 되는 거라고 생각했습니다.
실제로 몇 번 돌려보니 그렇게 간단한 일이 아니었어요.
저희 팀이 겪었던 실수들을 정리해봅니다.
비슷한 실수를 반복하고 있는 분들이라면 도움이 되지 않을까 싶어요.

 

저희가 처음 돌린 A/B 테스트는 표본 크기 계산 없이 그냥 "일주일 돌리고 보자"는 식으로 시작했습니다.
일주일 뒤 숫자를 보니 B안이 A안보다 전환율이 0.3%포인트 높았고, 팀은 신나서 B안을 채택했어요.
그런데 알고 보니 그 구간 트래픽으로는 0.3%포인트 차이를 통계적으로 신뢰할 수 있는 최소 표본에 한참 못 미쳤습니다.
결국 B안을 전체 적용하고 한 달을 지켜봤는데, 처음 기대했던 개선 효과가 전혀 나타나지 않았어요.
그 이후로는 테스트를 시작하기 전에 반드시 필요한 표본 크기와 예상 기간을 먼저 계산하고, 그 기간을 채우지 못하면 결과를 아예 보지 않기로 팀 규칙을 정했습니다.

 

두 번째로 자주 하는 실수는, 테스트할 때 버튼 색, 문구, 배치를 한꺼번에 다 바꾸는 겁니다.
저희도 결제 페이지 개편 테스트를 할 때 이 실수를 했어요.
버튼 색을 바꾸고, 문구도 바꾸고, 배치도 바꾼 버전을 A안과 비교했는데, 결과는 좋게 나왔지만 "정확히 뭐가 효과가 있었는지"는 알 수 없었습니다.
다음 프로젝트에 그 학습을 재사용하고 싶어도, 세 가지 중 뭐가 진짜 원인인지 알 수가 없으니 재사용이 안 되더라고요.
이후로는 한 테스트에 하나의 변수만 바꾸는 걸 원칙으로 삼았고, 시간이 조금 더 걸리더라도 확실한 인사이트를 쌓는 쪽을 택했습니다.

 

트래픽이 아주 많은 페이지에서는, 아주 작은 차이도 통계적으로 유의하다고 나올 수 있습니다.
저희도 한 번은 전환율이 0.05%포인트 차이인데 p-value가 낮게 나와서 "유의미한 결과"라고 보고했던 적이 있어요.
그런데 이 0.05%포인트가 실제로 매출이나 사용자 경험에 의미 있는 변화인지는 별개의 질문이었습니다.
통계적으로 유의하다는 것과 비즈니스적으로 의미가 있다는 것은 다른 이야기라는 걸 이때 배웠고, 이후로는 결과를 보고할 때 반드시 "이 차이가 실제로 어떤 의미인가"를 같이 적기로 했습니다.

 

테스트 초반에 한쪽이 확 앞서 나가면, 그 결과를 보고 바로 테스트를 중단하고 싶은 유혹이 생깁니다.
저희도 이틀 만에 B안이 크게 앞서는 걸 보고 조기 종료했다가, 나중에 다시 돌려보니 주중과 주말 사용자 패턴이 달라서 벌어진 일시적인 차이였다는 걸 알게 됐어요.
초반 며칠의 숫자만 보고 판단하면 요일별 편차, 특정 이벤트나 프로모션 효과 같은 것들을 놓치기 쉽습니다.
저희는 이후로 최소 1~2주기(보통 2주)는 채우고, 요일별 패턴이 한 바퀴는 돌고 난 뒤에 결과를 보는 걸 기본으로 하고 있습니다.

 

마지막으로 가장 무서운 실수는, 결과를 보고 싶은 대로 해석하는 것이었습니다.
새로운 디자인에 애착이 큰 팀원이 진행한 테스트에서, 결과가 애매하게 나왔는데도 "이 부분만 보면 사실 개선된 거다"라는 식으로 유리한 지표만 골라서 보고하는 걸 본 적이 있어요.
저도 제가 밀었던 아이디어의 테스트 결과가 안 좋게 나왔을 때, 은근히 다른 지표를 찾아서 정당화하려던 순간이 있었습니다.
그래서 저희 팀은 테스트를 시작하기 전에 "무엇을 성공 지표로 볼 것인가"를 미리 문서로 못 박아두고, 결과가 나온 뒤에는 그 지표만 보기로 규칙을 만들었어요.
결과가 나온 뒤에 지표를 고르면, 사람은 누구나 자기가 원하는 결론을 뒷받침하는 숫자를 찾아내기 마련이더라고요.

 

A/B 테스트는 도구일 뿐이고, 이 도구를 제대로 쓰려면 결국 통계에 대한 최소한의 이해와, 결과를 냉정하게 받아들이는 태도가 같이 필요하다는 걸 여러 번의 실수를 통해 배웠습니다.

저희 팀도 여전히 완벽하지는 않지만, 적어도 이 다섯 가지 실수는 이제 서로 체크해주는 문화가 생겼어요.
다음 분기에는 테스트 설계 체크리스트를 팀 위키에 정식으로 등록해서, 새로 합류하는 팀원들도 같은 실수를 반복하지 않게 해보려고 합니다.