AB 테스트의 현실: 비용과 실험의 딜레마

제가 과거 일했던 조직에서 2주일 단위로 고객 인터뷰를 진행하고, 여기서 얻은 인사이트를 기반으로 2주 단위로 AB 테스트를 계속 추가했습니다. 많을 때는 적은 규모의 스쿼드가 5-6개의 AB 테스트를 동시에 돌렸습니다. 이러한 접근은 빠르게 다양한 실험을 가능하게 했지만, 동시에 생각보다 많은 비용이 들었습니다.

많은 사람들이 AB 테스트를 통해 최적의 사용자 경험을 찾아내고자 합니다. 그러나 현실적으로 AB 테스트는 단순히 버튼 하나를 바꾸는 간단한 실험이 아닙니다. 여러 요소로 인해 비용이 크게 증가할 수 있습니다.

1. 첫째, AB 테스트는 본질적으로 실험의 영역에 속하므로 테스트 설계에도 비용이 발생합니다. 정확한 가설을 세우고, 실험군과 대조군을 적절히 나누며, 결과를 측정할 수 있는 지표를 정의하는 과정 준비도 비용입니다.

2. 둘째, AB 테스트(또는 A/B/n tests)를 위해 두 벌 이상의 개발이 필요합니다. 이는 단순히 기능을 만들고 끝나는 것이 아니라, 두 가지 이상의 버전을 구현해야 하므로 개발 비용이 추가로 소요된다는 것을 의미합니다. 또한, AB 테스트를 위한 배포/분석 인프라와 시스템을 준비해야 하므로 이 부분도 추가적으로 비용이 발생합니다.

3. 셋째, AB 테스트의 비용이 증가하는 또 다른 이유는 성공한 버전을 실제로 배포(delivery)할 때 발생하는 추가 작업입니다. 빠른 실험을 위해 일부 불완전한 디자인이나 코드를 사용하기도 하는데, 이를 정리하고 완성도 있는 상태로 만드는 작업 역시 추가적인 비용으로 이어집니다.

4. 또한 AB 테스트 배포 후에도 성공한 버전을 모니터링하기 위해 지속적인 리소스가 필요합니다. 단순히 결과를 보고 끝나는 것이 아니라, 실제 사용자가 느끼는 경험을 검증하고 문제가 없는지 실시간으로 체크해야 합니다. 또한, 점진적인 배포 체계를 병행해야 하는 경우도 많습니다. 모든 사용자에게 한 번에 변경 사항을 적용하기보다는 단계적으로 새로운 버전을 적용하면서 문제를 최소화해야 하기 때문에 추가적인 관리와 신중한 접근이 요구됩니다.

이렇듯 AB 테스트는 효과적인 제품 개선 도구인 동시에 많은 시간과 리소스를 필요로 하는 실험입니다. 따라서 이러한 테스트를 바로 진행하기보다는 그 이전 단계에서 충분히 실험할 수 있는 영역들을 탐색하는 것이 중요합니다. 무엇보다 AB 테스트 이전에 실험 대상을 잘못 선택하면 잘못된 최적화를 하게 됩니다.

이를 방지하기 위해서는 AB 테스트 이전에 실험 대상을 정하기 위한 검증 단계(validate stage)가 매우 중요합니다. 이 단계에서는 Assumption(가정)을 기반으로 검증이 이루어져야 합니다. Assumption은 제품이나 기능이 사용자에게 어떻게 가치를 제공할 것인지에 대한 가정으로, 이를 검증함으로써 어떤 요소가 실제로 테스트할 가치가 있는지 판단할 수 있습니다.

이후 AB 테스트 단계에서는 Hypothesis(가설)를 기반으로 실험이 설계됩니다. Hypothesis는 검증된 Assumption에 기초하여 특정 변경 사항이 사용자 경험이나 비즈니스 성과에 미칠 영향을 예측한 것입니다. 그리고 숫자로 성공 지표를 정의해야 합니다. 즉, Assumption 기반의 검증 단계를 통해 올바른 실험 대상을 선정해야만 AB 테스트가 의미 있는 결과를 도출할 수 있습니다.

