Fluid Compute는 무엇을 해결했는가
- 년에 GA된 Vercel Fluid Compute는 기존의 "Serverless Functions"와 "Edge Functions"로 나뉘어 있던 런타임을 통합한 차세대 실행 기반입니다. 기존 serverless는 "1요청 = 1컨테이너"의 idle 과금 부담이 컸고, Edge Functions는 50MB의 코드 사이즈 상한과 Node.js 호환성 제약이 무거웠습니다. Fluid Compute는 단일 인스턴스가 여러 요청을 병행 처리하는 "multi-tenant concurrency" 모델을 채택하여, I/O 대기 시간을 과금 대상에서 제외합니다. 결과적으로 DB 커넥션을 유지하면서 엣지에 가까운 레이턴시를 얻을 수 있다는, 기존에는 트레이드오프였던 특성이 양립하게 되었습니다.
- 년 4월 시점에서 next.config.ts의 runtime 옵션은 `"nodejs"` / `"edge"` / `"fluid"` 세 가지 선택지가 있습니다. Next.js 16의 기본값은 `"fluid"`이며, /app 하위 라우트는 명시적으로 `export const runtime = "edge"`를 작성하지 않는 한 Fluid 위에서 동작합니다. Edge Functions는 WebSocket 종단이나 극소 레이턴시 API에 용도가 좁아졌고, 기존의 "엣지냐 Lambda냐"라는 선정 논의는 "Fluid로 충분한가, Edge가 필요한가"로 이동했습니다.
Next.js 16의 RSC 엣지 렌더링
Next.js 16은 React Server Components(RSC)의 스트리밍 출력을 PoP에서 생성할 수 있게 되었습니다. 구체적으로는 Suspense 경계마다 HTML과 RSC payload를 비동기 flush하여 TTFB를 40ms 전후까지 단축합니다. 중요한 것은 데이터 페치의 배치입니다. RSC는 서버 측에서 완결되는 fetch를 작성할 수 있지만, 오리진 DB에 직결하는 것은 피하고 Vercel Data Cache(구 Request Memoization)나 Hyperdrive / PlanetScale Boost 같은 엣지 캐시 레이어를 거치는 것이 철칙이 되었습니다.
Edge Runtime 위에서 동작하는 RSC에는 제약이 있습니다. Node.js의 fs / net / child_process는 사용할 수 없고, 암호화는 Web Crypto API를 통해야 합니다. 2025년 말에 추가된 edge-compatible adapter로 Prisma 6과 Drizzle ORM은 그대로 동작하지만, Sequelize나 TypeORM은 Fluid 권장 상태입니다. "RSC는 Edge, DB 쓰기는 Fluid"로 역할을 분담하는 아키텍처가 2026년의 표준해입니다.
```typescript // app/products/[id]/page.tsx export const runtime = "edge"; export const revalidate = 60; export default async function ProductPage({ params }: { params: Promise<{ id: string }> }) { const { id } = await params; const product = await fetch(`${process.env.EDGE_API}/products/${id}`, { next: { revalidate: 60, tags: [`product-${id}`] }, }).then((r) => r.json()); return ( <> <ProductHeader product={product} /> <Suspense fallback={<ReviewsSkeleton />}> <ProductReviews id={id} /> </Suspense> </> ); } ```
Streaming SSR과 Partial Prerendering(PPR)
PPR은 Next.js 14에서 실험적으로 도입, 15에서 stable화, 16에서 기본 활성화된 기능으로, "정적 쉘 + 동적 채워 넣기"를 빌드 시와 실행 시의 하이브리드로 전달합니다. 빌드 시에 생성한 HTML 뼈대를 PoP에서 즉시 반환하면서, 사용자 고유 부분(장바구니 아이콘, 추천 상품)을 Suspense 경계로 남겨 서버에서 추가로 flush합니다. 이를 통해 CDN 히트율을 유지하면서 개인화를 양립할 수 있습니다.
구현상의 함정은 "cookies()나 headers()를 참조하는 순간, 그 트리 전체가 동적이 된다"는 점입니다. 무심코 레이아웃에서 headers()를 호출하면 PPR의 정적 쉘이 생성되지 않아 매번 풀 SSR로 격하됩니다. `next build`의 출력 로그에서 "Static (prerendered)"와 "Dynamic (on-demand)"의 비율을 정기적으로 감사하고, 정적 비율이 떨어지지 않는지 CI에서 감지해야 합니다.
Edge Config와 CDN 기반 Feature Flag
Edge Config는 Vercel이 제공하는 "읽기 최적화된 JSON 스토어"로, Edge Runtime에서 1ms 미만으로 읽을 수 있습니다. LaunchDarkly나 Statsig 같은 SaaS를 사용하지 않고, 자체 제작의 feature flag 기반을 Edge Config + Vercel Flags SDK로 구축하는 것이 2026년의 현실적인 해법이 되었습니다. 쓰기는 관리 API를 통해 수 초 이내에 전 리전에 전파되고, 읽기는 런타임의 Isolate 내에 내장되어 네트워크 RTT가 발생하지 않습니다.
Flags SDK는 A/B 테스트와 플래그 평가를 동일한 API로 처리하며, RSC와 클라이언트 컴포넌트에서 identity를 일치시킵니다. 구체적으로는, middleware에서 사용자 ID를 cookie에 고정하고, RSC 내에서 `flag("new-checkout").bucket(userId)`를 평가하며, 결과를 searchParams로 자식 컴포넌트에 전파합니다. 이를 통해 "최초 접근 시 서버 측에서 결정된 variant가, 이후 페이지 이동 후에도 유지된다"는 SPA 같은 경험이 엣지에서 완결됩니다.
```typescript import { flag } from "@vercel/flags/next"; import { get } from "@vercel/edge-config"; export const newCheckout = flag<boolean>({ key: "new-checkout", async decide({ entities }) { const config = await get<{ rollout: number }>("new-checkout"); const userId = entities?.user?.id ?? "anon"; return hash(userId) % 100 < (config?.rollout ?? 0); }, }); ```
Edge Config의 사이즈 상한은 512KB/스토어, 10스토어/프로젝트까지 확대되었습니다(2025년 말). 실무적으로는 "플래그 정의" "가격 테이블" "지역별 금지어" 같이 수 초에서 분 단위의 업데이트로 충분한 설정값을 저장하는 용도가 중심이며, 사용자 프로필 같은 고빈도 업데이트 데이터에는 적합하지 않습니다. 그런 경우에는 KV나 Redis를 사용합니다.
Observability와 Sourcemaps
Fluid Compute는 OpenTelemetry의 자동 계측을 기본 지원하며, `@vercel/otel` 패키지를 import하는 것만으로 trace가 Datadog / Honeycomb / Grafana Cloud로 흘러 들어갑니다. RSC 내에서 fetch를 호출하면 자동으로 span이 분리되고, Web Vitals(LCP / INP / CLS)는 RUM으로 별도 스트림으로 수집됩니다. 2026년부터는 Vercel Observability Plus에 의해 프로덕션 sourcemap을 안전하게 업로드하여 스택 트레이스를 TypeScript 줄 번호로 해결할 수 있게 되었습니다.
에러 버짓 운영은 Vercel Monitoring의 쿼리 언어(VQL)로 SLO를 정의하고, Slack / PagerDuty에 burn rate alert를 흘리는 것이 정석입니다. Edge Functions의 p99 레이턴시, Fluid의 concurrent invocations, Data Cache 히트율을 동일 대시보드에서 나란히 보면, PPR의 정적 비율 저하나 캐시 미스 증가를 조기에 감지할 수 있습니다. 엣지에서의 승부는 "빠름" 뿐만 아니라 "빠름이 변하지 않는 것"입니다.