# 피처 플래그란? 솔로 개발자를 위한 쉬운 가이드

URL: https://whatshouldibuildnext.com/ko/journal/피처-플래그란
Type: blog
Locale: ko
Published: 2026-10-31
Updated: 2026-11-01

---

> 피처 플래그는 재배포 없이 뒤집을 수 있는 if 문입니다. 네 가지 종류, 실제 비용, 솔로 개발자가 건너뛰어야 할 때를 정리했습니다.

피처 플래그란 코드 안의 `if` 문인데, 그 문이 참일지 거짓일지를 코드 바깥에서 정하는 것입니다. 새 코드 경로를 꺼진 상태로 배포해 두고, 나중에 설정 파일, 데이터베이스 행, 플래그 서비스에서 값만 바꿔 켤 수 있습니다. 다시 배포할 필요가 없습니다. 이 기법 하나 덕분에 코드를 배포하는 일과 기능을 출시하는 일을 분리할 수 있고, 그래서 플래그는 여러분이 가질 수 있는 가장 싼 롤백 수단이기도 합니다.

두 번째 절반은 저도 힘들게 배웠습니다. 제 첫 플래그는 환경 변수에 있던 불리언 값이었고, 금요일 밤에 켜 두고는 11개월 동안 그 존재를 잊고 지냈습니다. 아무것도 깨지지 않았습니다. 바로 그게 문제이고, 곧 다루겠습니다.

## 코드에서 피처 플래그는 실제로 어떻게 생겼나요?

벤더 홈페이지가 보여주는 것보다 훨씬 작습니다. 대시보드를 걷어내면 플래그는 조회 하나와 분기 하나입니다.

`const flags = { newCheckout: false };

if (flags.newCheckout) {
  return renderNewCheckout(user);
}
return renderOldCheckout(user);`나머지는 전부 `flags`가 어디서 오고 누가 그 값을 바꿀 수 있는지에 관한 질문입니다. 파일 안의 상수는 배포해야만 바뀌니 목적에 어긋납니다. 환경 변수는 재시작해야 바뀝니다. 데이터베이스 행은 몇 초 만에 바뀝니다. 호스팅 서비스도 몇 초 만에 바뀌고, 거기에 사용자별 타겟팅, UI, 감사 로그까지 붙습니다.

실제로 까다로운 부분은 코드가 아니라 수명 관리입니다. 운영에 분기가 둘 있으면 테스트할 동작도 둘이고, 새벽 2시에 디버깅할 경로도 둘입니다. 그중 하나는 썩어 갈 운명입니다.

![빨간 손잡이가 달린 강철 제어판의 산업용 토글 스위치, 킬 스위치](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-11/9ca39f-i1.webp)

## 피처 플래그 네 가지 종류 중 무엇부터 필요할까요?

