# 피처 플래그란 무엇인가: SRE가 배포와 릴리스를 분리하는 방법

URL: https://upstreamapi.com/ko/journal/피처-플래그란-무엇인가
Type: blog
Locale: ko
Published: 2026-08-29
Updated: 2026-08-31

---

> 새 빌드 없이 코드 경로를 제어하는 피처 플래그: 배포와 릴리스를 분리하고 SLO 게이트로 안전성을 검증하는 SRE 실전 가이드.

피처 플래그란 무엇인가? 새 빌드를 배포하지 않고도 특정 사용자, 세션, 환경에서 어떤 코드 경로를 실행할지 제어하는 조건부 체크다. `new_checkout_flow` 플래그가 99%의 사용자에게 `false`로 설정되어 있다면, 해당 코드는 2주 전에 이미 배포된 것이다. 단지 아직 켜지지 않았을 뿐이다. 이 계약이 만드는 것은 명확하다: 배포(deployment)와 릴리스(release)는 별개의 이벤트가 된다. 대규모 지속적 배포(continuous deployment)를 실행하는 팀에게 이 계약은 구조적으로 필수다.

## 배포와 릴리스는 같은 이벤트가 아니다

대부분의 팀은 잘못된 롤아웃을 겪고 나서야 이 차이를 배운다. 기능이 화요일 오후에 배포됐는데, 수요일 아침쯤 요청 트레이스에서 뭔가 이상한 동작이 시작됐고, 누군가 조사를 시작할 때쯤 diff는 커밋 4개와 서비스 경계 2개에 걸쳐 있다. 그 시나리오에서 인과관계를 특정하는 것은 진짜로 어렵다.

피처 플래그는 정밀도를 강제한다. 플래그 뒤의 코드가 병합되고 배포되면, 프로덕션에서 비활성 상태로 대기한다. 배포가 성공했는지 확인하고, 몇 시간 또는 며칠 동안 기준 메트릭을 관찰하며 아무것도 저하되지 않았는지 확인한다. 그런 다음 트래픽의 1%에 플래그를 켠다. 이제 단 하나의 귀속 가능한 변수가 생긴다. 플래그가 적용된 경로에서 에러율이 올라가면, 코드 diff를 디버깅하는 것이 아니다. 설정값 하나를 토글하는 것이다.

이 분리는 속도 논리가 아니다. 블라스트 반경(blast radius) 논리다. 세션 1%에 영향을 미치는 릴리스가 잘못되면 몇 분 내에 복구 가능하다. 세션 100%에 영향을 미치는 릴리스가 잘못되면 메이저 인시던트가 된다.

TypeScript에서 플래그 평가는 대략 이렇게 생겼다:

`const showNewCheckoutFlow = flagClient.variation(
  'new_checkout_flow',
  { userKey: session.userId, custom: { plan: user.plan } },
  false // 플래그 서비스 네트워크 파티션 시 기본값
);

if (showNewCheckoutFlow) {
  return renderNewFlow(cart);
}
return renderLegacyFlow(cart);``false` 기본값은 형식적인 것이 아니다. 플래그 평가 서비스에 네트워크 파티션이 발생할 때 사용자에게 제공되는 동작이다. 우연이 아닌 의도적으로 정의해야 한다.

## 프로덕션에서 실제로 중요한 플래그 4가지 유형

모든 피처 플래그가 동일한 운영 목적을 가지는 것은 아니다. 코드베이스와 관리 툴링에서 이를 동일하게 취급하면 인시던트 중 혼란과 플래그 부채 축적으로 이어진다.

**릴리스 플래그**: 개발 및 롤아웃 중 새 기능을 제어한다. 임시로 설계된다. 기능 브랜치 작업이 시작될 때 생성되고, 팀이 안정성을 확인한 후 100%에 도달하면 제거된다. 제거 날짜와 담당자 없는 릴리스 플래그는 코드베이스의 영구 가구가 된다.

**실험 플래그**: A/B 테스트와 다변량 실험을 구동한다. 애널리틱스 코호트 식별자에 연결되고 실험 기간으로 수명이 제한된다. 실험이 끝나면 플래그도 함께 사라져야 한다. 흔한 실수: 우승 변형을 "급하지 않다"는 이유로 플래그 뒤에 무기한 유지한다. 2년 후, 그 실험 플래그는 크리티컬 패스의 일부가 되고 아무도 어떤 변형이 활성화되어 있는지 기억하지 못한다.

