피처 플래그를 하드코딩해도 괜찮습니다 (2025)
It's OK to hardcode feature flags (2025)
피처 플래그 관리 소프트웨어는 강력할 수 있지만, 복잡성과 위험의 원천이기도 합니다. 마케팅 과대광고가 너무 심해서 불필요하다고 인정하는 것이 기술적 무능을 고백하는 것처럼 느껴질 정도입니다. 저자는 대부분의 팀과 제품에 대해 단순한 JSON 파일로 시작하는 하드코딩된 피처 플래그가 가장 간단하고 안정적이며 안전한 방법이라고 주장합니다. 런타임에 대규모로 기능을 변경해야 할 때가 오면 그때 필요성을 알게 될 것이며, 그때까지는 하드코딩이 최선의 선택입니다.
하드코딩된 피처 플래그는 이러한 문제를 대부분 해결합니다. 그것들은 단순하고, 안정적이며, 안전합니다. 그것은 가장 지루한 방법이며, 그래서 가장 좋은 방법입니다.
HN 토론
43- jameshart
제 경험상, (구성 기반의 피처 플래그와 피처 플래그 서비스)는 실제로는 완전히 다른 두 가지 문제를 해결하는 상호 보완적인 두 가지 기능인데, 우연히 같은 이름인 '피처 플래그'를 공유하고 있습니다.
구성 방식은 피처 플래그를 소프트웨어 개발 수명 주기 도구로 사용하는 데 중요합니다. 새 기능 x의 미완성 코드가 포함된 코드베이스를 관리하면서도, 기능 x를 켜지 않고도 배포하고 모든 테스트를 통과할 수 있게 하는 방법입니다.
이 모델에서는 기능 x를 작업하는 개발자가 로컬 테스트를 위해 그 기능을 활성화할 수 있는 메커니즘과, CI 시스템이 플래그 시스템과 상호 작용하여 x가 켜진 상태와 꺼진 상태 모두에서 애플리케이션이 작동하는지 테스트할 수 있는 메커니즘이 필요합니다.
이는 트렁크 기반 개발 모델에 이상적입니다. 기능 브랜치는 이 방식의 이점을 별로 얻지 못하는 대안적 접근 방식입니다(실제로 기능 브랜치 작업에 복잡성을 더합니다).
한편, 피처 플래그 서비스는 같은 소프트웨어를 사용하는 서로 다른 사람들이 서로 다른 기능을 켜야 하는 문제를 해결하기 위한 것입니다. 이는 내부 테스터나 베타 사용자만을 위한 것일 수도 있고, 테넌트별로 고정된 업데이트 창에 기능을 출시하기 위해 보류하는 것일 수도 있으며, 점진적 노출을 통해 기능을 출시하는 위험 관리 전략의 일부일 수도 있습니다.
또한 피처 플래그 시스템을 A/B 테스트 시스템과 혼동하고 싶은 유혹이 있을 수 있습니다. 피처 플래그 서비스를 사용하여 테스트 코호트에 기능을 노출할 수 있지만 [...]
- jdwyah
저는 두 번째 피처 플래그 스타트업을 하고 있지만, 이 글에 어느 정도 동의합니다.
모든 프로젝트에는 플래그가 있어야 하지만, 많은 프로젝트는 기본적인 것만 필요하며 서비스는 과할 수 있습니다.
자체적으로 JSON을 만드는 것은 여전히 피해야 할 것 같습니다. 처음에는 95%가 불리언이지만, 그러다가 롤아웃을 원하게 되고, 타겟팅 규칙을 원하게 되고, 불리언이 아닌 것(예: JSON)을 원하게 됩니다. JSON이 스키마를 따를 수 있다면 좋지 않을까요? 그러다 결국 배포 없이 이것들을 변경하고 싶어지거나, 여러 서비스에서 같은 플래그를 읽고 싶어집니다.
저는 이 최소 공통 분모를 https://quonfig.com 에 통합하려고 노력했습니다. 완전 무료이며 오픈 소스 SDK로 사용할 수 있고, git에서 추적할 수 있는 JSON을 로드하는 것뿐입니다. 에이전트들이 좋아하고, 핫 리로드, 다양한 언어의 SDK를 지원합니다. 하지만 자체 구현에 비해 설계 여지가 많습니다. 다양한 타겟팅 연산자, 세그먼트 등이 있습니다. 그리고 실시간 업데이트를 위한 멋진 UI/전송 네트워크를 원한다면 유료 측면을 사용할 수 있습니다.
로컬 사용 설명: https://docs.quonfig.com/docs/how-tos/open-source-local
- avlcodemonkey
C#으로 작업 중이라면, Microsoft는 .NET에서 피처 관리를 위한 일급 지원을 추가했습니다: https://github.com/microsoft/featuremanagement-dotnet. 간단한 켜기/끄기, 사용자 타겟팅, 백분율 롤아웃, 일정 관리를 위한 로직을 제공합니다. 피처 관리와 함께 `appSettings.json`에 하드코딩된 플래그를 사용하는 것은 더 간단한 애플리케이션에 완벽하게 적합합니다.
아키텍처가 성장하고 여러 애플리케이션 간에 구성을 동기화해야 하거나, 비기술적 사용자가 플래그를 변경해야 하는 경우, 하드코딩을 벗어나 서비스 구축(또는 구매)을 고려해야 할 것입니다. 제품 소유자가 `FeatureManagement__NewFeature__EnabledFor__0__Name` 같은 환경 변수를 설정하려고 하면 안 될 것입니다. Azure를 사용할 의향이 있다면 Azure App Configuration이 가장 적합합니다. JSON을 다루는 대신 플래그를 편집할 수 있는 멋진 UI를 제공합니다. 또는 Azure를 피하고 싶다면 대안 제공자로 https://featureflags.app/ 을 구축하고 있습니다. 이는 하드코딩과 LaunchDarkly 같은 본격적인 플랫폼 사이의 중간 지점입니다.
- maxidog
저는 현재 대규모 엔터프라이즈 앱을 리버스 엔지니어링하고 있는데, 피처 플래그 비대화가 정말 놀랍습니다. 제 생각에 과도한 피처 플래그 복잡성은 결정을 내리지 못하고 개발자들에게 신뢰를 받지 못하는 관리진의 증상입니다.
- stronglikedan
물론 Knight Capital의 경우는 예외입니다. https://www.youtube.com/watch?v=UuqSy1jPSUw