프로토타입을 빠르게 만드는 것과 올바르게 만드는 것은 다른 문제다. Vercel, Neon, Supabase, Resend를 조합하면 초기 운영 비용을 월 $6 수준으로 줄일 수 있다는 건 이미 검증된 이야기다. 하지만 스택 선택보다 먼저 결정해야 할 것이 있다. 각 페이지를 언제, 어떻게 렌더링할 것인가—즉 렌더링 전략이다.
이 질문을 나중으로 미루는 순간, 'Vercel 무료 티어에서 서버리스 함수 실행 시간이 왜 이렇게 많이 나가지?'라는 당혹감을 마주치게 된다. 혹은 반대로, ISR로 충분한 페이지를 굳이 SSR로 처리하면서 WordPress API를 Googlebot 크롤링 횟수만큼 호출하고 있다는 걸 뒤늦게 발견한다.
실험으로 보는 세 전략의 실제 차이
dev.to에 공개된 astro-wp-seo-lab 실험은 이 차이를 문서가 아닌 실측으로 보여준다는 점에서 흥미롭다. 동일한 WordPress 콘텐츠를 SSG, SSR, SSR+CDN 캐시, ISR(route-cache), Islands 아키텍처—다섯 가지 방식으로 동시에 서빙하고, 각 페이지 상단에 렌더링 시각을 찍어 비교한다. 이론이 아니라 타임스탬프로 차이를 보여주는 방식이다.
결과 중 가장 직관에 반하는 수치가 있다. Warm 상태 p75 TTFB 기준으로 route-cache(ISR)가 ssg-full(정적 파일)보다 빠른 경우가 있다. 정적 HTML이 가장 빠를 거라는 가정은 틀렸다. 인메모리 캐시는 파일시스템 접근조차 건너뛰기 때문이다. ssg-full이 0.43ms일 때 route-cache는 0.38ms였다. 이건 세팅 차이가 아니라 구조적 차이다.
또 하나 주목할 숫자는 ssr-cdn의 cold vs warm 격차다. 동일 라우트에서 cold p75 7.14ms, warm p75 0.93ms—7.7배 차이다. CDN 캐시의 이점은 origin 렌더링 코드와 무관하다. ssr-cdn과 plain ssr의 origin 응답 시간이 사실상 동일한 것도 이를 확인해준다. CDN이 앞에 없으면 캐시 헤더는 그냥 선언일 뿐이다.
SEO가 렌더링 전략을 강제하는 지점
실험에서 가장 실무적인 시사점은 Islands 아키텍처 섹션에서 나온다. server:defer로 지연 렌더링한 'Related posts' 컴포넌트는 브라우저에서는 정상적으로 보이지만, curl로 가져온 raw HTML에는 존재하지 않는다. 파비콘 버튼을 잘못 클릭하는 UX 문제가 아니라, 크롤러가 링크 자체를 발견하지 못하는 구조적 SEO 문제다.
Google이 JavaScript를 실행한다는 건 사실이지만, 크롤링과 렌더링은 별개의 큐로 처리된다. JS 전용 콘텐츠는 발견이 수일 지연될 수 있고, Bing은 일관성이 없으며, AI 크롤러들은 대부분 raw HTML만 가져간다. 실험의 결론은 명확하다—인덱싱되어야 할 모든 것은 정적 셸에 있어야 한다. server:defer는 UX 최적화 도구이지, 콘텐츠 배포 수단이 아니다.
$100/월 스택과 렌더링 전략의 교차점
dev.to에 소개된 $87/월 SaaS 스택—Vercel Hobby, Neon Free, NextAuth, Resend, Plausible, Polar.sh—은 초기 단계에서 매력적인 선택지다. 하지만 이 스택의 비용 구조를 실제로 유지하려면 렌더링 전략이 올바르게 설계되어 있어야 한다.
Vercel Hobby 티어의 서버리스 함수 실행 시간은 무한하지 않다. 콘텐츠가 자주 바뀌지 않는 마케팅 페이지, 블로그, 문서를 SSR로 처리하고 있다면 불필요한 함수 실행이 누적된다. ISR이나 SSG로 처리할 수 있는 페이지를 SSR로 두는 것은 비용 낭비이자 성능 손해다. 반대로, 사용자별 맞춤 데이터가 필요한 대시보드를 SSG로 캐싱하면 잘못된 데이터가 노출되는 버그가 된다.
렌더링 전략을 라우트 단위로 설계하는 습관이 필요한 이유가 여기 있다. Next.js의 export const revalidate나 export const dynamic은 파일 한 줄이지만, 그 선택이 인프라 비용, SEO 가시성, 데이터 신선도를 동시에 결정한다.
빠른 프로토타이핑과 올바른 설계는 양립한다
v0.dev나 Cursor로 UI를 빠르게 만들고 Vercel에 즉시 배포하는 워크플로우는 실제로 강력하다. 하지만 AI가 생성한 Next.js 페이지 컴포넌트는 기본적으로 SSR 또는 CSR로 동작하는 경우가 많다. 프로토타입 단계에서 이 기본값을 그대로 두면, 검증이 끝나고 스케일업할 시점에 렌더링 전략 전체를 재설계해야 하는 부채가 쌓인다.
실용적인 접근은 간단하다. 페이지를 만들기 전에 세 가지를 먼저 물어본다. 이 페이지의 데이터는 얼마나 자주 바뀌는가? 크롤러가 이 콘텐츠를 인덱싱해야 하는가? 이 콘텐츠는 사용자마다 달라지는가? 이 세 질문에 답하면 SSG·ISR·SSR 중 어디에 놓을지가 자연스럽게 결정된다.
렌더링 전략은 성능 최적화 단계의 이야기가 아니다. 설계 첫 단계에서 결정해야 할 아키텍처 선택이다. 스택이 아무리 저렴해도, 렌더링 전략이 잘못 설계된 앱은 스케일이 올라갈수록 비용과 품질 양쪽에서 균열이 생긴다. 빠르게 만들되, 올바르게 설계하는 것—이 두 가지는 순서가 있는 게 아니라 동시에 챙겨야 할 기준이다.