온전한 A/B 테스트
A/B 테스트할 때 주의할 점 5가지
A/B 테스트의 개념과 테스트 시 주의할 점을 살펴보겠습니다.
나는 과연 온전한 A/B 테스트를 하고 있는가?
A/B 테스트란?
신규 서비스의 유효성을 테스트하기 위한 실험이다. A/B 테스트를 통해 제품의 두 변수가 관심을 두고 있는 지표에 어떤 성과로 나타나는지 비교해볼 수 있다. 저비용으로 잠재적 기능 및 제품 출시가 목표를 달성하는 데 도움을 줄 것인지 확인하고, 형편없는 잠재적 아이디어를 세상에 내놓기 전에 걸러내고, 시제품에 대한 아이디어가 시도해볼 가치가 있는지 테스트할 수 있는 방법이다. 무작위로 하나의 사용자 그룹은 A로, 다른 그룹은 B로 설정하고 지표가 어떻게 나타나는지 테스트 하는 것이다.
A/B 테스트 사례
A/B 테스트의 대표적인 사례로 ‘버튼의 폰트, 색상, 크기, 그 외 기타 기능을 바꾸는 것이 버튼 클릭 횟수를 증가시킬까?’ 같은 질문을 해결하기 위해 웹사이트의 버튼을 조금씩 수정하는 것을 들 수 있다.
스포티파이 - 신규고객 인터페이스 기능을 실험
에어비앤비 - 숙소 예약 과정에 적용한 변경사항 실험
우버 - 새로 디자인한 버전의 앱을 실험
구글 - 다른 형식의 광고 링크를 실험
새로운 서비스를 만드는 PM으로서 A/B 테스트는 무기고에 들어 있는 무기 중에서 가장 중요한 무기인 이유다.
A/B 테스트의 효과
구글은 실험을 통해 서로 다른 40가지의 파란색 음영 중 가장 효과적이었던 색상이 광고 매출을 2억 달러나 증가시켰다는 사실을 발견했다. 2009년 구글에서 진행한 1만 2,000번의 A/B 테스트 중 10% 만이 뚜렷한 개선점으로 이어졌지만, 그러한 작은 승리들은 누적된다.
하루에도 수십번씩 앱을 보는 우리는 인기 앱을 켤 때마다 테스트에 참여하고 있다는 사실을 인지하지 못한 채 하나 또는 그 이상의 A/B 테스트에 참여하게 될 가능성은 매우 크다.
A/B 테스트는 어떻게 하는가
테스트 대상이 되는 표본을 둘로 나눈다. A는 기능이 포함되지 않은 통제 버전, B는 기능이 포함된 실험 버전이다. 실험대상이 너무 많지는 않아야 하므로 통제 버전은 150명에게, 실험 버전은 50명에게만 제공한다. 이제 계산해보자. 앱의 ToS (머무른 시간, Time on Site) 의 평균값이 통제 그룹은 10분이고 실험 그룹은 10.5분이다. 효과가 있었다.
그런데 아직 확신하기에는 이르다. 전체 사용자 기반의 작은 표본만을 테스트 대상으로 삼아 실험을 진행했으므로 여러분이 발견한 차이가 진짜인지 확신할 수 없지 않은가. 어쩌면 기능은 아무런 영향을 주지 않았고, 그저 우연히 그 사이트에 더 오래 머문 사용자를 표본으로 선택한 것인지도 모를 일이다.
신뢰구간 또는 p값을 확인해야 한다.
A/B 테스트 결과가 믿을 만한 것인지 확실하게 하기 위해서는 통계적 유의성 검정을 해야 한다. 통계적 유의성 검정의 기본은 기각하려는 귀무가설을 세우는 것이다. 귀무가설은 가장 비관적인 관점이다. 위 경우 귀무가설은 새로운 기능이 아무것도 변화시키지 않았고 나온 결과는 그저 무의미한 정보였다고 할 수 있다.
귀무가설을 기각할 수 있을지 알아내기 위해서는, 테스트 표본에 나타난 패턴이 전체 사용자에 적용되는지 확인해봐야 한다. 200명을 대상으로 테스트 했을때 ToS가 0.5분 증가했다. 그렇다면 전체 사용자 기반에 이 기능을 공개하면 어떤 일이 벌어질까?
전체 인구에 미칠 영향을 추산하기 위해서 CI(신뢰구간, confidence interval)를 구할 수 있다. 실질적으로 가장 자주 사용되는 신뢰수준은 95%이다. 신뢰구간을 구하기 위해서는 t-test(스튜던트의 두 꼬리 T-검정)이라는 도구를 사용한다. 이것이 평균차에 대한 신뢰구간을 제시해준다.
위 사례에 대한 A/B 테스트의 결과로 평균차에 대한 95% 신뢰구간은 (-0.080, 1.065)이다. 이는 이 기능을 전 세계에 출시하면 95%의 확률로 ToS가 -0.080에서 1.065분 사이 구간으로 바뀔 것이라는 뜻이다. 신뢰구간에 양수와 음수가 모두 포함된다는 것은 모든 사용자에게 기능을 공개하게 되면 ToS에 사실상 불리하게 작용할 가능성이 상당히 크다는 뜻이다. 실제 평균차가 0이하일 정확한 확률은 p값이라고도 부른다. 앞서 예시에서 p값은 0.092, 즉 9.2%였다. 따라서 우리가 고안한 기능은 9.2%의 확률로 사이트에 머문 시간에 불리하게 작용할 수 있다.
신뢰구간이 0을 포함할 때 우리는 귀무가설을 기각하는 데 실패한다. 우리는 출시하는 모든 것이 95% 확률로 지표를 개선하길 바라는데, 이를 가능하게 해줄 유일한 방법은 전체 95% 신뢰구간이 0을 초과하는 것이다. 따라서 우리가 진행한 A/B 테스트는 페이스북 전체에 이 기능을 출시하겠다는 주장을 정당화하기에 충분하지 못하게 된다.
가령 신뢰구간이 (0.1, 0.9)였다면 이 기능이 95% 확률로 모든 사용자의 ToS를 증가시킬 것이라고 말할 수 있다. 간단히 말하면, 전체 구간이 0을 초과했을 경우 결과만 통계적으로 유의미하고 출시가 가능 할 것이다. 이 경우에 p값은 0.05 미만이다. 이는 통계적 유의성을 나타내는 또 하나의 방법으로, 해당 기능의 출시를 정당화 할 수 있다.
반대로 신뢰구간이 (-0.6,-0.2)처럼 모두 0 미만이었다면 기능이 모든 사용자의 ToS 감소로 이어지는 게 확실하므로 아마도 그 기능의 출시를 취소했을 것이다.
유효한 신뢰구간 또는 p값을 갖기 위해서는?
신뢰구간을 축소하는 가장 좋은 방법은 더 큰 표본을 가진 실험을 해보는 것이다.실제로 위와 같은 결과를 얻었다면 그 다음으로 200명이 아니라 1000명의 사용자에게 테스트 해볼 수 있다.
어떤, 얼마만큼의 사용자를 표본으로 추출해 테스트해야 할까?
어떤 사람들을 A와 B그룹에 넣을지 결정하는 방법을 알아보자. 좋은 결과를 얻기 위해서는 실험 그룹 대상자가 충분한 게 좋다. 우리가 앞서 언급했듯이 표본 그룹이 커질수록 신뢰구간이 좁아져 통계적으로 유의미한 결과치를 얻기 쉽다. 일반적으로 표본의 크기를 4배 늘리면 신뢰구간의 너비가 반으로 줄어든다.
그렇지만, 지표에 미치는 효과가 확인되지 않은 기능을 넓은 범위의 사용자를 대상으로 실험하는 것은 위험하다. 일부 사용자가 자신이 사용할 수 없는 다른 기능을 다른 친구들이 사용하고 있는 상황을 보면서 혼란스러워하거나 화를 낼 수도 있다. 일반 사용자는 A/B 테스트가 무엇인지 전혀 알지 못하고 모든 사람이 똑같은 제품을 사용하고 잇을 거라고 생각한다는 사실을 기억하자.
구글이 고안해낸 경험법칙인 1% 실험에 따르면 사용자 기반의 1%에 실험적 기능을 적용하고 나머지 99%는 통제 그룹에 들어간다. 사용자 기반이 충분할 경우, 사용자 1%만으로도 확실한 결과를 얻어낼 수 있을 것이다. 이를테면 수백 명이 사용하는 스타트업 제품 등 훨씬 작은 제품을 담당하고 있다면 통계적으로 유의미한 결과를 얻기 위해 더 큰 비율의 사용자에게 변경 사항을 적용해야 할 것이다.
단계별로 A/B 테스트 표본을 늘린다.
구글, 메타같은 기업이 개발한 기능 대부분은 개발이 완료된 뒤 1%의 사용자 기반에 자동으로 배치된다. PM은 며칠간 데이터를 수집한 다음, 지표에 일어난 변화가 괜찮은지 확실하게 하기 위해 A/B 테스트 결과를 검토한다. 그러고 나서 해당 기능은 더 넓은 범위의 사용자에게 공개된다. 매 단계는 실험 그룹이 계속해서 점점 더 커지는 A/B 테스트라고 볼 수 있다.
1% 실험이 끝난 직후 해당 기능을 회사 외부에 있는 베타 테스터(제품을 판매하기에 앞서 제품의 결함 여부를 검사하는 사람)에게 보내는 경우도 있다. 예를 들어 윈도우의 새로운 기능은 일반 윈도우 사용자에게 적용되기 전에 윈도우 인사이더 프리뷰 고객에게 먼저 제공된다.
그런 다음 해당 기능은 일반 대중에게 서서히 확산된다. 처음에는 5%, 10%, 20%로 점점 더 늘어난다. 마침내 출시 준비가 완료된 단계까지 도달하겠지만, 이 단계에서조차 100%의 고객에게 적용되지는 않는다. 빅테크 기업에서 제품의 기능은 일반적으로 사용자의 95%, 99%에게만 공개되고, 나머지는 기능을 제공하지 않는 홀드백 그룹으로 남겨둔다.
홀드백 그룹을 남겨놓자.
홀드백 그룹은 제품 기능 출시가 지표에 제대로 영향을 미치는지 확인할 마지막 기회다. 일단 100%에 도달하면 통제 그룹은 더 이상 존재하지 않고, 이에 따라 A/B 테스트를 할 능력도 상실하기 때문이다. 해당 기능에 대한 확신이 있을 때에만 사용자 100%에게 기능을 제공해야 한다.
⚠️ A/B 테스트 주의점
절대 A/B 테스트를 맹목적으로 진행하고 테스트에서 나타난 결과를 그대로 실천에 옮기면 안된다. 지표가 곧 법은 아니다. 지표가 언제나 완성된 이야기를 들려주지 않기 때문이다. 구글 디자이너들은 이 실험이 구글에서 A/B 테스트를 무턱대고 따르며 일관된 디자인 언어가 없는 괴물 같은 제품을 만드는 사례라고 생각했다. 다시 말해 좋은 디자인 제품은 일관된 사용자 인터페이스, 색채 조합, 작동 방식을 가지고 있어야 한다. 그런데 사용자 인터페이스의 모든 부분을 극소 단위로 최적화하기 위해 A/B 테스트를 무더기로 진행하면 일관되지 못한 디자인을 가진 제품이 탄생한다. 이렇듯 A/B 테스트는 객관적이라는 장점이 있지만 디자인처럼 주관적인 요소를 설명하지 못한다.
⚠️ PM은 최적화할 더 나은 지표, 예를 들면 사용자가 서비스를 재방문한 횟수 등 잠재적인 불만 요소를 잡아냈을 데이터를 선택해야 했고, 애초에 너무 과도하게 의지하지 말아야 한다.
테스트를 하기 전 사용자에게 동의를 받는 경우가 있다. 물론 동의가 필요할 때가 분명히 있다. 그러나 모험적인 기능을 시도하는 것이 불편하지 않은 사용자들이 제품의 베타 버전 사용에 참여한다는 의사를 표현했으므로, 모험적인 기능을 사용하겠다고 동의한 것과 마찬가지가 될 수 있다. 베타 테스터는 일반 사람들과 꽤 다르다. 모험적인 기능을 A/B 테스트하는 가장 좋은 방법은, 베타테스터 중에서 임의로 선택된 부분집합에 기능을 제공하는 것이다. 이 전략은 위험을 최소화하면서 효과적인 A/B 테스트를 가능하게 해준다.
⚠️ 자주 볼 수 있는 실수는 테스트를 동의한 사용자를 상대로 아무 우려 없이 A/B 테스트를 실행하는 PM들이다.
A/B 테스트로 새로운 기능을 슬그머니 출시하는 방법을 선택하고 싶지 않은 경우도 있을 수 있다. 가끔은 큰 주목을 받는 편이 더 효과적이다. 큰 기능 컨퍼런스에서 새로운 기능을 먼저 발표하고 A/B 테스트를 하면서 천천히 제품을 출시할 수 있다. 하지만 이미 기능을 출시하겠다고 선언했기 때문에 지표가 안 좋게 나온다고 해서 출시를 취소할 수는 없다. 그래도 A/B 테스트는 제품을 모두에게 제공하기 전에 제품의 특정 파라미터를 수정할 수 있게 해준다.
체리피킹이란 어떤 관점을 뒷받침하지 않는 수없이 많은 데이터를 훑어보다가 우연히 주장을 뒷받침해주는 조각 몇 개를 골라내서 전체 데이터가 유리하게 적용되는 것처럼 보이게 하는 전술이다. 여러분이 테스트를 충분히 많이 하면 그중 최소한 하나에서는 통계적으로 유의미한 결과가 실수로 나타날 확률이 높아진다.
A/B 테스트가 통계적으로 유의미한 어떤 허상의 지표 변화로 이어지는 경우가 있을 수 있기 때문에 실험을 끝낸 뒤에는 모든 지표를 살펴보고 우연히 좋아보이는 혹은 나빠보이는 것들을 체리피킹 하지 말아야 한다. 하킹이라고 알려진 이 전술은 과학적인 부정행위로 분류한다.
⚠️ PM들은 실험을 진행하기 전에 어떤 지표를 고려할 것인지를 결정해야 한다. 그리고 실험이 끝났을 때 비로소 그 지표들을 관찰해야 한다.
실험이 성공적이었을 경우, 증가하리라 기대하는 지표, 즉 성공 지표를 확인하는 것만으로는 부족하다. 성공 지표에 도움이 되었을 때 손해를 볼 수 있는 지표인, 이른바 반대지표도 살펴봐야 한다. 반대지표는 자기 잠식과도 밀접하다. 자기잠식은 제품 하나가 다른 제품의 시장점유율을 먹어치울 때 일어난다. 두 제품이 모두 자사 제품인 경우 회사 전체에는 더 나아진 것이 없을 것이다.
⚠️ PM은 성공지표와 반대지표 모두 살펴봐야 한다.
또한, A/B 테스트에서 처음 확인한 효과가 지속되지 않을 수도 있다. 신규효과와 학습효과가 있기 때문에 초기 지표는 장기수치보다 각각 높거나 낮을 수 잇다. 신규효과는 기능에 변화를 주었을 때 사용자들의 관심을 끌어서 일시적으로 클릭 수나 사용량을 증가시킬 가능성이 생기는 현상을 설명한다. 이 변화는 시간이 지나면서 사라진다. 한편 학습효과로 인해 초기 지표가 장기 수치보다 낮을 수도 있다. 사용자들은 A/B 테스트 초반에 실험 버전을 어떻게 사용해야 할지 모를 수 있다. 다시 말해 어떤 지표는 시작할 당시에는 좋지 않더라도 실험이 진행될 수록 개선되기도 한다. 이런 현상은 사용자 인터페이스를 새로 디자인 했을 때 자주 일어난다.
두 효과 모두 실험을 하고 며칠 만에 바로 승리(또는 패배)를 선언하지 말라는 교훈을 준다. 신규효과 또는 학습효과가 적용될 가능성을 생각하면 인내심을 갖고 지표의 장기적인 값을 확인하도록 하자. 1주보다 3~4주 정도는 진행하는 것이 좋다.
⚠️ PM들은 사용자 인터페이스의 작은 변화로 인해 지표가 크게 뛰어오르는 A/B 테스트를 살펴볼 때 비판적인 시선을 가져야 한다.
프로덕트 매니지먼트 세계에서는 보통 실시간으로 운영되는 제품을 다루기 때문에 A/B 테스트가 시작됐을 때부터 실시간 데이터를 조회할 수 있다. 하지만 이런 식으로 엿보기를 하면 잘못된 판단을 할 수 있다. 실시간으로 테스트 하기 때문에 신뢰구간과 p값은 계속 왔다 갔다 할 것이고, 신뢰구간의 하단이 0에 근접하자마자 실험을 중단하고 싶은 유혹이 강하게 들 것이다. 통계적으로 유의미한 범위로 판단하는 시점이 p값이 0.05 아래로 내려갈 때도 마찬가지다.
⚠️ 지표는 최종 값에 정착하기 전까지 우연히 일시적으로 유의미한 영역을 드나들 수 있다. 엿보기를 하지 말라.
A/B 테스트와 주의점을 모두 살펴보았습니다. 나는 과연 온전한 A/B 테스트를 하고 있는가?
*본 컨텐츠는 책 <7가지 코드>를 기반으로 제작하였습니다.
"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."
