[번역] Next.js의 전체 페이지 캐싱: 신선도를 잃지 않고 SSR 페이지를 캐시하는 방법

Sonny·2025년 9월 7일

Cache Korean FE Article SSR caching frontend next.js

Article

목록 보기

39/39

원문: https://blog.melvinprince.io/full-page-caching-in-next-js-how-to-cache-ssr-pages-without-losing-freshness-b68699905314?sk=0cf579f3d465bc5507f01780c2cbd565

소개

지난 몇 번의 게시물을 통해 Next.js의 기본 캐싱 이해부터 ISR로 동적 콘텐츠를 효율적으로 처리하는 방법, 그리고 가장 최근에는 Vercel의 글로벌 인프라를 활용한 엣지 캐싱 탐구까지 캐싱 기술의 단계를 차근차근 올라왔습니다. 지금까지 우리는 Next.js 정적 및 동적 요구 사항 모두에 대한 콘텐츠 전송을 처리하는 방법에 대한 견고한 기반을 구축했습니다.

하지만 아직 우리가 다루지 않은 중요한 부분이 하나 있습니다. SSR(서버 사이드 렌더링) 페이지에 대한 전체 페이지 캐싱입니다.

정적 페이지와 달리 SSR 콘텐츠는 모든 요청에 대해 온디맨드로 렌더링되므로 신선도를 유지할 수 있지만 성능이라는 트레이드오프가 따릅니다. 각 요청은 백엔드에 접근하여 데이터를 가져오고, 서버 로직을 실행한 다음에야 응답을 보냅니다. 트래픽이 적은 페이지의 경우 이 방법이 괜찮을 수 있습니다. 하지만 SSR 경로가 분당 수백 또는 수천 개의 요청을 받기 시작하면 해당 렌더링 파이프라인에 빠르게 병목 현상이 발생할 수 있습니다.

그래서 진짜 도전은 다음과 같습니다.

SSR을 통해 생성된 전체 HTML 페이지를 SSR의 동적 신선도를 잃지 않고 캐시하려면 어떻게 해야 할까요?

이것이 바로 이 게시물에서 자세히 알아볼 내용입니다.

다음을 배우게 됩니다.

전체 페이지 캐싱이 의미가 있는 경우와 그렇지 않은 경우.
Cache-Control 헤더 또는 Redis와 같은 도구를 사용하여 안전하게 구현하는 방법.
성능 저하 없이 캐시 신선도를 지원하는 방법.
프로덕션에서 전체 페이지 캐싱 설정을 디버깅하고 모니터링하는 방법.

이는 제품 페이지, 블로그 세부 정보 보기 또는 마케팅 변형이 있는 랜딩 페이지와 같이 서버 렌더링 콘텐츠에 의존하는 SEO 친화적이고 트래픽이 많은 Next.js 앱을 구축하는 모든 사람에게 중요한 주제입니다.

성능을 한 차원 더 끌어올려 봅시다.

Next.js SSR의 본질

Next.js의 서버 사이드 렌더링(SSR)은 특히 Next.js 13+에 App Router가 도입되고 15+에 개선되면서 지난 몇 가지 버전에 걸쳐 크게 발전했습니다. 하지만 캐싱에 대해 이야기하기 전에 오늘날 Next.js 맥락에서 SSR이 무엇을 의미하는지 명확히 해 보겠습니다.

SSR이 실제로 하는 일

SSR을 사용하면 모든 요청에 따라 페이지가 서버에 렌더링됩니다. 이는 다음을 의미합니다.

요청당 동적 데이터를 가져옵니다.
HTML은 런타임에 생성됩니다.
결과는 첫 번째 의미 있는 페인트(FMP)를 위해 클라이언트 사이드 하이드레이션을 기다릴 필요 없이 즉시 브라우저로 전송됩니다.

따라서 SSR은 다음과 같은 경우에 이상적입니다.

데이터가 자주 변경되는 페이지
개인화된 콘텐츠
인증된 경로
최신 상태를 반영해야 하는 SEO가 중요한 페이지

Next.js 15+(App Router)에서 작동하는 방식

app/ 디렉토리 내에서 page.tsx를 사용하고 generateStaticParams() 또는 getStaticProps()를 선택하지 않은 경우, Next.js는 기본적으로 이를 SSR 페이지로 취급합니다. 그러나 App Router에는 다음과 같은 뉘앙스가 있습니다.

