brunch

You can make anything
by writing

C.S.Lewis

by Jyoung Jan 02. 2023

A/B 테스트의 기술

돌다리도 두들겨 보고 건너는 A/B 테스트의 기술에 대해 소개합니다.

구글, 넷플릭스 같은 해외 IT 공룡 기업들부터, 쿠팡, 토스, 당근마켓 등 국내 기업에 이르기까지 활발히 활용한다는 A/B 테스트.

A/B 테스트는 어떤 것이고, 어떻게 해볼 수 있는지. 주의할 점은 어떤 것들이 있는지 등을 알아보자.


A/B 테스트?

개념 자체는 매우 간단하다.

검증하고자 하는 부분만 변수로 남겨두고 나머지 모든 변수를 통제,

실험 후 각 그룹별 데이터를 확인하여 Winner 그룹을 선정하는 실험 방법이다.

이미지 출처: https://knowledgemarble.tistory.com/84


개인적으로 A/B 테스트의 핵심은 아래 부분이라고 생각한다.


검증하고자 하는 부분만 변수로 남겨두고
나머지 모든 변수를 통제



예를 들어, 결제 전환율을 높이기 위해 '결제하기' 버튼의 CTA 텍스트를 '구매하기'로 변경하는 상황을 가정해 보자.

대화를 다소 극적으로 재구성한 부분이 있지만, 현업에서는 실제로 종종 위와 같은 상황에 놓인다.

배포일 전후 비교만으로는 실제로 이번 배포가 프로덕트에 어떤 영향을 미쳤는지 알아내기 어려운데,

일단 시간이라는 큰 변수와, 그에 따른 여러 가지 외적 요인들이 (위 예시에서는 프로모션, 상품 배치 등) 변수로 작용할 수 있기 때문이다.

A/B 테스트를 진행하는 것은 이러한 외부 요인들을 최대한 통일하고, 정말 검증하고 싶은 부분만 변수로 둔 채 결과를 확인할 수 있다는 것에 가장 큰 의의가 있다고 생각한다.


만약 위 상황에 A/B 테스트를 대입한다면, 아래와 같이 깔끔하게 회고가 마무리되었을 것이다.

(물론 분산 방식에 따른 차이나 통계적 유의성 등 더 고려할 여지가 있지만 생략한다)


A/B 테스트 해보기 (with. 헬로우봇)

그렇다면 A/B 테스트를 어떻게 실무에 적용해볼 수 있을까?


헬로우봇에서 진행한 한 실험을 예로 들어, 직접 이 실험의 설계를 다시 한다고 가정하고 과정을 톺아보자.

좌측부터 순서대로 A, B, C 시안

헬로우봇 스킬스토어에서는 결과이미지 공유 보상과 관련된 A/B 테스트를 진행한 적이 있다.


실험 그룹은 아래와 같다.

A: 기존안 + 공유 보상 없음

B: 하단 토스트로 보상 안내 + 하트 4개

C: 상단 영역에 보상 안내 + 하트 4개


1. 문제 정의 & 가설 설정

일단 모든 기획의 기본이 되는, 문제 정의와 가설 설정부터 해야 한다.


당시에 당면했던 문제를 이해하기 위해서는 우선 결과이미지라는 기능이 왜 개발되었는지를 알 필요가 있다.

가장 주요한 이유는 결과를 요약하여 공유할 수 있는 기능을 추가함으로써 오가닉 파이프라인을 구축하기 위함이었는데, 결과적으로는 이후 시로의 부캐테스트 콘텐츠가 대박을 터트리면서 결과이미지의 효과를 톡톡히 보기도 했다.

하지만 대부분이 매출까지 이어지지 못하고 유입에 그치는 상황이었으며, 여기서 발생한 당시의 니즈는 "결과이미지가 오가닉 매출 채널로도 동작하게 하고 싶다!"는 것이었다.


주어진 상황에서 진짜 문제를 찾아내는 데에도 여러 가지 방법이 있지만, 다음에 기회가 되면 소개하도록 하고.

당시 상황과 니즈를 분석해서 프로덕트 차원에서 해결하고자 했던 문제와 가설은 아래와 같았다.

