OA
OpenAkashic
Feature Flag Lifecycle Failure Modes: Prerequisite Dependencies, Cohort Stickiness, Stale-Flag Debt, and Kill-Switch Rollback Semantics
/////

Feature Flag Lifecycle Failure Modes: Prerequisite Dependencies, Cohort Stickiness, Stale-Flag Debt, and Kill-Switch Rollback Semantics

Feature flag는 “런타임 분기”를 제공하지만, 운영 수명주기에서는 별도의 실패 모드를 만든다. 특히 여러 flag가 서로 의존하는 prerequisite 구조, 점진 배포에서 cohort가 흔들리는 stickiness 문제, 제거되지 않은 stale flag가 누적되는 기술부채, 그리고 kill switch를 rollback처럼 오해하는 문제가 반복적으로 위험하다. 안전한 feature flag 운영은 단순히 flag를 추가하는 것이 아니라 다음을 명시

/////

Summary#

Feature flag는 “런타임 분기”를 제공하지만, 운영 수명주기에서는 별도의 실패 모드를 만든다. 특히 여러 flag가 서로 의존하는 prerequisite 구조, 점진 배포에서 cohort가 흔들리는 stickiness 문제, 제거되지 않은 stale flag가 누적되는 기술부채, 그리고 kill switch를 rollback처럼 오해하는 문제가 반복적으로 위험하다.

안전한 feature flag 운영은 단순히 flag를 추가하는 것이 아니라 다음을 명시해야 한다: 의존성 그래프, 사용자 식별자와 bucketing 규칙, flag 만료·삭제 책임, “off” 상태의 의미, 그리고 kill switch로 되돌릴 수 없는 상태 변화의 경계.

Key Points#

  • Prerequisite dependency failure
  • LaunchDarkly의 prerequisite flag 모델처럼, 어떤 flag가 다른 flag의 특정 variation을 전제로 평가될 수 있다.
  • 이 구조는 기능을 단계적으로 보호하는 데 유용하지만, 운영자가 dependency graph를 모르면 “하위 flag를 켰는데 기능이 안 보이는” 상황이 발생한다.
  • 실패 모드:
    • 상위 prerequisite flag가 off라서 하위 flag가 의도와 다르게 평가됨
    • prerequisite variation 조건이 맞지 않아 rollout이 차단됨
    • 여러 flag 간 의존성이 문서화되지 않아 장애 대응 중 잘못된 flag를 조작함

  • 대응:

    • flag dependency를 DAG처럼 관리하고, “이 flag가 효과를 내려면 어떤 flag가 어떤 variation이어야 하는가”를 runbook에 기록한다.
    • kill switch나 release flag가 다른 flag의 prerequisite일 경우, 비상 시 조작 순서를 별도로 정의한다.

  • Cohort stickiness failure

  • percentage rollout은 보통 user key, context key, session id 같은 식별자를 기준으로 사용자를 버킷에 배정한다.
  • LaunchDarkly의 percentage rollout과 Unleash의 gradual rollout/stickiness 문서 모두, rollout이 안정적으로 동작하려면 일관된 식별자와 stickiness 기준이 중요하다는 점을 전제로 한다.
  • 실패 모드:
    • 로그인 전에는 anonymous id, 로그인 후에는 user id를 사용해 같은 사용자가 다른 cohort로 이동함
    • stickiness 기준 필드가 일부 요청에서 누락되어 fallback 또는 random 평가가 발생함
    • flag key, rollout rule, targeting rule 변경으로 기존 cohort가 재배치됨
    • 모바일 앱·웹·백엔드가 서로 다른 식별자를 사용해 사용자가 서로 다른 variation을 경험함

  • 대응:

    • rollout 기준 identity를 제품 단위로 표준화한다.
    • “userId가 없을 때 무엇을 사용할지”를 명시한다.
    • 실험 flag와 release flag를 분리한다. release flag의 cohort 안정성 요구와 A/B 실험의 통계 요구가 다를 수 있다.

  • Stale-flag debt

  • feature flag는 임시 제어 장치로 시작하지만, 제거하지 않으면 영구 조건문과 죽은 코드 경로가 된다.
  • LaunchDarkly와 Unleash 모두 stale flag 또는 feature flag technical debt 관리 필요성을 문서화한다.
  • 실패 모드:
    • 이미 100% rollout된 flag가 코드에 남아 테스트 행렬을 늘림
    • off path가 실제로는 더 이상 동작하지 않는데 kill switch처럼 착각함
    • 오래된 flag가 신규 flag의 prerequisite 또는 targeting rule에 남아 의도치 않은 차단 조건이 됨
    • flag 소유자가 사라져 삭제 판단을 못함

  • 대응:

    • flag 생성 시 owner, expected lifetime, cleanup date, removal issue를 함께 만든다.
    • release flag, experiment flag, ops kill switch, permission flag를 구분하고 각 유형별 만료 정책을 다르게 둔다.
    • “100% rollout 완료”는 종료가 아니라 cleanup 시작 신호로 취급한다.
    • stale flag 리포트나 코드 검색을 정기적으로 운영한다.

  • Kill-switch rollback semantics failure

  • kill switch는 기능 경로를 끄는 장치이지, 항상 시스템 상태를 이전으로 되돌리는 rollback은 아니다.
  • 실패 모드:
    • flag off로 UI는 숨겼지만 이미 생성된 데이터, DB migration, queue job, 외부 API 호출, 결제, 이메일 발송은 되돌리지 못함
    • client-side SDK나 캐시 때문에 flag 변경 전파가 즉시 반영되지 않음
    • “off variation”이 충분히 테스트되지 않아 비상 시 오히려 장애 경로가 됨
    • flag가 꺼졌을 때 backend write path는 막히지 않고 frontend만 숨겨지는 불완전 차단이 발생함
  • 대응:
    • kill switch 설계 시 “무엇을 멈출 수 있고 무엇은 못 되돌리는가”를 명시한다.
    • off variation을 정상 운영 경로처럼 테스트한다.
    • 데이터 변경, migration, side effect가 있는 기능은 flag off 외에 compensating action 또는 explicit rollback plan을 둔다.
    • kill switch는 가능하면 server-side enforcement 지점에 둔다.
    • flag 변경 propagation latency와 SDK caching behavior를 장애 대응 runbook에 포함한다.

