실험 플랫폼 비용 2026, A/B 테스트·피처 플래그·권한 기준

실험 플랫폼 비용을 검토하는 A/B 테스트와 피처 플래그 회의 장면 — 실험 플랫폼 비용은 좌석 수보다 이벤트 과금, 승인 권한, 플래그 정리 비용에서 크게 흔들린다.

실험 플랫폼 비용을 찾는 팀은 보통 A/B 테스트 도구 하나를 사면 제품 의사결정이 정리될 것이라고 기대한다.

실제로는 피처 플래그, 실험 노출 이벤트, 지표 계산, 권한 승인, 감사 로그, 데이터 웨어하우스 연결이 한 청구서에 섞인다.

결론부터 말하면 월 좌석 단가만 보고 고르면 첫 실험보다 두 번째 실험에서 비용과 운영 리스크가 커진다.

이 글은 GrowthBook, Statsig, PostHog, LaunchDarkly, OpenFeature 문서를 기준으로 실험 플랫폼 비용을 견적표로 바꾸는 방법을 정리한다.

핵심 요약

GrowthBook Starter는 무료로 최대 3명, 1개 프로젝트, 무제한 feature flags와 experiments를 제시한다.
GrowthBook Pro는 좌석당 월 40달러이며 최대 50명, 3개 프로젝트, CDN requests 월 2M 이후 100만건당 10달러 조건을 표시한다.
Statsig Developer Tier는 매월 2M metered events를 무료로 주고, Pro는 월 150달러와 월 5M metered events 포함 조건을 제시한다.
Statsig Pro에서 월 5M metered events를 넘으면 추가 1,000건당 0.05달러 overage가 붙는다고 공식 FAQ가 설명한다.

먼저 실험 플랫폼이 무엇을 과금하는지 나눌 것

실험 플랫폼은 단순 설문 도구가 아니라 배포와 분석 사이에 놓이는 운영 계층이다.

피처 플래그는 사용자를 나누어 기능을 켜고 끄는 배포 장치다.

A/B 테스트는 노출 집단과 지표를 묶어 제품 결정을 내리는 분석 장치다.

권한 관리는 잘못된 실험 시작, 강제 노출, 실험 종료 누락을 막는 통제 장치다.

Daangn Engineering의 실험플랫폼 글도 실험 설계를 편하게 만드는 내부 플랫폼 관점에서 문제를 다룬다.

과금 축	대표 입력값	비용이 커지는 순간	구매 전 질문
좌석	PM, 개발자, 데이터 분석가, 승인자 수	SSO와 승인 기능이 상위 플랜에 묶임	읽기 전용 사용자도 billable인지 확인했나
이벤트	exposure, log event, metric event	실험 노출과 제품 로그를 중복 전송함	과금 이벤트 정의와 dedupe 기준을 봤나
SDK 전달	CDN requests, bandwidth, streaming	트래픽 피크 때 flag evaluation이 늘어남	client SDK와 server SDK 트래픽을 분리했나
데이터 연결	warehouse, ETL, reverse ETL	실험 결과를 내부 지표와 맞추기 위해 파이프라인이 늘어남	BYO warehouse와 managed warehouse 경계를 정했나
거버넌스	approval, audit log, SCIM, stale flag	감사 요구가 생긴 뒤 Enterprise 기능이 필요해짐	승인권자와 flag cleanup SLA가 있나

이 조건이면 무료 플랜으로 파일럿을 시작할 수 있다.

실험 수가 적고, SSO가 필요 없고, 분석 이벤트가 월 무료 한도 안에 들어오는 초기 제품팀이다.

이 경우는 유료 플랜을 먼저 봐야 한다.

SSO, SCIM, 승인 워크플로, audit log export, 대규모 이벤트 계산이 이미 보안 요구사항에 들어간 조직이다.

공식 가격표 핵심 숫자

아래 숫자는 발행일 기준 공식 가격표와 FAQ에서 확인한 대표 조건이다.

실제 계약 전에는 통화, 세금, 연간 약정, 이벤트 정의, 엔터프라이즈 할인, 데이터 보관 조건을 다시 확인해야 한다.

