A/B 테스트 입문 — 대조군·전환율·유의성

이 글은 A/B 테스트 마스터 노트 시리즈의 첫 번째 편입니다. 한 페이지에서 버튼 색깔 하나가 매출에 수백만 달러 차이를 만들 수 있는 게 이커머스의 현실이에요. 그 차이를 감으로 잡지 않고 데이터로 증명하는 도구가 A/B 테스트입니다.

이 시리즈는 7편으로 A/B 테스트의 거의 모든 측면을 다룹니다. 1편은 가장 단단한 토대 — 대조군·변형·버케팅·전환율·통계적 유의성 다섯 단어를 손에 잡히게 만드는 게 목표예요. 이 다섯 개념이 잡혀야 2편 설계, 3편 시스템 구축이 자연스럽게 따라옵니다.

본문은 가상의 선글라스 쇼핑몰을 따라갑니다. 장바구니에 상품을 담을 때 슬라이드를 자동으로 띄우면 결제율이 어떻게 바뀔까 — 이 단순한 질문에서 시작해서 통계적 유의성·반복 개선까지 한 흐름으로 풀어 갑니다.

처음 A/B 테스트가 어렵게 느껴지는 이유

이유는 두 가지예요.

첫째, 단순해 보이는데 실제로 함정이 많습니다. "사용자 절반에게 A, 절반에게 B 보여주고 비교하면 끝 아닌가?" 라고 시작하지만, 곧 같은 사용자에게 매번 다른 그룹이 보이는 문제, 일찍 결과를 봤다가 우연을 진실로 착각하는 문제, 평균 주문 금액을 봤다가 한 명의 대형 주문에 휘둘리는 문제 — 이런 것들이 차례로 튀어나와요.

둘째, 통계 용어가 많습니다. 대조군·실험군·전환율·통계적 유의성·신뢰 수준·p-value — 비슷비슷한 단어들이 한꺼번에 들어와서 어느 게 어느 건지 혼란스럽습니다.

해결법은 한 가지예요. 모든 A/B 테스트 결정을 "법정"으로 비유하면 정리가 깔끔해집니다. 귀무가설(현재 상태) = 무죄 추정 / 새 변형 = 유죄 입증 시도. 검사(=데이터)가 합리적 의심을 넘는 증거(=통계적 유의성)를 제시할 때만 무죄 가정을 기각합니다. 이 비유 하나로 거의 모든 함정이 정리돼요.

대조군과 변형 — 두 그룹의 동시 실험

A/B 테스트는 정확히 두 가지 버전으로 시작합니다.

• 대조군 (Original / Control) — 현재 운영 중인 기존 버전
• 변형 (Variation / Treatment) — 검증하려는 새 버전

사용자는 무작위로 두 그룹 중 하나에 배정되고, 각 그룹의 행동 데이터를 모아 비교해요.

여기서 정말 중요한 시험 함정 — 두 그룹이 반드시 동시에(concurrently) 실험돼야 합니다. 순차적으로 한 주는 A만, 다음 주는 B만 보여주면 계절·프로모션·트래픽 변화 같은 외부 요인이 결과를 오염시켜요. 동시 실험만이 순수한 변수의 영향을 측정합니다.

코드로 보면 단순합니다.

// services/experiments.js — 가장 단순한 트래픽 분할
let variation = 'original'; // 기본값은 항상 original

function pickVariation() {
  // 50% 확률로 그룹 배정
  if (Math.random() < 0.5) {
    variation = 'show_cart';
  }
  // 어떤 그룹에 배정됐는지 추적 서버에 기록
  track('Bucket', [experimentName, variation]);
}

function getVariation() {
  return variation;
}

이 4줄짜리 모듈이 시리즈 전체의 토대예요. 7편까지 가면 이 한 함수가 점점 진화해 실험 플랫폼이 됩니다.

버케팅 — 한 사용자, 한 그룹의 원칙

버케팅(Bucketing) 은 사용자를 특정 테스트 그룹에 배정하는 과정입니다. 가장 중요한 원칙 한 줄 — 한 세션 안에서 같은 사용자는 항상 같은 그룹에 속해야 한다.

이게 안 지켜지면 어떤 일이 벌어지는지 코드로 보면 명확해요.

// 잘못된 방법 — 클릭할 때마다 그룹이 바뀜
function onAddToCartClick() {
  if (Math.random() < 0.5) {
    showModal(); // 매번 50% 확률로 모달 표시
  }
}