Martin Fowler의 [피처 토글 분류](https://martinfowler.com/articles/feature-toggles.html)가 여전히 가장 깔끔한 기준이고, 쓸모 있는 축은 각 종류를 얼마나 오래 살려 둘지입니다.

**릴리스 플래그**는 미완성이거나 위험한 작업을 숨깁니다. 일이 주 정도 살다가 옛 코드 경로와 함께 지웁니다. 가장 먼저 필요한 것이 이것입니다.

**운영 플래그**는 킬 스위치입니다. 무겁거나 깨지기 쉬운 기능(추천 위젯, 외부 API 호출 등)을 감싸서 부하가 걸렸을 때 배포 없이 끌 수 있게 합니다. 대부분은 금방 지우지만, 일부는 영원히 두어도 괜찮습니다.

**실험 플래그**는 A/B 테스트를 위해 사용자를 코호트로 나눕니다. 통계적으로 의미 있는 결과가 나올 때까지 살아 있으니 몇 시간에서 몇 주까지이고, 의미를 가지려면 실제 트래픽이 필요합니다.

**권한 플래그**는 요금제나 계정에 따라 기능을 제한합니다. Pro 등급이나 베타 그룹 같은 것들이죠. 몇 년씩 살아남을 수도 있는데, 그 시점이면 더 이상 플래그라기보다 권한(entitlement)이라서 제대로 된 데이터 모델이 필요합니다.

사용자가 40명인 솔로 개발자라면 릴리스 플래그와 킬 스위치 하나 정도면 충분합니다. 40명을 대상으로 한 실험 플래그는 데이터가 아니라 노이즈만 만듭니다. 측정할 지표와 표본 크기를 말할 수 있을 때까지는 건너뛰세요.

## 브랜치와 배포만으로는 못 푸는 문제를 플래그가 푸는 이유는?

세 가지뿐이고, 신경 쓸 가치가 있는 것도 그 셋뿐입니다.

**미완성 작업을 안전하게 머지하기.** 오래 살아남은 브랜치는 머지할 때 큰 전쟁이 됩니다. 플래그가 있으면 새 코드를 꺼 둔 채로 매일 main에 머지할 수 있습니다. 모두가 하나의 브랜치에 커밋하고, 플래그가 미완성 부분을 실어 나르는 트렁크 기반 개발의 엔진이 바로 이것입니다.

**점진적 롤아웃.** 먼저 나 자신에게 켜고, 다음은 사용자의 1%, 그다음 10%, 마지막에 전체에게 켭니다. Fowler는 사용자 ID를 100으로 나눈 나머지를 이용해 약 1% 카나리 코호트를 뽑는 방법을 설명합니다. 문제가 생기면 영향 범위가 전체 사용자 기반이 아니라 몇 명으로 줄어듭니다.

**빠른 되돌리기.** 배포를 롤백하려면 빌드, 파이프라인, 그리고 약간의 용기가 필요합니다. 플래그를 끄는 건 수정 한 번이면 됩니다. 나쁜 날에는 이 차이가 몇 분의 고생과 한 시간의 고생 차이입니다.

첫날부터 벤더가 필요한 건 아닙니다. 하지만 전부 규율이 필요합니다.

## JSON 파일로 충분할까요, 아니면 LaunchDarkly가 필요할까요?

JSON 파일이나 데이터베이스 테이블로도 충분합니다. 다음 중 하나가 참이 되기 전까지는요. 비개발자가 플래그를 뒤집어야 할 때, 비율 롤아웃이나 사용자별 타겟팅이 필요할 때, 누가 무엇을 바꿨는지 감사 기록이 필요할 때, 같은 플래그를 읽는 서비스가 둘 이상일 때입니다.

대략 이런 사다리를 한 칸씩 올라가겠습니다.

- 
상수와 환경 변수. 비용은 0입니다. 사이드 프로젝트의 첫 릴리스 플래그에 충분합니다.

- 
런타임에 읽는 `flags` 테이블이나 JSON 파일. 코드 열 줄이면 되고, 즉시 토글할 수 있으며, 벤더가 없습니다. 솔로 프로젝트를 놀라울 만큼 멀리 데려갑니다.

- 
오픈소스 또는 호스팅 플래그 서비스. 타겟팅 규칙, 점진적 롤아웃, 다른 사람도 쓸 수 있는 UI가 필요할 때입니다.

- 
엔터프라이즈 플랫폼. 컴플라이언스, 승인 절차, 수십 명의 엔지니어가 등장할 때입니다.

호스팅 도구는 3단계와 4단계를 담당합니다. LaunchDarkly가 기존 강자입니다. 가장 깊은 타겟팅과 거버넌스 기능을 갖췄고, 가격도 거기에 맞습니다.

Statsig은 플래그를 실험 및 프로덕트 분석과 묶어 줍니다. 플래그가 무엇을 했는지 측정하고 싶다면 이쪽이 맞습니다.

팀이 나 혼자라면 둘 다 건너뛰세요. 칸이 세 개인 표가, 한 분기에 두 번 열어 보는 대시보드보다 낫습니다. 수동 방식이 구체적인 대가를 치르게 했을 때에만 서비스를 고르세요. 예를 들어 늦은 밤에 프로덕션 설정을 고쳤다가 후회했을 때 말입니다.

알아 둘 만한 보험이 하나 있습니다. [OpenFeature](https://openfeature.dev/docs/reference/intro)는 CNCF 인큐베이팅 프로젝트로, 플래그를 평가하는 벤더 중립 API를 정의합니다. Node.js, Python, Go, Java, .NET, 웹 클라이언트 등의 SDK가 있습니다. 표준 인터페이스에 맞춰 코딩하면 밑에서 제공자만 바꿀 수 있습니다. 첫 설정을 곧 넘어설 것 같다면 OpenFeature로 연결해 두는 게 좋습니다. 그러면 이전이 설정 변경 한 번으로 끝납니다.

![밤의 개발 책상 위, 손으로 그린 체크박스와 화살표가 적힌 노트](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-11/f90753-i2.webp)

## 첫 플래그를 엉망으로 만들지 않고 추가하려면 어떻게 해야 할까요?

단일 릴리스 플래그와 몇 가지 원칙으로 시작하세요. 제가 따랐어야 했던 방식입니다.

**기능 이름이 아니라 기능을 기준으로 이름 짓기.** `new-checkout-flow`는 잘못되었을 때 무엇이 깨질지 알려 줍니다. `flag_47`은 여섯 달 뒤에 아무 말도 해 주지 않습니다.

**기본값은 꺼짐으로, 꺼짐은 기존 동작을 뜻하게 하기.** "끄면 레거시, 켜면 새 코드"라는 규칙이 압박 속에서도 시스템을 추론할 수 있게 해 줍니다. 이걸 깨면 모든 플래그가 퍼즐이 됩니다.

**평가는 한 곳에서.** Fowler는 이를 토글 반전(toggle inversion)이라고 부릅니다. 파일 스무 개에 `if (flags.x)`를 흩뿌리는 대신, 시스템의 가장자리에서 한 번 결정하고 그 결과를 넘기세요. 결정 지점이 하나면 바꿀 곳도 하나, 테스트할 곳도 하나입니다.

**플래그를 만드는 순간 제거 티켓을 쓰기.** 날짜를 붙여 백로그에 넣으세요. Fowler는 단기 토글에 만료 날짜를 두고, 날짜가 지나면 실패하는 테스트까지 두라고 권합니다. 제거 티켓이 없는 플래그는 상환 일정이 없는 대출입니다.

**중요한 평가는 로그로 남기기.** 사용자가 버그를 신고했을 때 플래그의 어느 쪽에 있었는지 알고 싶어집니다. 그걸 대답할 수 없다면 그 플래그는 부채입니다.

테스트에서 사람들은 과하게 엔지니어링합니다. 플래그의 모든 조합을 테스트할 필요는 없습니다. 대부분의 플래그는 서로 상호작용하지 않습니다. 운영에서 예상하는 설정을 테스트하고, 새 플래그가 꺼진 상태의 폴백을 테스트하고, 선택적으로 전부 켠 상태에서 한 번 돌려 드리프트를 잡으세요.

## 아무도 언급하지 않는 피처 플래그의 실제 비용은 무엇인가요?

플래그 하나마다 코드 경로가 두 배가 됩니다. 독립적인 플래그가 열 개면 이론상 1,024가지 조합입니다. 전부 테스트할 수는 없지만, 운영에서 아무도 예상하지 못한 조합을 한 번은 만나게 됩니다.

더 아픈 비용은 죽은 플래그입니다. 롤아웃이 끝나고 모두가 새 동작을 쓰는데 플래그는 100%에 머뭅니다. 옛 분기는 저장소에 남아 아무도 지울 엄두를 못 내는 코드가 됩니다. 여섯 달 뒤에는 이걸 끄는 게 안전한지 아무도 기억하지 못합니다.

이 문제의 유명한 사례가 2012년 8월의 Knight Capital입니다. 한때 퇴역한 거래 기능을 켜던 오래된 플래그가 새 코드에 재사용되었습니다. 여덟 대 서버 중 한 대가 배포를 놓쳐 옛 코드를 계속 돌렸습니다. 45분 만에 회사는 분기 보고서 기준 약 $440 million을 잃었고, 이후 보도에서는 $460 million에 가깝다고 했습니다. 실제 돈과 실제 엔지니어가 있는 거래 회사의 이야기이니, 여러분의 사이드 프로젝트가 더 안전하다고는 말하지 않겠습니다. 교훈은 규모를 줄여도 그대로 맞습니다. 플래그 이름을 절대 재사용하지 말고, 죽은 플래그는 고고학의 대상이 되기 전에 지우세요.

![열쇠들이 고리에 걸려 있는 모습, 일부는 녹슬었고 일부는 반짝이며 코드에 방치된 옛 플래그를 떠올리게 함](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-11/967554-i3.webp)

제가 계속 붙잡는 틀은 Fowler의 관점입니다. 플래그를 운반 비용이 드는 재고로 보라는 것입니다. 살아 있는 플래그 수에 상한을 두고, 하나를 지워야 새 플래그를 추가할 수 있게 하는 팀도 있습니다. 솔로 개발자라면 다섯 개를 하드 상한으로 두면 충분합니다.

## 언제 피처 플래그를 아예 건너뛰어야 할까요?

생각보다 자주입니다. 도구 벤더들이 인정하는 것보다 훨씬 자주요.

변경이 작고 git에서 되돌리기 쉬우며 배포에 2분이면 충분하다면 건너뛰세요. 플래그는 분기, 설정 소스, 잊어버릴 것 하나를 추가합니다. 되돌리는 게 플래그를 뒤집는 것보다 빠르다면, 그 플래그는 연극입니다.

사용자가 아직 없을 때도 건너뛰세요. 사용자 0명에게 점진적으로 롤아웃하는 건 그냥 지연일 뿐입니다. 배포하고, 로그를 보고, 고치세요.

토글로 되돌릴 수 없는 데이터베이스 마이그레이션도 건너뛰세요. 플래그로 UI에서 새 컬럼을 숨길 수는 있어도 드롭된 테이블을 되살릴 수는 없습니다. 스키마 변경에는 플래그 여부와 상관없이 확장 후 축소(expand-and-contract) 계획이 필요합니다.

플래그가 가치 있는 경우는 결제나 인증을 건드릴 때, 미완성 작업을 매일 머지하고 싶을 때, 서드파티 의존성이 실패할 수 있어 킬 스위치가 필요할 때입니다.

## 플래그를 켠 뒤에는 무엇을 지켜봐야 할까요?

플래그는 노출을 통제하고, 노출은 그다음에 무슨 일이 일어나는지 볼 수 있을 때만 도움이 됩니다. 에러율과 지연 시간을 보지 않고 사용자 10%에게 기능을 켜는 건, 부가 단계가 붙은 동전 던지기입니다.

첫 롤아웃 전에 1분 안에 답할 수 있는지 확인하세요. 플래그된 코호트의 에러가 늘었는가, 지연 시간이 나빠졌는가, 하류 시스템에서 무언가 바뀌었는가. 작은 제품이라면 업타임 모니터링과 로그 검색이 대부분을 커버합니다. Better Stack은 모니터, 상태 페이지, 로그를 무료 티어와 함께 한 곳에 묶어 줍니다.

지금 제가 따르는 규칙은 이렇습니다. 플래그는 붙어 있는 알람만큼만 쓸모가 있습니다. 알람이 없으면 어둠 속에서 무언가를 켜는 셈입니다.

## 이번 주에 실제로 무엇을 할까요?

지금 배포하기가 두려운 미완성 작업 하나를 고르세요. 테이블이나 JSON 파일에서 읽는 불리언 뒤에 두고, 기본값은 꺼짐으로 해서 오늘 main에 머지하세요. 에디터를 닫기 전에, 이 주 뒤 날짜를 붙인 제거 티켓을 쓰세요.

그다음 나 혼자만 켜고 하루 동안 써 보세요. 괜찮으면 범위를 넓히고, 아니면 끄면 됩니다. 잃는 건 1분뿐입니다.

여러분의 코드베이스에서 지금 한 달 넘게 100%에 머물러 있는 플래그는 무엇인가요? 그것이 여러분의 첫 삭제 대상입니다.

## FAQ

### 피처 플래그란 간단히 말해 무엇인가요?

피처 플래그는 켜고 끄는 값이 설정 파일, 데이터베이스, 플래그 서비스처럼 코드 바깥에 저장된 조건문입니다. 런타임에 값을 바꿀 수 있어서, 기능을 꺼진 상태로 배포해 두고 나중에 다시 배포하지 않고 출시할 수 있습니다.

### 피처 플래그와 피처 토글은 같은 건가요?

네, 같습니다. 피처 플래그, 피처 토글, 피처 스위치, 릴리스 토글은 모두 같은 기법을 가리킵니다. 팀마다 습관처럼 용어를 고르고, 도구들도 섞어서 씁니다.

### 피처 플래그의 주요 종류는 무엇인가요?

보통 네 가지를 씁니다. 미완성 작업을 숨기는 릴리스 플래그, 위험한 기능을 끄는 운영(킬 스위치) 플래그, A/B 테스트용 실험 플래그, 요금제나 계정별로 기능을 여는 권한 플래그입니다.

### 사이드 프로젝트에도 유료 피처 플래그 도구가 필요한가요?

보통은 필요 없습니다. 상수, 환경 변수, JSON 파일, 데이터베이스 테이블이면 솔로 프로젝트를 충분히 감당합니다. 비개발자가 플래그를 바꿔야 하거나 비율 롤아웃, 타겟팅, 감사 로그가 필요해지면 호스팅 서비스로 옮기세요.

### 피처 플래그는 얼마나 살아 있어야 하나요?

릴리스 플래그는 일이 주 정도 살다가 옛 코드 경로와 함께 지워야 합니다. 운영 킬 스위치는 더 오래 둬도 됩니다. 권한 플래그는 몇 년씩 가기도 하지만 사실상 권한이므로 제대로 된 데이터 모델이 필요합니다.

### 피처 플래그의 가장 큰 위험은 무엇인가요?

오래된 플래그입니다. 플래그마다 테스트해야 할 코드 경로가 생기고, 100%에 방치된 플래그는 아무도 감히 지우지 못하는 죽은 코드를 남깁니다. Knight Capital이 2012년에 약 $440 million을 잃은 사고에도 재사용된 옛 플래그가 얽혀 있었습니다. 플래그를 만들 때 제거 티켓을 함께 쓰세요.