Nuxt 서버·쿠키·컴포넌트 안정화 흐름 | Three-Day Nuxt Runtime Stability Watch

요약: 최근 72시간 Nuxt/Vue/Vite/Nitro 프론트엔드 생태계에서 새 안정 릴리즈는 확인되지 않았지만, Nuxt main에는 쿠키 쓰기 억제·route rules 런타임 안정성·client-only 컴포넌트 서버 빌드 경계를 다루는 수정이 연속 반영됐다. Nuxt 개발팀은 지금 당장 버전을 올리기보다 SSR/islands·useCookie·Nitro alias를 포함한 회귀 테스트를 먼저 고정하고, 직전 안정 릴리즈의 업그레이드 계획을 분리해 검증하는 편이 안전하다.

3일 결론

확인된 사실: 8월 7일~10일 KST 관찰 구간의 Nuxt 저장소는 main에서 readonly 쿠키의 클라이언트 쓰기, route matcher의 temporal dead zone(TDZ), bare module specifier를 향한 Nitro alias, client-only 컴포넌트의 서버 빌드 처리를 수정했다. 이는 미출시 개발 브랜치 작업이며 배포 가능한 새 Nuxt 릴리즈라는 뜻은 아니다.

실무 해석: 이번 흐름의 공통점은 UI 기능 추가가 아니라 SSR과 클라이언트 경계, prerender와 route rules, 타입/모듈 해석의 안정성이다. Nuxt 4 전환 또는 islands를 쓰는 팀은 “업데이트 대기”보다 이 경계를 재현하는 테스트를 추가할 때 비용이 낮다. 72시간 안에는 새 Vue·Vite·Nitro 안정 릴리즈가 없었으므로, 직전 공식 버전의 변경을 기준선으로 삼고 main 커밋은 관찰 대상으로만 취급해야 한다.

관찰 범위와 신뢰도

이 리포트는 2026년 8월 7일~10일 KST의 GitHub Releases, 커밋 API, npm 레지스트리를 확인했다. npm 레지스트리에는 이 기간 Nuxt, Vue, Vite, Nitro, Unhead, Nuxt ESLint의 새 배포 버전이 나타나지 않았다. 따라서 아래의 1~4번은 정확한 커밋 URL을 근거로 한 main 개발 동향, 5~7번은 최근에 공개된 안정 기준선이다.

미출시/main: Nuxt readonly cookie, route matcher/TDZ, bare-module alias, client-only server stubbing.
최근 안정 기준선: Nuxt 4.5.2·3.21.11(8월 5일), Vite 8.2.1(8월 6일), Vue 3.5.41(8월 5일), Nuxt ESLint 1.17.0(8월 6일).
주의: 기준선 버전도 엄밀히 72시간 창 바로 밖에 있으므로 ‘오늘의 릴리즈’로 표현하지 않는다.

핵심 흐름 1: `useCookie`의 읽기 전용 계약을 클라이언트까지 고정

사실 — readonly 기본값이 브라우저 쿠키를 쓰지 않도록 main에서 수정

Nuxt main의 #36014 커밋은 useCookie(..., { readonly: true, default: ... })가 기본값을 갖더라도 클라이언트에서 초기 쿠키를 쓰지 않도록 조건을 보강하고, 서버·클라이언트 양쪽 테스트를 추가했다. 바로 앞의 #35997은 readonly일 때 cookie watcher 자체를 건너뛰는 방향을 담고 있다.

시사점: consent, 실험 플래그, 서버가 소유한 세션 힌트처럼 ‘읽기만’ 의도한 값은 hydration 직후 의도치 않은 Set-Cookie나 브라우저 변경을 만들지 않아야 한다. 다만 이는 아직 main이므로 현행 프로젝트에 cherry-pick할 근거가 아니다. 대신 readonly + default 케이스를 브라우저 E2E와 SSR 응답 헤더 검사에 넣어, 현재 의존성에서도 계약을 확인하자.

핵심 흐름 2: route rules·Nitro alias의 빌드/런타임 경계 보강

사실 — 순환 import의 TDZ와 bare module alias 해석을 다루는 미출시 수정

#36012는 생성된 route rules matcher를 함수로 hoist해 순환 import가 default export의 TDZ를 건드리지 않게 한다. 별도 #36011은 Nitro alias가 defu 같은 bare module specifier를 가리킬 때 TypeScript path가 node_modules의 실제 위치로 해석되도록 테스트와 처리를 추가했다.

시사점: routeRules, prerender, case-sensitive 라우팅, 모듈이 넣는 Nitro alias를 함께 쓰는 앱은 dev에서는 지나가도 CI/production bundle에서 드러나는 경계가 있다. 릴리즈 노트를 기다리는 동안에도 프로덕션과 동일한 preset에서 build + prerender를 돌리고, alias를 직접 파일 경로와 패키지명 두 경우로 시험하는 것이 합리적이다.

