Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — "배포 = 릴리즈"는 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 + 갈아끼울 수 있는 백엔드"가 가능해졌다.

| 진영 | 대표 | 라이선스 | 호스팅 | 한 줄 평 |

| --- | --- | --- | --- | --- |

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 코드:

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 사용:

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 사용:

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):

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 사용:

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 사용:

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으로 이런 타입을 생성

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

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개:

1. 플래그를 만들고 안 지움 — 6개월 후 1000개 flag 좀비.

2. kill switch 없이 신기능 출시 — 사고 시 대응이 코드 롤백뿐.

3. 권한 분리 없이 누구나 production flag 켬 — 실수가 사고로.

4. SRM 무시 — 50:50인 줄 알았던 실험이 사실은 60:40.

5. peeking — sequential testing 없이 매일 결과를 보고 결정.

6. 단일 실험 결과로 영구 결정 — holdout으로 누적 효과 확인 안 함.

7. 플래그 평가에 외부 API 호출 — latency 폭발.

8. PII가 flag 평가 context에 그대로 들어감 — 콘솔에 노출.

9. 한 벤더에 강하게 락인 — 갈아끼울 때 코드를 다 고침(OpenFeature 안 씀).

10. 실험 가설/메트릭 사전 정의 없이 시작 — 결과를 보고 가설을 만듬(HARKing).

다음 글 예고

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

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

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

참고 / References

- [OpenFeature — CNCF](https://openfeature.dev/)

- [OpenFeature GitHub — open-feature/spec](https://github.com/open-feature/spec)

- [OpenFeature CNCF Incubating announcement](https://www.cncf.io/projects/openfeature/)

- [LaunchDarkly](https://launchdarkly.com/)

- [LaunchDarkly Documentation](https://docs.launchdarkly.com/)

- [Statsig](https://statsig.com/)

- [Statsig Documentation](https://docs.statsig.com/)

- [Statsig — Holdouts](https://docs.statsig.com/experiments-plus/holdouts/)

- [GrowthBook](https://www.growthbook.io/)

- [GrowthBook GitHub — growthbook/growthbook](https://github.com/growthbook/growthbook)

- [Unleash](https://www.getunleash.io/)

- [Unleash GitHub — Unleash/unleash](https://github.com/Unleash/unleash)

- [ConfigCat](https://configcat.com/)

- [Flagsmith](https://flagsmith.com/)

- [Flagsmith GitHub — Flagsmith/flagsmith](https://github.com/Flagsmith/flagsmith)

- [PostHog — Feature Flags](https://posthog.com/feature-flags)

- [PostHog GitHub — PostHog/posthog](https://github.com/PostHog/posthog)

- [Split — Now Harness Feature Management](https://www.harness.io/products/feature-flags)

- [DevCycle](https://devcycle.com/)

- [Hypertune](https://www.hypertune.com/)

- [Eppo](https://www.geteppo.com/)

- [Bucketeer GitHub — bucketeer-io/bucketeer](https://github.com/bucketeer-io/bucketeer)

- [Bucketeer — CyberAgent OSS](https://bucketeer.io/)

- [Vercel Flags SDK](https://vercel.com/docs/feature-flags)

- [Vercel Edge Config](https://vercel.com/docs/storage/edge-config)

- [Cloudflare Workers — KV](https://developers.cloudflare.com/kv/)

- [AB Tasty](https://www.abtasty.com/)

- [Optimizely Rollouts](https://www.optimizely.com/products/intelligence/rollouts/)

- [Toss SLASH Conference](https://toss.tech/slash)

- [Kakao Tech Blog](https://tech.kakao.com/)

- [Mercari Engineering Blog](https://engineering.mercari.com/en/)

- [Microsoft — Progressive Experimentation](https://learn.microsoft.com/en-us/azure/architecture/example-scenario/data/feature-flags)

- [Martin Fowler — Feature Toggles](https://martinfowler.com/articles/feature-toggles.html)

- [Statsig — CUPED](https://docs.statsig.com/stats-engine/methodologies/cuped)

- [Eppo — Sequential Testing](https://www.geteppo.com/sequential-testing)

- [Thompson Sampling — Multi-armed bandit](https://en.wikipedia.org/wiki/Thompson_sampling)