설정값에서 OpenFeature까지, 피처 플래그는 어떻게 바뀌어 왔을까요

2012년 8월 1일 아침, Knight Capital의 주문 시스템에서 오래전에 사용을 멈춘 Power Peg 코드가 다시 실행됐습니다. 45분 동안 154개 종목에서 약 4백만 건의 체결이 발생했습니다. 이 사건은 피처 플래그 사고로도 알려져 있지만 SEC 명령서에는 오래된 코드와 플래그 재사용뿐 아니라, 서버 한 대의 배포 누락과 검토 절차 부재도 함께 적혀 있습니다.

처음에는 미완성 기능을 설정값으로 숨긴 채 코드를 배포했습니다. 이후 기능을 조금씩 공개하거나 실험하는 도구가 나왔습니다. OpenFeature는 앱에서 여러 플래그 시스템을 같은 API로 호출할 수 있게 합니다.

2009년, Flickr는 미완성 기능을 설정값으로 숨겼습니다

Flickr는 몇 달짜리 기능 브랜치를 따로 유지하지 않으려 했습니다. 엔지니어 Ross Harmes는 2009년 글에서 모든 변경을 브랜치 없이 head에 합치고 하루에도 여러 번 프로덕션에 배포한다고 썼습니다. 미완성 기능은 설정값으로 숨긴 채 서버에 배포하고 출시할 때 값을 바꿨습니다. (Flickr의 당시 설명)

설정값은 환경별로 다르게 두고 필요하면 사용자마다 값을 바꿨습니다. 같은 코드를 배포해도 기능을 볼 수 있는 사용자를 따로 정할 수 있었습니다.

Flickr는 기능을 출시한 뒤 플래그 조건문과 이전 코드를 지우라고 했습니다. 옛 버전과 새 버전을 계속 함께 유지하면 악몽이 된다고 했습니다.

Martin Fowler도 2010년에 설정 파일로 기능을 켜고 끄는 방식을 소개했습니다. 사용자가 새 기능에 들어갈 때 플래그를 확인하도록 했습니다. 그는 2016년 Hodgson 글에 맞춰 설명을 개정했고 2023년에는 제목과 표현을 Feature Toggle에서 Feature Flag로 바꿨습니다. 당시에는 toggle, flag, flipper 같은 이름이 함께 쓰였다는 기록도 남겼습니다. (Fowler의 2010년 글과 개정 이력)

2012년, Knight에서는 오래된 코드와 배포 누락이 겹쳤습니다

SEC의 2013년 명령서에 따르면 Knight는 2003년에 Power Peg 기능 사용을 멈췄지만 코드는 서버에 남겨 뒀습니다. 2005년 주문 누적량 계산을 앞단으로 옮긴 뒤에도 Power Peg 코드를 다시 시험하지 않았습니다. (SEC 명령서)

2012년 RLP 주문 코드를 배포할 때 Knight는 예전에 Power Peg 기능이 사용하던 플래그를 재사용했습니다. 배포 작업에서 여덟 서버 중 한 대가 빠졌습니다. 그 서버에는 새 코드가 없었고 플래그가 활성화되자 오래된 Power Peg 코드가 실행됐습니다.

SEC 문서는 약 45분 동안 154개 종목에서 약 4백만 건이 체결됐고 손실이 4억 6천만 달러를 넘었다고 기록했습니다. SEC는 주문 위험 통제가 부족했고 두 번째 사람이 배포를 검토하도록 정한 서면 절차도 없었다고 지적했습니다.

2016년, 플래그를 네 가지 용도로 나누기 시작했습니다

Pete Hodgson은 플래그를 목적에 따라 나눴습니다. 2016년 초부터 연재한 글을 2017년에 개정하면서 release, experiment, ops, permissioning 네 종류를 설명했습니다. 모두 켜고 끄는 값처럼 보여도 얼마나 오래 유지하고 누가 바꾸는지는 목적에 따라 달랐습니다. (Hodgson의 분류와 관리 방법)

출시 플래그(release)는 개발 중인 기능을 숨기고 준비가 끝나면 공개하는 용도입니다. 대체로 짧게 유지합니다. 실험 플래그(experiment)는 사용자 반응이나 결과를 비교할 동안 유지합니다. 실험 설계와 분석이 끝나면 정리합니다.

운영 플래그(ops)는 부하가 높거나 장애가 났을 때 기능을 빠르게 끄는 용도입니다. 필요하면 오래 유지합니다. 권한 플래그(permissioning)는 사용자나 계정에 기능 접근을 허용하는 규칙입니다. 제품 권한 모델의 일부라면 수년간 유지될 수도 있습니다.

