Cloudflare가 일주일 만에 AI로 Next.js를 재구축한 방법

본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.

_{*이 게시물은 빌드 시간 벤치마크의 오타를 수정하기 위해 태평양 시간 오후 12:35에 업데이트되었습니다.}

지난주, 한 엔지니어와 AI 모델이 가장 인기 있는 프런트엔드 프레임워크를 처음부터 다시 구축했습니다. 그 결과, vinext ("vee-next"라고 발음됨)는 Next.js를 드롭인으로 대체합니다. Vite를 기반으로 구축되었으며, 단일 명령으로 Cloudflare Workers에 배포됩니다. 초기 벤치마크에서는 프로덕션 앱을 최대 4배 더 빠르게 구축하고 최대 57% 더 작은 클라이언트 번들을 생성합니다. 그리고 Cloudflare는 이미 고객이 이를 프로덕션으로 실행하고 있습니다. 

이 모든 작업에 토큰으로 약 1,100달러가 들었습니다.

Next.js는 가장 인기 있는 React 프레임워크입니다. 수백만 명의 개발자가 이 플랫폼을 사용합니다. 프로덕션 웹의 상당 부분을 구동하는 데는 타당한 이유가 있습니다. 개발자 경험이 최고입니다.

그러나 Next.js를 더 광범위한 서버리스 생태계에서 사용할 때 배포 문제가 있습니다. 이 도구는 전적으로 맞춤형입니다. Next.js는 Turbopack에 막대한 투자를 했지만, Cloudflare, Netlify, AWS Lambda에 배포하려면 해당 빌드 결과물을 대상 플랫폼에서 실제로 실행할 수 있는 것으로 바꾸어야 합니다.

“OpenNext라는 게 이런 일이 아닐까요?”라고 생각하고 계신 분이 있다면, 그 생각이 맞습니다. 

OpenNext는 바로 이 문제를 해결하기 위해 구축되었습니다. 또한 Cloudflare의 당사를 포함한 여러 공급자가 OpenNext에 많은 엔지니어링 노력을 기울였습니다. 이는 효과가 있지만 빠르게 한계에 부딪히고 두더지 잡기 게임이 됩니다. 

Next.js 출력을 기반으로 구축하는 것은 어렵고 취약한 접근 방식임이 입증되었습니다. OpenNext는 Next.js의 빌드 출력을 리버스 엔지니어링해야 하므로 버전 간에 예측할 수 없는 변경이 발생하며 수정하는 데 많은 작업이 필요합니다. 

Next.js는 최고 수준의 어댑터 API를 개발하고 있으며, 우리는 이를 위해 그들과 협력하고 있습니다. 아직 초기 단계이지만, 어댑터를 사용하더라도 맞춤형 Turbopack 툴체인을 기반으로 구축하고 있습니다. 그리고 어댑터는 빌드 및 배포만 담당합니다. 다음 개발 단계는 Node.js에서만 독점적으로 실행되며 다른 런타임에 연결할 수 있는 방법이 없습니다. 애플리케이션이 Durable Objects, KV, AI 바인딩 등의 플랫폼별 API를 사용하는 경우, 우회 방법 없이는 개발 환경에서 해당 코드를 테스트할 수 없습니다.

Next.js 출력을 조정하는 대신 Vite 에 직접 Next.js API 표면을 다시 구현한다면 어떨까요? Vite는 Next.js 외부의 대부분의 프런트 엔드 생태계에서 사용하는 빌드 도구로, Astro, SvelteKit, Nuxt, Remix와 같은 프레임워크를 지원합니다. 단순한 래퍼나 어댑터가 아니라 깔끔하게 다시 구현되었습니다. 솔직히 말하자면 우리는 이것이 효과가 있을 것이라고 생각하지 않았습니다. 하지만 2026년이 되면서 소프트웨어 구축 비용이 완전히 바뀌었습니다.

예상했던 것보다 더 많은 진전 사항이 있었습니다.

npm install vinext

스크립트에서 next를 vinext로 바꾸면 다른 모든 것은 동일하게 유지됩니다. 기존 app/, pages/, 및 next.config.js는 있는 그대로 작동합니다.

vinext dev          # Development server with HMR
vinext build        # Production build
vinext deploy       # Build and deploy to Cloudflare Workers

