기능 플래그
기능 플래그를 통해 기능을 점진적으로 노출하는 방법.
Ian Buchannan
수석 솔루션 엔지니어
개발 중에 애플리케이션에 기능을 지속적으로 통합할 계획이라면 기능 플래그를 고려해 보는 것이 좋습니다. 결국 기능을 토글하고 숨기거나 사용 중지하거나 사용 설정하고 싶을 수도 있습니다. 어떤 것이 더 나은지 알아보기 위해 사용자에게 기능의 다양한 변형을 공개하는 것도 좋습니다. “토글”, “비트”, “플리퍼”, “스위치”라고도 하는 기능 플래그를 통해 이 작업과 그 이상을 할 수 있습니다.
기능 플래그란?
기능 플래그(일반적으로 기능 토글이라고도 함)는 새 코드를 배포하지 않고 런타임 중에 일부 기능을 활성화 및 비활성화하는 소프트웨어 엔지니어링 기술입니다. 팀은 이 기능을 통해 추가 코드를 푸시하지 않고도 변경 사항을 적용할 수 있으며 기능의 수명 주기 동안 보다 통제된 실험을 할 수 있습니다. 따라서 기능 플래그로 애자일 관리 스타일과 CI/CD 환경에 매우 유용한 여러 새로운 워크플로를 사용할 수 있습니다.
개발 과정에서 소프트웨어 엔지니어는 원하는 코드 경로를 기능 플래그에 래핑합니다. 다음은 Javascript로 작성된 기본 기능 플래그의 예시입니다.
if(featureFlags[‘new-cool-feature’] == true){
renderNewCoolFeature();
} 이 코드는 “new-cool-feature”가 사용 설정되었는지 확인하는 간단한 명령문을 보여줍니다. 플래그 데이터나 새 로직 경로의 삽입과 제거를 관리하는 데 도움이 되는 고급 프레임워크와 도구가 있어도 기능 플래그는 기본적으로 "if 문"에 불과합니다. 따라서 이 바이너리 스위치는 모든 동의어가 공통적으로 가지고 있는 것입니다.
솔루션 보기
Open DevOps로 소프트웨어를 구축 및 운영
관련 자료
트렁크 기반 개발에 대해 알아보기
기능 플래그의 이점
기초적인 수준에서 기능 플래그를 사용하면 코드를 커밋하고 휴면 상태의 프로덕션에 배포한 다음 나중에 활성화할 수 있습니다. 그러면 팀이 최종 제품의 사용자 경험을 더 효과적으로 제어할 수 있습니다. 개발팀은 새 코드를 사용자에게 언제 어떻게 제공할지 선택할 수 있습니다.
기능 검증
개발자는 기능 플래그를 활용하여 신제품 기능의 “소프트 롤아웃”을 수행할 수 있습니다. 예상 릴리스의 일부로 기능 토글을 즉시 통합하여 새 기능을 구축할 수 있습니다. 기능 플래그는 코드가 배포되면 프로덕션 중에는 휴면 상태로 유지되고 기능 토글이 명시적으로 활성화될 때까지 새 기능이 사용 중지되도록 기본적으로 "비활성화"된 상태로 설정할 수 있습니다. 그런 다음 팀에서 기능 플래그를 언제 활성화할지 선택하여 코드가 활성화되면 팀에서 QA를 수행하고 예상대로 동작하는지 확인할 수 있습니다. 이 과정에서 문제를 발견하면 즉시 기능 플래그를 비활성화하여 새 코드를 사용 중지하고 문제에 대한 사용자 노출을 최소화할 수 있습니다.
위험 최소화
위에서 논의한 소프트 롤아웃이라는 아이디어를 바탕으로 근면한 팀은 간헐적으로 관찰되는 모든 이슈에 대응하기 위해 기능 플래그를 시스템 모니터링 및 메트릭과 함께 활용할 수 있습니다. 예를 들어 애플리케이션 트래픽 급증이 발생했는데 모니터링 시스템에서 이슈 급증을 보고하면 팀은 기능 플래그를 사용하여 성능이 낮은 기능을 사용 중지할 수도 있습니다.
운영 중단 없이 시스템 동작 수정
기능 플래그는 복잡한 코드 통합과 배포 시나리오를 최소화하는 데 사용할 수 있습니다. 복잡한 새 기능이나 민감한 리팩터링 작업은 리포지토리의 메인 프로덕션 브랜치에 통합하기 어려울 수 있습니다. 여러 개발자가 코드베이스에서 겹치는 부분을 작업하면 더욱 복잡해집니다.
알려져 있고 안정적인 코드를 그대로 유지하면서 기능 플래그를 사용하여 새 변경 사항을 분리할 수 있습니다. 그러면 개발자가 기능 토글 뒤에 있는 리포지토리의 메인 브랜치에 자주 커밋하기 때문에 기능 브랜치가 오래 유지되지 않도록 할 수 있습니다. 새 코드가 준비되면 중단이 요구되는 협업 중심의 병합 및 배포 시나리오가 필요하지 않으며 팀에서 기능 플래그를 활성화하여 새 시스템을 사용할 수 있습니다.
기능 플래그 사용 사례
기능 플래그의 참신한 유용성 덕분에 근면한 팀에서는 다양하고 창의적인 사용 사례를 사용할 수 있습니다. 다음 예에서는 애자일 환경에 기능 플래그를 적용한 몇 가지 인기 사례를 강조합니다.
제품 테스트
기능 플래그는 새 제품 기능을 단계적으로 릴리스하는 데 사용할 수 있습니다. 제안된 새 기능을 사용자가 채택할지, 투자 대비 효과가 있을지는 불확실할 수 있습니다. 팀은 새 제품 기능이나 기능의 일부 아이디어를 기능 플래그에 포함하여 릴리스하고 일부 사용자에게 배포하여 피드백을 수집할 수 있습니다. 사용자 중 일부는 적극적으로 베타 테스트를 하고 검토하여 의견을 내는 파워 유저일 수도 있습니다. 신제품 아이디어가 성공적이면 개발 팀은 더 큰 사용자층에 기능 플래그를 배포할 수 있습니다. 새 제품 아이디어가 실패인 것으로 드러나면 개발 팀은 기능 플래그를 쉽게 사용 중지하고 나중에 코드베이스에서 제거할 수 있습니다.
실험 진행
기능 플래그의 주요 예시는 실험이나 A/B 테스트입니다. 기능 플래그의 가장 단순한 형태에서는 기능의 '활성화된' 상태와 '비활성화된' 상태를 전환하는 역할을 합니다. 고급 기능 플래그는 한 번에 여러 플래그를 활용하여 사용자의 하위 집합에 대해 다양한 경험을 활성화합니다. 예를 들어 사용자층을 3분의 1로 나눈다고 상상해 보세요. 3분의 1마다 고유한 플래그와 사용자 경험이 주어집니다. 그런 다음 이 세 플래그의 성능을 서로 비교하여 측정하여 최종으로 커밋할 버전을 결정할 수 있습니다.
마이그레이션
애플리케이션에 종속 애플리케이션 코드 변경이 요구되는 데이터 마이그레이션이 필요한 경우가 있습니다. 이 시나리오는 여러 단계에 걸친 민감한 배포 작업입니다. 데이터베이스 필드는 애플리케이션 데이터베이스에서 수정, 제거 또는 추가할 수 있습니다. 애플리케이션 코드가 데이터베이스 변경에 대비되지 않으면 실패 및 오류가 발생합니다. 이런 일이 발생하면 데이터베이스 변경 사항과 애플리케이션 코드 간의 조정된 배포가 필요합니다.
기능 플래그는 팀이 기능 플래그로 애플리케이션 변경을 미리 준비할 수 있도록 하여 이 시나리오의 복잡성을 줄일 수 있습니다. 팀에서 데이터베이스를 변경하면 애플리케이션 코드에 맞게 기능 플래그를 즉시 전환하여 토글할 수 있습니다. 그러면 새 애플리케이션 코드 배포를 기다리거나 잠재적으로 배포에 실패하고 데이터베이스에서 애플리케이션 동기화가 해제되는 위험과 지연이 없어집니다.
카나리아 제공
이 맥락에서 카나리아는 석탄 광부가 일산화탄소를 감지하기 위해 유독가스에 민감한 카나리아 새를 탄광에 데리고 들어왔던 슬픈 옛 관행을 가리킵니다. 새는 기초대사율이 더 높고 호흡도 빠르기 때문에 광부보다 일산화탄소에 먼저 반응하여 쓰러졌습니다.
소프트웨어 개발에서 카나리아 제공은 전체 사용자에게 릴리스하기 전에 소수의 사용자에게 새 기능이나 코드 변경을 배포하여 동작을 모니터링할 때 이루어집니다. 새 기능에 오류 또는 실패의 징후가 보이면 자동으로 롤백됩니다. 기능 플래그는 사용자 풀을 제한하고 기능을 쉽게 비활성화할 수 있기 때문에 이 프로세스에 꼭 필요합니다.
시스템 중단
기능 플래그는 시스템 중단 도구로도 사용할 수 있습니다. 웹 애플리케이션은 유지 관리나 가동 중지 시간 때문에 기능 플래그를 사용하여 전체 웹사이트를 “비활성화”할 수 있습니다. 이 기능 플래그는 코드베이스 전체에 적용되어 민감한 트랜잭션을 푸시하고 최종 사용자에게 중단 콘텐츠를 표시할 수 있습니다. 민감한 배포를 할 때나 예상치 못한 문제가 발견되어 긴급히 해결해야 할 때 아주 유용할 수 있습니다. 팀은 필요한 경우 통제된 중단을 할 수 있는 자신감과 능력을 얻게 됩니다.
지속적 배포
기능 플래그는 진정한 지속적 배포 시스템을 구축하기 위한 필수 컴포넌트로 사용할 수 있습니다. 지속적 배포는 개발자로부터 새 코드를 가져와 프로덕션 최종 사용자에게 자동으로 배포하는 자동화된 파이프라인입니다. 지속적 배포는 새 코드가 파이프라인을 통해 이동할 때 일치하는 사양에 대해 예상대로 작동하는지 확인하는 자동 테스트 계층에 따라 다릅니다.
기능 플래그는 코드 변경과 사용자에게 공개하는 기능을 분리하여 지속적 배포를 더 안전하게 만들어줍니다. 새 코드는 자동으로 병합하여 프로덕션에 배포한 다음 기능 플래그 뒤에서 기다릴 수 있습니다. 지속적 배포 시스템은 사용자 행동 및 트래픽을 모니터링한 다음 기능 플래그를 자동으로 활성화할 수 있습니다. 반대로 지속적 배포 시스템은 새 기능 플래그 코드를 모니터링하여 예상대로 작동하는지 확인하고 그렇지 않으면 롤백할 수 있습니다.
기능 브랜치와 기능 플래그 비교
이름은 비슷하지만 기능 브랜치와 기능 플래그는 상당히 다릅니다. 기능 브랜치는 워크플로 패턴으로, Git 소스 제어 리포지토리와 관련이 있습니다. 개발자는 새 제품 기능을 시작하면 메인 브랜치에서 벗어난 새 해당 Git 브랜치를 만들어 새 기능에 대한 모든 코드를 포함합니다. 개발자는 새 기능을 완료하면 기능 브랜치를 다시 메인에 병합하고 배포합니다. 기능 브랜치는 기능 플래그와는 별개이며 독립적입니다.
기능 플래그는 기능 브랜치와 함께 사용할 수 있습니다. 기능 플래그를 만들려면 개발자가 기능 브랜치를 만들고 새 기능 플래그 코드를 기능 브랜치에 커밋합니다. 그런 후에는 기능 브랜치가 병합 및 배포되며 프로덕션에서 기능 플래그에 액세스할 수 있게 됩니다.
기능 브랜치 개발 중에는 프로젝트의 수명이 길어지거나 메인 브랜치에서 벗어나 수많은 커밋을 포함하게 될 수 있습니다. 개발자는 병합할 준비가 되었을 때 충돌을 최소화하도록 기능 브랜치를 계속 업데이트해야 합니다. 기능 브랜치를 병합할 때가 되면 충돌이 최소화되도록 기능 브랜치를 지속적으로 업데이트하기 위해서는 개발자의 추가적인 노력이 필요합니다. 기능 플래그는 이 시나리오를 해결하는 데 사용할 수 있습니다. 수명이 긴 기능 브랜치를 만들고 새 기능이 준비되었을 때 대규모 병합을 하는 대신 기능 플래그를 만들어 즉시 메인에 병합할 수 있습니다.
기능 플래그를 구현하는 방법
실행과 관련된 여러 고려 사항과 여러 투자 대비 효과(ROI)가 있으므로 기능 플래그를 구현하는 방법은 다양합니다. 가야 할 길은 팀의 요구 사항과 조직 차원의 목표에 따라 다릅니다.
기능 플래그에는 제대로 작동하려면 해결해야 하는 인프라 종속성이 있습니다. 팀에서 기능 플래그의 사용 규모를 조정하고 플래그 활성화/비활성화가 비즈니스와 관련된 결정이 되면 신뢰할 수 있는 데이터 저장소와 플래그 관리 메커니즘을 갖추는 것이 중요해집니다. 여러 타사 기능 플래그 서비스에서 데이터 저장소 종속성을 제공합니다.
타사 호스팅 기능 플래그 서비스가 가장 좋은 솔루션인 경우가 많습니다. 무거운 실행을 처리하고 설치 프로세스를 가속화하는 통합하기 쉬운 라이브러리를 제공합니다. 그러면 팀은 인프라 관리 대신 핵심적인 비즈니스 업무에 집중할 수 있습니다. 하지만 팀에 타사 보안 문제가 있는 경우에는 보안 플래그 백엔드를 구현하는 것이 최선일 수도 있습니다.
이와 별도로 엔지니어는 서비스에서 플래그 상태를 가져와서 플래그가 지정된 콘텐츠를 활성화하는 새 코드 로직을 만들어야 하며 활성화하기 전에 코드 병합과 플래그 코드 배포가 필요합니다. 많은 기능 플래그는 일시적이기 때문에 더 이상 필요하지 않은 기능 플래그는 삭제하는 것을 잊지 마세요.
결론...
기능 플래그는 애자일 개발 무기고에 강력한 추가 기능입니다. 기능 플래그는 여러 창의적인 방법으로 활용할 수 있습니다. 기능 플래그는 지속적 배포와 Git 버전 제어를 보완해 줍니다. 전반적으로 기능 플래그는 팀이 코드베이스, 배포, 최종 사용자 경험을 더 효과적으로 제어할 수 있도록 만들어 줍니다.
Open DevOps 도구 체인의 모범 사례를 보여주는 DevOps 기능 플래그 자습서를 확인하세요.
이 문서 공유
다음 주제
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
DevOps 커뮤니티
블로그 읽기
