들어가며: 모두가 베이지안을 외칠 때, Spotify는 왜 멈췄을까

최근 몇 년 사이 GrowthBook, LaunchDarkly, PostHog, Amplitude, Optimizely, VWO, Statsig, Eppo 같은 상용 실험 플랫폼들이 앞다투어 베이지안 모드를 추가했어요. 마케팅 메시지는 대동소이합니다.

  • "베이지안은 모던하고 유연하다"
  • "빈도주의보다 해석이 쉽다"
  • "다중 검정, 순차 검정 같은 빈도주의의 복잡함이 자연스럽게 해소된다"

그런데 Spotify 엔지니어링 팀은 정반대 결론을 냈습니다. **"지금은 베이지안을 붙일 필요가 없다"**는 거죠.

이 글은 Spotify가 공개한 분석 자료를 바탕으로, 왜 이런 결정을 내렸는지, 그리고 여러분의 팀이 베이지안을 도입할 때 무엇을 먼저 따져야 하는지를 정리합니다. 근거자료는 Spotify Engineering 블로그에서 확인할 수 있어요.

핵심 요약: 베이지안 A/B 테스트는 '하나의 기법'이 아니라 '설정들의 집합'입니다. 이걸 하나로 뭉뚱그려서 논하는 순간 논의가 망가져요.

Data analyst comparing Bayesian and frequentist A/B testing statistics on dual monitors Coding Session Visual

베이지안 A/B 테스트의 실체: 설정의 집합이다

베이지안 A/B 테스트는 정지 규칙(stopping rule) + 사전분포(prior) + 우도(likelihood) 세 가지로 정의되는 설정군입니다. 즉, "베이지안이냐 빈도주의냐"가 아니라 **"어떤 목표를 위해 어떤 설정을 고르느냐"**가 진짜 질문이에요.

실험 프로그램의 목표는 보통 이런 식입니다.

  • 효과 없는 기능을 출시하는 비율을 줄이고 싶다
  • 효과 크기를 일정 정밀도로 추정하고 싶다
  • 특정 비용 함수를 시간에 따라 최소화하고 싶다

목표가 다르면 최적 설정도 달라집니다. 그런데 온라인 담론에서는 이 둘을 섞어버려서, 비전문가들은 "베이즈는 만능"이라는 환상을 갖게 되죠.

흔한 주장 4가지, 조건을 붙여서 다시 쓰면

1) "베이지안은 peeking 보정이 필요 없다"

이 말은 두 가지로 갈립니다.

  • (목표) peeking 하의 false positive rate(FPR)를 신경 안 쓴다
  • (설정) Bayes factor stopping을 써서 자동으로 FPR이 통제된다

이 둘은 완전히 다른 주장이에요. 그런데 대부분 이걸 "베이즈의 속성"으로 뭉갭니다. 실제로 Bayes factor stopping은 martingale 성질 덕분에 peeking 하에서도 FPR이 통제돼요. 다만 이 설정을 제공하는 플랫폼은 거의 없습니다. 대부분의 플랫폼 기본값은 flat prior + posterior probability threshold인데, 이건 빈도주의 peeking과 동일한 FPR을 재현해요.

2) "베이지안은 다중 지표를 자동 처리한다"

이 주장이 숨기는 건 두 가지예요.

  • 통제되는 건 FPR이 아니라 FDR(False Discovery Rate)
  • 그걸 얻으려면 잘 보정된 Empirical Bayes prior + Bayes factor stopping이 필요

사전분포에 point-mass 컴포넌트(historical null 비율)를 넣어야 다중성 보정이 흡수돼요. 즉 "보정이 없다"가 아니라 **"매우 정교한 보정이 사전분포 안에 숨어 있다"**는 겁니다. 사전분포가 잘못 보정되면 FPR은 그냥 통제 안 됩니다.

3) "베이즈가 winner's curse를 고친다"

가장 덜 문제적인 주장이에요. 정보가 있는 사전분포는 추정치를 prior mean 쪽으로 shrink시켜서 winner's curse를 완화합니다. 문제는 대부분 팀이 flat prior(플랫폼 기본값)를 쓴다는 거예요. Flat prior는 shrinkage가 0이라 posterior mean = MLE, 즉 빈도주의와 똑같이 winner's curse에 노출됩니다.

시뮬레이션 결과, 잘 보정된 historical prior가 가장 낮은 추정 오차를 보였어요. 반대로 잘못 지정된 사전분포는 baseline GST보다 오히려 더 나빴습니다. 특히 실패 모드 두 가지:

  • 승리한 실험만 아카이브에 넣은 경우
  • 서로 다른 프로그램을 풀링한 경우

