설정값에서 OpenFeature까지, 피처 플래그는 어떻게 바뀌어 왔을까요

구조와 흐름

• 설정값으로 미완성 기능을 숨긴 뒤 배포와 공개를 분리한 초기 피처 플래그 활용
• 출시·실험·운영·권한 플래그로 목적과 유지 기간을 구분하는 관리 방식
• OpenFeature의 공통 평가 API와 Provider, OFREP의 원격 평가 요청·응답 규격

주의할 점

• 플래그 재사용, 오래된 코드 방치, 서버별 배포 누락과 검토 절차 부재가 겹친 Knight Capital 사고
• 출시 플래그의 만료일·제거 작업 관리와 stale flag 변경안의 담당자 검토 필요
• OpenFeature API 통일과 플래그 데이터·조건·평가 결과의 이식성은 별도 문제

선택 이유

• 플래그 관리 SaaS·오픈소스 도구로 중앙 제어와 사용자 조건 기반 점진 공개 지원
• 제품 교체 시 앱 호출부 수정 부담을 줄이는 Provider 추상화
• 배포 직후 내부 사용으로 검증한 뒤 고객 공개 범위를 넓히는 customer 0 방식

적용해볼 점

• 플래그 생성 시 용도, 담당자, 만료일, 제거 백로그를 함께 정의
• 배포 완료 여부와 이중 검토 절차 확인
• OFREP 지원 범위와 실험 단계 여부를 제품별로 확인