5,000페이지, 숫자가 아니라 아키텍처 결정이다
프론트엔드 개발자에게 '페이지 5,000개'라는 숫자는 단순한 콘텐츠 볼륨이 아닙니다. 빌드 타임, 캐시 무효화, 번들 사이즈, 그리고 Lighthouse 점수가 동시에 흔들리는 아키텍처 의사결정의 임계점이죠. 최근 dev.to에 올라온 두 개의 사례가 이 지점을 정확히 찌릅니다. Next.js 16 App Router + ISR로 항공편 보상 플랫폼 5,700 URL을 운영하는 FlyClaim.AI 사례와, Astro + Svelte 5 + Hono로 호스팅 비교 플랫폼을 구축한 HostingSift 사례입니다.
Next.js ISR: "페이지가 방문되기 전까진 유령이에요"
FlyClaim.AI의 핵심 전략은 ISR(Incremental Static Regeneration)입니다. /[locale]/vlucht/[slug] 형태의 동적 라우트가 요청 시점에 Supabase에서 데이터를 가져오고, 1시간 revalidation 윈도우로 엣지 캐시에 올립니다. 5개 언어 × 1,134개 항공편 = 약 5,700 URL. 풀 빌드를 돌리지 않고도 새 항공편이 자동 반영되니, 8시간 주기로 Make.com이 데이터를 밀어넣는 파이프라인과 궁합이 좋습니다.
그런데 사용자 입장에서 보면 함정이 있습니다. ISR은 누군가 방문해야 페이지가 갱신됩니다. 원작자도 인정하듯, 공항 허브 페이지에 새 항공편이 추가됐는데 아무도 안 들어오면 stale 데이터가 그대로 노출돼요. 결국 크론 기반 캐시 워밍 스크립트를 별도로 돌려야 했다는 고백 — 이거 사실 ISR의 고질적 트레이드오프입니다. 5,000페이지를 크론으로 워밍한다? 그 시점에서 "이거 그냥 SSG 빌드 돌리는 거랑 뭐가 다르지?"라는 질문이 떠오를 수밖에 없습니다.
번들 사이즈 관점에서도 생각해봐야 합니다. Next.js App Router는 서버 컴포넌트를 기본으로 쓰지만, 클라이언트 바운더리를 넘는 순간 React 런타임이 통째로 내려갑니다. 이 플랫폼처럼 대부분이 정적 콘텐츠 페이지라면 — SEO 타깃의 flight detail 페이지에서 인터랙티브한 요소가 얼마나 될까요 — React 런타임의 ~40KB (gzip) 오버헤드가 모든 페이지에 붙는 셈입니다. Lighthouse Performance 점수에서 TBT(Total Blocking Time) 항목이 신경 쓰이는 대목이에요.
Astro 하이브리드: "이 페이지는 SSR, 저 페이지는 SSG"
HostingSift는 정반대 방향에서 출발합니다. Astro의 하이브리드 SSR 모드는 라우트 단위로 렌더링 전략을 스위칭합니다. 호스팅 프로필, 카테고리, 홈페이지 같은 변경 빈도 낮은 페이지는 빌드 타임에 프리렌더하고, 비교 도구처럼 사용자 인풋에 의존하는 페이지만 서버 렌더링으로 돌립니다. Figma에서 보면 같은 '페이지'인데 실제 구현에서는 렌더링 파이프라인이 완전히 다른 거죠.
여기서 진짜 차이가 나는 건 클라이언트로 내려가는 JavaScript의 양입니다. Astro는 아일랜드 아키텍처를 쓰기 때문에, 인터랙티브 컴포넌트(Svelte 5로 작성된 비교 도구 등)만 선택적으로 하이드레이션합니다. 나머지는 순수 HTML/CSS로 제로 JS 전송. 원작자가 "output is noticeably lighter"라고 표현한 부분이 바로 이겁니다. 대규모 콘텐츠 사이트에서 Core Web Vitals의 LCP와 TBT를 동시에 잡으려면, 이 '선택적 하이드레이션'이 결정적 차이를 만듭니다.
Svelte 5의 runes API($state, $derived, $effect)도 주목할 포인트입니다. React의 useEffect 의존성 배열이나 stale closure 문제 없이 반응형 상태를 다룬다는 건, 인터랙티브 아일랜드 내부의 복잡도를 크게 줄인다는 뜻이에요. 다만 원작자도 솔직하게 인정하듯, "React/Next에서 한 줄이면 되는 것에 대응하는 라이브러리가 아직 없다"는 에코시스템 갭이 존재합니다.
5,000페이지 규모에서의 실전 시사점
두 사례를 나란히 놓으면, 프론트엔드 아키텍처 선택의 핵심 기준이 선명해집니다.
- 콘텐츠 갱신 주기: 8시간 단위로 데이터가 들어오고 '신선도'가 비즈니스 가치인 경우 → ISR의 on-demand 갱신이 유리하지만, 캐시 워밍의 운영 비용을 반드시 계산해야 합니다.
- 인터랙션 밀도: 페이지 대부분이 읽기 전용 콘텐츠라면 → Astro의 아일랜드 아키텍처가 번들 사이즈와 Core Web Vitals에서 구조적으로 앞섭니다.
- 빌드 타임 vs 런타임 비용: 5,000페이지를 풀 SSG로 빌드하면 CI 파이프라인이 수십 분 걸릴 수 있습니다. ISR은 이걸 런타임으로 분산하지만, 대신 첫 방문자가 cold start 페널티를 짊어집니다. Astro 하이브리드는 정적 페이지 빌드 + 동적 페이지 서버 렌더로 나눠서 양쪽의 고통을 줄입니다.
전망: 렌더링 전략은 '선택'이 아니라 '설계'
사실 이건 "Next.js가 좋으냐 Astro가 좋으냐"의 문제가 아닙니다. 5,000페이지 규모에서 사용자가 체감하는 첫 번째 바이트까지의 시간(TTFB), 의미 있는 페인트(LCP), 인터랙션 지연(INP) 같은 Core Web Vitals 지표가 어떤 렌더링 전략에서 구조적으로 유리한지를 따져야 합니다.
Next.js 쪽도 가만히 있진 않을 겁니다. Partial Prerendering(PPR)이 안정화되면 ISR의 캐시 워밍 문제가 상당 부분 해소될 수 있고, Astro 쪽도 Server Islands와 Content Layer API의 성숙이 대규모 사이트의 DX를 한 단계 끌어올릴 겁니다. 결국 프레임워크가 아니라, "이 페이지의 이 영역은 어떤 시점에 렌더링되어야 하는가"를 1px 단위로 설계하는 감각이 5,000페이지 스케일에서 Lighthouse 점수와 사용자 리텐션을 가릅니다.