도입
기능 배포는 했지만 사용자에게 바로 공개하면 위험한 경우가 많다.
특히 결제, 정산, 신규 UI 같은 기능은 문제가 생기면 영향 범위가 크다.
이때 사용하는 방식이 Feature Flag다. 배포와 공개를 분리하는 전략이다.
핵심 개념 설명
Feature Flag는 기능 활성화 여부를 코드 밖에서 제어하는 방식이다.
즉 코드는 이미 배포되어 있어도 기능은 OFF 상태로 둘 수 있다.
- 배포(Deploy): 서버에 코드 반영
- 공개(Release): 사용자에게 기능 노출
Feature Flag는 이 둘을 분리한다. 실무에서는 안정성을 위해 거의 필수다.
동작 원리 또는 구조
사용자 요청 시 Flag 상태를 먼저 확인한다.
즉 실행 경로 자체를 동적으로 변경하는 구조다.
그래서 코드 재배포 없이도 기능을 켜고 끌 수 있다.
실무 기준 / 적용 방법
1. 가장 기본적인 방식
가장 단순한 형태는 환경 변수 또는 DB 값 기반이다.
초기에는 이 정도만으로도 충분하다. 중요한 것은 중앙 제어다.
<?php
$isEnabled = config('feature.new_payment_ui');
if ($isEnabled) {
return view('new-payment');
}
return view('old-payment');
2. 사용자 그룹별 적용
실무에서는 전체 공개보다 일부 사용자에게 먼저 적용하는 경우가 많다.
운영팀, QA 계정, 특정 등급 사용자에게만 연다.
<?php
if (in_array($user->id, $betaUsers)) {
return $newFeature();
}
return $oldFeature();
3. Percentage Rollout
트래픽 일부에만 기능을 공개하는 방식이다. Canary 배포에서 많이 사용된다.
예를 들어 10% 사용자만 새 기능을 사용하게 할 수 있다.
<?php
$percent = crc32($user->id) % 100;
if ($percent < 10) {
return $newFeature();
}
return $oldFeature();
문제가 없으면 10% → 30% → 100% 순으로 확장한다.
4. 운영 관리 시스템
규모가 커지면 별도 Feature Flag 시스템을 사용한다.
- LaunchDarkly
- Unleash
- Flagsmith
운영자가 UI에서 ON/OFF를 관리한다. 재배포 없이 즉시 변경 가능하다.
실무에서 중요한 설계 기준
1. Flag 이름 규칙
이름이 모호하면 관리가 어려워진다. 기능과 목적이 드러나야 한다.
good:
payment_new_ui
checkout_v2
ai_summary_beta
bad:
new_feature
temp_flag
test1
2. 오래된 Flag 제거
Feature Flag를 계속 남겨두면 조건문이 폭발적으로 증가한다.
기능이 완전히 안정화되면 반드시 제거해야 한다.
이 단계가 빠지면 기술 부채가 된다.
3. DB보다 메모리 캐시 우선
요청마다 DB 조회하면 오히려 성능 문제가 생긴다.
Redis나 메모리 캐시를 사용하는 것이 일반적이다.
4. 장애 시 OFF 가능해야 함
Feature Flag의 가장 큰 목적은 긴급 차단이다.
문제가 발생하면 즉시 OFF할 수 있어야 한다.
재배포 없이 복구 가능하다는 점이 핵심이다.
자주 발생하는 문제
1. Flag 남발
모든 기능에 Flag를 붙이면 조건문 관리가 어려워진다.
위험도가 높은 기능 중심으로 사용해야 한다.
2. 제거 안 함
오래된 Flag가 계속 남으면 코드 가독성이 급격히 떨어진다.
Release 완료 후 제거를 규칙화해야 한다.
3. Frontend와 Backend 불일치
프론트는 ON인데 백엔드는 OFF인 경우가 생긴다.
중앙 관리 구조로 통일해야 한다.
4. 캐시 동기화 문제
Flag 변경이 즉시 반영되지 않으면 사용자 경험이 섞일 수 있다.
TTL과 캐시 무효화 전략이 필요하다.
한 줄 요약
Feature Flag는 배포와 공개를 분리해 위험한 기능을 점진적으로 운영할 수 있게 만드는 전략이며, 실무에서는 부분 공개와 긴급 차단 용도로 핵심적으로 사용된다.
댓글 0