feature flags를 도입하기까지

feature flags라는 키워드를 처음 보게 된 건 트래블월렛 프론트엔드 팀에서 Trunk Based Developement(TBD) 전략을 통해 단일 브랜치를 사용하고 있다는 인터뷰 아티클이 그 시작이었다.

 

지속적 배포를 위한 git 전략을 연구 중에 있습니다.
trunk based development라는 전략인데요 단일 브랜치로 배포 전략을 구성하는 것입니다.
작업 주기를 짧게 가져 바로 메인 브랜치에 머지 되고 배포 되는 방식이어서 개발자가 부담 없이 하루에도 몇번 씩 배포할 수 있는 환경을 구축하려고 합니다.

출처: https://travel-wallet.career.greetinghr.com/interview16

 

 

이게 어떻게 가능한 거지? 생각하며 조금 더 찾아보니 feature flags라는 키워드가 나왔고, 구현 중이거나 QA 중인 기능은 toggle처럼 on/off를 할 수 있다는 거였다. 우리 프로젝트는 단일 브랜치는 아니었지만 구현 중인 기능과 QA를 하는 기능, QA 중에 다시 롤백해야 하는 기능들이 얽히고 설켜가는 와중이어서 특정 기능을 각 서버 환경에 맞추워 on/off로 간단하게 제어할 수 있으면 좋겠다는 생각을 하게 되었다. 

 

아래의 구현 방법은 feature flags의 통상적인 사용 방식(?)이라기보다 당시 우리 팀의 필요에 맞춰 구현한 방식이라고 봐주면 좋겠다. 

 

 

사용 목적 

위에서 언급했다시피 단일 브랜치는 아니었지만 여러 기능을 동시에 개발하고, QA 진행과 실운영 서버 release까지 여러 기능을 병렬적으로 관리해야 했다. 따라서 QA가 완료되지 않은 기능을 프로덕션 환경에서 사용자에게 노출하지 않도록 제어하면서도 단일 코드 베이스를 관리할 필요가 있었다. 

 

 

구현 방식

기본적으로는 환경 변수를 통해 특정 기능을 'true' 또는 'false'라는 boolean 값으로 제어한다. 

 

// .env 파일 
# feature flags
REACT_APP_NEW_FEATURE=true

 

// config.ts
export const featureFlags = {
  newFeature: import.meta.env.REACT_APP_NEW_FEATURE === 'true',
};

 

// 사용 예시
import { featureFlags } from '@/config';

export default function Component() {
  return featureFlags.newFeature && <NewFeatureComponent />;
}

 

 

이후에는 각 프로젝트의 운영 환경에 맞추어 github actions, docker 등을 활용해 환경 변수를 주입한다.