💡 01. Infinite Queries와 페이지네이션 깊게 파보기

📋 목차

• ☕️ 영철이의 고민: "무한 스크롤, 렌더링이 갈수록 느려져요!"
• 🤔 왜 알아야 하는가: 배열의 함정과 다이어트
• 1. useInfiniteQuery 해부학 (Cursor 기반)
• 2. 데이터 다이어트 끝판왕: select 옵션
• 📝 배운 내용 점검하기 (Quiz)

"영철 님, 무한 스크롤 데이터 배열 5개 이어 붙인다고 프론트 배열 복사(concat)로 연산 다 돌리고 계신가요?"

☕️ 영철이의 고민: "무한 스크롤, 렌더링이 갈수록 느려져요!"

(월요일 오후, 끝없이 내려가는 쇼핑몰 상품 리스트를 보며 한숨 쉬는 영철)

🐣 영철: 리드 님! 저 드디어 커뮤니티 앱 메인 피드에 무한 스크롤을 useQuery로 달았습니다.
페이지 번호(pageState) 1씩 올릴 때마다 기존 배열에 [...old, ...newData] 이렇게 합쳐서 State로 저장하고, 그걸 map 돌려서 그리고 있어요. 근데 데이터가 한 1,000개 넘어가니까 휠 내릴 때마다 렌더링이 턱턱 걸리네요 ㅠㅠ.

🦁 영호: 영철 님, 데이터 패칭이 백그라운드에서 일어날 때마다 1000 + 20 개의 거대한 배열 뭉텅이를 통째로 딥 컴페어(Deep Compare) 돌리고, 그걸 또 로컬 useState 에 복사해서 밀어넣으니까 브라우저 메모리가 터져나가는 겁니다.
무한 스크롤은 useQuery 하나로 배열을 덧대는 게 아니라, useInfiniteQuery 와 select 옵션의 양날 검으로 캐시 포인터만 늘려가는 아주 우아한 아키텍처가 필요합니다.

🤔 왜 알아야 하는가: 배열의 함정과 다이어트

수많은 데이터(예: 트위터 타임라인, 인스타 피드)를 유저에게 한 번에 쏘는 건 서버비의 낭비입니다. 그래서 우리는 Cursor(마지막으로 본 글 번호)나 Page(페이지 번호)를 건네서 20개씩 쪼개 받습니다(Pagination).

문제는 프론트엔드입니다. 계속 받아오는 객체 덩어리들을 어디에 캐싱하고, 어떻게 합칠 것인가?
React Query의 useInfiniteQuery는 이 페이징 스냅샷들을 배열 안의 배열(pages[0], pages[1])로 캐시에 쌓아두고, 다음 페이지(Next Cursor)가 무엇인지 자기 스스로 추적(Tracking)하는 완전 관리형 훅입니다.

또한 여기에 데이터 사이즈를 깎아주는 궁극기 select 옵션이 결합되면, 브라우저가 버릴 데이터는 애초에 캐시 구독 계층에서부터 잘라버릴 수 있습니다.

1. useInfiniteQuery 해부학 (Cursor 기반)

TkDodo의 아티클 #26을 보면, 무한 쿼리는 사실 "페이지별 스냅샷을 담은 2차원 배열"입니다.

// 📝 types.ts
export type Post = { id: number; title: string; content: string };
export type FetchPostsResponse = {
  data: Post[];
  nextCursor: number | null; // 서버에서 "다음 호출은 이 번호부터 해!" 라고 줌
};

가장 기초적이면서 완벽한 TypeScript 기반 무한 쿼리 옵션 객체를 잡아봅시다.

// 📝 hooks/queries/useInfinitePosts.ts
import { useInfiniteQuery } from '@tanstack/react-query';
import axios from 'axios';
import { FetchPostsResponse } from '@/types';
 
