llm-wiki/raw/company-tech-blogs/config-launchdarkly-feature-flag-best-practice.md

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed

title	source_type	url	archive_url	status	confidence	tags	related_projects	related_branches	created	last_reviewed
LaunchDarkly + Unleash — feature flag SaaS / OSS 비교 (rollout · decouple)	company-tech-blog	https://launchdarkly.com/blog/what-are-feature-flags/		reviewed	medium	ca-tmpl config feature-flag launchdarkly unleash alternative	ca-skeleton-operational-contract	feature-env-driven-runtime-configuration	2026-05-22	2026-05-27

LaunchDarkly + Unleash — feature flag 서비스 비교 자료

Layer: raw/company-tech-blogs/ — LaunchDarkly 블로그 (SaaS 마케팅 페이지) + Unleash 메인 페이지 (OSS+SaaS) 원문 발췌. ca-tmpl feature-env-driven-runtime-configuration 의 대안 5 (dedicated feature flag service) 비교 자료. company-tech-blog 등급. 공식 best practice 로 취급 금지 (자기 제품 홍보 포함).

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-env-driven-runtime-configuration	env-startup flag + registry row 1차 결정의 대안 5 (dedicated feature flag service) — runtime/canary flag 를 외부 시스템으로 위임 가능한 시점 평가 근거
raw/project-notes/ca-skeleton-operational-contract	Group G 대안 평가 — high-volume product-experimentation 영역을 ca-tmpl 이 의도적으로 다루지 않는다는 결정의 비교 baseline

컨텍스트 / 왜 저장했는지

ca-tmpl feature-env-driven-runtime-configuration branch의 대안 5. branch는 env-startup flag + registry row를 1차로 두고 runtime/canary flag는 optional로 분류했음. LaunchDarkly/Unleash는 dedicated feature flag system. branch가 어떤 기능을 직접 구현하지 않기로 결정했는지, 그리고 어떤 상황에서 외부 시스템으로 옮길 수 있는지의 비교 자료.

출처 / Source

• 원본 URL (LaunchDarkly): https://launchdarkly.com/blog/what-are-feature-flags/
• 원본 URL (Unleash): https://www.getunleash.io/
• 아카이브 URL: (미확보)
• 저자 / 조직: LaunchDarkly (SaaS, 상업 제품 마케팅 페이지) / Unleash (OSS + 상업 SaaS)
• 발행 상태: rolling docs (페이지 자체에 명시 없음)
• 신뢰도 주의: company-tech-blog 등급. 공식 best practice로 취급 금지 (자기 제품 홍보 포함). 개념 정의의 참고 자료로만 사용.
• 마지막 확인일: 2026-05-27

핵심 인용 / Key quotes (verbatim)

(LaunchDarkly 측)

[§What are feature flags? — definition] "Feature flags allow you to enable or disable a feature without modifying the source code or requiring a redeploy."

[§Decoupling deploy and release] "Feature flags change the traditional deployment workflow by decoupling deploy and release, allowing new code to exist in a production deploy but not be executed."

[§Rollout patterns] "Starting small and rolling out to larger groups over time helps you observe the behavior of the systems and services under increasing load."

(Unleash 측)

[§Unleash homepage — Open source positioning] "Unleash is the largest open source feature flagging solution built for enterprises, available on GitHub under an open-source license."

[§Unleash homepage — Edge SDK evaluation] "Unleash evaluates flags in the SDK or at the edge, not on the Unleash server. This means flag decisions happen in nanoseconds."

[2026-05-27 verified — WebFetch 재검증 성공]:

