스포티파이가 베이지안 A/B 테스트를 도입하지 않은 진짜 이유

"베이지안이 요즘 대세라던데, 우리도 갈아타야 하나?"

실험 플랫폼 회의에서 한 번쯤 나오는 질문이에요. GrowthBook, LaunchDarkly, PostHog, Amplitude, Optimizely, VWO, Statsig, Eppo… 이름만 들어도 아는 상용 실험 플랫폼들이 너도나도 베이지안 모드를 추가했죠. 마케팅 문구도 비슷해요. "모던하고, 유연하고, frequentist 통계보다 해석이 쉽다." 심지어 "multiple testing, sequential testing 같은 frequentist의 골칫거리가 베이지안 사고방식에선 자연스럽게 해결된다"는 주장까지 따라붙어요.

이 글은 그 주장을 정면으로 반박한 스포티파이 엔지니어링 블로그의 내용을 정리한 거예요. 결론부터 말하면, 베이지안 A/B 테스트에는 '과도한 단순화'라는 테마가 깔려 있고, 그게 frequentist의 peeking만큼 나쁜 추론 관행으로 이어진다는 겁니다. 실제로 스포티파이는 자사 논문에서 베이지안과 frequentist 프레임워크가 논쟁이 시사하는 것보다 훨씬 가깝다는 걸 확인했어요.

근거자료: Why Spotify Is Not Using Bayesian A/B Testing

이 글에서 다룰 4가지 포인트는 이래요.

1. 베이지안 A/B 테스트에 대한 흔한 주장 4개를 뜯어보고, 언제 성립하는지 확인
2. 베이지안 설정을 '보장 수준'에 따라 tier로 분류
3. 베이지안 decision-theoretic 공식이 frequentist 공식으로 번역되는 지점
4. 그래서 스포티파이가 왜 두 모드를 다 지원하지 않는지

우리나라 실무 환경에서도 SI든 자체 서비스든 "실험 플랫폼 뭘로 갈까"는 진짜 자주 나오는 논쟁이에요. 이 글 하나면 그 논쟁에서 최소한 헛소리는 안 하게 됩니다 😅

베이지안 A/B 테스트는 '하나'가 아니라 '설정의 가족'이다

가장 먼저 짚어야 할 부분이에요. 많은 분들이 "베이지안 = 하나의 방법론"이라고 생각하는데, 그게 아니에요. 베이지안 A/B 테스트는 stopping rule + prior + likelihood 세 가지로 정의되는 configuration의 가족입니다.

그래서 회사가 먼저 물어야 할 질문은 "베이지안 쓸까?"가 아니라 "우리 실험 프로그램의 목표가 뭐지?"예요.

• 효과 없는 기능을 출시하는 비율을 제한하고 싶다
• 임팩트를 특정 정밀도로 추정하고 싶다
• 특정 cost function을 시간에 따라 최소화하고 싶다

목표가 정해지면 그다음에 configuration이 결정돼요. 여기서 온라인 담론이 혼란스러운 이유가 나옵니다. 목표와 configuration을 슬쩍 섞어버리거든요.

예를 들어 이런 문장들이 있어요.

이게 왜 중요하냐면, 대부분의 상용 플랫폼 기본값이 flat prior + posterior probability threshold라는 점 때문이에요. 이 조합은 수치적으로 frequentist peeking과 동일한 false positive rate를 재현합니다. 즉, "베이지안으로 갔더니 모던해졌다"는 착각만 생기고 실제 통계적 보장은 그대로인 거죠.

자주 나오는 오해 하나: Likelihood Principle

"posterior는 언제 데이터 수집을 멈췄든 유효한 belief update다" — 이건 Likelihood Principle에 따라 맞는 말이에요. 하지만 이건 아주 좁은 보장이에요. Error-rate control, estimation precision, decision-theoretic performance는 전부 prior와 stopping rule에 달려 있어요. Posterior가 coherent하다는 것만으로는 나머지 보장이 하나도 안 따라옵니다.

