A/B 테스트에서 이겼는데 왜 매출은 그대로일까요?
A/B 테스트가 실패하는 가장 흔한 원인은 아이디어가 아니라 설계 전에 숫자를 정하지 않은 것입니다. 검정력 80%와 유의수준 5%라는 기본값에서 최소 검출 효과(MDE)와 표본 크기는 하나로 묶여 움직입니다. 표본을 두 배로 늘리면 검출 가능한 효과 크기는 약 30% 작아집니다. 반대로 작은 트래픽에서 5% 개선을 잡겠다고 하면 필요한 기간이 몇 달로 늘어납니다. 그런데 현장에서는 이 계산 없이 "일주일 돌려 보고 이긴 쪽"을 고릅니다. 그렇게 고른 승자가 다음 달에 사라지는 일이 반복됩니다. 테스트 설계는 버튼 색을 고르는 일보다 의사결정의 오류율을 정하는 일에 가깝습니다.
목차
- 전환율 18% 상승이 한 달 만에 사라진 이유
- A/B 테스트는 실제로 무엇을 측정하나요
- MDE와 표본 크기는 어떻게 정하나요
- 결과를 미리 들여다보는 피킹이 왜 문제인가요
- 테스트 도구는 무엇을 보고 고르나요
- 실험이 망가지는 다섯 가지 흔한 지점
- 실험 설계 체크리스트 4단계
- FAQ
- 같이 읽으면 좋은 것들
전환율 18% 상승이 한 달 만에 사라진 이유
고객 경험 개선 프로젝트를 함께한 한 이커머스 팀의 기록입니다. 결제 페이지의 버튼 문구를 "구매하기"에서 "지금 주문하기"로 바꾸는 테스트였습니다. 6일 차에 전환율이 대조군 대비 18% 높게 나왔고 팀은 환호했습니다. 바로 전체 적용을 결정했습니다.
한 달 뒤 전체 전환율은 테스트 이전과 통계적으로 구분되지 않는 수준이었습니다. 되짚어 보니 문제가 세 겹이었습니다.
첫째, 표본이 작았습니다. 각 그룹에 배정된 방문자가 1,400명 남짓이었습니다. 기준 전환율 2.1%에서 이 표본으로 검출 가능한 최소 효과는 상대 40%대였습니다. 18%라는 숫자는 애초에 신뢰 구간 안에서 흔들리는 범위였습니다.
둘째, 매일 결과를 확인하며 유의미해지는 순간에 멈췄습니다. 이것이 피킹입니다. 결과를 반복해서 들여다보고 원하는 숫자가 나올 때 중단하면 거짓 양성 비율이 설정값인 5%를 훨씬 넘어갑니다.
셋째, 기간이 6일이었습니다. 주말과 평일의 구매 패턴이 다른 업종인데 한 주기를 채우지 않았습니다. 테스트 시작일이 화요일이라 주말이 한 번만 들어갔습니다.
세 가지 모두 돈이 드는 문제가 아니었습니다. 시작 전에 종이 한 장에 숫자를 적어 두었으면 피할 수 있는 일이었습니다.
A/B 테스트는 실제로 무엇을 측정하나요
A/B 테스트는 "B가 A보다 낫다"를 증명하는 도구가 아닙니다. "관측된 차이가 우연만으로 생기기 어려운 정도인가"를 판정하는 도구입니다. 이 차이를 혼동하면 결과 해석이 어긋납니다.
유의수준 5%는 실제로 차이가 없는데 있다고 판단할 확률을 5%로 통제하겠다는 선언입니다. 검정력 80%는 설정한 크기의 효과가 실제로 존재할 때 그것을 탐지할 확률이 80%라는 뜻입니다. 같은 실험을 100번 반복하면 약 80번은 유의한 결과가 나오고 20번은 결론을 못 내린다는 계산입니다.
여기서 자주 생기는 오해가 하나 있습니다. "유의하지 않다"는 "효과가 없다"가 아닙니다. 표본이 작아 못 잡았을 뿐일 수 있습니다. 검정력이 낮은 실험에서 나온 음성 결과로 아이디어를 폐기하는 것은 데이터 기반 의사결정이 아니라 데이터 모양을 한 직감입니다.
반대쪽 오해도 있습니다. 유의한 결과가 나왔다고 해서 효과 크기가 크다는 뜻은 아닙니다. 표본이 아주 크면 0.3% 차이도 유의해집니다. 그래서 판단에는 통계적 유의성과 실무적 의미 두 가지를 함께 봐야 합니다. 0.3% 개선을 위해 개발 2주를 쓰는 것이 맞는지는 통계가 답하지 않습니다.
MDE와 표본 크기는 어떻게 정하나요
최소 검출 효과는 "이 정도는 잡아내겠다"고 사전에 선언하는 효과 크기입니다. 네 가지 입력값이 서로 묶여 있습니다. 기준 전환율, MDE, 유의수준, 검정력입니다. 셋을 정하면 나머지 하나가 결정됩니다.
관계를 체감하려면 아래 숫자를 보시면 됩니다. 기준 전환율 3%, 유의수준 5%, 검정력 80%를 고정했을 때의 그룹당 필요 표본입니다.
| 잡고 싶은 상대 개선폭 | 그룹당 필요 표본(근사) | 일 방문 2,000명 기준 소요 기간 |
|---|---|---|
| 상대 5% | 약 250,000명 | 250일 |
| 상대 10% | 약 63,000명 | 63일 |
| 상대 20% | 약 16,000명 | 16일 |
| 상대 30% | 약 7,000명 | 7일 |
표를 위에서 아래로 내려 읽으면 규칙이 하나 보입니다. 작은 개선을 잡으려면 표본이 제곱에 가깝게 불어납니다. MDE를 절반으로 줄이면 필요 표본은 네 배가 됩니다. 반대로 표본을 두 배로 늘리면 검출 가능한 효과는 약 30% 작아집니다.
그래서 트래픽이 적은 서비스에서는 전략이 달라져야 합니다. 작은 변화를 여러 번 테스트하는 방식은 수학적으로 불가능합니다. 선택지는 세 가지입니다. 큰 변화를 과감하게 시도하거나, 지표를 전환율보다 상위 퍼널의 클릭률처럼 발생 빈도가 높은 것으로 바꾸거나, 테스트 기간을 몇 주 단위로 길게 잡는 것입니다.
사후 검정력 계산은 하지 않는 편이 낫습니다. 실험이 끝난 뒤 관측된 효과로 검정력을 역산하는 것은 통계적으로 의미가 없고 오해만 키웁니다. 검정력 분석은 실험 시작 전에 끝나야 하는 작업입니다.
결과를 미리 들여다보는 피킹이 왜 문제인가요
대시보드가 실시간이라 유혹이 큽니다. 매일 들어가 보고 유의미해 보이면 멈추고 싶어집니다.
그런데 이렇게 하면 오류율 통제 자체가 깨집니다. 전환율 차이는 누적 데이터가 쌓이는 동안 위아래로 흔들립니다. 반복해서 들여다보다 가장 유리한 순간에 멈추면 실제로는 차이가 없는데도 유의하다고 판정할 확률이 올라갑니다. 매일 확인하며 2주를 돌리면 거짓 양성 비율이 설정값의 서너 배로 뛴다는 시뮬레이션 결과가 여러 차례 보고됐습니다.
해법은 두 갈래입니다. 고전적인 방법은 시작 전에 표본 크기와 종료 조건을 못 박고 그때까지 결과를 보지 않는 것입니다. 운영상 어렵다면 순차 검정이나 베이지안 방식처럼 중간 확인을 전제로 설계된 통계 방법을 쓰는 것이 맞습니다. 요즘 실험 플랫폼 상당수에 이 기능이 들어 있습니다.
어느 쪽을 고르든 종료 규칙을 미리 정해 두는 것이 먼저입니다. 규칙 없이 눈으로 판단하기 시작하면 그 실험은 가설 검증에서 멀어져 확증 편향을 확인하는 도구가 됩니다.
테스트 도구는 무엇을 보고 고르나요
도구 선택에서 기능 목록을 비교하는 것은 생각보다 덜 중요합니다. 순서로는 운영 방식이 먼저입니다.
클라이언트 사이드 방식은 브라우저에서 자바스크립트로 화면을 바꿉니다. 설치가 간단하고 비개발 직군이 직접 실험을 만들 수 있습니다. 대신 원래 화면이 잠깐 보였다가 바뀌는 깜빡임이 생기고 페이지 속도에 부담을 줍니다. 마케팅 랜딩 페이지 중심이라면 합리적인 선택입니다.
서버 사이드 방식은 서버에서 분기를 처리합니다. 깜빡임이 없고 가격 정책이나 추천 로직처럼 화면 밖의 변경도 테스트할 수 있습니다. 대신 개발 리소스가 필요합니다. 제품 자체를 실험하는 조직이라면 이쪽이 맞습니다.
기능 플래그 기반 플랫폼은 배포와 실험을 한 체계로 묶습니다. 점진적 롤아웃과 A/B 테스트를 같은 도구로 관리하므로 엔지니어링 문화가 자리 잡은 팀에 적합합니다.
비용을 볼 때는 표시 가격보다 과금 단위를 확인하셔야 합니다. 월 활성 사용자 기준인지, 실험 참여 이벤트 수 기준인지에 따라 같은 트래픽에서도 청구액이 몇 배 차이 납니다. 무료 플랜의 월 사용자 한도를 넘기면 다음 달 요금이 갑자기 뛰는 구조도 흔합니다.
마지막으로 데이터 소유권을 보십시오. 실험 원천 데이터를 내 창고로 내보낼 수 있는지, 분석을 도구 안에서만 해야 하는지가 1년 뒤의 분석 자유도를 가릅니다. 도구를 바꿀 때 과거 실험 기록이 통째로 묶이면 곤란합니다.
실험이 망가지는 다섯 가지 흔한 지점
통계 설계를 제대로 했는데도 결과가 쓸모없어지는 경우가 있습니다. 대개 운영 쪽에서 생깁니다.
첫째, 배정이 섞입니다. 같은 사용자가 기기를 바꾸거나 로그아웃 상태로 다시 들어오면 다른 그룹에 배정되는 일이 생깁니다. 쿠키 기반 배정의 고질적인 한계인데요. 로그인 사용자는 사용자 ID로, 비로그인은 기기 식별자로 배정 키를 나누고 두 집단을 섞어 해석하지 않는 쪽이 안전합니다.
둘째, 실험 기간에 다른 변화가 겹칩니다. 할인 행사, 대규모 광고 집행, 언론 노출이 들어오면 양쪽 그룹에 똑같이 영향을 주더라도 사용자 구성 자체가 바뀝니다. 평소와 다른 유입이 섞인 기간의 결과는 평시에 그대로 적용되지 않습니다.
셋째, 지표 정의가 도중에 바뀝니다. 전환을 "결제 완료"로 세다가 "장바구니 담기"를 포함하는 식의 변경이 실험 중간에 일어나면 비교가 깨집니다. 지표 정의서를 실험 시작 시점에 고정해 두어야 합니다.
넷째, 한쪽 그룹에만 버그가 있습니다. 특정 브라우저에서 신규 변형의 버튼만 눌리지 않는 상황이 실제로 자주 발생합니다. 점검 지표로 그룹별 오류율과 페이지 로딩 시간을 함께 보면 조기에 잡힙니다.
다섯째, 승자를 적용한 뒤 기록을 남기지 않습니다. 반년 뒤에 같은 아이디어가 다시 올라오고 또 테스트합니다. 실험 대장을 한 곳에 모아 가설, 설계값, 결과, 적용 여부를 적어 두면 조직의 학습 속도가 달라집니다. 실패한 실험일수록 기록 가치가 큽니다.
실험 설계 체크리스트 4단계
1단계. 가설을 한 문장으로 적습니다. "결제 버튼 문구를 바꾸면 전환율이 오를 것이다"가 아니라 "주문 직전 망설임이 이탈 원인이라면 행동을 명시한 문구가 결제 완료율을 상대 20% 높일 것이다"처럼 적습니다. 추정 원인과 기대 효과 크기가 함께 들어가야 합니다.
2단계. 지표를 세 층으로 나눕니다. 판정에 쓸 주 지표 하나, 부작용을 감시할 보조 지표 두세 개, 실험이 제대로 돌아가는지 보는 점검 지표를 구분합니다. 전환율이 올랐는데 환불률이 함께 올랐다면 그 실험은 성공이 아닙니다.
3단계. 표본과 기간, 종료 조건을 미리 적습니다. MDE를 정하고 계산기로 표본을 구한 뒤 하루 트래픽으로 나눠 기간을 산출합니다. 최소 한 주기, 가능하면 두 주기를 포함하도록 잡습니다. 그리고 "이 날짜 이전에는 결과를 보지 않는다"를 문서에 남깁니다.
4단계. 결과를 네 칸으로 해석합니다. 유의했는가와 실무적으로 의미 있는 크기인가를 교차하면 네 경우가 나옵니다. 유의하고 크면 적용, 유의하지만 작으면 비용 대비로 판단, 유의하지 않고 효과 추정치가 크면 표본을 늘려 재실험, 둘 다 아니면 종료입니다. 이 네 칸을 미리 정해 두면 결과를 보고 나서 기준을 바꾸는 일이 줄어듭니다.