SSR 페이지는 여전히 캐시될 수 있지만 Next.js 또는 CDN에 처리 방법을 명시적으로 지시하지 않는 한 캐시할 수 없습니다.
'force-static'과 같은 export const dynamic = 'force-dynamic' 지시문을 사용하여 캐싱 동작을 미세 조정할 수 있습니다.
기본적으로 App Router는 스마트 휴리스틱을 사용하지만 전체 페이지 캐싱의 경우 정밀한 제어가 필요한 경우가 많습니다.

성능이 저하되기 시작하는 곳

SSR의 가장 큰 장점인 '항상 신선한 콘텐츠'는 동시에 약점이 되기도 합니다.

모든 요청에는 새로운 렌더링이 필요합니다.
모든 렌더링에는 DB 쿼리, API 호출 및 로직이 포함될 수 있습니다.
이로 인해 특히 부하가 걸린 상태에서 응답 지연과 인프라 비용 증가로 이어집니다.

바로 이 지점에서 전체 페이지 캐싱이 작동합니다. 페이지를 한 번 생성하고, HTML 출력을 저장한 다음 재검증할 때가 될 때까지 후속 요청이 있을 때, 캐시에서 제공합니다.

다음 섹션에서는 이러한 종류의 캐싱이 올바른 조치인 경우와 어떤 종류의 페이지가 가장 큰 이점을 얻을 수 있는지 살펴보겠습니다.

전체 페이지 캐싱이 의미가 있는 경우

솔직히 말해서 모든 SSR 페이지를 캐시해야 하는 것은 아닙니다. 일부 페이지는 관리자 대시보드나 금융 시세와 같이 매번 새로운 데이터를 제공하는 데 적합한 페이지도 있습니다. 그러나 많은 페이지가 자주 변경되지 않으며 요청이 있을 때마다 여전히 재생 비용이 발생합니다.

전체 페이지 캐싱은 동적 HTML을 제공하면서 백엔드를 불필요하게 호출할 필요성을 줄여주는 스마트한 최적화가 가능합니다.

그렇다면 전체 페이지 캐싱은 언제 의미가 있을까요?

1. 콘텐츠는 자주 변경되지 않지만 동적으로 렌더링해야 합니다

제품 목록, 마케팅 페이지, 블로그 상세 페이지 등 몇 분 또는 몇 시간마다 업데이트되는 데이터를 가져오는 페이지의 경우 매번 렌더링할 필요가 없습니다. 대신 짧은 기간(예: 60초) 동안 캐시하고 캐시된 응답을 여러 사용자에게 제공하세요. 이렇게 하면 백엔드의 부담을 줄이면서 콘텐츠를 합리적으로 최신 상태로 유지할 수 있습니다.

2. 대량의 익명 트래픽

가격 페이지, 지역 랜딩 페이지 등 공개적으로 접근할 수 있는 SSR 페이지는 모든 사용자에 대해 개인화할 필요가 없는 경우가 많습니다. 트래픽의 상당 부분이 로그인하지 않은 경우 하나의 버전을 안전하게 캐시하여 여러 요청에서 재사용할 수 있습니다.

3. 무거운 백엔드 로직이 많은 페이지

페이지가 여러 API 또는 복잡한 데이터베이스 쿼리 체인을 사용하나요? 데이터가 너무 자주 변경되지 않는다면 전체 페이지 캐싱을 통해 TTFB(첫 번째 바이트 도달 시간)를 크게 개선할 수 있습니다. 이는 제품 출시나 바이럴 콘텐츠 등 트래픽이 급증하는 페이지에 특히 중요합니다.

4. 다중 지역 또는 글로벌 사이트

사용자가 전 세계에 흩어져 있고 서버가 중앙 집중식(예: 하나의 AWS 리전에서 호스팅)인 경우 엣지 로케이션에서 캐싱하면 성능이 크게 향상될 수 있습니다. 사용자에게 더 가까운 곳에서 제공되는 캐시된 HTML 응답 = 더 빠른 렌더링 시간 + 더 행복한 사용자.

전체 페이지를 캐시하지 않는 경우

이에 대해서는 이후 섹션에서 자세히 설명하겠습니다.

사용자 ID, 세션 데이터 또는 변동성이 큰 콘텐츠(주가 또는 실시간 분석 등)를 기반으로 페이지가 변경되는 경우 전체 페이지 캐싱으로 인해 오래되거나 부정확한 동작이 발생할 수 있습니다.