이는 Next.js 및 Turbopack 출력의 래퍼가 아닙니다. 라우팅, 서버 렌더링, React 서버 구성 요소, 서버 작업, 캐싱, 미들웨어 등 API 표면의 대안적인 구현입니다. 이 모든 것은 플러그인인 Vite를 기반으로 구축되었습니다. 가장 중요한 것은 Vite 환경 API 덕분에 Vite 출력이 모든 플랫폼에서 실행된다는 점입니다.

초기 벤치마크 결과는 유망합니다. 33개 경로 공유 앱 라우터 애플리케이션을 사용하여 vinext를 Next.js 16과 비교했습니다. 두 프레임워크 모두 컴파일, 번들링, 서버 렌더링 경로 준비 등 동일한 작업을 수행합니다. Next.js의 빌드에서는 TypeScript 유형 검사와 ESLint를 비활성화하고(Vite는 빌드 중에는 이를 실행하지 않음), 강제 동적을 사용하여 Next.js가 정적 경로를 사전 렌더링하는 데 추가 시간을 소비하지 않도록 했습니다. 살펴봅니다. 목표는 번들러와 컴파일 속도만 측정하는 것이었습니다. 메인에 병합할 때마다 GitHub CI에서 벤치마크가 실행됩니다.

프로덕션 빌드 시간:

클라이언트 번들 크기(gzip 압축):

이 벤치마크는 프로덕션 제공 성능이 아닌 컴파일 및 번들링 속도를 측정합니다. 테스트 픽스처는 33개 경로 단일 앱이며, 모든 프로덕션 애플리케이션을 대표하는 샘플은 아닙니다. 세 가지 프로젝트가 계속 진행됨에 따라 이러한 수치는 계속 늘어날 것으로 예상됩니다. 전체 방법론 및 과거 결과 는 공개되어 있습니다. 이를 확정적이지 않은 방향이 아니라 방향이라고 생각하세요.

하지만 그 방향은 고무적입니다. Vite의 아키텍처, 특히 Rolldown (Vite 8에서 제공되는 Rust 기반 번들러)에는 빌드 성능 측면에서 구조적 이점이 있으며, 여기에서 명확하게 알 수 있습니다.

vinext는 Cloudflare Workers를 첫 번째 배포 대상으로 하여 구축되었습니다. 하나의 명령으로 소스 코드에서 실행 중인 Worker로 이동할 수 있습니다.

vinext deploy

이 플랫폼에서는 애플리케이션을 빌드하고, Worker 구성을 자동으로 생성하고, 배포하는 등 모든 작업을 처리합니다. 앱 라우터와 Pages 라우터는 모두 완전한 클라이언트 측 수분 공급, 대화형 구성 요소, 클라이언트 측 탐색, React 상태를 통해 Workers에서 작동합니다.

프로덕션 캐싱의 경우 vinext에는 즉시 사용 가능한 ISR(증분 정적 재생)을 제공하는 Cloudflare KV 캐시 핸들러가 포함되어 있습니다.

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

setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));

KV는 대부분의 애플리케이션에 적합한 기본값이지만, 캐싱 계층은 플러그인 방식으로 설계되었습니다. setCacheHandler 호출은 백엔드에서 의미가 있는 것은 무엇이든 교체할 수 있음을 의미합니다. R2는 캐시된 페이로드가 크거나 액세스 패턴이 다른 앱에 더 적합할 수 있습니다. 또한 더 적은 구성으로 강력한 캐싱 계층을 제공할 수 있도록 Cache API를 개선하기 위해 노력하고 있습니다. 앱에 맞는 캐싱 전략을 선택하는 유연성이 목표입니다.

현재 실행 중인 라이브 예시:

• App 라우터 Playground

• Hacker News 클론

• 앱 라우터 최소

• Pages Router 최소

또한 이제 개발 및 배포 단계 모두에서 전체 앱이 workerd에서 실행되므로 getPlatformProxy 와 같은 해결 방법이 필요 없는 Next.js 앱에서 Cloudflare 에이전트가 실행되는 라이브 예시 도 있습니다. 즉, Durable Objects, AI 바인딩, 기타 모든 Cloudflare 전용 서비스를 손상 없이 사용할 수 있습니다. 여기를 살펴보세요.

