07. 📡 서버 상태 관리와 캐싱 전략 마스터

📌 이 면접 항목의 목표

⏱️ 예상 읽기 시간: 24분 (핵심 요약: 12분)

🗺️ 이 챕터의 흐름
[개념 사전] → [질문 1: 클라이언트 상태 vs 서버 상태] → [질문 2: 캐싱 및 신선도 관리] → [실전 변형 질문]

🎯 이 챕터를 다 읽으면 할 수 있는 것

• 왜 서버 데이터를 전역 상태 라이브러리(Zustand 등)에 저장하면 안 되는지 설명합니다.
• Stale-While-Revalidate 전략이 사용자 경험을 어떻게 개선하는지 이해합니다.
• 무한 스크롤, 낙관적 업데이트 등 복잡한 비동기 패턴의 구현 원리를 마스터합니다.

📚 핵심 개념 사전 (Concept Glossary)

1. 서버 상태 (Server State)

내가 소유하지 않은, 원격지의 DB에 저장된 데이터입니다. 언제든 다른 사용자에 의해 바뀔 수 있으며(Out-of-sync), 가져오는 데 시간이 걸리는 비동기적 특성을 가집니다.

2. SWR (Stale-While-Revalidate)

"상한(Stale) 데이터를 먼저 보여주되, 그동안 서버에서 신선한(Fresh) 데이터를 다시 가져와(Revalidate) 조용히 교체한다"는 캐싱 전략입니다. 사용자에게 '대기 시간 0'의 경험을 줍니다.

3. 낙관적 업데이트 (Optimistic Update)

서버의 응답이 오기도 전에 미리 UI를 '성공'한 것처럼 바꾸는 기법입니다. 좋아요 버튼이나 댓글 작성처럼 빠르기 차이가 UX에 큰 영향을 주는 기능에 필수적입니다.

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 🐣 영철 (후반 초입): "영호 님! '영수네 게시판' 데이터를 Redux에 저장하고 관리하느라 loading, error, success 상태 변수가 계속 늘어납니다. 서버 데이터와 UI 상태를 같은 방식으로 다뤄도 되는지 헷갈려요."
• 🦁 영호 (리드): "영철 님, 서버 데이터는 우리가 소유한 상태라기보다 서버의 원격 스냅샷입니다. 우리 앱 상태에 무리하게 맞추기보다 캐시, 신선도, 재검증을 다루는 도구에 맡기고 컴포넌트는 그 결과를 구독하게 만들어 봅시다."

면접 질문 1. 클라이언트 상태(Client State)와 서버 상태(Server State)를 명확히 구분해야 하는 이유는 무엇인가요?

🎯 출제 의도

데이터의 소유권과 생명주기를 이해하고 있는지 확인합니다. 이를 구분하지 못하면 불필요한 보일러플레이트 코드와 데이터 불일치(Data Inconsistency) 버그에 시달리게 됩니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 모든 API 응답을 클라이언트 전역 스토어에 직접 넣고 있습니다.

// 🐣 영철: "유저 목록도 전역 상태니까 Redux에 저장해야지!"
function Users() {
  const dispatch = useDispatch();
  const { data, isLoading } = useSelector(state => state.users);
 
  useEffect(() => {
    dispatch(fetchUsers()); // ⚠️ 로딩, 에러, 캐시 무효화 로직을 직접 다 구현해야 함
  }, []);
 
  // ⚠️ 문제: 다른 탭에서 유저가 추가되어도 이 앱은 알 방법이 없음 (Outdated)
}

🦁 영호의 리뷰 포인트
"영철 님, 유저 목록은 우리 앱이 주인이 아니에요. 서버가 주인이죠. 데이터가 바뀌면 서버가 알려주거나 우리가 다시 물어봐야 합니다. 클라이언트 상태(다크모드 여부 등)와는 완전히 다른 생태계예요."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드는 React Query를 사용해 선언적으로 서버 데이터를 다루는 법을 보여줍니다.

// 🦁 영호: "데이터 페칭은 '명령'이 아니라 '선언'입니다."
 
function Users() {
  // ✅ 로딩, 에러, 데이터, 신선도 체크까지 한 줄로 해결
  const { data, isLoading, error } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
    staleTime: 1000 * 60 * 5, // 5분 동안은 신선한 데이터로 간주 (캐시 활용)
  });
 
  if (isLoading) return <Spinner />;
  return <div>{data.map(user => <div key={user.id}>{user.name}</div>)}</div>;
}

