Feature Flag 는 왜 항상 쌓이나
만들 때보다 지울 때가 더 무서운 이유, 그리고 한 가지 처방
플래그가 죽지 않는 이유
막상 해보면 생성 비용이 0에 가깝다. 하루 이틀이면 플래그 하나 붙여서 배포 끝. 문제는 회수 비용이 비대칭이라는 점이다.
- 플래그 붙이는 사람 ≠ 플래그 아는 사람. 3개월 뒤 그 코드 건드릴 사람은 보통 다르다.
- “아직 롤아웃 중” 상태가 기본값이 된다. 100% 켜도 코드는 안 지운다.
- 레거시 플래그 하나 지우려면 의존 경로 추적, QA 재확인, 릴리즈 슬롯 필요. 신규 기능 대비 ROI 가 0으로 보인다.
- 분기 회의에서 “다음 스프린트에” 라는 말이 나온 순간 그 플래그는 6개월 더 산다.
우리 팀도 올해 기준 active 로 표시된 플래그 38개 중 실제 AB 실험 중인 건 4개였다. 나머지 34개는 누가 켜뒀는지조차 불분명.
보통은 이렇게 썩는다
생명주기를 정의해 둔 팀도 실제 집행은 흐릿하다.
- 만료일 필드를 LaunchDarkly 에 넣어도 알림을 아무도 안 본다.
flag_cleanup태스크를 백로그에 넣으면 우선순위가 계속 밀린다.- 플래그 삭제 PR 은 리뷰어가 소극적이다. “혹시 몰라서” 라는 댓글이 달린다.
- 오너십이 없다. 플래그를 만든 사람이 팀을 떠나면 그 플래그는 고아가 된다.
사실은 플래그 자체가 문제가 아니라 오너 부재가 문제다. README 에 “누가 이 플래그의 책임자인지” 한 줄 없으면 아무도 손 안 댄다.
다음 한 가지
플래그 생성 시 만료일 + 오너 슬랙 핸들 필수 입력. 만료일 D-7 에 오너한테 자동 DM. 이것만 해도 30% 는 제때 정리된다 — 우리 팀 6주 실험 결과.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.