💡 04. 의존성 있는 쿼리 (Dependent Queries)와 병렬 페칭

📋 목차

• ☕️ 영철이의 고민: "데이터 두 개 가져오는데 로딩이 두 배로 걸려요!"
• 🤔 왜 알아야 하는가: 네트워크 병목 줄이기
• 1. 나쁜 폭포수(Waterfall) 피하기: 병렬 페칭(Parallel Queries)
• 2. 순서가 중요할 때: enabled 옵션의 마법 (Dependent Queries)
• 📝 배운 내용 점검하기 (Quiz)

"영철 님, 유저 정보를 다 불러올 때까지 왜 게시글 목록 API는 시작조차 안 하고 손가락만 빨고 있나요?"

☕️ 영철이의 고민: "데이터 두 개 가져오는데 로딩이 두 배로 걸려요!"

(금요일 오전, 네트워크 탭을 보며 머리를 벅벅 긁는 영철)

🐣 영철: 리드 님! 마이페이지를 만들고 있는데요. 유저 개인정보(fetchUser)랑, 유저가 쓴 게시글 목록(fetchPosts)을 화면에 같이 띄워야 하거든요? 둘 다 useQuery로 잘 짰는데, 로딩이 엄청 오래 걸리네요. 네트워크 탭 보니까 유저 정보 다 받아온 뒤에야 게시글 API가 뒤늦게 출발해요.

🦁 영호: 아주 전형적인 폭포수(Waterfall) 페칭 현상이네요. 영철 님이 두 쿼리를 따로따로 불렀더라도, 컴포넌트 렌더링을 막아(Block) 뒀기 때문에 병렬(Parallel) 처리가 안 된 겁니다. 게다가 반대로, 유저 id가 있어야만 게시글을 가져올 수 있는 의존적인 상황 에서는 아무 때나 쿼리를 날리면 컴파일 에러나 404 에러가 나겠죠.

🐣 영철: 아... 그럼 서로 상관없는 애들은 같이 출발시키고, 서로 꼬인 애들은 순서대로 출발시키려면 어떻게 해야 하죠?!

🤔 왜 알아야 하는가: 네트워크 병목 줄이기

현대의 웹에서 페이지 하나를 띄울 때 API 3~4개를 호출하는 건 기본입니다.
이 3개의 API가 서로 아무 관련이 없는데도 (예: 상단 배너 이미지, 우측 추천 상품, 본문 내용) 순차적으로 하나씩 A 완료 -> B 시작 -> B 완료 -> C 시작 된다면 유저의 인내심은 바닥납니다.

반면, A의 결과물(유저 id)이 있어야만 B(해당 유저의 장바구니)를 가져올 수 있는 엄격한 상황도 있습니다.

React Query는 이 두 가지 딜레마를 병렬 렌더링 과 enabled 옵션 이라는 강력한 무기로 우아하게 해결합니다.

1. 나쁜 폭포수(Waterfall) 피하기: 병렬 페칭(Parallel Queries)

영철이가 짰던 코드를 봅시다.

// ❌ 영철이의 폭포수 코드 (Waterfall)
function MyPage() {
  const { data: user, isLoading: isUserLoading } = useQuery({ queryKey: ['user'], queryFn: fetchUser });
 
  // 여기서 렌더링이 막힌다! (Return 쳐버림)
  if (isUserLoading) return <Spinner />;
 
  // ⚠️ 위쪽에 로딩이 안 끝나면, 이 코드는 아예 실행조차(마운트조차) 안 됩니다.
  const { data: posts, isLoading: isPostsLoading } = useQuery({ queryKey: ['posts'], queryFn: fetchPosts });
 
  // return JSX...
}

이 방식은 useEffect 시절의 잔재입니다. React Query를 쓸 때는 모든 훅을 아무 방해 없이 최상단에 병렬로 깔아두기만 하면 알아서 동시에 출발합니다.

// ✅ 영호 리드의 동시 출발(병렬) 코드
function MyPage() {
  // 1. 둘 다 동시에 네트워크 출발! (넌-블로킹)
  const userQuery = useQuery({ queryKey: ['user'], queryFn: fetchUser });
  const postsQuery = useQuery({ queryKey: ['posts'], queryFn: fetchPosts });
 
  // 2. 두 개 중 하나라도 로딩 중이면 스피너 하나만 띄움
  const isLoading = userQuery.isLoading || postsQuery.isLoading;
  if (isLoading) return <Spinner />;
 
  // 3. 둘 다 무사히 도착 시 화면 렌더!
  return <Profile user={userQuery.data} posts={postsQuery.data} />;
}

🔥 최신 문법: useQueries (동적 병렬 쿼리)
만약 쿼리 개수가 정해져 있지 않고, 배열 요소만큼 동적으로 쿼리를 10개, 100개 쏴야 한다면 useQueries 훅을 사용하세요! (문서 구조가 훨씬 깔끔해집니다.)

2. 순서가 중요할 때: enabled 옵션의 마법 (Dependent Queries)

반대로 생각해봅시다. 이번엔 fetchPosts API가 유저의 userId 파라미터 를 필수로 받아야만 동작하는 API라고 가정해보죠. 위처럼 동시에 출발시키면 userId가 undefined인 상태로 API가 날아가서 400 Bad Request가 뜹니다.

이때 React Query 최고의 치트키인 enabled 옵션을 사용합니다.