Next.js에서 SSR 페이지를 캐시하는 전략

이제 전체 페이지 캐싱이 의미가 있는 시기를 확인했으므로 Next.js 15+ 앱에서 실제로 구현하는 방법에 대해 이야기해 보겠습니다.

여기에는 모든 경우에 적용되는 만능 솔루션은 없습니다 — 올바른 전략은 호스팅 설정, 콘텐츠 변경 빈도, 캐시 수명 주기에 대한 제어의 정도에 따라 다릅니다.

주요 전략을 분석해 보겠습니다.

전략 1: Cache-Control 헤더를 통한 CDN 수준 캐싱

Vercel 또는 CDN 지원 환경 에 배포하는 경우 HTTP 헤더를 사용하여 CDN에 전체 SSR 응답을 캐시하도록 지시할 수 있습니다.

작동 방식

평소와 같이 SSR 페이지를 렌더링합니다.
응답에 Cache-Control 헤더 설정
CDN은 전체 HTML을 캐시하고 후속 요청에 제공합니다.

헤더 예시

ts
CopyEdit
Cache-Control: public, s-maxage=60, stale-while-revalidate=120

public: 응답이 중간 캐시에 의해 캐시될 수 있음을 나타냅니다.
s-maxage=60: CDN은 60초 동안 캐시된 버전을 제공합니다.
stale-while-revalidate=120: 캐시가 오래된 경우에도 백그라운드 새로 고침이 새 캐시를 가져오는 동안 캐시를 제공합니다.

이를 통해 신선도를 조절하면서 엄청나게 빠른 응답을 얻을 수 있습니다.

전략 2: Redis(또는 유사한 스토어)를 사용한 수동 HTML 캐싱

사용자 지정 서버(예: Node.js 또는 Express 사용)를 실행하거나 CDN을 인식하지 않는 공급자에서 호스팅하는 경우 렌더링된 HTML 출력을 수동으로 캐시할 수 있습니다.

흐름

요청 URL을 캐시 키로 사용합니다.
첫 번째 요청에서 SSR 페이지를 렌더링하고 출력을 Redis에 저장합니다.
후속 요청에서 가능한 경우 Redis에서 HTML을 제공합니다.
신선도를 보장하기 위해 TTL(time-to-live)을 설정합니다.

사용 사례

이는 백엔드 환경을 제어하고 정확한 캐시 무효화 로직을 원하는 내부 도구, 호스팅된 대시보드 또는 애플리케이션에 적합합니다.

전략 3: 캐시 키 라우팅을 사용하는 Edge Middleware

콘텐츠에 여러 변형(예: 지역 타겟팅 또는 A/B 테스트)이 있는 경우 Edge Middleware를 사용하여 요청 경로를 수정하고 규칙에 따라 캐시를 분할할 수 있습니다.

예를 들어 다음과 같습니다.

국가를 기준으로 사용자를 example.com 에서 example.com/us 또는 example.com/fr 로 리디렉션
각 국가별 경로에 대한 SSR 출력을 개별적으로 캐시합니다.

이는 페이지 렌더링이 발생 하기 전에 작동하여 고유한 요청마다 캐시를 무효화하지 않고도 지역 또는 테스트 그룹별로 캐시를 관리할 수 있도록 합니다.

전략 4: 하이브리드 ISR(Incremental Static Regeneration)

ISR은 정적 페이지만을 위한 것이 아닙니다. Next.js 15+에서는 특히 ISR과 엣지 캐싱을 결합할 때 SSR과 유사한 페이지도 재검증의 이점을 누릴 수 있습니다.

revalidate와 함께 getStaticProps를 사용하는 경우, 페이지는 전체 SSR 페이지처럼 작동할 수 있지만 재생성 로직이 내장되어 있습니다.

요컨대 다음과 같습니다.

Vercel을 사용하는 경우 Cache-Control 헤더로 간단하게 시작하세요.
개인화된 캐싱이나 복잡한 제어가 필요한 경우 Redis 또는 엣지 로직을 사용하여 더 깊이 들어가세요.
캐시 무효화에 대해 미리 생각해 보세요 — 오래된 콘텐츠는 느린 콘텐츠보다 더 나쁩니다.

코드 예제: SSR + 캐시 제어 설정

이제 App Router를 사용하는 최신 Next.js 15+ 앱에서 전체 페이지 캐싱이 실제로 어떻게 보이는지 살펴보겠습니다.