export const useInfinitePosts = () => {
  return useInfiniteQuery({
    queryKey: ['posts', 'infinite'],
    // 1️⃣ pageParam: 이게 바로 Next.js의 Cursor입니다. 최초엔 무조건 첫 페이지(0)로 시작.
    queryFn: async ({ pageParam = 0 }) => {
      const res = await axios.get<FetchPostsResponse>(`/posts?cursor=${pageParam}`);
      return res.data;
    },
    // 2️⃣ TypeScript의 위엄: 초기 커서값을 필수로 정의 (v5 기능)
    initialPageParam: 0,
    // 3️⃣ 핵심 마법: 방금 응답받은 데이터(lastPage)를 까보고, 다음 커서가 있으면 리턴!
    getNextPageParam: (lastPage) => lastPage.nextCursor ?? undefined,
  });
};

이제 컴포넌트는 상태 변수(page=1)나 setPage를 들고 있을 필요가 일절 없습니다.
오직 훅이 주는 fetchNextPage() 함수 하나만 호출하면 끝납니다. 화면에 붙일 때는 data.pages.map으로 풀어서 그립니다.

function Feed() {
  const { data, fetchNextPage, hasNextPage, isFetchingNextPage } = useInfinitePosts();
 
  return (
    <div>
      {/* data.pages는 [ {data:[20개], next:1}, {data:[20개], next:2} ] 형태의 2차원 배열이다. */}
      {data?.pages.map((page, index) => (
        <React.Fragment key={index}>
          {page.data.map(post => <PostCard key={post.id} post={post} />)}
        </React.Fragment>
      ))}
 
      <button 
        onClick={() => fetchNextPage()} 
        disabled={!hasNextPage || isFetchingNextPage}
      >
        {isFetchingNextPage ? '불러오는 중...' : hasNextPage ? '더 보기' : '마지막 글입니다'}
      </button>
    </div>
  )
}

🔥 시니어의 조언:
실무에서는 더 보기 버튼 대신 IntersectionObserver 를 이용해 바닥에 닿으면(ViewPort에 들어오면) fetchNextPage() 를 자동으로 발사하게끔 만들어 진짜 무한 스크롤을 완성합니다. (react-intersection-observer 라이브러리 추천)

2. 데이터 다이어트 끝판왕: select 옵션

자, 영철이의 "렌더링 턱턱 걸려요" 문제가 아직 안 풀렸죠?
서버에서 Post 정보로 title, content 만 오면 다행인데... 유저 정보 뭉태기, 좋아요 누른 유저 배열, 이미지 URL 스무 개, 쓸데없는 메타데이터까지 통째로 내려온다면? 1,000개를 모아 그릴 때 브라우저 렌더가 무거워집니다.

게다가 2차원 배열(data.pages.map)을 그리는 것도 은근히 코드 뎁스가 깊어져서 가독성이 떨어집니다.
우리는 React Query의 select 옵션 으로 이 원시 API 데이터를 "내 입맛에 맞는 가벼운 1차원 렌더링 배열"로 깎아버릴 겁니다!

export const useOptimizedInfinitePosts = () => {
  return useInfiniteQuery({
    queryKey: ['posts', 'infinite'],
    queryFn: fetchInfinitePosts,
    initialPageParam: 0,
    getNextPageParam: (lastPage) => lastPage.nextCursor ?? undefined,
    // 🚀 데이터 폭풍 다이어트 & 1차원 배열(Flat) 화!
    select: (data) => ({
      // pages (2차원) 배열을 flatMap으로 1차원으로 쫙 펼침
      // 그리고 무거운 content 다 버리고 딱 id, title만 메모리 렌더로 올려보냄
      pages: data.pages.flatMap((page) => 
        page.data.map((post) => ({
          id: post.id,
          title: post.title,
        }))
      ),
      pageParams: data.pageParams,
    }),
  });
};

