실험 플랫폼은 'Feature Flag의 연장'이 아니다
- 년 시점에서 많은 팀이 'Feature Flag 도구 = 실험 플랫폼'으로 인식하고 있지만, 이는 정확히는 틀린 것입니다. Feature Flag는 단순히 릴리스 제어의 스위치이며, A/B 테스트를 위해서는 독립된 통계 엔진·메트릭 레지스트리·Exposure 로그·Guardrail의 4점 세트가 필요합니다. 2026년의 주요 플레이어인 Statsig, LaunchDarkly, GrowthBook, Unleash는, 이 4점 세트를 어디까지 제공하는가에 따라 성격이 완전히 다릅니다.
Statsig는 통계 엔진이 가장 성숙하며, Meta 출신 팀의 설계 사상을 짙게 계승합니다. LaunchDarkly는 Feature Flag의 사실상 표준이지만, 실험 기능은 Experimentation 애드온으로 별도 과금입니다. GrowthBook은 OSS로 통계 로직을 완전히 오픈하고 있으며, 자사의 데이터 웨어하우스에 탑재하는 구성이 가능합니다. Unleash는 Feature Flag 단독의 OSS로, 실험은 외부 통합을 전제로 하는 명쾌한 설계를 취합니다.
Statsig: 엔드 투 엔드의 통계 엔진
Statsig의 강점은, CUPED(Controlled-experiment Using Pre-Experiment Data), Sequential Testing, Bayesian/Frequentist의 전환, Guardrail Metrics가 처음부터 통합되어 있다는 점입니다. 2026년 버전에서는 특히 'Autotune' 기능이 주목받고 있으며, 밴딧 기반으로 트래픽 배분을 동적으로 조정합니다. 최적의 배리언트로의 수렴 속도가 고정 배분의 2~3배 빠르다고 공표되었습니다.
Exposure 로그는 `@statsig/react` 경유로 자동 기록되며, 이벤트와의 결합은 Statsig 내부의 통계 엔진이 처리합니다. Metrics 레지스트리는 DAG 구조로, 파생 메트릭(예: '구매 완료 후 30일 이내의 2회째 구매율')을 선언적으로 정의 가능합니다. 가격은 무료 플랜이 월 100만 이벤트까지로 관대하며, 스타트업 단계부터 사용할 수 있습니다. Enterprise 플랜은 연액 3,000~8,000만 엔 레인지입니다.
일본 팀이 빠지기 쉬운 함정은 Exposure의 타이밍입니다. Statsig는 '값을 참조한 순간'을 Exposure로 기록하므로, 사전에 전 배리언트를 평가하는 코드는 의도치 않은 Exposure를 대량 생성합니다. 반드시 `checkGate`/`getExperiment`를 사용 직전에 호출하는 구현 규약이 필요합니다.
LaunchDarkly: Feature Flag 기반으로서의 견고함
LaunchDarkly는 Feature Flag 운용의 견고함에서 다른 것을 압도합니다. Targeting Rule의 버저닝, Approval Workflow, Code References, Guarded Rollouts(메트릭 악화 시의 자동 롤백) 등의 본番 운용 기능이 망라되어 있으며, 1,000명 규모의 엔지니어 조직에서도 파탄이 없습니다.
- 년 버전에서는 `AI Configs`라는 새 기능이 추가되어, Anthropic/OpenAI/Google의 LLM 호출을 모델·온도·프롬프트 단위로 Flag 관리할 수 있게 되었습니다. 모델 전환을 Feature Flag와 동일한 운용 흐름에 올릴 수 있는 점은, LLM 프로덕트의 운용 효율을 크게 높입니다.
실험 기능은 Experimentation 애드온으로 연액 추가 1,500만 엔 전후부터입니다. 통계 엔진은 Frequentist 기반으로, Sequential Testing은 대응하지만 CUPED는 미대응입니다. 따라서 분석의 깊이가 필요한 경우에는, Exposure 로그를 BigQuery/Snowflake에 출력하고 직접 통계 처리하는 구성이 됩니다. LaunchDarkly + dbt + Hex의 조합은 2026년의 정석입니다.
GrowthBook: OSS와 데이터 웨어하우스 통합
GrowthBook은 완전 OSS(MIT)로, 통계 엔진이 Python/Go 구현으로 공개되어 있습니다. 최대의 차별화 포인트는 '데이터 웨어하우스에 직접 쿼리하는' 설계 사상입니다. BigQuery, Snowflake, Redshift, ClickHouse, Databricks 등 20종 이상에 대응하며, 분석 대상 이벤트 테이블을 GrowthBook 측으로 복사하지 않습니다. 이를 통해 데이터 주권을 잃지 않고, PII의 월경을 피할 수 있습니다.
통계 엔진은 Bayesian(기본값)과 Frequentist 양쪽 대응, CUPED, Sequential Testing, CUPAC(CUPED의 다변량 확장)도 구현되어 있습니다. 2026년 버전에서는 Causal Inference(Double Machine Learning) 기능이 추가되어, 관찰 데이터로부터의 인과 효과 추정도 가능해졌습니다. 관찰 데이터는 엄밀한 A/B보다 약하지만, 윤리적으로 실험할 수 없는 영역(예: 가격 변경)의 1차 스크리닝에 유효합니다.
GrowthBook Cloud는 월 200달러(약 30,000엔)부터, 셀프호스트는 완전 무료입니다. 다만 셀프호스트는 Redis + MongoDB 운용이 필요하며, 소규모 팀에서는 GrowthBook Cloud가 실질적으로 저렴해집니다.
Unleash: 순수한 Feature Flag와 외부 통합
Unleash는 Feature Flag 단독의 OSS로, 실험은 '데이터 파이프라인으로 외부화한다'는 명쾌한 방식입니다. ClickHouse나 Apache Druid에 Exposure를 출력하고, 통계 처리는 별도 도구(Kubit, 직접 노트북, Metabase 등)로 실시하는 것을 전제로 합니다.
이 설계의 강점은, 실험 플랫폼을 데이터 기반의 일부로 구성할 수 있다는 점입니다. Unleash에서 BigQuery에 Exposure를 보내고, 기존 KPI 메트릭(세그먼트/LTV/해약률)과 결합하여 분석함으로써, 실험 전용 메트릭과 경영 메트릭의 이중 관리를 피할 수 있습니다. 대기업의 데이터 기반과의 친화성은 이 4사 중 가장 높습니다.
Bayesian vs Frequentist: 2026년의 현실적 결론
오랜 논쟁이지만, 2026년 시점에서의 실무적 권장은 '거의 모든 프로덕트 실험은 Bayesian, Regulated 업계(금융·의료)만 Frequentist'라는 단순한 결론에 귀결되고 있습니다. Bayesian은 '배리언트 A가 이길 확률'이라는 직관적인 해석, Stop condition의 유연함, 사전 분포에 의한 지식 취합이라는 점에서 실무에 적합합니다.
다만 Bayesian을 사용할 때의 최대 함정은 사전 분포(Prior)의 설정입니다. Uninformative Prior를 선택한다면 좋지만, 과거 데이터로부터 Informative Prior를 구성하면, 의도치 않게 과거의 실패 패턴을 바이어스로 가져오는 위험이 있습니다. GrowthBook/Statsig 모두 기본값은 Uninformative Prior이므로, 망설인다면 변경하지 않는 것이 안전합니다.
Frequentist를 선택하는 경우에도, 종래의 `p<0.05` 고정값은 Peeking Problem(중간 확인에 의한 α팽창)을 일으키므로, Sequential Testing(Alpha-spending 또는 Always-valid p-values)을 반드시 병용합니다. Statsig/GrowthBook 모두 Sequential Testing 대응 완료입니다.
CUPED에 의한 분산 삭감
CUPED(Controlled-experiment Using Pre-Experiment Data)는, 실험 기간 전의 유저 행동을 공변량으로 사용하여 메트릭의 분산을 삭감하는 기법입니다. 동일한 효과 사이즈를 검출하는 데 필요한 샘플 수를 30~50% 삭감할 수 있습니다. 특히 Revenue나 Retention처럼 노이즈가 큰 메트릭에서는 극적인 효과가 있습니다.
구현은 단순하여, 실험 전 30일간의 유저 행동(예: 구매 금액, 세션 수)을 공변량 `X`로 하고, 메트릭 `Y`를 `Y - θ(X - E[X])`로 조정합니다. `θ`는 `cov(Y, X) / var(X)`로 추정합니다. Statsig/GrowthBook은 이를 자동화하고 있지만, LaunchDarkly에서는 직접 구현이 필요합니다.
주의점으로, CUPED는 배리언트 간에 사전 기간의 행동이 독립적이어야 합니다. 신규 유저가 많은 실험에서는 사전 데이터가 존재하지 않아 CUPED의 혜택이 얇아집니다. 따라서 신규 유저 실험에서는 CUPED를 비활성화하는 것이 올바른 운용입니다.
Guardrail Metrics와 Stop 판정
Guardrail Metrics는 실험의 성공 메트릭과는 별도로 '무너뜨려서는 안 되는 메트릭'(페이지 로드 시간, 오류율, 이탈률 등)을 모니터링하여, 악화된 순간에 실험을 자동 중지하는 구조입니다. Statsig는 `Guardrails` 탭에서 설정 가능하며, GrowthBook도 동등한 기능을 제공합니다.
Stop 판정은 'Guardrail이 유의하게 악화되면 즉시 중지'와 '주요 메트릭이 충분한 확률로 이기고 있으면 조기 종료'의 2축으로 설계합니다. Bayesian의 경우, 주요 메트릭의 승률 95% 이상으로 조기 승리, Guardrail의 악화 확률 90% 이상으로 조기 중지라는 것이 2026년의 정석 임계값입니다.
Server-side vs Client-side의 판단 축
실험을 Server-side와 Client-side 중 어느 쪽에서 평가할 것인가는, 구현 때마다 판단하는 문제가 아니라 조직으로서 정책을 결정해야 할 영역입니다. 2026년의 권장은 'Server-side 기본, Client-side는 UI에만 한정'입니다.
Client-side의 문제는 세 가지입니다. 첫째는 Flicker(배리언트 전환 시의 화면 깜박임)로, UX를 극적으로 손상시킵니다. 둘째는 광고 차단기에 의한 SDK 로드 실패로, Exposure의 결손율이 5~15% 발생합니다. 셋째는 기밀 로직(가격, 추천)을 클라이언트에 노출하는 보안 리스크입니다.
Server-side에서 평가할 때의 주의점은, Edge 런타임(Cloudflare Workers, Vercel Edge)에서 Statsig/LaunchDarkly의 SDK를 사용하는 경우, 콜드 스타트에서 100~300ms의 오버헤드가 발생한다는 것입니다. Edge Config(LaunchDarkly)나 Statsig의 Local Evaluation 모드를 사용하여, 평가 로직을 메모리 내에서 완결시키는 구성이 필수입니다.
실험 플랫폼 선정 체크리스트
- 통계 엔진(CUPED/Sequential Testing/Bayesian)의 표준 장비를 반드시 확인합니다.
- Exposure 로그를 데이터 웨어하우스에 복제하여, 외부에서의 재분석을 가능하게 해둡니다.
- Guardrail Metrics를 처음부터 설정하고, 자동 중지의 임계값을 명시합니다.
- Server-side 평가를 기본으로 하고, Client-side는 UI에만 한정합니다.
- Feature Flag와 Experiment를 동일한 도구에 통합할지, 분리할지를 조직에서 결정해둡니다.
- OSS/셀프호스트를 선택하는 경우, 운용 공수를 연간 400~600시간으로 산정합니다.
실험 플랫폼은 2026년, '의사결정의 속도와 올바름'을 결정하는 가장 중요한 기반 중 하나입니다. 통계 엔진의 차이, 운용의 세세한 규약, 그리고 Server-side/Client-side의 설계 사상까지 포함하여, 전략적으로 선택하는 시대가 되었습니다.