일반적인 시나리오는 다음과 같습니다. 서버 사이드에서 렌더링된 제품 상세 페이지가 있지만 콘텐츠가 자주 변경되지 않습니다. 60초 동안 캐시하고 백그라운드에서 새 버전을 가져오는 동안 오래된 콘텐츠를 제공할 수 있도록 허용하려고 합니다.

Cache-Control 헤더가 특히 Vercel과 같은 플랫폼에 배포될 때 빛을 발하는 곳입니다.

단계별 예시

app/ 디렉토리 내의 경로 기반 페이지 파일에서 설정하는 방법은 다음과 같습니다.

// app/product/[slug]/page.tsx
import { headers } from 'next/headers';
import { fetchProductBySlug } from '@/lib/data';

export const dynamic = 'force-dynamic'; // 이 경로는 항상 서버 렌더링되도록합니다

export default async function ProductPage({ params }) {
  const { slug } = params;

  // 백엔드 페치 시뮬레이션 (DB 또는 외부 API)
  const product = await fetchProductBySlug(slug);

  // 캐싱 헤더를 직접 설정
  const responseHeaders = headers();
  responseHeaders.set(
    'Cache-Control',
    'public, s-maxage=60, stale-while-revalidate=120'
  );

  return (
    <main>
      <h1>{product.title}</h1>
      <p>{product.description}</p>
      <p>Price: ${product.price}</p>
    </main>
  );
}

NOTE: 이 기능은 CDN 수준에서 이러한 헤더를 존중하는 플랫폼(예: Vercel 또는 Netlify Edge Functions)에 배포된 경우에만 의도한 대로 작동합니다.

여기서 무슨 일이 일어나고 있을까요?

force-dynamic은 페이지가 항상 SSR되도록 강제합니다.
Cache-Control 헤더는 CDN에 다음을 지시합니다.
- 60초 동안 응답을 캐시합니다(s-maxage=60).
- 백그라운드에서 다시 검증하는 동안 최대 120초 동안 오래된 버전을 제공합니다.
결과: 첫 번째 요청이 서버에서 페이지를 렌더링 → 60초 동안 모든 후속 요청이 캐시에 도달 → 60초가 지나면 캐시가 만료되지만, 사용자는 기다리지 않고 즉시 만료된 콘텐츠를 제공받으며 Next.js가 자동으로 캐시를 새로 고칩니다.

피해야 할 문제들

응답에서 cookies를 사용하는 경우 페이지에서 CDN 캐싱을 완전히 건너뛸 수 있습니다. 이를 제거하거나 로직을 클라이언트 컴포넌트로 이동합니다.
s-maxage를 빠뜨리면 CDN이 얼마 동안 캐시해야 할지 알 수 없으므로, 결과적으로 캐싱이 전혀 동작하지 않습니다.
의도적으로 모든 형태의 캐싱을 비활성화하는 경우가 아니라면 no-store를 사용하지 마세요 (드물지만).

이 패턴은 최신 스택에서 전체 페이지 SSR 캐싱을 구현하는 가장 쉽고 효과적인 방법 중 하나입니다. 추가 인프라가 없습니다. Redis가 없습니다. 스마트 헤더만 있으면 됩니다.

동적 콘텐츠를 캐싱하는 것은 모든 사용자가 다른 것을 볼 수 있는 경우 까다롭습니다. 지역 타겟팅 랜딩 페이지, A/B 테스트 변형 또는 언어별 SSR 경로를 생각해 보세요.

모든 사람에게 동일한 HTML을 캐시하면 잘못된 사용자에게 잘못된 콘텐츠를 표시할 위험이 있습니다. 그러나 캐싱을 완전히 건너뛰면 성능이 저하됩니다.

Edge Middleware는 페이지가 렌더링되기 전에 캐시를 제어하는 세 번째 옵션을 제공합니다.

핵심 아이디어

Edge Middleware는 요청이 실제 페이지 코드에 도달하기 전에 실행됩니다. 즉, 다음을 수행할 수 있습니다.

요청 검사(지역, 쿠키, 헤더)
URL 또는 경로 수정
헤더를 삽입하거나 경로를 변경하여 올바른 변형을 제공합니다.
CDN이 이러한 변형을 별도로 캐시하도록 합니다.

이것은 모든 고유 사용자에 대해 캐시를 파괴하지 않고 변형별로 캐시를 분할하는 데 중요합니다.

