데이터 관리의 복잡성을 해결하고 사용자 경험을 혁신하는 Stale-while-revalidate(SWR) 전략에 대해 깊이 탐구합니다.
💡 왜 데이터 '신선도'와 '속도'는 양립할 수 없을까?
프론트엔드 개발을 하면서 가장 골치 아픈 문제 중 하나는
데이터 동기화와 성능 사이의 균형을
맞추는 것입니다.
데이터가 항상 최신 상태이기를 바라지만, 매번 서버에서 데이터를 가져오는
것은 네트워크 지연을 유발합니다.
반대로, 성능을 위해 캐시(Cache)에 의존하면 사용자가
오래된(Stale) 데이터를 보게 될 위험이 생깁니다.
앱이 느리거나, 방금 수정한 내용이
반영되지 않는 경험은 치명적인 사용자 경험(UX) 저하로 이어집니다.
이러한 딜레마를 해결하기 위해 등장한 혁신적인 캐싱 전략이 바로
Stale-while-revalidate(SWR)입니다.
React Query(현재는 TanStack Query)는 이 SWR 패턴을 구현하여 프론트엔드
개발 방식을 근본적으로 변화시켰습니다.
🧠 SWR의 핵심 원리: '낡았지만 괜찮아' 철학
SWR은 HTTP 캐싱에서 영감을 받은 패턴으로, 그 이름에 모든 원리가 담겨
있습니다.
'Stale-while-revalidate'는 직역하면
'낡은 데이터를 보여주는 동안
재검증을 한다'는 의미입니다.
이는 단순한 캐싱을 넘어, 데이터 신선도와
로딩 속도를 동시에 최적화하는 데 목표를 둡니다.
✨ SWR의 3단계 작동 메커니즘
- Stale (낡은 데이터 제공): 사용자에게 가장 먼저 캐시된 데이터를 즉시 보여주어 로딩 시간을 0에 가깝게 만듭니다. (빠른 응답)
- While (동시에 백그라운드 재검증): 낡은 데이터를 화면에 띄운 동시에, 백그라운드에서 서버에 최신 데이터 요청을 보냅니다. (데이터 신선도 확보 시도)
- Revalidate (데이터 갱신): 서버로부터 새로운 데이터가 도착하면, 자동으로 캐시를 업데이트하고 화면을 부드럽게 갱신합니다. (최신 데이터 반영)
이 패턴 덕분에 사용자는 데이터가 로드될 때까지 빈 화면을 보거나
스피너(로딩 아이콘)를 오래 보지 않습니다.
대부분의 경우, 낡은 데이터라도 최신 데이터와 크게 다르지 않기 때문에
사용자 경험은 매우 매끄럽게 유지됩니다.
데이터 상태의 4가지 전환
React Query는 SWR 패턴을 구현하며 데이터에 4가지 상태를 부여하여 복잡한
캐싱 로직을 단순화합니다.
| 상태 | 설명 | 개발 관점에서의 의미 |
|---|---|---|
| Fetching | 현재 서버에서 데이터를 가져오는 중 |
isLoading 또는 isFetching 상태
|
| Fresh | 가장 최근에 가져온, 매우 신선한 데이터 | 재검증(Revalidation)이 필요 없는 상태 |
| Stale | 재검증이 필요한, 낡은 데이터 | SWR이 작동하며 백그라운드에서 Fetching을 시작하는 상태 |
| Inactive | 사용되지 않고 캐시에 저장된 데이터 | 일정 시간이 지나면 Garbage Collected되어 사라짐 |
🚀 SWR이 기존 캐싱 방식보다 우월한 이유
기존의 전통적인 캐싱 방식은 개발자가 수동으로 데이터를 갱신하거나, 특정
시간(TTL: Time To Live)이 지난 후에만 갱신하는 방식을 주로
사용했습니다.
이는 개발 복잡도를 높이고, 사용자가
데이터 불일치를 경험할 가능성을 높였습니다.
❌ 전통적인 캐싱의 문제점
- 개발자 수동 개입: 데이터 변경 시마다 캐시를 무효화하는 로직을 직접 작성해야 합니다.
- UX 저하: 캐시 만료 시, 다음 Fetching이 완료될 때까지 빈 화면을 보여줄 수밖에 없습니다.
- 과도한 Fetching: TTL이 너무 짧으면 서버 부하가 증가합니다.
✅ SWR 전략의 장점
- 자동화된 재검증: 캐싱, 동기화, 에러 처리 로직 대부분을 React Query가 처리합니다.
- 즉각적인 응답: 캐시된 데이터를 즉시 보여주어 사용자 경험(UX)이 극대화됩니다.
- 데이터 신뢰성: 백그라운드 재검증을 통해 데이터의 신선도를 상시 보장합니다.
SWR 전략의 가장 큰 혁신은 'Optimistic UI (낙관적 UI)'
패턴을 적용하기 쉽게 만든다는 점입니다.
데이터가 변경될 것으로 '낙관'하고, 즉시 UI를 업데이트한 뒤 백그라운드에서
실제 서버 변경을 기다리는 방식으로, 사용자는 기다림 없이 즉각적인 피드백을
받습니다.
⚙️ React Query에서 SWR을 활용하는 방법
React Query(TanStack Query)는 $SWR$ 패턴을 useQuery 훅(Hook)
하나로 매우 쉽게 구현합니다.
여기에는 SWR 작동 방식을 결정하는 주요 옵션들이 있습니다.
useQuery의 핵심 설정 (Stale Time & Cache Time)
✅ Stale Time (staleTime)
데이터가 'Fresh' 상태를 유지하는 시간입니다.
이 시간 동안은 React Query가 캐시된 데이터를
신선한 것으로 간주하여, 컴포넌트가 다시 마운트되거나
윈도우 포커스가 돌아와도 서버에 재요청을 보내지 않습니다.
기본값은 0밀리초(ms)로, 데이터를 가져오자마자 바로
Stale 상태가 됩니다.
⏳ Cache Time (cacheTime)
데이터가 'Inactive' 상태로 남아있는 시간입니다. 즉,
컴포넌트에서 사용되지 않아도 캐시에 보존되는
시간입니다.
이 시간이 지나면 캐시에서 데이터가 완전히 삭제(Garbage
Collected)됩니다.
기본값은 5분($300,000$ms)이며, 보통 이 값은 변경하지 않는 것을
권장합니다.
staleTime을 설정하는 것이 SWR 전략에서 가장
중요합니다.
예를 들어, staleTime: 60 * 1000 (1분)으로 설정하면, 1분
동안은 아무리 컴포넌트가 리렌더링 되어도 서버 요청 없이 캐시된 데이터를
빠르게 보여줍니다.
1분 후에 해당 데이터가 필요해지면, 캐시 데이터를 보여주고 백그라운드
재검증을 시작합니다. 이것이 바로 SWR의 핵심
동작입니다.
staleTime을 길게 설정하면 서버 부하를 줄일 수 있지만, 그만큼
최신 데이터 반영이 지연될 수 있습니다. 사용자에게
실시간으로 중요한 데이터(ex. 주식 가격, 채팅 목록)는
staleTime을 짧게, 변동이 적은 데이터(ex. 사용자 프로필, 설정
정보)는 길게 설정하는 유연함이 필요합니다.🎉 SWR 전략으로 개발 생산성 높이기
React Query의 Stale-while-revalidate 전략은 프론트엔드
개발자가 직면하는 데이터 관리의 복잡성을 획기적으로 낮춰줍니다.
이 전략을 통해 우리는 더 이상 수동적인 캐시 무효화나 지루한 로딩 상태
관리에 시간을 낭비할 필요가 없습니다.
- 1. 데이터 요청 시: 캐시된 낡은(Stale) 데이터를 즉시 보여줍니다. (속도 확보)
- 2. 동시에: 백그라운드에서 서버에 최신 데이터를 요청합니다. (신선도 확보)
- 3. 최신 데이터 수신 시: 화면을 자동으로 갱신합니다. (최고의 UX)
다음 단계 실천 가이드
SWR의 개념을 이해하셨다면, 이제 실제 React 프로젝트에 React Query를
도입하여 useQuery 훅의 staleTime 옵션을 다양하게
설정해보는 실습을 진행해보세요.
이는 프론트엔드 성능 최적화에 대한 깊은 이해로 이어질
것입니다.
댓글 쓰기