// 올바른 방법 — 앱 로드 시 한 번만 그룹 배정
useEffect(() => {
  pickVariation(); // 마운트 시 1회만 실행
}, []); // 빈 배열이 핵심

잘못된 방법이면 사용자가 같은 페이지에서 장바구니를 두 번 누를 때 첫 번째는 모달이 뜨고 두 번째는 안 뜨는 일관성 없는 경험을 합니다. 데이터도 같이 오염되고요.

여기서 시험 함정이 하나 있어요. 재방문 사용자도 같은 그룹에 들어가야 합니다. 단순히 메모리 변수로 그룹을 보관하면 새로고침하는 순간 초기화돼요. localStorage에 UUID를 저장해서 재방문 때도 같은 ID를 쓰는 패턴이 표준입니다.

function getUuid() {
  let uuid = window.localStorage.getItem('uuid');
  if (!uuid) {
    uuid = Math.random().toString(36).substring(2);
    window.localStorage.setItem('uuid', uuid);
  }
  return uuid;
}

UUID 한 번 생성되면 사용자가 같은 브라우저로 들어오는 한 같은 ID로 인식돼요.

전환율 — 절대 수치가 아니라 비율

전환율(Conversion Rate) 은 특정 목표 행동(구매·장바구니 추가·회원가입 등)을 완료한 사용자의 비율이에요.

$$\text{전환율} = \frac{\text{목표 달성 사용자 수}}{\text{전체 사용자 수}} \times 100%$$

예시로 풀어 봅니다.

• 대조군: 50명 중 5명 구매 → 전환율 10%
• 변형: 42명 중 8명 구매 → 전환율 19%

여기서 시험 함정이 하나 있어요. 절대 수치만 보면 오해합니다. 두 그룹 모두 17명이 구매했더라도 대조군이 49명 중 17명(34%)이고 변형이 42명 중 17명(40%)이라면 변형이 이긴 거예요. 항상 비율로 비교해야 합니다.

통계적 유의성 — 우연인지 진짜 차이인지

A/B 테스트의 가장 무거운 한 단어가 통계적 유의성(Statistical Significance) 이에요. 결과가 단순한 우연이 아니라 의미 있는 차이임을 수치로 증명하는 개념입니다.

동전 비유 — 직관 잡기

동전을 3번 던져서 앞면이 3번 나왔다고 해서 "이 동전은 앞면만 나오는 동전"이라고 말할 수는 없죠. 우연일 수 있어요. 1000번을 던져서 700번 앞이 나왔다면 그제서야 편향된 동전임을 의심합니다.

A/B 테스트도 똑같아요.

사례	결과	신뢰?
10명 중 7명이 변형 선택	비율 70%	신뢰 어려움
1000명 중 700명이 변형 선택	비율 70%	신뢰 가능

같은 70%여도 표본 크기가 작으면 우연일 확률이 큽니다.

신뢰 수준 — 우연일 확률을 뒤집은 숫자

신뢰 수준(Confidence Level) 은 통계적 유의성을 수치로 표현한 것이에요.

신뢰 수준	우연일 확률	해석
90%	10%	10번 중 1번은 틀릴 수 있음. 낮은 트래픽 사이트
95%	5%	표준. 대부분의 경우
99%	1%	핵심 기능 변경 시

100% 신뢰 수준은 통계적으로 불가능합니다. 항상 우연의 가능성은 남아 있어요.

세부 계산은 5편(통계 심화)에서 카이제곱 검정으로 풀어 갑니다. 1편에서는 일단 "신뢰 수준이 95%를 넘었을 때 의사결정 근거가 된다"는 한 줄만 잡고 가요.

가설 — 막연한 변경에서 검증 가능한 질문으로

좋은 A/B 테스트는 항상 명확한 가설에서 시작합니다. 가설은 "무엇을 왜 변경하면 어떤 결과가 나올 것이다"의 형태여야 해요.

나쁜 가설 vs 좋은 가설

나쁨: "버튼을 빨간색으로 바꾸면 더 좋을 것이다."

• 왜 좋아진다는 근거가 없음
• 어떤 지표를 개선하려는 건지 불명확