플래그의 용도마다 제거 시점을 다르게 정해야 합니다. 출시 플래그는 기능을 출시한 뒤 옛 경로를 제거할 날짜가 필요합니다. 운영 스위치는 장애 대응 절차에서 계속 필요할 수 있습니다. 권한 규칙은 제품 정책을 따라야 합니다. Hodgson은 플래그가 쌓일수록 관리할 일이 늘어난다고 설명했습니다. 출시 플래그는 만들 때 제거 작업을 백로그에 올리고 만료일을 정하며 기한이 지나면 테스트가 실패하게 하라고 권했습니다.

플래그를 관리하는 SaaS와 오픈소스 도구

LaunchDarkly처럼 플래그를 관리하는 SaaS가 나왔습니다. 팀은 자체 관리 화면과 배포 시스템을 매번 만들지 않고 기능을 중앙에서 켜고 끄거나 사용자 조건에 따라 점진적으로 공개할 수 있게 됐습니다.

Unleash, Flagsmith, Flipt, GrowthBook 같은 오픈소스 도구도 나왔습니다. 팀이 직접 운영하고 저장 데이터를 관리할 수 있습니다. 기능 범위와 배포 방식은 프로젝트마다 다릅니다. (도구 비교 자료)

제품마다 SDK와 플래그 평가 호출 방식이 달랐습니다. 앱에서 사용자나 요청 정보를 넘기는 형식도 달랐습니다. 제품을 바꾸면 관리 화면과 함께 앱 코드의 호출부도 고쳐야 했습니다.

2017년 이후, Uber는 오래된 플래그를 지우는 Piranha를 만들었습니다

새 플래그는 계속 추가됐지만 쓰지 않는 플래그는 코드에 남았습니다. Uber는 목적을 다한 플래그(stale flag)를 찾아 조건문과 관련 코드를 제거하는 도구 Piranha를 만들었습니다. 2017년 12월부터 2019년 5월까지 운영한 결과를 ICSE-SEIP 2020 논문에 보고했고 2020년 3월 도구를 공개했습니다. (Piranha 논문, Uber의 공개 글)

논문의 1,381개는 Piranha가 삭제용 diff를 만든 플래그 수입니다. 당시 전체 플래그의 17%였습니다. 나머지 플래그가 모두 stale인 것은 아니라고 논문도 적고 있습니다. 17%를 stale 비율로 읽으면 안 됩니다.

Piranha는 플래그와 관련 코드를 지우는 변경안을 자동으로 만들었습니다. 생성된 diff 중 65%는 고치지 않고 그대로 반영됐습니다. 다만 어떤 플래그가 정말 필요 없어졌는지는 도구만으로 판정하기 어려웠습니다. 팀에서 담당자를 정해 변경안을 검토하고 반영해야 했습니다.

Kubernetes와 GitLab에서는 플래그를 추가한 뒤 제거하기까지 수개월에서 수년이 걸렸습니다. 2026년 공개된 연구는 두 저장소에서 플래그 추가와 제거 이벤트 4천 건 이상을 분석했습니다. Kubernetes에서는 제거된 플래그의 중앙 생존 기간이 734일이었고 GitLab에서는 185일이었습니다. 두 프로젝트 모두 분석 시점에 추가된 수가 제거된 수보다 많았습니다. 대상은 두 오픈소스 프로젝트라서 모든 조직에 그대로 적용할 수는 없습니다. (Tërnava의 토글 수명 연구)

2022년, OpenFeature가 플래그 평가 API를 통일하기 시작했습니다

제품마다 평가 API가 달라 플래그 제품을 바꿀 때 앱의 호출 코드도 고쳐야 했습니다. 2022년 Dynatrace는 Google, LaunchDarkly, GitLab, Split, Flagsmith, CloudBees와 함께 OpenFeature를 발표하고 CNCF Sandbox 프로젝트로 제안했습니다. 보도자료는 통합 작업이 늘고 벤더 종속이 생긴다고 설명했습니다. (2022년 발표)

앱에서는 OpenFeature의 평가 API만 호출합니다. 공급자(Provider)가 그 호출을 실제 플래그 시스템에 연결합니다. 스펙은 Provider가 벤더 SDK나 REST 클라이언트를 감싸거나 로컬 파일에서 값을 읽을 수 있다고 설명합니다. 백엔드를 바꿀 때 앱의 평가 호출 코드를 고치지 않아도 됩니다. (OpenFeature API 개요, Provider 설명)

