Vercel과 Cloudflare 연동 시 캐싱 충돌 해결: Next.js SSR/ISR 환경 최적화 팁

많은 개발자가 Vercel의 뛰어난 개발 경험(DX)과 Cloudflare의 강력한 DNS 및 보안 기능을 동시에 활용하고자 합니다. 하지만 이 두 서비스는 모두 자체적인 CDN(Content Delivery Network)과 엣지(Edge) 네트워크를 보유하고 있다는 공통점이 있습니다. 이로 인해 '이중 캐싱(Double Caching)' 문제가 발생하기 쉽습니다.

Vercel에서 배포된 Next.js 애플리케이션은 기본적으로 Vercel의 엣지 네트워크에 최적화된 캐싱 정책을 따릅니다. 여기에 Cloudflare를 프록시(Proxy)로 앞단에 배치하면, Vercel이 내려준 응답을 Cloudflare가 다시 한번 캐싱하게 됩니다. 이 과정에서 배포 후에도 구버전 화면이 보이거나, ISR(Incremental Static Regeneration)로 갱신된 데이터가 즉시 반영되지 않고 무한 로딩에 걸리는 등의 충돌 현상이 발생합니다. 이러한 구조적 원인을 이해하는 것이 문제 해결의 첫걸음입니다.

가장 근본적인 해결책은 명확한 Cache-Control 헤더를 설정하여 두 CDN이 어떻게 행동해야 할지 지시하는 것입니다. 특히 next.config.js 파일이나 미들웨어에서 헤더를 제어하는 것이 효과적입니다.

SSR(Server-Side Rendering) 페이지의 경우, 브라우저나 CDN이 오래된 데이터를 가지고 있지 않도록 다음과 같은 전략을 고려해야 합니다. s-maxage는 CDN(Vercel, Cloudflare)이 캐시를 유지하는 시간을, max-age는 사용자 브라우저가 캐시를 유지하는 시간을 의미합니다.

• 동적 데이터가 중요한 경우: Cache-Control: public, max-age=0, s-maxage=0, must-revalidate 설정을 통해 항상 최신 상태를 검증하도록 유도합니다.
• 정적 콘텐츠(ISR)의 경우: stale-while-revalidate 지시문을 활용하여, 백그라운드에서 캐시가 갱신되는 동안 사용자는 기존 캐시를 빠르게 볼 수 있도록 설정하여 성능과 최신성 사이의 균형을 맞춥니다.

코드 레벨에서의 설정뿐만 아니라, Cloudflare 대시보드에서도 몇 가지 조정이 필요합니다. 기본적으로 Cloudflare는 HTML 파일까지 적극적으로 캐싱하려고 할 수 있는데, 이는 Next.js의 동적 라우팅과 충돌을 일으킬 수 있습니다.

실무적으로 가장 권장되는 방법은 '개발 모드(Development Mode)' 활용이 아닌, '캐시 규칙(Cache Rules)'을 생성하는 것입니다. 특정 경로(예: /_next/static/*)에 대해서는 캐싱을 허용하되, HTML 문서나 API 라우트(/api/*)에 대해서는 'Bypass Cache'를 설정하면 충돌을 최소화할 수 있습니다. 또한, 'Auto Minify' 기능이 Next.js의 자체 최적화와 충돌하여 하이드레이션(Hydration) 오류를 일으키는 경우가 있으므로, JS/CSS 압축 옵션을 해제하고 테스트해보는 것이 좋습니다.

개발자로서 다양한 프로젝트를 진행하며 느낀 점은, 이러한 캐싱 문제는 단순히 설정값 복사/붙여넣기로는 해결되지 않는 경우가 많다는 것입니다. 특히 AI 관련 서비스를 개발할 때 실시간 데이터 반영이 늦어지면 사용자 경험에 치명적일 수 있습니다.

문제가 발생했을 때 가장 먼저 해야 할 일은 크롬 개발자 도구의 'Network' 탭을 확인하는 것입니다. 응답 헤더(Response Headers)에서 cf-cache-status(Cloudflare)와 x-vercel-cache(Vercel) 값이 각각 HIT인지 MISS인지 확인해보세요. 두 값이 모두 HIT라면 이중 캐싱이 강력하게 걸려있는 상태입니다. AI 도구를 활용하여 로그를 분석하거나 복잡한 헤더 규칙 시나리오를 시뮬레이션해보는 것도 시간을 단축하는 좋은 방법입니다. 결국, 인프라의 특성을 이해하고 우리 서비스에 맞는 '적당한' 캐싱 전략을 찾는 것이 핵심입니다.