Feature Flag와 Experiment를 통합하면 숨겨진 비용을 절감할 수 있는 이유

Feature flag와 experiment는 서로 다른 두 가지 역할을 수행합니다.

Flag는 **전달(delivery)**을 제어합니다. 특정 사용자에게 기능이 활성화될지 여부를 결정하며, 문제가 발생했을 때 빠르게 기능을 비활성화할 수 있게 해줍니다.

Experiment는 **측정(measurement)**에 관한 것입니다. 사용자를 그룹으로 나누고, 그들에게 다른 변형(variation)을 보여준 다음, 중요한 지표에서 어떤 것이 더 나은 성과를 내는지 알아내는 것입니다.

새로운 결제 버튼을 예로 들어보겠습니다. Flag가 이를 전달합니다: 이 사용자에게는 활성화하고, 저 사용자에게는 비활성화하는 식입니다. Experiment는 이를 측정합니다: 새로운 버튼이 기존 버튼보다 전환율이 더 좋은지? 두 부분 모두 '다른 결제 버튼을 시도해 보고 도움이 되는지 확인한다'라는 하나의 아이디어를 설명하지만, 역할이 다르기 때문에 팀들은 이들을 서로 다른 곳에서 실행하게 됩니다. 전달은 플래깅 도구(flagging tool)나 설정 서비스(config service)에 존재합니다. 측정은 다른 곳에 존재합니다: 전용 A/B 플랫폼이나 SDK와 분석 파이프라인을 혼합한 자체 구축 시스템입니다.

하나의 아이디어를 두 개의 시스템으로 설명하게 되면, 어떤 사용자가 어느 그룹에 속하는지 일치시키는 것이 도구(tooling)의 문제가 아니라 여러분의 업무가 됩니다. 이것이 바로 '접합부(seam)'이며, 전달과 측정 사이의 연결 지점입니다. 이 접합부는 간과하기 쉬운 금전적 비용과 엔지니어링 시간이라는 대가를 수반합니다. AWS AppConfig가 이미 배포하고 있는 것과 동일한 Feature flag를 사용하여 A/B 테스트를 네이티브하게 실행함에 따라, 이 접합부를 다시 살펴볼 가치가 생겼습니다. 본 게시물은 전달과 측정을 분리했을 때 발생하는 숨겨진 세금(tax)과, 이 둘을 하나의 제어 평면(control plane)에서 공유할 때 얻게 되는 이점에 대해 다룹니다.

여러 서비스가 부과하는 세금 (The multi-service tax)

여러분은 네 가지 방식으로 비용을 지불합니다.

통합(Integration). 애플리케이션에 연결해야 하는 두 개의 시스템이 있으며, 각각 자체적인 설정, 인증 및 구성을 가지고 있습니다. 모든 환경에서 프로비저닝하고 정확하게 유지해야 할 두 가지 요소가 생깁니다.

SDK 확산 (SDK sprawl). 여기에는 플래그 평가 SDK(flag-evaluation SDK)가 있고, 저기에는 실험 또는 분석 SDK(experiment or analytics SDK)가 있습니다. 이것이 여러분이 실행하는 모든 언어와 서비스에 걸쳐 곱해집니다. 배포해야 할 종속성(dependency)이 더 많고, 최신 상태로 유지해야 할 버전이 더 많으며, 문제가 발생했을 때 취약점 표면적(surface area)도 더 넓어집니다.

운영 오버헤드(Operational overhead). 두 개의 제어 평면(control planes). 관리하고 감사해야 할 두 세트의 대시보드가 있습니다. 두 가지 권한 모델이 필요합니다. 엔지니어가 고객에게 보이는 것을 안전하게 변경하기 전에 배워야 하는 것이 두 가지입니다. 그리고 '플래그 지정된 것'과 '측정되는 것' 사이의 격차는 그 자체로 혼란의 범주가 됩니다.

할당 드리프트(Assignment drift). 이것은 미묘한 문제입니다. 플래그 지정 시스템과 실험 시스템이 사용자를 독립적으로 그룹화할 때, 단일 사용자를 두 가지 모두에서 일관된 변형에 유지하는 것이 까다로워집니다. 여기서 작은 실수가 조용히 실험 데이터를 오염시킵니다. 이는 최악의 종류의 버그인데, 오류가 발생하지 않기 때문에 단순히 잘못된 숫자를 결정하게 됩니다.

이들 중 어느 것도 단독으로 극적이지 않습니다. 하지만 함께 작용하면 측정할 가치가 있는 모든 변경에 대한 지속적인 세금과 같습니다.

무엇이 바뀌었나

2026년 중반, AWS는 AWS AppConfig에서 실험(experimentation) 도구의 일반 사용 가능(general availability)을 발표했습니다. A/B 및 다변량 테스트가 이제 별도의 실험 인프라를 구축하거나 실행할 필요 없이 이미 배포하는 기능 플래그에 내장되었습니다. 콘솔, CLI, API 또는 CDK를 통해 변형을 정의하고, 규칙 빌더로 대상 고객을 지정하며, 트래픽 분할(traffic split)을 설정하고, 노출도를 점진적으로 높이며(ramp exposure), 승자를 홍보할 수 있습니다. 이는 모든 상업용 AWS 리전에서 사용 가능합니다.