예시: 지역 타겟팅 제품 페이지

국가를 기준으로 캐시된 버전의 /product/shoes(/us/product/shoes 대 /de/product/shoes)를 게재한다고 가정해 보겠습니다.

다음과 같이 미들웨어를 사용할 수 있습니다.

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export const config = {
  matcher: ['/product/:path*'], //  product 경로에만 적용
};

export function middleware(request: NextRequest) {
  const geo = request.geo?.country || 'US'; // 사용할 수 없는 기본값
  const url = request.nextUrl.clone();

  // 캐시 가능한 변형을 생성하기 위해 국가 코드와 URL prefix
  url.pathname = `/${geo.toLowerCase()}${url.pathname}`;

  return NextResponse.rewrite(url, {
    headers: {
      'Cache-Control': 'public, s-maxage=60, stale-while-revalidate=120',
    },
  });
    }

지금

독일 사용자는 /de/product/shoes를 누르고 있습니다.
미국 사용자는 /us/product/shoes를 누르고 있습니다.
두 버전 모두 CDN 수준에서 독립적으로 캐시됩니다.

페이지 자체의 논리를 변경할 필요가 없으며 개인화를 희생하지 않고도 캐싱의 속도 이점을 얻을 수 있습니다.

이 패턴을 사용하는 경우

지역 기반 마케팅 페이지 또는 지역별 가격 책정
각 테스트 그룹이 서로 다른 변형을 가져오는 A/B 테스트
언어 접두사가 붙은 경로(예: /fr, /es 등)

주의사항

캐시 카디널리티 (변형당 하나의 버전)를 늘리고 있습니다 — 이는 괜찮지만 그에 따라 계획하세요.
너무 많은 조합(지역 + AB + 장치 + 로그인 상태)을 도입하지 않으면 캐시가 비효율적이 됩니다.
엣지 로직을 철저히 테스트하세요 — 잘못된 리디렉션은 경로를 끊을 수 있습니다.

미들웨어를 사용하면 캐싱이 발생하기 전에 요청을 형성할 수 있으며, 이를 통해 안전하고 확장 가능한 개인화의 문이 열립니다.

ISR + Edge = 완벽한 듀오

한동안 Next.js 사용해 왔다면 전체 재배포 없이 초기 빌드 이후 업데이트되는 정적 페이지 뒤에 숨은 마법인 ISR(Incremental Static Regeneration)에 대해 이미 알고 있을 것입니다.

하지만 ISR과 엣지 캐싱을 결합하면 어떻게 될까요?

다음과 같은 설정을 얻을 수 있습니다.

정적 생성처럼 빠릅니다.
SSR처럼 신선합니다.
CDN처럼 전 세계에 배포됩니다.

이것이 어떻게 작동하는지, 그리고 이것이 여전히 최신 상태로 유지되는 전체 페이지 캐싱을 위한 최고의 전략 중 하나인 이유를 분석해 보겠습니다.

간략한 요약: ISR 작동 방식

ISR을 사용하면 getStaticProps를 사용하여 정적 페이지를 미리 렌더링할 수 있을 뿐만 아니라 revalidate 간격도 정의할 수 있습니다. 그 시간이 지나면 다음 동작이 수행됩니다.

간격 이후의 첫 번째 요청은 재생성을 트리거합니다.
이전 버전은 즉시 제공됩니다.
새로운 버전은 백그라운드에서 빌드되며 준비가 되면 캐시를 대체합니다.

이를 통해 사용자 요청을 막지 않는 논블로킹 방식으로 페이지를 최신 상태로 유지할 수 있습니다.

이것이 Edge 캐싱과 작동하는 방식

Vercel에 배포된 경우 다음과 같이 동작합니다.

ISR 생성 페이지는 기본적으로 Edge Network에서 제공됩니다.
Vercel은 캐시 키와 무효화를 자동으로 처리합니다.
모든 지역의 요청은 인근 CDN 엣지에서 빠른 응답을 받습니다.

사진에 stale-while-revalidate를 추가하면 이제 백그라운드에서 새 버전이 생성되는 동안 약간 오래된 페이지를 즉시 제공할 수 있습니다.

예시 코드: Next.js 15+의 ISR

App Router를 사용하여 ISR 기반 페이지가 표시되는 방식은 다음과 같습니다.

tsx
CopyEdit
// app/blog/[slug]/page.tsx
import { getPost } from '@/lib/posts';