스펙은 사용자 정보, 호출 전후 처리, 상태 변경 알림도 정의합니다. Evaluation Context는 사용자나 요청 같은 평가용 속성을 담습니다. Hooks는 평가 전후나 오류 시점에 검증, 문맥 보완, 로깅 같은 처리를 끼워 넣습니다. Events는 Provider 준비 완료나 설정 변경을 앱에 알립니다. Tracking은 플래그 평가 결과를 이후 사용자 행동과 연결합니다. (공식 스펙의 구성)

OpenFeature로 API를 통일해도 기존 플래그 데이터가 새 시스템으로 복사되지는 않습니다. 플래그 키, 조건, 평가 방식은 각 관리 시스템에 남고 데이터를 옮기는 일도 따로 해야 합니다. 같은 API로 불러도 시스템마다 같은 결과가 나온다는 보장은 없습니다.

CNCF는 OpenFeature를 2022년 Sandbox로, 2023년 Incubating으로 올렸습니다. CNCF의 프로젝트 단계와 OpenFeature 스펙의 안정화 상태는 각각 따로 표시됩니다. 2026년 여름 공개된 스펙 v0.9.0에서는 평가 API와 Provider 절이 Stable로 표시됐고 Hooks·Events·Evaluation Context는 Hardening 단계였습니다. 전체 스펙은 여전히 0.x입니다. (CNCF의 Incubating 발표, OpenFeature 2026년 중간 업데이트)

OFREP는 원격 평가 요청과 응답 형식을 정합니다

OpenFeature API를 사용해도 Provider마다 서버에 보내는 요청과 응답 형식은 달랐습니다. OFREP(OpenFeature Remote Evaluation Protocol)는 OpenFeature SDK와 플래그 관리 시스템 사이의 원격 평가 API를 OpenAPI 명세로 정의합니다. 공식 안내는 OFREP를 "프로토콜이지 Provider가 아니다"라고 설명합니다. (OpenFeature의 OFREP 안내)

OFREP에서는 POST /ofrep/v1/evaluate/flags/{key}로 플래그 하나를 평가합니다. 여러 플래그는 POST /ofrep/v1/evaluate/flags로 한꺼번에 평가합니다. 서버 쪽 Provider는 요청마다 문맥을 보내 평가하고 정적 문맥을 사용하는 클라이언트는 일괄 결과를 받아 캐시합니다. 경로에 v1이 있어도 OFREP는 1.0이 아닙니다. (OFREP OpenAPI 정의)

GO Feature Flag, flagd, Flipt가 제공하는 OFREP 기능은 서로 다릅니다. GO Feature Flag는 2024년 3월 초기 구현을 실험 단계라고 발표했습니다. flagd 문서는 단건과 일괄 평가 엔드포인트를 지원한다고 설명하면서 서비스 자체는 EXPERIMENTAL로 표시합니다. Flipt 문서는 서버 API의 OFREP 지원과 Go, JavaScript 서버·웹 Provider를 안내합니다. 제품을 고를 때는 필요한 엔드포인트와 안정화 상태를 각각 확인해야 합니다. (GO Feature Flag 발표, flagd 문서, Flipt 문서)

OFREP는 아직 0.x입니다. OpenFeature의 2026년 업데이트는 0.3.0을 언급하고 프로토콜 저장소의 OpenAPI 정의는 0.4.0입니다.

flex는 플래그로 속도와 안정성을 함께 가져갑니다

플렉스팀은 피처 플래그를 customer 0의 수단으로 씁니다. 새 기능을 고객에게 열기 전에 먼저 저희에게 켭니다. 저희가 저희 제품의 첫 번째 고객이 되어 실제 업무에서 써 보고, 불편한 점을 고친 뒤에 범위를 넓힙니다.

이렇게 하는 이유는 속도와 안정성 중 하나를 고르지 않기 위해서입니다. 배포를 늦추면 안정적이지만 느려지고, 바로 공개하면 빠르지만 문제를 고객이 먼저 만납니다. 플래그로 배포와 공개를 나누면 둘 다 포기하지 않아도 됩니다. 코드는 준비되는 대로 배포하고, 문제는 고객보다 저희가 먼저 겪습니다. 고객이 만나는 기능은 저희가 먼저 써 본 기능입니다.

Flickr가 하루에도 여러 번 배포하려고 설정값을 썼듯이, 저희도 같은 이유로 플래그를 씁니다. 더 자주 배포하고, 더 안심하고 공개하려는 것입니다.