이 코드는 데이터를 "가져오라"고 명령하기보다 ['users']라는 키의 서버 스냅샷을 구독한다고 선언합니다. 같은 키를 쓰는 다른 컴포넌트는 캐시와 진행 중인 요청을 공유하므로 로딩, 에러, 중복 요청 처리를 매번 다시 만들 필요가 줄어듭니다.

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "서버 상태는 API로 가져오는 데이터고, 클라이언트 상태는 UI용 데이터입니다. 서버 데이터는 로딩 처리가 필요합니다."
• Level 2 (Senior): "소유권(Ownership)의 차이를 설명합니다. 서버 상태는 비동기적이고 동기화가 필요하며 여러 사용자가 공유한다는 점을 지적합니다. 이를 위해 캐싱, 중복 요청 방지, 백그라운드 업데이트 등이 필요함을 강조합니다."
• Level 3 (Specialist): "서버 상태 관리가 복잡한 비즈니스 애플리케이션에서 어떻게 'SSOT(Single Source of Truth)' 문제를 해결하는지 분석합니다. 서버 상태 라이브러리가 리액트의 '선언적 UI' 패러다임과 어떻게 일치하는지, 그리고 이로 인해 전역 상태 라이브러리의 역할이 '순수 UI 상태'로만 축소되는 아키텍처적 우아함을 설명합니다."

면접 질문 2. staleTime과 gcTime의 차이를 설명하고, 이를 활용한 최적의 캐시 전략을 제시해 보세요.

🎯 출제 의도

React Query의 핵심 매커니즘인 '신선도'와 '메모리 관리'를 정확히 이해하고 상황에 맞게 튜닝할 수 있는지 확인합니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 모든 API 요청에 대해 기본 설정만 쓰고 있습니다.

// 🐣 영철: "설정값이 너무 많아서 그냥 기본으로 써요. 알아서 잘 되겠죠?"
const { data } = useQuery({ queryKey: ['posts'], queryFn: fetchPosts });
// ⚠️ 문제: 페이지를 잠깐 나갔다 올 때마다 매번 API 재호출 발생 (서버 부하)

🦁 영호의 리뷰 포인트
"영철 님, 게시글 목록은 보통 1초마다 바뀌지 않습니다. 그런데 매번 서버에 다시 물으면 사용자도 서버도 불필요한 비용을 치러요. 데이터를 얼마나 '신선(Fresh)'하다고 믿어줄지 결정하는 게 시니어의 세심함입니다."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드가 상황에 따른 캐시 설정법을 전수합니다.

// 🦁 영호: "데이터의 성격에 따라 유통기한을 정하세요."
 
// 1. 공지사항: 잘 안 변함 -> staleTime을 길게 (예: 1시간)
const noticeQuery = useQuery({
  queryKey: ['notices'],
  queryFn: fetchNotices,
  staleTime: 1000 * 60 * 60,
});
 
// 2. 실시간 채팅: 계속 변함 -> staleTime은 0 (마운트/포커스 등에서 재검증)
const chatQuery = useQuery({
  queryKey: ['chats'],
  queryFn: fetchChats,
  staleTime: 0,
});
 
// 💡 팁: gcTime은 사용되지 않는 쿼리 캐시가 메모리에 남아있는 시간입니다.
// 보통 staleTime보다 길게 두어, 잠깐 이동했다 돌아왔을 때 캐시를 재사용합니다.

TanStack Query v5에서는 예전 cacheTime 이름이 gcTime으로 바뀌었습니다. staleTime은 "다시 물어볼 필요가 있는가"를 결정하고, gcTime은 "아무도 구독하지 않는 데이터를 언제 메모리에서 치울 것인가"를 결정합니다.

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "staleTime은 데이터가 신선한 시간이고, gcTime은 사용하지 않는 캐시가 메모리에 남아있는 시간입니다."
• Level 2 (Senior): "데이터가 'stale'해져도 즉시 사라지지 않고, 백그라운드 재검증(Revalidation)의 대상이 됨을 설명합니다. gcTime은 가비지 컬렉터가 작동하기 전까지의 여유 시간임을 명확히 구분합니다."
• Level 3 (Specialist): "사용자 경험 관점에서 staleTime을 길게 두고 mutation 이후 invalidateQueries를 수동으로 호출하는 '정적 데이터 관리' 전략을 설명합니다. 또는 prefetchQuery와 결합하여 다음 페이지 데이터를 미리 캐시에 넣어 전환 지연을 줄이는 기법을 제시합니다."

🔗 실전 변형 질문 (Related Variations)

면접 질문 72. 쿼리 무효화(Invalidation)와 수동 업데이트(SetQueryData)의 차이점은 무엇인가요?

• 🎯 출제 의도: 데이터 일관성을 지키는 두 가지 전략의 트레이드오프를 이해하는지 확인합니다.
• 💡 핵심 원리 & 답변: Invalidate는 "이 데이터는 상했으니 서버에서 다시 받아와!"라고 선언하는 안전한 방식이며, 항상 최신 데이터를 보장합니다. 반면 SetQueryData는 서버 응답 전에 캐시를 직접 수정하는 '낙관적 업데이트'에 주로 쓰이며, 네트워크 요청을 한 번 아낄 수 있어 훨씬 빠릅니다. 하지만 직접 데이터를 조심스럽게 조작해야 하므로 복잡도가 높고 실패 시 롤백 로직이 필수입니다.

면접 질문 85. 무한 스크롤(Infinite Scroll) 기능을 구현할 때 고려해야 할 핵심 성능 포인트는?

