TT Lab

한국어 English 日本語

시작하기
블로그

블로그

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

2026-05-16 · 37 분 읽기 · #feature-flags#experimentation#ab-testing#launchdarkly#statsig#growthbook#unleash#configcat#flagsmith#posthog#split-io#devcycle#hypertune#openfeature#cncf#deep-dive

대화로 듣기 · 12분두 사람이 이 글을 풀어 줍니다

프롤로그 — "배포 = 릴리즈"는 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

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

3) 통합 플랫폼 진영 — PostHog

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

진영대표라이선스호스팅한 줄 평
매니지드 SaaSLaunchDarklyClosedSaaS + 셀프 옵션엔터프라이즈 디폴트
매니지드 SaaSStatsigClosedSaaSflags + 실험 + 분석 통합
오픈소스GrowthBookMITself/SaaS실험 강한 OSS
오픈소스UnleashApache 2.0self/SaaS엔터프라이즈 친화 OSS
오픈소스FlagsmithBSD-3self/SaaSAPI 우선 OSS
통합PostHogMIT (코어)self/SaaSanalytics + flags + replay
표준OpenFeatureApache 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가 표준화하는 것:

표준화하지 않는 것:

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

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

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

LaunchDarkly의 강점:

전형적인 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의 차별점:

전형적인 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의 결:

전형적인 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의 결:

전형적인 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:

전형적인 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 (운영 안전망)

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

2) Gradual rollout (점진 출시)

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

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

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

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

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

5) Holdout (누적 효과 측정)

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

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

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

한국 — 토스

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

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

한국 — 카카오

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

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

일본 — 메르카리

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

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

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

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

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

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

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

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

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

결정의 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년 현재 시장은:

흔한 함정 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

로그인하면 좋아요를 누를 수 있습니다

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다