Nuxt 3일 운영: H3 캐시 수정과 Vite·Vitest 전환점 | Three-Day Nuxt Operations: H3 Cache Fixes and Vite–Vitest Checkpoints

Nuxt 3일 운영: H3 캐시 수정과 Vite·Vitest 전환점 | Three-Day Nuxt Operations: H3 Cache Fixes and Vite–Vitest Checkpoints

요약: 2026년 10월 18일~21일(KST) 최근 72시간의 Nuxt 프론트엔드 생태계는 런타임 캐시의 헤더 경계, 서버 라우팅 호환성, 새 프로젝트의 TypeScript 선택, 변경분 중심 테스트 실행이라는 네 축에서 움직였다. 이번 3일 리포트의 핵심은 “새 기능을 서둘러 채택하기”보다 Nuxt/Nitro 서비스의 캐시·런타임·생성 템플릿·CI 기준선을 분리해 점검하는 것이다.

3일 결론

핵심 답변: 운영 중인 Nuxt 앱은 H3 2.0.6~2.0.7의 캐시 관련 수정부터 검토하고, Nitro의 최신 main 변경은 배포 대상이 아니라 사전 호환성 신호로 취급해야 한다. 새 Vite 기반 프로젝트는 생성 시점의 TypeScript 버전과 템플릿 출력물을 고정·검증하고, Vitest 5.1.0-beta.1의 선택 실행 기능은 별도 실험 브랜치에서 CI 시간을 줄이는 용도로 평가하는 편이 안전하다.

  • 즉시 확인: 캐시되는 API/SSR 응답에서 미들웨어가 추가한 헤더가 캐시 본문과 섞이지 않는지 확인한다.
  • 업그레이드 판단: H3 2.0.7은 정식 릴리즈지만, Nitro와 Nuxt의 최근 커밋은 아직 정식 배포본이 아니다.
  • 개발환경 판단: create-vite의 TypeScript 선택이 이틀 사이 조정됐으므로, 신규 프로젝트 생성 결과를 CI 기준으로 남긴다.

1. H3 2.0.6~2.0.7: 캐시와 미들웨어 헤더의 경계를 다시 세움

확인된 사실