현재 배포 대상은 Cloudflare Workers이지만, 이는 전체 그림의 일부에 불과합니다. vinext의 95%는 순수 Vite입니다. 라우팅, 모듈 shim, SSR 파이프라인, RSC 통합 등 그 어떤 것도 Cloudflare 전용이 아닙니다.

Cloudflare는 고객에게 이 툴체인을 도입하기 위해 다른 호스팅 공급자와 협력하는 것을 고려하고 있습니다( Vercel 에 대한 개념 증명을 작업하는 데 30분도 걸리지 않았습니다!). 이는 오픈 소스 프로젝트이며, Cloudflare에서는 장기적인 성공을 위해 생태계 전반의 파트너와 협력하여 지속적인 투자를 보장하는 것이 중요하다고 생각합니다. 다른 플랫폼의 PR도 환영합니다. 배포 대상을 추가하고 싶다면 이슈를 열거나 문의하세요.

다음 사항을 명확히 하고자 합니다. vinext가 실험적이라는 점입니다. 만들어진 지 일주일도 되지 않았으며, 아직 대규모 유의미한 트래픽을 검증받지도 못했습니다. 프로덕션 애플리케이션용으로 평가하는 경우에는 주의하여 진행하세요.

테스트 스위트는 Next.js 테스트 스위트와 OpenNext의 Cloudflare 적합성 제품군에서 직접 포팅한 테스트를 포함하여 1,700여 개의 Vitest 테스트 및 380개의 Playwright E2E 테스트로 광범위합니다. 우리는 이것을 Next.js App Router Playground에서 확인했습니다. 범위는 Next.js 16 API 표면의 94%를 차지합니다. 실제 고객이 수행한 초기 결과는 고무적입니다. 우리는 National Design Studio의 베타 사이트 중 하나인 CIO.gov에서 모든 정부 기관 인터페이스를 최신화하는 것을 목표로 하는 팀과 협력하고 있습니다. 이들은 이미 프로덕션 환경에서 vinext를 실행하고 있으며, 빌드 시간과 번들 크기가 크게 개선되었습니다.

README는 지원되지 않거나 지원되지 않을 내용과 알려진 제한 사항에 대해 솔직하게 설명합니다. 우리는 많은 약속을 하지 않고 미리 약속하고 싶습니다.

vinext는 이미 정적 증가분 재생성(ISR)을 지원합니다. 모든 페이지에 대한 첫 번째 요청 후, Next.js와 마찬가지로 백그라운드에서 캐시되고 재검증됩니다. 이 부분은 지금도 효과가 있습니다.

vinext는 아직 빌드 시 정적 사전 렌더링을 지원하지 않습니다. Next.js에서 동적 데이터가 없는 페이지는 next build 중에 렌더링되어 정적 HTML로 제공됩니다. 동적 경로가 있는 경우에는 generateStaticParams()를 사용하여 미리 구축할 페이지를 열거합니다. vinext는 아직 그렇게 하지 않습니다.

이는 출시를 위한 의도적인 설계 결정이었습니다. 로드맵에 있지만, 귀하의 사이트가 100% 미리 구축된 HTML 정적 콘텐츠인 경우 현재 vinext에서 많은 이점을 얻지 못할 것입니다. 즉, 엔지니어가 토큰에 $1,100를 지출하고 Next.js를 재구축할 수 있다면, 10달러를 지출하고 Astro 와 같이 정적 콘텐츠용으로 특별히 설계된 Vite 기반 프레임워크로 마이그레이션할 수 있습니다(Cloudflare Workers에도 배포됨).

하지만 순전히 정적이 아닌 사이트의 경우, 빌드 시 모든 것을 사전 렌더링하는 것보다 더 나은 것을 할 수 있다고 생각합니다.

Next.js는 빌드 중에 generateStaticParams() 에 나열된 모든 페이지를 사전 렌더링합니다. 10,000개의 제품 페이지가 있는 사이트는 빌드 시 10,000개의 렌더링을 의미하지만, 해당 페이지의 99%는 요청을 수신하지 못할 수 있습니다. 빌드는 페이지 수에 비례하여 확장됩니다. 이것이 대규모 Next.js 사이트가 30분 빌드로 끝나는 이유입니다.

