Next.js 캐싱 가이드를 읽고 나서, 지금 운영 중인 프로젝트의 캐싱 전략도 한 번 정리해봐야겠다는 생각이 들었습니다.
Next.js App Router의 캐싱은 레이어가 많습니다. Request Memoization, Data Cache, Full Route Cache, Router Cache를 각각 이해하는 것도 중요하지만, 실무에서는 그보다 먼저 물어야 할 질문이 있었습니다.
이 데이터는 모든 사용자에게 같은 값을 보여줘도 되는가?
이 질문에 대한 답에 따라 Next.js 캐시에 올릴 데이터, TanStack Query에 남길 데이터, 클라이언트에서만 요청할 개인화 데이터를 나눌 수 있었습니다.
이 글은 Next.js 캐싱 전체를 깊게 설명하는 글이 아닙니다. 원래 Next 캐싱을 적극적으로 쓰지 않던 프로젝트에 일부 캐싱을 도입하면서, 어떤 기준으로 경계를 나눴는지 정리한 실무 기록입니다.
"결제되었다고 알림이 왔는데, 왜 티켓 보관함에는 티켓이 없나요?"
공연 플랫폼 서비스 운영 중 CS가 접수되었습니다. 로그를 확인해 보니 결제 솔루션(PortOne) 콘솔에는 결제 내역이 있는데, 정작 우리 서비스 DB에는 해당 주문에 대한 상품(ex: 티켓)이 생성되지 않은 상태였습니다.
이 포스팅은 프론트엔드 중심의 결제 처리 방식에서 발생하는 이러한 구조적 취약점을 분석하고, 이를 Webhook 기반의 서버 주도(Server-Driven) 아키텍처로 전환하여 결제 누락 문제를 해결한 과정을 공유합니다.
지난주 유저 CS를 처리하던 중 Firebase 콘솔에서 예상치 못한 요금 폭탄을 발견했습니다.
이 서비스는 별도 백엔드 없이 Firebase를 사용 중인데요.
매칭 서비스 특성상 봄이 성수기이기에 유저 및 트래픽이 증가하긴 했지만, 특히 주요 페이지 개편 이후 요금이 비정상적으로 치솟았다는 사실을 알게 됐습니다.
이 문제를 계기로 새로 작성한 코드부터 레거시 코드까지 전수 점검했고, 결과적으로 현재까지 Firebase 비용을 기존 대비 80% 이상 절감할 수 있었습니다.
이 글에서는 그 과정을 공유합니다.
이 글에서는 TanStack React Query에서 쿼리 키(queryKey)를 효율적이고 안전하게 관리하기 위해 사용하는 쿼리 키 팩토리(QueryKey factory) 패턴에 대해 살펴보고, TanStack React Query v5에서 도입된 queryOptions를 활용하여 쿼리키와 쿼리를 통합하여 관리하는 쿼리 팩토리(Query factory) 에 대해 알아봅니다.
SWR, React-query 같은 data fetching 라이브러리들은 기본적으로 fetch한 데이터에 대한 캐싱 기능을 제공한다.
이 포스팅에서는 서버에서 받아온 데이터에 대한 캐싱 과정을 라이브러리 없이 직접 구현해보면서 이해해본다.