이 글은 Tech-Verse 2025에서 발표된 동적 유저 세분화를 활용한 새로운 A/B 테스트 시스템 세션을 글로 옮긴 것입니다.
안녕하세요. LINE+ Contents Service Server 1 팀 조강훈입니다. 이번 글에서는 동적으로 사용자 그룹을 분할하는 방법을 활용해 고도화한 A/B 테스트 시스템을 소개하겠습니다.
A/B 테스트란?
먼저 A/B 테스트란 무엇일까요? A/B 테스트란 두 개 혹은 그 이상의 버전들을 비교함으로써 어떤 버전이 더 나은 버전인지 확인할 수 있는 방법입니다.
예를 들어 제가 어떤 웹사이트의 운영자라고 가정해 보겠습니다. 현재 이 웹사이트의 배너는 흰색인데 배너 색상을 파란색으로 바꾸면 사용자가 더 많이 클릭할 것 같다는 생각이 들었습니다. 이때 먼저 일부 사용자에게만 배너를 파란색으로 노출하고 일정 시간이 지난 후 기존 버전과 신규 버전의 CTR(click-through rate)을 비교해 보면 어떤 버전이 더 나은 버전인지 확인할 수 있을 것입니다. 이것이 A/B 테스트입니다.
그렇다면 A/B 테스트는 왜 필요할까요? 저는 두 가지 이유로 A/B 테스트가 필요하다고 생각합니다. 첫 번째는 더 좋은 사용자 경험을 만들기 위해서입니다. 어떤 디자인 혹은 기능이 사용자에게 더 좋은 경험을 줄지 판단하기 위해서 A/B 테스트가 필요합니다. 두 번째는 데이터에 기반해 의사 결정을 내리기 위해서입니다. A/B 테스트를 실시하면 단순히 추측하거나 직관에 의존하지 않고 데이터에 기반해 의사 결정을 내릴 수 있습니다.
A/B 테스트에서 테스트 그룹을 나누는 방법
본격적으로 새로운 A/B 테스트 시스템을 설명하기 전에 테스트 그룹의 개념을 살펴보겠습니다.
A/B 테스트를 진행할 때에는 사용자를 '컨트롤 그룹'과 '테스트 그룹'으로 나눕니다. 이때 컨트롤 그룹은 새로운 변화가 적용되지 않고 기존의 상태를 그대로 유지하는 그룹이고, 테스트 그룹은 새로운 변화가 적용되는 그룹입니다. 아래 예시에서는 기존과 동일한 흰색 배너가 노출되는 그룹이 컨트롤 그룹이고, 새로운 파란색 배너가 노출되는 그룹이 테스트 그룹입니다.
여기서 테스트 그룹을 어떤 기준으로 나눌지가 아주 중요한 요소인데요. 일반적인 A/B 테스트 시스템과 고도화한 A/B 테스트 시스템의 테스트 그룹 분배 방법을 비교해 보겠습니다.
일반적인 A/B 테스트 시스템에서 테스트 그룹 나누는 방법
일반적인 A/B 테스트 시스템에서는 테스트 그룹을 나눌 때 무작위로 나눕니다. 예를 들면 사용자의 아이디를 기반으로 해시값을 추출해서 이 해시값을 기반으로 테스트 그룹을 무작위로 나눕니다.
이런 방식에는 두 가지 장점이 있습니다. 첫 번째는 시스템이 간단해집니다. 시스템이 간단하다 보니 구현하고 관리하기 쉬워지며, 시간이나 인력 등 리소스 측면에서 비용을 절약할 수 있습니다. 두 번째는 신뢰를 확보할 수 있습니다. 무작위로 나누기 때문에 그룹 간 편향이 감소하며, 이를 통해 테스트의 신뢰를 높일 수 있습니다.
고도화한 A/B 테스트 시스템: 동적 사용자 분할
그렇다면 고도화한 A/B 테스트 시스템은 어떤 점이 다를까요? 설명하기 위해 앞의 배너 예시의 가정을 살짝 변형해 보겠습니다. 새로운 가정은 '오사카에 사는 iOS 사용자의 경우 배너가 파란색이면 CTR이 더 높을 것이다'입니다.
새로운 가정에서는 앞서와는 다르게 전체 사용자를 대상으로 하는 게 아니라 특정 사용자 세그먼트를 대상으로 하는 테스트가 필요합니다. 이런 경우 테스트 그룹을 무작위로 나누기보다는 동적 사용자 분할 기법을 활용해서 사용자 세그먼트 기반으로 테스트 그룹을 나눠야 하며, 이것이 이번 글에서 소개하려는 고도화한 A/B 테스트 시스템입니다.
새로운 버전을 배포하기 전에 특정 사용자 세그먼트의 반응만 확인하고 싶다면 고도화한 A/B 테스트 시스템이 필요합니다. 일반적인 A/B 테스트 시스템과 달리 고도화한 A/B 테스트 시스템은 사용자 세그먼트를 기반으로 테스트 그룹을 나눕니다. 또한 일반적인 A/B 테스트 시스템이 전체 사용자를 대상으로 하는 일반적인 테스트용이라면 고도화한 A/B 테스트 시스템은 사용자의 특성에 기반해 개인화한 테스트에 특화돼 있습니다.
| 일반적인 A/B 테스트 시스템 | 고도화한 A/B 테스트 시스템 | |
|---|---|---|
| 그룹 나누기 | 무작위 | 사용자 세그먼트 기반 |
| 사용 사례 | 일반적인 테스트(전체 사용자) | 개인화한 테스트 |
고도화한 A/B 테스트 시스템의 아키텍처
고도화한 A/B 테스트 시스템은 두 가지 컴포넌트로 구성됩니다. 첫 번째 컴포넌트는 특정 사용자 세그먼트를 대상으로 삼기 위한 '타겟팅 시스템'이고, 두 번째 컴포넌트는 A/B 테스트를 설정하고 각 사용자를 테스트 그룹으로 할당하기 위한 'A/B 테스트 시스템'입니다.
각 컴포넌트를 하나씩 살펴보겠습니다.
타겟팅 시스템
먼저 타겟팅 시스템 컴포넌트를 소개하겠습니다. LINE Plus에서는 사용자의 다양한 특성과 관련된 데이터를 HDFS(Hadoop Distributed File System)에 저장합니다.
타겟팅 시스템에서는 Spark 애플리케이션을 이용해 사용자 정보 데이터를 조회해서 사내 오브젝트 스토리지에 저장합니다. HDFS에 이미 사용자 데이터가 저장돼 있는데 별도로 한 번 더 저장하는 이유는 추후 다양한 사용자 세그먼트 추출 시 재사용하기 쉽게 만들기 위해서입니다. 참고로 이 사내 오브젝트 스토리지는 AWS S3와 호환됩니다.
이렇게 필요한 데이터를 조회해 별도 오브젝트 스토리지에 저장해 놓으면, 운영자가 타겟팅 시스템의 관리지 시스템을 통해 '오사카에 사는 iOS 사용자' 세그먼트를 생성하라고 명령합니다. 그러면 Spark 애플리케이션이 오브젝트 스토리지의 데이터 중 '오사카에 사는 iOS 사용자' 데이터만 추출해서 Redis에 저장하는데요. 세그먼트를 생성하면서 세그먼트 아이디가 발급되며, Redis에 저장할 때 사용자 아이디와 세그먼트 아이디를 조합해 Redis 키를 생성합니다. 예를 들어 아래와 같이 Redis에 1-777이라는 키가 있으니 사용자 아이디가 1인 사용자는 777이라는 세그먼트에 속해 있다고 볼 수 있습니다.
또한 타겟팅 시스템에서는 타겟팅할 때 Spark 관계형 DB의 union(), intersect(), subtract() API를 통해서 AND/OR 조건, 합집합, 차집합 연산과 같은 다양한 조건 연산을 지원합니다.
A/B 테스트 시스템
다음으로 A/B 테스트 시스템 컴포넌트를 소개하겠습니다. 운영자는 관리자 시스템을 이용해 A/B 테스트를 설정할 수 있습니다. 테스트 정보는 Central Dogma라는 설정 리포지터리에 JSON 형태로 저장됩니다. 테스트 그룹은 단순히 컨트롤 그룹과 테스트 그룹, 이렇게 두 개만 설정할 수 있는 것은 아니고요. 두 개 이상의 그룹도 설정할 수 있습니다.
이렇게 설정한 각 그룹에 세그먼트를 할당할 수 있습니다. 어떤 사용자 세그먼트를 매핑할 것인지 해당 세그먼트 아이디를 입력하면 됩니다. 예를 들면 아래 예시에서는 테스트 그룹 1번에 세그먼트 아이디 777을 할당하고 있습니다.
즉, 위 설정에 따라 오사카에 사는 iOS 사용자는 테스트 그룹 1번에 속하며, isRestOfThem 설정에 따라 777 세그먼트가 아닌 사용자는 전부 컨트롤 그룹에 속하게 됩니다.
또한 저희가 개발한 A/B 테스트 시스템은 사용자 세그먼트 기반의 테스트 그룹 분배만 할 수 있는 것이 아니라 아래와 같이 사용자 아이디의 해시 값을 활용해서 무작위로 테스트 그룹을 나누는 것도 가능합니다.
전체 작동 흐름
이제 새로운 A/B 테스트 시스템이 어떻게 작동하는지 전체적으로 살펴보겠습니다. 아래 그림의 맨 왼쪽 클라이언트는 최종 사용자의 단말을 의미하며, 가운데 아래 왼쪽 파란색 영역이 A/B 테스트 시스템 컴포넌트, 오른쪽 파란색 영역이 타겟팅 시스템 컴포넌트입니다.
작동 흐름은 다음과 같습니다.
- 먼저 클라이언트가 사용자 아이디(
user_id)가 포함된 요청을 전송하면 테스트 그룹 할당자(Test Group Assigner)가 이 요청을 받습니다. - 테스트 그룹 할당자는 우선 Central Dogma에서 A/B 테스트 관련 정보를 가져옵니다. 위 예제에서 는 이 정보에 테스트 그룹 1번에 해당하는 세그먼트 아이디(
segment_id)가777이라는 정보가 포함돼 있습니다. - 테스트 그룹 할당자가 사용자의 아이디와 세그먼트 아이디를 기반으로 해당 사용자가 어느 테스트 그룹에 속하는지 판단합니다. 위 예제에서는 Redis에
1-777이라는 키가 있으니 해당 사용자가 테스트 그룹 1번에 속한다는 것을 알 수 있습니다. - 테스트 그룹 할당자는 3번에서 확인한 테스트 그룹을 바탕으로 업스트림 서버로부터 해당 테스트 그룹에 맞는 데이터를 가져옵니다.
- 테스트 그룹 할당자가 업스트림 서버에서 클라이언트에 맞게 가져온 데이터를 클라이언트에게 응답 데이터로 전송합니다.
- 실행 중인 테스트의 아이디와 할당받은 테스트 그룹 정보를 로그 스토어(Log Store)에 저장합니다. 이 데이터는 테스트 종료 후 결과를 확인하기 위한 대시보드를 구성할 때 사용합니다.
활용 사례
현재 이 시스템을 실제로 어떻게 사용하고 있는지 소개하겠습니다. 저희 팀은 주로 컨텐츠를 추천하는 플랫폼을 개발하고 있으며, 사용자에게 어떤 컨텐츠를 추천할지 혹은 페이지 내 모듈의 순서를 어떻게 노출하는 게 좋을지를 개인화 추천을 통해서 판단하고 있는데요. 어떤 머신러닝 모델의 성능이 좋을지 특정 사용자 세그먼트의 반응만 확인하고 싶을 때 고도화한 A/B 테스트 시스템이 필요합니다.
그 외에도 아래와 같은 활용 사례를 생각해 볼 수 있습니다. 먼저 어떤 앱에서 새로운 온보딩 화면이 효과가 있는지 확인하기 위해 전체 사용자가 아닌 신규 사용자만을 대상으로 테스트하고 싶은 경우가 있겠습니다. 또한 쇼핑 서비스에서 할인 쿠폰이 주문 빈도에 영향이 있는지 알고자 라이트 유저만을 대상으로 테스트하고 싶은 경우가 있겠습니다. 헤비 유저의 경우 할인 쿠폰이 주문 빈도에 영향이 없을 가능성이 크기 때문입니다.
향후 계획
마지막으로 앞으로의 계획을 말씀드리겠습니다. 먼저 이번 글에서 소개한 고도화한 A/B 시스템을 현재 LINE Wallet과 LYP Premium 서비스에서만 사용하고 있는데요. 그 외 LY Corporation 내 다양한 서비스에서도 사용할 수 있도록 플랫폼을 확장할 계획입니다. 두 번째로 테스트의 전체 라이프 사이클을 관리할 수 있는 관리자 시스템을 개발할 계획입니다. 개발이 완료되면 테스트를 생성/수정하고 결과까지 확인할 수 있는 통합 관리자 시스템이 제공될 예정입니다.
추후 기회가 닿는다면 플랫폼 확장 및 통합 관리자 시스템 개발 완료 후 다시 이 블로그를 통해 공유드리겠습니다. 긴 글 읽어주셔서 감사합니다.
