엣지 캐싱 전략: 글로벌 SaaS를 위한 CDN에서 Workers Cache까지

캐싱(Caching)은 SaaS 애플리케이션을 위한 가장 영향력 있는 단일 성능 최적화 방법입니다. 이는 지연 시간(Latency)을 줄이고, 오리진 부하(Origin load)를 낮추며, 사용자 경험을 개선합니다. Cloudflare는 전 세계적으로 30ms 이내에 엣지 로케이션(Edge locations)에서 콘텐츠를 제공할 수 있는 다층 캐싱 스택(CDN, Workers Cache API, KV, D1 쿼리 캐싱, Cache Reserve)을 제공합니다. 이 가이드는 tanstackship.com에서 사용되는 실질적인 패턴과 함께 각 계층에서의 캐싱 전략을 다룹니다.

캐싱 스택 (The Caching Stack)

Cloudflare의 캐싱 인프라는 각각 다른 특성을 가진 여러 계층으로 구성됩니다:

계층 1: CDN 캐싱 (Layer 1: CDN Caching)

기본 엣지 캐싱 (Default Edge Caching)

// wrangler.jsonc — 캐싱 규칙 설정
{
  "name": "tanstack-ship",
...

Cache-Control 헤더 (Cache-Control Headers)

// 서버 함수에서 cache-control 헤더 설정
export const getPublicProduct = createServerFn({ method: "GET" }).handler(
  async ({ data, context }) => {
...

계층 2: Workers Cache API (Layer 2: Workers Cache API)

CDN 캐싱은 불가능하지만 인메모리 캐싱(In-memory caching)의 이점을 얻을 수 있는 동적 콘텐츠의 경우:

// server/middleware/cache.ts
interface CacheOptions {
  ttl: number           // 초 단위 생존 시간 (Time to live in seconds)
...

서버 함수에서의 사용 (Usage in Server Functions)

// 자주 액세스되는 데이터 캐싱
export const getDashboardStats = createServerFn({ method: "GET" }).handler(
  async ({}, { context }) => {
...

계층 3: 글로벌 설정을 위한 Workers KV (Layer 3: Workers KV for Global Configuration)

KV는 변경 빈도가 낮은 설정 데이터에 이상적입니다:

// KV에 가격 설정 저장
await context.env.KV.put("pricing:starter", JSON.stringify({
  monthlyPrice: 29,
...

KV vs D1 vs Cache API 사용 시점

Layer 4: Stale-While-Revalidate

SaaS를 위한 가장 중요한 캐싱 패턴:

export const getAnalyticsData = createServerFn({ method: "GET" }).handler(
  async ({ data, context }: { data: { timeframe: string } }) => {
    // 캐시에서 제공한 후, 백그라운드에서 새로고침
...

캐시 무효화 (Cache Invalidation)

수동 캐시 퍼징 (Manual Cache Purging)

// server/admin/cache.ts
export const purgePageCache = createServerFn({ method: "POST" }).handler(
  async ({ data, context }: { data: { url: string } }) => {
...

캐시 태그 (Cache Tags / Surrogate Keys)

// 세밀한 무효화를 위해 캐시 항목에 태그 지정
context.response.headers.set(
  "Cache-Tag",
...

캐시 전략 의사결정 트리 (Cache Strategy Decision Tree)

데이터가 사용자별로 특화되어 있는가? (Is the data user-specific?)
├── YES → CDN 레벨에서 캐싱하지 마십시오
│   ├── 사용자별 키를 사용하여 Workers Cache API 사용
...

캐시 적중률 최적화 (Cache Hit Rate Optimization)

// 캐시 성능 로그 기록 및 모니터링
export const getCacheMetrics = createServerFn({ method: "GET" }).handler(
  async ({}, { context }) => {
...

프로덕션 캐싱 체크리스트 (Production Caching Checklist)

• 파일 이름에 콘텐츠 해시 (content hash)를 포함하여 정적 자산 (Static assets)을 1년 동안 캐싱
• HTML 페이지를 5~60초의 TTL + stale-while-revalidate 설정으로 캐싱
• 업데이트 빈도에 따라 적절한 TTL을 적용하여 API 응답을 캐싱
• 사용자별 데이터 중 변경 속도가 느린 데이터에 Workers Cache API 사용
• 글로벌 설정 및 피처 플래그 (feature flags)를 위해 KV 사용
• 세밀한 무효화 (invalidation)를 위해 캐시 태그 (Cache tags) 설정
• 캐시 히트율 (Cache hit rate)을 모니터링하고 10% 이상 하락 시 알림 설정
• 중요한 엔드포인트에 대해 stale-while-revalidate 활성화
• 알려진 트래픽 패턴에 대한 캐시 프리워밍 (Cache pre-warming)
• 쿼리 파라미터 (query parameter) 변동성에 따른 캐시 키 (Cache key) 전략 검토

결론 (Conclusion)

엣지 캐싱 (Edge caching)은 단일 설정이 아니라 다층적인 전략입니다. 올바른 접근 방식은 데이터에 따라 달라집니다. 정적 자산은 공격적으로 캐싱해야 하며, 사용자별 데이터는 Workers Cache API를 사용해야 하고, 설정은 KV에 저장해야 하며, 데이터베이스 쿼리는 데이터의 신선도 (staleness)가 허용되는 경우에만 캐싱해야 합니다.

Cloudflare 스택은 이러한 전략을 쉽게 구현할 수 있게 해줍니다. 첫 번째 계층으로는 CDN 캐시를, 동적 콘텐츠를 위해서는 Cache API를, 설정을 위해서는 KV를, 그리고 대용량 객체를 위해서는 Cache Reserve를 사용합니다. 이들을 결합하면 90% 이상의 요청을 10ms 미만의 지연 시간 (latency)으로 엣지 캐시에서 처리할 수 있습니다.

최적화된 캐싱 전략을 갖춘 프로덕션 SaaS에 대해서는 tanstackship.com을 참조하세요.

관련 리소스 (Related Resources)

• Cloudflare R2: 엣지 애플리케이션을 위한 객체 스토리지 (Object Storage)
• Cloudflare D1: 엣지에서의 프로덕션 데이터베이스 (Production Database)
• 코어 웹 바이탈 (Core Web Vitals) 최적화 가이드
• 성능 예산 책정 (Performance Budgeting): 목표 설정 및 자동화된 강제 적용