김영인Frontend Developer

Problem · 왜 이 문제가 중요했는가

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

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

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

Analyze · 어떤 선택을 했는가

`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을 제거하기로 결정했습니다.

Analyze · 어떤 선택을 했는가

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와의 연동에 별도 파이프라인 구성이 필요해 현재 스택 대비 복잡도 증가가 컸습니다.

ImageKit은 커스텀 로더에서 렌더 시점의 실제 폭(`w-{actual_width}`)을 URL 파라미터로 주입할 수 있어 동적 컨테이너에서도 정확한 크기를 요청할 수 있고, URL 파라미터 기반 실시간 변환과 글로벌 Edge 캐싱, Supabase Origin 연동 단순함을 함께 제공합니다. ImageKit으로 결정했습니다.

이미지 경로가 CDN으로 바뀐 뒤에도 검색 카드→모달 전환 시 LCP 타임라인이 늦게 찍히는 문제가 남았습니다. 사용자가 카드를 클릭하기 전, 포인터가 링크 위에 올라오거나 탭하기 직전에 LCP 후보 이미지 요청을 시작해 전환 후 다운로드 대기 시간을 줄이는 방향으로 결정했습니다.

DB 워터폴은 `ToLocationButton`이 이미 `location` prop을 보유하고 있다는 점에서 해법을 찾았습니다. 해당 값을 URL 쿼리 파라미터(`?loc=N`)로 모달에 전달하면, 모달 마운트 시점에 `useSearchParams()`로 동기적으로 location을 읽을 수 있어 Server Action 호출이 불필요해집니다. URL에 직접 접근하는 경우에는 기존 DB 조회 폴백을 유지하기로 결정했습니다.

CDN 도입으로 외부 서비스 의존성이 추가되지만, 서버 부하 분산과 Edge 캐싱 효과로 Cold Start 편차를 구조적으로 줄일 수 있다고 판단했습니다.