Three Tiers of Data Freshness in a SvelteKit Static Site

Context

정적 사이트는 호스팅이 저렴하고 빠르지만 배포 순간부터 데이터가 부실(stale)해진다. GitHub Pages에서 서버나 엣지 함수 없이 순수 정적 HTML로 배포하면서 외부 데이터 소스의 신선도 요구사항이 각각 다른 상황을 어떻게 처리할 것인가가 문제였다.

Technical Solution

• Tier 1 - 배포 시점 사전 렌더링: +page.server.ts 로더에서 North Cloud API를 빌드 타임에만 호출해 데이터를 HTML에 직접 포함, 재배포 시에만 갱신
• Tier 2 - 클라이언트 측 캐싱: prerender = false로 설정한 /blog 경로에서 RSS 피드를 브라우저에서 런타임에 요청하고 feedCache를 30분 단위로 유지
• Tier 3 - 사전 렌더링 + 실시간 갱신: entries() 함수로 빌드 타임에 Series ID를 미리 파악해 각 경로마다 정적 HTML 생성하되, load 함수가 클라이언트 네비게이션 시에도 실행되도록 해 GitHub 소스코드와 Hugo JSON 엔드포인트에서 신선한 데이터 조회
• Fetch 주입 패턴: 모든 서비스 함수의 첫 번째 매개변수로 fetchFn: typeof fetch를 받아 SvelteKit의 SSR fetch(쿠키 처리, 요청 중복 제거)와 브라우저 fetch 간 차이를 흡수하고 테스트 용이성 확보
• 404 플래시 방지: prerender = false 경로에서도 GitHub Pages의 fallback: '404.html' 설정으로 SPA 라우터가 클라이언트에서 접수할 수 있도록 함

Key Takeaway

정적 배포와 동적 데이터를 양립시키려면 데이터마다 필요한 신선도 수준(배포 시점/30분 캐시/실시간)을 명확히 분류하고, 빌드 타임과 런타임에 실행 가능한 로더 함수를 전략적으로 배치하는 것이 핵심이다.