이 글은 Unleash 공식 문서
What is a feature flag를 읽고,
내용을 정리하고 개인적인 이해를 바탕으로 재구성한 글입니다.
배포는 했는데 기능은 아직 공개하고 싶지 않을 때, 혹인 이미 배포된 기능이 문제가 생겨 당장 꺼야 하는 상황이 오기도 합니다.
이럴 때 가장 단순한 선택지는 “다시 배포한다”이지만, 실무에서는 이 선택이 생각보다 비싸고 위험합니다.
- 재배포는 빌드 → 테스트 → 이미지 생성 → 배포 파이프라인 실행 → 서비스 재시작 또는 롤링 업데이트 이런 과정이 있습니다. 자동화가 되어있더라도 몇 분은 걸릴 것입니다. 장애 상황에서는 이 시간이 그대로 서비스 장애 시간이 되기 때문에 비용이 크고 특히 트래픽이 많은 시간대나 고객이 직접 영향을 받는 기능일 때 이는 문제가 될 것입니다.
이 문제를 해결하기 위해 등장한 개념이 Feature Flag입니다.
Feature Flag란
소스 코드를 다시 배포하지 않고, 실행 중인 애플리케이션에서 특정 기능을 켜거나 끌 수 있게 해주는 기법입니다.
핵심은 “배포와 기능 공개를 분리”! 기술적 문제를 운영 전략으로 풀어낸 방식입니다.
CI/CD + Feature Flag 구조
기존 흐름은 보통 <코드 작성 → 테스트 → 배포 → 기능 공개> 입니다.
Feature Flag를 도입하면 흐름이 아래와같이 바뀝니다.
코드 작성 → 테스트 → 배포
↓
Feature ON / OFF (런타임 제어)즉, 코드는 이미 프로덕션에 존재하지만 기능의 실행 여부를 런타임에서 제어하는 것입니다.
이 차이가 운영 유연성을 만들어냅니다.
왜 Feature Flag가 필요했을까?
Feature Flag는 기존 Feature Branch 방식의 한계 때문에 주목받게 되었습니다.
Feature Branch의 현실적인 문제
- 피드백이 느리다
- 브랜치마다 테스트 환경을 따로 띄워야 함
- 이해관계자 확인 비용 증가
- 머지 지옥
- 브랜치가 오래될수록 충돌 확률 증가
- 릴리즈 일정 지연
- 운영 환경 불확실성
- 실제 프로덕션 데이터에서 어떻게 동작할지 알 수 없음
- 예상 못 한 엣지 케이스 발생
이 문제를 해결하기 위해 나온 접근이 Trunk-based Development + Feature Flag 조합입니다.
Feature Flag가 주는 이점
-
배포 리스크 감소
- 기능을 숨긴 채로 배포 가능
- 문제 발생 시 즉시 OFF
- 롤백 없이 장애 완화 가능
-
QA와 실사용 환경 테스트
Feature Flag를 사용하면
- 특정 사용자
- 특정 조직
- 특정 조건
에게만 기능을 노출할 수 있어집니다. 즉, 실제 프로덕션 환경에서, 실제 데이터로 테스트가 가능해집니다.
-
빠른 릴리즈 사이클
- 기능 완성 ≠ 기능 공개
- 배포는 자주, 공개는 신중하게
CI/CD 파이프라인과 결합하면 작은 변경을 빠르게 쌓아 올릴 수 있는 구조가 됩니다.
-
A/B 테스트와 실험
Feature Flag는 단순 ON/OFF를 넘어서
- 사용자 그룹별 분기
- 비율 기반 노출
- 실험군/대조군 분리
같은 실험 도구로도 활용될 수 있습니다. “이 기능이 진짜 사용자에게 도움이 되는가?”를 데이터로 판단할 수 있습니다.
Feature Flag vs Feature Branch
| 구분 | Feature Branch | Feature Flag |
|---|---|---|
| 코드 위치 | 별도 브랜치 | main / trunk |
| 배포 시점 | 기능 완성 후 | 언제든 가능 |
| 리스크 | 머지 충돌 | 런타임 제어 |
| 운영 테스트 | 제한적 | 프로덕션 가능 |
둘 중 하나만 써야 하는 것은 아닙니다. Feature Branch + Feature Flag처럼 조직/규제 환경에 맞게 혼용 가능합니다.
Feature Flag는 결국 조건문이다
가장 단순한 형태의 Feature Flag는 이런 코드입니다.
if (featureFlag.isEnabled("new-payment")) {
newPayment();
} else {
oldPayment();
}차이는 이 flag 값이 어디서 오느냐입니다.
- config 파일
- DB
- 외부 Feature Management 플랫폼
값만 바꾸면 재배포 없이 즉시 동작 변경이 가능합니다.
Feature Flag의 주의점
잘못쓰면
- 플래그가 제거되지 않고 쌓입니다.
- 코드 복잡도가 폭증합니다.
- 읽기 어려운 조건문 지옥이 됩니다.
좋은 Feature Flag 사용 원칙
- 임시 플래그는 수명 관리
- 실험 종료 후 코드 정리
- 핵심 로직에 과도한 분기 금지
마무리
Feature Flag의 본질은 단순한 ON/OFF 기술이 아니라, 배포와 공개를 분리함으로써 운영 리스크를 제어하는 전략입니다.
이를 통해 팀은 배포를 두려워하지 않고, 더 자주 배포하며, 실제 사용자 환경에서 안전하게 검증할 수 있게 될 것입니다. 하지만 잘못 사용하면 코드 복잡도를 키울 수 있으니 명확한 목적과 수명을 가지고 사용하는 것이 중요할 것입니다.
