Nuxt 4.6·Vite 8·H3 v2 전환점 | Three-Day Frontend Runtime Upgrade Guide

요약: 2026년 10월 5~8일의 Nuxt/Vue/Vite 생태계에서는 Nuxt 4.6의 서버 API 분리, Nuxt CLI v4의 관측성 강화, Vite 다중 유지보수 라인의 패치, H3 v2 안정화가 한꺼번에 확인됐다. Nuxt 프론트엔드 팀의 우선순위는 새 기능을 즉시 넓게 적용하는 것이 아니라, 서버 의존성 경계·Node 런타임·개발 서버·오류 처리 경로를 작은 범위에서 검증하는 일이다.

핵심 답변: 이번 3일에 무엇을 해야 하나?

결론부터 말하면, Nuxt 4 사용 팀은 Nuxt 4.6을 통해 nuxt/server를 새 서버 코드의 기본 경계로 삼고, Nuxt 3 잔존 서비스는 v4 마이그레이션 계획을 확정할 시점이다. Vite는 사용 중인 메이저 라인에 맞는 10월 6일 패치를 먼저 잠금 파일 갱신과 함께 검증하고, H3 v2/Nitro v3 전환은 별도 브랜치에서 Node 20.19+와 스트림 오류 처리를 포함한 회귀 테스트로 다뤄야 한다.

확인된 사실: Nuxt 4.6.0은 10월 5일 릴리스됐고, 서버 유틸리티용 nuxt/server와 Nuxt CLI v4를 포함한다.
확인된 사실: Vite는 10월 6일 v8.3.3, v8.2.4, v8.1.6, v7.3.7, v6.4.4를 같은 날 배포했다. v8.3.3은 HTML 변환 파일명, WASM 인스턴스 관련 파일 제공, 안전 모듈 경로 처리를 고쳤다.
확인된 사실: H3 v2.0.1은 안정 릴리스이며, 10월 7일 v2.0.2가 Node 스트림 오류의 onError 호출과 미들웨어 오류 응답 처리를 보완했다.
해석: 이번 묶음은 ‘새 프레임워크로 교체’보다 Nuxt 서버 추상화와 Vite/H3 런타임 경계를 테스트 가능한 계약으로 만드는 데 의미가 있다.

3일 결론: 프론트엔드 운영은 서버 경계를 먼저 정리해야 한다

이번 72시간의 중심 변화는 Nuxt 4.6이다. 공식 릴리스 노트에 따르면 Nuxt는 nuxt/server라는 서버 전용 import surface를 제공한다. 기본 구현은 여전히 Nitro지만, 핸들러·미들웨어·서버 유틸리티가 h3 또는 nitropack의 타입과 직접 결합하지 않도록 Nuxt가 요청 이벤트·route rules·typed $fetch의 자체 타입 표면을 정의한다.

이는 이미 배포된 변경이다. 다만 ‘어떤 서버 빌더로도 즉시 이전 가능’이라는 뜻으로 확대 해석하면 안 된다. Nuxt 팀은 기본값으로 Nitro가 대부분의 앱에 적합하다고 명시하며, 순수 Vite 서버 빌드를 위한 @nuxt/vite-server는 실험적 구현이라고 구분한다. 실무적으로는 신규 server/api 코드부터 h3/nitropack 직접 import를 줄이고 nuxt/server를 채택하는 방식이 가장 낮은 위험의 적용 순서다.

흐름 1: Nuxt 4.6의 서버 불변성 — `nuxt/server`로 업그레이드 비용을 낮춘다

공개 API와 런타임 구현을 분리

Nuxt 4.6은 defineEventHandler, query/body/cookie/redirect/response status, route rules, runtime config 등 서버 코드에서 자주 쓰는 기능을 nuxt/server로 노출한다. 공식 노트는 이 경계가 Nuxt 5의 Nitro v3·H3 v2 전환에서도 같은 서버 코드를 유지하는 길이라고 설명한다. 따라서 모듈 제작자와 앱 팀은 피어 의존성으로 특정 H3/Nitro 타입을 끌어올리기보다 Nuxt가 소유한 표면을 우선 사용해야 타입 충돌 가능성을 줄일 수 있다.

