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 상태 변수만 6개를 만들었어요. 비동기 코드 짜다가 늙어버릴 것 같아요... 👴"
• 🦁 영호 ( 리드 ): "영철 님, 서버 데이터는 '상태'가 아니라 '원격 스냅샷'입니다. 그걸 굳이 우리 앱 상태에 억지로 끼워 맞추려니까 힘든 거예요. React Query 같은 도구에게 '관리'를 맡기고 우리는 그저 '구독'만 하면 됩니다."

Q1. 클라이언트 상태(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>;
}

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

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

Q2. staleTime과 cacheTime의 차이를 설명하고, 이를 활용한 최적의 캐시 전략을 제시해 보세요.

🎯 출제 의도

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'],
  staleTime: 1000 * 60 * 60,
});
 
// 2. 실시간 채팅: 계속 변함 -> staleTime은 0 (매번 재검증)
const chatQuery = useQuery({
  queryKey: ['chats'],
  staleTime: 0,
});
 
// 💡 팁: cacheTime은 데이터가 메모리에 남아있는 시간(Unused data)입니다. 
// 보통 staleTime보다 길게 설정하여 하이드레이션 시 이점을 얻습니다.

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

• Level 1 (Junior): "staleTime은 데이터가 신선한 시간이고, cacheTime은 메모리에 남아있는 시간입니다."
• Level 2 (Senior): "데이터가 'stale'해져도 즉시 사라지지 않고, 백그라운드 재검증(Revalidation) 트리거가 됨을 설명합니다. cacheTime은 가비지 컬렉터가 작동하기 전까지의 여유 시간임을 명확히 구분합니다."
• Level 3 (Specialist): "사용자 경험 관점에서 staleTime을 무한(Infinity)으로 두고 Invalidate를 수동으로 조절하는 '정적 데이터 관리' 전략을 설명합니다. 또는 Prefetching과 결합하여 다음 페이지 데이터를 미리 stale 상태로 캐시에 넣어두어 전환 속도를 0으로 만드는 기법을 제시합니다."

🔗 실전 변형 질문 (Related Variations)

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

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

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

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

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

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

🐣 영철이의 복기 일기

오늘 '서버 상태'라는 개념을 배우고 나서 그동안 내가 왜 그렇게 불행(?)했는지 알게 되었다. 서버 데이터를 내 지역 변수처럼 부리려 했던 오만함이 문제였다. 이제 React Query라는 든든한 파트너에게 복잡한 건 맡기고, 나는 사용자에게 어떤 데이터를 얼마나 빨리 보여줄지만 고민하면 된다.

💡 "최고의 전역 상태는 아예 전역 상태에 넣지 않아도 되는 상태다."

내일은 모던 웹의 표준, 'Next.js와 서버 컴포넌트'의 세계로 들어간다. App Router는 또 얼마나 혁명적일지, 영호 님께 제대로 배워봐야지! 🚀💻