핵심 흐름 3: client-only/islands의 서버 빌드 회귀를 테스트로 봉합

#36019는 client-only 컴포넌트를 서버 빌드에서 stub 처리하고, 테스트 컴포넌트 매핑을 보강한다. 커밋에는 Webpack dev에서 실패로 표시되던 client-only 및 islands 테스트를 정상 테스트로 바꾸는 변경도 포함된다. 이는 ‘모든 앱의 SSR 오류가 해결됐다’는 발표가 아니라, upstream이 server/client component 경계의 재현 케이스를 구체화하고 있다는 신호다.

시사점: .client.vue, <ClientOnly>, islands, lazy hydration을 섞는 프로젝트는 서버 HTML에 fallback이 나오는지, 클라이언트 hydration 뒤 interactive 상태가 되는지, 그리고 production build에서만 깨지지 않는지를 별도 assertion으로 유지해야 한다.

핵심 흐름 4: 직전 안정 기준선에서 확인할 업그레이드 항목

Nuxt 4.5.2와 Nuxt 3.21.11

Nuxt 4.5.2는 변경되지 않은 생성 파일 재작성 생략, lazy import로 parsing 개선, app/component scan 재사용 등 성능 변경과 islands·prerender·route meta 관련 수정들을 공개했다. 같은 날의 Nuxt 3.21.11 릴리즈 노트는 Nuxt v3가 EOL임을 명시한다. 그러므로 v3 팀은 ‘패치만 유지’가 아니라 v4 전환 범위와 지원 책임을 계획에 반영해야 한다.

Vite 8.2.1, Vue 3.5.41, Nuxt ESLint 1.17.0

Vite 8.2.1은 sharedPlugins: true일 때 client chunk import map, bundled-dev 스크립트 순서, CSS minify 재방문, port 0 서버 처리 등의 수정을 담았다. Vue 3.5.41은 SSR async setup 상태 복원, hydration의 hidden state 정규화, compiler SFC cache invalidation 뒤 template AST 처리 등 SSR/hydration 관련 수정이 포함된 안정 버전이다. Nuxt ESLint 1.17.0은 template root의 여분 comment와 spread operator 관련 버그를 수정했다.

실무 해석: 이들은 72시간 경계 밖의 최근 기준선이다. 특히 빌드 파이프라인 또는 SSR이 민감한 서비스는 lockfile을 갱신하기 전에 node/runtime, Nuxt module, Vite plugin, preview 배포를 묶어 canary 검증해야 한다. Vite/Vue의 변경이 Nuxt 앱에 자동으로 적용된다고 가정하지 말고 Nuxt가 실제로 해석한 의존성 트리를 확인한다.

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

쿠키: readonly: true + default 조합에서 SSR 응답의 Set-Cookie와 브라우저 document.cookie가 바뀌지 않는지 테스트한다.
SSR/islands: client-only 컴포넌트의 fallback HTML, hydration 후 상호작용, production build를 각각 검증한다.
Nitro: routeRules + prerender + case sensitivity와 bare package alias를 가진 모듈을 production preset에서 build한다.
업그레이드: Nuxt 4.5.2/Vite 8.2.1/Vue 3.5.41을 별도 브랜치에서 lockfile 포함으로 올리고 build·preview·E2E를 비교한다.
지원 정책: Nuxt 3 EOL 사용 여부를 inventory로 만들고, v4 전환 우선순위를 보안·SSR 핵심 경로부터 정한다.

짧은 Q&A

Q. 지금 Nuxt main의 커밋을 배포해야 하나?

A. 아니다. 이번 72시간의 핵심 수정은 main 개발 브랜치에 있으며 정식 릴리즈가 아니다. 정확한 재현 테스트를 먼저 추가하고, 후속 release note에 해당 수정이 포함됐는지 확인한 뒤 업그레이드한다.

Q. 이번에 가장 먼저 볼 곳은 어디인가?

A. SSR/hydration, useCookie의 readonly 값, routeRules/prerender, 모듈 alias다. 모두 서버와 클라이언트·빌드와 런타임의 경계에서만 드러나기 쉬운 영역이다.

Q. Nuxt 3을 계속 써도 되는가?

A. 공식 3.21.11 노트는 v3 EOL을 명시한다. 즉시 마이그레이션이 불가능하더라도, 새 기능 투입과 운영 위험을 분리하고 v4 전환 계획·검증 환경을 마련하는 것이 현실적인 다음 단계다.

주요 출처

더 깊게 읽기: 실전 가이드

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