김영인

블로그는 읽기 비중이 극단적으로 높고 콘텐츠 변경이 드문 서비스입니다. 그러나 서버 캐시 계층 없이 구성하면 동일 게시글을 반복 방문할 때도 요청마다 Supabase DB에 직접 접근하는 구조가 됩니다.

게시글 상세 페이지는 동일 postId에 대한 읽기가 반복되더라도 매번 DB를 조회했고, 글 목록과 검색은 서버에서 내려주는 초기 데이터와 클라이언트 queryKey가 일치하지 않아 hydration 이후에도 중복 fetch가 발생하는 구조였습니다. 또한 갱신 빈도가 낮은 목록에 주기적 polling이 설정되어 있어 불필요한 백그라운드 요청이 지속되었습니다.

서버 캐시 계층의 부재와 서버-클라이언트 데이터 흐름의 불일치, 두 가지가 핵심이었습니다.

revalidatePath는 경로 단위로 무효화 범위가 넓어, 댓글 하나가 추가되어도 해당 게시글 페이지 전체가 재생성됩니다. 글 본문·댓글·해시태그·조회수가 독립적으로 무효화되어야 하는 데이터 구조에서는 범위를 제어할 수 없어 기각했습니다.

ISR(revalidate: number)은 주기적으로 콘텐츠가 갱신되는 서비스에 적합하지만, 이 블로그는 작성·수정이라는 mutation 이벤트 기반으로 갱신됩니다. TTL이 남아 있는 동안 mutation 직후에도 구버전 스냅샷이 독자에게 노출될 수 있어 정합성을 보장하기 어렵다고 판단했습니다.

Redis 같은 외부 캐시는 세밀한 제어가 가능하지만 추가 인프라 비용과 운영 복잡도가 따릅니다. 개인 블로그 규모에서는 과도한 설계라고 보았습니다.

unstable_cache + revalidateTag 조합을 선택했습니다. TanStack Query가 query factory 패턴으로 key 계층을 설계해 무효화 범위를 제어하듯, Data Cache에도 posts·post-${id}·comments·hashtags 태그 계층을 두어 mutation 종류에 따라 영향받는 캐시만 선택 무효화할 수 있습니다. Data Cache는 Next.js 서버가 관리하므로 별도 인프라 없이 요청 간 스냅샷을 공유할 수 있습니다. 다만 TTL 내 stale 가능성이 있으므로 revalidateTag를 주 전략으로, TTL은 보조 안전망으로 두기로 했습니다.

클라이언트 측 문제는 두 가지로 진단했습니다. /search가 initialData 방식을, /posts가 prefetchInfiniteQuery 방식을 써서 hydration 계약이 달랐고, 동일한 화면이라도 서버 시드가 클라이언트 TanStack 캐시로 이어지지 않아 중복 fetch가 발생했습니다. 또한 변경이 드문 글 목록에 주기적 polling이 설정되어 있어 실제 갱신과 무관한 반복 요청이 지속됐습니다. 두 문제 모두 mutation 이벤트 후 명시적으로 동기화하는 방식으로 해결할 수 있으므로, 클라이언트 패칭 계약을 단일 방식으로 통일하고 polling을 제거하기로 결정했습니다.

Chrome DevTools Performance·Network·Lighthouse를 병행해 병목을 측정했습니다. JPEG 기준 약 76KB 이미지에 다운로드만 약 2.45s가 소요됐고, LCP 후보 이미지의 Resource Load Delay도 함께 관찰됐습니다. Warm 캐시 상태에서는 체감이 개선됐지만 Cold Start에서는 동일한 지연이 반복됐습니다.

이미지 최적화 방법으로 Next.js 내장 Image Optimization, Cloudflare Images, ImageKit을 검토했습니다.

Next.js 내장 방식은 서버 측 변환이라 트래픽 증가 시 서버 부하·비용이 함께 증가합니다. 또한 위치 지도 이미지의 컨테이너 폭이 뷰포트에 따라 유동하는 구조라, 정적 deviceSizes breakpoint 기반 srcset + sizes 힌트 방식으로는 렌더 시점의 실제 폭에 정확히 맞는 크기를 요청하기 어려워 과다 전송이 발생할 수 있었습니다. Cloudflare Images는 Supabase Storage와의 연동에 별도 파이프라인 구성이 필요해 현재 스택 대비 복잡도 증가가 컸습니다.