개발자 시사점: 기존 API route를 일괄 치환하지 말고, 새 route와 수정되는 route부터 import 규칙을 바꾸며 타입 체크·SSR smoke test를 통과시키는 것이 안전하다. 이는 공식 릴리스의 호환성 목표에 근거한 운영 제안이며, 개별 어댑터의 완전한 호환성을 보장한다는 주장은 아니다.

Vue Vapor는 지원되지만 실험 도입으로 한정

Nuxt 4.6 릴리스에는 Vue Vapor interop 지원도 포함된다. 릴리스 노트의 방향은 앱 루트를 한 번에 바꾸는 것이 아니라 선택한 컴포넌트·페이지에서 실험하는 것이다. Vue 3.6은 아직 RC 계열이며, npm 최신 안정 태그는 Vue 3.5.43이다. 따라서 Vapor는 성능 가설이 명확한 독립 화면에서 hydration·에러·개발 도구 회귀를 측정하는 실험으로 분리하고, 기본 렌더링 전략을 바꾸는 릴리스 작업과 묶지 않는 편이 낫다.

흐름 2: Nuxt CLI v4 — 개발 서버의 관측성을 배포 품질에 연결

같은 Nuxt 4.6 릴리스와 함께 포함되는 Nuxt CLI v4는 대화형 터미널 UI, 오류·라우트·네트워크 패널, 재시작/리로드 이유와 느린 시작·빌드 시간의 세부 정보를 제공한다. 또한 .nuxt/ lock file과 실행 중인 dev 서버에 연결하는 nuxt curl, nuxt task가 추가됐다.

공식 수치에는 CLI 설치 크기·의존성 감소와 dev 첫 화면/포트 바인딩 시간 개선이 제시돼 있지만, 이것은 특정 Linux 측정치다. 팀의 CI나 macOS 개발 환경에서 동일한 수치를 약속하지 않는다. 대신 모듈 초기화 시간, config 변경 뒤 재시작 이유, 라우트별 요청 오류를 이번 CLI로 관찰해 기준선을 남기는 것이 재현 가능한 활용법이다.

흐름 3: Vite 유지보수 패치 — 사용 중인 메이저 라인에서 먼저 잠근다

Vite 프로젝트는 10월 6일에 v8.3.3·v8.2.4·v8.1.6·v7.3.7·v6.4.4라는 여러 라인의 릴리스를 받았다. 이 중 v8.3.3 공식 릴리스에는 transformIndexHtml에 query가 포함되지 않은 파일명을 전달하도록 수정한 점, ?vite-wasm-instance에서 파일 제공 설정을 확인하도록 한 점, safe module path에 URL 대신 id를 저장하도록 한 점이 명시돼 있다.

각 유지보수 버전은 같은 기능을 뜻하지 않는다. 패키지 매니저의 자동 업데이트로 서로 다른 메이저를 섞지 말고, 현재 Nuxt 프로젝트가 잠근 Vite 메이저와 호환 범위를 확인한 뒤 해당 라인의 패치만 선택해야 한다. WASM·HTML transform plugin·monorepo symlink·커스텀 dev middleware를 사용하는 앱이라면 특히 dev 서버와 production build를 모두 재현해야 한다.

흐름 4: H3 v2 안정화와 v2.0.2 — Nitro v3 준비는 오류 경로 테스트가 핵심

H3 v2.0.1은 web standard의 Request/Response/URL/Headers 위에서 재작성된 안정 버전이다. Node·Bun·Deno·Workers 등에서 같은 핸들러 모델을 목표로 하며, Node 사용 시 최소 Node 20.19를 요구한다. 이어진 v2.0.2는 Node handler의 스트림 오류에서 onError를 호출하고, onError에서 처리된 응답을 미들웨어가 통과시키도록 고쳤다.