둘 다 추정 정확도를 떨어뜨렸어요.

4) "Decision theory를 쓰려면 베이즈가 필요하다"

의사결정론은 비용 함수를 지정하게 해주는데, A/B 테스트에서 최적 정책은 Bayes rule이 됩니다. 단순한 비용 함수(FN + FP + 샘플링 비용)에 대해 최적 정책은 Bayes factor threshold이고, 이건 동시에 error-rate 보장도 줘요. 즉 의사결정론과 error-rate 제어는 같은 설정의 두 파라미터화가 되는 경우가 많습니다.

예외는 instructive합니다. Stucchio가 설명한 expected-loss stopping은 posterior가 충분히 tight해지면 무조건 ship해요. Flat prior에서 FPR이 약 50%인데, 만약 null-effect 배포가 진짜 비용 0이라면 이게 최적이에요. 하지만 비용이 실제 효과 크기의 몇 %만 넘어도 더 이상 최적이 아닙니다.

Developer reviewing Bayesian inference posterior probability charts for experimentation platform Development Concept Image

베이즈와 빈도주의는 생각보다 훨씬 가깝다

실무에서 가장 많이 쓰이는 설정 기준으로 보면, 베이지안과 빈도주의는 논쟁이 시사하는 것보다 훨씬 유사해요.

Flat prior + two-group normal 모델에서 수치적으로 동일

베이지안빈도주의
Posterior meanMaximum Likelihood Estimate
P(B > A | data)1 − p-value
95% posterior probability thresholdOne-sided rejection region

Flat prior 쓰면서 posterior probability threshold로 결정 내리는 실험자는 용어만 다를 뿐 빈도주의 추론을 하고 있는 겁니다.

더 깊은 연결: mSPRT = Bayes factor stopping

  • Mixture SPRT(빈도주의 순차 검정의 대표주자)는 동일 prior 하의 Bayes factor stopping과 정확히 일치
  • 빈도주의자가 MDE에서 power를 최대화하려고 mixing distribution을 고르는 건, 베이지안 관점에서 treatment effect에 prior를 놓는 것과 같아요. mixing distribution이 곧 prior입니다.
  • mSPRT는 GST(Group Sequential Testing)로 잘 근사됩니다.

결국 많은 자연스러운 비용 함수의 최적 결정 규칙은 Bayes factor threshold → 그건 mSPRT → mSPRT는 GST로 근사. 두 프레임워크는 대립이 아니라 보장이 겹치는 영역이 매우 큽니다.

해석이 정말 더 좋은가?

"효과가 0.2%~1.1% 사이에 있을 확률이 95%"라는 표현이 "95% 신뢰구간"을 설명하는 것보다 자연스러운 건 맞아요. 하지만 flat prior 하에서는 모든 확률적 진술이 빈도주의량과 1:1 대응합니다. 점추정·구간도 같고, P(B>A) = 1 − p-value예요.

확률적 해석이 진짜 달라지는 건 좋은 사전분포가 있을 때뿐인데, 좋은 prior는 공짜가 아니에요. 지정·정당화·유지보수·설명 비용이 붙습니다. 해석은 얻지만 다른 종류의 복잡도를 지불하는 거죠.

Empirical Bayes, 실제로 구현하기 얼마나 어려운가

앞의 두 섹션이 공통으로 가리키는 지점: Bayes factor stopping + 잘 보정된 Empirical Bayes prior는 빈도주의가 깔끔하게 재현 못 하는 진짜 이점을 줘요. 문제는 그 prior를 충분한 품질로 추정하는 게 어렵다는 것.

  • 코퍼스가 커야 함 (때로 200개 이상 실험)
  • 대표성이 있어야 함
  • 이질적 프로그램/지표를 풀링하면 안 됨

예시를 들어볼게요. 어떤 프로그램이 sign-up rate와 recommendation CTR을 추적한다고 해봐요.

  • Sign-up: 대부분 실험에서 거의 안 움직임
  • CTR: 쉽게 움직임

둘을 한 코퍼스에 풀링하면 prior variance가 sign-up에겐 너무 넓고, CTR에겐 너무 좁아요. null-rate 추정도 틀려요. 결과적으로 어느 지표도 실제로 따르지 않는 분포에 보정된 prior가 나옵니다. 지표별로 prior를 따로 추정할 수도 있지만, 새 지표가 생길 때마다 과거 실험을 backfill해야 하죠.

게다가 프로그램 내에서도 시간이 지나면 효과 분포가 변해요(수확 체감, 세상이 변함). 과거 실험이 미래 실험에 대해 대표성을 갖는지 판단하는 것 자체가 어렵습니다.

