About→
Mail

← About

Next.js와 Sanity를 선택한 이유

웹 공간을 구축하기로 결정한 후, 핵심 기술 스택으로 Next.js와 Sanity를 선택했습니다. 이 선택의 목적은 단 두 가지였습니다.

  • Next.js: 검색엔진(SEO)이 정확히 수집할 수 있는 HTML과 메타데이터를 생성하기 위함
  • Sanity: 코드 재배포 없이 콘텐츠(글, 브리핑, 도구)를 자유롭게 관리하기 위함

Next.js: 검색엔진에 열려 있는 HTML과 SSG 선택

pokitstory.com은 앱 서비스만으로는 해결할 수 없는 검색 유입(SEO)을 끌어오기 위한 웹 공간입니다. 매거진 홈, 아카이브, 주간 브리핑, 앱 소개 등의 페이지가 구글 검색엔진에 정적 문서로 인덱싱되어야 비로소 의미를 갖습니다.

클라이언트 사이드 렌더링(CSR) 기반의 SPA는 첫 응답 시 빈 껍데기 HTML만 반환하므로, 크롤러가 자바스크립트를 실행해 화면을 그려줄 때까지 기다려야 하는 불확실성이 존재합니다. 반면 Next.js (App Router)는 서버 측에서 완성된 본문이 담긴 HTML을 미리 생성합니다.

왜 SSR이 아닌 SSG(정적 사이트 생성)인가?

Next.js의 서버 렌더링 방식 중에서도 SSR과 SSG 사이에서 SSG(Static Site Generation)를 선택했습니다.

  • SSR (Server-Side Rendering): 요청이 들어올 때마다 서버에서 HTML을 새로 그리므로 유저별 맞춤 데이터나 실시간 데이터가 필요한 곳에 적합하지만, 서버 부하가 생기고 첫 응답 속도(TTFB)가 느려질 수 있습니다.
  • SSG (Static Site Generation): 페이지를 미리 완성된 HTML 파일로 구워 두고 CDN을 통해 즉시 응답하므로, 응답 속도가 매우 빠르고 크롤러가 문서를 즉각 수집할 수 있습니다.

개인화나 실시간 유저 데이터가 필요 없는 매거진 특성상, 최상의 LCP 성능과 빠른 크롤링을 보장하는 SSG 방식이 가장 적합했습니다. 덕분에 /ko, /en, /ja 각 언어별 페이지가 완성된 정적 문서 형태로 즉시 제공될 수 있었습니다.

통합된 SEO 및 메타데이터 관리

SEO 제어 로직을 프레임워크 내부로 끌어왔습니다.

  • generateMetadata: 페이지별 제목, 설명, Canonical URL, hreflang, Open Graph, Twitter Card, robots 설정을 유연하게 할당
  • 파일 기반 설정: sitemap.ts, robots.ts를 라우터 코드로 직접 작성하여 정적 파일 수동 관리 최소화
  • 구조화된 데이터 (JSON-LD): 검색 크롤러가 각 페이지의 정체성(메인 홈, 앱 소개 랜딩, 큐레이션 목록 등)을 정확히 파악할 수 있도록 표준 규격 데이터를 페이지 내부에 함께 포함

CMS나 외부 테마 위에 SEO 플러그인을 얹는 방식 대신, URL·HTML·메타데이터를 하나의 코드베이스 안에서 다루는 구조를 택했습니다.

Sanity: 코드 배포 없는 콘텐츠 발행 (SSG + ISR)

코드는 간헐적으로 변경되지만 기사, 주간 브리핑, 루틴 도구 등의 콘텐츠는 주 단위로 지속해서 업데이트됩니다. 만약 본문을 마크다운 파일로 관리하며 리포지토리에 포함했다면, 단순한 오타 수정조차 전체 사이트 빌드 및 배포를 거쳐야 했을 것입니다.

발행 프로세스를 코드 배포와 분리하기 위해 헤드리스 CMS인 Sanity를 도입했습니다.

스키마 기반 타입 분리와 다국어 통합

  • 다양한 콘텐츠 타입 분리: 기사, 주간 브리핑, 루틴 도구 등 각기 다른 성격의 데이터를 스키마 형태로 명확히 정의
  • 단일 문서 내 다국어 관리: 언어별로 별도 문서를 복제하지 않고, 하나의 Sanity 문서 내에서 한국어 원문과 영어·일본어 번역을 함께 관리

SSG와 ISR(증분 정적 재생성)의 결합

Sanity Studio에서 콘텐츠가 수정·발행되면 웹훅(Webhook)을 통해 Next.js로 요청이 전달되어 해당 페이지만 ISR(Incremental Static Regeneration) 방식으로 정적 재배포됩니다.

전체 사이트를 다시 빌드하거나 개발자가 직접 배포하지 않아도, 기존 SSG의 빠른 속도 장점을 그대로 유지하면서 최신 HTML을 즉시 반영할 수 있게 됩니다.