시기 또한 두 번째 이유로 중요합니다. AWS의 전용 A/B 테스트 서비스인 Amazon CloudWatch Evidently는 2025년 10월 17일에 지원 종료(end of support)했습니다. 따라서 '이제 A/B 테스트는 어디에 존재하는가?'라는 질문은 가설적인 것이 아니라, Evidently에 의존했던 모든 사람에게 실시간으로 제기된 질문이었습니다.

실질적인 효과는 간단합니다. 기능을 제공하는 플래그 자체가 그것을 측정하는 실험을 실행하는 플래그가 된 것입니다.

얻게 되는 것

동일한 네 가지 비용을 다시 되짚어 봅시다.

하나의 제어 평면(control plane). 플래그 자체가 실험 표면(experiment surface)이 됩니다. 실험은 기존의 기능 플래그를 선택하며, 각 처리(treatment)는 해당 플래그 구성의 변형입니다. 롤아웃을 제어하는 것이 테스트를 실행하는 것과 같으며, 변형을 정의하고 트래픽 분할을 설정하는 것은 단지 실험 정의의 일부일 뿐입니다. 여기서는 CDK에서 볼 수 있는데, 각 처리는 자신이 설정하는 플래그 값과 트래픽을 분할하는 weight를 가집니다:

from aws_cdk import aws_appconfig as appconfig

AttrValue = appconfig.CfnExperimentDefinition.AttributeValueProperty
...

CfnExperimentDefinition 구성 요소는 최신 버전의 aws-cdk-lib(2.268.0 이상)에만 포함되어 있습니다.

하나의 에이전트(agent). 실험은 Amazon EC2, AWS Lambda, Amazon ECS, Amazon EKS 및 온프레미스 서버에서 실행되는 AWS AppConfig Agent를 통해 제공됩니다. 이미 플래그 평가를 위해 에이전트를 사용하고 있다면, 배포하고 최신 상태로 유지해야 할 런타임당 구성 요소가 하나일 뿐이지 두 개가 아닙니다. 현재 AppConfig API를 직접 호출하는 경우라면, 에이전트 추가에 대한 예산을 책정하세요. 실험을 위해서는 에이전트가 필수적입니다.

하나의 워크플로우(workflow). 변형을 정의하고, 대상 고객을 지정하며, 트래픽 분할을 설정한 다음, 0% 노출에서 시작하여 메트릭을 모니터링하면서 점진적으로 늘립니다. 특정 처리가 승리하면, 표준 AppConfig 안전 롤아웃을 통해 이를 승격시킵니다. 이는 다른 모든 구성 변경에 사용하는 것과 동일한 점진적이고 모니터링되는 배포입니다. 제대로 알아야 할 한 가지 세부 사항이 있습니다: 실험이 여전히 실행 중일 때, 승리한 값으로 플래그를 업데이트하고 배포한 다음, 실험을 중지합니다. 이 순서대로 진행되어 사용자는 분할된 상태에서 전체 롤아웃으로 바로 이동합니다. 먼저 중지하면, 플래그는 다시 배포될 때까지 현재 배포된 값(일반적으로 기본값)으로 되돌아갑니다.

구축을 통한 일관된 할당(Consistent assignment by construction). 플래그를 처리하는 시스템 자체가 사용자 그룹화(bucketing)도 수행합니다. 따라서 서로 의견이 충돌할 수 있는 두 번째 서비스가 없기 때문에, '두 시스템 모두 이 사용자를 같은 그룹에 넣었는가?'라는 질문은 더 이상 잘못될 수 있는 문제가 아닙니다. 이것이 제로 작업은 아닙니다. 이미 플래그 처리에 사용하는 에이전트 호출과 동일한 방식으로 사용자(Entity-Id)를 식별하는 헤더와, 잠재 고객 규칙(audience rule)이 평가하는 속성들을 담는 Context라는 두 개의 헤더를 추가하여 트릿먼트(treatment)를 검색합니다. 하지만 안정적인 엔티티 ID가 주어지면, 에이전트는 해당 실행 기간 동안 그 엔티티에 대해 항상 동일한 트릿먼트를 반환합니다. 일관성은 시스템의 역할이지 사용자의 책임이 아닙니다. 그리고 트릿먼트 할당은 한 번 실행이 시작되면 잠기기 때문에, 진행 도중에 분할 비율이 조용히 바뀌는 일이 없습니다.

절약 효과가 멈추는 지점 (Where the savings stop)

통합(Consolidation)은 전달(delivery), 할당(assignment), 노출 제어(exposure control)를 다룹니다. 분석(Analysis)은 여전히 사용자의 영역입니다. 실험 데이터를 수집하도록 분석 플랫폼을 구성하는 것은 워크플로우 내의 명시적인 단계이며, AppConfig는 어떤 플랫폼이든 상관없이 의도적으로 중립적(agnostic)입니다: CloudWatch, Snowflake, Datadog 또는 자체 데이터 웨어하우스가 될 수 있습니다. 사용자가 통합하는 것은 '실험을 실행하는 장소'이지, '측정하는 방법' 자체가 아닙니다. 이것이 올바른 트레이드오프입니다. 측정 지표 정의(metric definitions)는 보통 마지막에 마이그레이션하고 싶은 것이지만, 분석 측면은 여전히 사용자가 관리하게 된다는 의미입니다.

