Vercel Flags: 플랫폼 네이티브 기능 플래그 (Feature Flags)

Vercel에서 기능 플래그 (Feature Flags)는 우리가 제품을 출시하는 방식입니다. 새로운 기능부터 v0의 모델 업데이트, 그리고 플래그가 전환점 역할을 했던 프로덕션 데이터베이스 마이그레이션과 같은 인프라 변경 사항까지 포함됩니다. 팀 자체적으로만 매 순간 수백 개의 플래그를 운영하고 있습니다. v0

코드를 병합(Merging)하면 프로덕션으로 빌드가 전송되지만, 기능 플래그 (Feature Flags)는 사용자가 변경 사항을 볼 수 있는지 여부를 제어합니다. 플래그를 사용하면 자신만의 일정에 맞춰 제품을 출시하고, 준비가 되었을 때 특정 세그먼트(Segments)에 배포하며, 소스 파일을 수정하거나 재배포할 필요 없이 플래그를 토글하는 것만으로 즉시 롤백(Roll back)할 수 있습니다.

이는 플랫폼 네이티브(Platform-native)입니다: 기본적으로 서버 사이드(Server-side)로 작동하며, 페이지 성능에 영향이 없고, 이미 사용 중인 프레임워크와 직접 통합됩니다. Vercel Flags

Vercel Flags를 사용하면 기능 플래그 (Feature Flags)를 생성하고, 사용자 속성, 세그먼트(Segments) 또는 환경에 따라 타겟팅 규칙을 정의하며, 점진적 배포(Progressive rollouts)를 실행하고, 프로덕션에서 문제가 발생할 경우 킬 스위치(Kill switches)를 작동시킬 수 있습니다.

코드에서 여러분은 Flags SDK를 통해 플래그를 읽습니다. 이는 우리가 유지 관리하는 오픈 소스이며, Next.js 및 SvelteKit을 위한 퍼스트 클래스 어댑터(First-class adapters)를 갖춘 프로바이더 불가지론적(Provider-agnostic) 라이브러리입니다. 다른 프레임워크를 사용하는 경우, 내장된 OpenFeature 프로바이더를 사용하여 Vercel Flags를 사용할 수 있습니다.

Vercel Flags 대시보드는 프로젝트 및 배포와 나란히 위치하여, 이곳에서 플래그를 생성하고 관리할 수 있습니다.

하지만 Vercel Flags를 다른 플래그 서비스와 차별화하는 점은 바로 프레임워크 통합(Framework integration)입니다.

다른 플래그 프로바이더들은 프레임워크에 직접 연결해야 하는 범용 SDK와 플래그를 관리하기 위한 별도의 대시보드를 제공합니다. 반면 Vercel Flags는 Vercel 플랫폼에 내장되어 있어, 배포와 동일한 대시보드에서 플래그를 관리할 수 있으며, 코드는 프레임워크 네이티브(Framework-native)인 Flags SDK를 통해 플래그를 읽어옵니다.

클라이언트에서 플래그가 평가될 때, 사용자에게 로더(loader), 깜빡임(flicker), 또는 레이아웃 이동(layout shift)이 나타날 수 있습니다. 플래그 값이 돌아올 때까지 브라우저는 올바른 뷰를 렌더링할 수 없기 때문입니다. Flags SDK는 대신 서버에서 평가를 수행합니다. Next.js React Server Components를 사용하면 렌더링 중에 플래그를 읽을 수 있습니다. 올바른 뷰가 서버 측에서 결정되며, 브라우저는 별도의 플래그 요청 없이 이를 직접 렌더링합니다. 해당 값은 Vercel Flags에서 가져오며, 여기서 설정 변경 사항은 밀리초(milliseconds) 내에 모든 리전(region)으로 전파됩니다. await

고급 사례의 경우, 플래그를 await 하는 대신 클라이언트 컴포넌트에 프로미스(promise)로 전달할 수 있습니다. 이를 통해 플래그 값이 도착하기 전에 페이지 렌더링을 시작할 수 있으며, 그동안 컴포넌트는 폴백(fallback)을 보여줍니다. 플래그는 여전히 서버에서 해결(resolve)되므로, 브라우저 측에서의 요청은 발생하지 않습니다.

Vercel Flags는 플래그를 자동으로 등록합니다. 코드에서 플래그를 정의하고 배포하면 대시보드에 초안(draft)으로 나타납니다. 타겟팅(targeting)을 구성하고 배포(roll out)할 준비가 되면 초안을 승격(promote)하세요. 코드에서 플래그를 제거하면 대시보드에 참조되지 않음(unreferenced)으로 표시되므로, 무엇을 안전하게 아카이브(archive)할 수 있는지 항상 알 수 있습니다. 작성한 플래그가 곧 관리하는 플래그가 되며, 수동으로 동기화해야 할 별도의 목록이 필요 없습니다.

정적 페이지(Static pages)는 귀하와 사용자에게 가장 가까운 CDN 리전에서 제공되기 때문에 빠르고 일관적입니다. 하지만 플래그를 추가하면 페이지가 동적(dynamic)이 됩니다. 서버 측에서 렌더링하면 CDN 제공의 이점을 잃게 되고, 클라이언트 측에서 플래그를 가져오면 레이아웃 이동(layout shift)이 다시 발생합니다. 그러나 Flags SDK에는 이 문제를 해결하는 선택적이고 고급스러운 패턴이 포함되어 있습니다. 사전 계산(Precompute)을 사용하면 빌드 타임(build time)에 모든 변형(variant)을 빌드하고, 이를 CDN을 통해 배포하며, (Next.js의 파일이) 각 사용자를 올바른 변형으로 라우팅(route)하게 할 수 있습니다. 모든 페이지는 정적 상태를 유지하며 레이아웃 이동 없이 로드됩니다. Routing Middleware proxy.ts

