인터넷 시대의 과학적 방법론, A/B 테스트
A/B testing
A/B testing이란?
A/B testing은 웹이나 앱에서 A버전과 B버전을 무작위로 유저들에게 보여주고 어떤 것이 나은지 실험하는 방법이다. 각 버전을 본 유저의 행동 데이터를 통계적으로 분석하여 특정한 변화를 주었을 때 목표를 더 높게 달성하는지 알아낼 수 있다.
사실 A/B testing은 오래전부터 과학에서 쓰여왔던 대조 실험(Controlled experiment)과 본질적으로 같다. 가설을 입증하기 위해 대조군(Controlled group)과 실험군(Experimental group)을 설정하고 결과를 검증하는 것은 과학적 방법론의 기본이다. A/B testing은 이 과학적 방법론을 인터넷 환경에 맞게 실행하는 것으로 볼 수 있다.
A/B testing은 웹/앱 기반 비즈니스라면 누구나 사용하고 있는 필수 도구다. 아마존, 구글, 넷플릭스 등 많은 기업들이 새로운 기능을 테스트하고 디자인을 최적화하기 위해 A/B testing을 활용하고 있다.
구글은 오래전부터 A/B testing을 적극적으로 활용해온 것으로 유명한데, 지금도 꾸준히 한 번에 50개 이상의 A/B test를 진행한다고 한다. 그러니 우리는 인터페이스가 약간 바뀌어도 알아채지 못하거나 신경 쓰지 않지만, 사실 A/B testing의 실험 대상이 되고 있을 수도 있다.
A/B testing이 중요한 이유는 가설을 직관이 아니라 데이터로 증명할 수 있기 때문이다. 사실 디자인에 대해서는 누구나 가설을 세울 수 있지만 증명하기는 어렵다. 만드는 사람 입장에서는 너무나 중요해보이지만 실제로는 아무런 행동을 이끌어내지 못한다거나, 전혀 예상치 못했는데 전환율이 크게 증가한다거나 하는 사례는 비일비재하다.
웹에서는 사용자들의 행동을 트래킹할 수 있기 때문에, 유저들이 실제로 어떻게 반응하는지 정량적으로 측정 가능하다. 실제 유저들의 심리와 행동을 파악하는 귀중한 자료가 되고, 이 피드백을 통해 서비스를 최적화해나갈 수 있다.
A/B testing으로 큰 효과를 낸 사례들을 몇 가지 보자. (Smashing Magazine을 참고했다.)
1. “I’m on twitter”보다 “You should follow Me on Twitter here”가 실제 팔로우 확률이 173% 높았다.
2. 회원가입 버튼 옆에 ‘It’s free!’를 넣으면 버튼을 누를 확률이 28% 증가한다.
3. 문장 스타일 정보 입력 폼을 사용하자 완료할 확률이 25-40%로 증가했다.
A/B testing은 만능이 아니다.
A/B testing은 아주 유용한 툴이지만, 모든 의사결정을 A/B testing으로 해결할 수는 없다. Diane Tang은 A/B testing course에서 이에 대해 “A/B testing은 산을 잘 올라가고 있는지는 말해주지만 어느 산에 올라가야 하는지는 말해주지 않는다.”라고 표현했다. 즉, A/B testing은 최적화 도구일 뿐 큰 그림을 보여주지는 못한다.
자..잠깐, 이 산 맞나?그래서 A/B testing은 완전히 새로운 기능을 추가하거나, 훨씬 높은 단계의 의사결정에 관해서는 효과적이지 않다. 예를 들어 ‘유료로 이용할 수 있는 프리미엄 기능’을 추가한다거나, ‘현제 시작 페이지에 어떤 문제가 있는가?’ 같은 질문에는 대답하기 어렵다. 따라서 A/B testing을 실행할 때는 아주 구체적이고 명확한 기능, 디자인을 대상으로 하는 것이 좋다.
A/B testing은 웹 로그 분석, 사용성 테스트, 유저 인터뷰 등 보완적인 방법들을 함께 사용해야 한다. A/B testing은 정답을 유추해내는 하나의 단서일 뿐 그 자체가 정답은 아니다.
A/B tesing을 할 때 알아야 할 실험 윤리
Udacity의 A/B testing course(링크)에서는 한 챕터를 'Policy and Ethics of in A/B testing'에 할애하고 있다. 미처 생각해보지 못했던 부분이었다. 비록 불특정 다수를 대상으로 하지만 A/B testing도 실험의 일종이기 때문에 실험 과정에서 참가자를 보호할 의무가 있다. 다음 4가지 질문을 기억하자.
첫 번째, 참가자에게 어떤 위험이 따르는가?
‘참가자가 일반적인 일상생활에서 겪는 위험’을 최소 위험이라고 한다. 이를 기준으로 더 큰 위험이 따르는 경우 반드시 참가자의 동의를 얻어야 한다.
두 번째, 참가자들이 어떤 개인 정보가 수집되는지 알고 있는가?
실험 과정에서 민감한 정보를 수집하는 경우도 있다. 민감한 정보란 일반적으로 건강, 의료 데이터나 금융 데이터 등이 해당된다. 이런 정보가 수집되는 경우에는 정보 수집, 처리 과정에 대해 알리고 참가자의 동의를 받아야 한다.
세 번째, 개인 정보가 식별 가능한가?
프라이버시에 관해서 데이터는 다음과 같이 나뉜다.
식별 가능 데이터 (Identified data) : 특정 개인임을 알아낼 수 있는 정보. 이름, 아이디, 주민등록번호, 운전면허 번호, 휴대폰 번호 등이 해당된다.
익명 데이터(Anonymous data) : 식별 가능 정보가 없는 데이터
익명화된 데이터(Anonymous data): 재식 별 위험이 없도록 수정된 데이터
가명화 데이터 (Psuedonymous data) : 무작위로 생성한 쿠키 등을 통해 동일 데이터를 파악할 수는 있지만 개인 식별은 불가능한 데이터
각 데이터의 종류에 따라 프라이버시 보호의 정도가 달라진다. 법적 조항은 각 나라마다 다르다고 한다. 우리나라의 개인정보보호 가이드라인은 개인정보보호 종합포털을 참고.
네 번째, 데이터가 어떤 과정을 거쳐서 처리되는가?
처리 과정에서 어떤 사람들이 접근 권한을 가지고 있으며, 원래 목적으로만 사용되도록 보호하는 조치는 어떤 것이 있는가? 위반 시 어떤 조치를 하는가? 이런 질문에 대해서 미리 답변할 수 있어야 한다.
A/B testing 프로세스
1. 기존에 존재하는 데이터를 모으고 들여다본다.
웹 로그 분석이나 사용자 인터뷰 등 이미 가지고 있는 데이터들에 대해 충분히 이해해야 한다. 곧 설명하겠지만, A/B testing을 하기 위해서는 실험에 필요한 지표, 신뢰 수준, 표본 숫자 등등 많은 것들을 결정해야 한다.
이를 결정할 인사이트를 얻기 위해서는 기존 데이터에서 문제점은 무엇이 있는지, 어떻게 개선할 수 있을지, 지표들의 흐름은 어떠한지, 지표가 변동하는 범위는 어느 정도인지 등을 사전에 파악해야 한다. 유난히 이탈률이 높은 페이지를 찾아보거나, 트래픽이 유난히 높을 때는 언제인지 등등을 눈여겨보자.
2. 목표(Goal)를 구체화한다.
먼저 A/B testing을 통해 궁극적으로 이루고자 하는 목표가 명확해야 한다. 어떤 비즈니스를 하느냐에 따라 목표는 다 다를 수 있다. 예를 들어 취업 포털 사이트라면 ‘더 많은 사람들의 취직을 돕는 것’이 목표일 수 있고 가격 비교 사이트라면 ‘소비자들이 가장 싼 가격에 좋은 물건을 사게 하는 것’이 목표가 될 수 있겠다.
어느 정도 레벨을 목표로 잡느냐에 따라서도 다르다. 높은 수준의 목표라면 ‘더 많은 사람들의 취직을 돕는 것’ ‘유저가 싼 물건을 짧은 시간에 찾을 수 있게 하는 것’ 등이 될 수도 있고, 좀 더 구체적으로는 ‘채용 기업 회원 숫자’나 ‘회원 만족도’를 목표로 할 수도 있다.
목표를 세울 때 중요한 점은 ‘우선순위’의 관점에서 생각해야 한다는 것이다. 당연히 회원 수가 늘면 좋고, 매출이 늘어도 좋고, 만족도가 늘어도 좋다. 하지만 의미 있는 서비스를 만들기 위해서는 그중에서 팀이 가장 중요하게 생각하는 것이 반드시 합의되어야 한다.
다른 말로 하면 이 목표를 위해서는 다른 목표를 희생할 수도 있다는 점을 모두가 동의해야 한다. A/B testing에 있어서 ‘명확한 목표’는 실험을 효과적, 효율적으로 진행하기 위한 기본이다.
3. 지표(Metric)를 선정한다.
목표를 정했다면 그에 맞는 지표(Metric)를 선정해야 한다. A/B testing에서 좋은 지표를 선정하는 것은 아주아주 중요하므로 지표를 선정할 때는 신중하자.
3.1. 목표에 맞는 지표
지표를 선정할 때는 주로 퍼널 분석(Funnel Analysis)을 하게 된다. 퍼널 분석이란 특정 목표를 이루기 위해 필요한 이벤트를 단계적으로 나누어 분석하는 것을 말한다. 다음 단계로 넘어갈수록 깔때기처럼 좁아지기 때문에 퍼널(Funnel, 깔때기) 분석이라고 한다. 이 방법은 전환율(Conversion rate)을 계산함으로써 유저 행동을 단계별로 분석할 수 있기 때문에 유용하다.
서비스에서 유저들이 통과하는 퍼널을 단계적으로 분류해보고 이 과정에서 A/B testing로 개선이 필요한 지표를 선택한다. 1단계에서 기존 데이터를 살펴보았다면, 특별히 유저들이 많이 이탈하는 단계를 먼저 선정할 수 있다.
아니면 미리 설정한 ‘목표’에 가장 큰 영향을 주는 단계의 전환을 지표로 삼는 것도 좋다. 버튼을 클릭하는 것이나 이메일을 열어보는 것 등 측정할 수 있는 거라면 뭐든 지표가 될 수 있다.
3.2. 지표의 종류
지표의 종류는 크게 네 가지 카테고리가 있다.
첫 번째는 ‘웹사이트에 들어온 전체 유저의 숫자’와 같은 합계 지표(Sum)이다.
두 번째는 평균(mean)이나 중앙값(median)이다. 예를 들어 구매까지 걸리는 평균 시간(mean), 첫 구매가 발생할 때까지 방문한 페이지의 중윗값(median) 등이 있다.
세 번째는 확률(probability)이다. 어떤 이벤트가 발생한 경우 1, 아닌 경우 0을 부여해서 전체 확률을 볼 수 있다. 확률 지표는 항상 0과 1 사이에 위치한다.
마지막으로는 비율(Ratio)이 있다. 한 지표를 다른 지표로 나눈다. “결제하기를 누른 횟수 중 구매 완료한 횟수 / 결제하기를 누른 횟수” 같은 식이다.
3.3. 민감도와 강건성
지표를 결정할 때는 민감도(Sensitivity)와 강건성(Robustness) 두 가지를 반드시 고려해야 한다. 우리가 원하는 변화가 발생했을 때 그 변화에 비례해서 움직이는 지표를 민감(Sensitive)하다고 한다. 반대로 목표와 상관없는 변화가 일어났을 때 지표가 움직이지 않으면 강건(Robust)하다고 한다.
예를 들어서 이 ‘시간당 회원가입을 클릭한 횟수’가 지표라고 해보자.
먼저 강건성 체크를 위해 아무것도 바꾸지 않은 상태에서 회원가입을 클릭하는 횟수가 어떻게 변동하는지 본다. 그런데 지표를 보니 아무런 변화를 주지 않았는데도 ‘회원 가입 클릭 횟수’가 큰 폭으로 오르락내리락했다. 실험과 관련된 변화가 없는데도 들쑥날쑥하면 실험 결과가 왜곡될 수 있기 때문에 좋은 지표라고 할 수 없다.
반대로 우리의 목표인 ‘활동 유저 수(Active user)’가 늘어도 ‘시간당 회원가입을 클릭한 횟수’는 별로 변화가 없을 수도 있다. 이 경우에는 충분한 민감하지 못한 지표이기 때문에 역시 적합하지 않다.
기존 데이터나 아니면 작은 실험을 통해서 지표가 이 두 가지 조건을 만족하는지 테스트해보자.
3.4 지표의 정의
한 가지 더 주의해야 할 점은 testing을 하기 전에 지표를 엄밀하게 정의해야 한다는 점이다. 단순히 ‘클릭한 확률(Click-through-rate)’이 지표라고 하더라도 impression을 기준으로 할지, 페이지뷰를 기준으로 할지에 따라 완전히 다르다. ‘클릭한 순간을 트래킹할지 클릭하고 다음 페이지로 이동했을 때 트래킹할지’ 같이 사소해 보이는 문제도 실제 웹상에서는 구현할 때는 완전히 다를 수 있다. 지표를 수식으로 나타내 보고 각 요소를 하나하나 따져보자. 테스팅을 구현하는 개발자와 원활한 소통을 위해서는 지표를 최대한 엄밀하게 정의하는 것이 좋다.
4. 가설을 수립한다.
목표와 지표가 있다면 이제 어떤 변화를 주어야 이 지표가 향상될 수 있을지, 그리고 왜 그럴지에 대해 가설을 세운다.
예시) “결제 페이지를 세 단계에서 두 단계로 바꾸면 결제하기를 클릭한 사람 중 완료한 사람의 비율이 높아질 것이다. 결제 단계가 간단하면 중간에 포기하고 나가는 고객이 줄어들 것이기 때문이다.”
유저 행동에 영향을 미치는 요소라면 무엇이든지 A/B testing 대상이 될 수 있다. 헤드라인, 텍스트, 사용후기, CTA(Call to Action) 버튼, 링크, 이미지, 접기 버튼, 기사 스크랩, 페이지 레이아웃 등등.
여러 가지 가설이 리스트에 있다면 예상되는 효과의 크기와 실행 난이도에 따라서 우선순위를 매기면 된다. 효과가 크고, 실행하기 쉬운 가설부터 실험한다.
5. 실험을 설계한다.
5.1. 분기 단위(Unit of diversion)
먼저 분기 단위(Unit of diversion)를 정해야 한다. 분기 단위(Unit of diversion)는 A그룹(대조군)과 B그룹(실험군)을 나누는 기준을 말한다. 주로 사용되는 3가지는 ID, cookie, event다.
ID의 경우, 로그인이 된 회원의 ID를 기준으로 대조군, 실험군을 나눈다. ID를 사용하면 동일 유저가 시간차를 두고 나중에 다시 접속하거나, 디바이스를 웹에서 모바일로 바꾸더라도 환경이 바뀌지 않아 일관적이다. 하지만 로그인을 하기 전에는 분기를 할 수 없고, 개인 식별이 가능하기 때문에 데이터 수집 시 주의해야 한다.
Cookie란 사용자가 사이트를 방문할 때 생성되는 기록 파일이다. 로그인을 하지 않아도 사용자의 행동을 트래킹 할 수 있다는 장점이 있다. 그래서 웹사이트에 들어가면 “쿠키 정보를 수집합니다”라고 알림이 뜨는 이유다. 다만 브라우저나 디바이스가 바뀌거나 쿠키가 삭제되면 트래킹이 불가능하다는 단점이 있다.
Event을 사용하면 유저가 어떤 행동(event)을 했을 때 무작위로 A 혹은 B의 결과가 나타나게 된다. 즉 ‘회원가입 클릭’이라는 이벤트를 기준으로 한다면, 매번 회원가입을 클릭할 때마다 A 화면이 뜰 수도 있고 B 화면이 뜰 수도 있다. 이 경우 동시에 서비스의 일관성을 많이 해칠 수 있다. 대신 가장 임의화된 (Randomized) 샘플을 뽑을 수 있어서 통계적으로 효과적이라는 장점이 있다.
따라서 Event 분기는 유저가 눈치채기 어려운 A/B testing일 때만 쓰인다. 예를 들어 ‘동영상 로딩 속도’를 높였을 때 ‘동영상을 끝까지 보는 사람의 비율이 늘어나는지 확인’하고 싶다고 하자. 동영상을 클릭했을 때 랜덤으로 ‘로딩 시간 0.5초’ 혹은 ‘로딩 시간 2초’가 나타나는 것이다. 이런 변화의 경우 유저가 알아채기 거의 힘들다. 즉, 유저가 “아니 어떨 때는 0.5초가 걸리고 어떨 때는 2초가 걸리는 거야?”라고 불만을 가지지 않는다는 말이다. 그래서 이럴 때는 Event 분기를 사용해서 A/B testing을 할 수 있다.
한 가지 더 고려해야 할 점은 분석 단위(Unit of analysis)이다. 분석 단위란 간단히 말해 지표의 분모다. 지표가 ‘회원당 구매액’이라고 해보자. 수식은 다음과 같을 것이다.
총 구매액 합계 / 회원 수
이 지표에서 분석 단위는 분모인 ‘회원’이 된다. 즉, A/B testing으로 영향을 주려고 하는 최소 단위다.
분기 단위를 정할 때는 분석 단위와 일치시키는 것이 바람직하다. ‘회원당 구매액’의 경우 분석 단위가 ‘회원 한 명’이므로 ID를 기준으로 분기한다. 분기 단위와 분석 단위를 일치시키는 이유는 실험 데이터를 ’독립 사건’으로 만들기 위해서다. 예를 들어 우리가 분석하고 싶은 단위는 ‘회원’인데 실험 데이터에서는 ‘페이지뷰’로 분기되어있다면, 한 명은 회원이 여러 개의 페이지뷰를 만들어낼 수 있다. 그러나 각 페이지뷰는 한 명의 회원이 만들어낸 것이므로 서로 확률이 연관되어있고, 사건 간의 독립성이 없다. 따라서 어떤 회원은 페이지뷰를 100번 했고, 어떤 회원은 페이지뷰를 1번 했을 때 실험 데이터가 왜곡될 가능성이 커진다. ‘통계적으로 유의미’ 한 결과가 나오기 힘들어진다. ‘통계적 유의성’에 관해서는 5단계에서 알아보겠다.
5.2. 목표 집단 (Target Population)
일반적으로 실험을 할 때는 샘플 숫자가 많을수록 좋다. 결과의 신뢰도가 올라가기 때문이다.
그럼에도 불구하고 무작정 모든 유저를 모집단(Population)으로 잡고 샘플링하면 오히려 신뢰도를 떨어뜨릴 수 있다. 어떤 상황에서는 측정하려고 하는 변화가 특정 집단에게만 의미 있는 것일 수 있기 때문이다.
예를 들어 홈페이지에 한국어 폰트를 변경하는 테스트를 했을 경우, 이 변화의 영향을 받는 유저는 한국 유저다. 그런데 이를 고려하지 않고 외국 유저까지 포함된 전체 유저를 대상으로 샘플링을 할 경우, 한국어 폰트 변경이 효과가 있었음에도 불구하고 영향을 받지 않는 그룹(외국 유저) 때문에 데이터를 분석했을 때 ‘효과 없음’으로 결론날 수가 있다. 한국 유저들의 행동 변화를 외국 유저들이 상쇄시키기 때문이다. 따라서 실험의 대상이 되는 모집단을 정확히 정의하자.
코호트(Cohort)를 기준으로 A/B testing을 할 수도 있다. 코호트란 ‘특정 기간 특정 경험을 공유한 사람들의 집합’을 말한다. 예를 들면 ‘앱 설치’가 기준이라면 4월에 앱을 설치한 그룹, 5월에 앱을 설치한 그룹 이런 식으로 나누는 방법이다. 코호트 분석은 유저 행동을 분석할 때 널리 쓰이는 방법이다. 웹/앱 서비스를 사용한 시간에 따라서 사용자의 패턴이 달라지기 때문이다. 서비스를 사용한 지 1개월 된 유저와 3년 된 유저는 특성이 매우 다를 수밖에 없다.
A/B testing에 코호트를 적용하는 이유는 여러 가지가 있다. 그중 하나는 ‘학습 효과’를 없애기 위해서다. 서비스에 변화가 생기면 유저들이 처음에는 익숙하지 않다가 차차 변화에 적응하는 것을 학습 효과라고 부르는데, 학습 효과가 진행되는 기간에는 데이터가 튀거나 왜곡될 수 있다. 실제로는 긍정적인 변화라도 기존 방식에 익숙해져 있던 유저들에게는 단기적으로 안 좋은 지표 변화가 나타날 수 있기 때문이다. 코호트를 사용해 새로 서비스를 사용하기 시작한 유저들을 대상으로만 A/B testing을 사용하는 식으로 ‘학습 효과’를 데이터에서 배제할 수 있다.
이 외에도 유저 리텐션(Retention) 향상이 목표이거나, 가입 시점에 따라서 실험 결과가 영향을 받을 수 있는 A/B testing의 경우는 목표 집단을 특정 코호트로 제한하는 방법이 효과적이다.
5.3. 표본 크기(Sample Size)
의미 있는 결과를 내기 위해 필요한 표본 숫자(n)가 얼마인지 알아야 한다. 필요한 표본 숫자는 신뢰도 수준을 더 보수적으로 잡거나, 오차 범위 구간을 작게 잡거나, 현실적으로 유의미한 변화(6.3.에서 설명)를 낮게 설정할수록 늘어난다.
각 수치들은 트레이드오프 관계이기 때문에 우선순위를 정하기 나름이다. 신뢰도가 높은 결과를 얻고 싶다면 표본 숫자를 늘려야 하고, 표본 숫자를 많이 구하기가 힘들다면 그만큼 신뢰 수준이 낮거나 오차 범위가 커진다.
우선순위를 고려해서 수치를 결정했다면 표본 숫자 계산은 어렵지는 않다. A/B testing 프레임워크를 쓴다면 대부분 자동으로 탑재되어있으며, 아니면 구글에서 ‘A/B testing sample size calculator’라고만 검색해도 쉽게 찾을 수 있다.
5.4. 실험 기간(Duration)
실험 기간도 결정해야 한다. 시간은 금이기 때문에 일단 기간은 최대한 짧은 게 좋겠지만, 기간이 짧은 경우 정확성을 놓칠 수가 있다. 전문가들은 A/B testing기간은 최소 수 일 이상은 되어야 한다고 조언한다. 결과에 영향을 미칠 수 있는 외부 변수들이 많이 있기 때문이다. 트래픽은 특정한 날짜나 요일에 따라서 영향을 받는다. 특히 E-commerce 사이트의 경우 명절, 연휴 기간에는 평소와 전혀 다른 패턴이 나타날 수 있다. 이런 경우가 실험에 영향을 주지 않도록 고려해서 기간을 정해야 한다. 또는 구매 주기가 긴 상품(가구, 자동차 등)의 경우에는 효과가 나타날 때까지 시간이 걸린다. 현실적으로 가능한 선에서 충분한 기간을 갖고 실험하자.
6. 결과를 분석한다.
이제 실험에서 도출된 데이터를 보고 결론을 도출해야 한다. 지표가 긍정적으로 변했다고 해서 흥분하지 말자. A/B testing을 할 때 가장 흔하게 나타나는 실수다. 실험 과정에서 무언가 잘못되었을 수도 있고, 우연의 일치가 일어났을 수도 있다. 그러므로 실제로 이 결과가 정말로 의미 있는지 알려면 3단계 확인을 해야 한다.
6.1. 불변 지표(Invariant Metric)
먼저 실험 과정에서 문제점이 없었는지 재점검을 해보기 위해서 불변 지표(Invariant metric)가 변하지 않았는지 체크한다. 불변 지표란 실험 과정에서 변하면 안 되는 변수다.
예를 들어 표본 숫자는 실험군과 대조군 사이에 큰 차이가 나서는 안된다. 기본적으로 A/B testing에서는 50대 50 확률로 실험/대조군을 분류하게 된다. 전체 트래픽을 2분의 1로 딱 나누는 것이 아니기 때문에 실험/대조군의 표본 숫자에 차이가 나는 것이 정상이다. 하지만 오차 범위를 계산해봤을 때 그 이상으로 차이가 난다면 실험 과정에서 뭔가 잘못되었을 가능성이 있다.
그 외에도 가설과 관련 없는 지표가 변화(회원가입 버튼을 바꾸었는데 결제 페이지 지표가 크게 바뀌었다던지) 하지 않았는지 확인하자. 시스템 상에서 오류가 일어나는 경우는 흔하고, 아니면 다른 외부 변수가 작용했을 수 있다.
A/A testing은 실험이 제대로 진행되었는지 확인할 때 유용하다. A/A 테스트란 아무런 변화도 주지 않고, 두 집단의 차이를 측정하는 실험이다. 즉, A/A 테스트를 했을 때는 양쪽 집단에서 결과가 똑같이 나와야 정상이다. 그렇지 않다면 뭔가 문제가 있는 것이다. 체중계로 치면 영점 조정이라고 할 수 있겠다. 올라가기 전에 정확하게 0에 맞춰져 있어야 측정 결과를 신뢰할 수 있는 것과 같은 원리다. Diane에 따르면 구글에서는 A/B 테스팅 전후에 A/A 테스트를 반드시 하도록 내부적으로 정해져 있다고 한다.
6.2. 통계적 유의성 (Statistical significance)
어떤 실험 결과를 두고 ‘통계적으로 유의미하다’고 하는 것은 단순히 우연이라고 보기 어렵다는 뜻이다. 실험에서는 언제나 우연의 가능성이 있기 때문에, 통계적으로 유의미한 결과인지 확인하는 것은 아주아주 중요하다.
통계적으로 유의미하다는 말은 동시에 이 실험을 다시 한번 해도 똑같은 결과가 나온다는 말이기도 하다. 우리는 A/B testing을 통해서 가설을 입증하고 이를 서비스 전체에 적용하고 싶은 것이기 때문에, 이 결과를 반복해서 나타날 수 있는지 여부를 반드시 점검해야 한다.
이 과정을 통계학에서는 가설 검정(hypothesis test)이라고 한다. 가설 검정을 모두 설명하게 되면 관련된 통계학 이론에 대해서 설명해야 하기 때문에 나중에 이 부분에 관해서 따로 정리해보겠다.
결론만 말하자면, Hypothesis testing을 통해서 변화가 ‘우연히 일어났을 확률’을 구할 수 있는데, 일반적으로 이 확률이 5% 이하이면 통계적으로 유의미한 것으로 본다.
6.3. 현실적 유의성 (Practical significance)
통계적으로 유의미한 결과가 나왔다고 하더라도 바로 그 가설을 적용해서는 안된다. 이 실험 결과를 전체적으로 적용하기 위해서는 시간과 돈이 들기 때문이다. 따라서 현실적으로 유의미하다는 말은 비용과 시간을 고려했을 때도 충분히 실행할 가치가 있는 가설이라는 뜻이다. 따라서 이는 상황을 고려해서 직접 결정해야 한다. 어떤 비즈니스냐에 따라 범위가 다를 수 있다.
극단적인 예로 신약 개발의 경우, 신약의 성능이 15% 이상은 되어야 현실적으로 유의미한 숫자라고 한다. 제품화에 그만큼 많은 시간과 비용이 들기 때문이다. 하지만 웹/앱 서비스 경우에는 그렇지 않기 때문에 1-2% 정도만 되어도 굉장히 의미 있는 차이로 본다.
‘왜’를 놓치지 말자
실험 결과가 이 3가지 점검을 모두 통과했다면 가설을 전체 서비스에 적용할 수 있다. 하지만 한 가지 더 마지막으로 유의해야 할 점이 있다. 단순히 가설을 입증했다고 해서 끝은 아니다.
왜 그런 결과가 나왔는지에 대한 이유를 더 파고 들어가야 한다. A/B testing은 유저 행동이 변화한 이유까지는 알려주지 않기 때문이다. 입증된 가설을 가지고 유저 인터뷰 등 정성적인 분석 방법을 통해서 유저에 대해 깊게 이해해나가야 지속적으로 사랑받는 서비스를 만들어갈 수 있다.
이 글은 Udacity의 A/B testing 강의 내용을 재구성했습니다.