select 함수 내부의 연산은 React Query가 내부적으로 극한의 Memoization(캐싱) 을 돌려줍니다.
원본 데이터(캐시 금고)의 데이터 1개라도 바뀌지 않는 이상 절대 flatMap을 다시 연산하지 않아요!
덕분에 컴포넌트 쪽에서는 아무 생각 없이 가벼워진 data.pages.map 만 1차원 배열로 편안하게 즐기면 렌더링 스몰 다이어트가 완성되는 겁니다.

🐣 영철이의 퇴근 일기

와... 오늘 select 옵션에 flatMap 태워서 데이터 가볍게 깎아냈더니, 무한 스크롤 1,000개 내려가던 거 프레임 완전 부드럽게 꽂힌다 미쳤다 진짜 ㅠㅠ

💡 오늘의 교훈: "무한 스크롤은 내가 배열 복사(Local State) 해서 붙이는 게 아니라 useInfiniteQuery에게 커서 포인터만 던져주는 거다! 그리고 데이터가 비대해질 땐 select 과도로 뷰 전용 객체로 날카롭게 조립(Memoize) 시켜서 UI를 구출하자."

예전엔 useEffect 안에서 배열 자르고 붙이고 스크롤 이벤트 바인딩 걸고 아주 스파게티 요리사가 따로 없었는데, 역시 도구가 좋으니까 로직이 컴포넌트 코드 10줄 이내로 압축되네. 무한 스크롤 무서웠는데 이젠 스크롤 바닥 칠 때마다 짜릿하다! 내일 영호 리드 님한테 코드 리뷰 완전 당당히 올려야지 😆.

📝 배운 내용 점검하기 (Quiz)

Q. 영철이가 쇼핑몰 무한 스크롤을 구현하던 중, 특정 상품 하나가 삭제되거나 품절로 상태가 변경되는 액션(useMutation)이 일어났습니다. 이때, 무한 스크롤 형태의 거대한 다차원 배열 데이터 중 딱 그 하나의 상품 상태만 (전체 리패칭 없이) '낙관적 덮어쓰기(setQueryData)'로 고쳐 치려면, TypeScript 환경에서 어떻게 콜백을 작성해야 안전할까요?

• A) queryClient.setQueryData(['posts', 'infinite'], (old) => { ... }) 안에서 1차원 배열로 filter 치고 돌려준다.
• B) 불가능하다. 무한 스크롤 데이터 구조(pages, pageParams)는 너무 복잡해서 부분 수정이 꼬이므로 무조건 invalidateQueries로 전체 초기부터 재통신해야만 한다.
• C) setQueryData 의 old 클로저 안에서 old.pages 배열을 map 순회하여 page 뭉치를 열고, 그 안의 page.data 배열을 한 번 더 map으로 찾아 해당 상품만 수정해준 똑같은 2차원 객체 구조({ pages, pageParams })를 반환한다.

✅ 정답: C

💡 상세 해설:

• 원리 설명: TkDodo 아티클 #26과 #2를 살펴보면 useInfiniteQuery의 캐시 메모리 데이터 원본은 항상 { pages: [...], pageParams: [...] } 형태의 기괴한 객체 덩어리입니다. 수동으로 데이터를 쪼개 수정(setQueryData) 할 때는 반드시 기존의 2차원(페이지 안의 아이템) 배열 구조를 훼손하지 않고 완벽하게 동일한 껍데기로 감싸서 반환해 주어야 React Query가 에러를 뿜지 않습니다.
• 오답 피드백: "영철 님! A번처럼 1차원 쌩 배열로 리턴해버리면 캐시통 구조가 터져서 다음 무한 스크롤 페칭할 때 크래시 에러가 폭발합니다. 구조적 껍데기는 항상 유지해야 해요!"
• 📌 핵심 기억법: 무한 무효화 덮어쓰기(setQueryData) 할 때는, pages 객체 구조 그대로 이중루프(map 안의 map)로 까고 닫기!