결론: 성숙한 단일 프로그램 + 일관된 지표 정의 + 통계 전문가가 prior를 유지하는 조직은 Empirical Bayes로 실질적 가치를 얻을 수 있어요. 하지만 대부분 조직에서는 prior 유지보수 복잡도가 이점을 상쇄합니다.

이 기술의 한계와 주의사항

  • "베이지안"이라는 라벨에 속지 마세요. 플랫폼 기본값 대부분은 flat prior + posterior threshold로, 빈도주의 peeking과 동일한 FPR을 냅니다.
  • FDR 통제 주장은 조건부입니다. 잘 보정된 empirical prior가 없으면 그냥 안 됩니다.
  • 사전분포는 유지보수 대상입니다. 한 번 만들고 끝이 아니라, 드리프트·풀링 오류·승리 편향을 지속 감시해야 해요.
  • 해석의 편의는 complexity trade-off입니다. "이해하기 쉬움"은 공짜가 아니에요.

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

국내 환경에서는 특히 두 가지가 걸립니다.

  1. 실험 볼륨이 부족한 팀이 많아요. Empirical Bayes prior를 만들 만한 코퍼스(200+ 실험)가 안 되는 조직이 대부분입니다. 이 경우 베이지안 모드를 켜도 이점은 거의 없고, 오히려 flat prior의 함정만 떠안게 돼요.
  2. 그로스 조직과 데이터 조직의 역할 분리가 명확하지 않은 경우가 많아요. Spotify는 통계 전문가가 prior를 유지하는 전제를 명시하는데, 국내 스타트업/중견에서는 그 역할을 누가 맡을지부터 정해야 합니다.

실무적으로는 **"알파/파워를 비용 함수 관점에서 정하고, GST 기반으로 운영"**하는 것만으로도 대부분의 가치를 얻을 수 있어요. 프레임워크 교체 없이요.

다음 단계 학습 방향

  • Sequential testing: GST, mSPRT, always-valid inference의 관계
  • Multiple testing: FDR vs FWER, Benjamini-Hochberg, 사전분포 기반 FDR 제어
  • Decision theory for A/B testing: 비용 함수 설계, expected-loss stopping의 함정
  • Empirical Bayes: James-Stein shrinkage, hierarchical modeling, prior calibration 진단

Engineer configuring A/B testing infrastructure with empirical Bayes prior on server dashboard Technical Structure Concept

그래서 Spotify는 왜 베이지안을 안 붙였나

Spotify의 실험 프로그램 목표를 다시 봅시다.

  1. 비즈니스 결정을 해치는 실험 수를 최소화 (제품을 해치는 변경, 개선 없는 변경 ship 방지)
  2. 실험 증거를 신뢰할 수 있어야 함
  3. 결과를 잘못 해석하기 어려워야 함 (특히 팀·부서 간 협업에서)
  4. 계획·설정은 쉬워야 하지만 잘못 설정하기는 어려워야 함

Spotify는 실험 설계와 결과 소비에서 회사 전체가 상시 협업합니다. 이 상황에서 두 모드를 지원하면 계획·모니터링·해석·출력이 전부 달라져요. 두 번째 프레임워크의 이점이 그 비용을 넘지 못한다는 게 그들의 결론입니다.

예외는 인정합니다. 잘 보정된 Empirical Bayes prior + Bayes factor stopping은 진짜 이점이 있어요(shrinkage + 자동 FDR 통제). 하지만 모든 지표·프로그램에 대해 충분한 품질로 prior를 유지해야 하고, 잘못되면 오히려 신뢰가 떨어집니다. 혼란을 더하는 sophistication은 증거의 강도를 오히려 낮춥니다.

실무 조언 (Spotify가 던지는 메시지)

1. 원하는 실험 프로그램을 먼저 정의하세요. 2. 필요한 보장(guarantee)을 정하고, 지속 유지 가능한지 확인하세요. 3. 그다음에 "특정 베이지안 설정이 기존 대비 유의미하게 개선되는가"를 물으세요.

Spotify에게 지금 그 답은 "아니오"입니다.

프레임워크 논쟁은 사실 본질을 흐리는 소모전이 되기 쉬워요. 진짜 중요한 건:

  • 추론이 일관적인가?
  • 샘플 사이즈 계산기가 실제 결정 규칙과 일치하는가?
  • 실험이 ship 결정만이 아니라 학습을 만들고 있는가?

이 세 가지가 안 되어 있으면, 베이지안이든 빈도주의든 별 의미가 없습니다.

함께 보면 좋은 글

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.