서비스	무료·기본 조건	유료 시작점	초과·운영 비용 신호
GrowthBook Starter	무료, 최대 3 users, 1 project, unlimited feature flags, unlimited experiments, unlimited traffic	Pro 전에는 고급 권한과 지원 범위가 제한됨	CDN requests 월 1M, bandwidth 월 5GB 기본 조건을 확인
GrowthBook Pro	최대 50 users, 3 projects, unlimited flags와 experiments	좌석당 월 40달러	CDN requests 월 2M 이후 100만건당 10달러, bandwidth 월 20GB 이후 GB당 1달러
GrowthBook Enterprise	custom environments, approval workflows, SSO, SCIM, exportable audit logs	Custom pricing	대규모 데이터셋과 SLA 조건은 영업 견적 기준
Statsig Developer Tier	매월 2M metered events 무료	무료 한도 초과 시 Pro 업그레이드 안내	Metric Lift 계산이 멈추는 조건과 알림을 확인
Statsig Pro	월 5M metered events 포함	월 150달러 baseline fee	초과분은 추가 1,000 events당 0.05달러
PostHog Feature Flags	공식 가격 페이지가 product별 usage-based와 free tier를 안내	필요 제품과 이벤트량별 계산 필요	제품 분석, replay, flag event가 한 프로젝트에서 섞이는지 확인
LaunchDarkly	공식 가격 페이지에서 Free 시작과 plan matrix를 제공	MAU, AI runs, platform plan 조건 확인 필요	client-side MAU, overage, Enterprise 기능을 따로 검토

이 주제는 LLM 입력 토큰·출력 토큰 청구가 아니라 이벤트·좌석·CDN 트래픽 청구로 봐야 한다.

가격표에서 가장 먼저 볼 숫자는 좌석 단가가 아니다.

월 이벤트량, CDN request, bandwidth, SSO 요구, 승인 워크플로가 유료 플랜을 결정한다.

GrowthBook Pro의 40달러 좌석 단가는 이해하기 쉽지만 CDN request와 bandwidth overage가 숨어 있다.

Statsig의 150달러 baseline은 단순하지만 metered events 5M 이후 추가 1,000건당 0.05달러가 예산 변수가 된다.

GrowthBook을 먼저 볼 조건

GrowthBook은 feature flags와 experiments를 한 제품 안에서 다루고, 자체 호스팅과 cloud 선택지를 같이 검토할 수 있다.

공식 가격표는 Starter와 Pro 모두 unlimited feature flags와 unlimited experiments를 전면에 둔다.

작은 제품팀은 Starter의 최대 3 users와 1 project 조건으로 실험 운영 방식을 먼저 검증할 수 있다.
중간 규모 팀은 Pro의 좌석당 월 40달러와 최대 50 users 조건으로 예산을 빠르게 추산할 수 있다.
SSO, SCIM, approval workflows, exportable audit logs가 필요하면 Enterprise 조건을 먼저 문의해야 한다.
BYO warehouse를 쓰면 데이터 소유권은 좋아지지만 지표 스키마 설계와 warehouse 비용은 내부 팀 책임이 된다.

실무 시나리오 1은 B2B SaaS 팀이 기존 BigQuery나 Snowflake 안의 결제 이벤트로 실험 지표를 계산하는 경우다.

이 조건이면 GrowthBook의 BYO warehouse 구조가 맞을 수 있지만 데이터 스키마 소유자가 반드시 필요하다.

반대로 데이터 웨어하우스가 없고 PM이 바로 실험을 열어야 한다면 managed warehouse 조건과 overage를 같이 봐야 한다.

Statsig를 먼저 볼 조건

Statsig는 gates, configs, experimentation, analytics를 한 플랫폼으로 묶고 metered events 기반 과금 철학을 설명한다.

공식 FAQ는 Developer Tier에서 매월 2M metered events를 무료로 제공한다고 안내한다.

Pro Tier는 월 150달러 baseline fee와 월 5M metered events 포함 조건을 제시한다.

월 5M을 넘으면 추가 1,000 events당 0.05달러 overage가 청구된다는 문구도 공식 FAQ에 있다.

실험 노출, 로그 이벤트, warehouse에서 가져온 metric이 모두 metered events에 들어가는지 확인한다.
클라이언트 SDK와 서버 SDK의 exposure dedupe window가 비용과 지표 정확도에 어떤 영향을 주는지 본다.
0% 또는 100% rollout에서 Metric Lift 계산을 켰는지에 따라 과금 이벤트가 달라질 수 있다.
월 5M events 근처에 있는 조직은 실험 수보다 이벤트 설계가 예산을 좌우한다.

