📡 03. Query Lifecycle과 렌더링 최적화

📋 목차

• ☕️ 영철이의 고민: "왜 자꾸 뒤에서 새로고침이 되는 걸까요?"
• 🤔 왜 알아야 하는가: 캐시 서버의 제왕 파악하기
• 1. staleTime vs gcTime: 절대 헷갈리지 않는 비유
  • 🍞 staleTime : 식빵의 신선도 (Data Freshness)
  • 🗑️ gcTime : 냉장고 유통기한 (Garbage Collection Time)
• 2. 엄청난 마법: Structural Sharing과 리렌더링 강어
• 📝 배운 내용 점검하기 (Quiz)

"영철 님, staleTime과 gcTime 값이 똑같은 게 말이 되나요? 캐시를 버리고 있는데 왜 상한 빵을 들고 있죠?"

☕️ 영철이의 고민: "왜 자꾸 뒤에서 새로고침이 되는 걸까요?"

(목요일 오후, 크롬 디버거 네트워크 창을 유심히 들여다보며 당황하는 영철)

🐣 영철: 아니, 리드 님! 방금 제가 React Query 도입하면서 staleTime을 아예 1시간으로 왕창 늘려놨거든요? 서버에 1시간 동안 무조건 안 치고 캐시 쓰겠다고요. 근데 제가 브라우저 탭을 잠깐 다른 데 갔다 왔더니 뒤에서 또 네트워크 API fetch 가 팍팍 찍히고 있어요 ㅠㅠ! 도대체 이유가 뭘까요? 제 설정이 무시당하는 기분이에요.

🦁 영호: 설정이 무시당하는 게 아닙니다. 영철 님이 지금 "신선도(staleTime)" 와 "유통기한(gcTime)" 이라는 두 가지 생명주기를 완벽히 혼동하고 계신 거네요.

게다가 영철 님의 코드에서는 데이터가 하나도 안 바뀌었는데 쓸데없이 전체 목록이 리렌더링(Re-render) 되고 있어요. React Query가 내부적으로 얼마나 무서운 최적화 메커니즘을 돌려주는지 모르고 쓰고 계신 게 분명합니다.

🤔 왜 알아야 하는가: 캐시 서버의 제왕 파악하기

우리가 React Query를 쓰는 건, 네트워크 페칭 횟수를 줄여서 서버 부하를 막고, 유저에게는 0초 로딩 경험을 주기 위함입니다.

그런데 라이프사이클(Lifecycle)을 모르면,

• "난 분명히 캐시를 쓰려고 뒀는데 왜 자꾸 API 콜이 날아갈까?" (불필요한 과금 발생)
• "왜 모달 창만 열었다 닫았는데 리스트 100개가 다 리렌더링 치지?" (성능 하락)
  같은 악순환에 직면합니다.

이 단원에서는 5년 차 실무자가 가장 먼저 물어보는 기술 면접 1순위 질문인 staleTime과 gcTime을 당신의 머릿속에 완벽히 새겨 넣겠습니다.

1. staleTime vs gcTime: 절대 헷갈리지 않는 비유

React Query의 디폴트(기본값)는 엄청나게 보수적이고 영리합니다.
먼저 이걸 외우고 시작하세요. "디폴트 staleTime = 0", "디폴트 gcTime = 5분"

🍞 staleTime : 식빵의 신선도 (Data Freshness)

stale은 '상한, 퀴퀴한' 이라는 뜻입니다.
데이터를 받아오자마자 이 식빵은 얼마나 신선한 상태를 유지할까요?
React Query의 기본값은 0, 즉 받아온 즉시 바로 상한(Stale) 식빵 취급을 합니다.

• 만약 staleTime: 5 * 60 * 1000 (5분) 이라면?
  • 데이터를 받아오고 5분 동안은 완전 신선(Fresh)합니다.
  • 이 기간 동안 유저가 다른 탭을 갔다가 다시 오거나, 새로운 컴포넌트를 열어도 절대로 백그라운드에서 다시 네트워크(Fetch) 요청을 쏘지 않습니다!
  • 영철이가 겪었던 "탭 바꿨는데 자꾸 페치해요!" 는 이 신선도 시간을 제대로 안 줬거나, 0으로 두었기에 발생한 겁니다. (Stale 상태일 땐, 포커스가 돌아오면 무조건 다시 쏠 준비를 하니까요)

🗑️ gcTime : 냉장고 유통기한 (Garbage Collection Time)

이건 cacheTime이라는 이전 v4 시절의 이름에서 gcTime으로 바뀌었습니다. (오해 방지)
이 Query를 바라보는 옵저버(컴포넌트)가 화면에서 한 명도 안 남고 모두 언마운트(Unmount) 되었을 때부터 카운트다운 이 시작됩니다.

• 5분 뒤, (기본값) "아무도 이 신선도 확인 안 한 지 5분이나 됐네? 메모리 낭비다, 이 빵은 쓰레기통(Garbage)으로!" 하고 하드디스크(메모리 캐시)에서 싹 날려버립니다.
• 그 이후 다시 컴포넌트를 띄우면 완전 극초기 하드 로딩(isLoading === true) 상황으로 회귀합니다.

‼️ 시니어의 조언:
실무에서 staleTime을 gcTime보다 같거나 강제로 더 길게 설정하면 파멸을 부릅니다.
"데이터 신선도가 1시간 남았는데, 메모리에서 5분 만에 지워버려라" 라는 기괴한 정책이 되기 때문이죠. 항상 gcTime 이 staleTime 보다 크게 설정해야 캐시 시스템이 온전히 동작합니다.