• LaunchDarkly C1 (definition): live page 본문은 "Feature flags are a software development concept that allow you to enable or disable a feature without modifying the source code or requiring a redeploy." — 위 capture quote (Feature flags allow you to...) 는 live 본문의 verbatim 부분문자열로 일치 (인용자가 sentence-initial paraphrase 한 형태). strength upgrade 가능.
• LaunchDarkly C2 (decoupling): live 페이지에 trailing clause "and, therefore, not released." 가 추가됨. 위 capture 는 verbatim 부분문자열이지만 sentence 가 잘려있음 — paraphrased 분류, 인용 시 잘림 명시 필요.
• LaunchDarkly C3 (rollout): live 페이지에서 colon + list 형태 ("...helps you: Observe the behavior of the systems and services under increasing load.") — 위 capture 는 동등한 의미의 단일 문장으로 정규화되어 있음. paraphrased 분류.
• Unleash C4 (OSS positioning): FAQ "Is Unleash open source?" 섹션에서 FOUND VERBATIM. strength upgrade 가능.
• Unleash C5 (edge SDK nanoseconds): FAQ "How does Unleash evaluate feature flags?" 섹션에서 FOUND VERBATIM. strength upgrade 가능. (참고: live 페이지에는 동일 메시지의 보조 인용 "flag decisions happen in nanoseconds with zero network latency" 도 존재)
• [2026-05-25 capture] 본 5개 quote 의 2026-05-22 capture verbatim 본문은 위와 같이 그대로 보존.

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
LD-FF-C1	feature flag 는 source code 수정 또는 redeploy 없이 기능을 enable/disable 가능	[§Defining Feature Flags, 2026-05-27 verified verbatim substring] "Feature flags [are a software development concept that] allow you to enable or disable a feature without modifying the source code or requiring a redeploy."	company-case-study [2026-05-27 verified]	LaunchDarkly 제품 시나리오. 일반화 시 별도 출처 필요 (LaunchDarkly 가 자사 마케팅 페이지에서 정의)	feature flag 의 보편적 정의가 본 인용과 동일하다는 뜻은 아님 — 공식 표준 정의는 별도
LD-FF-C2	feature flag 는 deploy 와 release 를 decouple 하여 new code 가 production deploy 에 존재하되 실행되지 않을 수 있게 함	[§Decoupling deploy from release, 2026-05-27 verified paraphrased] "Feature flags change the traditional deployment workflow by decoupling deploy and release, allowing new code to exist in a production deploy but not be executed[, and, therefore, not released]." — live 페이지에는 trailing clause "and, therefore, not released." 가 추가됨. capture 는 부분문자열 일치	company-case-study [2026-05-27 verified, paraphrased — trailing clause 누락]	LaunchDarkly 의 deployment workflow 권고. ca-tmpl 의 1차 정책 아님	"deploy ≠ release" 가 공식 best practice 라는 뜻은 아님 — company-tech-blog 의 진술이며 official-vendor-doc 으로 corroborate 되지 않음
LD-FF-C3	작게 시작하여 시간에 따라 더 큰 group 으로 rollout 하면 시스템·서비스의 load 증가 하 동작 관찰이 용이	[§De-risk software releases, 2026-05-27 verified paraphrased] live 페이지는 colon+list 형태: "Starting small and rolling out to larger groups over time helps you: Observe the behavior of the systems and services under increasing load." — capture 는 동등 의미의 단일 문장으로 정규화	company-case-study [2026-05-27 verified, paraphrased — sentence/list 구조 변경]	percentage rollout / canary 전략을 사용하는 환경	percentage rollout 의 정확한 단계 (1% → 10% → 50% 등) 가 본 인용에 명시되어 있다는 뜻은 아님 — vendor-specific 권고
LD-FF-C4	Unleash 는 GitHub 의 OSS license 하에 enterprise 를 위해 만들어진 가장 큰 OSS feature flagging solution 이라고 자사 주장	[§Unleash FAQ — Is Unleash open source?, 2026-05-27 verified verbatim] "Unleash is the largest open source feature flagging solution built for enterprises, available on GitHub under an open-source license."	company-case-study [2026-05-27 verified]	Unleash 자사 마케팅 진술	객관적 시장 점유율 / OSS feature flag tool 간 비교 결과로 입증된 사실은 아님 — vendor 자기 주장
LD-FF-C5	Unleash 는 flag 를 server 가 아닌 SDK 또는 edge 에서 평가 하므로 결정이 nanoseconds 단위로 일어난다고 자사 주장	[§Unleash FAQ — How does Unleash evaluate feature flags?, 2026-05-27 verified verbatim] "Unleash evaluates flags in the SDK or at the edge, not on the Unleash server. This means flag decisions happen in nanoseconds."	company-case-study [2026-05-27 verified]	Unleash SDK 사용 시	"nanoseconds" 가 모든 워크로드에서 측정된 latency 라는 뜻은 아님 — vendor 마케팅 단위, 별도 벤치마크 필요

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • LD-FF-C1~C5: LaunchDarkly / Unleash 자사 페이지의 5가지 진술 (정의 / decouple / rollout / OSS positioning / edge SDK)
• 이 자료가 증명하지 않는 것:
  • "deploy ≠ release" 가 공식 best practice 라는 단정 — 본 자료는 company-tech-blog 등급이며 official-standard / official-vendor-doc / official-reference 로 corroborate 되지 않음. UNSUPPORTED_DECISION 으로 분류해야 정확
  • feature flag 의 보편적 정의 (CNCF / IEEE / ACM 등 표준화 단체의 정의 부재)
  • percentage rollout 의 권장 단계 (1% → 10% → 50% 등 vendor-specific 권고)
  • SaaS pricing 모델 (MAU/seat 기반) 의 정확한 가격 (변경 잦음)
  • flag lifecycle (생성 → 측정 → 회수) 의 의무화가 모든 환경에 보편적이라는 점
  • Unleash 가 OSS feature flag tool 중 시장 점유율 1위라는 객관적 검증
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • ca-tmpl 의 env-startup flag + registry row 정책이 dedicated feature flag service 로 마이그레이션 되어야 하는 임계점 (active flag 수, product team 의 deploy independence 요구)
  • fallback / cache 정책 (external feature flag service outage 시 동작 정의)
  • registry 의 owner_branch 패턴이 LaunchDarkly / Unleash 의 flag metadata 와 어떻게 매핑되는지

