이 글의 원문은 링크를 통해 확인할 수 있습니다. 이미지 또한 해당 출처에서 가져옴을 알립니다.
피처 플래그란?
피처 플래그(또는 피처 토글이라고도 불립니다.)는 새로운 코드를 배포하지 않고도 런타임에 특정 키능을 켜고 끌 수 있는 기술을 말합니다. 이 기술은 추가 코드를 푸쉬하지 않고도 변경을 일으킬 수 있으며 기능의 라이프 사이클 내에서 좀 더 정교한 실험을 가능하게 합니다. 이러한 이유로 피처 플래그를 통해 애자일 관리와 CI/CD 환경에서 매우 유용하게 사용할 수 있는 워크 플로우를 만들 수 있습니다.
개발 중에 소프트웨어 에니니어들은 요구하는 코드 경로를 피처 플래그로 감쌉니다. 아래에 있는 예시는 자바스크립트로 쓰인 피처 플래그입니다.
if(featureFalgs['new-cool-feature'] == true) {
renderNewCoolFeature()
}이 코드는 new-cool-feature가 가능한 지 확인합니다. 만약에 플래그 데이터나 논리 경로를 주입하거나 제거하는 것을 도와주는 프레임워크나 툴이 나왔다고 해도 피처 플래그는 if 선언문만 있으면 됩니다. 이렇게 둘 중 하나를 보는 방식은 모든 이야기에서 공통적으로 가지고 있는 얘기 입니다.
피처 플래그의 장점
기본적으로 피처 플래그는 코드를 커밋하고 코드를 활성화하지 않은 상태로 프로덕션에 내보냅니다 그리고 나중에 활성화 합니다. 이것이 뜻하는 바는 사용자 경험과 이미 내보낸 제품에 대한 통제권을 더 쥘 수 있습니다. 개발팀은 어떤 유저들에게 새로운 코드를 제공할 것인지 선택할 수 있습니다.
선택 기능 활성화
개발팀은 피처 플래그를 통해 새로운 제품 기능에 소프트 롤아웃을 수행할 수 있습니다. 새로운 기능은 그 기능이 반영될 예정일 릴리즈에 바로 통합될 수 있습니다. 피처 플래그는 기본적으로 꺼진 상태가 기본입니다. 이렇게 함으로써 피처 플래그가 명시적으로 활성화될 때까지 프로덕션에 잠재되어 있을 수 있습니다. 팀에서 피처 플래그를 통해 어떤 코드를 활성화할지 결정했다면 QA를 수행할 수 있도록 하고 기대된 동작이 정상적으로 수행되는 지 확인할 수 있습니다. 만약 QA 팀에서 기능 수행 도중 문제를 발견했다면 즉각적으로 피처 플래그를 꺼서 새로운 코드를 비활성화 시킴으로써 유저에게 문제가 노출되는 것을 최소화 할 수 있습니다.
위험 부담 최소화
위에서 얘기한 소프트 롤아웃을 기반으로, 성실한 팀원들이 피처 플래그를 시스템에 주입함으로써 모니터링과 관찰 가능한 간헐적 이슈에 대응하는 것이 가능합니다. 예를 들어 애플리케이션에서 트랙픽이 증가하고 모니터링 시스템에서 문제가 증가했다고 보고하는 경우 팀에서 피처 플래그를 통해서 저성능 기능을 끌 수 있습니다.
방해되는 변경없이 시스템 수정하기
피처 플래그는 복잡한 코드 통합과 배포 시나리오를 최소화할 수 있습니다. 어려운 새 기능이나 조심해야 할 수정 사항을 레포지토리의 프로덕션 메인 브랜치에 머지하는 것이 어려울 수 있습니다. 만약 한 코드 베이스에서 여러 작업자가 동시에 작업한 경우엔 더 힘들 수 있습니다.
피처 플래그는 새로운 변경 사항에과 안정적인 코드를 분리하는데에 사용될 수도 있습니다. 피처 토글을 두고 메인 브랜치에서 커밋을 자주 할 수 있게 되면서 기능 브랜치가 오랫동안 살아있는 것을 막습니다. 새로운 코드가 다른 머지를 기다리거나 배포 시나리오에 영향이 가지 않는다면 팀에선 피처 플래그를 토글하여 새로운 시스템을 활성화할 수 있습니다.
피처 플래그의 사용처
피처 플래그의 유용한 활용성은 비즈니스 요건에 따라 다양한 유즈 케이스를 생성할 수 있다는 것입니다. 아래에 나오는 예시들은 애자일 환경에서 가장 잘 사용되는 피처 플래그의 기능들입니다.
제품 테스트
피처 플래그는 새로운 제품 기능들을 점진적으로 릴리즈할 수 있습니다. 이는 제안된 새로운 기능이 유저에게 보였을 때, 리소스를 투자할 가치가 있었는 지 검토할 때 유용합니다. 팀에서는 새로운 제품의 기능이나 부분적 아이디어를 특정 집합의 사용자들에게 배포하여 피드백을 받을 수도 있습니다. 특정 집합에 속한 사용자들은 아마 베타 테스트나 리뷰를 좋아하는 유저들일 수도 있습니다. 만약 새로운 제품 아이디어가 반응이 좋았다면 개발 팀이 좀 더 넓은 유저층으로 피처 플래그를 활성화 할 수 있습니다. 만약 새로운 제품 아이디어가 별로라면, 개발 팀에서 쉽게 해당 피처 플래그를 제거할 수 있고 추후에 코드베이스에서 지울 수 있습니다.
실험 설계
실험이나 A/B테스트는 피처 플래그의 기본적인 예시입니다. 가장 간단한 양식으로 피처 플래그가 토글로써 두 상태만 존재할 수 있습니다. 더 나아간 피처 플래그는 다양한 플래그 값을 사용함으로써 특정 집단의 사용자에게 다른 경험을 선사할 수 있습니다. 예를 들어, 여러분이 유저를 세 개의 집단으로 나눈다고 생각해봅니다. 각각의 집단은 다른 피처 플래그 값을 받음과 동시에 다른 유저 경험을 하게 됩니다. 이 세개의 플래그를 분석함으로써 어떤 것을 최종적으로 반영할지 결정할 수 있습니다.
마이그레이션
의존하는 애플리케이션의 코드가 바뀌면서 데이터 마이그레이션이 필요한 경우가 있습니다. 이러한 다단계 배포 시나리오는 특히 유의해야합니다. 데이터베이스의 필드가 애플리케이션 데이터 베이스에 수정, 삭제, 추가될 수 있습니다. 만약 애플리케이션 코드가 이러한 데이터베이스 변경에 준비되지 않을 경우, 에러와 실패를 야기할 수 있습니다. 이러한 일이 일어날 경우 데이터베이스 변경과 관련된 배포를 조정해야 합니다.
피처 플래그는 팀들에게 향상된 애플리케이션 변경에 대해서 준비할 수 있도록 하여 이러한 시나리오 내에서 복잡성을 줄일 수 있도록 합니다. 일단 팀에서 데이터베이스를 변경하면 그와 관련된 애플리케이션 코드를 즉시 작동시킵니다. 이 작업은 (데이터베이스와 싱크를 맞춘) 새로운 코드 배포 시간을 단축시킵니다. 더하여 애플리케이션과 데이터 베이스가 맞지 않을 위험과 빌드가 실패할 가능성도 낮춰줍니다.
Canary launches
이 문맥내에서 카나리아는 탄광부들이 일산화탄소를 감지하기 위해 카나리아 새를 탄광으로 데려온 오래되고 병적인 관행을 이야기합니다. 카나리아는 사람보다 더 높은 신진대사율과 빠른 호흡을 가지고 있어 광부들보다 먼저 일산화탄소에 굴복했습니다.
소프트웨어 카나리아 출시란 새로운 기능이나 수정 사항을 전체 유저에게 배포하기 전에 작은 집합의 유저들에게 기능을 출시하고 이를 모니터링 하는 것을 말합니다. 만약 새로운 기능이 알지 못했던 에러나 실패를 보여준다면 자동적으로 롤백을 수행합니다. 피처 플래그는 사용자 집합을 제한하거나 기능을 끄는 것을 쉽게 하도록 도와줍니다.
시스템 중단
피처 플래그는 시스템을 중단하는 도구로도 사용할 수 있습니다 웹 애플리케이션에서 유지 관리를 위해 피처 플래그를 통해 전체 웹사이트를 닫아버릴 수 있습니다. 피처 플래그는 코드 베이스를 통해 조작될 수 있으며, 유저에게 중단한다는 내용을 보여줄 수 있습니다. 이 경우 중대한 배포를 하고 있는 중이나 제품에서 긴급한 이슈가 발생한 경우에 유용하게 사용할 수 있습니다. 이렇게 하면 필요한 경우 팀에게 통제된 중단을 하게 할 수 있으며 자신감을 얻게 할 수 있습니다.
CD(Continuous deployment)
피처 플래그는 지속적인 배포 시스템에서 통합 가능한 컴포넌트를 만드는데에 사용할 수 있습니다 지속적인 배포란 자동화된 파이프라인으로 새로운 개발이 이루어지면 자동적으로 배포를 수행하여 유저에게 보여지는 것을 말합니다. 지속적인 배포는 자동화 테스트에 의존하고 있습니다. 파이프라인 내에서 자동화된 태스트를 통해 새로운 코드가 예상된 동작을 수행하는 지 알 수 있습니다.
피처 플래그는 코드 변경을 유저에게 보여지는 기능에 따라 구분함으로써 지속적인 배포를 더 안전하게 만들어 줍니다. 새로운 코드는 자동적으로 머지되고 비활성화된 상태로 프로덕션에 반영됩니다. 지속적인 배포 시스템은 유저의 행동과 트래픽을 모니터 할 수 있습니다. 그리고 그 결과에 따라 피처 플래그를 자동적으로 활성화할 수 있습니다. 반대로 지속적인 배포 시스템은 새로운 피처 플래그코드가 정상적오르 동작하는 지 확인하고 그렇지 않을 시 되돌릴 수 있습니다.
피처 브랜치 vs 피처 플래그
둘의 이름은 비슷하지만 피처 브랜치와 피처 플래그는 꽤 다릅니다. 피처 브랜치는 워크플로우 패턴입니다(깃 소스 관리와 관련된). 개발자가 새로운 제품 기능을 만들기 시작한다면 그들은 메인브랜치에서 그에 상응하는 깃 브랜치를 생성하고 이를 다시 메인 브랜치에 머지하여 배포합니다. 피처 브랜치들은 피처플래그와 완전히 다른 개념입니다.
피처 플래그는 피처 브랜치와 같이 사용될 수 있습니다. 피처 플래그를 생성하기 위해 개발자가 피처 브랜치에서 새로운 피처 플래그 코드를 추가합니다. 피처 브랜치가 머지되고 피처 플래그와 함께 배포되면 프로덕션에서 피처 플래그를 조작할 수 있습니다.
피처 브랜치를 개발하는 동안,기반으로 하는 프로젝트는 수명이 너무 오래되었거나 메인 브랜치에서부터 분리되어 수많은 커밋을 내포하고 있을 수 있습니다. 개발자들은 수시로 메인브랜치를 업데이트 함으로써 최소한의 충돌로 머지되도록 대비해야합니다. 이러한 대비는 개발자들에게 추가 리소스를 쓰도록 합니다. 이러한 상황을 피처 플래그가 해결해 줄 수 있습니다. 긴 수명의 피처 브랜치를 사용하는 것과 새 기능이 준비될 때까지 계속 머지하는 것 대신 피처 플래그를 생성하고 메인에 바로 머지할 수 있습니다.
피처 플래그 생성 방법
고려상황과 이점에 따라 피처 플래그를 생성하는 다양한 방법이 있습니다. 팀의 필요상황과 조직의 목표에 따라 방법을 다르게 설정합니다.
피처 플래깅(Feature Flagging)이 제대로 동작하기 위해선 일부 인프라에 종속성을 가질 수 있습니다. 팀에서 피처 플래그의 사용을 늘리과 하며 플래그를 켜고 끄는 것이 비즈니스 결정으로 이루어진다면 데이터 사용 권한이나 저장 그리고 매커니즘을 관리하는 것이 중요합니다. 많은 서드파티 피처 플래그는 이러한 데이터 저장 의존성을 관리해줍니다.
서드파티에서 제공하는 피처 플래그 서비스가 주로 최고의 솔루션입니다. 그 서비스들은 어려운 논리들을 처리해주고 통합하기 좋고 설치 하기 쉬운 라이브러리를 제공합니다. 이는 팀원들이 인프라 종석성으로 인한 업무가 아닌 주요 비즈니스 업무를 다할 수 있도록 합니다.하지만 보안 상의 이유로 서드파티를 사용하기 어렵다면 보안 플래그를 백엔드에 구현하는 것이 좋습니다.
앞서 말한 것과 별개로 엔지니어들은 플래그된 컨텐츠를 서비스에서 활성화하기 위한 새로운 코드 로직을 작성해야 합니다. 이를 위해선 플래그 코드 활성화 이전에 머지하고 배포해야 합니다. 많은 피처 플래그들이 임시로 존재하기 때문에 더 이상 필요하지 않은 피처 플래그들은 제거하는 과정이 필요합니다.
결론
피처 플래그는 애자일 개발 환경에서 강력한 촉진제가 되어줍니다. 피처 플래그를 활용하는 방식에는 여러 방식이 있습니다. 피처 플래그는 CD와 깃 버전 관리에 도움을 줍니다. 전체적으로, 피처 플래그는 팀들에게 코드베이스, 배포 그리고 사용자 경험성에 더 많은 조작을 가능하도록 합니다.
감사합니다🙇♂️