---
id: a/b-testing
title: "A/B Testing"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["Split Testing", "대조 실험"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.90
created_at: 2026-06-12
updated_at: 2026-06-12
review_reason: ""
merge_history: []
tags: ["research", "Assumption Validation Loop", "Experimentation"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["Amazon (Feature Placement Testing)", "Buffer (Demand/Pricing Validation)", "Microsoft/Netflix (Feature Performance Validation)"]
github_commit: ""
---

# [[A/B Testing]]

## 🎯 한 줄 통찰 (One-line insight)
A/B Testing은 직관이나 의견이 아닌 **실제 사용자 행동 데이터**를 기반으로 두 가지 이상의 대안을 비교하여 가설을 검증하고 리스크를 최소화하는 정량적 실험 도구이다. [1-3]

## 🧠 핵심 개념 (Core concepts)
1. **가설 기반 실험 (Hypothesis-Driven):** 모든 A/B 테스트는 "만약 X를 하면, Y 지표가 Z만큼 변할 것이다"라는 가설에서 시작하며, 이를 증명하거나 반증하기 위해 설계된다. [2, 4]
2. **변수 통제 및 격리 (Variable Isolation):** 신뢰할 수 있는 결과를 얻기 위해 한 번에 하나의 변수만 변경하여 결과의 인과관계를 명확히 한다. [3, 5]
3. **무작위 대조군 설정 (Control & Variant):** 사용자를 무작위로 대조군(A)과 실험군(B)으로 나누어 외부 요인을 차단하고 대안 간의 순수한 성능 차이를 측정한다. [3]
4. **행동 지표 중심 측정 (Behavioral Metrics):** 사용자의 주관적인 '말'이 아니라 클릭률(CTR), 전환율, 유지율 등 실제 '행동' 데이터를 통해 성공 여부를 판단한다. [6-8]

## 🧩 추출된 패턴 (Extracted patterns)
- **점진적 배포 패턴 (Staged Rollout):** [[Feature Flag]]를 사용하여 전체 사용자에게 리스크를 노출하지 않고 특정 세그먼트에서만 A/B 테스트를 진행하여 안정성을 확보한다. [2, 9, 10]
- **랜딩 페이지 스모크 테스트 (Landing Page Smoke Test):** 제품을 실제로 구축하기 전에 서로 다른 가치 제안(Value Proposition)이나 가격 책정을 담은 랜딩 페이지를 A/B 테스트하여 시장 수요를 먼저 확인한다. [5, 11, 12]
- **순차적 가설 검증 (Sequential Validation):** 수요 가설(랜딩 페이지 A/B) -> 가격 가설(가격 페이지 A/B) -> 기능 가설(기능별 A/B) 순으로 검증 단계를 높여가며 자원 낭비를 방지한다. [13, 14]

## 📖 세부 내용 (Details)
A/B Testing은 [[Assumption Validation Loop]]의 실행 단계에서 가장 강력한 정량적 검증 도구 중 하나로 활용된다. [2, 15]

- **실험 설계 및 실행:** 
  - 실험 전 반드시 **성공 지표(Success Metric)**와 **실패 기준(Fail Criteria)**을 사전에 정의해야 사후 확신 편향을 방지할 수 있다. [16-18]
  - 대조군(A)은 기존 상태를 유지하고, 실험군(B)에는 변경된 단일 변수를 적용하여 일정 기간 동안 데이터를 수집한다. [3]
  - 표본 크기가 충분하지 않은 초기 단계(50~200명 수준)에서는 통계적 유의미성 확보가 어려우므로 정성적 인터뷰와 병행하는 것이 권장된다. [19, 20]

- **검증 영역:** 
  - **수요 검증:** 랜딩 페이지의 메시지나 디자인을 달리하여 더 높은 가입률을 끌어내는 요소를 찾는다. [12, 21]
  - **가격 검증:** 서로 다른 가격 체계나 수익 모델(예: 사용량 기반 요금제)에 대한 고객의 결제 의사(Willingness to Pay)를 비교한다. [22-24]
  - **기능 가설 검증:** 특정 기능이 사용자에게 실제로 가치를 제공하는지, 혹은 제거했을 때 반발이 없는지를 확인하기 위해 사용된다. [5, 12]

- **도구 및 기술:**
  - 현대적 제품 개발팀은 AI 어시스턴트를 활용하여 정성적 리서치를 합성하거나 A/B 테스트 결과를 분석하여 학습 속도를 높인다. [25]
  - No-code 도구(Webflow, Zapier 등)를 사용하면 실제 코드를 작성하기 전에 고충실도(High-fidelity) 환경에서 A/B 테스트를 수행할 수 있어 엔지니어링 비용을 90%까지 절감할 수 있다. [26, 27]

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **통계적 유의미성의 함정:** 소스 데이터는 신생 스타트업이 완벽한 통계적 확실성을 얻기 위해 결정을 미루는 것을 "검증 함정(Validation Trap)"으로 경고한다. [20] 초기에는 완벽한 숫자보다 정성적 수렴과 빠른 학습 속도가 더 중요할 수 있다. [19, 28]
- **단순 A/B vs MVT:** A/B 테스트는 단일 변수 비교에 최적화되어 있으나, 복합적인 변수 간 상호작용을 확인해야 할 때는 다변량 테스트(Multi-variant Testing, MVT)가 필요하다는 점이 구분되어 명시된다. [3]

## 🛠️ 적용 사례 (Applied in summary)
- **Amazon:** 새로운 제품 카테고리 투자 전, 기존 사용자층을 대상으로 페이크 도어(Fake Door) A/B 테스트를 실시하여 클릭률이 높은 제품만 실제 재고를 확보함. [21, 29]
- **Buffer:** 랜딩 페이지와 가격 책정 페이지를 단계별로 A/B 테스트하여, 실제 제품 코드를 한 줄도 쓰기 전에 수요와 결제 의사를 모두 증명함. [14, 30, 31]
- **Microsoft, Netflix:** 배포되는 기능의 60~90%가 지표 개선에 실패한다는 데이터를 근거로, 거의 모든 신규 기능을 A/B 테스트를 거쳐 검증함. [32, 33]

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 적용 사례가 풍부하게 보고됨)
- **출처 신뢰도:** B (전문적인 제품 관리 및 린 스타트업 프레임워크 기반)
- **중복 검사 결과:** 신규 생성 (New discovery)


## 🔗 관련 문서 링크 (Related document links)

### 상위/유사 개념

#### [프레임워크 및 방법론]
- [[Assumption Validation Loop]]
  - 연결 이유: A/B Testing은 이 루프의 'Measure' 단계를 구성하는 핵심 엔진임. [15]
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 전체적인 리스크 완화 프로세스 내에서의 실험 위치.
- [[Riskiest Assumption Testing]] (RAT)
  - 연결 이유: 가장 위험한 가설을 가장 저렴하게 검증하는 방법으로 A/B 테스트가 자주 활용됨. [34, 35]
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: '최소 기능 제품' 구축 전 단계의 검증 전략.

#### [측정 및 분석]
- [[Conversion Rate]]
  - 연결 이유: A/B 테스트의 성공 여부를 판단하는 가장 대표적인 정량 지표임. [12, 30]
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 실험 결과의 객관적 해석 기준.

### 심층 후속 질문 (Deeper Research Questions)
- 초기 사용자가 극소수인 환경에서 A/B 테스트의 통계적 신뢰도를 확보하기 위한 최소 표본 크기는 어떻게 결정하는가? [19, 20, 36]
- [[Feature Flag]]를 활용한 A/B 테스트 환경 구축 시 시스템 복잡도와 기술 부채를 어떻게 관리하는가? [2, 37, 38]
- 정량적인 A/B 테스트 결과와 정성적인 사용자 인터뷰 결과가 상충될 때 의사결정 우선순위는 어떻게 설정하는가? [22, 39, 40]
- 다변량 테스트(MVT)와 단순 A/B 테스트의 선택 기준은 무엇이며, 각각의 비용 효율성은 어떻게 차이가 나는가? [3, 26]
- AI 기반 분석 도구가 A/B 테스트의 가설 설정 및 결과 해석 단계에서 편향을 제거하는 데 어떤 역할을 하는가? [25]

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** [[Feature Flag]] 시스템을 도입하여 코드 변경 없이 실험군/대조군 전환을 관리함. [2, 10]
- **System Design:** 실험 데이터를 실시간으로 수집하고 분석할 수 있는 데이터 파이프라인 및 대시보드 설계가 선행되어야 함. [9, 41]
- **Operation / Maintenance:** 실험 종료 후 실패한 대안의 코드를 즉시 제거하여 기술 부채가 쌓이지 않도록 운영 프로세스를 수립함. [37, 38]
- **Learning Path:** 린 스타트업 방법론을 익히고 가설 수립 -> 실험 설계 -> 지표 분석의 사이클을 반복 훈련함. [42-44]

### 인접 주변 주제
- [[Kano Model]]
  - 확장 방향: 어떤 기능을 A/B 테스트 대상으로 우선 선정할지 결정할 때 사용자 만족도 유형을 분류하는 데 도움을 줌. [45, 46]
- [[Jobs-to-be-Done]] (JTBD)
  - 확장 방향: A/B 테스트를 통해 검증하고자 하는 근본적인 사용자 동기와 목적을 정의하는 데 활용됨. [47-49]

## 📝 변경 이력 (Change history)
- 2026-06-12: Initial draft generated via Datacollector_MAC P-Reinforce engine. [Source Synthesis]