$ cd /blog
오류 해결

Vercel 배포했는데 옛날 페이지가 보인다면? Cloudflare 캐시의 함정

Vercel 배포가 성공했는데 일부 페이지만 예전 버전이 보이는 문제의 원인과 해결법. Cloudflare를 앞단에 둔 사이트의 s-maxage 캐시 동작을 실제 사례로 정리했습니다.


안녕하세요. Jay입니다!

Vercel에 배포가 분명히 성공했는데, 사이트를 열어보면 예전 페이지가 그대로 보인 적 있으신가요? 더 이상하게는 어떤 페이지는 새 버전인데 어떤 페이지만 옛날 버전인 경우도 있습니다. 저도 최근 운영 중인 사이트의 개인정보처리방침을 급하게 고치고 배포했는데, 40여 개 페이지를 전수 확인해보니 딱 1개 페이지만 계속 옛 버전이 나와서 한참을 헤맸어요. 범인은 코드가 아니라 Cloudflare 캐시였습니다.

🔍 증상: 배포는 성공, 그런데 일부 페이지만 과거에 머물러 있다

이 문제의 전형적인 모습은 이렇습니다.

  • Vercel 대시보드에서는 배포가 정상 완료됨
  • 브라우저 강력 새로고침을 해도 옛 페이지가 보임
  • 페이지마다, 지역마다 다르게 보임 — 어떤 URL은 새 버전, 어떤 URL은 옛 버전
  • 시간이 지나면 일부는 저절로 새 버전이 됨

"일부만, 무작위처럼" 보인다는 게 핵심 단서입니다. 코드 문제라면 모든 요청이 같은 결과여야 하니까요. 이건 URL별·데이터센터(POP)별로 따로 저장되는 CDN 캐시의 특징입니다.

🧩 원인: Vercel은 배포 때 자기 캐시만 비운다

Next.js에서 이런 헤더를 설정했다면:

Cache-Control: public, s-maxage=604800, stale-while-revalidate=2592000

s-maxage=604800은 "CDN아, 이 페이지를 7일 동안 캐시해도 돼"라는 뜻입니다. 여기서 함정이 갈립니다.

  • Vercel의 자체 CDN: 새 배포가 나가면 엣지 캐시를 자동으로 비웁니다(purge). 그래서 Vercel만 쓸 때는 긴 s-maxage를 줘도 배포 즉시 반영돼요.
  • 앞단의 Cloudflare: Vercel이 배포했다는 사실을 전혀 모릅니다. s-maxage 그대로 최대 7일간 저장해둔 HTML을 계속 내보냅니다.

사용자 → Cloudflare → Vercel 구조에서는, Vercel이 아무리 새 배포를 해도 Cloudflare가 들고 있는 옛 HTML이 먼저 응답되는 겁니다. Cloudflare는 데이터센터마다 캐시가 따로라서 "서울에선 새 버전, 다른 지역에선 옛 버전" 같은 미스터리도 여기서 나옵니다.

🛠 해결법 3가지

1) 당장 반영이 급할 때 — Cloudflare 캐시 퍼지 Cloudflare 대시보드 → Caching → Configuration → Purge Everything(또는 특정 URL만 Purge). 1분 안에 전 세계 캐시가 비워집니다. 급한 불은 이걸로 끕니다.

2) 반복된다면 — 배포 후 퍼지 자동화 배포 파이프라인 끝에 Cloudflare API 호출 한 줄을 붙이면 사람이 잊어버릴 일이 없습니다.

curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer {API_TOKEN}" \
  -d '{"purge_everything":true}'

GitHub Actions라면 배포 완료 스텝 뒤에 넣어주면 끝이에요.

3) 구조를 다시 볼 때 — s-maxage 전략 점검 애초에 s-maxage를 길게 준 이유가 있을 겁니다(저는 Vercel 무료 플랜의 사용량 한도를 아끼려는 목적이었어요). 그 목적이 유효하다면 긴 캐시 + 퍼지 자동화 조합이 정답이고, 아니라면 s-maxage를 짧게(예: 60초) 줄이는 게 가장 단순한 해법입니다. 콘텐츠가 자주 바뀌는 페이지만 헤더를 분리하는 것도 방법이고요.

💡 Jay의 한 가지 팁: 배포 검증은 "사용자가 보는 URL"로

이번에 배운 가장 큰 교훈입니다. 배포 확인을 Vercel 프리뷰 URL이나 대시보드로만 하면 이 문제를 절대 못 잡습니다. 실제 도메인을 curl로 확인해보세요.

curl -sI https://내도메인.com/페이지 | grep -i "cache-control"

응답 헤더에 s-maxage가 길게 잡혀 있고 Cloudflare를 쓰고 있다면, "배포 = 즉시 반영"이라는 가정은 버려야 합니다. 저는 이제 중요한 페이지를 고치면 배포 → 퍼지 → 실제 URL 확인 3단계를 세트로 묶어서 처리하고 있어요.

결론

  • Vercel은 배포 시 자기 CDN만 비운다 — 앞단 Cloudflare는 s-maxage만큼 옛 페이지를 계속 서빙
  • 일부 페이지만·지역마다 다르게 옛 버전이 보이면 코드가 아니라 CDN 캐시부터 의심
  • 급하면 Cloudflare Purge Everything, 반복되면 배포 파이프라인에 퍼지 자동화, 근본적으로는 s-maxage 전략 재점검

같은 문제로 시간을 태우고 계셨다면 도움이 되었길 바랍니다. 다음에도 유익한 포스팅으로 찾아오겠습니다. 감사합니다!

#Vercel#Cloudflare#CDN 캐시#Next.js

$ ls related/

더 많은 IT·AI 활용법이 궁금하다면?

매주 새로운 실전 가이드가 업데이트됩니다.

전체 글 보기