export const revalidate = 60; // 60 초마다 재평가하세요

export default async function BlogPost({ params }) {
  const post = await getPost(params.slug);

  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );

이 한 줄은 다음과 같습니다.

export const revalidate = 60;

… Next.js 다음과 같이 말합니다.

"이 페이지의 정적 버전을 제공하되 마지막 재생성 이후 60초 이상이 지났다면 백그라운드에서 조용히 다시 빌드하세요."

이것이 강력한 이유

ISR + Edge 사용:

요청당 한 번이 아닌 간격당 한 번만 백엔드에 접속합니다.
방문자는 가장 가까운 CDN 노드에서 초고속 페이지 로드를 받습니다.
재생되는 동안 사용자를 차단하지 않습니다 — 사용자에게 보이지 않습니다.
캐시는 수동 무효화 없이 충분히 신선하게 유지됩니다.

따라서 다음에 이상적입니다.

블로그
상품 상세 페이지
가격 책정 페이지
자주 업데이트되지만 모든 요청에 업데이트되는 것은 아닌 모든 페이지

성능 저하 없이 엣지에서의 개인화

개인화된 경험은 사용자에게 좋지만 신중하게 다루지 않으면 성능에 악몽이 될 것입니다. 이유는 무엇일까요?

개인화는 종종 캐싱을 중단하기 때문입니다.

사용자마다 위치, 언어, 디바이스 유형 또는 검색 기록에 따라 다른 콘텐츠가 표시될 수 있습니다. 사용자별로 새로운 SSR 페이지를 생성하면 캐싱이 사라집니다. 한 버전을 캐싱하면 잘못된 경험을 제공할 위험이 있습니다.

해결책? 페이지가 렌더링되기 전에 개인화를 엣지로 이동합니다.

개인화가 이루어져야 하는 곳

개인화 로직을 서버에서 렌더링되는 컴포넌트 내부 깊숙이 포함시키는 대신 해당 로직을 Edge Middleware로 푸시합니다.

미들웨어를 사용하면 다음을 수행할 수 있습니다.

지역 또는 헤더를 기반으로 URL 수정합니다.
페이지 렌더링에 영향을 주는 헤더 또는 쿠키 추가합니다.
요청을 변형 경로(예: /fr/home, /us/home)로 다시 작성합니다.
실제 페이지 내에서 동적 렌더링 로직을 피하고 캐시 가능하게 유지합니다.

실제 사용 사례: 지리 인식 랜딩 페이지

방문 페이지가 하나이지만 방문자의 국가를 기반으로 현지화된 버전을 표시하려고 한다고 가정해 보겠습니다.

미들웨어와 함께 사용하기

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export const config = {
  matcher: ['/landing'],
};

export function middleware(request: NextRequest) {
  const geo = request.geo?.country?.toLowerCase() || 'us';
  const url = request.nextUrl.clone();
  url.pathname = `/${geo}/landing`; // 현지화 된 버전으로의 경로

  return NextResponse.rewrite(url, {
    headers: {
      'Cache-Control': 'public, s-maxage=60, stale-while-revalidate=120',
    },
  });
}

그러면 /us/landing, /de/landing 및 /in/landing 페이지를 페이지 자체에 조건부 논리 없이 독립적으로 정적으로 또는 SSR로 렌더링하고 캐시할 수 있습니다.

캐시 기능 그대로 유지

캐시 성능을 유지하려면 다음을 수행합니다.

필요한 경우가 아니면 헤더 또는 쿠키에 사용자별 데이터를 전달하지 마세요.
국가나 언어와 같이 자주 변경되지 않는 예측 가능한 변형으로 페이지를 분할합니다.
경로 재작성 또는 쿼리 문자열을 사용하여 이러한 변형을 별도로 캐시합니다.

올바르게 수행되면 변동이 일관되고 예측 가능한 한 경우 개인화된 경험을 위해 Cache-Control, ISR 또는 수동 Redis 캐싱을 계속 사용할 수 있습니다.

요약

핵심은 다음과 같습니다.

개인화가 모든 사용자에게 SSR을 의미할 필요는 없습니다.

미들웨어와 스마트 라우팅을 사용하면 페이지를 캐시 친화적으로 유지하면서도 사용자에게 기대하는 경험을 제공할 수 있습니다.

Vercel을 사용한 엣지 캐싱 디버깅

캐싱은 예상대로 작동할 때 훌륭합니다. 그러나 페이지가 느린 이유, 캐시가 적중하지 않는 이유 또는 사용자가 오래된 데이터를 보는 이유를 파악하는 것은 가시성 없이는 실망스러울 수 있습니다.

Vercel(또는 고급 캐싱을 지원하는 CDN)에 배포하는 경우 캐싱이 실시간으로 어떻게 작동하는지 검사하고 디버깅하는 데 사용할 수 있는 명확한 도구와 헤더가 있습니다.

1단계: 응답 헤더 확인

Vercel의 모든 캐시된 응답에는 x-vercel-cache 헤더가 포함됩니다. 페이지가 다음과 같은지 여부를 알려줍니다.

HIT: 캐시에서 제공 — 이것이 당신이 원하는 것입니다.
MISS: 캐시가 없기 때문에 요청이 서버로 전달되었습니다.
STALE : 캐시가 만료되었지만 새 버전이 재빌드되는 동안 오래된 버전이 제공되었습니다.

브라우저 DevTools(네트워크 탭) 또는 curl을 사용하여 다음을 검사합니다.

bash
CopyEdit
curl -I https://your-domain.com/pa

다음과 같은 헤더를 찾으세요.

x-vercel-cache: HIT
cache-control: public, s-maxage=60, stale-while-revalidate=120

이를 통해 실시간으로 캐싱 작동 여부를 확인할 수 있습니다.

2단계: 다른 지역으로 테스트

Vercel은 전 세계 엣지 로케이션에 콘텐츠를 캐시합니다. 경우에 따라 캐시는 한 지역에서는 warm하지만 다른 지역에서는 cold 할 수 있습니다.

테스트는 다음을 참고하세요.

VPN 또는 프록시를 사용하여 다른 국가의 요청을 시뮬레이션합니다.
혹은 Vercel의 CLI를 사용하여 캐시 동작을 시뮬레이션합니다.

이는 지리 인식 콘텐츠나 글로벌 앱의 경우 특히 중요하며, 미국에서는 HIT가 첫 번째 요청에서 유럽에서는 MISS가 될 수 있습니다.

3단계: 캐시 버스터 감시

다음과 같은 특정 항목은 자동으로 캐시를 우회합니다.

next-auth.session-token과 같은 쿠키가 있는 요청
force-dynamic을 호출하고 캐시 헤더를 설정하지 않는 페이지
요청별로 변경되는 쿼리 문자열 또는 헤더(고려되지 않은 경우)

HITS를 받지 못하면 요청에 포함된 내용을 살펴보세요. 캐시 우회를 트리거하는 미묘한 쿠키, 쿼리 또는 헤더인 경우가 많습니다.

4단계: Vercel Analytics 사용

Vercel의 Pro 요금제를 사용하는 경우 내장된 Analytics 대시보드는 모든 지역의 실제 성능 데이터를 제공합니다. 다음을 측정할 수 있습니다.

캐시 적중률
TTFB (Time to First Byte)
위치별 대기 시간
재검증 패턴

이렇게 하면 실제 사용자 경험을 캐싱 전략과 연관시키는 데 도움이 됩니다.

디버깅 팁

DevTools로 시작하고 x-vercel-cache를 살펴보세요.
독립적이고 재현 가능한 테스트를 위해 curl을 사용하세요.
공개 페이지에 대한 불필요한 쿠키 제거하세요.
Cache-Control 헤더가 일관되고 존재하는지 확인하십세요.
시간 경과에 따른 모니터링 — 하나의 좋은 요청이 캐시가 사이트 전체에서 작동한다는 것을 의미하지는 않습니다.

Edge 및 전체 페이지 캐싱에 대한 모범 사례

지금까지 SSR 페이지를 캐싱하는 방법부터 캐싱 시기 및 위치(서버, CDN, 엣지 또는 Redis)까지 많은 내용을 다뤘습니다. 하지만 현실은 완벽하지 않습니다. 작은 실수로 인해 조용히 성능이 저하되거나 추적하기 어려운 버그가 발생할 수 있습니다.

마무리하기 전에 SSR 및 엣지 캐싱 구현을 깔끔하고 빠르고 안정적으로 유지하는 데 도움이 되는 몇 가지 실용적인 캐싱 모범 사례를 소개합니다.

의도하지 않는 한 `no-store`를 피하세요