이것은 Nuxt 4.6의 서버 API 분리와 직접 맞물린다. Nuxt 4.6은 당장 기본 Nitro 구현을 유지하면서도, H3/Nitro 메이저 변화가 앱의 import·타입에 연쇄적으로 퍼지는 것을 줄이려 한다. 단, H3 v2나 Nitro v3를 Nuxt 운영 서비스에 강제로 올리라는 릴리스는 아니다. 현재 Nitro v3는 beta 패키지이므로 production 기본값으로 취급하지 말고, 스트리밍 응답·예외·redirect·session·CORS를 포함한 별도 호환성 테스트 대상으로 둔다.

추가 관찰: Unhead 변경은 main 브랜치 작업이며 아직 릴리스가 아니다

Unhead 저장소에는 10월 6일 non-string textContent hash 처리와 numeric template parameter 보존 관련 커밋이 올라왔다. 이는 main 브랜치 커밋으로 확인된 개발 중 작업이며, 배포 가능한 릴리스라고 표현하면 안 된다. SEO/head 태그 계층에 민감한 Nuxt 앱은 이를 업그레이드 근거로 쓰지 말고, 이후 공식 릴리스 노트를 기다리는 편이 맞다.

프론트엔드 개발자 액션 체크리스트

의존성: Nuxt 4 프로젝트에서 npx nuxt upgrade --dedupe 전용 브랜치를 만들고 lockfile diff, Node 버전, peer dependency 경고를 검토한다. Nuxt CLI v4의 지원 Node 범위(22.21+/24.11+/26+)도 CI와 개발 환경에 대조한다.
서버 코드: 새 API route부터 nuxt/server import를 사용하고, 직접 H3/Nitro import가 남은 위치를 목록화한다. handler의 query/body/cookie/redirect와 타입 체크를 smoke test에 넣는다.
Vite: 현재 메이저 라인만 패치한 뒤 vite dev, Nuxt dev, production build, preview를 모두 실행한다. WASM, HTML transform, symlink workspace가 있으면 전용 회귀 시나리오를 추가한다.
H3/Nitro 실험: H3 v2/Nitro v3은 production 기본 업그레이드가 아니라 분리된 호환성 브랜치에서 검증한다. Node stream error, handled error response, streaming/redirect, CORS와 session을 포함한다.
관측성: Nuxt CLI v4의 모듈 setup 시간과 재시작 원인을 캡처해, 다음 성능 개선 전후의 비교 기준으로 남긴다.

짧은 Q&A

Nuxt 3 프로젝트는 이번 주에 무엇을 결정해야 하나?

Nuxt 3은 Nuxt 릴리스 노트상 2026년 7월 31일 지원 종료 상태다. 즉시 대규모 전환이 어렵더라도 Node 기준, 모듈 호환성, API route import를 포함한 Nuxt 4 마이그레이션 범위와 일정은 확정하는 것이 합리적이다.

`@nuxt/vite-server`를 바로 production에 적용해도 되나?

아니다. 공식 발표는 이를 experimental implementation으로 명시한다. 기본 Nitro 경로를 유지하고, 서버 추상화 API와 배포 어댑터의 호환성을 별도 검증한 뒤 제한된 환경에서 평가해야 한다.

Vite 패치는 왜 Nuxt 팀에도 중요한가?

Nuxt의 개발·빌드 경로가 Vite에 의존하기 때문이다. 단, Nuxt가 사용하는 정확한 Vite 버전 범위를 우선하고, Vite의 다른 메이저 릴리스를 임의로 교차 적용해서는 안 된다.

주요 출처

오늘의 결론

이번 3일의 핵심은 Nuxt를 더 쉽게 ‘교체’하는 일이 아니라, Nuxt 서버 코드를 H3/Nitro 구현 세부와 분리해 다음 런타임 전환을 관리 가능한 변화로 만드는 것이다. Nuxt 4.6의 nuxt/server와 CLI 관측성을 신규 코드·테스트 기준에 먼저 흡수하고, Vite/H3 업데이트는 현재 사용 중인 메이저 라인과 오류 경로를 검증하는 작은 배포로 진행하자.

더 깊게 읽기: 실전 가이드

이 리포트는 최근 흐름을 빠르게 파악하기 위한 요약입니다. 실제 프로젝트에 적용할 때는 아래의 기준 글과 함께 확인하면 더 안전합니다.