Optimizely에서 상호 배타적 실험 그룹을 구성하여 트래픽 충돌을 방지하는 방법

디지털 실험을 빠르게 실행하는 제품 및 그로스 조직에서는 동일한 웹페이지, 결제 퍼널, 주요 전환 여정에서 여러 A/B 테스트를 동시에 진행하는 경우가 빈번합니다. 하지만 한 사용자가 서로 다른 두 개 이상의 실험에 중복 배정되면 **상호작용 효과(Interaction Effects)**가 발생하여 지표 개선이 어느 실험 덕분인지 파악할 수 없게 되며, 트래픽 비율 왜곡으로 인해 샘플 비율 불일치(Sample Ratio Mismatch, SRM) 경고가 발생할 위험이 커집니다.

Optimizely에서는 이를 해결하기 위해 **배타 그룹(Exclusion Groups / Mutually Exclusive Groups)**을 구성합니다. 배타 그룹은 중복되는 실험들을 묶어주는 트래픽 컨테이너 역할을 하며, 동일한 결정론적 해시 시드를 공유하여 오디언스 트래픽을 배타적으로 분할합니다. 배타 그룹 내에서 실험 A에 배정된 사용자는 동일 그룹 내 실험 B에 절대 노출되지 않습니다.

상호 배타적 그룹을 사용해야 하는 경우와 피해야 하는 경우

상호 배타성을 설정하면 데이터의 통계적 신뢰성을 확보할 수 있지만, **트래픽 희석(Traffic Dilution)**이라는 대가가 따릅니다. 한정된 전체 트래픽을 여러 실험으로 나누게 되므로 실험당 표본 크기가 줄어들고, 통계적 유의성에 도달하기까지 필요한 기간이 늘어납니다.

실험 운영팀은 상황별로 명확한 기준을 적용해야 합니다.

Optimizely 상호 배타 분류의 내부 동작 원리

기본 상태에서 Optimizely는 각 실험을 독립적으로 분류(Bucketing)합니다. 각 실험마다 사용자 고유 식별자(User ID 또는 Bucketing ID)와 실험 ID(Experiment ID)를 조합하여 결정론적 해시 알고리즘인 MurmurHash3를 통과시킨 후, 0부터 9,999까지 총 10,000개의 트래픽 버킷에 매핑합니다.

독립된 실험들은 서로 다른 해시 값을 산출하므로, 동일한 사용자가 동시에 진행 중인 여러 실험의 유효 버킷에 중복 배정될 수 있습니다.

실험을 **배타 그룹(Exclusion Group)**에 등록하면 분류 메커니즘이 변경됩니다:

1. 공유 해싱 도메인: 해시 함수는 사용자 식별자를 각 실험 ID가 아닌 배타 그룹 ID와 조합하여 먼저 평가합니다.
2. 결정론적 구간 분할: 10,000개의 버킷이 배타 그룹 내 각 실험에 설정된 트래픽 비율에 맞춰 배타적으로 할당됩니다.
3. 완전 격리: 사용자가 실험 A에 해당하는 버킷 구간에 배정되면 오직 실험 A에만 참여 자격을 얻으며, 그룹 내 실험 B나 실험 C의 평가 대상에서는 즉시 제외됩니다.

분류 평가 우선순위 (Evaluation Order)

Optimizely Feature Experimentation 및 Web Experimentation에서 사용자 결정은 엄격한 우선순위에 따라 단락 평가(Short-Circuiting)됩니다:

1. 규칙 활성화 확인: 플래그 규칙 또는 실험이 활성 상태인지 점검.
2. 강제 변형(Forced Variations): 최우선 적용 (QA 및 디버깅용).
3. 허용 목록 사용자(User Allowlisting): 특정 사용자 ID의 고정 배정.
4. 사용자 프로필 서비스(User Profile Service, UPS): 이전 세션에서 저장된 고정 변형 기록 확인.
5. 오디언스 타겟팅(Audience Targeting): 사용자 속성이 타겟 조건에 맞는지 평가.
6. 배타 그룹 평가(Exclusion Group Evaluation): 해당 사용자가 그룹 내 다른 실험에 이미 할당되었는지 확인 후 중복 시 제외.
7. 트래픽 분배 및 변형 결정(Traffic Allocation): 최종 선정된 실험 내 비율에 따라 변형(A안 또는 B안) 배정.

단계별 가이드: Optimizely Web Experimentation 설정

클라이언트 사이드 또는 Edge 환경에서 웹 실험을 진행하는 팀을 위한 단계입니다:

1. 배타 그룹 생성

1. Optimizely Web Experimentation 대시보드에서 Experiments로 이동합니다.
2. Exclusion Groups 탭을 클릭합니다. (참고: Optimizely Personalization을 사용하는 경우 Optimizations > Exclusion Groups로 이동).
3. Create New Exclusion Group 버튼을 클릭합니다.
4. 식별하기 쉬운 그룹 이름(Name)(예: Checkout_Funnel_Q2_Exclusion)과 선택적 **설명(Description)**을 입력합니다.

2. 실험 등록 및 트래픽 비율 할당

1. 배타 그룹에 포함할 초안(Draft) 상태의 실험들을 선택합니다.
2. 배타 그룹 전체 트래픽 중 각 실험이 차지할 비율을 지정합니다:
   • 두 개의 실험이라면 각각 50%씩 균등 할당;
   • 또는 비참여 제어군(Holdout)을 남길 수도 있습니다 (예: 실험 1에 40%, 실험 2에 40%, 미할당 20%).