문제: 결과이미지를 공유할 동인이 부족하다
가설: 결과이미지 공유 시 적절한 보상을 제공하면 결과이미지를 통한 결제 매출이 N% 상승할 것이다.


2. A/B 테스트 지표 설정

A/B 테스트에서 보는 지표는 여러 가지가 있지만, 두 가지만 알아도 실험이 가능하다.


성공 지표 (success metric)

실험의 성공 여부를 확인하는 지표로서, 가설을 검증할 수 있는 지표로 설정한다.

핵심 지표 (primary metric) 라고도 한다.


가드레일 지표 (guardrail metric)

실험으로 인해 부정적인 영향을 받을 수 있는 지표 혹은 서비스에 중요한 지표로 설정한다.


위 두 지표 외에도 보조지표를 설정해서 실험의 영향을 확인하기도 하며, 성공 지표와 가드레일 지표를 포함하여 최소 4~5개의 지표를 설정하는 것이 바람직하다고 한다. (참고 자료: https://blog.hackle.io/post/conquering-abtest-2)


그렇다면 다시 예시로 돌아가서, 공유 보상 실험의 지표를 설정해 보자.


성공 지표는 뭐였을까?

문제와 가설을 다시 보면 성공 지표를 정하기 쉬워진다.

결과이미지를 통한 결제 매출이 N% 상승할 것이다.

가 가설이었으니, 성공 지표는 '결과이미지를 통한 결제 매출'이 되어야 한다.

                    

가드레일 지표는 각 그룹에 속한 사용자들의 전체 매출로 설정했다.

1. 매출이 중요한 지표이기도 하고

2. 하트 보상을 받아서 결제를 덜 하게 될 수도 있기 때문이다.

기본적으로 무료 보상을 주는 기능에서는 결제가 위축되지는 않는지 확인해야 한다.


마지막으로, 보조지표로는 결과이미지 공유 수, 결과이미지 유입 수 관련 지표를 측정했다.


3. 실험 결과 확인

각 그룹 별 대략적인 차이만 반영한 가짜 데이터.

이 실험의 경우, 성공 지표만 봐도 어떤 그룹이 Winner 인지 파악이 매우 쉬운 실험이었다.

문제는 B그룹 같은 경우에서 발생하는데, 성공 지표는 상승했지만 가드레일 지표에서 하락세를 보이고 있다.


만약 이 실험에서 C그룹 없이 A그룹과 B그룹만으로 실험을 진행했다면 어떻게 Winner를 결정할 수 있을까?

1. 실험 전에 미리 설정했던 지표들뿐 아니라 다른 행동 데이터들도 활용하여 왜? 를 딥하게 탐구해야 한다.

2. 실험에 포함된 사용자들을 여러 세그먼트로 나누어서 결과를 다시 해석해봐야 한다. 심슨 패러독스 현상으로 인해 전체 실험 결과와 세그먼트별 결과가 다르게 나오는 것은 흔한 경우이기 때문이다. 특정 세그먼트에서는 가드레일 지표에 악영향을 주지 않으면서 성공 지표는 높게 잡히는 케이스가 있을 수 있다.

3. 가드레일 지표가 떨어지는 것을 감수하고라도 성공 지표의 상승을 택할 것인지 고민해야 할 때가 있다. 이런 경우에는 가능하다면 가드레일 지표의 하락세와 성공 지표의 상승세를 반영하여 지표 프로젝션을 해보는 것이 가장 좋다.


주의할 점


1. 통계적 유의성 확보하기

A/B 테스트를 처음 할 때, 가장 고민됐던 건 의외로 실험을 종료하는 순간이었다.

'이거 지금 종료해도 되나..? 실험 결과를 믿어도 되는 건가?' 같은 생각이 들었기 때문이다. (당시에는 PM도 PO도 아닌 앱 개발자였으니 이해해 주세요..)


이런 때 확인할 수 있는 게 통계적 유의성이다.

통계적 유의성이란 통계학자가 자신의 실험(또는 기존 데이터에 대한 연구) 결과가 우연히 일어난 것인지 아니면 우연히 일어날 수 없는 극단적인 것인지를 판단하는 방법이다. 결과가 우연히 벌어질 수 있는 변동성 바깥에 존재한다면 우리는 이것을 통계적으로 유의하다고 말한다.

출처: 기초통계 (21) 통계적 유의성과 p값


통계적 유의성 관련해서 디테일한 설명을 하려면 (능력도 부족하거니와) 내용이 너무 산으로 가게 되기 때문에, 언급만 하고 넘어가려고 한다.

대부분의 A/B 테스트 툴에서 p-value를 계산해주고 있으니 쓰고 있는 툴을 확인해보시는 것을 추천한다.


다만, 툴에서 계산해주지 않거나, 툴을 이용하지 않고 A/B 테스트를 진행하고 있다면 서베이몽키에서 제공하는 계산기를 이용하면 된다.


2. 최소 기간 지키기

그렇다면, 통계적 유의성만 확보되면 바로 실험을 종료해도 되는 걸까?

답은 NO다.


만약 특정 실험이 하루 만에 통계적 유의성을 확보한 성공으로 나온다 하더라도, 시간이 더 흐르면 성공도 실패도 아닌 null 값으로 바뀌거나, 아예 실패로 변경될 수도 있다.

다양한 요인이 있을 수 있겠지만 대표적으로는 신기 효과(novelty effect)를 꼽을 수 있는데, 신기 효과란 심리학 용어로서 새롭고 낯선 것에 관심을 가지게 되지만 적응된 후에는 관심을 끌지 못하는 것을 의미한다.

신기 효과의 여파로 일시적으로 성과를 보이는 것에 현혹되지 않으려면, 실험 내용에 따라 적절한 최소 기간을 설정하고 지키는 것이 중요하다.


3. 핵심만 담아 가볍게

이 점은 아무래도 개발자 출신이라 더 고민하게 됐던 듯싶다.

간단한 UI 테스트라면 몰라도, 거대한 기능을 A/B 테스트로 실험하는 것은 -개발하는 입장에서- 쉽지 않다.

물론 상황에 따라 거대한 실험이 필요할 수 있지만, 보통은 검증하고 싶은 가설의 핵심만 담아 추리면 개발 공수를 많이 줄일 수 있다. 과정에서 개발자와의 소통은 필수!


예를 들어, 위에 언급했던 헬로우봇 공유 보상 기능의 경우

각 스킬별로 공유 보상을 얼마 지급할지 운영단에서 직접 설정할 수 있게 되어있다.

그런데, A/B 테스트에 보상 설정 기능이 포함되어야 할까?

당시 검증하고자 했던 가설은 '공유 보상이 있으면 결과이미지를 통한 결제액이 상승할 것이다'였고, 따라서 보상액 설정 기능은 테스트 대상에 포함되지 않아도 되는 상황이었다.

덕분에 모수 확보에 가장 용이한 스킬 하나만 선정하여 실험을 세팅할 수 있었고, 매우 빠르게 실험 설계 - 개발 - 배포 - 결과 확인 사이클을 돌 수 있었다.



마무리하며

1월 1일을 맞아 돌다리도 두들겨보고 건너는 A/B 테스트의 기술에 대해 소개해봤다.

A/B 테스트가 뭔지 궁금해하는 주니어 분들이나, A/B 테스트를 실무에 적용하려다 어려움을 겪고 계신 분들에게 조금이나마 도움이 되길 바란다.


또, 'A/B 테스트가 핫하다던데.. 나(우리)도 빨리 시작해야 하는 거 아닌가?!' 하는 조바심을 느끼는 분이 있다면..

무조건 해야만 하는, 성공을 보장하거나 어떤 상황에도 딱 맞아떨어지는 방법 or 프로세스는 없다는 말을 전해주고 싶다.

모든 방법론은 적절한 상황 적절한 팀에서 사용할 때 효과가 가장 좋으니, 팀과 조직, 나와 협업자들의 상황에 맞게 사용하시길!




글을 쓴 건 분명 1월 1일이었는데.. 지금은 1월 2일이 되어버린... 작가님들 다 존경합니다.

틀리거나 애매한 내용이 있다면 덧글로 지적해 주세요. 감사히 여기고 수정 반영 하겠습니다 :)





브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari