피처 플래그 & 실험 플랫폼 2026 — LaunchDarkly / Statsig / GrowthBook / Unleash / PostHog / OpenFeature 심층 비교

프롤로그 — "배포 = 릴리즈"는 2026년에도 여전히 안 맞는다

엔지니어: "이번 주에 신기능 배포 끝났어요." PM: "그럼 사용자에게 켜진 거예요?" 엔지니어: "아니요, 플래그로 막혀 있어요. 다음 주에 5%부터 켭니다." PM: "그럼 배포가 끝난 게 아닌 거잖아요?" 엔지니어: "...배포는 끝났고, 릴리즈가 안 된 거예요."

2026년이 되어도 이 대화는 흔하다. 그리고 이 분리 — deploy(코드를 production에 두는 것) vs release(사용자에게 켜는 것) — 가 modern delivery의 핵심이고, 그걸 가능하게 하는 도구가 피처 플래그(feature flag) 다.

피처 플래그는 더 이상 "if 문 트릭"이 아니다. 2026년의 피처 플래그 플랫폼은 kill switch + gradual rollout + A/B 실험 + multi-arm bandit + holdout 분석 + targeting + segmentation + audit log가 한 제품에 묶여 있고, OpenFeature라는 CNCF 표준 SDK가 그 위에 얹혀 있다. 그리고 시장은 매니지드 SaaS(LaunchDarkly·Statsig), 오픈소스(GrowthBook·Unleash·Flagsmith), 통합 플랫폼(PostHog) 세 진영으로 갈라져 있다.

이 글은 2026년 현재 피처 플래그/실험 플랫폼 지도를 그린다. 16개 제품·표준을 한 줄씩 위치 짓고, 패턴(kill switch·gradual rollout·A/B·bandit·holdout)을 정리하고, 토스·카카오·메르카리의 실제 사례를 살피고, 우리 팀이 무엇을 골라야 할지까지 가본다.

1장 · 2026년 피처 플래그 지도 — 매니지드 / 오픈소스 / 통합 플랫폼 3 진영

먼저 큰 그림. 2026년의 시장은 세 진영으로 깔끔하게 갈라진다.

1) 매니지드 SaaS 진영 — LaunchDarkly, Statsig, ConfigCat, Split, DevCycle, AB Tasty, Eppo, Optimizely Rollouts

호스티드 첫 번째. 엔터프라이즈 SLA·SSO·SOC2·HIPAA·BAA.
가격은 MAU·플래그 수·환경 수로 매겨진다.

2) 오픈소스 진영 — GrowthBook, Unleash, Flagsmith, Bucketeer

셀프 호스팅이 일등 시민. SaaS 옵션은 부가.
라이선스: GrowthBook(MIT), Unleash(Apache 2.0), Flagsmith(BSD-3), Bucketeer(Apache 2.0).
"벤더 락인을 피하고 싶다", "데이터를 우리 인프라 안에", "BYO budget"이 결정 요인.

3) 통합 플랫폼 진영 — PostHog

analytics + session replay + feature flags + 실험을 한 제품에.
플래그를 별도 도구로 보지 않고 "이벤트와 같은 평면 위의 토글"로 본다.

그리고 그 위에 OpenFeature(CNCF) 라는 표준 SDK 레이어가 있다. 어떤 벤더를 쓰든 코드 호출 면은 통일된다. 이게 2024~2026년의 가장 큰 변화다 — 이제 "벤더 한 번 정하면 평생"이 아니라 "표준 SDK + 갈아끼울 수 있는 백엔드"가 가능해졌다.

진영	대표	라이선스	호스팅	한 줄 평
매니지드 SaaS	LaunchDarkly	Closed	SaaS + 셀프 옵션	엔터프라이즈 디폴트
매니지드 SaaS	Statsig	Closed	SaaS	flags + 실험 + 분석 통합
오픈소스	GrowthBook	MIT	self/SaaS	실험 강한 OSS
오픈소스	Unleash	Apache 2.0	self/SaaS	엔터프라이즈 친화 OSS
오픈소스	Flagsmith	BSD-3	self/SaaS	API 우선 OSS
통합	PostHog	MIT (코어)	self/SaaS	analytics + flags + replay
표준	OpenFeature	Apache 2.0 (CNCF)	표준 SDK	벤더 중립 SDK 계층

2장 · OpenFeature (CNCF) — 표준 SDK

OpenFeature는 2022년 시작해 2023년 CNCF Incubating, 2024~2025년 사이 채택이 가팔라진 벤더 중립 피처 플래그 표준이다. 2026년 현재 LaunchDarkly·Split·ConfigCat·Flagsmith·Unleash·DevCycle·GrowthBook 등 거의 모든 주요 플래그 벤더가 OpenFeature provider를 공식 지원한다.

핵심 아이디어: SDK API는 한 가지로 통일하고, 백엔드(provider)는 갈아끼울 수 있게 한다. OpenTelemetry가 텔레메트리에서 한 것을, OpenFeature는 피처 플래그에서 한다.

전형적인 Node/TS 코드:

import { OpenFeature } from '@openfeature/server-sdk'
import { LaunchDarklyProvider } from '@openfeature/launchdarkly-server-provider'

await OpenFeature.setProviderAndWait(
  new LaunchDarklyProvider(process.env.LD_SDK_KEY!)
)

const client = OpenFeature.getClient()

const showNewCheckout = await client.getBooleanValue(
  'new-checkout',
  false, // default fallback
  { targetingKey: userId, plan: user.plan }
)

if (showNewCheckout) {
  return <NewCheckout />
}
return <LegacyCheckout />

내일 Unleash로 바꾸기로 했다면? LaunchDarklyProvider만 UnleashProvider로 교체하면 끝. 평가 호출(getBooleanValue/getStringValue 등) 한 줄도 안 건드린다.

OpenFeature가 표준화하는 것:

평가 API — getBooleanValue/getStringValue/getNumberValue/getObjectValue.
evaluation context — 평가에 쓰이는 사용자/요청 속성(targetingKey·임의 attrs).
hooks — before/after/error/finally 라이프사이클 훅.
providers — 벤더 백엔드 어댑터.
telemetry — OpenTelemetry 스팬으로 평가 이벤트 자동 기록.

표준화하지 않는 것:

플래그 정의 형식 — 각 벤더 콘솔이 달라도 됨.
targeting 룰 — 벤더가 알아서.
실험·통계 — provider 영역.

언제 OpenFeature를 안 끼고 가도 되나: 작은 팀, 단일 벤더 확정, 빠른 입문이 절대 우선일 때. 그 외에는 거의 모든 신규 프로젝트에서 OpenFeature SDK를 입구로 두고 그 뒤에 provider를 꽂는 것이 2026년의 디폴트가 되었다.

3장 · LaunchDarkly — 엔터프라이즈 리더

LaunchDarkly는 2014년 창업, 피처 플래그 매니지드 SaaS의 사실상 원조이자 엔터프라이즈 디폴트다. 2026년 현재 Fortune 500 다수가 사용하고, SOC2·HIPAA·BAA·FedRAMP·SAML SSO·SCIM 같은 엔터프라이즈 체크리스트를 가장 잘 채운다.

LaunchDarkly의 강점:

SDK 매트릭스가 가장 넓다 — Node/TS/Go/Java/Python/Ruby/.NET/PHP/Rust/Erlang/Elixir/Swift/Kotlin/Flutter/React/Vue/Angular/iOS/Android/Edge Workers.
클라이언트 사이드 안전성 — server-side 평가, edge relay proxy, "프라이빗 attributes"로 PII가 콘솔에 안 새도록.
권한·승인 워크플로우 — 누가 어떤 환경에서 어떤 플래그를 켤 수 있는지 RBAC, approvals, 변경 요청.
audit log·compliance — 모든 변경이 누가/언제/왜를 남김.
실험(Experimentation) — 자체 통계 엔진(베이지안 + frequentist), CUPED, sequential testing 지원.
enterprise 통합 — Datadog·Slack·Jira·ServiceNow·Terraform provider까지.

전형적인 LaunchDarkly 사용:

import * as LDClient from 'launchdarkly-node-server-sdk'

const ldClient = LDClient.init(process.env.LD_SDK_KEY!)
await ldClient.waitForInitialization()

const context = {
  kind: 'user',
  key: userId,
  plan: user.plan,
  country: user.country,
}

const variant = await ldClient.variation('checkout-redesign', context, 'control')

switch (variant) {
  case 'treatment-a':
    return <CheckoutA />
  case 'treatment-b':
    return <CheckoutB />
  default:
    return <CheckoutControl />
}

단점: 가격(MAU·플래그 수 기반으로 빠르게 비싸짐), SaaS 의존(셀프 호스팅 옵션이 있긴 하나 별도 계약), 작은 팀에는 과한 기능 셋.

언제 LaunchDarkly: 엔터프라이즈, 규제 산업(금융·헬스), 다수 환경·다수 SDK·승인 워크플로우 필요, 예산 여유.

4장 · Statsig — flags + 실험 + 분석

Statsig는 2021년 Meta에서 스핀오프한 팀이 만든 매니지드 SaaS다. 처음부터 "피처 플래그와 실험과 분석을 한 제품에 묶는다" 는 결로 출발했다. 2026년 현재 OpenAI·Notion·Atlassian·Figma·Whatnot 같은 빠르게 성장하는 스타트업/스케일업이 광범위하게 사용한다.

Statsig의 차별점:

gate(불리언 플래그) + experiment(A/B) + dynamic config(런타임 설정) + holdout 같은 1급 컨셉.
자체 통계 엔진 — frequentist(t-test·delta method) 기본, sequential testing, CUPED, 표본 비율 mismatch(SRM) 자동 감지.
이벤트 자체 수집 — 자체 분석/이벤트 파이프라인이 있어서 "flag 평가 + 노출 + 메트릭"이 한 시스템 안에 묶임.
무료 tier가 후하다 — 월 100만 이벤트까지 무료, 스타트업이 시작하기 쉬움.
Pulse — production에서 흥미로운 메트릭 변화를 자동 감지해서 알림.

전형적인 Statsig 사용:

import { Statsig } from 'statsig-node'

await Statsig.initialize(process.env.STATSIG_SERVER_KEY!)

const user = { userID: userId, email: user.email, country: user.country }

if (await Statsig.checkGate(user, 'new_checkout_enabled')) {
  // gradual rollout
}

const experiment = await Statsig.getExperiment(user, 'checkout_redesign_v2')
const layout = experiment.get('layout', 'vertical')
const buttonColor = experiment.get('button_color', 'blue')

await Statsig.logEvent(user, 'checkout_completed', orderTotal, { variant: layout })

Holdout — Statsig에서 가장 자주 언급되는 기능. "장기적으로 어떤 사용자 그룹에는 실험 변경을 일절 적용 안 하고", 분기마다 그 그룹과 나머지의 메트릭 차이를 봐서 누적 효과(or 회귀)를 측정한다. 단일 실험은 통계적으로 유의해도, 누적되면 어떤 영향인지는 holdout으로만 보인다.

언제 Statsig: 빠르게 성장하는 제품팀, 실험을 매주 여러 개 돌리고, "플래그 + 메트릭 + 분석"이 한 도구에 묶이는 결이 좋을 때. Meta의 internal tool과 결이 가장 비슷하다.

5장 · GrowthBook (오픈소스) — Series Seed

GrowthBook는 2020년 오픈소스로 시작한 실험 플랫폼이다. MIT 라이선스 + Y Combinator + Series Seed. "오픈소스 진영의 실험 플랫폼" 자리에서 가장 빠르게 자리를 굳혔다.

GrowthBook의 결:

데이터 웨어하우스 기반 실험 — 메트릭을 자체 수집하지 않고 BigQuery·Snowflake·Redshift·ClickHouse·Postgres·MySQL·Databricks 등 우리 웨어하우스에서 직접 SQL로 가져온다.
베이지안 + frequentist 통계 엔진 — 둘 다 지원, 베이지안이 디폴트.
셀프 호스팅 첫 번째 — docker compose up 한 번으로 떠짐. SaaS는 부가.
flag + experiment 둘 다 — 단순 플래그 토글부터 풀 실험 분석까지.
시각화 — uplift·신뢰구간·time-series·dim별 breakdown이 깔끔하게 보임.

전형적인 GrowthBook 사용(JS):

import { GrowthBook } from '@growthbook/growthbook'

const gb = new GrowthBook({
  apiHost: 'https://gb.example.com',
  clientKey: process.env.GB_CLIENT_KEY!,
  attributes: { id: userId, country: user.country },
})

await gb.loadFeatures()

const showNewCheckout = gb.isOn('new-checkout')

const experiment = gb.evalFeature('checkout-redesign')
const variant = experiment.value // 'control' | 'treatment-a' | 'treatment-b'

gb.trackingCallback = (experiment, result) => {
  analytics.track('experiment_viewed', {
    experimentId: experiment.key,
    variationId: result.variationId,
  })
}

데이터 웨어하우스 기반이라는 결이 핵심이다. Statsig은 자체 이벤트 파이프라인을 갖지만, GrowthBook은 "우리는 metric 수집 안 한다, 너희 웨어하우스에 이미 있는 이벤트 위에서 분석한다"는 입장. 그래서 데이터 거버넌스가 깔끔하고, 이미 dbt/Airflow로 만든 메트릭을 그대로 가져다 쓰면 된다.

언제 GrowthBook: 이미 자체 데이터 웨어하우스 + 분석 파이프라인이 있고, 거기에 실험 레이어를 얹고 싶을 때. OSS + 셀프 호스팅 선호. 데이터 팀과 실험 팀의 협업이 핵심일 때.

6장 · Unleash — 노르웨이 오픈소스

Unleash는 노르웨이에서 시작한 오픈소스 피처 플래그 플랫폼이다. 2014년부터, Apache 2.0 라이선스. 2026년 현재 OSS 진영에서 GrowthBook과 함께 가장 자주 거론되지만, 결은 다르다 — Unleash는 "엔터프라이즈 친화 OSS" 라는 위치.

Unleash의 결:

셀프 호스팅이 1급 시민 — Docker/Helm/Terraform 다 공식.
enterprise 기능을 OSS에도 많이 풀어놨다 — 환경 분리, 프로젝트 단위 권한, audit log, change requests(요청·승인 워크플로우)까지 OSS에서.
strategies — 단순 boolean 외에 gradual rollout, userId 기반, custom 전략 같은 구성을 콘솔에서.
edge proxy — Unleash Edge라는 별도 컴포넌트로 클라이언트 평가를 데이터센터/edge에 가까이 가져옴.
다국적 채택 — 노르웨이 정부, 핀란드 정부, BMW, Audi, Lufthansa 같은 EU 엔터프라이즈 사용 사례가 많음.

전형적인 Unleash 사용:

import { initialize } from 'unleash-client'

const unleash = initialize({
  url: 'https://unleash.example.com/api/',
  appName: 'web-checkout',
  customHeaders: { Authorization: process.env.UNLEASH_API_TOKEN! },
})

unleash.on('ready', () => {
  const enabled = unleash.isEnabled('new-checkout', {
    userId: userId,
    properties: { plan: user.plan, country: user.country },
  })

  const variant = unleash.getVariant('checkout-experiment', { userId })
  // variant.name: 'control' | 'a' | 'b' | 'disabled'
})

SaaS vs OSS의 경계가 흐릿하다는 점이 Unleash의 특이점이다. Unleash Enterprise는 SaaS로도 제공하지만, OSS에 풀린 기능 폭이 큰 편이라 "self-host + OSS"만으로도 상당히 멀리 갈 수 있다. EU GDPR/데이터 주권을 신경 쓰는 정부·금융·제조 도메인에서 특히 자주 채택된다.

언제 Unleash: 엔터프라이즈 친화 기능이 OSS로 필요할 때, EU/규제 산업, self-host 의무. GrowthBook이 "실험에 강한 OSS"라면 Unleash는 "플래그 운영에 강한 OSS".

7장 · ConfigCat / Flagsmith / Split — 그 외

ConfigCat — 헝가리 팀이 만든 단순한 매니지드 SaaS. "피처 플래그 = 그냥 토글" 이라는 결로, 실험 기능을 의도적으로 빼고 가격을 저렴하게 가져간다. 무료 tier가 후하고(월 1000만 평가), targeting·gradual rollout·환경 분리 같은 기본기는 다 있다. SDK도 20+ 언어 지원. "실험은 다른 도구로, 플래그만 있으면 된다"는 팀에게 매력적.

Flagsmith — 영국 팀의 OSS(BSD-3) + SaaS. Unleash·GrowthBook과 결이 비슷하지만 API/headless 우선이 차별점. REST + GraphQL + SDK + Terraform provider가 1급. self-host도 docker compose 한 번. PostHog·Segment·Datadog·Slack 같은 도구와 통합이 깔끔.

Split — 2015년 창업, 실험 + 플래그를 같이 묶은 초기 매니지드 SaaS. 2024년 Harness에 인수되어 Harness Feature Management & Experimentation으로 합쳐졌다. 2026년 현재 Split을 따로 평가하기보다, Harness 플랫폼의 한 모듈로 보는 게 자연스럽다. CI/CD·deploy verification과 한 도구에 묶인다는 점이 가장 큰 장점.

AB Tasty — 프랑스의 매니지드 SaaS, 마케팅/제품팀 친화. 2024년 Insight Partners 다수 지분 인수, 2024년 9월 DEPT 디지털 에이전시에 인수. 2026년 현재 marketing experimentation에 가까운 결이고, 엔지니어 1급 사용자는 LaunchDarkly·Statsig 쪽이 더 익숙.

Optimizely Rollouts — Optimizely(전 Web Experimentation 리더)가 무료 피처 플래그 제품으로 내놓은 결. 실험은 유료 제품 쪽에서, 단순 플래그는 Rollouts로. 2026년 현재 마케팅 친화 실험 + 엔지니어 친화 플래그를 같이 쓰고 싶은 큰 조직에서 자주 보임.

8장 · PostHog — 올인원 (analytics + flags + replay)

PostHog는 2020년 시작한 OSS(MIT 코어) 제품 분석 플랫폼이다. analytics + funnel + retention + session replay + feature flags + experiment + surveys + data warehouse + LLM observability까지 한 제품에 다 넣는 결. 2026년 현재 YC top company 한 자리를 차지하고, 매니지드 SaaS + 셀프 호스팅 둘 다 1급.

피처 플래그 관점의 PostHog:

analytics와 같은 평면 위의 토글 — 플래그를 켜면 그 즉시 "분석 이벤트와 묶어서" 코호트·funnel·retention·replay를 볼 수 있다.
flag → 실험 → 메트릭 → 결정의 흐름이 한 도구에서.
session replay와 결합 — 신기능 켠 사용자의 실제 클릭 패턴을 그대로 볼 수 있다.
LLM observability(LLM 분석) — 2025~2026년 추가, 프롬프트별 latency/비용/결과 추적도 같은 평면에서.
무료 tier가 매우 후하다 — 월 100만 이벤트, 100만 플래그 호출까지.

전형적인 PostHog 사용:

import { PostHog } from 'posthog-node'

const client = new PostHog(process.env.POSTHOG_KEY!, { host: 'https://app.posthog.com' })

const enabled = await client.isFeatureEnabled('new-checkout', userId, {
  groups: { organization: orgId },
  personProperties: { plan: user.plan, country: user.country },
})

const variant = await client.getFeatureFlag('checkout-redesign', userId)
// variant: 'control' | 'treatment-a' | 'treatment-b'

client.capture({
  distinctId: userId,
  event: 'checkout_completed',
  properties: { variant, orderTotal },
})

PostHog의 결정적 매력은 "한 제품으로 다 된다" 이다. 작은 팀은 Mixpanel + LaunchDarkly + Optimizely + Hotjar + Datadog LLM을 다 따로 사는 대신 PostHog 하나로 시작할 수 있다. 단점: 분석/replay/flags 각 영역에서 단일 전문 도구(Amplitude·Mixpanel·LaunchDarkly·FullStory)만큼 깊지는 않을 수 있다 — "퍼져 있지만 적당히 깊은" 결.

언제 PostHog: 스타트업·스케일업, 분석/replay/flags가 처음부터 한 제품에 있으면 좋겠다, OSS/self-host 옵션도 필요. 2026년 신규 SaaS 스타트업의 가장 흔한 디폴트 중 하나.

9장 · DevCycle / Hypertune (TS) / Eppo / Bucketeer

이 그룹은 "특정 결로 차별화"한 후발 주자들.

DevCycle — 2023년 Taplytics에서 리브랜드. edge 평가가 1급 — Cloudflare Workers·AWS Lambda@Edge·CloudFront Functions에서 평가가 mSec 단위로 끝난다. SDK는 자동 동기화로 평가 자체가 로컬에서 일어남(네트워크 라운드트립 없음). 모바일·edge·serverless 환경에서 가장 자주 거론되는 매니지드 SaaS.

Hypertune — TypeScript 타입 안전이 1급 차별점. 플래그 정의가 그대로 TS 타입으로 생성되어, flags.checkout.layout처럼 dot-access로 쓰면 IDE 자동완성과 타입 체크가 즉시 작동한다. Vercel 출신 팀이 만들었고, Next.js + TS 풀스택 팀에 특히 강하게 다가간다. 단순 boolean 토글을 넘어 구조화된 config(객체·중첩 enum) 를 타입 안전하게 다루는 결.

// Hypertune은 codegen으로 이런 타입을 생성
import { createHypertune } from './generated/hypertune'

const hypertune = createHypertune(/* ... */)

const layout = hypertune.checkout({ user }).layout()
// 'vertical' | 'horizontal' (enum 타입)
const buttonColor = hypertune.checkout({ user }).buttonColor()
// 'blue' | 'green' | 'red'

Eppo — 실험 first 매니지드 SaaS. GrowthBook과 결이 비슷하게 "데이터 웨어하우스 위의 실험"이지만 SaaS. CUPED·sequential·SRM·heterogeneous treatment effect 같은 고급 통계가 1급. Airbnb·Stitch Fix 출신이 만들었고, "데이터 사이언티스트가 실험을 깊게 분석하는" 결.

Bucketeer — CyberAgent(일본)에서 사내 도구로 만들다 2022년 Apache 2.0으로 공개. 셀프 호스팅 OSS. "일본의 LaunchDarkly" 같은 위치이고, 일본 엔터프라이즈/게임 산업에서 채택 사례가 있다. OpenFeature provider 공식 지원.

10장 · Vercel Edge Flags / Cloudflare Workers

Vercel — 자체 호스팅이 아니라 adapter 모델을 택했다. @vercel/flags라는 얇은 라이브러리 + Edge Config(글로벌 read-optimized KV)로, 어떤 플래그 벤더(LaunchDarkly·Statsig·Hypertune·Optimizely 등)든 Vercel adapter를 통해 Edge 함수에서 mSec 단위 평가가 가능해진다. 2025년 안정화, 2026년 Next.js 풀스택 팀의 디폴트 패턴이 되어가고 있다.

// app/page.tsx
import { flag } from '@vercel/flags/next'

const showNewCheckout = flag({
  key: 'new-checkout',
  decide: async () => {
    const ld = await getLaunchDarklyClient()
    return ld.variation('new-checkout', context, false)
  },
})

export default async function Page() {
  const enabled = await showNewCheckout()
  return enabled ? <NewCheckout /> : <LegacyCheckout />
}

Cloudflare Workers — Cloudflare 자체로는 매니지드 플래그 제품이 없다(2026년 5월 기준). 대신 Workers KV + D1 + Durable Objects를 조합해서 직접 만드는 패턴이 흔하고, Statsig·LaunchDarkly·DevCycle·Flagsmith의 Workers 어댑터를 통한 평가도 표준. Hyperdrive + Workers Analytics Engine이 실험 분석에 깔리는 결도 보이기 시작.

핵심 아이디어: edge에서의 평가는 mSec 단위여야 한다. 사용자 요청 → edge → 플래그 평가 → 응답 분기까지가 한 region 안에서 끝나야 한다. 이걸 위해 SDK들은 "플래그 정의를 미리 동기화 → 평가는 100% 로컬"로 동작하는 게 디폴트. 평가 자체에 외부 API 호출이 끼면 안 된다.

11장 · 패턴 — kill switch / gradual rollout / A/B / multi-arm bandit / holdout

도구를 골랐다면 그 다음은 패턴이다. 2026년 현재 실무에서 가장 자주 쓰이는 다섯 가지.

1) Kill switch (운영 안전망)

가장 단순하고 가장 중요한 패턴. 새 기능을 켜고 모니터링하다가 문제가 보이면 즉시 끈다. 이건 실험이 아니다 — 운영 사고 대응이다.

운영 룰: 모든 새 기능은 최소 첫 1~4주는 kill switch 뒤에 있어야 한다.
가드: SRE/on-call이 PM/엔지니어 승인 없이도 끌 수 있도록 권한 분리.
모니터링: 플래그 켜진 사용자의 에러율·latency·conversion이 자동 알람과 묶여 있어야.

2) Gradual rollout (점진 출시)

% 기반으로 천천히 트래픽을 늘린다. 1% → 5% → 10% → 25% → 50% → 100%. 각 단계 사이에 canary 기간을 두고 메트릭이 정상인지 확인.

userId·sessionId·deviceId 기반의 결정적 해싱 — 같은 사용자는 항상 같은 그룹.
"전체의 5%"가 아니라 "신규 가입자의 5%부터" 같은 segmentation이 흔함.
targeting 룰: country·plan·platform·app version으로 한정.

3) A/B 테스트 (가설 검증)

두(혹은 더 많은) 변형이 메트릭에 미치는 인과 효과를 측정한다. 단순 rollout과 본질적으로 다른 건 — A/B는 통계적 결론을 내려는 시도다.

사전 설계: hypothesis·primary metric·secondary metrics·MDE(minimum detectable effect)·sample size·duration.
실행 중 hygiene: SRM(sample ratio mismatch) 자동 감지, peeking 자제(sequential testing이 도와줌).
의사 결정: lift + 신뢰구간 + business impact 트리plet으로.

4) Multi-arm bandit (적응적 탐색)

A/B와 다른 결. 고정된 비율로 끝까지 가는 대신, 잘하는 arm에 점점 더 많이 배정한다. Thompson sampling이 가장 흔한 알고리즘.

언제 좋은가: 단기 의사 결정(headline·thumbnail·푸시 알림), 명확한 단일 메트릭, 빠른 피드백.
언제 나쁜가: 장기 효과를 봐야 하는 변경(가격·온보딩 흐름), heterogeneous treatment effect 보고 싶을 때.
도구: Statsig·Eppo·LaunchDarkly·GrowthBook 모두 bandit 모드 지원.

5) Holdout (누적 효과 측정)

일부 사용자 그룹에는 모든 실험 변경을 일절 적용하지 않는다. 분기마다 그 그룹과 나머지의 메트릭 차이를 봐서 "지난 분기 우리가 친 변경들의 누적 효과"를 본다.

왜 필요한가: 개별 실험은 다 +0.5% lift였는데, 분기 끝에 보니 retention이 떨어졌다? 개별 실험 검증으로는 안 보이는 시스템 효과를 잡아낸다.
운영: 1~5%의 사용자를 분기 시작에 무작위로 골라 모든 실험에서 제외.
도구: Statsig·LaunchDarkly·Eppo가 holdout을 1급 기능으로 지원.

12장 · 한국 / 일본 — 토스, 카카오, 메르카리

해외 SaaS만 보면 그림이 절반이다. 한국·일본 빅테크의 실제 사용 패턴.

한국 — 토스

토스(비바리퍼블리카) 는 사내 피처 플래그 시스템을 자체 구축한 것으로 알려져 있다. 토스 SLASH 컨퍼런스 발표·기술 블로그에 따르면:

트래픽 분기 결정(gradual rollout·A/B)을 위해 자체 트래픽 분기 시스템 운영.
결제·송금처럼 금융 도메인 특유의 안전성 요구 — 잘못된 분기는 즉시 사고로 이어지므로 권한·승인·audit이 매우 엄격.
데이터 인프라(자체 사내 분석 시스템)와 결합해서, 플래그 평가 + 노출 + 메트릭이 한 흐름에.

토스의 결은 "규제 산업의 자체 구축 + 데이터팀과 깊은 통합" 으로 요약 가능. 외부 SaaS를 도입하기보다 자체적으로 만든 결.

한국 — 카카오

카카오는 여러 사업부가 있어 일률적이지 않지만, 카카오 if/kakao 컨퍼런스와 카카오 기술 블로그에서 다음과 같은 흐름이 확인된다:

사내 피처 플래그 게이트웨이 패턴 — 마이크로서비스 앞단에서 플래그 평가를 통일.
카카오톡·카카오페이·카카오모빌리티 같은 대규모 서비스의 A/B 인프라가 사내에서 발표된 적 있음.
일부 사업부는 PostHog/LaunchDarkly 같은 외부 SaaS와 자체 구축을 병행하는 결.

큰 조직답게 사업부별 도구 선택이 다르고, 사내 공통 게이트웨이가 그 위에 깔리는 구조.

일본 — 메르카리

メルカリ(Mercari) 는 자사 엔지니어링 블로그에서 피처 플래그 운영을 비교적 자세히 공개한 사례가 있다:

LaunchDarkly를 한 시기 사용했다고 알려져 있고, 일부 도메인에선 자체 구축으로 전환한 흐름도.
Microservices 환경에서 플래그 평가가 마이크로서비스 간 일관성을 깨지 않도록 하는 패턴 — 한 요청 안에서 같은 플래그를 여러 서비스가 평가해도 같은 결과가 나오게.
데이터 거버넌스 + 인앱 실험 + 마이크로서비스가 만나는 결로, 자체 구축이 점점 더 자연스러워진 사례.

또한 Bucketeer(CyberAgent) 가 일본 컨퍼런스에서 자주 거론되는 것도 일본 시장의 특징 — 일본 발 OSS가 일본 엔터프라이즈에서 OpenFeature provider로 채택되는 흐름.

공통 패턴: 한국·일본 빅테크는 외부 SaaS만 쓰지 않는다. 자체 구축 또는 OSS self-host를 mix하고, 데이터 거버넌스·승인 워크플로우·도메인 특성(금융·전자상거래·통신)에 맞게 커스터마이즈한다. OpenFeature 표준이 이런 mix 환경에서 가장 빛난다 — 외부 SaaS · 자체 구축 · OSS 사이를 같은 SDK로 묶을 수 있다.

13장 · 누가 무엇을 골라야 하나 — 작은 팀 / 그로스 / 엔터프라이즈 / 셀프호스팅

도구 비교는 끝났다. 우리 팀에 맞는 답.

작은 팀(5~20명) — 단일 제품, 빠른 시작

첫 번째 추천: PostHog — analytics + flags + replay 한 번에. 무료 tier가 후하고, 작은 팀이 도구 5개 운영할 여력이 없다.
OpenFeature는 끼우는 게 좋다 — 작은 팀일수록 미래에 벤더 갈아 끼울 가능성이 크다.
벤더 락인 걱정 없으면 Statsig — 무료 tier가 후하고, 실험을 매주 돌릴 때 결이 잘 맞는다.
단순 토글만 필요하면 ConfigCat — 가격이 매우 저렴, 실험 없이 플래그만.

성장 단계(20~200명) — 실험 문화

실험을 매주 다수 돌린다면: Statsig — flags + 실험 + 분석이 한 도구에 묶이는 결.
데이터 웨어하우스 첫째라면: GrowthBook 또는 Eppo — 메트릭이 이미 BigQuery/Snowflake에 있을 때.
Next.js + TS 풀스택이라면: Hypertune + Vercel Edge Flags — 타입 안전과 edge 평가가 핵심.
여전히 OpenFeature 적극 활용 — 도구가 바뀔 가능성이 높은 단계.

엔터프라이즈(200명+, 규제 산업) — 권한·승인·감사

첫 번째 추천: LaunchDarkly — 엔터프라이즈 체크리스트(SOC2·HIPAA·BAA·FedRAMP·SSO·SCIM)를 가장 잘 채운다.
EU/GDPR 첫째라면: Unleash Enterprise — EU 기반, self-host 옵션 풍부.
CI/CD에 묶고 싶다면: Harness Feature Management(구 Split) — deploy + flag + verification이 한 플랫폼.
OpenFeature는 의무 — 다수 벤더가 사내에서 공존하는 게 자연스러움.

셀프 호스팅(법적/기술적 요구) — 데이터 주권

OSS first가 디폴트 — GrowthBook·Unleash·Flagsmith·Bucketeer 중 결에 맞게:
- GrowthBook — 실험 강함, 데이터 웨어하우스와 통합.
- Unleash — 플래그 운영·승인 워크플로우 강함.
- Flagsmith — API/headless 우선, 다른 도구와 통합 쉬움.
- Bucketeer — 일본 OSS, OpenFeature provider 공식.
PostHog self-host — 분석/replay도 같이 self-host 하고 싶을 때.

결정의 4가지 축

축	A 쪽	B 쪽
호스팅	SaaS(LaunchDarkly·Statsig·ConfigCat)	self-host(Unleash·GrowthBook·Flagsmith·PostHog)
범위	flags only(LaunchDarkly·ConfigCat)	플랫폼(Statsig·PostHog·GrowthBook)
데이터 모델	자체 이벤트 파이프(Statsig·PostHog)	웨어하우스 first(GrowthBook·Eppo)
친화도	마케팅/PM(AB Tasty·Optimizely)	엔지니어/데이터(LaunchDarkly·Statsig·GrowthBook)

가운데에 OpenFeature를 두면, 위의 축들이 모두 "갈아끼울 수 있는 결정"이 된다. 2026년의 디폴트는 "벤더 + OpenFeature" 이다.

에필로그 — 플래그는 운영 안전망이고, 실험은 학습 시스템이다

이 글의 한 줄 요약:

피처 플래그는 deploy와 release를 분리하는 운영 안전망이고, 실험은 가설을 데이터로 검증하는 학습 시스템이다. 둘은 보통 한 도구에 묶이지만, 우선순위는 다르다 — 플래그는 모든 팀에 필요하고, 실험은 실험 문화가 있을 때 필요하다.

2026년 현재 시장은:

LaunchDarkly — 엔터프라이즈 디폴트.
Statsig — 실험 + 플래그 + 분석 통합, 빠르게 성장하는 팀.
GrowthBook / Unleash / Flagsmith / Bucketeer — OSS 진영, 자체 호스팅과 데이터 주권.
PostHog — analytics + flags + replay 올인원.
ConfigCat / Split(Harness) / DevCycle / Hypertune / Eppo / Optimizely Rollouts / AB Tasty — 각자의 결.
OpenFeature — 위 모두를 묶는 CNCF 표준.

흔한 함정 10개:

플래그를 만들고 안 지움 — 6개월 후 1000개 flag 좀비.
kill switch 없이 신기능 출시 — 사고 시 대응이 코드 롤백뿐.
권한 분리 없이 누구나 production flag 켬 — 실수가 사고로.
SRM 무시 — 50:50인 줄 알았던 실험이 사실은 60:40.
peeking — sequential testing 없이 매일 결과를 보고 결정.
단일 실험 결과로 영구 결정 — holdout으로 누적 효과 확인 안 함.
플래그 평가에 외부 API 호출 — latency 폭발.
PII가 flag 평가 context에 그대로 들어감 — 콘솔에 노출.
한 벤더에 강하게 락인 — 갈아끼울 때 코드를 다 고침(OpenFeature 안 씀).
실험 가설/메트릭 사전 정의 없이 시작 — 결과를 보고 가설을 만듬(HARKing).

다음 글 예고

다음 글 후보: OpenFeature 깊게 파기 — provider 직접 만들기, 실험 통계 깊게 파기 — CUPED·sequential·SRM, kill switch + canary + SRE on-call 묶기.

"deploy는 코드를 옮기는 것, release는 사용자에게 켜는 것. 그 사이의 거리를 좁히면서도 안전하게 만드는 게 피처 플래그의 일이다."

— 피처 플래그 & 실험 플랫폼 2026, 끝.