원문 제목: How we rebuilt Next.js with AI in one week 원문 링크: https://blog.cloudflare.com/vinext/ 번역 생성일: 2026-02-25 KST
(길이상 요약 번역)
Cloudflare는 Next.js를 다른 서버리스 환경에 배포할 때 생기는 마찰(출력 포맷 호환, OpenNext 유지 부담, dev 환경 불일치)을 줄이기 위해, **Next.js API 표면을 Vite 위에서 다시 구현한 vinext**를 공개했습니다.
핵심 주장:
next대신vinext로 교체해도 기존app/,pages/,next.config.js를 최대한 유지할 수 있도록 설계- Cloudflare Workers 배포를
vinext deploy한 번으로 처리 - 초기 벤치마크에서 빌드 시간/번들 크기 개선을 확인
기존 방식(OpenNext)은 Next.js 산출물을 역해석해 플랫폼에 맞추는 구조라서:
- Next.js 버전 변화에 취약
- 호환 유지 비용이 큼
- 개발 단계에서 Node 종속성 때문에 플랫폼 고유 API 테스트가 어려움
vinext는 “어댑터”가 아니라 “재구현” 접근을 택했습니다.
같은 33개 라우트 앱으로 비교했을 때:
- 빌드 속도: Next.js 대비 최대 4.4배 빠름(실험 환경 기준)
- 클라이언트 번들(gzip): 최대 57% 감소
작성자는 이 수치를 “방향성 지표”로 봐야 한다고 명시합니다.
- Workers에 1커맨드 배포
- KV 기반 캐시 핸들러로 ISR 유사 흐름 제공
- 캐시 백엔드 교체 가능(R2 등)
즉, 런타임/캐시를 플랫폼 특성에 맞게 바꾸기 쉬운 구조를 목표로 합니다.
- 프로젝트는 experimental
- 대규모 트래픽 검증은 제한적
- 다만 테스트 수(유닛/E2E)가 많고, Next.js 테스트 일부를 포팅했다고 설명
- 현재는 정적 사전 생성보다 요청 후 캐시(ISR) 중심
- 실험 기능으로 “트래픽 기반 프리렌더링(TPR)” 제안
- 실제 유입이 많은 경로만 배포 시 선렌더
- 롱테일 페이지는 요청 시 생성/캐시
대형 카탈로그형 사이트에서 빌드 시간 폭증을 줄이려는 아이디어입니다.
작성자는 “코드 대부분을 AI가 작성했지만, 사람이 아키텍처/우선순위/품질 게이트를 강하게 잡아야 한다”는 점을 강조합니다.
운영 방식:
- 작업 단위 정의
- AI가 구현+테스트 작성
- 테스트 실패 로그를 다시 AI에 피드백
- 반복
핵심 메시지:
- AI만으로 자동 완성이 아니라, 명확한 스펙 + 테스트 + 리뷰 루프가 성패를 가름
- 대형 프레임워크급 작업도 “검증 가능한 범위로 쪼개면” 실행 가능해졌다는 사례
이 글은 단순 성능 자랑보다,
- Next.js 배포 생태계의 구조적 문제,
- Vite 기반 재구현 전략,
- AI 시대의 프레임워크 개발 방식(사람이 가드레일을 쥐는 모델) 을 함께 보여주는 사례입니다.