실무 시나리오 2는 커머스 앱이 홈 화면, 검색, 쿠폰, 결제 흐름에서 동시에 실험을 돌리는 경우다.

이 조건이면 노출 이벤트와 구매 이벤트를 모두 보내기 전에 metered event 정의를 비용표에 붙여야 한다.

실험 수가 적어도 트래픽이 크면 월 5M events를 빨리 넘을 수 있다.

PostHog와 LaunchDarkly를 비교할 때

PostHog는 제품 분석, feature flags, session replay 같은 제품군을 같은 공간에서 보는 팀이 검토하기 좋다.

공식 pricing 페이지는 product별 usage-based 구조와 free tier를 안내하므로 필요한 제품만 따로 계산해야 한다.

LaunchDarkly는 feature management와 release governance가 중심인 조직에서 먼저 검토할 만하다.

공식 pricing 페이지는 MAU, AI runs, plan matrix와 Enterprise 조건을 함께 보여주므로 실험 분석 도구와 같은 표에 넣으면 안 된다.

선택지	강한 지점	비용 확인 포인트	보류할 조건
PostHog	제품 분석과 feature flags를 한 프로젝트에서 연결	product별 free tier, event volume, 추가 제품 사용량	이미 별도 분석 플랫폼이 있고 flag만 필요한 경우
LaunchDarkly	릴리즈 관리, kill switch, feature governance	MAU, client-side evaluation, Enterprise governance 기능	통계 분석과 warehouse 지표가 핵심인 경우
GrowthBook	A/B 테스트와 feature flags를 데이터 웨어하우스와 연결	좌석, CDN request, bandwidth, managed warehouse	데이터 스키마 소유자가 없는 경우
Statsig	실험, gates, configs, analytics를 이벤트 기반으로 운영	metered events, overage, metric computation	이벤트 정의가 통제되지 않는 조직

이 조건이면 PostHog를 본다.

제품 분석, funnel, feature flags, replay를 한 화면에서 보고 싶고 여러 제품을 이미 PostHog에 모을 계획인 경우다.

이 조건이면 LaunchDarkly를 본다.

실험 통계보다 배포 안전, kill switch, 승인, flag lifecycle 통제가 더 큰 비용 리스크인 경우다.

권한과 보안 비용을 빼면 견적이 틀린다

실험 플랫폼은 제품팀만 쓰는 도구처럼 보이지만 실제 권한은 배포 권한에 가깝다.

누가 flag를 켜고 끄는지, 누가 실험 대상을 바꾸는지, 누가 지표를 확정하는지 정하지 않으면 장애와 데이터 왜곡이 동시에 생긴다.

SSO와 SCIM은 편의 기능이 아니라 퇴사자 권한 회수와 감사 증거를 위한 비용 항목이다.

approval workflow는 느려 보이지만 결제, 추천, 가입, 보안 기능 실험에서는 사고 비용을 줄이는 장치다.

통제 항목	필요한 기능	비용이 붙는 방식	검증 질문
SSO	Google 또는 OIDC SSO	Pro 또는 Enterprise 플랜 조건일 수 있음	외부 계정 로그인을 허용할 수 있나
SCIM	입사·퇴사 자동 권한 반영	대개 Enterprise 기능으로 묶임	퇴사자 flag 권한 회수 증거가 필요한가
Approval	실험 시작과 rollout 변경 승인	상위 플랜 또는 custom 조건일 수 있음	결제·가입 실험에 2인 승인이 필요한가
Audit log	flag 변경 이력과 export	exportable audit logs가 Enterprise 조건일 수 있음	사고 뒤 누가 언제 바꿨는지 추적 가능한가
Stale flag cleanup	오래된 flag 탐지와 제거	기능 제공 여부와 운영 인건비가 함께 듦	45일 이상 방치된 flag를 누가 지우나

보안팀은 실험 플랫폼을 SaaS 구매로만 보지 말아야 한다.

flag 하나가 특정 사용자에게 결제 화면, 권한 메뉴, 추천 결과를 다르게 보여줄 수 있기 때문이다.

이벤트 과금 폭탄을 막는 설계 순서

비용을 줄이는 가장 확실한 방법은 실험을 줄이는 것이 아니라 과금 이벤트를 통제하는 것이다.