좋음: "장바구니 담기 버튼을 클릭했을 때 장바구니가 자동으로 슬라이드되어 나타나면(Trigger), 사용자가 결제 버튼을 더 빨리 발견할 수 있어(Mechanism) 전환율이 상승할 것이다(Expected Outcome)."

세 요소가 다 있어요 — 변경 사항 + 이유 + 측정 가능한 결과.

반복 실험 — 한 번으로 끝나지 않음

A/B 테스트의 진짜 가치는 반복 개선의 사이클에 있어요. 한 번 테스트해서 끝나는 게 아니라, 실패한 테스트에서 인사이트를 얻고 다음 테스트를 더 정교하게 설계합니다.

희소성(Scarcity) 전략의 진화를 따라가면 이게 잘 보여요.

차수	시도	결과	인사이트
1차	가격 아래 진행률 표시줄	변화 없음	진행률은 구매 동기 부여 못 함
2차	페이지에 실제 재고량 텍스트	변화 없음	숫자만으로는 긴박감 X
3차	사이즈 선택 시 "3개 남음"	소폭 성공	개인화 + 구매 직전 단계가 핵심
4차	카테고리에 "몇 개 남지 않음" 배너	대성공	탐색 단계에서 미리 노출 = 클릭 유도

세 번 실패하고 네 번째에 큰 성공이 나왔어요. 한 이커머스 회사에서 이 4차 실험으로 수백만 달러의 추가 연 매출을 만들어 낸 사례가 있습니다.

여기서 정말 중요한 시험 함정 — 실패한 테스트도 가치 있는 데이터입니다. 실패에서 "왜 안 됐을까"를 분석하면 다음 시도가 보여요. 실패를 숨기는 조직은 같은 실수를 반복합니다.

HiPPO 문제 — 가장 큰 목소리가 아니라 데이터로