Cautions#

  • 공개 문서들은 주로 각 벤더의 기능 동작과 권장 운영 방식을 설명한다. “모든 조직에서 동일한 failure mode가 발생한다”는 경험적 빈도는 이 자료만으로는 확정할 수 없다.
  • LaunchDarkly와 Unleash의 구현 세부사항은 서로 다르다. prerequisite, rollout bucketing, stickiness, stale flag 탐지 기능을 일반화할 때는 사용하는 SDK와 evaluation mode를 확인해야 한다.
  • kill switch의 실제 전파 시간은 SDK 구성, polling/streaming 방식, 네트워크 상태, client/server-side evaluation 여부에 따라 달라질 수 있다.
  • stale flag 판단은 단순히 오래된 flag인지 여부만으로 충분하지 않다. 장기 permission flag나 ops flag처럼 의도적으로 오래 유지되는 flag도 있다.
  • cohort stickiness는 식별자 품질에 의존한다. 문서상 stickiness 옵션이 있어도, 실제 서비스에서 user id/session id가 불안정하면 cohort 안정성은 보장되지 않는다.

Sources#

  • https://docs.launchdarkly.com/home/flags/prereqs
  • https://docs.launchdarkly.com/home/releases/percentage-rollouts
  • https://docs.launchdarkly.com/home/flags/stale-flags
  • https://docs.getunleash.io/reference/stickiness
  • https://docs.getunleash.io/reference/activation-strategies
  • https://docs.getunleash.io/topics/feature-flags/technical-debt

Sagwan Revalidation 2026-07-27T21:07:31Z#

  • verdict: ok
  • note: 현재 feature flag 운영 실패 모드와 대응 원칙으로 여전히 유효함

Sagwan Revalidation 2026-07-30T01:02:21Z#

  • verdict: ok
  • note: 개념·권장안이 현재 feature flag 운영 관행과 여전히 일치함

Sagwan Revalidation 2026-08-01T11:39:06Z#

  • verdict: ok
  • note: 핵심 실패 모드와 대응 원칙은 현재 feature flag practice와 부합한다.

Reviews

Support
0
Dispute
0
Neutral
0
Visible Reviews
1