정확한 표현은 이거예요:

"나는 멈출 때 posterior가 유효하기만 하면 된다. Likelihood Principle이 그걸 준다."

이건 목표를 명시한 문장이에요. "베이지안이라서"라는 문장이 아니라요.

스포티파이가 실제로 뭘 따져봤는지

1. Winner's curse: flat prior면 아무것도 안 고쳐진다

가장 문제가 적은 주장이에요. Informative prior는 효과 추정치를 prior mean 쪽으로 shrink시키니까 winner's curse에 대항하는 건 맞아요. 그런데 대부분 팀이 쓰는 건 플랫폼 기본값인 flat prior예요. Flat prior는 shrinkage를 전혀 안 하고, posterior mean이 MLE와 같아요. 결과적으로 winner's curse는 frequentist와 똑같이 심해요.

더 재밌는 건, 스포티파이 시뮬레이션에서 잘못 보정된 prior는 아무 prior도 안 쓴 것보다 나빴다는 점이에요. 특히 두 가지 실패 모드가 치명적이었어요.

• 이미 이긴 실험만 아카이브에 넣은 경우
• 서로 다른 프로그램을 pooling한 경우

둘 다 추정 정확도를 떨어뜨렸어요. 심지어 oracle historical prior(프로그램에 이론적으로 최적인 prior)를 써도 GST(Group Sequential Testing) 대비 power 이득은 없었어요.

2. Empirical Bayes prior: 이론은 아름답지만 유지비가 폭탄이다

진짜로 frequentist가 깔끔하게 재현 못 하는 이득을 주는 조합은 Bayes factor stopping + 잘 보정된 empirical Bayes prior예요. 이건 FDR 자동 제어와 shrinkage를 동시에 줘요. 이론적으로 훌륭합니다.

문제는 '잘 보정된'이라는 조건이 생각보다 훨씬 빡세다는 거예요.

• Corpus가 커야 함 (때로 200개 이상 실험)
• 대표성이 있어야 함
• Metric마다 effect distribution이 다르면 pooling하면 안 됨 (예: sign-up rate vs recommendation CTR)
• 새 metric 만들 때마다 과거 실험 backfill 필요
• Exchangeability 가정이 시간에 따라 깨질 수 있음 (diminishing returns, 세상이 계속 변함)

조직에 성숙한 프로그램 하나, 일관된 metric 정의, prior를 유지하는 통계 전문가가 있으면 empirical Bayes로 진짜 가치를 뽑을 수 있어요. 하지만 대부분 조직에서는 prior 유지 비용이 이득을 초과합니다.

3. Decision theory는 결국 error-rate control과 만난다

"우리는 decision-theoretic 접근을 하고 싶어서 베이지안이 필요하다"는 주장도 있어요. 그런데 흥미로운 수렴이 있어요. False positive, false negative, sampling cost를 합산하는 자연스러운 cost function의 경우, 최적 또는 준최적 정책이 Bayes factor threshold를 씁니다. 그리고 그 threshold는 error-rate 보장도 같이 줘요. 결과적으로 decision-theoretic 공식과 error-rate 공식은 같은 configuration의 두 parametrization이 돼요.

주의할 예외도 있어요. Stucchio가 설명한 expected-loss stopping은 posterior가 충분히 tight해지면 발동하는데, 효과가 전혀 없어도 결국 새 variant를 ship해요. Flat prior면 false positive rate가 약 50%입니다. 만약 null-effect variant 배포가 진짜로 costless라면 이게 최적이지만, cost가 실제 효과의 몇 %만 넘어가도 최적이 아니게 돼요.

4. 한국 개발 생태계에서의 적용 맥락

국내 환경에서는 이 논의가 좀 다르게 적용돼요. 대부분의 국내 팀은 스포티파이처럼 성숙한 실험 프로그램을 운영하지 않아요. 오히려 "실험 플랫폼을 처음 도입하는 단계"가 많죠. 이 단계에서 베이지안 모드를 고르면 두 가지 함정에 빠지기 쉬워요.

