여행 일정의 순서를 드래그로 바꾸는 기능을 react-dnd로 만들며 겪은 것들입니다. drop이 아니라 hover 시점에 정렬하는 이유, 드래그 아이템의 index를 직접 갱신하지 않으면 hover마다 이동이 재실행되어 순서가 튀는 고전 함정, 그리고 이 글을 쓰며 지금 코드에서 새로 찾은 버그 — 삭제 드롭존이 한 번 빨개지면 안 돌아오는 문제 — 까지 정리했습니다.
로그인 풀림, alert 두 번 뜸, 무한 토큰 갱신 루프 — 증상은 달랐지만 전부 한 뿌리였습니다. 401 처리가 화면마다 흩어져 있었거든요. 서버 에러를 enum 4종으로 분류하는 공통 fetch 래퍼로 모은 과정과, 인증 상태를 boolean이 아니라 3-state로 두는 이유, 그리고 지금 코드에 남아 있는 결함까지 정리했습니다.
App Router로 만들었다고 믿었던 프로젝트의 루트 레이아웃에 use client가 붙어 있었습니다. 그 한 줄 때문에 트리 전체가 클라이언트 컴포넌트였고, next/head는 무동작이었으며, QueryClient는 모듈 최상단에서 만들어지고 있었어요. 점수를 올리러 갔다가 경계를 다시 그은 기록입니다.
여행지 목록에서 상세로 들어가면 북마크가 가끔 빈 상태로 보였습니다. isAuthenticated가 null에서 확정되기 전에 요청이 나갔고, 같은 데이터가 캐시 키 두 개로 갈려 있었어요. 고치긴 했는데 지금 다시 보니 원인 진단과 처방이 어긋나 있고 캐시를 통째로 끄는 코드가 남았습니다.
목록↔상세를 오갈 때 스크롤 위치를 기억했다가 복원하는 훅을 만들었던 글입니다. 개고하며 코드를 다시 보니 결함이 다섯 개 보여요 — 전역 단일 키, 저장과 복원의 책임 분열, 스로틀 없는 매 이벤트 저장, "맨 위로 돌아간 것"을 기억 못 하는 조건, 그리고 비동기 목록에서는 복원 타이밍 자체가 문제라는 것까지. 원래 코드와 고친 코드를 나란히 실었습니다.
useInfiniteQuery, useQuery, useSWR로 무한 스크롤을 각각 구현해 비교했습니다. 그런데 실제 프로젝트에 넣어보니 예제 코드 세 개가 전부 문제를 갖고 있었어요. 종료 조건, stale closure, 등호 비교로 바닥을 판정하는 것까지 — 실무에서 걸린 지점을 뒤에 덧붙였습니다.
여행 루트 목록에서 과거 데이터 병합 오류·삭제 데이터 미반영이 반복돼 병합 로직을 재작성했던 기록입니다. 당시엔 해결이라고 썼는데, 이 방식은 결국 뒤집혔어요 — 병합 자체가 문제의 근원이라 react-query를 이 화면에서 걷어내는 것으로 끝났습니다. 중간 기록으로서의 가치가 있어 결말과 함께 남깁니다. (원래 2023-09로 잘못 적혀 있던 날짜를 커밋 기준 2025-01로 교정했습니다.)
무한 스크롤을 붙인 화면마다 이슈가 났는데, 돌아보니 라이브러리 문제가 아니라 전부 "누적된 목록의 주인이 누구인가"가 흐릿해서 생긴 문제였습니다. react-query 캐시와 zustand 스토어가 같은 목록을 두고 싸우다 한쪽을 걷어낸 이야기, 페이지 번호를 컴포넌트가 들고 있다가 캐시에 넘긴 이야기를 정리했습니다.
무한 스크롤 라이브러리를 비교하기 전에 "무한 스크롤을 쓸 것인가"부터 정해야 했습니다. 페이지네이션과의 트레이드오프, 그리고 useInfiniteQuery·useQuery·useSWRInfinite 중 무엇을 고를지의 기준을 정리했습니다. 구현 코드는 별도 글로 뺐습니다.
fetch와 axios의 차이를 정리했던 글입니다. 내장 API·번들 크기·SSR 호환이라는 당시 결론은 지금도 유효하지만, 다시 보니 진짜 이유를 놓치고 있었어요 — Next.js App Router는 fetch 자체를 확장해 캐싱·중복 제거를 얹습니다. 실제 프로젝트에서 fetch를 직접 채택하고 래퍼를 만들며 치른 비용까지 붙여서 업데이트했습니다.