Feature Flag (Feature Toggle)

한 문장 정의

Feature Flag는 기능을 ‘개발 완료 여부’와 ‘서비스 공개 여부’로 분리하여,
운영 중인 서비스에서 기능의 노출·차단·대상을 실시간으로 제어하는 메커니즘이다.

이 문장이 핵심이다.
개발 ≠ 오픈

---

왜 이 개념이 등장했는가

과거에는 이런 구조였다.

• 기능 개발
• QA
• 앱/웹 배포
• 전체 유저에게 동시에 노출

문제점:

• 작은 수정도 전체 배포 필요
• 장애 발생 시 롤백 어려움
• 실험 불가능
• 기획 변경 = 개발 재작업

서비스가 커질수록 이 방식은 운영 불가능해짐

그래서 나온 개념이 Feature Flag다.

---

Feature Flag의 본질적 역할

Feature Flag는 단순히 “켜고 끄는 스위치”가 아니다.
기획 관점에서 보면 다음 4가지를 가능하게 만든다.

1. 릴리즈 전략 분리
2. 운영 리스크 흡수
3. 실험 가능한 UX
4. 의사결정의 데이터화

---

Feature Flag의 동작 구조

• 기능은 이미 코드에 존재
• 기능 실행 전에 서버에 물어봄

→ “이 기능 사용해도 되나요?”

• 서버가 조건 판단 후 응답
• 클라이언트는 응답에 따라 UI/기능 처리

여기서 중요한 포인트:

• 기획자가 정한 조건이 서버 로직이 됨
• 앱은 판단하지 않음, 서버가 판단함

---

Feature Flag에서 가장 중요한 개념: “조건”

기획자가 실질적으로 다루는 건
ON / OFF가 아니라 ‘조건 설계’다.

대표적인 조건 유형

1. 유저 속성 기반

• 신규 유저 / 기존 유저
• 결제 유저 / 비결제 유저
• VIP / 일반
• 특정 레벨 이상

→ CRM, 라이브 운영과 직결

2. 디바이스 / 환경 기반

• Android / iOS
• 앱 버전 이상만
• 특정 OS 버전 제외

→ 스토어 이슈 대응용

3. 국가 / 리전 기반

• 한국만 오픈
• 글로벌 순차 오픈
• 법/정책 이슈 회피

→ 법무·정책 리스크 관리

4. 비율 기반 (Percentage Rollout)

• 전체 유저의 1%
• 5% → 20% → 100%

→ 점진적 확산 (Gradual Rollout)

---

Feature Flag를 쓰는 핵심 시나리오

1. 소프트 런칭 (Soft Launch)

기획적으로 가장 중요한 활용

• QA 완료
• 내부 계정 ON
• 문제 없으면 일부 유저 ON
• 데이터 확인 후 전체 오픈

→ “오픈일”의 의미가 달라진다
→ 날짜가 아니라 상태값

2. 실험 가능한 UX 설계 (A/B Test)

예시:

• 결제 버튼 위치 A안 / B안
• 홈 구조 두 가지 안
• 문구 차이

Feature Flag 없으면:

• 회의 → 의견 → 감으로 결정

Feature Flag 있으면:

• 실제 데이터로 결정

3. 장애 대응용 Kill Switch

이건 정말 중요하다.

상황:

• 특정 기능에서 오류 발생
• 외부 API 장애
• 트래픽 폭증

Feature Flag 있으면:

• 서버에서 즉시 OFF
• 앱은 정상 유지

없으면:

• 긴급 공지
• 강제 업데이트
• 스토어 심사 대기

4. 일정 불확실성 대응

기획에서는 이런 일이 항상 발생한다.

• A 기능은 일정 OK
• B 기능은 QA 지연

Feature Flag 기반이면:

• A는 오픈
• B는 OFF 상태로 다음 주 오픈

→ 전체 일정이 기능 하나에 발목 잡히지 않음

---

Feature Flag와 기획 문서의 관계

좋은 요구사항 예시

• “해당 기능은 Feature Flag 적용 대상”
• “초기에는 내부 계정만 노출”
• “문제 발생 시 서버에서 즉시 비활성화 가능해야 함”
• “유저 그룹별 노출 조건 설정 가능”

---

Feature Flag를 남용하면 생기는 문제

1. 플래그 관리 복잡도 증가

• 사용 끝난 플래그 방치
• 조건 꼬임

2. UX 일관성 깨질 위험

• 유저마다 화면이 다름
• 고객센터 혼란

3. QA 복잡도 상승

• 케이스 수 증가

---

Feature Flag 마인드셋

이렇게 생각하면 된다.

• “이 기능은 언제든 꺼질 수 있어야 한다”
• “오픈은 이벤트가 아니라 상태다”
• “운영 리스크는 코드가 아니라 설계로 줄인다”
• “기획은 출시가 아니라 운영까지 포함한다”

---

최종 요약

Feature Flag는 기능을 안전하게 실험·운영·통제하기 위한 장치로,
기획자가 서비스 리스크와 사용자 경험을 동시에 관리할 수 있게 해준다.