실험 노출 이벤트와 일반 제품 로그 이벤트를 분리한다.
클라이언트 SDK와 서버 SDK가 같은 exposure를 중복 전송하지 않는지 확인한다.
guardrail metric은 꼭 필요한 것만 첫 실험에 넣는다.
warehouse metric을 가져올 때 집계 주기와 fresh requirement를 표로 둔다.
무료 한도와 유료 한도 70%, 90%, 100% 알림을 만든다.
flag evaluation이 CDN request나 streaming update로 과금되는지 본다.
실험 종료 뒤 flag cleanup 일정을 release calendar에 넣는다.
월말 청구서에서 seats, events, bandwidth, SSO add-on을 분리해 회고한다.

개발팀은 SDK 설치 전에 이벤트 이름과 사용자 식별자를 고정해야 한다.

데이터팀은 실험 결과가 내부 매출 지표와 어긋날 때 어느 쪽을 기준으로 의사결정할지 미리 정해야 한다.

OpenFeature로 vendor lock-in을 낮추는 방법

OpenFeature는 feature flag provider를 애플리케이션 코드와 느슨하게 연결하는 표준 인터페이스 접근을 제시한다.

이 표준을 쓴다고 비용이 자동으로 내려가지는 않지만 provider 교체와 이중 운영 기간을 줄이는 데 의미가 있다.

다만 OpenFeature는 실험 통계, metric pipeline, 승인 워크플로를 대신하지 않는다.

따라서 SDK 추상화는 배포 계층에서 쓰고, 실험 분석과 권한 통제는 구매 기준표에 따로 둬야 한다.

애플리케이션 코드는 OpenFeature 표준 인터페이스를 호출하고 provider 교체 지점을 한 곳에 둔다.
client side와 server side key를 분리하고 사용자 식별자 노출 범위를 제한한다.
flag default value와 provider 장애 시 fallback 값을 코드 리뷰에서 확인한다.
실험 노출 이벤트는 provider와 warehouse 양쪽에서 중복 계산되지 않게 설계한다.

실무 시나리오 3은 스타트업이 GrowthBook으로 시작했다가 대기업 고객 요구 때문에 LaunchDarkly나 Statsig 검토가 필요한 경우다.

이 조건이면 OpenFeature provider 경계를 먼저 잡아두면 앱 코드 수정 비용을 줄일 수 있다.

구매 전 체크리스트

실험 플랫폼 비용 비교표는 아래 입력값이 없으면 가격표 복사본에 그친다.

최근 30일 사용자 수, 월간 세션, 핵심 이벤트 수, 예상 exposure 수를 뽑는다.
첫 3개월에 돌릴 실험 수와 각 실험의 guardrail metric 수를 적는다.
PM, 개발자, 데이터 분석가, 승인자, 읽기 전용 사용자를 구분한다.
SSO, SCIM, approval, audit log export가 필수인지 보안팀 확인을 받는다.
flag cleanup SLA와 owner를 release process에 넣는다.
SDK 평가 방식이 client-side인지 server-side인지 나누고 key 노출 범위를 검토한다.
무료 tier 한도를 넘는 순간 어떤 기능이 멈추거나 청구되는지 문서화한다.
PoC는 하나의 checkout 또는 onboarding flow만 골라 이벤트량을 실제로 측정한다.

구매팀은 견적서에 좌석 단가만 있으면 반려해야 한다.

제품팀은 실험 결과 리포트가 예뻐도 metric owner와 중단 기준이 없으면 도입을 보류해야 한다.

실무 스켈레톤: 비용 입력 YAML

아래 YAML은 실제 계약서가 아니라 벤더 비교 전에 입력값을 빠뜨리지 않기 위한 검토용 템플릿이다.

# experiment-platform-cost.yaml
# 목적: A/B 테스트와 피처 플래그 플랫폼 견적 전에 이벤트량, 좌석, 권한, 데이터 보관을 같은 단위로 맞춘다.
# 실제 계약 전에는 각 벤더의 공식 가격표, 과금 이벤트 정의, 데이터 처리 계약, SSO 조건을 다시 확인한다.

team:
  product_managers: 8
  engineers: 14
  data_analysts: 3
  approvers: [product-lead, security-lead, data-lead]