A/B 테스트가 없는 환경에서는 의사결정이 종종 가장 큰 목소리를 가진 사람의 의견으로 결정돼요. 이걸 HiPPO(Highest Paid Person's Opinion) 문제라고 부릅니다.

실무에서 자주 만나는 풍경:

• 크리에이티브 팀: "재고 부족 배너는 못생겼어요. 브랜드 이미지를 해칩니다."
• 머천다이징 팀: "재고 부족을 광고하는 건 회사 약점을 노출하는 거예요."
• 이커머스 팀: "수백만 달러의 추가 매출을 무시할 수는 없죠."

데이터가 모든 의견 충돌의 중재자가 됩니다. "당신의 의견을 소중히 생각합니다. 하지만 데이터로 테스트해 봅시다" — 이 한 마디가 데이터 기반 문화의 핵심이에요.

ROI — 같은 트래픽에서 더 많은 수익

A/B 테스트가 비즈니스적으로 강력한 이유 — 광고비나 신규 고객 유치 없이 기존 트래픽에서 더 많은 수익을 짜내기 때문입니다.

ROI 계산 예시:
- 월 방문자: 100,000명
- 기존 전환율: 3%, 평균 주문 $50
- 기존 월 매출: 100,000 × 0.03 × $50 = $150,000

- 개선된 전환율: 3.1% (단 0.1%p 향상)
- 개선 후 월 매출: 100,000 × 0.031 × $50 = $155,000
- 월 추가 수익: $5,000
- 연간 추가 수익: $60,000

전환율 0.1%p 차이가 연 $60,000예요. 100배 큰 사이트에서는 같은 0.1%p가 연 600만 달러의 차이가 됩니다. 이커머스 기업이 A/B 테스트에 막대한 투자를 하는 이유.

인과관계 vs 상관관계 — 통계학의 가장 큰 함정

데이터에서 발견되는 패턴이 항상 인과를 의미하지는 않아요. 5편(통계 심화)에서 본격적으로 다루는데 1편에서 미리 짚어 두면 좋습니다.

이런 데이터를 봤다고 합시다.

• 이미지 2번 조회: 463명 중 12명 구매 (2.6%)
• 이미지 3번 조회: 19명 중 16명 구매 (84%)

이미지를 3번 본 사용자의 구매율이 폭발적으로 높아요.

질문: 이미지를 3번 봐서 구매한 건가(인과)? 아니면 이미 구매할 마음이 있어서 3번 본 건가(상관)?

이 질문에 답하는 유일한 방법은 A/B 테스트예요. 사용자가 이미지를 더 많이 보도록 강제로 유도하는 UI를 만들어서, 실제로 구매율이 오르는지 검증해야 합니다. 이걸 4편(실전 사례)의 갤러리 테스트에서 다뤄요.

안전한 폴백 — 항상 Original을 else에 배치

A/B 테스트 코드에서 가장 중요한 패턴이 있어요. 새 변형은 if에, 기존 동작은 else에 둔다.

// 잘못된 방법 — Original이 if에 있음
if (getVariation() === 'original') {
  // 기존 동작
} else {
  showNewModal(); // 새 변형
}

// 올바른 방법 — Original이 else에 있음
if (runExperiment('add_to_cart_modal')) {
  showNewModal(); // 새 변형
} else {
  // 기존 동작 (기본값, 폴백)
}

여기서 시험 함정이 하나 있어요. 두 코드가 같아 보이지만 결정적인 차이가 있어요. runExperiment가 어떤 이유로 null이나 undefined를 반환하면:

• 잘못된 방법 → 'original' === undefined → false → 새 변형 실행됨 (폴백 X)
• 올바른 방법 → falsy → 기존 동작 실행됨 (안전한 폴백)

실험 플랫폼 서버가 다운되거나, 타겟팅 조건이 안 맞거나, 그룹 배정이 실패해도 사용자는 항상 안전한 기존 경험을 봅니다. 7편(베스트 프랙티스)에서 더 깊이 다루는 핵심 패턴이에요.

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 1편의 핵심입니다. 시험 직전 또는 실무에서 헷갈릴 때 다시 펼쳐 볼 수 있게 압축 노트로 마무리할게요.

• A/B 테스트 = 두 버전 동시 비교 (순차 X — 외부 요인 오염)
• 대조군(Original) vs 변형(Variation) — 사용자 무작위 배정
• 버케팅 = 사용자를 그룹에 배정하는 과정
• 한 세션 안에서 같은 사용자는 같은 그룹 (필수)
• UUID를 localStorage에 저장해 재방문도 동일 그룹
• pickVariation()은 앱 로드 시 1회만 (useEffect의 빈 배열)
• 전환율 = 목표 달성 / 전체 × 100%
• 절대 수치 X, 비율 ◯ (50명 중 5명 vs 42명 중 8명)
• 통계적 유의성 = 결과가 우연이 아닐 확률
• 신뢰 수준 95% = 우연일 확률 5% (표준)
• 신뢰 수준 90% (낮은 트래픽), 99% (핵심 기능)
• 100% 신뢰는 통계적으로 불가능
• 좋은 가설 = 변경 + 이유 + 측정 가능한 결과
• 반복 개선이 핵심 — 한 번으로 끝 X
• 실패한 테스트도 데이터 (다음 시도 인사이트)
• HiPPO 문제 = 가장 큰 목소리 X, 데이터 ◯
• 0.1%p 전환율 차이도 연 수백만 달러 가능 (큰 사이트)
• 강한 상관 ≠ 인과 — A/B 테스트로만 검증
• 이미지 3번 본 사용자 84% 구매 = 상관일 수도 인과일 수도
• Original은 항상 else에 배치 (안전한 폴백 보장)
• runExperiment가 null이면 자동 폴백되도록 설계
• 실험 종료 후 코드 정리 (테스트 코드 남기지 X)

시리즈 다른 편

같은 시리즈의 다른 글들도 같은 톤으로 묶어 정리되어 있어요. 1편의 가설·전환율·유의성 감각이 다음 편 설계로 자연스럽게 이어집니다.

• 1편 — A/B 테스트 입문 (현재 글)
• 2편 — 테스트 설계 (가설·지표·편향 방지)
• 3편 — A/B 테스트 시스템 (Feature Flag·실험 플랫폼)
• 4편 — 실제 사례 분석 (5가지 패턴)
• 5편 — 통계 심화 (카이제곱·베이지안·다중 비교)
• 6편 — 구현 패턴 (React·Node·Pandas)
• 7편 — 베스트 프랙티스 (실험 문화·흔한 실수)

공식 문서: Optimizely A/B Testing Guide와 Google 실험 가이드에서 더 깊은 자료를 볼 수 있어요.

다음 글(2편)에서는 테스트 설계의 본격 — 가설 수립·지표 선택·타겟팅·트래픽 분할 전략을 풀어 갑니다. 1편에서 잡은 다섯 단어 위에 설계 기법이 그대로 올라가요.