대충 만든 게 아니라, 설계로 만들었습니다

블로그는 읽기 집중 워크로드입니다. 그래서 RDBMS 대신 Firestore(운영 부담 0, 서버리스와 궁합이 좋음), 정적 생성 대신 MDX(코드·수학 공식 지원), 별도 CMS 대신 Firestore 문서(배포 없이 발행)를 골랐습니다. Next.js 16의 Server Components는 Firestore SDK를 클라이언트 번들에서 제외시켜 포스트 페이지 JS 크기를 줄여줍니다.

이 블로그의 트래픽은 "한 번 발행된 글을 수백 번 읽는" 패턴입니다. 그래서 2번째 요청부터는 Vercel Edge에서 정적 HTML을 바로 서빙하고, 서버리스 함수는 빌드 시와 무효화 시에만 실행됩니다. 결과적으로 읽기 요청의 서버 비용이 사실상 0에 가깝습니다.

왜 3계층인가 — 각 계층이 다른 문제를 해결합니다. Request Cache는 포스트 페이지가 같은 데이터를 3번 조회해도 Firestore는 1번만 호출되게 하고, Data Cache는 Firestore SDK가 Next.js fetch 캐시의 대상이 아니라는 한계를 메우며, Route Cache는 렌더링 자체를 없앱니다. TTL 기반 재검증을 버린 이유: 불필요한 Firestore 호출을 유발하고, 변경 직후에도 TTL까지 지연되기 때문입니다. "변경 시에만"이 이 워크로드에서 정확합니다.

오딧 전에는 root layout이 모든 페이지에 한국어 서픽스를 붙이고, /en·/jp에도 lang="ko-KR"을 내는 치명적 문제가 있었습니다. 페이지별 위임(self canonical, 로케일별 lang)으로 정리했고, IndexNow로 Bing 인덱싱 대기 시간을 수 주에서 수 분으로 줄였습니다.

개인 블로그도 XSS·클릭재킹 표적이 될 수 있습니다. Edge에서 헤더를 일괄 적용하면 개별 페이지에서 누락될 일이 없고, CSP allowlist는 광고·트래킹 스크립트만 정확히 허용해 공격 표면을 최소화합니다.

광고 스크립트는 LCP를 망가뜨리는 주범입니다. lazyOnload + 지연 push로 핵심 콘텐츠 렌더링이 끝난 뒤에 로드되도록 했고, env가 없으면 스크립트 자체가 삽입되지 않아 개발·미설정 환경에서 제로 오버헤드입니다.

콘텐츠와 코드를 분리하면 글 한 편을 발행할 때마다 배포(빌드·캐시 무효화 대기)를 할 필요가 없습니다. 저장 API가 Firestore에 쓰고 revalidation을 트리거하는 순간 모든 캐시가 갱신됩니다. 화이트리스트는 클라이언트에 노출되므로 실제 방어는 서버 토큰 검증이 담당합니다.

쿼리 파라미터(?lang=en) 대신 /en·/jp 라우트를 쓰는 이유: 각 언어가 독립 URL을 가지면 검색엔진이 각각 인덱싱하고 hreflang 관리가 명확해집니다. 번역이 없는 포스트는 해당 언어에서 숨겨져, 반쪽짜리 페이지가 노출되지 않습니다.

검색과 어드민만 force-dynamic(Shell only)입니다. 검색은 사용 패턴이 예측 불가능해 캐싱 대신 항상 최신 결과를 반환하고, 어드민은 인증이 필요한 동적 영역이라 정적 캐시를 쓰지 않습니다. 나머지는 전부 정적입니다.