그래서 당사는 트래픽 인식 사전 렌더링 (TPR)을 구축했습니다. 현재는 실험 단계이며, 실제 테스트가 더 많아지면 기본값으로 설정할 계획입니다.

아이디어는 간단합니다. Cloudflare는 이미 사이트의 리버스 프록시입니다. 당사에는 귀하의 트래픽 데이터가 있습니다. 실제로 어떤 페이지가 방문되는지 알 수 있습니다. 따라서, 모든 것을 사전 렌더링하거나 아무것도 사전 렌더링하지 않는 대신, vinext는 배포 시 Cloudflare의 영역 분석을 쿼리하여 중요한 페이지만 사전 렌더링합니다.

vinext deploy --experimental-tpr

  Building...
  Build complete (4.2s)

  TPR (experimental): Analyzing traffic for my-store.com (last 24h)
  TPR: 12,847 unique paths — 184 pages cover 90% of traffic
  TPR: Pre-rendering 184 pages...
  TPR: Pre-rendered 184 pages in 8.3s → KV cache

  Deploying to Cloudflare Workers...

100,000개의 제품 페이지가 있는 사이트의 경우 거듭제곱의 법칙에 따르면 일반적으로 50~200페이지의 페이지로 트래픽의 90%가 이동합니다. 초 단위로 사전 렌더링됩니다. 그 외에는 모두 온디맨드 SSR에 의존하고 첫 번째 요청 후에 ISR을 통해 캐시합니다. 새로 배포할 때마다 현재 트래픽 패턴을 기반으로 집합이 새로 고쳐집니다. 입소문을 타는 페이지는 자동으로 선택됩니다. 이 모든 것은 generateStaticParams() 없이도 빌드를 프로덕션 데이터베이스에 연결하지 않고도 작동합니다.

이러한 프로젝트는 일반적으로 엔지니어 팀이 몇 년은 아니더라도 수개월이 걸립니다. 여러 회사의 여러 팀에서 이를 시도했지만, 그 범위는 엄청납니다. Cloudflare에서 체험한 적이 있습니다! 2개의 라우터, 33개 이상의 모듈 쉼, 서버 렌더링 파이프라인, RSC 스트리밍, 파일 시스템 라우팅, 미들웨어, 캐싱, 정적 내보내기. 아무도 성공하지 못한 데는 이유가 있습니다.

이번에는 일주일 만에 완료할 수 있었습니다. AI를 지시하는 엔지니어(기술 엔지니어링 관리자) 1명.

첫 번째 커밋은 2월 13일에 이루어졌습니다. 같은 날 저녁이 되자 Pages Router와 App Router 모두 미들웨어, 서버 작업, 스트리밍과 함께 기본 SSR을 구현했습니다. 다음 날 오후까지 App 라우터 Playground는 11개 경로 중 10개를 렌더링하고 있었습니다. 3일째 되던 날, vinext deploy는 전체 클라이언트 하이드레이션과 함께 Cloudflare Workers에 앱을 배포했습니다. 그리고 나머지 한 주간, 에지 케이스 수정, 테스트 스위트 확장, API 적용 범위를 94%까지 확장하는 등 강화 작업에 시간을 보냈습니다.

이전의 시도와 무엇이 바뀌었을까요? AI가 더 좋아졌습니다. 훨씬 개선되었습니다.

모든 프로젝트가 이렇게 진행되는 것은 아닙니다. 이는 적절한 시기에 몇 가지 일을 했기 때문에 일어난 일입니다.

Next.js는 잘 지정되어 있습니다. 방대한 문서, 방대한 사용자 기반, 수년간의 스택 오버플로 답변과 튜토리얼이 있습니다. API 표면은 학습 데이터 전체에 걸쳐 있습니다. Claude에게 getServerSideProps를 구현하거나 useRouter 의 작동 방식을 설명하도록 요청하면 할루시네이션을 하지 않습니다. Next 작동 방식을 알고 있습니다.

