피처 플래그

피처 플래그(Feature flag, 피처 토글이라고도 함)는 런타임 설정에서 값을 가져오는 코드 속 조건입니다. 이 사용자나 환경에 대해 플래그가 켜져 있으면 새 경로를, 아니면 기존 경로를 탑니다. 코드의 **배포(deploy)**와 기능의 **출시(release)**를 분리해 줍니다. 코드를 꺼진 상태로 프로덕션에 두었다가 내부 사용자, 고객의 10%, 전체 순으로 활성화하고, 문제가 생기면 몇 초 만에 다시 끌 수 있습니다.

예시

if (flags.isEnabled('new-checkout', { userId: user.id })) {
  return renderNewCheckout(cart);
}
return renderLegacyCheckout(cart);

플래그 서비스(상용 제품, 오픈 소스, 또는 자체 데이터베이스의 테이블)가 사용자별로 값을 결정하며, 주로 비율이나 속성을 기준으로 합니다.

테스트에 주는 의미

플래그 하나가 생길 때마다 그 코드를 지나는 경로의 수가 두 배가 됩니다. 테스터가 알아야 할 것은 다음과 같습니다.

• 어떤 플래그 상태들이 함께 배포되는지. “전부 켜기”만이 아니라 실제로 프로덕션에서 활성화될 조합을 테스트하세요.
• 활성 플래그 각각의 양쪽 경로. 플래그가 제거되기 전까지는 기존 경로도 여전히 프로덕션 코드이므로 회귀 스위트가 이를 커버해야 합니다.
• 전환 자체. 세션 도중 플래그를 켜거나 꺼도 데이터가 손상되거나 사용자가 흐름 중간에 갇혀서는 안 됩니다.
• 테스트에서의 제어. 자동화 테스트는 공유 환경의 현재 값에 의존하지 말고, 테스트 전용 API, 쿠키, 설정 오버라이드 등으로 플래그 값을 명시적으로 설정해야 합니다. 그렇지 않으면 누군가 플래그를 바꿨을 때 상관없는 테스트 실행이 깨지고, 이는 플래키 테스트와 똑같아 보입니다.

test('new checkout shows delivery slots', async ({ page, context }) => {
  await context.addCookies([
    { name: 'ff_new-checkout', value: 'on', url: 'https://staging.example.com' },
  ]);
  await page.goto('https://staging.example.com/checkout');
  await expect(page.getByRole('heading', { name: 'Choose a delivery slot' })).toBeVisible();
});

여기 쓴 쿠키 이름은 예시일 뿐이며, 실제로는 사용 중인 플래그 시스템이 제공하는 오버라이드 방식을 쓰세요.

흔한 실수

제거되지 않는 플래그가 장기적으로 가장 큰 비용입니다. 죽은 분기, 아무도 이해하지 못하는 조합, 조용히 썩어 가는 기존 경로가 남습니다. 릴리스 플래그는 담당자와 제거 날짜를 정한 임시 장치로 다루고, 롤아웃이 끝나면 선택되지 않은 분기와 그 테스트를 삭제하세요.