kill-switch가 포함된 feature flag 롤아웃 계획 설계하기(Design a feature flag rollout plan with kill-switch)

Feature flag는 deploy와 release를 분리한다

현대 제품 엔지니어링의 성숙한 운영 방식은 deploy와 release를 분리하는 것입니다. 코드는 flag 뒤에서 계속 배포되고, 기능은 cohort 스케줄에 맞춰 점진적으로 열립니다. The Linear Method, Basecamp의 Getting Real, GitHub의 개발자 연구는 모두 이 접근으로 수렴합니다. Blast radius는 줄고, rollback은 즉시 가능해지며, 팀은 분기 단위가 아니라 주간 단위로 ship할 수 있습니다. 특히 "주니어 엔지니어 테스트"가 중요합니다. 새벽 2시에 on-call인 사람이 war room 없이도 나쁜 기능을 끌 수 있어야, 그 rollout plan은 진짜로 견고한 것입니다.

이 프롬프트의 작동 방식

이 프롬프트는 internal → beta → canary 1% → canary 10% → GA 순서로 cohort 노출을 설계하고, 각 단계마다 promotion criteria와 kill criteria, automation rule을 명시합니다. 특히 "canary-in-the-coalmine" metric, 즉 사용자 눈에 띄는 회귀가 드러나기 전에 먼저 움직이는 leading indicator를 찾게 만드는 점이 핵심입니다. 이 지표가 있어야 1% 단계에서 문제를 포착하고 10%까지 퍼지기 전에 막을 수 있습니다.

언제 사용할까

• 핫패스를 건드리는 기능을 출시할 때
• 이전 출시가 몇 시간 동안 프로덕션 회귀를 일으켰을 때
• 주니어 엔지니어 온콜 로테이션이 시작되며 rollback이 특정 시니어에게 의존하면 안 될 때
• 리더십이 blast radius를 키우지 않으면서 주간 출시 속도를 높이고 싶어 할 때
• 실험 시스템을 세우는 중이고 flagging 패턴을 공식화해야 할 때

흔한 함정

• 테스트되지 않은 kill-switch. 한 번도 테스트하지 않은 kill-switch는 그냥 희망사항입니다. 롤아웃 전에 반드시 검증하세요.
• Metric 없는 promotion criteria. "괜찮아 보여요"는 기준이 아닙니다. 숫자 threshold를 미리 커밋하세요.
• 너무 많은 자동화. Error rate 자동 rollback은 표준이지만, activation metric 자동 rollback은 위험할 수 있습니다. 애매한 metric은 사람이 최종 판단하도록 남겨 두세요.

참고 자료

• The Linear Method — Linear
• Getting Real — Basecamp
• GitHub Developer Research — GitHub
• Optimizely Insights — Optimizely