A/B 테스트, 제대로 알고 쓰고 있나요? (2부) — 설계 기본기와 결과 분석

설계 기본기와 결과 분석

💡 이 글에서 다루는 내용 1부에서 개념을 다뤘다면, 이번엔 실험을 어떻게 설계하고 결과를 어떻게 해석하는지 다룹니다.

 

1. 좋은 실험은 가설에서 시작한다

"일단 돌려보자"는 실험은 나중에 해석할 기준이 없습니다. 좋은 A/B 테스트는 항상 명확한 가설에서 출발해야 합니다.

가설 템플릿 "[무엇을] 바꾸면, [어떤 지표]가 [어느 방향으로] 변할 것이다. 왜냐하면 [이유] 때문이다."

예시

추천 리스트의 개인화 강도를 높이면, 클릭률이 상승할 것이다. 왜냐하면 유저의 현재 관심사와 더 밀접한 아이템이 노출되기 때문이다.

⚠️ 가설 없이 실험하면, 여러 지표 중 우연히 좋아 보이는 것만 골라 "성공"이라 주장하는 오류(HARKing, p-hacking)에 빠지기 쉽습니다.

 

 

2. 지표는 두 종류로 나눠서 본다

구분 의미 예시

Primary Metric<br>(핵심 지표)	실험의 성패를 판단하는 단 하나(또는 소수)의 지표	구매전환율
Guardrail Metric<br>(가드레일 지표)	핵심 지표가 좋아져도 절대 나빠지면 안 되는 지표	레이턴시, 에러율, 크래시율, 재방문율

📌 클릭률(Primary)이 올라도 레이턴시(Guardrail)가 나빠졌다면 "성공"이라 부르기 애매합니다. 백엔드 개발자라면 시스템 성능 지표를 가드레일에 반드시 포함시켜야 합니다.

 

3. 무작위 배정, 어떤 단위로?

단위 특징

유저 단위 (user-level)	가장 흔함. 실험 기간 내내 같은 그룹 고정 → 경험 일관성 유지
세션 단위 (session-level)	방문할 때마다 그룹이 바뀔 수 있음
요청 단위 (request-level)	API 요청마다 배정. 인프라 실험에 주로 사용
아이템 단위 (item-level)	특정 상품·콘텐츠군에만 새 로직 적용

✅ 추천 시스템은 대부분 유저 단위가 기본입니다. 같은 유저가 어제는 A, 오늘은 B를 보면 경험이 혼란스럽고 지표 해석도 어려워집니다.

 

4. 트래픽은 얼마나, 얼마나 오래?

트래픽 분할 비율

• 50:50 → 통계적으로 가장 효율적 (최대 검정력)
• 90:10 / 95:5 → 리스크 큰 변경일 때 실험군 비중 축소
• 단계적 확대(Ramp-up) → 1% → 5% → 20% → 50% 순으로 점진 확대. 실무에서 가장 안전

실험 기간

표본 크기는 아래 요소로 결정됩니다.

• Baseline conversion rate (현재 지표 평균)
• MDE (감지하고 싶은 최소 효과 크기)
• 유의수준(보통 0.05), 검정력(보통 0.8)

⏱ 실무적으로는 최소 1~2주 유지 — 요일별 패턴(주중/주말 차이)을 반영하기 위함

 

5. 배정 방식과 SRM

해싱 기반(Hash-based) 배정이 가장 널리 쓰입니다. 유저 ID + 실험 ID를 조합해 계산한 값으로 그룹을 결정 → 같은 유저는 항상 같은 그룹, 서버가 늘어나도 일관성 유지.

추가로 유저를 신규/기존, 지역, 디바이스 등으로 먼저 나눈 뒤 그룹 내에서 무작위 배정하는 **계층화 샘플링(Stratified Sampling)**도 있습니다.

🚨 SRM (Sample Ratio Mismatch) 50:50으로 설계했는데 실제론 52:48로 배정됐다면? → 실험 신뢰도를 무너뜨리는 심각한 신호

흔한 원인: 봇 트래픽 편중, 그룹별 로깅 유실 차이, 캐싱 이슈, 배정 로직 버그

 

6. 결과 읽는 법: p-value와 신뢰구간

동전 던지기 비유

공정한 동전을 10번 던졌는데 앞면이 7번 나왔다면? "편향된 동전"이라 확신할 수 있을까요? 10번은 너무 적어서 우연일 수도 있습니다.

용어 의미

p-value	A와 B가 진짜 차이 없다고 가정할 때, 지금 본 차이가 우연히 나타날 확률. 0.05 미만 → "우연으로 보기엔 너무 극단적 → 진짜 차이 있음"
신뢰구간 (Confidence Interval)	"클릭률이 2%~8% 증가했다"처럼, 효과 크기 + 불확실성 범위를 함께 제공

✅ 실무에서는 p-value만 보지 말고 신뢰구간을 함께 보는 것을 권장합니다.

 

7. 결과 해석, 흔한 실수 3가지

1. 피킹 문제 (Peeking Problem) 실험 종료 전 매일 결과를 들여다보다 유의미해 보이는 순간 조기 종료 → 거짓 양성 확률 급증
2. 다중비교 문제 (Multiple Comparisons Problem) 지표 20개를 동시에 보면 우연히 1개는 "유의미하게" 보일 수 있음 → Primary Metric을 미리 하나로 고정
3. 표본 부족 상태에서 결론 내리기 "아직 유의하지 않다" ≠ "효과가 없다" — 표본 부족하면 판단 유보

 

8. 실험 종료 체크리스트

• [ ] 실험 전 표본 크기·최소 기간을 미리 계산해서 문서화했는가
• [ ] 기준 도달 전까지 중간 결과로 의사결정하지 않았는가
• [ ] Primary Metric의 유의성 + 신뢰구간을 확인했는가
• [ ] Guardrail Metric에 이상이 없는가
• [ ] 승자가 확인되면 → 점진적으로 100% 롤아웃
• [ ] 유의미한 차이가 없으면 → 가설 기각으로 기록하고 다음 가설로 (이것도 유효한 학습 결과!)

 

📌 2부 요약

• 실험은 가설에서 시작 → Primary/Guardrail Metric 구분 → 유저 단위 배정이 기본
• 트래픽은 Ramp-up으로 안전하게, 기간은 최소 1~2주
• SRM은 실험 신뢰도를 깨는 대표 신호
• p-value + 신뢰구간으로 결과를 해석하되, 피킹·다중비교 문제를 조심

다음 3부에서는 실무에서 자주 걸리는 함정들(네트워크 효과, 콜드스타트, 노벨티 효과)과 추천 시스템 외 활용 사례를 다룹니다.