monthly_volume:
  feature_flag_evaluations: 48000000
  experiment_exposures: 9000000
  product_events: 36000000
  metric_computation_events: 7000000
  sdk_cdn_requests: 2600000
  sdk_cdn_bandwidth_gb: 38

pricing_inputs:
  seats:
    billable_users: 25
    review_users: 6
    sso_required: true
  events:
    metered_event_definition_checked: true
    dedupe_window_checked: true
    overage_alert_owner: data-platform-team
  governance:
    approval_workflow_required: true
    audit_log_export_required: true
    flag_cleanup_sla_days: 45

purchase_gate:
  - starter_or_free_tier_does_not_hide_sso_requirement
  - event_overage_alarm_defined_before_first_experiment
  - warehouse_or_vendor_storage_boundary_reviewed
  - rollback_owner_named_for_every_flag
  - experiment_decision_log_kept_with_metric_owner

핵심은 실험 수가 아니라 billable users, metered events, CDN requests, bandwidth, SSO requirement를 같은 파일에 두는 것이다.

이 파일을 PoC 시작 전에 채우면 무료 tier에서 유료 tier로 넘어가는 지점이 보인다.

과금 위험 점검 Python 스켈레톤

아래 코드는 실제 청구 계산기가 아니라 공식 가격표에서 다시 확인해야 할 위험 항목을 표시하는 예시다.

#!/usr/bin/env python3
# ab_test_cost_guardrail.py
# 목적: 실험 플랫폼 견적 전 이벤트 과금과 좌석 과금을 분리해 초과 위험을 표시한다.
# 단가는 예시가 아니며, 실제 계산 전 각 벤더 공식 가격표의 최신 단가로 교체해야 한다.

from dataclasses import dataclass

@dataclass
class ExperimentWorkload:
    billable_users: int
    monthly_metered_events: int
    monthly_cdn_requests: int
    monthly_cdn_bandwidth_gb: int
    sso_required: bool
    approval_workflow_required: bool

    def risk_flags(self) -> list[str]:
        flags = []
        if self.sso_required:
            flags.append('SSO가 유료 또는 Enterprise 조건인지 확인')
        if self.approval_workflow_required:
            flags.append('실험 승인 흐름과 audit log export 조건 확인')
        if self.monthly_metered_events > 5_000_000:
            flags.append('Statsig Pro 포함 이벤트 5M 초과 가능성 확인')
        if self.monthly_cdn_requests > 2_000_000:
            flags.append('GrowthBook Pro CDN request 2M 이후 overage 확인')
        if self.monthly_cdn_bandwidth_gb > 20:
            flags.append('GrowthBook Pro CDN bandwidth 20GB 이후 overage 확인')
        return flags

workload = ExperimentWorkload(
    billable_users=25,
    monthly_metered_events=7_000_000,
    monthly_cdn_requests=2_600_000,
    monthly_cdn_bandwidth_gb=38,
    sso_required=True,
    approval_workflow_required=True,
)

for flag in workload.risk_flags():
    print('-', flag)

이 스크립트는 단가를 계산하지 않는다.

대신 GrowthBook과 Statsig 가격표에서 자주 놓치는 request, bandwidth, metered events 조건을 검토 목록으로 끌어올린다.

OpenFeature provider 점검 JSON

아래 JSON은 provider 교체 가능성을 남기면서도 장애 대응 책임을 흐리지 않기 위한 체크리스트다.

{
  "openfeature-provider-checklist": {
    "goal": "피처 플래그 SDK와 실험 분석 도구를 느슨하게 결합한다",
    "must_check": [
      "provider 교체 때 애플리케이션 코드 변경 범위",
      "client side key와 server side key 분리",
      "실험 노출 이벤트와 일반 로그 이벤트의 중복 전송",
      "kill switch가 장애 대응 runbook에 들어갔는지 여부",
      "flag cleanup SLA와 stale flag 리포트"
    ],
    "rollback": {
      "owner": "release-manager",
      "max_minutes": 15,
      "evidence": "flag change history and incident note"
    }
  }
}

vendor lock-in을 줄인다는 말은 계약서보다 코드 경계와 장애 runbook에서 먼저 증명되어야 한다.

provider가 장애를 내도 기본값, kill switch, rollback owner가 있으면 실험 플랫폼 장애가 서비스 장애로 번지는 시간을 줄일 수 있다.