---
id: feature-flag
title: "Feature Flag"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["Feature Flagging"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.85
created_at: 2026-06-12
updated_at: 2026-06-12
review_reason: ""
merge_history: []
tags: ["research", "Assumption Validation Loop"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: []
github_commit: ""
---

# [[Feature Flag]]

## 🎯 한 줄 통찰 (One-line insight)
전체 사용자 기반에 대한 리스크를 최소화하면서 특정 세그먼트의 실시간 반응을 통해 가설을 검증하게 하는 점진적 기능 노출 및 실험 제어 기술 [1, 2].

## 🧠 핵심 개념 (Core concepts)
- **가설 기반 배포 (Hypothesis-based Deployment):** 모든 기능을 확정된 결과물이 아닌 하나의 가설로 취급하여, 엔지니어링 리소스를 본격적으로 투입하기 전 실험의 형태로 배포함 [3, 4].
- **점진적 롤아웃 (Gradual Rollouts):** 새로운 기능이나 변경 사항을 한꺼번에 공개하지 않고, 특정 사용자 또는 세그먼트에만 활성화하여 단계적으로 확장함 [2, 5].
- **실시간 리스크 제어 (Real-time Risk Mitigation):** 기능 노출을 코드가 아닌 플래그 설정을 통해 제어함으로써, 부정적인 지표가 발견될 경우 전체 시스템에 영향 없이 즉각적으로 기능을 비활성화함 [1].
- **타겟 피드백 수집 (Targeted Feedback Collection):** 특정 사용자 그룹을 대상으로 기능을 우선 공개하여 해당 그룹의 성능 데이터와 행동 피드백을 집중적으로 분석함 [2].

## 🧩 추출된 패턴 (Extracted patterns)
- **디지털 MVP 전략 패턴:** 가설 검증을 위한 디지털 MVP(Digital MVP)의 한 형태로서, 실제 제품 환경 내에서 저비용으로 실험을 수행하는 도구로 활용됨 [5, 6].
- **개발 중 검증 패턴 (During Development Validation):** 개발 프로세스 중간에 삽입되어, 정식 출시 전 베타 테스팅(Beta Testing)과 유사하게 소규모 통제 그룹에서 성능과 사용성을 미리 검증하는 패턴임 [2].

## 📖 세부 내용 (Details)
- **실험 도구로서의 역할:** Feature Flag는 [[A/B Testing]] 및 단계별 배포와 결합되어 사용된다 [1]. 이를 통해 제품 팀은 전체 사용자에게 리스크를 전이시키지 않고 새로운 기능의 임팩트를 정밀하게 측정할 수 있다 [1].
- **린 제품 관리(Lean Product Management)의 핵심:** 린 제품 관리 프레임워크 내에서 Feature Flag는 '구조화된 실험(Structured Experimentation)'의 일환으로 간주된다 [3]. 이는 팀이 단순한 기능 출력이 아닌, 측정 가능한 사용자 행동의 변화나 비즈니스 성과(Outcomes)에 집중하게 만든다 [3].
- **구현 방식:** 새로운 기능이나 코드 변경 사항을 배포 시스템에 포함시키되 대부분의 사용자가 접근할 수 없도록 숨긴 상태로 유지하며, 운영 단계에서 동적으로 이를 활성화한다 [2].
- **측정 및 학습:** 배포 후에는 활성화된 세그먼트의 활성화(Activation), 유지(Retention), 전환(Conversion) 등의 지표를 모니터링하여 가설의 성패를 판단하며, 이 데이터는 다음 의사결정(Pivot/Persevere)의 근거가 된다 [1, 7].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- 소스 내에서 상충되는 정보는 발견되지 않았으나, Feature Flag가 단순한 기술적 '온/오프 스위치'를 넘어 [[Assumption Validation Loop]]를 구성하는 전략적 '실험 엔진'으로 격상되어 설명되고 있음이 확인됨 [1, 3].

## 🛠️ 적용 사례 (Applied in summary)
- 현재 소스 데이터 내에서 특정 코드베이스나 프로젝트 명칭이 명시된 구체적인 적용 사례는 발견되지 않았습니다.

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
- **출처 신뢰도:** B (Lean Product Management 및 MVP 검증 가이드 기반)
- **중복 검사 결과:** 신규 생성 (New discovery)

## 🔗 관련 문서 링크 (Related document links)

### 상위/유사 개념
#### [가설 검증 프레임워크]
- [[Assumption Validation Loop]]
  - 연결 이유: Feature Flag는 가설을 검증하는 루프 시스템 내의 실행 단계에서 필수적인 도구임 [8].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 실험 결과가 어떻게 다시 가설 수립 단계로 피드백되는지 이해 가능.
- [[Minimum Viable Product]]
  - 연결 이유: Feature Flag는 고충실도(High-fidelity) 디지털 MVP를 구현하는 주요 기술 중 하나임 [5, 6].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: '최소(Minimum)'의 범위를 유지하며 '실행 가능성(Viable)'을 테스트하는 방법론.

#### [실험 방법론]
- [[A/B Testing]]
  - 연결 이유: Feature Flag는 A/B 테스트를 기술적으로 구현하고 통제하는 기반 기술임 [1].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대조군과 실험군을 나누어 데이터의 통계적 유의미성을 확보하는 원리.

### 심층 후속 질문 (Deeper Research Questions)
- Feature Flag 관리에 따른 기술적 부채(Technical Debt)를 방지하기 위해 검증이 끝난 플래그를 제거하는 최적의 주기는 어떻게 되는가? [9, 10]
- 복잡한 마이크로서비스 아키텍처에서 여러 서비스에 걸친 Feature Flag의 일관성을 어떻게 유지하는가? [11]
- Feature Flag 실험에서 통계적 유의미성을 확보하기 위한 최소 사용자 세그먼트 크기는 어떻게 산출하는가? [12]
- 사용자에게 노출되는 'Aha Moment'를 해치지 않으면서 Feature Flag 기반 실험의 '최소 생생함(Viability)'을 어떻게 정의하는가? [13]

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** 특정 사용자 속성(예: 가입 기간, 지역)에 따른 동적 기능 활성화 로직 설계.
- **System Design:** 배포와 노출을 분리하는(Decouple Deployment from Release) 시스템 아키텍처 구축.
- **Operation / Maintenance:** 기능 배포 후 실시간 대시보드를 통한 지표 모니터링 및 비상 시 킬 스위치(Kill Switch) 운영.
- **Learning Path:** 린 스타트업의 Build-Measure-Learn 루프 중 'Measure' 단계의 효율을 높이는 기술적 역량 습득.

### 인접 주변 주제 (Adjacent Topics)
- [[Canary Deployment]]
  - 확장 방향: 인프라 수준에서의 단계적 배포 기법과의 차이점 및 결합 방안 연구.
- [[Staged Rollouts]]
  - 확장 방향: 운영 안정성 확보를 위한 배포 전략으로서의 연계성 탐구.

## 📝 변경 이력 (Change history)
- 2026-06-12: Initial draft generated via Datacollector_MAC P-Reinforce engine. [1-3, 5] 참조.