H3 v2.0.6과 v2.0.7은 미들웨어 단계에서 설정된 헤더가 handler-level 또는 route-rule 캐시 엔트리에 남지 않도록 수정했다. v2.0.6에는 이름 있는 catch-all 규칙(/**:name)의 대상 보정도 포함됐고, v2.0.7은 동일한 캐시-헤더 격리 문제를 handler 캐시까지 확장해 수정했다. npm 레지스트리 기준 최신 H3는 2.0.7이다.

왜 중요한가

Nuxt/Nitro의 API 라우트에서 인증, 지역화, 실험군, 보안 정책 같은 응답 헤더를 미들웨어가 추가한다면 캐시 경계가 잘못되었을 때 다른 요청의 메타데이터가 재사용될 위험이 있다. 이는 “캐시가 동작한다”는 기능 문제보다, 어떤 레이어의 헤더가 캐시 키·캐시 값에 포함되는가라는 운영 설계 문제다. 개인화 응답을 캐시하지 않더라도 공통 캐시 엔드포인트에 관측·정책 헤더가 추가되는 환경은 점검 대상이다.

개발자 액션

  • h3 직접 의존 또는 Nitro가 끌어오는 버전을 lockfile에서 확인하고, 독립 H3 서비스를 2.0.7으로 올릴 수 있는지 검토한다.
  • 캐시된 엔드포인트에 서로 다른 사용자/지역/권한 헤더를 넣는 회귀 테스트를 추가한다.
  • catch-all route rule을 쓰는 서비스는 실제 매칭 URL과 prerender/edge 환경을 함께 확인한다.

2. Nitro의 최근 main: 캐시 순서와 Node.js 기준선은 ‘출시 전’ 신호

확인된 사실

Nitro 저장소의 10월 20일 main 커밋은 미들웨어를 cache route rule보다 먼저 실행하고, 미들웨어 헤더가 캐시 엔트리에 들어가지 않도록 변경했다. 같은 날의 다른 main 커밋은 Node.js 최소 버전을 22.12.0 이상으로 올렸다. 두 항목은 이 보고서 시점에 정식 릴리즈 노트가 아닌 main 브랜치 작업이므로, 배포 가능한 릴리즈로 간주하면 안 된다.

시사점

H3 정식 패치와 Nitro main의 방향이 같은 문제를 가리킨다는 점은, Nuxt 서버 계층에서 캐시와 미들웨어의 결합을 명시적으로 테스트해야 한다는 신호다. Node.js 기준 상향은 단순 엔진 필드 변경이 아니라 CI 이미지, 서버리스 런타임, 로컬 개발 컨테이너를 함께 점검해야 하는 호환성 변화다. 따라서 오늘의 결론은 runtime 이미지를 즉시 바꾸는 것이 아니라, 사용 중인 Node 버전과 배포 플랫폼의 지원 범위를 인벤토리로 만드는 것이다.

3. create-vite 9.3.0~9.3.1: 템플릿의 TypeScript 정책이 빠르게 조정됨

확인된 사실

create-vite 9.3.0은 가능한 곳에서 TypeScript 7을 사용하고 생성 전 버전을 출력하는 기능을 추가했으며 TanStack Router/Start용 router-only 선택지도 보완했다. 바로 다음 정식 릴리즈인 9.3.1은 TypeScript 6을 우선 사용하도록 조정하고 TanStack 프로젝트에서 Vite를 사용하도록 수정했다.

왜 중요한가

이는 Vite 런타임의 메이저 변경이 아니라 신규 프로젝트의 초기 조건이 바뀌는 변화다. Nuxt 팀이 별도 Vite 패키지, 컴포넌트 플레이그라운드, 디자인 시스템 또는 마이크로 프론트엔드 템플릿을 생성할 때, 같은 명령이라도 생성물의 TypeScript 버전과 의존성 그래프가 달라질 수 있다. 따라서 신규 스캐폴딩을 “개발자 로컬 선택”이 아니라 재현 가능한 팀 자산으로 관리해야 한다.

개발자 액션

  • 새 템플릿을 만들 때 CLI 버전, Node.js 버전, 생성된 package.json과 lockfile을 함께 커밋한다.
  • TypeScript 7을 시험할 경우 Nuxt 앱 본체와 분리된 패키지에서 vue-tsc, ESLint, 테스트 타입 검사를 먼저 돌린다.
  • CI에는 “새 프로젝트 생성 → install → typecheck → test” 스모크 잡을 둬 템플릿 드리프트를 조기에 잡는다.

4. Vitest 5.1.0-beta.1과 Nuxt main: 변경분 중심 개발 루프의 실험 구간

확인된 사실

Vitest 5.1.0-beta.1은 실패한 테스트만 재실행하는 --last-failed, 이전 실행 이후 변경분을 겨냥하는 --since-last-run, 브라우저 테스트 import map 모킹 등을 포함한다. 다만 npm의 stable 태그는 여전히 5.0.5이며, 5.1.0-beta.1은 프리릴리즈다. 한편 Nuxt의 main 커밋에는 nitroLegacy 호환 모드에서 중첩 server/utils 스캔을 추가하고 경고하는 작업이 들어왔다. 이 역시 아직 정식 Nuxt 릴리즈가 아니다.

시사점

프론트엔드 개발 루프는 전체 테스트를 매번 빠르게 돌리는 문제에서, 변경분·실패 이력·서버 유틸 자동 탐색이 일관되게 재현되는 문제로 이동하고 있다. 그러나 프리릴리즈와 main 변경을 운영 CI의 기본값으로 바꾸는 것은 별개다. 확인된 기능은 실험 환경에서 측정하고, 안정 채널의 업그레이드는 정식 릴리즈를 기다리는 구분이 필요하다.

Nuxt 프론트엔드 운영 체크리스트

  • 캐시: SSR/API route에 미들웨어 헤더를 붙인 뒤, 서로 다른 요청이 동일 캐시 응답을 받지 않는지 테스트했는가?
  • 런타임: 배포 대상의 Node.js 버전과 Nitro의 향후 22.12.0 기준을 비교해 업그레이드 계획을 만들었는가?
  • 생성기: create-vite로 만든 템플릿의 CLI·TypeScript·lockfile을 고정했는가?
  • 테스트: Vitest beta의 선택 실행 기능을 안정 CI와 분리한 실험 잡에서만 평가하는가?
  • Nuxt 호환성: server/utils 자동 탐색 또는 legacy 런타임 의존이 있다면, 정식 Nuxt 릴리즈 전 nightly 검증만 수행하는가?

자주 묻는 질문(FAQ)

지금 바로 Nuxt 또는 Nitro nightly로 올려야 하나?

아니다. 이번 창에서 Nuxt/Nitro 관련 핵심 변화 중 일부는 main 브랜치 커밋이다. 운영 반영은 정식 릴리즈와 릴리즈 노트를 확인한 뒤 진행하고, 지금은 캐시 회귀 테스트와 Node.js 호환성 확인에 쓰는 것이 적절하다.

H3 2.0.7은 누가 우선 검토해야 하나?

미들웨어가 응답 헤더를 만들고 route/handler 캐시를 함께 쓰는 H3·Nitro 서비스가 우선 대상이다. 특히 인증, 변형, 지역화, 보안 헤더가 캐시 응답과 결합되는 API는 재현 테스트를 먼저 작성해야 한다.

create-vite 변화가 기존 Nuxt 앱에 영향을 주나?

기존 Nuxt 런타임을 직접 바꾸지는 않는다. 다만 새 패키지·플레이그라운드·독립 Vite 앱을 만드는 팀이라면 생성 시점의 TypeScript 정책과 의존성 선택이 달라질 수 있으므로 템플릿 검증에 영향을 준다.

주요 출처

더 깊게 읽기: 실전 가이드

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

댓글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다