• 🎯 출제 의도: 데이터 양이 늘어날 때 생기는 브라우저의 한계와 비동기 처리를 조화시키는 능력을 확인합니다.
• 💡 핵심 원리 & 답변: 첫째, useInfiniteQuery를 사용하여 pageParam 단위로 데이터를 관리하고 이전/다음 페이지를 매끄럽게 페칭해야 합니다. 둘째, 렌더링 최적화입니다. 데이터가 많아지면 DOM 노드가 무거워지므로 Intersection Observer는 물론, 화면 밖의 노드를 제거하는 '윈도잉(Windowing/Virtualization)' 기법을 병행해야 합니다. 마지막으로 스크롤 이벤트 디바운싱이나 쓰로틀링을 통해 불필요한 API 요청이 연속으로 발생하지 않게 해야 합니다.

면접 질문 91. 여러 컴포넌트에서 같은 Query를 호출할 때, 네트워크 요청이 한 번만 발생하는 원리는?

• 🎯 출제 의도: 라이브러리의 내부 캐싱 레이어와 요청 병합(Request Deduplication) 메커니즘을 이해하고 있는지 확인합니다.
• 💡 핵심 원리 & 답변: React Query는 QueryClient라는 전역 저장소를 가지고 있으며, 모든 쿼리는 고유한 QueryKey를 식별자로 사용합니다. 동일한 키로 여러 번 요청이 들어오면, 라이브러리는 현재 '진행 중인 요청(Pending Promise)'이 있는지 확인하고 있다면 별도의 네트워크 호출 없이 해당 프로미스를 공유합니다. 이미 완료된 데이터라면 캐시된 값을 즉시 반환하며 staleTime에 따라 백그라운드 업데이트 여부를 결정합니다. 이를 통해 컴포넌트가 파편화되어 있어도 데이터 일관성을 유지할 수 있습니다.

📝 마무리 퀴즈

Q1. 서버 데이터를 Zustand 같은 클라이언트 전역 상태에 그대로 넣으면 왜 문제가 되기 쉬운가요?

✅ 정답: 서버 데이터의 소유권, 신선도, 재검증, 중복 요청, 에러/로딩 상태를 직접 관리해야 하기 때문

💡 상세 해설:

• 원리 설명: 서버 상태는 클라이언트가 원본을 소유하지 않습니다. 그래서 staleTime, refetch, invalidation, retry, background update 같은 캐시 정책으로 다루는 편이 안전합니다.
• 오답 피드백: "전역에서 쓰니까 전역 store"라는 판단은 데이터의 소유권과 신선도 문제를 놓칩니다.
• 📌 핵심 기억법: 서버 데이터는 저장보다 동기화가 핵심입니다.

Q2. staleTime과 gcTime을 구분해서 설명해야 하는 이유는 무엇인가요?

✅ 정답: staleTime은 데이터가 신선하다고 보는 시간이고, gcTime은 사용하지 않는 캐시를 메모리에 보관하는 시간이라 목적이 다르기 때문

💡 상세 해설:

• 원리 설명: 두 값을 혼동하면 너무 자주 refetch되거나, 반대로 오래된 데이터가 오래 보이는 문제가 생깁니다. 면접에서는 사용자 경험과 네트워크 비용 사이의 균형까지 말해야 합니다.
• 오답 피드백: 둘 다 "캐시 시간"이라고만 답하면 실제 설정 의도를 설명하지 못합니다.
• 📌 핵심 기억법: 신선도와 보관 기간은 다른 축입니다.

Q3. 영철이의 테스트 타임: 댓글 작성 mutation 성공 후 가장 자연스러운 캐시 처리 방식은 무엇인가요?

✅ 정답: 관련 query key를 무효화하거나 optimistic update를 적용해 목록과 상세 화면의 일관성을 회복한다

💡 상세 해설:

• 원리 설명: mutation은 서버에 변화를 만들고, 기존 캐시는 그 순간 낡아질 수 있습니다. 어떤 key가 영향을 받는지 설계해야 사용자는 일관된 화면을 봅니다.
• 오답 피드백: window.location.reload()는 문제를 숨길 뿐, 캐시 전략을 설계한 답변이 아닙니다.
• 📌 핵심 기억법: mutation 후에는 어떤 캐시가 낡았는지 묻습니다.

🐣 영철이의 퇴근 일기

오늘은 서버 데이터를 내 마음대로 소유한 것처럼 다루던 습관을 버렸다. 영수네 댓글 목록이 새로고침해야만 맞아 보였던 이유도 결국 캐시를 설계하지 않고 값만 저장하려 했기 때문이었다.

💡 "서버 상태는 들고 있는 값이 아니라, 서버와 계속 맞춰야 하는 약속이다."

다음부터는 API 응답을 store에 넣기 전에 "이 데이터의 원본은 어디고, 언제 낡으며, 어떤 mutation이 영향을 주지?"를 먼저 적어봐야겠다. 이제 영철이 조금씩 클라이언트 코드 바깥의 시간까지 보게 되는 것 같다.