---
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.9
created_at: 2026-05-24
updated_at: 2026-05-24
review_reason: ""
merge_history: []
tags: ["research", "hypothesis-driven thinking", "experimentation", "data-driven"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["Source 292: Production Environment Feedback Loop", "Source 766: Pricing Strategy Experiment"]
github_commit: ""
---

# [[A/B Testing]]

## 🎯 한 줄 통찰 (One-line insight)
A/B 테스팅은 가설을 검증하기 위해 대조군과 실험군을 직접 비교하여 통계적 유의성에 기반한 최적의 의사결정을 도출하는 강력한 실증적 도구이다 [1, 2].

## 🧠 핵심 개념 (Core concepts)
- **대조군 및 실험군 비교 (Control vs. Treatment):** 전통적인 방식(A)과 새로운 변경 사항(B)을 별도의 사용자 그룹에 동시에 노출하여 결과를 측정한다 [1, 2].
- **통계적 유의성 (Statistical Significance):** 관찰된 결과가 우연이 아님을 보장하기 위해 충분한 표본 크기와 신뢰 수준(일반적으로 95%)을 확보해야 한다 [2, 3].
- **변수 격리 (Isolation of Variables):** 변화의 원인을 정확히 파악하기 위해 가급적 한 번에 하나의 변수만 테스트하는 것이 권장된다 [2, 4].
- **지표 기반 의사결정 (Metric-led Decisions):** 사전에 정의된 성공 임계치(Success Thresholds)와 선행/후행 지표를 기준으로 가설의 채택 여부를 결정한다 [5-7].

## 🧩 추출된 패턴 (Extracted patterns)
- **신속한 피드백 루프:** 실운영 환경에서 기존 시스템과 변경 사항을 병렬로 실행하고, 부정적 결과 시 자동 롤백(Rollback)하는 구조를 취한다 [8].
- **가설 기반 설계 (If/Then/Because):** 단순한 기능 구현이 아니라, 특정 변경이 사용자 행동에 미칠 영향을 구체적인 문장 형식으로 설계한 후 테스트를 수행한다 [9-11].
- **편향 완화 메커니즘:** 인간의 직관이나 계층적 의사결정(HiPPO) 대신 데이터 기반의 증거를 우선시하여 확증 편향 및 고정관념을 방지한다 [12-14].

## 📖 세부 내용 (Details)
- **목적 및 정의:** A/B 테스팅은 제품 변경이나 새로운 기능이 사용자 행동 또는 비즈니스 결과에 미치는 영향을 예측하는 가설을 검증하기 위한 실증적 방법론이다 [15, 16]. 이는 단순히 아이디어를 구현하는 것이 아니라, 가설을 테스트하여 학습하고 반복하는 과정의 핵심이다 [17, 18].
- **수행 조건:** A/B 테스팅은 위험이 큰 변경을 수행하기 전 높은 확신이 필요할 때, 행동 차이를 정량화할 수 있을 때, 그리고 통계적 유의성을 빠르게 확보할 수 있는 충분한 트래픽이 있을 때 적합하다 [2].
- **평가 지표 설정:** 
    - **선행 지표(Leading Indicators):** 가설이 맞을 수 있다는 초기 신호(예: 기능 클릭률, 초기 사용 시간) [5, 19].
    - **후행 지표(Lagging Indicators):** 장기적인 결과(예: 유지율, 전환율, 고객 생애 가치) [5, 19].
- **테스트 프로세스:** 
    1. 가설 수립 및 사용자 세그먼트 정의 [20, 21].
    2. 성공, 부분 성공, 실패를 판단할 임계치 설정 [6, 7].
    3. 대조군과 실험군에 대한 무작위 배정 및 실험 수행 [2, 22].
    4. 결과 분석 및 학습 내용 문서화 [23, 24].
- **주의사항:** 너무 많은 변수를 동시에 테스트하면 어떤 변화가 결과에 기여했는지 알 수 없게 된다 [4, 25]. 또한, 결과가 좋게 보일 때 실험을 조기에 중단하는 'p-hacking' 행위를 경계해야 한다 [25].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **트래픽 제약:** 통계적 유의성에 도달하는 데 수개월이 걸릴 정도로 트래픽이 적다면 A/B 테스팅은 적절한 방법론이 아니며, 이 경우 사용자 인터뷰나 프로토타입 테스트가 더 효과적이다 [2, 26].
- **정량적 데이터의 한계:** 수치는 '무엇'이 일어났는지는 보여주지만 '왜' 일어났는지는 설명하지 못하므로, 정성적 연구(사용자 인터뷰 등)와 병행해야 완전한 학습이 가능하다 [25, 27].
- **가설의 우선순위:** 모든 것을 테스트할 수는 없으므로 RICE 또는 WSJF와 같은 프레임워크를 사용하여 위험도가 높거나 임팩트가 큰 가설을 우선적으로 테스트해야 한다 [28, 29].

## 🛠️ 적용 사례 (Applied in summary)
- **가격 전략 실험:** 소규모 기업 사용자를 대상으로 월 49달러의 사용자당 요금제와 월 99달러의 정액제(최대 5인)를 A/B 테스트하여 전환율과 수익성을 비교 검증함 [22].
- **온보딩 최적화:** 신규 사용자의 이탈률을 줄이기 위해 가이드된 체크리스트나 툴팁을 도입한 버전과 기존 버전을 비교하여 유지율 변화를 측정함 [30-32].
- **실운영 피드백 루프:** 레거시 시스템 현대화 과정에서 코드 변경 사항을 운영 환경의 일부 사용자에게만 노출하여 성능 지표와 오류 여부를 모니터링함 [8].
- **편향 완화 도구:** 기업 의사결정에서 AI 증강 모델과 전통적 직관 기반 모델의 성과를 A/B 테스트로 비교하여 인지 편향의 감소 효과를 정량적으로 평가함 [1, 33].

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 비즈니스 케이스 및 방법론적 소스를 통해 개념적 타당성 확인)
- **출처 신뢰도:** B (기업 보고서, 컨설팅 방법론, 통계 및 가설 사고 전문 가이드를 기반으로 합성됨)
- **중복 검사 결과:** 신규 생성 (New discovery)

## 📝 변경 이력 (Change history)
- 2026-05-24: Initial draft generated via Datacollector_MAC P-Reinforce engine. 기초 가설 기반 사고(hypothesis-driven thinking)의 하위 실천 도구로 정립.