물론 무료는 아닙니다. AppConfig 실험 기능은 사용한 만큼 비용을 지불하는 방식(pay-as-you-go)이며, 실행이 시작되는 순간부터 종료할 때까지 실험당 시간 단위로 청구되고, 실험이 진행되는 동안 표준 AppConfig 구성 요청(configuration-request) 요금이 추가로 부과됩니다. (현재 요율은 아래 가격 책정 링크를 참조하십시오.) 주장의 핵심은 통합 비용이 아무것도 아니라는 것이 아닙니다. 한 가지 아이디어에 대해 두 번 지불하는 것을 멈추는 것입니다.

통합이 답이 아닌 경우 (When consolidating isn't the answer)

이는 현재 잘 작동하고 있는 시스템을 완전히 폐기해야 할 상황은 아닙니다.

만약 이미 전담 실험(experimentation) 플랫폼에 투자했다면 — 분석가들이 도구를 구축하고, 자체 통계 엔진과 홀드아웃 그룹을 갖추며, 사람들이 의존하는 워크플로우를 가진 플랫폼이라면 — 계산이 달라집니다. AppConfig의 AI 지원 실험 설계는 디자인 단계에서 귀하의 환경을 실험 모범 사례와 비교하여 충분한 통계적 검정력(statistical power)에 도달하도록 돕지만, 분석 자체는 귀하의 자체 도구에서 이루어지며, 매우 진보된 프로그램은 여전히 이 두 가지를 모두 수행하는 플랫폼을 원할 수 있습니다.

플래그가 브라우저나 모바일 클라이언트에서 평가되는 경우에도 마찬가지입니다. 문서화된 경로는 서버 측 컴퓨팅(server-side compute)의 에이전트를 통해 실행되므로, 클라이언트 측 실험은 백엔드에서 작업을 수행하고 결과를 전달하는 것을 의미합니다. 이것은 장애물이 아니라 의도적으로 내려야 할 설계 결정입니다.

통합의 가치는 두 번째 시스템이 주로 오버헤드인 경우에 가장 높습니다 — 즉, 플래그 지정(flagging)과 실험이 역사적으로 같은 곳을 공유할 수 없었기 때문에 존재만 하는 경우입니다. 이 사례는 이미 AppConfig 기능 플래그를 운영하는 팀에게서 가장 강력한데, 이러한 팀은 별도의 실험 시스템이 이미 가지고 있는 플래그를 중복합니다.

간단한 자가 진단

자신만의 세금(tax)을 파악하기 위한 네 가지 질문:

• 하나의 시스템에서 기능을 제공하고 다른 시스템에서 측정하여, 동일한 변경 사항을 두 번 설명하는가?
• 단일 기능이 종단 간(end to end) 평가되는 동안 몇 개의 SDK 또는 에이전트를 건드리는가?
• 실험이 승자를 산출했을 때, 이를 기존 배포 안전망(deployment safety net)을 통해 승격시킬 수 있는가, 아니면 별도의 수동 단계인가?
• 시스템 전반에 걸쳐 사용자에게 일관된 변형(variation) 상태를 유지하는 것을 적극적으로 관리하고 있는가?

'예'라는 답변이 많을수록 되찾을 것이 더 많다는 의미입니다.

이것이 중요한 이유

AWS에서 구축하는 팀들에게, 기능을 제공하는 것과 그것을 측정하는 것 사이의 분리는 예전에는 구조적인 문제였습니다. AppConfig가 플래그를 지정하고, 다른 시스템이 실험을 수행했으며, 이 두 가지를 연결하는 것이 비즈니스를 하는 비용이었습니다.

더 이상 구조적인 문제가 아닙니다. 그것은 선택의 문제입니다. 그리고 통합하는 것은 돈 이상의 비용을 절감합니다. 움직이는 부품이 적어지고, 드리프트(drift)가 줄어들며, 아이디어를 테스트하는 것부터 승리한 것을 배포하는까지 안전한 경로를 하나로 만듭니다. 이 비용은 청구서가 결코 도착하지 않기 때문에 지불하기 쉬운 종류의 비용이며, 이것이 바로 의도적으로 합산할 가치가 있는 이유입니다.

추가 자료

• AWS AppConfig 실험(User Guide)
• AWS AppConfig, A/B 테스트를 위한 관리형 실험 도구를 출시하다
• 실험 워크플로우 예시
• 승리한 트릿먼트(treatment) 홍보하기
• AWS AppConfig 가격 책정 (AppConfig는 AWS Systems Manager 가격 페이지에 표시됩니다. 실험은 실험 실행 시간당 청구됩니다.)
• 실험 실행 가격 모델 설명 (