피처 플래그를 차분히 보기

피처 플래그 (feature flag · feature toggle) 는 큰 회사 사례에서 자주 인용되는 패턴. 작은 팀에서도 같은 무게의 기대를 거는 경우가 있는데, 비용과 이득은 환경에 따라 다릅니다. 이 글은 사실 기준으로 정리.

1. 피처 플래그에 대한 이야기

코드의 분기점에 켜고 끌 수 있는 토글을 두어, 배포 (deploy) 와 출시 (release) 를 분리하는 기법. 코드는 운영에 배포돼 있지만 특정 사용자 · 조건에 한해서만 동작.

대표 도구:

• LaunchDarkly (2014, Edith Harbaugh 등) — SaaS. 가장 널리 알려진 상용.
• Unleash (2014, FINN.no 발) — 오픈소스 코어. 자체 호스팅 가능.
• Flagsmith (2018) — 오픈소스 코어 + SaaS.
• Split (2015) · GrowthBook (2020) · PostHog (피처 플래그 모듈 포함, 2020) 등.

Martin Fowler 와 Pete Hodgson 의 글 "Feature Toggles (aka Feature Flags)" (2017) 가 토글의 분류를 정리한 글로 자주 인용.

2. 토글의 분류

Hodgson 의 분류는 네 가지:

종류	수명	의도
Release toggle	짧음 (며칠 ~ 몇 주)	미완성 기능을 운영 코드에 두되 비활성. 머지 후 점진 출시.
Experiment toggle	짧음	A / B 테스트. 사용자 그룹별 다른 경로.
Ops toggle	가변	사고 시 기능 일시 차단 (killswitch).
Permission toggle	김	사용자 / 플랜별 기능 노출.

각 종류의 운영 비용이 다름. Release toggle 은 수명이 짧을수록 좋고, Permission toggle 은 사실상 권한 시스템이라 다르게 다뤄야.

3. Trunk-Based Development 와의 관계

trunkbaseddevelopment.com 은 미완성 기능을 trunk 에 두기 위해 피처 플래그를 권장. 짧은 피처 브랜치 + 플래그로 가린 미완성 코드 = 잦은 머지 + 안전한 출시.

이 조합이 큰 팀의 CI / CD 파이프라인에서 자주 채택되는 이유:

• 머지가 늦어질수록 충돌 비용이 커짐.
• 매일 머지하면 충돌이 작은 단위로 해결.
• 미완성 기능을 가리는 안전 장치가 필요하므로 플래그 도입.

4. 작은 팀에서의 비용 / 이득

피처 플래그는 코드에 분기를 더함. 분기는 다음을 부름:

• 테스트 매트릭스 증가 — 한 플래그가 두 경로를 만들고, 두 플래그가 네 경로를 만듦.
• 코드 노이즈 — if flag.is_on('x') ... 가 곳곳에 흩어짐.
• 수명 관리 — 출시가 끝난 release toggle 은 제거해야 하는데 잊히기 쉬움. LaunchDarkly 등 도구가 "stale flag" 알림을 제공하는 이유.
• 운영 의존 — 플래그 평가 서비스가 죽으면 어떻게 동작할지 미리 정해 두는 편이 안전. 보통 fallback 값을 코드에 박아 둠.

작은 팀 (개발자 5 명 이하 · 일배포 빈도 낮음 · 사용자 베이스 작음) 에서는 다음이 자주 동등 효과:

• 짧은 피처 브랜치 + PR + 빠른 머지.
• 환경변수 한두 개로 가린 단순 토글.
• 베타 사용자에게는 별도 환경 / 도메인 제공.

대규모 도구 (LaunchDarkly · Unleash) 의 풍부한 기능 (타겟팅 · 세그먼트 · A/B 통계) 이 정작 쓰이지 않는다면 비용 대비 이득이 작아진다는 평.

큰 팀에서 효과가 분명한 신호:

• 일배포 빈도가 높음 (여러 회 / 일).
• 동시에 여러 미완성 기능이 trunk 에 머지.
• 사용자 세그먼트별 점진 출시 (canary · ring) 가 일상.
• 사고 시 기능 단위 빠른 차단이 필요.

5. 다른 길

피처 플래그의 대안 또는 보완:

• 환경 분리 — dev / staging / prod 의 구분. 단순한 환경별 토글로 충분한 경우가 많음.
• 블루-그린 / 카나리 배포 — 인프라 단의 점진 출시. 코드 분기를 늘리지 않음.
• 권한 시스템 — 사용자 / 플랜별 기능 노출은 도메인 차원의 권한 모델로 다루는 편이 의미가 명확.
• 다크 런치 (dark launch) — 새 코드 경로를 운영에 두되 결과를 사용자에게 보여 주지 않고 데이터만 비교. 검증 후 활성화.

6. 자주 쓰는 모양

단순 환경변수 기반 (작은 팀):

const NEW_PRICING = process.env.FEATURE_NEW_PRICING === "1";

function priceFor(item) {
  return NEW_PRICING ? newPrice(item) : legacyPrice(item);
}

도구 기반 (LaunchDarkly 풍 SDK 의사 코드):

const showNewPricing = await client.variation("new-pricing", user, false);

7. 자주 걸리는 자리

"stale flag" 누적 — 켠 채로 잊혀진 토글은 코드를 뒤덮음. 분기마다 만들어진 두 경로가 서로 다른 방향으로 진화하면 토글 제거가 위험해짐.

토글이 권한 시스템 역할을 대신하는 사고 — 권한은 도메인 모델로 다루고, 토글은 출시 · 실험 · 사고 차단에 한정.

의존성 토글 — 한 토글이 다른 토글을 가정하면 (A 가 켜져야 B 가 의미 있음) 매트릭스가 폭발. 토글 사이의 의존을 명시적으로 문서화하거나 제거.

도구 의존 — 외부 SaaS 의 일시 장애가 운영 결정을 못하게 만드는 사고. 캐시 · 기본값 처리를 처음부터 정함.

작은 팀이 큰 팀의 사례를 그대로 가져오는 경우 — 도구의 비용 (SaaS 요금 · 운영 부담) 이 이득을 넘는 경우가 흔함.

하고픈 말

피처 플래그는 큰 팀의 CI / CD 환경에서 효과가 분명하지만, 작은 팀에서는 코드 노이즈와 운영 의존이 이득을 넘을 수 있음. "stale flag" 누적 + 매트릭스 폭발 + 권한 시스템 대용 셋의 함정이 흔함. 환경 분리 + 단순 환경변수 + 카나리 배포 같은 인프라 단 분리가 더 자연스러운 자리.

Next

• naming-readability
• (philosophy 끝)

Pete Hodgson · Martin Fowler Feature Toggles · LaunchDarkly 공식 문서 · Unleash 공식 문서 · Flagsmith 공식 문서 · Trunk-Based Development · Continuous Delivery (Humble & Farley, 2010) · GrowthBook 공식 사이트 · PostHog Feature Flags 를 참고합니다.