**운영 플래그**: 킬 스위치와 서킷 브레이커다. 릴리스 플래그와 달리 영구 인프라로 설계된다. SLO가 저하될 때 느린 ML 추론 레이어를 우회할 수 있는 `disable_ml_recommendations` 플래그는 오전 3시에 문서를 읽지 않고도 사용할 수 있어야 한다. 이 플래그들은 로컬에서 평가되어야 하고, 잘 문서화된 폴백을 가져야 하며, 압박 아래서가 아니라 정기적으로 테스트되어야 한다.

**권한 플래그**: 사용자 티어, 계정 플랜, 베타 코호트별 접근을 제어한다. 설계상 수명이 길다. 혼동 위험: 권한 플래그는 히스토리를 모르는 독자에게 릴리스 플래그처럼 보인다. 명확한 네이밍 컨벤션이 다른 어떤 곳보다 여기서 더 중요하다.

![퍼센트 기반 트래픽 라우팅과 동심원 노드 구조로 표현된 점진적 소프트웨어 롤아웃 시각화](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/e28abc-inline1.webp)

## SLO 게이트 없는 퍼센트 롤아웃은 느린 배포일 뿐이다

여기서 대부분의 피처 플래그 구현이 부족해진다. 플랫폼 팀이 롤아웃 일정을 구성한다: 월요일 1%, 화요일 5%, 수요일 25%, 금요일 100%. 문서화하고, 이해관계자와 공유하고, 점진적 딜리버리라고 부른다.

그러나 각 단계에서 검증 조건 없이 "점진적"인 것은 리스크를 줄이는 것이 아니라 리스크를 미루는 것이다. 퍼센트 다이얼은 노출을 제어한다. 안전성을 검증하지는 않는다.

단계적 롤아웃을 운영적으로 의미 있게 만드는 것은 각 단계 사이의 SLO 게이트다. 5%에서 25%로 전진하기 전에, 플래그가 적용된 코드 경로의 에러율이 SLO 예산 내에 있는지 확인해야 한다. p99 레이턴시가 컨트롤 그룹과 같은 범위 내에 있는지? 에러 예산이 기준선보다 빠르게 소진되고 있는지? 이 질문들이 계측되지 않으면, 롤아웃 일정은 검증 루프가 아닌 타임라인이다.

프로덕션에서 유효한 설정: SLO 평가 윈도우를 2개로 정의한다. 단기 윈도우(15분)는 빠른 장애를 잡는다. 잘못된 데이터베이스 쿼리, 스키마 불일치, 크리티컬 패스의 회귀. 장기 윈도우(24시간 또는 전체 트래픽 사이클)는 점진적 저하를 잡는다. 메모리 누수, 캐시 압박, 저빈도 트래픽 세그먼트의 엣지 케이스. 두 윈도우가 모두 그린을 보여야 전진 가능하다. 하나라도 위반되면 롤아웃을 중단하고 온콜을 호출한다.

퍼센트는 다이얼이다. SLO 윈도우는 게이트다. 둘 다 필요하다.

## 킬 스위치 엔지니어링: 필요하기 전에 설계하라

킬 스위치는 폴백이 아니다. 기능 코드의 첫 번째 줄이 작성되기 전에 존재해야 하는 1급 설계 결정이다.

압박 하에 설계된 킬 스위치는 검토되지 않은 가정을 가진 킬 스위치다. PagerDuty 알림으로 열린 터미널 세션에서, Slack 스레드를 5명이 바라보고 있는 동안, 활성 인시던트 중에 처음 테스트하게 된다. 운영 플래그가 세션 ID로 사용자를 타겟팅하는데 세션 서비스가 현재 저하된 상태라는 것을 발견하기 최악의 순간이다.

![에러 예산 소진율 차트와 기능 롤아웃 제어를 위한 킬 스위치 지표가 표시된 SLO 모니터링 대시보드](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/dd1477-inline2.webp)

프로덕션용 킬 스위치에 비협상 가능한 세 가지 속성:

- 
**50ms 미만 로컬 평가**: 플래그 체크는 원격 평가 서비스에 대한 네트워크 호출이 될 수 없다. 평가가 스스로 저하될 수 있는 서비스에 의존한다면, 인시던트 대응 경로에 순환 의존성이 생긴다.

- 
**명시적 폴백 값**: 플래그 서비스에 접근할 수 없을 때 플래그는 무엇을 반환하는가? 코드에서 정의되고 문서화되고 테스트되어야 한다. "SDK 기본값"은 답이 아니다.

- 
**의존성 장애 하에서 테스트**: 킬 스위치는 카오스 엔지니어링 로테이션의 일부여야 한다. 인증 저하, 플래그 서비스 다운, 평가 엔드포인트 레이턴시 초과 시나리오를 검증한다.

인시던트 대응을 깔끔하게 수행하는 팀들은 리허설을 한 팀들이다. 킬 스위치는 런북의 일부다. 지루할 만큼 익숙해야 한다.

## 플래그 부채: 로드맵에 아무도 넣지 않는 기술 부채

적극적으로 피처 플래그를 도입한 팀들은 종종 플래그 부채를 축적한다. 목적을 달성했지만 제거되지 않은 플래그들이다. 기능이 배포됐고, 실험이 끝났고, 베타가 종료됐다. 플래그는 남았다.

50개 플래그에서는 사소한 불편이다. 분산 시스템 전반에 걸쳐 500개 플래그에서는 활성 운영 리스크다. 각 플래그는 인시던트 조사 중 유지보수, 테스트, 이해가 필요한 코드 브랜치다. 오전 2시에 장애를 이해하려는 개발자는 관련 브랜치를 찾기 위해 조건 분기 40개를 추적하고 싶지 않다.

여러 플랫폼 팀에서 관찰된 패턴: 플래그 평가 미들웨어가 p99 레이턴시의 상위 5개 스택 프레임에 나타나는 것. 대부분의 경우 원인은 요청당 수십 개의 조건을 평가하는 복잡한 타겟팅 규칙을 가진 오래된 플래그들이다. 2년 전에 내려진 결정의 무게를 짊어지고 있다.

대책은 기술적이 아닌 조직적이다. 생성된 모든 플래그에는 세 가지 속성이 있어야 한다: 담당자, 유형(릴리스, 실험, 운영, 권한), 예상 제거 날짜. 릴리스 플래그는 전체 롤아웃 후 2스프린트 내에 제거되어야 한다. 실험 플래그는 실험이 끝날 때 제거되어야 한다. 플래그 인벤토리는 온디맨드로 감사 가능하고 엔지니어링 헬스 대시보드에 표시되어야 한다.

## 엔터프라이즈 규모에서 깨지는 타겟팅 세분성

대부분의 피처 플래그 플랫폼은 퍼센트 기반 롤아웃과 기본적인 사용자 속성 타겟팅을 지원한다. 엔터프라이즈 규모에서 나타나는 격차는 타겟팅 세분성이다. 유용할 만큼 구체적이면서 유지보수 불가능할 만큼 복잡하지 않은 롤아웃 규칙을 표현하는 능력이다.

플랫폼 팀 수준에서 프로덕션 롤아웃에 유용한 타겟팅 계층:

- 
**환경 수준**: 프로덕션, 스테이징, 프리뷰. 첫 번째 게이트이지, 유일한 게이트가 아니다.

- 
**인프라 세그먼트**: 데이터센터, 가용 영역, Kubernetes 클러스터. 지리적 블라스트 반경 격리에 유용하다.

- 
**계정 또는 테넌트**: B2B SaaS 플랫폼의 경우 사용자 퍼센트보다 계정 단위 롤아웃이 종종 더 안전하다. 통계적 샘플이 아닌 전체 계정의 트래픽 패턴을 관찰할 수 있기 때문이다.

- 
**사용자 코호트**: 베타 사용자, 내부 사용자, 활동 티어별 파워 유저.

- 
**세션 속성**: 실험 플래그에 유용하지만 운영 플래그에는 위험하다.

SRE 팀들이 이를 규모 있게 수행할 때 가장 많이 인용하는 플랫폼(LaunchDarkly와 Statsig)은 활성 롤아웃 중 타겟팅 로직을 수정하기 위한 엔지니어링 시간 없이 복잡한 규칙 구성을 허용한다. 이 셀프서비스 능력이 30초 롤아웃 일시 정지와 플랫폼 팀에 대한 티켓의 차이다.