Next.js에는 정교한 테스트 스위트가 있습니다. Next.js 리포지토리 에는 모든 기능 및 에지 사례를 다루는 수천 개의 E2E 테스트가 포함되어 있습니다. 저희는 테스트 제품군에서 직접 테스트를 포팅했습니다(코드에서 속성을 확인할 수 있습니다). 이를 통해 우리는 기계적으로 검증할 수 있는 사양을 확보할 수 있었습니다.

Vite는 훌륭한 기반 솔루션입니다. Vite는 빠른 HMR, 네이티브 ESM, 깔끔한 플러그인 API, 프로덕션 번들링 등 프런트 엔드 도구의 어려운 부분을 처리합니다. 번들러를 구축할 필요가 없었습니다. Next.js를 말하는 법을 가르쳐 주기만 하면 되었습니다. @vitejs/plugin-rsc는 아직 초기 단계이지만, 처음부터 RSC 구현을 구축하지 않고도 React Server Components를 지원했습니다.

모델들이 따라잡았습니다. 불과 몇 달 전만 해도 이런 일은 불가능했을 것입니다. 이전 모델은 이 정도 크기의 코드베이스에서는 일관성을 유지할 수 없었습니다. 새로운 모델은 전체 아키텍처의 맥락을 파악하고, 모듈이 상호 작용하는 방식을 추론하며, 추진력을 유지할 수 있도록 올바른 코드를 자주 생성할 수 있습니다. 때때로 저는 버그를 파악하기 위해 Next, Vite, React 내부로 이동하는 것을 보았습니다. 최첨단 모델이 인상적이며 계속 개선되고 있는 것 같습니다.

이 모든 것이 동시에 사실이어야 했습니다. 잘 문서화된 대상 API, 포괄적인 테스트 스위트, 그 기반이 되는 탄탄한 구축 도구, 실제로 복잡성을 처리할 수 있는 모델. 이 중 하나를 제거하면 잘 작동하지 않습니다.

vinext의 거의 모든 코드 줄은 AI가 작성했습니다. 하지만 더 중요한 것은 모든 줄이 사람이 작성한 코드와 동일한 품질의 게이트를 통과했다는 사실입니다. 이 프로젝트에는 1,700여 개의 Vitest 테스트, 380개의 Playwright E2E 테스트, tsgo를 통한 전체 TypeScript 유형 검사, oxlint를 통한 linting이 포함되어 있습니다. 지속적 통합을 이용하면 모든 풀 요청에서 이 모든 것이 실행됩니다. 코드베이스에서 AI의 생산성을 높이려면 좋은 가드레일 세트를 수립하는 것이 중요합니다.

이 프로세스는 계획과 함께 시작되었습니다. 저는 아키텍처를 정의하기 위해 몇 시간 동안 OpenCode 에서 Claude와 대화를 나누었습니다. 무엇을 빌드하고, 어떤 순서로, 어떤 추상화를 사용할 것입니다. 그 계획은 북극성이 되었습니다. 이후의 워크플로우는 간단했습니다.

1. 작업을 정의합니다("usePathname, useSearchParams, useRouter 로 다음/탐색shim을 구현합니다").

2. AI가 구현 및 테스트 작성 과정을 작성하도록 합니다.

3. 테스트 스위트를 실행하세요.

4. 테스트를 통과하면 병합합니다. 그렇지 않다면 AI가 오류를 출력하고 반복하도록 합니다.

5. 반복하세요.

우리는 코드 검토를 위해 AI 에이전트도 연결했습니다. PR이 열리면 에이전트가 검토했습니다. 리뷰 댓글이 돌아오자 다른 에이전트가 리뷰 댓글을 달았습니다. 피드백 루프는 대부분 자동화되었습니다.

매번 완벽하게 작동하지는 않았습니다. 완전히 잘못된 PR도 있었습니다. AI는 옳게 보이지만 실제 Next.js 동작과 일치하지 않는 무언가를 자신 있게 구현할 것입니다. 정기적으로 경로를 수정해야 했습니다. 아키텍처 결정, 우선순위 지정, AI가 언제 막다른 길로 접어들었는지 파악하는 것, 그게 전부였습니다. AI에게 좋은 방향, 좋은 컨텍스트, 좋은 보호 장치를 제공하면 AI는 매우 생산적일 수 있습니다. 하지만 인간이 조종해야 합니다.