AB 테스트의 안티 패턴 중 하나는 의견이 갈리는 경우 단순히 의견 대립의 답을 내기 위한 수단으로 AB 테스트를 활용하는 것입니다. 이는 AB 테스트의 목적을 왜곡하는 접근입니다. AB 테스트는 실험 이전에 충분히 evidence(근거)가 Assumption 기반으로 검증되고 나서 진행해야 합니다. 그렇지 않으면 실험 자체가 의미 없거나 잘못된 방향으로 이어질 가능성이 큽니다.

AB 테스트와 같은 실험을 수행하기 전에 충분한 발견 과정이 이루어져야 합니다. 이는 고객의 문제를 깊이 이해하고, 다양한 해결책을 탐색하는 과정을 의미합니다. 지속적인 발견은 팀이 올바른 문제를 해결하고 있는지 확인하는 데 도움을 주며, Assumption을 명확하게 검증하고 가설을 세우는 데 있어 중요한 역할을 합니다. 이를 위해 팀이 사용자와 지속적으로 대화하고, 정성적 데이터와 정량적 데이터를 조합하여 인사이트를 도출해야 합니다. 이러한 접근은 결국 AB 테스트가 더 의미 있는 결과를 가져오도록 하며, 단순히 의견 대립을 해결하기 위한 도구로 사용되는 것을 방지합니다.

Itamar Gilad는 AB 테스트를 일종의 실험 영역으로 정의하고, 실험 영역 이전에 테스트 영역으로 다양한 아이디어 검증 방법을 제안합니다. 그리고 아래 방법들을 통해 ICE 스코어(Impact, Confidence, Ease)를 지속적으로 업데이트하면서 아이디어를 교차 비교합니다. 핵심은 아이디어가 evidence 기반으로 팀이 확신(confidence)를 갖추는 것입니다. 다음과 같은 방법들이 있습니다: 

1. 목표 정렬(Goals Alignment): 실험을 통해 무엇을 달성하려는지 명확히 정의합니다. 목표가 명확해야만 올바른 가설과 실험 설계가 가능합니다. 

2. 데이터 분석(Data Analysis): 기존 데이터를 분석하여 문제 영역을 파악하고 가설을 세우는 데 활용합니다. 

3. 가설 매핑(Assumption Mapping): 주요 가정을 명확히 정의하고, 이 가정이 검증될 때 필요한 조건들을 명확히 합니다. 

4. 연구 조사(Surveys, Field Research): 설문조사나 현장 조사를 통해 초기 가정을 검증하고 사용자 니즈를 파악합니다. 

5. 사용자 인터뷰(User Interviews): 사용자 인터뷰를 통해 정성적인 데이터를 수집하고, 사용자의 문제와 기대를 이해합니다. 

6. 위자드 오브 오즈(Wizard of Oz): 실제로는 수동으로 처리되는 기능을 자동화된 것처럼 보여주어 사용자 반응을 테스트하는 방법입니다. 

7. 사용성 테스트(Usability Tests): 사용자가 제품을 사용하는 모습을 관찰하여 사용성 문제를 발견하고 개선합니다.

8. 도그푸드(Dogfood): 자사 직원들이 제품을 직접 사용하면서 문제를 발견하고 개선점을 제안합니다. 

9. 실험군 테스트(Longitudinal User Study): 장기간에 걸쳐 사용자의 행동 변화를 관찰하고, 시간에 따른 사용 패턴을 파악합니다. 

이러한 방법들을 통해 AB 테스트 이전 단계에서 충분히 가설을 검증하고, 필요한 경우에만 AB 테스트를 진행하는 접근이 필요합니다. 이러한 사전 작업을 통해 AB 테스트가 실질적으로 유의미한 결과를 제공할 수 있도록 도울 수 있습니다.

AB 테스트는 분명 제품을 개선하는 데 큰 도움이 되지만, 그 비용과 리소스를 고려할 때 신중한 접근이 필요합니다. 초기 단계에서의 다양한 가설 검증과 실험을 통해 진정으로 가치 있는 AB 테스트를 진행할 수 있는 준비를 갖추는 것이 중요합니다.