핵심 요약
피처 플래그(feature flag)는 코드에 스위치를 두어, 기능을 켜고 끄는 것이다. 핵심은 "배포(deploy)"와 "출시(release)"를 분리하는 것 — 코드는 미리 배포해두되 기능은 플래그로 감춰두고, 준비되면 켠다. 문제가 생기면 코드를 되돌릴 필요 없이 플래그만 끄면 된다.
1. 왜 쓰나
- 안전한 출시 — 문제 발생 시 재배포 없이 즉시 끄기(초 단위 롤백)
- 점진적 공개 — 1% → 10% → 100% 사용자에게 단계적으로
- 미완성 기능 병합 — 긴 브랜치 대신 main에 자주 합치되 플래그로 숨김(trunk-based)
- A/B 테스트 — 그룹별로 다른 기능 노출
2. 가장 단순한 형태
if (flags.isEnabled('new_checkout', user)) {
return newCheckout() // 새 기능
} else {
return oldCheckout() // 기존 기능
}
처음엔 설정 파일·환경변수의 boolean으로 시작해도 된다. 규모가 커지면 사용자·비율별 제어가 되는 전용 서비스(LaunchDarkly, Unleash 등)를 쓴다.
3. 종류
| 종류 | 용도 |
|---|---|
| 릴리스 플래그 | 새 기능 점진 출시(수명 짧음) |
| 운영 플래그 | 부하 시 무거운 기능 끄기(kill switch) |
| 실험 플래그 | A/B 테스트 |
| 권한 플래그 | 특정 플랜·사용자에게만 노출 |
4. 함정 — 플래그 부채
- 출시가 끝난 릴리스 플래그를 안 지우면 코드에 죽은 분기가 쌓인다. 100% 배포 후엔 플래그와 옛 코드를 제거하는 정리 습관이 필수.
- 플래그가 많아지면 조합이 폭발해 테스트가 어려워진다 — 수를 관리하라.
- 플래그 판단 로직이 무거우면 성능에 영향 — 평가 결과를 캐시하거나 요청 초기에 한 번만 계산.
자주 묻는 질문
피처 플래그와 브랜치 개발은 뭐가 다른가요?
긴 기능 브랜치는 나중에 병합할 때 큰 충돌이 납니다. 피처 플래그는 미완성 코드도 main에 자주 병합하되 플래그로 숨기므로, 병합 지옥을 피하면서 통합을 자주 할 수 있습니다(트렁크 기반 개발의 핵심 도구).
플래그는 언제 제거하나요?
릴리스용 플래그는 기능이 100% 안정적으로 출시되면 즉시 제거해야 합니다. 방치하면 켜진 적 없는 옛 분기가 코드에 쌓여(플래그 부채) 유지보수를 해칩니다. 반면 kill switch 같은 운영 플래그는 영구적으로 둡니다.
작은 팀도 도구를 도입해야 하나요?
처음엔 환경변수나 설정 테이블의 boolean으로 충분합니다. 사용자별·비율별 제어, 실시간 토글, 감사 로그가 필요해지면 전용 서비스를 검토하세요. 필요보다 앞서 도구부터 도입할 필요는 없습니다.

댓글 0