A/B 테스트

1. 개요

- 서비스의 특정 기능을 새로 론칭하기 전에 기존 사용자층 전체(A그룹, 컨트롤 그룹이라고도 한다)에 곧바로 노출시키는 게 아니라 소수 사용자(B그룹=테스트 그룹)에게 먼저 노출시키고 그 반응을 기존 사용자층과 대조해본 후 노출 사용자층을 넓혀갈지를 결정하는 새 기능 검증 방식을 A/B테스트라 한다. (어떤 판단을 할지를 ‘데이터를 통해’ 결정하는 것이므로 A/B테스트 후의 결정은 data-driven decision에 속한다.)

- A/B테스트 시작 전에는 항상 ‘테스트 그룹에서 이러한 지표가 얼만큼 개선될 것이다’라는 식의 가설을 명확히 정해두는 것이 좋다.

• A/B테스트는 비용이 많이 나가는 검증 방식이므로 이 부분은 매우 중요하다. 특히 가설을 명확히 정할 수 없는 주제에 대해서는 성공/실패의 기준을 잡을 수가 없으므로 이런 경우에는 A/B테스트가 의미가 없다는 한계가 있다. (이런 경우에 A/B테스트를 한다면 결과에 끼워맞추기식 해석을 할 수 있다.)

• A/B테스트는 세워둔 가설에 대한 데이터를 얻어 그 데이터를 해석해 결정을 내리는 것이므로, 데이터 해석에 있어 통계 지식이 필요하다.

2. A/B테스트의 이점

• 실제 사용자들로부터 유의미한 검증 데이터를 얻을 수 있다: 특정 기능을 어떤 알고리즘으로 구현했을 때 그것이 얼만큼 성능을 보이는지를 평가하는 문제는 매우 중요한 문제인데, 이를 실제 테스트 사용자층에게 실험해보지 않고도 내부적으로 평가하는 방법과 실제 테스트 사용자층에게 실험해보는 방법(A/B테스트)이 있다. 이론적으로 그러한 내부 평가 결과가 실제 평가 결과와 일치하도록 내부 평가 방법을 설계한 것이겠지만, 실제로 정말로 일치하는 경우가 있고 일치하지 않는 경우도 있다. (예를 들어 추천엔진의 경우, 사용자들은 과거에 높은 선호를 표했던 아이템이라 하더라도 시간이 지난 뒤에는 그 아이템에 대한 선호가 크게 떨어질 수 있다. 내부 평가 방법으로는 이러한 케이스를 판별할 수 없다.) 이런 경우에는 A/B테스트를 통해 그 성능을 평가할 수 있다.

• 리스크 최소화: 새 기능을 바로 서비스에 적용하는 것이 아니라 일단 소수 사용자를 대상으로 테스트를 하는 것이므로 리스크를 최소화할 수 있다는 이점이 있다.

3. A/B테스트의 과정

(1) A/B 테스트 가설 제시

(2) 구현

(3) 결과 해석

(4) B그룹 크기를 키워가며 반복하기

(5) 검토

4. A/B테스트 시 고려할 점

• 데이터 결함 여부

• 객관적이고 공개적인 결과 해석: 결과를 해석하는 사람 개인의 주관이 개입되거나 외부에서 자기 입맛에 맞는 해석 관점을 압박할 수 있다. 또, A/B테스트에는 고려해야 할 요소가 굉장히 많기 때문에 이 테스트가 어떤 변수를 고려한 것인지 등의 정보를 공개해 보다 많은 사람이 이를 파악하고 의견을 낼 수 있게 해야 한다.

• 수개의 A/B테스트 사이 간섭: 서비스 내에 여러 A/B테스트가 동시에 이뤄지면 데이터 해석에 어려움이 있을 수 있다.

• 데이터 인프라 비용: A/B테스트는 데이터 인프라 자원을 굉장히 많이 사용하기 때문에(많은 기업의 전체 데이터 인프라 자원의 상당 비율이 A/B테스트 분석에 사용된다), 불필요한 A/B테스트가 자원을 차지하지 않도록 해야 한다.

• A/B테스트 유형을 고려한 결과 해석: 예를 들어 UI/UX 관련 기능에 대한 A/B테스트는 아무리 좋은 기능이라 하더라도 새 기능이라면 사용자 입장에서는 낯설고 불편하기 때문에 테스트 시작 직후에는 매우 낮은 지표를 보이다가 시간이 지나면서 서서히 나아지는 경향이 있다. 따라서 이와 같은 특성을 지닌 기능에 대한 A/B테스트는 이러한 특성을 고려하여 충분한 기간 동안 테스트한 후 그 기능의 효과를 평가해야 한다.

• 아웃라이어 배제: 특정 선택에 대해 굉장히 편향된 사용자를 A그룹 또는 B그룹에 포함시키면 그 그룹쪽으로 지표가 크게 편향된 결과를 보이는 경향이 있으므로 이러한 사용자는 A/B테스트 대상에서 제외해야 한다. (웹 스크레이퍼 또한 A/B테스트에 있어 아웃라이어와 마찬가지로 악영향을 줄 수 있으므로 이 역시 적절히 고려해야 한다.)