## 포스트모템이 반복해서 발견하는 것

피처 관련 프로덕션 인시던트에 대한 모든 포스트모템은 동일한 질문 집합을 묻는다. 기능이 플래그 뒤에 있었는가? 롤아웃이 점진적이었는가? 단계 사이에 검증 조건이 있었는가? 킬 스위치가 인시던트 전에 테스트되었는가?

4가지 모두 예라면, 인시던트는 보정 문제다. 너무 느슨하게 설정된 임계값, 엣지 케이스가 있는 타겟팅 규칙, 계정되지 않은 네트워크 파티션 하에서의 SDK 평가 동작. 설정 변경과 런북 업데이트로 해결 가능하다.

하나라도 아니오라면, 인시던트는 아키텍처 문제다. 피처 플래그는 디버깅 편의가 아니다. 배포 아키텍처 결정이다. 그 결정은 기능이 배포되기 전에 존재하거나, 전혀 존재하지 않는다.

오늘 밤 무언가 잘못된다면 다음 릴리스의 포스트모템은 무엇을 말할 것인가?

## FAQ

### 피처 플래그와 환경 변수의 차이점은 무엇인가?

환경 변수는 서비스 재시작이 필요하고 런타임 중 변경할 수 없다. 피처 플래그는 실시간으로 평가되어 재배포 없이 동작을 변경한다. 킬 스위치 시나리오에서 이 차이는 수 분의 MTTR 차이를 만든다.

### 피처 플래그는 성능에 영향을 미치는가?

잘못 관리된 플래그는 영향을 미친다. 복잡한 타겟팅 규칙을 가진 오래된 플래그들이 p99 레이턴시의 상위 기여자가 되는 사례를 실제 플랫폼 팀에서 관찰했다. 해결책은 플래그 인벤토리 위생이다. 로컬로 평가되는 활성 플래그는 무시할 수 있는 오버헤드만 추가한다.

### SLO 게이트는 어떻게 구현하는가?

각 롤아웃 단계에서 단기(15분)와 장기(24시간) SLO 평가 윈도우를 정의한다. 플래그가 적용된 코드 경로의 에러율, p99 레이턴시, 에러 예산 소진율을 측정한다. 두 윈도우가 모두 그린일 때만 다음 단계로 전진하고, 하나라도 위반되면 롤아웃을 중단하고 온콜을 호출한다.

### 피처 플래그의 수명을 어떻게 관리하는가?

생성 시점에 담당자, 유형, 예상 제거 날짜를 할당한다. 릴리스 플래그는 전체 롤아웃 후 2스프린트 내에 제거한다. 플래그 인벤토리를 엔지니어링 헬스 대시보드에서 감사 가능하게 유지한다. 제거 날짜 없는 플래그는 코드베이스의 영구 가구가 된다.

### 킬 스위치를 어떻게 테스트해야 하는가?

카오스 엔지니어링 로테이션에 포함시킨다. 인증 저하, 플래그 서비스 다운, 평가 엔드포인트 레이턴시 초과 시나리오를 검증한다. 인시던트 중 처음 테스트하는 상황을 만들지 않는 것이 핵심이다. 킬 스위치는 런북의 일부여야 하고 지루할 만큼 익숙해야 한다.

### 피처 플래그 부채를 어떻게 측정하는가?

제거 날짜가 없는 플래그 수, 담당자 없는 플래그, 실험 종료 후 남은 플래그를 추적한다. 피처 플래그 미들웨어가 p99 레이턴시 상위 스택 프레임에 나타나면 플래그 부채가 운영 리스크로 전환된 신호다.

### LaunchDarkly와 Statsig 중 어떤 것을 선택해야 하는가?

LaunchDarkly는 엔터프라이즈 거버넌스와 복잡한 타겟팅 규칙에 강점이 있다. Statsig는 플래그, 실험, 제품 애널리틱스를 통합한다. 두 플랫폼 모두 활성 롤아웃 중 엔지니어링 시간 없이 셀프서비스 규칙 수정을 지원한다. 결정 기준은 마케팅이 아니라 타겟팅 세분성과 SDK 레이턴시다.