핵심 답변: Nuxt 4.5는 Vite 8·SSR 스트리밍을 시험할 시점이지만, Nuxt 3 앱은 7월 31일 지원 종료 전에 보안 패치와 업그레이드 경로를 분리해야 한다
Nuxt 팀은 2026년 7월 18일 Nuxt 4.5.0과 유지보수 패치 Nuxt 3.21.9를 함께 공개했다. 4.5의 핵심은 Vite 8, Rspack 2/Rsbuild 기반, 실험적 SSR streaming, 안정적인 오류 코드와 tracing channel이다. 동시에 Nuxt 3의 공식 지원 종료일은 2026년 7월 31일로 공지됐다. 즉 이번 릴리스는 ‘새 기능을 켤지’와 ‘지원되는 보안 기준선으로 옮길지’를 같은 스프린트에서 다뤄야 하는 변화다. Nuxt 4.5.0 공식 릴리스가 날짜·버전·지원 종료 일정을 명시한다.
오늘의 결론은 두 갈래다. Nuxt 3을 유지하는 서비스는 적어도 3.21.9로 올려 CSS/SSR/라우팅 회귀를 확인하고, 7월 31일 이전에 Nuxt 4 전환 계획을 고정해야 한다. Nuxt 4 서비스는 Vite 8과 unhead v3을 ‘의존성 업그레이드’로 가볍게 취급하지 말고, custom plugin·head 타입·빌드 캐시를 스테이징에서 검증해야 한다. SSR streaming은 콘텐츠 중심 경로의 TTFB를 개선할 후보이지만, 첫 바이트 뒤에 상태·헤더·쿠키를 바꾸는 앱에서는 전면 활성화가 아니라 route 단위 실험이 안전하다.
무슨 일이 있었나
Nuxt는 7월 18일 v4.5.0을 배포했다. 공식 릴리스에 따르면 Vite 8, Rspack 2, Rsbuild 기반 Rspack builder, unhead v3, unctx v3을 포함하며, experimental.ssrStreaming, stable error code, useLayout, named views, SSR diagnostics-channel trace를 도입했다. Nuxt 5의 breaking change를 미리 시험할 future.compatibilityVersion: 5도 안내한다. 새 기능의 세부와 코드 예시는 발표 원문이 1차 출처다.
동시에 v3.21.9는 CSS 추출, Nitro transform, useFetch, navigation 등 3.x 호환성 수정을 backport한 패치다. 하지만 4.5의 Vite 8·Rspack 2·unhead v3은 4.x 전용이며, Nuxt 팀은 Nuxt 3의 EOL을 7월 31일로 밝혔다. 또한 6월 공개된 고위험 권고 CVE-2026-53721은 case-insensitive router와 case-sensitive routeRules matcher 불일치로 routeRules.appMiddleware 인증을 우회할 수 있었고, 4.4.7/3.21.7에서 수정됐다. 3.21.9와 4.5.0은 그 수정 버전보다 새롭다.
왜 중요한가
사실: 4.5는 Vite 8 및 unhead v3 같은 major dependency를 묶고, streaming은 experimental·기본 비활성이다. 스트리밍에서는 HTML shell을 먼저 내보내므로 렌더링 시작 뒤의 response mutation이 클라이언트에 닿지 않을 수 있다고 Nuxt가 명시한다. 해석: 성능 기능의 문제는 평균 응답 시간이 아니라, 오류·redirect·cookie가 섞인 경로에서 HTTP 의미가 달라지는 데 있다. 따라서 Web Vitals만으로 통과시키면 안 되며 상태 코드, Set-Cookie, canonical/meta, bot HTML까지 검사해야 한다. 불확실성: 각 서비스의 TTFB/LCP 개선 폭과 Vite 8 plugin 호환성은 앱의 모듈·호스팅·캐시 구조에 따라 달라진다.
Gil처럼 Nuxt 프론트엔드와 운영을 같이 맡는 팀에는 Nuxt 3 EOL이 더 긴급한 신호다. EOL은 즉시 장애가 난다는 뜻은 아니지만, 이후 발견되는 프레임워크 결함과 보안 이슈에 3.x 유지보수 패치가 보장되지 않는다는 뜻이다. 보안은 UI middleware에만 기대지 말고 API와 데이터 계층에서 재검증해야 한다. 위 권고가 보여 주듯 routeRules의 편의 설정을 인증 경계로 사용하면 라우팅 의미의 작은 차이가 데이터 노출로 이어질 수 있다.
1. Vite 8·unhead v3: 빌드가 성공해도 plugin과 head 계약을 검증한다
변경 내용: Nuxt 4.5는 Vite 8로 이동하고 unhead v3와 unctx v3를 포함한다. 공식 발표는 custom Vite plugin 또는 vite.config 조정이 있다면 Vite migration guide를 검토하라고 경고하며, unhead v3의 더 엄격한 useHead 타입과 promise input 제거 가능성을 알린다. 실제 영향: CI build가 통과해도 virtual module, transform order, 타입 추론, SEO head 병합이 달라질 수 있다. 특히 analytics·A/B test·이미지·PWA 모듈처럼 head를 만지는 확장 기능은 페이지별 canonical과 preload를 비교해야 한다.
적용/회피 조건: custom Vite plugin, workspace alias, legacy plugin, 직접 Vite 의존성이 있으면 lockfile을 고정한 별도 브랜치에서 시작한다. npx nuxt upgrade --dedupe는 의존성을 정리하는 권장 경로지만, production에서 즉시 실행하지 않는다. 검증 방법: nuxt typecheck, production build, Playwright의 주요 라우트 hydration test를 실행한다. SSR HTML에서 title, description, canonical, OG, modulepreload를 기준 버전과 diff하고 client console error=0, build 시간, bundle size를 기록한다. 원문과 Vite 공식 migration guide를 함께 참조한다.
2. SSR streaming: TTFB 최적화는 응답 불변성 검증 뒤에 켠다
변경 내용: experimental.ssrStreaming: true를 켜면 Nuxt는 head·style·preload·entry script를 먼저 flush하고 body를 Vue 렌더링에 따라 스트리밍한다. bot/crawler에는 자동 비활성화되며 botRegex를 조정할 수 있고, routeRules의 streaming: false로 경로를 제외할 수 있다. redirect, cache, ISR/SWR, noScripts, ssr:false 규칙은 buffered renderer로 fallback하는 것이 공식 설명이다.
실제 영향: 느린 데이터가 있는 콘텐츠 페이지에서 사용자가 더 빨리 shell을 볼 수 있다. 그러나 첫 byte 후 setResponseStatus(), cookie write, middleware header 변경이 있으면 최종 상태가 전달되지 않을 수 있다. 이는 에러 페이지가 200으로 보이거나 로그인 cookie가 누락되는 식의 운영 결함으로 나타날 수 있다. 적용/회피 조건: 정적에 가까운 읽기 전용 랜딩·아티클 경로부터 시작하고, 결제·로그인·preview·redirect가 많은 경로는 opt-out한다. 검증 방법: curl로 status·headers·TTFB를 비교하고, Googlebot과 일반 UA 각각의 HTML을 저장해 canonical/meta/본문을 비교한다. 302, 404, 500, Set-Cookie, cache-control, abort 네트워크 조건을 테스트 fixture로 만든다.
3. Nuxt 3.21.9와 EOL: ‘마지막 패치’와 ‘마이그레이션’을 분리한다
변경 내용: v3.21.9는 7월 18일 공개된 patch이며 CSS delivery, useFetch, Nitro와 navigation 관련 수정이 포함된다. Nuxt 팀은 3.x EOL을 7월 31일로 공지했다. 실제 영향: 당장은 3.x에 남더라도 패치 기준선을 올려 회귀와 알려진 보안 범위를 줄일 수 있다. 하지만 이것이 장기 지원 약속은 아니다. 3.21.9만 올리고 migration backlog를 닫는 것은 위험을 미루는 결정이다.
적용/회피 조건: 대형 모듈 호환성 때문에 v4 이동이 당장 어렵다면 3.21.9를 security baseline으로 삼고, Nuxt 4 별도 환경에서 모듈 인벤토리·Node 버전·배포 adapter를 검증한다. 검증 방법: package.json과 lockfile에서 Nuxt 및 @nuxt/* 중복 버전을 제거하고, SSR CSS·lazy component·payload extraction·nested layer를 포함한 smoke test를 만든다. migration branch에서 route snapshot, Lighthouse, server error rate를 기준선과 비교한다.
4. routeRules 보안: 앱 middleware는 API 인가의 대체물이 아니다
변경 내용: GHSA-mm7m-92g8-7m47/CVE-2026-53721은 routeRules.appMiddleware 사용 시 대소문자가 다른 URL이 middleware를 건너뛸 수 있던 문제다. 영향 범위는 Nuxt 4.0.0~4.4.6, Nuxt 3.11.0~3.21.6이며 각각 4.4.7과 3.21.7에서 패치됐다. 실제 영향: 예를 들어 /admin/dashboard만 규칙에 써 두고 API/SSR data fetch를 보호하지 않았다면 /Admin/dashboard가 페이지와 SSR 데이터를 노출할 수 있었다.
적용/회피 조건: 먼저 버전을 패치 이상으로 올린다. 임시 완화로 router를 sensitive하게 하거나 definePageMeta({ middleware })를 사용할 수 있지만, 둘 다 서버 API 인가를 대체하지 않는다. 검증 방법: 보호 경로의 모든 static segment를 대·소문자로 변형해 SSR 요청과 client navigation을 검사하고, API는 세션 없는 요청에 401/403을 반환하는지 테스트한다. <NoScript>에 비신뢰 입력을 넣었다면 별도 XSS 권고 GHSA-m3q2-p4fw-w38m도 확인하고 정적 text 또는 안전한 textContent로 바꾼다.
5. tracing과 stable error code: 배포 관측성의 공통 언어를 만든다
변경 내용: 4.5는 build/runtime 오류에 stable code와 해결 힌트를 제공하고, tracingChannel로 nuxt.render, nuxt.island, nuxt.data, nuxt.plugin diagnostics channel을 낸다. production output에서는 장황한 설명을 줄이고 code를 남기는 설계다. 실제 영향: 릴리스 직후 “Nuxt 오류가 늘었다”는 모호한 알림보다 코드·라우트·배포 SHA로 집계할 수 있다.
적용/회피 조건: observability SDK가 diagnostics-channel을 어떻게 수집하는지 먼저 검증한다. 채널 이름과 payload shape는 untracing registry가 안정화되는 동안 변할 수 있으므로 public dashboard schema에 바로 고정하지 않는다. 검증 방법: 스테이징에서 의도적인 async context 오류, data fetch 오류, island render를 발생시켜 trace correlation과 PII 마스킹을 확인한다. SLO는 route별 p95 server duration, 5xx, hydration error, NUXT 코드별 발생량으로 둔다.
개발자 실행 계획
- 자산 목록:
package.json, lockfile,nuxt.config.ts, custom Vite/Rspack plugin, @nuxt 모듈, 배포 preset을 표로 만들고 3.x/4.x 여부를 확정한다. - 즉시 패치: Nuxt 3은 3.21.9 이상, Nuxt 4는 4.5.0 이상을 스테이징에 pin하고
npm audit만으로 끝내지 말고 Nuxt 보안 권고의 영향 조건을 점검한다. - 인가 테스트:
tests/e2e/auth-route-case.spec.ts에 URL case 변형·직접 API 요청·SSR data 노출 검사를 넣는다. - 업그레이드 검증:
npx nuxt upgrade --dedupe를 feature branch에서 실행하고 typecheck, build, 핵심 route Playwright를 수행한다. - head 회귀 검사: 대표 페이지의 SSR HTML snapshot으로 canonical/robots/OG/schema/preload와 HTTP header를 비교한다.
- streaming canary:
nuxt.config.ts에서 streaming을 콘텐츠 route에만 1% canary로 설정하고 TTFB, 5xx, redirect/cookie 오류, bot HTML 차이를 관찰한다. - 관측성:
tracingChannel은 스테이징에서만 먼저 켜고 trace 비용·PII·NUXT error code 대시보드를 검토한다. - EOL 일정: 7월 31일 이전 Nuxt 4 전환의 담당자·모듈 blocker·롤백 release를 티켓으로 고정한다.
리스크와 한계
Nuxt 4.5의 streaming은 experimental이다. TTFB가 좋아져도 LCP가 반드시 개선되는 것은 아니며, CDN buffering·서버리스 adapter·클라이언트 hydration이 결과를 바꾼다. Vite 8, Rspack 2, unhead v3은 major dependency 전환이므로 custom plugin·타입·head runtime에 호환성 문제가 나올 수 있다. Nuxt 5 compatibility option도 사전 검증 수단이지 production 보증이 아니다.
롤백 기준을 배포 전에 합의한다. authenticated route에서 header/status/cookie가 하나라도 달라지거나, SEO snapshot이 달라지거나, 5xx/hydration 오류가 기준보다 증가하면 streaming부터 끄고 이전 lockfile/이미지로 되돌린다. Vite 8 문제는 Nuxt 버전 전체 롤백보다 plugin pin 또는 설정 수정으로 분리 가능한지 먼저 확인한다. Nuxt 3 EOL이라는 사실은 확인됐지만, 각 외부 모듈의 지원 상태는 별도 공식 문서로 확인해야 한다.
FAQ
Nuxt 3.21.9를 설치하면 Nuxt 3 지원 종료 문제가 해결되나요?
아니다. 3.21.9는 2026년 7월 18일의 유지보수 패치이며, Nuxt 팀이 공지한 3.x EOL은 7월 31일이다. 패치로 현재 기준선을 올리고, 별도로 Nuxt 4 전환과 모듈 호환성 검증을 완료해야 한다.
Nuxt 4.5의 SSR streaming은 SEO에 안전한가요?
Nuxt는 crawler에서 자동 비활성화한다고 설명하지만, 실제 bot user agent·CDN·route rule 조합은 서비스마다 다르다. Googlebot/Bingbot과 일반 브라우저의 HTML, status, canonical, robots meta를 실제 요청으로 비교한 뒤 route별로 켜야 한다.
routeRules.appMiddleware로 관리자 페이지를 보호해도 되나요?
패치 버전으로 올려도 UI middleware만을 보안 경계로 삼으면 안 된다. 권고의 case mismatch는 앱 계층 보호가 우회될 수 있음을 보여 준다. API와 데이터 fetch에서 세션·역할·테넌트 인가를 다시 검사하고, 페이지 middleware는 UX 보조로 사용한다.
출처 및 추가 읽기
더 깊게 읽기: 실전 가이드
이 리포트는 최근 흐름을 빠르게 파악하기 위한 요약입니다. 실제 프로젝트에 적용할 때는 아래의 기준 글과 함께 확인하면 더 안전합니다.