Files
2nd/10_Wiki/Topics_Blog/Feature-Flags.md
T

27 lines
1.7 KiB
Markdown

---
id: P-REINFORCE-AI-FE FEATURE-FLAGS
category: "10_Wiki/💡 Topics/AI"
confidence_score: 0.98
tags: [DevOps, FeatureFlags, Deployment, RiskManagement]
last_reinforced: 2026-04-20
---
# [[Feature-Flags|Feature-Flags]] (피처 플래그)
## 📌 한 줄 통찰 (The Karpathy Summary)
> "배포는 하되, 보일지 말지는 스위치로 결정한다." 코드 배포와 기능 출시(Release)를 분리하여, 런타임에 동적으로 기능을 켜고 끄거나 특정 유저에게만 노출할 수 있게 하는 마법의 스위치다.
## 📖 구조화된 지식 (Synthesized Content)
- **Core Functions**:
- **Kill Switch**: 신규 기능에 치명적인 버그가 발견되면 코드 수정 없이 즉시 비활성화.
- **Canary Release**: 소수의 유저(예: 1%)에게만 기능을 먼저 공개하여 안정성 검증.
- **A/B Testing**: 동일한 기능을 두 가지 버전으로 배포하고 성과를 비교.
- **Implementation**: `if (flag('new-ui')) { ... }` 식의 조건문으로 감싸고, 중앙 서버(LaunchDarkly 등)에서 상태를 제어한다.
## ⚠️ 모순 및 업데이트 (RL Update)
- 피처 플래그를 방치하면 코드 곳곳에 조건문이 남게 되어 기술 부채(Technical Debt)가 급증한다. 기능이 성공적으로 안착했다면 즉시 플래그 코드를 지우는 '클린업 사이클'이 운영 프로세스에 반드시 포함되어야 한다. 또한 플래그 설정값 자체가 하나의 '전역 상태'이므로, 이에 대한 히스토리 관리가 필수적이다.
## 🔗 지식 연결 (Graph)
- Related: [[DevOps-and-UX-Convergence|DevOps-and-UX-Convergence]] , Continuous-Deployment
- Strategy: Trunk-Based-Development