김영인 | Frontend Developer

refresh 중복 문제는 두 축으로 나눠 분석했습니다. (1) 여러 API 요청이 동시에 401을 받는 경우, (2) 세션 검증 훅과 인터셉터가 동시에 refresh를 호출하는 경우입니다.

초기에는 인터셉터 큐만으로 문제를 해결할 수 있다고 판단했지만, 세션 검증 훅과의 중복 호출 문제는 남아 진입점 전반을 함께 정리해야 했습니다.

이 문제를 해결하기 위한 접근으로, 인터셉터 레벨에서는 failedQueue + isRefreshing 패턴으로 동시 요청을 제어하고 진입점 간 중복 호출은 refreshViewer 내부 Singleton Promise로 통합하는 방향을 선택했습니다.

하지만 브라우저가 인증 API를 직접 호출하는 구조로 인해 쿠키 전송과 CORS 문제는 남아 있었고, 이를 구조적 한계로 판단했습니다.

이 과정에서 인증 책임을 클라이언트에서 완전히 해결하는 것은 한계가 있다고 보고, 인증 흐름의 일부를 서버 경계로 이동시키는 방향으로 설계를 전환했습니다.

이에 따라 인증 요청을 same-origin으로 수렴시키는 BFF 패턴을 도입했습니다. 브라우저는 `/api/auth/*`만 호출하고, 서버가 백엔드를 호출하도록 인증 경계를 재획정했습니다.

또한 middleware에서 쿠키 존재 여부를 기준으로 접근 제어를 1차 분기하고, 인증 여부 확정은 클라이언트에서 보완하도록 역할을 분리했습니다.

마지막으로 서버 간 요청의 신뢰 경계를 보완하기 위해 내부 경유 요청을 식별하는 별도의 검증 계층을 두기로 결정했습니다.

결과적으로 문제를 동시성·네트워크·보안이 결합된 구조 문제로 재정의했습니다.

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

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 편차를 구조적으로 줄일 수 있다고 판단했습니다.