Feature Flag - 안전하고 신뢰할 수 있는 배포로 가는 열쇠 🔑

11번가 Core플랫폼개발팀은 Spring Cloud 기반 전사 MSA 플랫폼 Vine의 공통 컴포넌트와 운영 툴체인을 담당하고, 내부 개발자 플랫폼 Wheelhouse도 함께 제공한다. 그 과정에서 REST(HTTP) 호출을 gRPC 호출 기반으로 전환하는 공통 라이브러리를 만들었지만, 검증 환경과 달리 대규모 트래픽이 몰리는 Production에서는 즉시 롤백이 필요할 수 있어 배포와 기능 전환을 분리할 안전장치가 필요했다.

그 해법으로 Feature Flag를 사용한다. Feature Flag는 런타임에서 조건에 따라 기능을 켜고 끄는 메커니즘으로, 코드를 다시 배포하지 않고도 기능 공개 여부를 바꿀 수 있다. 이를 통해 시스템 안정성, A/B 테스트, 개인화, 점진적 Rollout을 구현할 수 있으며, 특히 신규 기능을 일부 사용자나 그룹에 먼저 노출해 위험을 줄일 수 있다.

구현 방식은 플래그 정의가 들어 있는 FlagConfiguration, 플래그 상태를 읽어오는 Flag Router, 그리고 조건문으로 기능을 분기하는 Flag Point로 나뉜다. 만약 플래그 상태를 배포된 애플리케이션 외부에서 읽지 않으면 Spring Boot profile처럼 매번 재배포가 필요해지므로, Feature Flag의 핵심 이점인 빠른 전환과 불필요한 배포 감소를 잃게 된다.

표준 인터페이스로는 OpenFeature를 사용한다. OpenFeature는 CNCF Sandbox 프로젝트로 지정된 벤더 중립 표준이며, SDK와 Provider 구조를 통해 다양한 Flag Management System과 연결된다. 이 글에서는 오픈소스 Provider인 flagd를 함께 사용해 Flag Backend와 Flag Evaluation Engine을 구성하는 방법을 설명한다.

flagd는 Boolean, String, Number, JSON 타입을 지원하고, Context 기반 Targeting, Pseudo-random 할당, 점진적 릴리즈, Flag Aggregation 같은 기능을 제공한다. Kubernetes에서는 open-feature-operator로 sidecar 형태의 flagd를 주입할 수 있고, 11번가는 IDC와 AWS EKS가 섞인 Hybrid 인프라에서 동일한 Engine을 바라보도록 EKS에 flagd Docker 이미지를 배포해 Ingress로 통합 운영했다. 예시로 사용된 이미지 버전은 ghcr.io/openfeature/flagd:v0.6.6이다.

Flag 정의는 JSON이나 YAML로 작성하며, flagd는 파일, Kubernetes Custom Resource, HTTP/gRPC 엔드포인트를 Watch하면서 변경을 즉시 반영한다. 주요 항목은 state(ENABLED/DISABLED), variants(값 매핑), defaultVariant, targeting이며, targeting은 변형된 JSONLogic 기반 조건식으로 동작한다. 예를 들어 email이 @sk.com으로 끝나는 사용자에게만 특정 variant를 주거나, fractional 규칙으로 50/20/30 같은 비율의 Canary를 적용할 수 있다.

Java SDK에서는 OpenFeatureAPI에 FlagdProvider를 연결한 뒤 Client로 평가를 수행한다. 평가 API는 Boolean, String, Integer, Double, Object 다섯 가지 타입을 지원하며, 단순 값만 받는 get[Type]Value()와 Flag Key, 결과값, 이유, 에러 코드까지 포함하는 get[Type]Details()를 제공한다.