메모 / Notes (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 적용 컨텍스트 해석.

• 적용 시나리오: A/B testing, percentage rollout, user-targeting, kill switch가 business 요구로 등장하는 단계. 보통 50+ active flag 또는 product team이 backend 배포 없이 toggle을 직접 운영해야 하는 단계.
• 장점:
  • LaunchDarkly: SaaS UI / 권한 관리 / audit / experimentation 통합.
  • Unleash: OSS self-host 가능 (Docker), edge SDK evaluation으로 low latency.
  • 둘 다 deploy ≠ release 분리를 1급 시민으로 다룸.
• 단점:
  • 외부 의존: flag eval이 외부 시스템에 의존. fallback / cache 정책 필수. service degradation 시 동작 정의 필요.
  • cost: LaunchDarkly는 MAU/seat 기반 과금이 빠르게 비싸짐. Unleash는 self-host 운영 부담.
  • debt: 단순 on/off용 flag가 너무 늘면 코드 분기 폭증. flag lifecycle (생성 → 측정 → 회수) 의무화 필요.
• ca-tmpl 결정과의 차이:
  • ca-tmpl: env-startup flag + registry row + owner_branch 강제. runtime flag는 optional.
  • LaunchDarkly/Unleash: runtime flag 1차, targeting/segment/percentage가 core feature.
  • 즉 ca-tmpl이 의도적으로 "low-volume, infra-mode-switch" 영역만 다루고, "high-volume, product-experimentation" 영역은 외부 시스템으로 위임 가능하다고 본 것.
• 채택 시점 후보: product team이 backend 배포 사이클과 독립적으로 feature를 on/off 해야 할 때.
• 회수 의무: LaunchDarkly 자체 가이드도 "stale flag = tech debt"를 강조. branch의 owner_branch + registry는 이 회수 의무의 최소 단위.
• 신뢰도: company-tech-blog 등급. 정의/마케팅 인용은 가능하나 "이게 best practice"라는 단정은 금지. 이 자료의 어떤 주장도 official-standard / official-vendor-doc / official-reference 로 corroborate 되지 않는 한 best practice 로 인용 금지.

Related / 관련

• 같은 주제 다른 raw:
  • raw/official-docs/config-12-factor-app-config
  • raw/official-docs/config-spring-cloud-config-server-official
• 인용하는 branch:
  • raw/branch-notes/feature-env-driven-runtime-configuration
• 인용하는 project:
  • raw/project-notes/ca-skeleton-operational-contract
• 대안 그룹: Group G — Env-driven runtime configuration
• 본 source의 위치: 대안 5: LaunchDarkly / Unleash (dedicated feature flag service, SaaS or OSS)
• 인용한 wiki 요약: (미작성)