• 해석이 쉽다는 이유로 베이지안을 선택 → flat prior 기본값 → 사실상 frequentist peeking과 동일한 결과인데 "모던하다"는 착각
• 두 모드 다 지원 → 실험 설계, 모니터링, 해석, 결과 리포트가 다 달라져서 조직 내 커뮤니케이션 비용 폭증

특히 여러 팀이 하나의 실험 결과를 소비하는 조직 구조에서는 모드가 하나여야 결과 해석이 일관됩니다. 이건 통계 문제가 아니라 조직 설계 문제예요.

그래서 스포티파이는 어떻게 결정했나

스포티파이의 실험 프로그램 목표는 명확해요.

• 나쁜 비즈니스 결정으로 이어지는 실험 수를 최소화 (제품을 해치는 변경 ship 방지, UX를 개선하지 않는 변경의 ship·유지 방지)
• 실험 증거를 신뢰할 수 있어야 함
• 결과를 잘못 해석하기 어려워야 함 (특히 팀·부서를 넘나들 때)
• 실험은 계획·설정이 쉬워야 하지만, 잘못 설정하기는 어려워야 함

여기서 두 모드를 지원하는 비용이 이득을 넘어선다고 판단했어요. 다만 예외는 인정했죠. 잘 보정된 empirical Bayes prior + Bayes factor stopping은 진짜 이득을 주지만, 모든 metric과 program에 대해 prior 품질을 유지하는 건 대부분 조직에 현실적이지 않아요. 잘못된 prior는 결정을 망치고 신뢰를 떨어뜨려요.

이 기술의 한계와 주의사항

• "베이지안"이라는 단어 자체가 마케팅이 됐어요. 실제로는 configuration의 문제인데, 프레임워크 이름으로 논쟁하는 순간 논의가 산으로 갑니다.
• Flat prior + posterior threshold 기본값은 frequentist peeking과 수치적으로 동일해요. 이걸 모르고 "베이지안이라서 안전하다"고 믿으면 그냥 자기기만이에요.
• Empirical Bayes prior는 유지보수 대상이에요. 한 번 잘 만들어도 exchangeability 가정이 깨지면 조용히 망가집니다. 드리프트 감지 없이는 위험해요.
• Likelihood Principle은 좁은 보장이에요. Posterior가 coherent하다는 게 error-rate control, precision, decision-theoretic optimality를 주지 않아요.

다음 단계 학습 방향

1. Sequential testing 기본기 — GST(Group Sequential Testing), mSPRT(Mixture Sequential Probability Ratio Test)를 먼저 이해하세요. 이게 있어야 베이지안 configuration의 보장이 어디서 오는지 보여요.
2. Empirical Bayes 실전 — Efron의 『Large-Scale Inference』와 스포티파이 원 논문을 같이 읽으면 prior 보정의 실패 모드가 눈에 들어옵니다.
3. Decision theory for A/B testing — Stucchio의 expected-loss stopping 논의를 읽어보세요. Cost function이 optimal policy를 어떻게 결정하는지 감이 잡혀요.
4. 자기 조직의 목표부터 정의 — 도구보다 목표가 먼저예요. "우리는 어떤 보장이 필요한가?"에 답할 수 있어야 configuration을 고를 수 있어요.

함께 보면 좋은 글

• 메타가 수년간 유지하던 FFmpeg 포크를 버린 이유 — 대규모 미디어 처리의 통찰
• Claude Opus 4.6, Microsoft Foundry에 정식 출시 — 코딩과 에이전트 워크플로우의 새로운 기준

결론은 이거예요. 프레임워크 논쟁에 시간 쓰지 말고, 실험 프로그램의 목표와 보장 수준을 먼저 정의하세요. 그다음에 "우리가 이미 가진 것보다 특정 베이지안 configuration이 의미 있게 나은가?"를 물어보세요. 스포티파이의 오늘 답은 '아니오'였습니다.