2. 엄청난 마법: Structural Sharing과 리렌더링 강어

영철(신입): "리드 님! 아까 데이터 안 바뀌면 리렌더링 안 일어난다 하셨는데 그게 무슨 원리인가요? API 백그라운드로 쏘면 무조건 새 객체 받으니까 리액트는 다르다고 판단해서 무조건 새로고침 치는 거 아닌가요?"

🦁 영호: "React Query 내부의 최고 마법 구조인 Structural Sharing (구조적 공유) 을 전혀 모르시는군요."

만약 100개의 리스트가 있습니다. 화면에서 다른 탭 갔다 와서 백그라운드 폴링(isFetching)이 일어났습니다. 서버에서 통째로 100개의 리스트를 새로 내려보냈다고 가정합시다. 이 중, 1번째 글의 제목 딱 하나만 바뀌고 나머지 99개는 완벽히 똑같습니다.

// 백그라운드 페칭 이전 캐시
{ "data": [{ "id": 1, "title": "토끼" }, { "id": 2, "title": "거북이" }] }
 
// 백그라운드 페칭 결과 (새로운 객체 덩어리)
{ "data": [{ "id": 1, "title": "무적 토끼" }, { "id": 2, "title": "거북이" }] }

보통의 useEffect + setState 라면 이 거대한 뭉텅이를 통째로 덮어씌워서 100개 컴포넌트가 전부 미친듯이 번쩍거리며 리렌더링 되었을 겁니다 (Redux도 마찬가지).

하지만 React Query는 그렇지 않습니다.

1. 서버에서 새 응답이 옴.
2. React Query가 아주 깊은 곳에서 방금 온 새 데이터 뭉치와 기존 캐시 메모리를 재빨리 한 겹 한 겹 순회하며 Deep Equal (깊은 비교) 을 수행함.
3. 어라? 2번 거북이 객체는 안의 내용이 자릿수 하나 안 틀리고 똑같네? -> 새로 온 2번 객체를 과감히 버리고, 이전 2번 캐시 메모리의 참조(Reference) 주소를 그대로 재사용합니다.
4. 어? 1번 토끼 객체만 이름이 바뀌었네? -> 얘는 새 주소로 갈아끼움.
5. 결과: React는 참조 주소가 안 바뀐 99개의 컴포넌트에 대해 절대로 리렌더링을 일으키지 않습니다. (최적화 성능 폭발 🌋)

이것이 React Query를 썼을 때, 아무 최적화 안 했는데도 앱이 스무스하고 경이롭게 구동되는 진짜 이유(성능 이점) 입니다.

🐣 영철이의 퇴근 일기

헐... 난 그냥 편하려고 React Query 썼는데, 안에서 Deep Equal 비교해서 참조 주소를 갈아주며 렌더링 최적화까지 해주고 있었다니 소름 돋네;;

💡 오늘의 교훈: "stale(상한 빵 여부 판단)과 gc(쓰레기통 직행 여부) 시간을 확실히 구분! 그리고 100개 데이터 페치 중 1개만 바뀌면 1개만 그려준다! React Query 미친 효율성 최고존엄."

영호 님이 무심하게 툭 던진 말 중에 **"staleTime이랑 gcTime을 세트로 맞출 땐 항상 gcTime을 더 넉넉하게 잡는 걸 명심해라"**라는 게 오늘 젤 크게 와닿았다. 집에 가서 내 플래너 앱 캐시 폴링 기능들 다시 싹 다 잡아봐야겠다. 신난다! 🏃‍♂️💨

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

Q. 다음과 같은 상황에서 영철이가 코드를 짰습니다.

const { data } = useQuery({
  queryKey: ['profiles'],
  queryFn: fetchProfiles,
  staleTime: Infinity,           // "앱을 살아숨쉬는 한 절대 캐시 안 상하게!"
  gcTime: 5 * 60 * 1000,         // 5분 후 캐시 날려버림
});

이 코드로 'profiles' 페이지를 들어갔다가 다른 화면으로 벗어난 지 10분이 지나서 다시 'profiles' 페이지로 돌아왔을 때, 어떤 일이 벌어질까요?

✅ 정답: 지독한 하드 로딩 스피너가 돌며 데이터를 왕창 처음부터 다시 가져오게(Fetch) 됩니다.

💡 상세 해설:

• 원리 설명: staleTime을 영원(Infinity)으로 걸어 놨으니 절대로 다시 네트워크 요청을 안 쏠 것 같죠? 아닙니다. 아무리 신선도를 영원으로 명명해 놨어도, 영철이가 화면을 벗어난(언마운트) 후 gcTime 인 5분이 넘어서는 순간, 캐시 메모리 청소부는 그 데이터를 차가운 쓰레기통으로 갈아버립니다(Garbage collected). 캐시 통 자체가 텅텅 비어버렸는데 staleTime이 무슨 소용이 있겠습니까?
• 오답 피드백: "영철 님, 명심하세요. staleTime이 gcTime을 뛰어넘으면 아무 소용이 없어요! 냉장고 유통기한이 5분인데 식빵 제조일자 유효기간 10년 찍힌 스티커 붙여봐야, 결국 냉장고에서 5분 뒤에 다 버려집니다."
• 📌 핵심 기억법: staleTime (신선도) < gcTime (냉장고보관일자). 이 절대 공식을 반드시 암기하세요!