function MyProfile() {
  // 1. 유저 정보를 먼저 쏜다.
  const { data: user } = useQuery({
    queryKey: ['user', 'me'],
    queryFn: getUserByToken,
  });
 
  // 2. 게시글은 유저 정보가 있을 때만 쏜다!
  const { data: posts } = useQuery({
    queryKey: ['posts', user?.id], // user.id가 생길 때 동적으로 키가 변함
    queryFn: () => fetchPostsByUser(user!.id),
    // 💡 마법의 한 줄: user.id가 존재할(Truthy) 때만 이 쿼리를 활성화(Enable)하라!
    enabled: !user?.id,
  });
 
  return ( ... );
}

enabled: false 상태인 쿼리는:

1. 마운트되어도 절대 네트워크 요청을 날리지 않습니다.
2. isLoading 상태가 무한정 지속되는 것이 아니라, fetchStatus === 'idle' 상태로 얌전히 대기합니다.
3. 조건(!user?.id)이 true로 뒤바뀌는 순간, 잠에서 깨어나 맹렬하게 데이터를 Fetch 합니다.

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

Q. 영철이는 사용자 검색 창을 만들고 있습니다. 검색어(keyword)가 3글자 미만일 때는 아예 백엔드로 검색 API를 쏘지 않고 싶어 합니다. React Query로 이를 구현할 가장 우아한 방법은 무엇입니까?

• A) queryFn 함수 안에서 if (keyword.length < 3) return [] 처리한다.
• B) useEffect 안에서 3글자가 넘으면 queryClient.prefetchQuery를 쏜다.
• C) useQuery 설정에서 enabled: keyword.length >= 3 을 추가한다.

✅ 정답: C

💡 상세 해설:

• 원리 설명: enabled 옵션은 단지 "순서가 꼬인 쿼리"에만 쓰는 것이 아니라, "특정 조건이 만족될 때만 쿼리를 켜고 쓰겠다" 는 선언적 제어 장치입니다. 검색어 길이가 조건에 부합할 때만 네트워크가 활성화되며, 부합하지 않으면 fetchStatus가 idle로 유지되면서 쓸데없는 네트워크 낭비를 완벽히 차단합니다.
• 오답 피드백: "영철 님, A번처럼 queryFn 안에서 리턴해버리면 네트워크는 안 탈지언정 React Query는 '아 검색 완료됐구나!' 하고 성공(success) 상태로 빈 배열 캐시를 남겨버려요. 아예 시동조차 안 걸리게 하려면 엔진(Query) 밖에서 enabled로 스위치를 내려야 합니다!"
• 📌 핵심 기억법: 쿼리 발사를 참아야 할 땐, 목줄 꽉 쥐는 enabled: 조건식!

📝 마무리 퀴즈

Q1. 유저 정보를 받은 뒤에만 해당 유저의 게시글을 가져와야 합니다. TanStack Query에서 가장 자연스러운 제어 방법은 무엇인가요?

✅ 정답: 두 번째 쿼리의 queryKey에 userId를 포함하고 enabled: !userId로 실행 조건을 둡니다.

💡 상세 해설:
의존성 있는 쿼리는 조건이 준비되기 전에는 대기해야 합니다. queryFn 안에서 if (!userId)로 막는 방식은 실행 조건과 캐시 키가 흐려집니다. 키와 enabled를 함께 설계하면 데이터 흐름이 코드 리뷰에서 바로 보입니다.

Q2. 첫 번째 쿼리가 로딩 중이면 바로 return하는 코드가 병렬 페칭을 망치는 이유는 무엇인가요?

✅ 정답: 아래쪽 쿼리 훅이 실행될 기회를 얻지 못해 네트워크 요청이 순차적으로 밀리는 워터폴이 생기기 때문입니다.

💡 상세 해설:
React 훅은 렌더링 중 호출되어야 합니다. 첫 쿼리 로딩에서 컴포넌트가 조기 반환되면 뒤의 쿼리는 시작조차 못 합니다. 서로 독립인 데이터라면 쿼리를 모두 먼저 선언하고, 렌더링 분기만 나중에 처리해야 합니다.

Q3. 영철이의 테스트 타임: 선택된 태그 ID 배열이 [1, 2, 3]처럼 매번 달라지고, 각 태그 상세를 동시에 가져와야 합니다. 어떤 훅이 적절한가요?

✅ 정답: useQueries로 동적 개수의 쿼리 옵션 배열을 만들어 병렬 실행합니다.

💡 상세 해설:
고정된 2~3개 쿼리는 useQuery를 나란히 둘 수 있지만, 개수가 배열 길이에 따라 달라지면 useQueries가 맞습니다. 핵심은 “의존 관계가 있는가, 독립 병렬인가, 동적 개수인가”를 먼저 나누는 것입니다.

🐣 영철이의 퇴근 일기

와... 나 이때까지 쿼리 하나 불렀다고 그 밑에다 if (isLoading) return 치면서 길막하고 있었네. 다른 API들이 멍 때리고 기다리는 줄도 모르고 프론트엔드 왜 이렇게 느리냐 백엔드 탓만 했다 (영수 님 죄송...)

💡 오늘의 교훈: "서로 상관없는 쿼리는 나란히 써서 브라우저의 동시성(병렬) 성능을 극한으로 뽑아먹고, 앞 데이터 결과가 꼭 필요한 쿼리망 enabled 옵션으로 스마트하게 목줄을 채워두자!"

사실 enabled 옵션 처음 봤을 때 "이건 disabled의 반대말이니까 항상 true겠지?" 하고 지나쳤는데 이게 데이터 페칭의 순서(Dependency) 를 보장해주는 안정적인 도구일 줄이야... 당장 내일 가서 연쇄 페칭(chain fetching) 일어났던 레거시 코드들 다 enabled 하나로 정리해야겠다!