CLI를 통해 터미널에서도 동일한 플래그 관리 기능을 사용할 수 있으므로, 개발자와 코딩 에이전트(coding agents)가 플래그를 생성하고, 타겟팅(targeting)을 설정하며, 롤아웃(rollouts)을 실행하고, 아카이브(archive)할 수 있습니다.vercel flags

Vercel Toolbar에 내장된 Flags Explorer를 사용하면 브라우저 세션에서 모든 플래그를 재정의(override)하여 변형(variant)을 테스트할 수 있습니다. 공유 설정은 변경되지 않으며 재배포(redeploy)할 필요도 없습니다.

2026년 4월에 Vercel Flags를 일반적으로 공개(GA)했지만, 저희는 이미 1년 이상 내부적으로 사용해 왔습니다. v0 팀은 언제나 수백 개의 플래그가 활성화되어 있는, 대규모 환경에서 이것이 어떻게 작동하는지를 보여주는 좋은 사례입니다.

팀들이 플래그 뒤에 배치하는 기능들의 몇 가지 예시는 다음과 같습니다:

v0와 같은 제품의 경우, 추가되는 모든 지연 시간(latency)은 최종 사용자 경험을 저하시킵니다. Vercel Flags는 서버 측(server-side)에서 평가되기 때문에, 팀은 클라이언트 측(client-side) 플래그 평가가 추가하는 추가적인 왕복(round trip) 없이 기능 플래깅(feature flagging)을 사용할 수 있습니다.

모든 새로운 기능이 플래그 뒤에서 구축되기 때문에, 개발자는 미완성된 작업을 출시하지 않고도 main 브랜치로 지속적으로 머지(merge)할 수 있습니다. 오래 유지되는 브랜치(long-lived branches)도 없고, 해결해야 하는 고통스러운 머지 충돌(merge conflicts)도 없습니다. 코드를 배포하는 것과 기능을 출시하는 것이 두 개의 별개 결정이 됩니다.

출시는 통제된 단계(controlled progression)를 거쳐 진행됩니다. 기능을 만든 개발자가 가장 먼저 확인하고, 그다음 내부 팀이 확인합니다. 그 후, 플래그는 모든 사용자에게 전달되기 전, 6시간마다 각각 사용자 중 5%, 10%, 25%, 50%로 단계적으로 확대됩니다. 만약 어느 단계에서든 문제가 발생하면, 팀은 코드 변경이나 재배포 없이 해당 기능을 즉시 중단(kill)할 수 있습니다.

또한 플래그는 v0의 AI 모델 트래픽을 제어하여, 새로운 모델이 출시될 때 한꺼번에 전환하는 대신 점진적으로 전환합니다.

v0는 플래그를 사용하여 프로덕션 데이터베이스 마이그레이션 (database migration)을 수행하기도 했습니다. 기존 데이터베이스와 새로운 데이터베이스를 동기화된 상태로 유지했으며, 플래그가 어떤 데이터베이스를 사용할지 제어했습니다. 플래그를 전환하는 것 자체가 곧 컷오버 (cutover)였습니다. 스테이징 (staging) 환경에서 이를 반복적으로 연습한 후, 트래픽 저하 없이 프로덕션에서 실행했습니다. 플래그는 위험 부담이 큰 인프라 변경 작업을 팀이 연습하고, 일정을 잡고, 확신을 가지고 배포할 수 있는 작업으로 바꾸어 놓았습니다.

코드 배포 (shipping code)와 기능 출시 (releasing a feature)가 분리된 단계가 되면, 단순히 PR (Pull Request)만으로는 얻을 수 없었던 수준의 확신을 가지고 작업을 배포하기 시작할 수 있습니다.

모든 플랜에서 사용할 수 있습니다. CLI (Command Line Interface)를 통해 사용자와 에이전트 (agents)는 어디에서나 플래그를 생성, 검사, 롤아웃 (rollouts) 관리 및 아카이브 (archive)할 수 있습니다.Vercel Flags vercel flags

시작하려면 문서를 읽거나, .에 대한 도움을 에이전트에게 요청하세요.Vercel Flags documentation Flags SDK skill

더 읽어보기

Vercel Flags란 무엇인가

프레임워크 네이티브 (framework-native)가 중요한 이유

Vercel은 Vercel Flags로 배포합니다

시작하기

서버 측 평가 (Server-side evaluation)

자동 플래그 등록 (Automatic flag registration)

사전 계산 (Precompute)

에이전트 네이티브 플래그 관리 (Agent-native flag management)

브라우저에서의 플래그 오버라이딩 (Overriding flags in the browser)

개발 중인 새로운 기능
사용자 또는 세그먼트별 AI 모델 라우팅 (routing)
운영용 킬 스위치 (kill switches)
데이터베이스 마이그레이션 (database migrations) 및 제공업체 교체 (provider swaps)
초기 고객 또는 내부 팀을 위한 베타 액세스 (Beta access)