A/B테스트에서 가장 중요한 사용자 분배 방법과 고려할 점
서비스

A/B테스트에서 가장 중요한 사용자 분배 방법과 고려할 점

A/B 테스트에서 사용자를 무작위로 분배할때 고려해야 하는 것에 대해 알려드립니다.

Yong
,
Co-Founder&Software Engineer
September 15, 2020
콘텐츠 공유

A/B Test

사용자를 여러 그룹으로 무작위 분배하는 것은 A/B 테스트에서 중요한 부분입니다. 사용자를 무작위로 분배할때 고려해야 하는 점은 아래와 같습니다.

검증되지 않은 변경을 테스트하는 것이기 때문에 한번에 모든 사용자가 테스트에 참여하면 리스크가 있습니다. 일부 사용자만 테스트에 참여시키고 참여 비중을 조금씩 높여 가야 합니다.

테스트 도중 그룹이 바뀌게 되면 사용자 경험이 달라지게 되고 그로 인해 데이터가 오염됩니다.

모든 테스트가 그룹을 분배하는 기준이 동일하면 항상 같은 사용자끼리 그룹화가 되기 때문에 사용자를 테스트에 할당하고 그룹으로 분배하는 기준은 테스트마다 달라야 합니다.

서버의 응답 시간, 페이지의 로딩 시간 또한 사용자 경험에 영향을 미치게 됩니다. 사용자가 테스트에 할당됐는지 확인하고 특정 그룹으로 분배하는 과정은 빠른 시간 내에 처리되어야 합니다.

여러 개의 A/B 테스트를 진행하다 보면 초당 수천, 수만 번의 사용자 분배를 해야 합니다.

A/B 테스트를 사용하는 서버의 환경이 다를 수 있습니다. 사용하는 환경, 프로그래밍 언어가 달라도 사용자 분배는 동일한 로직으로 처리되어야 합니다. 위 조건들을 고려하여 A/B 테스트에 사용자를 할당하고 분배하는 방법을 소개 하고자 합니다.

Deterministic Bucketing

버케팅은 A/B 테스트에서 사용자를 할당하고 특정 그룹으로 분배하기 위한 프로세스입니다. 버케팅은 결정적(Deterministic)입니다. A/B 테스트의 조건이 변경되지 않는 한 사용자는 항상 동일한 그룹으로 할당됩니다.

버킷

각 A/B 테스트는 자신이 속한 버킷이 있습니다. 버킷은 사용자를 무작위로 섞는데 사용할 시드(seed)와 10000개의 슬롯을 가지고 있습니다.

해싱

시드와 사용자아이디를 해싱하여 슬롯 범위에 해당하는 정수로 맵핑합니다. 해시 함수는 결정적이므로 시드가 변경되지 않는 한 같은 사용자아이디는 항상 동일한 슬롯으로 맵핑됩니다.

슬롯과 할당량

10000개의 슬롯은 100%의 할당 비율에 해당됩니다. 즉 1개의 슬롯은 0.01%의 할당량을 차지합니다.

A/B 테스트에 사용자 할당
할당 (0%)

사용자 할당이 0%일 때는 어떠한 사용자도 A/B 테스트에 할당되지 않습니다.

할당 (40%)

사용자 할당이 40%라면 0~3999번 슬롯으로 맵핑된 사용자는 A/B 테스트에 할당됩니다.

그룹 분배
할당 (40%) / 분배 A(50), B(50)

테스트에 할당된 사용자들을 기준으로 그룹을 분배합니다. A, B 두개의 그룹이 있고 각각의 분배비율이 50:50 이라면 0~1999 슬롯에 맵핑된 사용자는 A로 분배되고, 2000~3999 슬롯에 맵핑된 사용자는 B로 분배 됩니다.

할당 (40+20%) / 분배 A(50), B(50)

사용자 할당을 60%로 증가시키면 추가된 20%에 해당하는 슬롯을 더 할당해야 합니다. 아직 할당이 되지 않은 슬롯 2000개(20%)를 분배 비율에 맞게 할당합니다.

버케팅 과정 정리
  1. 시드를 사용해서 사용자를 슬롯으로 맵핑
  2. 맵핑된 슬롯에 의미를 부여 (테스트 할당, 그룹 분배)

여러 테스트가 같은 버킷에 속해서 같은 시드를 사용하게 구성한다면 상호배타적으로 진행되어야 하는 테스트도 할 수 있습니다.

이제 버케팅을 사용하는 곳을 고려해야 합니다.

버케팅 서버

다양한 환경에서 일관된 로직으로 버케팅 하기 위해 가장 간단하게 할 수 있는 방법은 버케팅 서버를 별도로 두고 API를 제공하는 것입니다.

하지만 이 방법은 버케팅이 필요할 때마다 네트워크 호출을 해야 하고 처리속도와 처리량도 안좋습니다.

인메모리

버케팅을 위해 필요한 정보는 시드, 슬롯의 상태 밖에 없습니다. 이 정보들을 인메모리 캐시하고 있으면 네트워크 호출없이 아주 빨리, 많은 양을 처리 할 수 있습니다. 인메모리 캐시는 A/B 테스트 설정정보를 관리하는 서버와 동기화 시켜주면 됩니다.

하지만 이 방법은 A/B 테스트를 사용하는 서버마다 버케팅, 동기화 로직을 구현해야 하는 단점이 있습니다.

SDKs

인메모리캐시, 동기화, 버케팅 로직을 포함하는 SDK를 언어별로 제공합니다. 사용하는곳에서는 자신의 환경에 맞는 SDK를 사용하면 메소드 호출 한번만으로 간단하게 버케팅을 할 수 있고 처리속도, 처리량 모두 뛰어납니다.

사용자아이디가 시스템간 일관되게 공유가 된다면 어떤 SDK를 사용하더라도같은 결과가 나오게 됩니다.

마무리

A/B 테스트에서 사용자를 할당하고 그룹으로 분배하는 방법을 살펴보았습니다. 버케팅과 SDK는 A/B 테스트 구현의 기본이 되는 요소입니다. 이 두 요소를 활용하면 더 복잡한 기능들도 유연하게 대처할 수 있습니다. A/B 테스트의 구현을 고민하시는 분들께 도움이 되었기를 바라며 글을 마치겠습니다.

A/B 테스트에 대해 더 많은 정보를 알고 싶으시다면 여기에서 확인하실 수 있습니다. 감사합니다.

트위터에 공유하기
제품 주도 성장에 필요한 모든 기능을
All-in-One 플랫폼 핵클과 함께 시작해보세요!
무료 체험 시작하기
콘텐츠 공유
인터뷰에 나온 회사처럼,
빠르게 성장하고 싶다면 핵클과 함께 하세요!
핵클 드림팀 신청하기

성장의 시작, 핵클이 함께합니다!

비대면 바우처를 통해 70% 할인된 금액으로 핵클을 시작해보세요.
자세히 알아보기

👀 이런 콘텐츠는 어때요?