3. Create Exclusion Group을 클릭하여 저장합니다.

3. 활성화 조건 및 페이지 타겟팅 확인

그룹에 속한 모든 실험이 동일한 URL 조건과 이벤트 트리거를 공유하는지 점검하여 불균형한 노출을 방지합니다.

단계별 가이드: Optimizely Feature Experimentation 설정

백엔드, 모바일 앱, 풀스택 아키텍처 환경에서 개발하는 엔지니어링 팀을 위한 단계입니다:

1. Flags 대시보드에서 배타 그룹 생성

1. Flags 메뉴에서 Exclusion Groups 탭을 선택합니다.
2. Create New Exclusion Group을 클릭합니다.
3. 그룹 이름과 설명을 입력합니다.
4. 적용 대상 환경(Environment)(예: Production, Staging)을 지정합니다. 배타 그룹은 환경별로 독립적으로 관리됩니다.
5. Create Exclusion Group을 클릭하여 생성을 완료합니다.

2. 플래그 실험 규칙을 배타 그룹에 연결

1. Flags 목록으로 돌아가 실험 규칙이 포함된 기능 플래그(Feature Flag)를 엽니다.
2. 해당 환경을 선택하고 구체적인 Experiment Rule로 들어갑니다.
3. Configure Rule 섹션에서 "Add this experiment to the following exclusion group" 드롭다운 메뉴를 찾습니다.
4. 앞서 생성한 배타 그룹을 선택합니다.
5. 이 실험이 배타 그룹 내에서 가져갈 트래픽 백분율을 입력합니다.
6. Save Experiment를 클릭합니다.
7. 배타 관계를 유지해야 하는 다른 실험 규칙들에도 동일하게 적용합니다.

3. REST API를 통한 자동화 배포

배포 자동화(CI/CD)를 적용하는 엔지니어링 팀은 API를 통해 직접 배타 그룹을 관리할 수 있습니다:

• 그룹 생성: POST /v2/groups (페이로드: {"name": "Cart_Redesign_Group", "environment_key": "production"}).
• 규칙 등록: PATCH /v2/groups/{group_id} (실험의 고유 rule_id 전달).
• 구성 감사: GET /v2/groups (환경 내 활성화된 배타 그룹 목록 조회).

4. SDK 코드 수정 불필요

배타 그룹 로직은 다운로드되는 규칙 파일(Datafile / Ruleset)에 정의되어 SDK가 메모리 내에서 자동으로 처리합니다. 애플리케이션에서 client.decide(user_key, flag_key)를 호출할 때 추가적인 분기 코드를 작성할 필요가 없습니다.

실험 조직이 반드시 준수해야 할 4가지 거버넌스 원칙

데이터 오염과 통계적 오류를 방지하기 위해 실험 조직은 다음 네 가지 원칙을 지켜야 합니다:

1. 배타 그룹 내 실험들은 반드시 동시에 론칭할 것

오늘 실험 1을 시작하고 다음 주에 같은 배타 그룹에 실험 2를 추가해서는 안 됩니다. 이미 일부 사용자가 그룹 차원에서 버킷 배정을 받은 상태에서 실험을 추가하면 해시 경계가 재조정되어 기존 사용자의 배정이 바뀌거나 표본의 무작위성이 깨집니다.

2. 실행 중인 배타 그룹에 실험을 추가하거나 삭제하지 말 것

배타 그룹 내 어떤 실험이라도 운영 중이라면:

• 새로운 실험을 추가하지 마십시오.
• 진행 중인 실험을 그룹에서 제거하지 마십시오. 실행 도중 그룹을 수정하면 트래픽 비율이 붕괴되어 샘플 비율 불일치(SRM) 경고가 발생하고 실험 통계가 무효화됩니다. 특정 실험을 조기 종료해야 한다면 그룹을 해체하지 말고 해당 규칙만 일시 정지(Pause)하십시오.

3. 그룹 내 오디언스 타겟팅 일관성 유지

실험 A는 전체 데스크톱 유저를 타겟팅하고 실험 B는 모바일 유저만 타겟팅하는 경우, 두 실험을 같은 배타 그룹에 넣으면 트래픽 낭비가 발생합니다. 그룹 단위에서 먼저 버케팅이 이루어지므로, 실험 B로 분류된 데스크톱 유저는 아무런 변경도 보지 못하게 되어 실험 A의 유효 표본이 급감합니다.

4. 사용자 프로필 서비스(UPS)의 우선순위 우회 주의

세션 간 일관된 변형 제공을 위해 User Profile Service(UPS)를 사용하는 경우, UPS 조회가 배타 그룹 평가보다 먼저 실행됩니다. 만약 사용자가 배타 그룹에 묶이기 전에 단독 실험 시절의 변형 기록을 가지고 있다면, UPS가 이전 변형을 강제로 반환하여 배타 규칙을 무력화할 수 있습니다. 완벽한 트래픽 분리가 필요하다면 OptimizelyDecideOption.IGNORE_USER_PROFILE_SERVICE 옵션을 활용하십시오.

참고 자료

• Use mutual exclusion - Feature Experimentation docs
• How bucketing works - Feature Experimentation docs
• Optimizely's automatic sample ratio mismatch detection