브라우저 수준 테스트의 경우 에이전트-브라우저를 사용하여 실제 렌더링된 출력, 클라이언트 측 탐색, 수화 행동을 확인했습니다. 단위 테스트에서는 미묘한 브라우저 문제가 많이 누락됩니다. 이 점에 주목했습니다.

프로젝트를 진행하는 동안 우리는 OpenCode에서 800개 이상의 세션을 실행했습니다. 총 비용: 약 1,100달러(Claude API 토큰).

스택에 왜 그렇게 많은 레이어가 있을까요? 이 프로젝트를 하면서 이 질문에 대해 깊이 생각해보게 되었습니다. 그리고 AI가 답에 어떤 영향을 미치는지 고려해야 합니다.

대부분의 소프트웨어 추상화는 사람의 도움이 필요하기 때문에 존재합니다. 전체 시스템을 기억할 수 없었으므로 복잡성을 관리할 계층을 구축했습니다. 각 계층은 다음 사람의 작업을 더 쉽게 만들었습니다. 그래서 여러분은 프레임워크, 래퍼 라이브러리, 수천 줄의 글루 코드로 된 프레임워크로 귀결됩니다.

AI도 같은 제한이 없습니다. 전체 시스템을 컨텍스트에 고려하고 코드만 작성하면 됩니다. 정리를 위해 중간 프레임워크가 필요하지 않습니다. 사양과 구축할 기반만 있으면 됩니다.

어떤 추상이 진정으로 기반이 되는지, 어떤 추상이 인간의 인식을 위한 것인지는 아직 명확하지 않습니다. 이러한 경계는 앞으로 몇 년 동안 많이 바뀔 것입니다. 하지만 vinext는 데이터 요소입니다. API 계약, 빌드 도구, AI 모델만 가져왔고, 그 중간의 모든 내용은 AI가 작성했습니다. 중간 프레임워크가 필요하지 않습니다. Cloudflare는 이러한 패턴이 많은 소프트웨어에서 반복될 것이라고 생각합니다. 여러 해에 걸쳐 구축한 계층만으로는 충분하지 않습니다.

Vite 팀에 감사드립니다. Vite 는 이 모든 것이 뒷받침되는 토대입니다. @vitejs/plugin-rsc 는 아직 초기 단계이지만, 처음부터 구축할 필요 없이 RSC를 지원할 수 있었습니다. 그렇지 않았다면 큰 문제가 되었을 겁니다. Vite 유지 관리자들은 신속하게 지원해 주었습니다. 제가 플러그인을 한 번도 테스트해보지 못한 영역으로 확장해 볼 때 도움이 되었습니다.

저희는 또한 Next.js 팀에 감사의 말씀을 전하고 싶습니다. Cloudflare에서는 React 개발의 기준을 한 단계 올린 프레임워크를 구축하는 데 여러 해에 걸쳐 노력해 왔습니다. API 영역이 문서화가 잘 되어 있고 테스트 제품군이 매우 포괄적이라는 사실은 이 프로젝트가 가능했던 큰 부분입니다. vinext는 자신들의 기준이 없었다면 존재할 수 없었을 것입니다.

vinext에는 마이그레이션을 처리하는 에이전트 기술 이 포함되어 있습니다. Claude Code, OpenCode, Cursor, Codex 등 수십 가지의 AI 코딩 도구와 함께 작동합니다. 이를 설치하고, Next.js 프로젝트를 열고, AI에게 마이그레이션을 지시합니다.

npx skills add cloudflare/vinext

그런 다음, 지원되는 도구에서 Next.js 프로젝트를 열고 다음과 같이 말합니다.

migrate this project to vinext

이 기술은 호환성 검사, 종속성 설치, 구성 생성, 개발 서버 시작을 처리합니다. vinext가 무엇을 지원하는지 알고 있으며, 수동 관리가 필요한 모든 것에 플래그를 지정합니다.

또는 수동으로 수행하는 것을 선호하는 경우:

npx vinext init    # Migrate an existing Next.js project
npx vinext dev     # Start the dev server
npx vinext deploy  # Ship to Cloudflare Workers

소스는 github.com/cloudflare/vinext에 있습니다. 문제, PR 및 피드백을 환영합니다.