Vercel에서 돌아가는 Nuxt 앱의 서버리스 호출 횟수를 줄이는 캐싱 설정
makedream1 mai 2026
0
컴퓨터/소프트웨어Related Video
36:54▲ 커뮤니티 세션: Vercel 환경에서의 Nuxt 활용하기
Vercel
Comments (0)
Log in to leave a comment
No posts yet
makedream36:54makedream36:54Vercel
Log in to leave a comment
No posts yet
Nuxt의 Nitro 엔진은 어디서든 잘 돌아가는 것처럼 보이지만, Vercel Edge Runtime에 올라가는 순간 이야기가 달라집니다. 로컬에서 멀쩡하던 sharp나 bcrypt 같은 라이브러리가 배포 후에 즉시 500 에러를 뱉는 이유는 Vercel 엣지가 Node.js 표준 모듈 접근을 차단하기 때문입니다. 저는 배포 버튼을 누르기 전에 반드시 npx vercel build를 실행합니다. 리눅스 기반 환경을 미리 시뮬레이션하지 않으면 새벽 3시에 런타임 에러와 씨름하게 될 확률이 높습니다.
안정적인 운영을 원한다면 nuxt.config.ts에서 프리셋을 vercel-edge 대신 일반 vercel로 명시하는 편이 안전합니다. 모든 API를 엣지로 돌릴 필요는 없습니다. 환경 변수도 process.env를 직접 호출하지 말고 Nitro의 useRuntimeConfig로 표준화하십시오. 이 사소한 습관이 배포 후 발생하는 런타임 에러의 80%를 걷어냅니다.
Vercel 요금 청구서의 주범은 서버리스 함수의 실행 시간과 호출 횟수입니다. Nitro 3에서 제공하는 routeRules는 이 비용을 물리적으로 깎아내는 가장 강력한 도구입니다. stale-while-revalidate(SWR) 전략을 제대로 쓰면 API 요청이 1만 번 들어와도 실제 함수 실행은 단 1회로 끝납니다. 사용자에게는 밀리초 단위의 빠른 응답을 주면서 지갑은 지키는 영리한 방법입니다.
비용을 40% 이상 줄이는 구체적인 설정입니다.
nuxt.config.ts의 routeRules 객체에서 캐싱할 경로를 지정합니다.swr: 3600을 추가해 1시간 동안 백그라운드 갱신 모드를 켭니다.cache 옵션 내에 maxAge와 staleMaxAge를 명시해 CDN이 캐시를 들고 있을 시간을 정의합니다.이렇게 하면 Vercel 대시보드에서 서버리스 함수 호출 횟수가 수직 낙하하는 것을 확인하게 됩니다.
서버가 만든 HTML과 클라이언트의 자바스크립트가 만날 때 발생하는 하이드레이션 오류는 앱을 불안정하게 만듭니다. Nuxt 4는 이를 해결하려고 useAsyncData 호출 시 deep: false를 기본값으로 쓰도록 설계되었습니다. 불필요한 객체 추적을 포기하는 대신 메모리를 아끼고 서버 상태를 클라이언트로 안전하게 넘깁니다.
데이터 불일치를 잡고 페이로드 크기를 줄이는 세 가지 규칙을 적용하십시오.
pick 옵션을 사용해 템플릿 렌더링에 꼭 필요한 키값만 골라냅니다. 이것만으로 페이로드 크기가 최대 50%까지 줄어듭니다.useId()를 써서 서버와 클라이언트의 식별자를 일치시킵니다.<NuxtTime> 컴포넌트로 감싸서 브라우저 로케일 기반으로 처리합니다.프로젝트가 커지면 Vercel 빌드 컨테이너가 제공하는 8,192MB 메모리도 부족할 때가 있습니다. 정확히는 Node.js의 기본 힙 크기가 가용 메모리보다 작게 설정되어 가비지 컬렉션이 빈번해지고 결국 빌드가 멈춥니다.
빌드 속도를 높이고 배포 실패를 막으려면 다음 설정을 바로 적용하십시오.
NODE_OPTIONS="--max-old-space-size=4096"를 추가합니다. 힙 메모리 제한을 푸는 것만으로도 빌드 병목이 사라집니다.npx nuxt analyze를 실행해 무거운 서버 전용 의존성이 클라이언트 번들에 섞여 있지 않은지 확인하고 #server 별칭으로 격리합니다.server/middleware/의 무거운 로직을 특정 경로의 이벤트 핸들러 내부로 옮겨 서버 번들 크기를 줄입니다.이 환경 구성을 마치면 CI/CD 파이프라인 대기 시간이 단축되고 배포 실패율이 현저히 낮아집니다.