Feature Flag 가 토글이 아니라 컨트롤 플레인이 되는 시점

처음에 우리 feature flag 시스템은 boolean 토글 12개 였다. configcat 같은 SaaS 위에 박아 둔. 9개월 후에 우리 flag 인스턴스는 407개 였고, 시간당 평균 14건의 변경 이 일어나고 있었다. 우리 프로덕션 인프라에서 가장 자주 바뀌는 표면 이 됐다.

이 변환을 의도하지 않고 겪으면 통제 불가능한 chaos 가 된다. 의도하고 겪으면 organization 의 가장 강력한 도구 가 된다.

토글에서 컨트롤 플레인으로 — 4 단계

1단계 — 기능 출시 토글 (1~50 flag)

처음 단계. 새 기능을 배포 후 점진적 활성화 가 목적. 보통 bool flag. lifetime 짧음 (1~3 sprint 후 제거).

이 단계 함정 — 제거 안 함. 기능이 안정 되면 flag 도 같이 제거해야 하지만, 번거로워서 안 함. flag 가 50개 를 넘으면 낡은 flag 가 절반 이상.

2단계 — 위험 차단 toggle (50~150 flag)

다음 단계. 문제 발생 시 즉시 끄는 도구로 진화. circuit breaker 의 수동 버전. lifetime 영구 (인시던트 응답용으로 유지).

이 단계 함정 — 어떤 flag 를 어떤 인시던트에 쓸지 가 문서화되지 않음. 03:11 인시던트 시점에 어느 flag 를 끌지 가 그 사람의 기억 에 의존.

3단계 — segment-targeted rollout (150~300 flag)

다음 단계. 특정 사용자 segment 만 새 동작 받게 함. bool 이 아니라 target rule 을 표현. 기업 결제 사용자만, 한국 사용자만, 베타 프로그램 가입자만.

이 단계 함정 — targeting 표현식이 분산. 같은 segment 가 여러 flag 에서 다르게 정의됨. 한 사용자가 flag A 에서는 "베타 사용자", flag B 에서는 아님.

4단계 — 컨트롤 플레인 (300+ flag)

여기서 변환 이 일어난다. flag 가 기능 이 아니라 시스템 동작 자체 를 통제. 트래픽 비율, 캐시 TTL, retry 횟수, 타임아웃, 외부 vendor 선택, 모델 버전 등 런타임 결정 전체 가 flag 로 표현됨.

이 시점에서 deploy 의 의미가 변한다. 코드 deploy 는 기반 설치, 실제 제품 동작 은 flag 변경 으로 결정.

4단계의 의미 — deploy 의 본질이 바뀐다

3단계까지는 deploy = 기능 출시. 4단계에서는 deploy = 코드 변경, flag = 동작 변경. 두 개가 분리된다.

이게 의미하는 것:

• 코드 review 와 flag review 가 분리됨. 코드는 엔지니어 review, flag 는 제품·SRE·보안 합동.
• 코드 deploy 빈도는 떨어지지만 flag 변경 빈도는 올라감. 우리 데이터: 일 5~7 deploy → 일 14 flag 변경.
• 인시던트 시 첫 행동이 flag 변경 — code revert 보다 빠름.
• A/B 테스트가 별도 시스템이 아님 — 모든 flag 가 잠재적 A/B.

4단계로 가는 비싼 부분 4가지

1. Flag typing 시스템

300+ flag 가 bool 이 아닌 다양한 타입 이 된다. number, string, JSON object, target rule. 타입이 코드와 일치 해야 — 코드가 string 을 기대하는데 flag 에 number 가 들어가면 런타임 깨짐.

해결: flag 정의 시점에 schema 박음, 코드와 동기화 검증.

2. Flag audit

300+ flag 의 변경 이력 이 감사 가능 해야. 누가 언제 어떤 flag 를 변경했고, 그 시점의 시스템 상태 가 어땠는지.

해결: flag 변경을 deploy 와 같은 audit trail 에 박음. 변경자, 시각, 이전 값, 새 값.

3. Flag dependency 그래프

flag 가 서로 의존 한다. flag A 가 켜져 있을 때만 flag B 의 의미가 있음. 이 의존을 수동으로 관리하면 3개월 안에 무너진다.

해결: flag 정의에 prerequisite 명시, 시스템이 불가능한 조합 을 차단.

4. Flag cleanup 자동화

flag 가 영원히 살지 않게 해야. 만들 때 expiry 또는 cleanup 트리거 명시. 자동으로 정기 cleanup 알림.

해결: 매 분기 90일 이상 변경 안 된 flag 자동 보고. 절반은 제거 가능.

우리 사례 — 인시던트 응답 시간

3단계에서 4단계로 넘어간 후 측정한 인시던트 응답 시간:

3단계 (flag 150개):
  인시던트 → 코드 revert → deploy → 적용
  평균 시간: 27 분

4단계 (flag 300+):
  인시던트 → flag 변경 → 즉시 적용
  평균 시간: 4 분

23분 단축. 이게 4단계의 진짜 가치. 인프라 비용은 더 들고, 운영 복잡도는 올라가지만, 인시던트 응답이 7배 빨라진다.

4단계가 모든 팀에 맞는가

아니다. 4단계는 flag 운영 전담팀 이 있어야 유지 가능. 200명 미만 조직은 거의 항상 3단계가 상한.

누가 이 글을 읽으면 좋은가

이미 flag 가 100개 이상 이고 통제력이 떨어진다 고 느끼는 플랫폼·SRE 리드. 4단계의 4 가지 비용을 지금 박지 않으면 6개월 후 전체 재설계 가 된다.