Cloudflare Vinext: Next.js 앱을 Vite로 돌리기

2026년 2월 말, Cloudflare가 꽤 파격적인 프로젝트를 공개했습니다. 이름은 Vinext — Next.js의 공개 API를 Vite 플러그인으로 재구현한 오픈소스 프로젝트인데요. Next.js를 포크한 게 아니라, Next.js가 제공하는 라우팅, 서버 렌더링, next/* 모듈 임포트, CLI 등의 API 표면을 Vite 생태계 위에서 처음부터 다시 만든 겁니다.

“AI가 일주일 만에 만들었다”는 타이틀이 워낙 자극적이라 화제가 됐는데, 막상 내용을 들여다보면 기술적으로 꽤 흥미로운 지점이 많습니다. 이번 글에서는 Vinext가 왜 만들어졌고 어떤 구조로 동작하는지, 실제로 써볼 만한 물건인지 살펴보겠습니다.

Next.js의 구조적 문제

Next.js는 React 생태계에서 가장 대중적인 메타 프레임워크입니다. SSR부터 정적 사이트 생성, 파일 기반 라우팅, 이미지 최적화까지 웹 애플리케이션에 필요한 거의 모든 걸 제공하죠.

문제는 Next.js가 Vercel 플랫폼에 최적화되어 있다는 점입니다. Vercel에 배포하면 모든 기능이 매끄럽게 돌아가지만, 다른 플랫폼에서 운영하려면 이야기가 달라집니다. 빌드 결과물을 수정해야 하고, 별도의 어댑터를 붙여야 하고, 심지어 문서화되지 않은 동작에 의존해야 하는 경우까지 생기거든요.

OpenNext 같은 프로젝트가 이 문제를 해결하려고 시도했습니다. Next.js의 빌드 결과물을 역공학해서 AWS Lambda나 Cloudflare Workers 같은 다른 플랫폼에서 돌릴 수 있게 만들어주는 건데요. 이 접근 방식은 Next.js 버전이 바뀔 때마다 내부 구현이 달라져서 깨질 위험이 있다는 근본적인 한계가 있었습니다.

Vinext는 완전히 다른 접근을 택했습니다. 빌드 결과물을 뜯어고치는 대신, Next.js의 공개 API 자체를 Vite 위에서 재구현한 거죠.

Vinext의 핵심 아이디어

Vinext의 구조를 한 문장으로 요약하면 이렇습니다.

“Next.js의 API 표면은 유지하되, 그 아래 엔진은 Vite로 교체한다.”

기존 Next.js 앱에서 사용하던 app/ 디렉토리, pages/ 디렉토리, next.config.js를 그대로 가져다 쓸 수 있습니다. next/link, next/image, next/router 같은 모듈 임포트도 동일하게 동작하고요. 달라지는 건 내부에서 코드를 컴파일하고 번들링하는 엔진뿐입니다.

Cloudflare 블로그에 따르면, Vinext의 약 95%는 순수 Vite 코드이고 나머지 5%만 플랫폼별 통합 코드라고 합니다. Vite의 플러그인 생태계와 Environment API를 최대한 활용한 결과물이라 할 수 있겠네요.

API 커버리지

Vinext는 Next.js 16의 공개 API 중 약 94%를 지원한다고 밝히고 있습니다. 어디까지 지원하는지 살펴보면, 라우팅 쪽에서는 App Router와 Pages Router를 모두 지원합니다. 동적 라우트([param]), catch-all([...slug]), 라우트 그룹, 병렬 라우트, 인터셉팅 라우트까지 파일 시스템 기반 라우팅의 거의 모든 패턴을 다루고 있어요.

서버 렌더링 쪽도 폭넓게 커버합니다. React Server Components, Server Actions, 스트리밍 SSR은 물론이고, Pages Router의 getStaticProps, getServerSideProps, getStaticPaths도 fallback 모드 포함해서 지원합니다. ISR(Incremental Static Regeneration)과 "use cache" 디렉티브도 동작하고요.

next/* 모듈 임포트도 대부분 동작해요. next/link는 prefetch와 IntersectionObserver까지 전체 지원하고, next/image는 리모트 이미지에 @unpic/react, 로컬 이미지에 srcSet 방식을 쓰는 식으로 구현했습니다. next/router와 next/navigation도 useRouter, usePathname, redirect 같은 핵심 API가 동작하고, next/server의 NextRequest/NextResponse, next/headers의 비동기 headers()와 cookies()도 지원합니다. 캐싱 쪽에서는 next/cache의 revalidateTag, revalidatePath는 물론 "use cache" 디렉티브와 cacheLife()까지 커버하고, next/og로 OG 이미지 생성도 가능합니다.

지원하지 않는 기능도 있습니다. next/font의 폰트 서브세팅과 셀프 호스팅, 빌드 타임 이미지 최적화, 도메인 기반 i18n 라우팅 등은 아직 미지원이에요. Vercel의 문서화되지 않은 내부 동작에 의존하는 기능도 의도적으로 지원하지 않고요.

성능 벤치마크

33개 라우트를 가진 애플리케이션으로 Next.js 16.1.6과 비교한 벤치마크 결과가 공개되어 있습니다.

빌드 시간부터 보면, Next.js가 Turbopack으로 7.38초 걸린 것에 비해 Vinext는 Vite 7 + Rollup 조합에서 4.64초(1.6배 빠름), Vite 8 + Rolldown 조합에서 1.67초(4.4배 빠름)를 기록했습니다.

클라이언트 번들 크기도 차이가 큽니다. Next.js의 gzip 압축된 클라이언트 번들이 168.9KB인 반면, Vinext는 72.9KB로 약 57% 줄었습니다.

다만 이 벤치마크는 컴파일과 번들링 성능만 측정한 거라, 프로덕션 서빙 성능은 별개의 이야기이긴 하고요.

시작하기

기존 Next.js 프로젝트를 Vinext로 마이그레이션하는 방법은 세 가지입니다.

가장 간단한 방법은 vinext init 명령어를 사용하는 겁니다.

npx vinext init

이 명령어가 호환성 검사, 의존성 설치, ESM 설정, vite.config.ts 생성, npm 스크립트 교체를 자동으로 처리해줍니다.

마이그레이션이 끝나면 package.json의 스크립트가 이렇게 바뀝니다.

{
  "scripts": {
    "dev": "vinext dev",
    "build": "vinext build",
    "start": "vinext start"
  }
}

개발 서버를 띄워보면 기존 Next.js 앱이 Vite 위에서 돌아가는 걸 확인할 수 있습니다.

npx vinext dev

마이그레이션 전에 미리 호환성만 확인하고 싶다면 vinext check 명령어를 사용하면 됩니다.

npx vinext check

지원되지 않는 기능을 사용하고 있는지 스캔해서 알려줍니다.

Cloudflare Workers 배포

Vinext의 가장 큰 강점은 Cloudflare Workers에 한 줄로 배포할 수 있다는 점입니다.

npx vinext deploy

이 명령어 하나로 빌드, Worker 설정 파일 생성, 배포가 한꺼번에 처리됩니다. wrangler.jsonc나 worker/index.ts 같은 설정 파일도 자동으로 생성해주기 때문에 Wrangler를 따로 설정할 필요가 없어요.

환경별 배포도 지원합니다.

npx vinext deploy --env staging
npx vinext deploy --preview

ISR을 사용한다면 캐시 핸들러를 설정해야 하는데, Cloudflare KV를 사용하는 내장 핸들러가 제공됩니다.

import { setCacheHandler } from "next/cache";
import { KVCacheHandler } from "vinext/cloudflare";

setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));

R2나 커스텀 백엔드를 쓰고 싶다면 CacheHandler 인터페이스를 구현하면 되는 플러그러블 구조입니다.

Traffic-Aware Pre-Rendering

Vinext에는 실험적이지만 꽤 참신한 기능이 하나 있습니다. Traffic-Aware Pre-Rendering(TPR)이라고 하는데, 배포 시점에 Cloudflare의 실제 트래픽 데이터를 분석해서 자주 방문되는 페이지만 선별적으로 프리렌더링하는 기능입니다.

npx vinext deploy --experimental-tpr

기존 SSG 방식에서는 generateStaticParams()로 프리렌더링할 페이지 목록을 직접 지정해야 했습니다. 페이지가 수만 개인 대규모 사이트에서는 빌드 시간이 길어지고, 프로덕션 데이터베이스에 빌드 타임 접근이 필요한 경우도 생기죠.

TPR은 이 문제를 뒤집어서 접근합니다. 존(zone) 분석 데이터를 기반으로 트래픽의 90%를 차지하는 상위 페이지만 프리렌더링하고, 나머지는 요청 시 SSR로 처리한 뒤 ISR 캐싱으로 잡아두는 식입니다.

프리렌더링 범위도 조절할 수 있습니다.

npx vinext deploy --experimental-tpr --tpr-coverage 95
npx vinext deploy --experimental-tpr --tpr-limit 500
npx vinext deploy --experimental-tpr --tpr-window 48

--tpr-coverage로 전체 트래픽 대비 커버 비율을, --tpr-limit으로 최대 프리렌더링 페이지 수를, --tpr-window로 분석할 트래픽 기간(시간 단위)을 설정할 수 있습니다.

AI로 만든 프로젝트

Vinext가 화제가 된 이유 중 하나는 개발 방식 때문입니다. Cloudflare 블로그에 따르면, 한 명의 엔지니어가 Claude Code를 사용해서 800회 이상의 개발 세션을 진행하며 2026년 2월 13일부터 19일까지 약 일주일 만에 만들었다고 합니다. AI 토큰 비용은 약 $1,100이었고, “거의 모든 코드가 AI로 작성되었다”고 밝혔습니다.

개발 타임라인을 보면 속도가 놀랍습니다. 첫째 날 저녁에 이미 양쪽 라우터(App Router, Pages Router)의 기본 SSR, 미들웨어, 서버 액션, 스트리밍이 동작했고, 둘째 날 오후에는 App Router Playground의 11개 라우트 중 10개가 렌더링됐습니다. 셋째 날에 vinext deploy까지 완성되어 하이드레이션이 포함된 전체 배포 파이프라인이 돌아갔고, 나머지 4일은 안정화와 테스트 확충에 썼다고 합니다.

물론 이게 가능했던 배경이 있습니다. Next.js는 공개 API가 잘 문서화되어 있고 테스트 코드도 풍부합니다. Vite가 프론트엔드 빌드의 어려운 부분을 이미 해결해놓은 상태이기도 했고요. 아키텍처 결정과 우선순위는 인간이 잡고, 구현과 테스트는 AI가 맡는 역할 분담이 잘 맞아떨어진 사례로 보입니다.

품질 검증에는 1,700개 이상의 Vitest 테스트와 380개 이상의 Playwright E2E 테스트가 사용되었습니다. Next.js와 OpenNext의 테스트 스위트에서 포팅한 것도 포함되어 있어서, API 호환성을 기계적으로 돌려볼 수 있는 구조예요.

실제로 쓸 수 있을까?

솔직히 말하면, Vinext는 아직 실험적 단계입니다. 공개된 지 일주일도 안 됐고 대규모 트래픽을 받아본 적도 없어요. Cloudflare에서도 프로덕션 적용에는 신중하게 접근하라고 권고하고 있고요.

그래도 몇 가지 라이브 데모가 이미 Cloudflare Workers 위에서 돌아가고 있습니다. App Router Playground, Hacker News 클론, Nextra 문서 템플릿 등 6개의 예제 앱이 배포되어 있고, 미국 정부 기관인 CIO.gov의 베타 사이트에서 National Design Studio가 Vinext를 프로덕션으로 사용하고 있다는 언급도 있습니다.

그렇다면 현시점에서 Vinext가 적합한 상황은 어디일까요?

가장 먼저 떠오르는 건 Cloudflare Workers에 Next.js 앱을 배포하고 싶을 때입니다. OpenNext보다 안정적인 접근 방식이고, 배포도 명령어 한 줄이면 끝이니까요. 빌드 성능이 병목인 대규모 프로젝트라면 Vite 8 + Rolldown의 빌드 속도와 줄어든 번들 크기가 매력적일 겁니다.

반면 Node.js에서 셀프 호스팅하는 경우에는 아직 맞지 않아요. 배포 타겟이 Cloudflare Workers로 한정되어 있거든요. next/font 폰트 최적화나 빌드 타임 이미지 처리가 필요하다면 현재로서는 제약이 있습니다.

마치며

Vinext는 “Next.js의 API는 좋은데, 특정 플랫폼에 종속되는 건 싫다”는 불만에 대한 하나의 답을 제시합니다. 빌드 결과물을 역공학하는 대신 API를 재구현한다는 발상이 핵심이고, Vite 생태계 위에서 Cloudflare Workers까지 한 줄 배포로 이어지는 흐름이 매끄럽습니다.

아직 실험적 프로젝트이고 프로덕션 검증이 부족한 건 사실입니다. 하지만 94% API 커버리지에 2,000개 넘는 자동화 테스트, 이미 돌아가는 라이브 데모까지 보면 단순한 프로토타입 수준은 넘어섰다고 봐야겠죠.

Next.js를 쓰고 있는데 Vercel 외의 플랫폼을 고려하고 있다면, Vinext의 발전을 지켜볼 가치가 충분합니다. 관심이 있으시다면 Vinext GitHub 저장소와 Cloudflare 공식 블로그 포스트를 참고해보세요.

Cloudflare Workers나 Vite에 대해 더 알고 싶으시다면 관련 포스팅도 함께 읽어보시길 추천드립니다.