| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
- docker
- redis
- COALESCE
- Spring
- codedeploy error
- codebuild
- codepipeline
- kubeflow
- chartjs
- Python
- Spring Error
- openlens
- node
- JavaScript
- bootstrap
- aws cicd
- PostgreSQL
- aws
- SQL
- 도커
- Airflow
- IntelliJ
- chart.js
- Kafka
- Flux
- VPN
- java bigdecimal
- codedeploy
- Jenkins
- AWS CI/CD 구축하기
- Today
- Total
Small Asteroid Blog
A/B 테스트, 제대로 알고 쓰고 있나요? (1부) — 개념과 목적 본문
💡 이 글에서 다루는 내용 A/B 테스트가 정확히 뭔지, 왜 굳이 해야 하는지를 개발자 관점에서 정리합니다.
1. A/B 테스트, 한 문장으로
떡볶이 가게를 상상해봅시다.
사장님이 새로운 소스 레시피(B)를 개발했는데, 기존 레시피(A)보다 더 잘 팔릴지 확신이 없습니다. 무작정 전체 메뉴를 B로 바꾸는 건 위험합니다. 손님들이 싫어하면 매출이 뚝 떨어지니까요.
그래서 이렇게 합니다.
- 홀수 번째 손님 → 기존 소스(A)
- 짝수 번째 손님 → 새 소스(B)
- 일주일간 각각 몇 그릇 팔렸는지, 재방문했는지 기록
- B가 확실히 더 잘 팔리면 → 그때 전체를 B로 교체
A/B 테스트 = 바꾸기 전에, 일부에게만 먼저 보여주고 숫자로 확인하는 것
IT 서비스에서는 이 "레시피"가 추천 알고리즘, 버튼 디자인, 가격 정책 등으로 바뀔 뿐 원리는 똑같습니다.
핵심 용어 두 가지
| 용어 | 의미 |
| A · Control (대조군) | 기존에 쓰던 방식. 비교의 기준점(baseline) |
| B · Treatment (실험군) | 새로 시도하는 방식. 여러 개일 수도 있음 (A/B/C/D) |
⚠️ 주의할 점 A와 B에 배정된 유저 집단은 통계적으로 비슷해야 합니다. A그룹엔 20대만, B그룹엔 40대만 있다면 — 결과 차이가 "모델 때문"인지 "나이대 때문"인지 구분할 수 없습니다. 그래서 **무작위 배정(randomization)**이 핵심 전제입니다.
2. 왜 추천 시스템에서 A/B 테스트가 필요할까
"이 모델이 정확도가 더 높으니까 당연히 더 좋은 거 아닌가요?"
실제로는 아닙니다. 이유는 세 가지입니다.
- 오프라인 지표 ≠ 실제 유저 반응 RMSE, NDCG가 좋아져도 클릭·구매 행동이 좋아진다는 보장은 없습니다. 모델이 학습한 과거 데이터와 실제 서비스 환경(실시간 맥락, UI 배치, 다른 추천과의 경쟁)은 다르기 때문입니다.
- "더 정교한" 추천이 오히려 역효과일 수 있음 유저에게 부담스럽거나, 너무 잘 아는 것 같아 오히려 불쾌할 수 있습니다.
- 원인 파악이 불가능해짐 감이나 오프라인 실험만 믿고 배포하면, 매출·리텐션에 미친 실제 영향을 알 수 없고, 문제가 생겨도 원인을 찾기 어렵습니다.
그래서 실제 트래픽 일부에게 노출시켜 진짜 비즈니스 지표(클릭률, 구매전환율, 체류시간)가 개선되는지 검증하는 게 A/B 테스트입니다.
3. "감"이 아니라 "데이터"로
시니어 개발자나 PM의 직관도 틀리는 경우가 많습니다.
📊 업계에 널리 알려진 경험칙 새로 제안된 기능 중 실제로 긍정적 효과를 낸 비율은 약 1/3 — 나머지 1/3은 효과 없음, 나머지 1/3은 오히려 악화
즉 "이렇게 바꾸면 당연히 좋아질 것"은 검증 전까지 가설일 뿐입니다. A/B 테스트는 이 가설을 객관적으로 검증하는 사실상 유일한 방법입니다.
4. 잘못된 배포를 막는 안전장치
새 모델을 전체 유저에게 한 번에 배포했다가 문제가 생기면?
- ❌ 매출 급감의 원인을 실시간으로 구분하기 어려움
- ❌ 롤백 전까지 모든 유저가 나쁜 경험을 함
- ❌ 장애 영향 범위(blast radius)를 통제 불가
A/B 테스트 = 리스크를 제한된 유저 집단에 가둬두는 안전장치
문제가 감지되면 즉시 롤백할 수 있죠. SRE의 "블라스트 레이디어스 최소화" 전략과 같은 원리입니다.
5. 우리가 매일 마주치는 A/B 테스트
| 서비스 | 실험 내용 |
| 🎬 넷플릭스 | 유저마다 다른 썸네일 노출 → 클릭 유도 이미지 탐색 |
| ▶️ 유튜브 | 홈 피드 추천 순서를 일부(1%)에 먼저 적용 → 시청 시간 변화 확인 |
| 🛒 커머스 | "함께 구매한 상품" 정렬 로직 변경 → 클릭률·전환율 비교 |
유저는 자신이 실험 대상인지 전혀 모른 채 서비스를 이용하고, 그 반응 데이터가 조용히 쌓입니다.
📌 1부 요약
- A/B 테스트 = 바꾸기 전에 일부에게 먼저 보여주고 숫자로 확인하는 것
- A(대조군) vs B(실험군), 무작위 배정이 핵심 전제
- "감"이 아니라 "데이터"로 검증해야 하는 이유 → 새 기능의 성공률은 생각보다 낮음(약 1/3)
- 리스크를 통제하는 안전장치 역할도 함
다음 2부에서는 실험을 어떻게 설계하는지, 결과를 어떻게 통계적으로 해석하는지(p-value, 신뢰구간 등)를 다룹니다.