콘텐츠로 이동
CS Study

Experimentation & Feature Flags

Experimentation & Feature Flags

섹션 제목: “Experimentation & Feature Flags”

분류: Layer 13 - Product Engineering & Growth Systems

핵심 질문

섹션 제목: “핵심 질문”

Product Engineer는 기능을 “배포했다”에서 끝내지 않는다. 어떤 사용자에게 언제 노출할지, 변경의 효과를 어떻게 분리해서 볼지, 문제가 생기면 얼마나 빨리 끌지까지 설계한다. 이때 A/B 테스트와 feature flag는 제품 학습과 출시 안전성을 연결하는 핵심 도구다.

1. 한 줄 정의

섹션 제목: “1. 한 줄 정의”

Experimentation & Feature Flags는 제품 변경을 실험 가능한 가설로 만들고, 기능 플래그로 사용자 노출을 제어하며, guardrail metric과 rollback으로 출시 위험을 관리하는 역량이다.

2. 왜 중요한가

섹션 제목: “2. 왜 중요한가”

새 UX가 좋아 보인다고 해서 모든 사용자에게 바로 노출하면 세 가지를 잃는다.

  • 효과 분리: 지표 변화가 새 UX 때문인지, 유입 변화 때문인지 알기 어렵다.
  • 출시 안전성: 문제 발생 시 코드를 되돌리지 않고 노출만 끄기 어렵다.
  • 학습 속도: 일부 사용자에게 먼저 노출하고 feedback을 반영하는 루프가 느려진다.

Feature flag는 release를 제어하고, experimentation은 변경 효과를 비교한다. 둘을 함께 쓰면 Product Engineer는 “코드는 이미 배포했지만 아직 5% 사용자에게만 노출”, “conversion은 올랐지만 error rate guardrail이 악화되어 중단” 같은 판단을 할 수 있다.

2.5. 선행 방식의 한계 — 왜 Experiment와 Feature Flag가 필요한가

섹션 제목: “2.5. 선행 방식의 한계 — 왜 Experiment와 Feature Flag가 필요한가”

전통적인 release는 배포 단위와 사용자 노출 단위가 같았다. 배포가 끝나면 모든 사용자가 새 기능을 보았고, 문제가 생기면 rollback이나 hotfix가 필요했다. 이 방식은 작은 서비스에서는 단순하지만, 제품 규모가 커질수록 위험하다. 기능이 특정 plan, region, role, cohort에만 영향을 줄 수도 있고, 지표 변화가 우연인지 기능 효과인지 분리하기도 어렵다.

GrowthBook은 experiment health에서 Sample Ratio Mismatch, multiple exposures, guardrail 같은 데이터 품질 체크를 중요하게 다룬다. LaunchDarkly는 flag variation이 customer action, application performance, business outcome에 어떤 영향을 주는지 metric으로 연결한다. 두 관점은 같은 메시지를 준다. 실험은 통계만의 문제가 아니고, flag는 설정 UI만의 문제가 아니다. 둘 다 제품 변경을 안전하고 학습 가능하게 만드는 엔지니어링 장치다.

따라서 이 문서는 테스트 전략의 연장선이지만, 코드 정합성 검증이 아니라 제품 가설 검증과 사용자 노출 제어를 다룬다.

3. 실험은 가설에서 시작한다

섹션 제목: “3. 실험은 가설에서 시작한다”

좋은 실험은 variant보다 가설이 먼저다.

가설:
첫 workspace 생성 직후 팀원 초대 CTA를 보여주면
신규 admin의 invite_accepted rate가 증가한다.


대상:
처음 workspace를 만든 admin


Primary metric:
7일 내 invite_accepted rate


Guardrail metric:
workspace_created -> first_project_created conversion,
invite_create_failed rate,
support ticket rate

가설에는 대상, 변경, 기대 행동, 시간 범위가 있어야 한다. “새 버튼이 더 좋을까?”는 약한 가설이고, “신규 admin의 첫 팀원 초대 완료율이 7일 안에 증가하는가?”는 실험 가능한 가설이다.

4. Randomization Unit

섹션 제목: “4. Randomization Unit”

Randomization unit은 사용자를 어떤 단위로 control/treatment에 배정할지 정하는 것이다.

단위적합한 경우위험
User개인별 UX 변경같은 workspace 안에서 사용자마다 다른 UX를 볼 수 있음
Workspace/Account협업·권한·결제 기능표본 수가 줄어들 수 있음
Session일회성 UI 노출같은 사용자가 여러 variant를 볼 수 있음
Request인프라/알고리즘 비교사용자 경험 일관성이 깨질 수 있음

협업 제품에서는 user 단위 실험이 항상 맞지 않는다. 초대, 권한, billing처럼 account 상태가 바뀌는 기능은 workspace 단위 randomization이 더 안전할 수 있다.

퀴즈

workspace 초대 UX를 user 단위로 A/B 테스트하면 어떤 문제가 생길 수 있는가?

힌트: 초대는 개인 UI가 아니라 팀 상태를 바꾼다.

정답 보기

같은 workspace 안의 admin들이 서로 다른 초대 UX를 보거나, 한 variant에서 만든 상태가 다른 variant 사용자에게 영향을 줄 수 있다. 협업·권한·결제 흐름은 workspace/account 단위 randomization을 검토해야 한다.