Cache-Control: no-store 설정은 CDN, 브라우저, 모든 것과 같은 모든 캐싱을 효과적으로 비활성화합니다. 다음 경우에만 사용하세요.

인증된 사용자 페이지(예: 대시보드)
캐시해서는 안 되는 민감한 데이터

대부분의 SSR 사용 사례에서는 stale-while-revalidate가 있는 짧은 s-maxage라도 캐싱을 전혀 하지 않는 것보다 낫습니다.

2. `stale-while-revalidate`를 사용하여 블로킹을 방지하세요

이 지시어는 매우 유용한 도구입니다. 사용자는 페이지가 다시 생성될 때까지 기다릴 필요 없이 오래된 버전을 즉시 받고 백그라운드에서 새 페이지를 작성할 수 있습니다.

재생을 차단하면 병목 현상이 발생할 수 있는 트래픽이 급증할 때 특히 유용합니다.

3. 쿠키에 주의하세요

쿠키는 일반적인 캐시 킬러입니다. Vercel을 포함한 많은 CDN은 요청에 특정 쿠키, 특히 인증과 관련된 쿠키가 포함된 경우 캐시를 완전히 우회합니다.

솔루션

개인 설정을 페이지 내부가 아닌 미들웨어로 이동
공개 SSR 경로에서 필수적이지 않은 쿠키 제거
마케팅 또는 랜딩 페이지에서 불필요한 쿠키 사용 방지

4. 올바른 재검증 빈도 선택

revalidate를 사용하는 경우 숫자만 추측하지 마세요. 다음을 고려하세요.

콘텐츠가 실제로 변경되는 빈도
업데이트를 즉시 확인하는 것이 얼마나 중요한지
처리할 수 있는 백엔드 로드의 양

대부분의 콘텐츠가 많은 SSR 페이지에 대한 좋은 기준은 revalidate: 60이며, 이는 페이지가 재구축되기 전에 1분 동안 최신 상태로 유지됨을 의미합니다.

5. 변형별 캐시 — 중요한 경우에만

캐시를 과도하게 조각화하지 마세요. 지역, 언어 또는 장치 유형에 따라 다른 경우 각 변형이 그만한 가치가 있는지 확인하세요.

모든 고유한 버전은 캐시 크기와 복잡성을 증가시킵니다.

UX를 진정으로 개선하는 변형만 캐시합니다.

6. 모든 것을 모니터링하세요

보이지 않는 것은 개선할 수 없습니다.

실시간 통찰력을 위해 x-vercel-cache 헤더 사용
Vercel Analytics 또는 사용자 지정 로깅에 연결하여 성능 추적
다양한 지역에서 정기적인 컬 테스트를 실행하여 엣지 동작을 검증합니다.

캐싱은 초능력이지만 의도적으로 사용하는 경우에만 가능합니다.

올바른 헤더, 스마트 미들웨어 및 견고한 재검증 전략을 통해 SSR 페이지는 정적 페이지만큼 원활하게 확장할 수 있습니다.

결론

SSR 페이지를 캐싱하는 것은 모순처럼 느껴졌습니다 — 모든 요청에서 신선해야 하는 것을 어떻게 캐시합니까?

하지만 이 게시물에서 보았듯이 이는 절대적으로 가능하며 많은 경우 필수적입니다.

활용

Smart Cache-Control 헤더
개인화 인식 라우팅을 위한 Edge Middleware
수동 제어를 위한 Redis 또는 사용자 정의 논리
CDN 지원 전달을 통한 ISR(Incremental Static Regeneration)

신선도, 유연성 또는 사용자 경험을 희생하지 않고 성능 병목 현상을 강점으로 전환할 수 있습니다.

전체 페이지 캐싱은 비용을 절감하기 위한 것이 아닙니다. 중요한 페이지를 어디에 어떻게 캐싱할지 파악하여 사용자가 초고속 페이지를 경험하고 서버는 부하를 견딜 수 있도록 하기 위함입니다.

다음 소식

다음 게시물에서는 캐싱을 더욱 발전시킬 것입니다 - 이번에는 CDN 수준으로.

Cloudflare, AWS CloudFront 및 Vercel의 자체 Smart CDN과 같은 글로벌 CDN 제공업체가 Next.js 앱을 강화할 수 있는 방법을 살펴보겠습니다.

헤더를 구성하고, stale-while-revalidate 동작을 조정하고, 기본적으로 전체 사이트를 전역적으로 빠르게 만드는 방법을 배웁니다.