A/B 테스트

A/B 테스트란?

A/B 테스트는 라이브 트래픽의 일정 비율을 테스트 버전으로 라우팅하고, 나머지는 현재 라이브 버전으로 유지합니다. 두 버전 모두 실행 로그를 생성하므로, 완전히 전환하기 전에 실제 데이터로 성능을 비교할 수 있습니다.

사전 조건

현재 배포된 (라이브) 버전이 있는 정책 그룹
발행된 (ACTIVE 상태) 테스트 버전
두 버전이 동일한 정책 그룹에 속해야 함

트래픽 식별 키

A/B 라우팅은 실행 요청마다 애플리케이션이 함께 보내는 값 하나로 트래픽을 가릅니다. 그 값이 context.trafficKey입니다. 엔진은 이 값을 정책 그룹 ID와 함께 해싱해 버킷을 정하므로, 같은 키 값은 그 그룹에서 항상 같은 버전으로 갑니다. facts가 아니라 context에 담습니다. 라우팅은 context만 읽습니다. facts에 넣은 trafficKey는 무시됩니다.

{
  "facts": {
    "paymentAmount": 150000,
    "customerTier": "VIP"
  },
  "context": {
    "trafficKey": "customer-8f3a21"
  }
}

trafficKey가 없거나 비어 있으면 분배가 일어나지 않고 테스트 버전 트래픽이 0%가 됩니다. 콘솔에는 테스트가 진행 중으로 표시되고 실행 로그도 계속 쌓이므로, 응답만 봐서는 이 상태를 알 수 없습니다. 서버 로그에는 해당 요청마다 경고가 남습니다. 값을 고를 때 기준은 셋입니다.

실험 단위마다 고정된 값을 씁니다. 고객 ID, 가맹점 ID, 세션 ID처럼 실험을 무엇을 단위로 측정할지에 맞춥니다
원본 식별자 대신 해시나 대체 키를 씁니다. context 객체 전체가 실행 원장에 저장되므로 이메일이나 전화번호를 그대로 담지 않습니다
요청마다 바뀌는 값은 쓰지 않습니다. 요청 ID나 타임스탬프를 넣으면 한 사용자가 두 버전에 흩어져 비교가 무너집니다

버킷은 그룹마다 독립입니다. 그룹 ID가 해시에 섞이므로 같은 trafficKey 값이라도 정책 그룹마다 배정이 따로 정해지고, 한 실험이 다른 실험을 오염시키지 않습니다.

키를 담는 자리

엔드포인트	라우팅이 키를 읽는 자리
`POST /execution/groups/{groupId}`	`context.trafficKey`
`POST /execution/composite`	`context.trafficKey`. 그룹마다 버킷이 따로 정해집니다
`POST /execution/groups/{groupId}/batch`	`sharedContext.trafficKey`. 배치 전체가 한 버전으로 실행되며, 개별 요청의 `context.trafficKey`는 버전 결정에 영향을 주지 않습니다
`POST /execution/groups/{groupId}/versions/{versionId}`	읽지 않습니다. 이 엔드포인트는 라우팅을 건너뜁니다

GET /execution/groups/{groupId}/requirements가 돌려주는 exampleRequest의 context에는 trafficKey가 없습니다. 이 템플릿을 그대로 복사하면 A/B 테스트가 0%로 돕니다.

A/B 테스트 시작

콘솔

정책 그룹으로 이동 → A/B 테스트 시작 클릭 → 테스트 버전 선택 → 트래픽 비율 설정.

CLI

lexq groups ab-test start \
  --group-id <groupId> \
  --version-id <testVersionId> \
  --traffic-rate 10

--traffic-rate는 테스트 버전으로 라우팅할 트래픽 비율(1–99%)입니다. 나머지 트래픽은 라이브 버전으로 갑니다.

결과 모니터링

A/B 테스트 중 두 버전 모두 실행 로그를 생성합니다:

lexq history stats --group-id <groupId>

성공률, 매칭률, 레이턴시, 출력 변수 분포를 비교하세요.

트래픽 조정

확신이 생기면 점진적으로 테스트 버전의 트래픽을 증가시킵니다:

lexq groups ab-test adjust --group-id <groupId> --traffic-rate 30
lexq groups ab-test adjust --group-id <groupId> --traffic-rate 50

A/B 테스트 중지

lexq groups ab-test stop --group-id <groupId>
lexq groups ab-test stop --group-id <groupId> --force

중지하면 모든 트래픽이 라이브 버전으로 돌아갑니다. 테스트 버전은 ACTIVE 상태를 유지하지만 더 이상 트래픽을 수신하지 않습니다.

일반적인 워크플로우

규칙 변경사항이 있는 새 DRAFT 버전 생성
드라이런으로 변경사항 검증
새 버전 발행 (DRAFT → ACTIVE)
실행 요청이 context.trafficKey를 싣는지 확인
10% 트래픽으로 A/B 테스트 시작
실행 로그 모니터링 및 지표 비교
점진적 증가: 10% → 30% → 50%
만족스러우면 테스트 버전을 새 라이브 버전으로 배포
A/B 테스트 중지

A/B 테스트는 프로덕션 트래픽에 영향을 줍니다. 낮은 비율(5–10%)로 시작하고 스케일업 전에 면밀히 모니터링하세요.

시작하기

핵심 개념

기능

A/B 테스트란?

사전 조건

트래픽 식별 키

키를 담는 자리

A/B 테스트 시작

콘솔

CLI

결과 모니터링

트래픽 조정

A/B 테스트 중지

일반적인 워크플로우

다음 단계

변경 영향 시뮬레이션

배포

​A/B 테스트란?

​사전 조건

​트래픽 식별 키

​키를 담는 자리

​A/B 테스트 시작

​콘솔

​CLI

​결과 모니터링

​트래픽 조정

​A/B 테스트 중지

​일반적인 워크플로우

​다음 단계

변경 영향 시뮬레이션

배포

A/B 테스트란?

사전 조건

트래픽 식별 키

키를 담는 자리

A/B 테스트 시작

콘솔

CLI

결과 모니터링

트래픽 조정

A/B 테스트 중지

일반적인 워크플로우

다음 단계