5. Guardrail Metric

섹션 제목: “5. Guardrail Metric”

Primary metric은 좋아졌지만 제품이 망가지는 경우가 있다. Guardrail metric은 실험이 넘어서는 안 되는 안전 경계다.

Primary Metric과 Guardrail Metric

Primary metric

실험이 개선하려는 핵심 행동 지표

예: invite_accepted rate, checkout_completed rate

Secondary metric

효과를 해석하기 위한 보조 지표

예: modal_opened, invite_created, time_to_accept

Guardrail metric

악화되면 실험을 중단하거나 재검토해야 하는 안전 지표

예: error rate, latency, support ticket, cancellation

Data quality metric

실험 배정과 이벤트 수집이 정상인지 확인하는 지표

예: SRM, multiple exposure, missing property

Product Engineer는 제품 metric과 시스템 metric을 함께 본다. conversion이 올라가도 latency, error, accessibility issue가 악화되면 좋은 release가 아니다.

6. Sample Ratio Mismatch와 Multiple Exposure

섹션 제목: “6. Sample Ratio Mismatch와 Multiple Exposure”

실험 결과를 보기 전에 먼저 실험이 정상인지 확인해야 한다.

  • Sample Ratio Mismatch: control/treatment 비율이 의도한 비율과 다르게 수집되는 현상이다. 배정 로직, 필터, 이벤트 누락, bot traffic 문제일 수 있다.
  • Multiple exposure: 한 사용자가 둘 이상의 variant에 노출되는 현상이다. randomization key 변경, 캐시, 로그인 전후 id merge 문제에서 생긴다.
  • Missing assignment: 결과 이벤트는 있는데 experiment assignment property가 없는 경우다.
  • Late event: 실험 기간 밖의 이벤트가 결과에 섞이는 경우다.

이 문제가 있으면 p-value나 uplift를 보기 전에 instrumentation과 assignment를 고쳐야 한다.

7. Feature Flag 패턴

섹션 제목: “7. Feature Flag 패턴”

Feature flag는 단순한 on/off 스위치보다 넓다.

패턴목적예시
Release flag배포와 노출 분리새 onboarding을 5%만 노출
Experiment flagvariant 비교control vs treatment
Permission flag특정 사용자/plan만 접근beta customer allowlist
Operational flag장애 시 기능 축소heavy export 기능 임시 off
Kill switch위험 기능 즉시 중단결제 webhook 오류 시 신규 checkout off

flag가 늘어나면 flag debt도 생긴다. 실험이 끝난 flag, 임시 allowlist, 오래된 kill switch는 코드 복잡도를 키운다. Product Engineer는 flag 생성만큼 제거 조건도 정해야 한다.

8. Rollout Plan

섹션 제목: “8. Rollout Plan”

출시는 한 번에 열지 않아도 된다. 일반적인 rollout은 다음처럼 진행한다.

  1. internal dogfood: 내부 계정에서 기능 확인
  2. beta allowlist: 일부 고객 또는 workspace에만 노출
  3. canary rollout: 1% 또는 5% 사용자에게 노출
  4. metric check: primary, guardrail, error, RUM 확인
  5. gradual rollout: 25% -> 50% -> 100%
  6. cleanup: flag 제거, dead code 삭제, docs 갱신

시나리오

새 checkout UX를 100% 배포할지 결정해야 한다

treatment variant의 checkout_completed rate는 올랐지만, payment_failed rate와 support ticket이 같이 증가했다.

primary metric만 보고 승리 선언하지 않으려면 어떤 guardrail과 세그먼트를 확인할 것인가?

9. 실무 체크리스트

섹션 제목: “9. 실무 체크리스트”

Experiment/Feature Flag 체크

  • 실험 가설에 대상, 변경, 기대 행동, 시간 범위가 포함되어 있다
  • randomization unit이 제품 상태 경계와 맞는다
  • primary metric, secondary metric, guardrail metric이 분리되어 있다
  • SRM, multiple exposure, missing assignment를 확인할 수 있다
  • feature flag가 deploy와 release를 분리한다
  • kill switch와 rollback 기준이 정해져 있다
  • rollout 단계마다 metric check 시점이 있다
  • 실험 종료 후 flag cleanup 계획이 있다

10. 다음 문서로 이어지는 연결

섹션 제목: “10. 다음 문서로 이어지는 연결”

실험과 flag는 제품 상태 모델과 강하게 연결된다. 권한, plan, workspace, subscription 같은 도메인 상태가 명확해야 안전하게 노출을 제어할 수 있다.

  • Product Domain Modeling: flag와 experiment가 참조하는 account, workspace, role 상태를 모델링한다.
  • Billing, Subscription & Entitlement: plan과 entitlement 기반 feature exposure를 설계한다.
  • Frontend Product Quality & RUM: rollout 중 성능·접근성 guardrail을 확인한다.

추가 학습 키워드

섹션 제목: “추가 학습 키워드”
  • A/B testing
  • Randomization unit
  • Guardrail metric
  • Sample Ratio Mismatch
  • Multiple exposure
  • Feature flag
  • Staged rollout
  • Kill switch
  • Flag debt

참고 소스

섹션 제목: “참고 소스”