SWR(Stale-While-Revalidate)의 개념

https://swr.vercel.app/ko

데이터 가져오기를 위한 React Hooks – SWR

 

SWR란?

SWR란 Stale-While-Revalidate의 약자로, 먼저 캐시된 오래된 데이터(stale)를 즉시 보여주고 배경에서 최신 데이터로 재검증(revalidate)하여 갱신하는 데이터 패칭 전략을 말한다. 사용자는 로딩 스피너 대신 즉시 콘텐츠를 보게 되고, 백그라운드에서 네트워크 요청이 완료되면 화면이 최신 상태로 바뀐다. 웹 성능과 사용자 경험을 동시에 개선하는 전략이라 할 수 있다.

뜻 풀의

• Stale → 오래된, 신선하지 않은 데이터
• While → ~하는 동안
• Revalidate → 다시 검증하다, 최신으로 갱신하다

 

SWR의 핵심 아이디어

• 즉시성: 캐시에 데이터가 있으면 지연 없이 먼저 화면에 그린다.
• 정합성: 그와 동시에 네트워크로 최신 데이터를 받아 캐시와 UI를 갱신한다.
• 표준화된 캐싱 흐름: 키(key) 기반으로 데이터와 요청 상태를 관리하여 동시 요청 중복을 줄인다.
• 자동 갱신: 포커스 복귀, 네트워크 재연결, 인터벌 설정 등 이벤트 기반으로 최신 상태를 유지한다.

동작 흐름

1. 요청 키로 캐시를 조회 및 캐시가 있으면 즉시 화면에 표시한다.
2. 동시에 네트워크에 최신 데이터를 요청한다.
3. 응답이 오면 캐시와 화면을 최신 데이터로 교체한다.
4. 포커스 복귀나 재연결 시 같은 키의 데이터를 자동 재검증한다.

간단한 사용 예시 (React)

import useSWR from "swr";

const fetcher = (url) => fetch(url).then((res) => res.json());

export default function Profile() {
  const { data, error, isLoading, mutate } = useSWR("/api/user", fetcher, {
    revalidateOnFocus: true,       // 탭에 돌아오면 재검증한다.
    dedupingInterval: 2000         // 중복 요청을 2초 내에는 합친다.
  });

  if (error) return <p>에러가 발생했다</p>;
  if (!data && isLoading) return <p>로딩 중이다</p>;

  return (
    <div>
      <h3>프로필</h3>
      <p>이름: {data?.name}</p>
      <button onClick={() => mutate()}>새로고침</button>
    </div>
  );
}

SWR의 장점

•  빠른 체감 속도
  •  캐시 데이터를 즉시 보여주므로 첫 화면에서 로딩 스피너 노출을 최소화한다.
  • 사용자는 콘텐츠가 바로 보이기 때문에 체감 성능이 높아진다.
• 자동 최신화
  • 포커스 복귀, 네트워크 재연결, 인터벌 등으로 데이터를 자동 재검증한다.
  • 별도의 새로고침 없이도 최신 상태를 유지할 수 있다.
• 중복 요청 방지
  • 동일 키의 동시 요청을 dedupe하여 불필요한 네트워크 트래픽을 줄인다.
  • 이는 서버 비용 절감과 응답 안정성 향상에 도움이 된다.
• 낙관적 업데이트와 오프라인 친화
  • mutate를 이용해 낙관적 업데이트를 수행하면 UI가 즉시 반영된다.
  • 이후 서버 응답이 오면 실제 결과로 조정되며, 캐시 기반 구조 덕분에 오프라인 환경에서도 비교적 강하다.

SWR의 단점

• 완벽한 일관성 보장은 어렵다
  • 처음 표시되는 데이터는 잠정적(stale)일 수 있다.
  • 강한 정합성이 필요한 화면이라면 재검증 완료 전까지의 표시 전략을 별도로 설계해야 한다.
• 캐시 복잡도
  • 키 설계, 무효화 범위, 의존성 관계를 신중히 설계하지 않으면 문제가 발생할 수 있다. (중복 캐시, 요청 시점을 잘못 설정했을 때 에러)
  • 갱신 누락이나 불필요한 재검증으로 이어질 수 있다.
• - 메모리 사용 증가
  • 광범위한 캐시는 메모리 사용량을 늘린다.
  • 오래된 항목 정리(Garbage Collection)나 TTL(Time To Live)을 적절히 설정해야 효율적인 관리가 가능하다.

키 설계 전략

• 쿼리 파라미터까지 포함한 정규화: /api/posts?page=2&q=react처럼 요청을 유일하게 식별해야 한다.
• 의존 관계를 키로 표현: 사용자 ID가 로드된 이후에만 /api/users/{id}를 활성화한다.
• null 키로 비활성화: 필수 조건 미충족 시 key = null로 요청을 막아 불필요한 트래픽을 줄인다.

무효화와 갱신 패턴

• 부분 무효화: 특정 키만 mutate(key)로 재검증한다.
• 쓰기 후 재검증: POST/PUT/DELETE 이후 관련 리스트 키를 재검증하여 목록과 상세를 동기화한다.
• 낙관적 UI: mutate(key, newData, false)로 캐시만 먼저 바꾸고, 이후 서버 응답으로 정정한다.

언제 적합한가

• 읽기 중심 UI: 대시보드, 피드, 상세/목록 같이 조회가 많고 최신성이 필요한 화면에 적합하다.
• 반복 방문/탭 전환이 잦은 앱: 포커스 복귀 시 자동 최신화로 UX가 향상된다.
• 오프라인/불안정 네트워크 고려: 캐시 우선 전략이 안정적인 사용자 경험을 제공한다.

주의할 점

• 강한 정합성 요구: 금융 거래 확인 등 잠정 데이터 표시가 위험한 화면은 로딩 정책을 보수적으로 잡아야 한다.
• 대용량 리스트: 무한 스크롤, 가상화와 결합하고 페이지 키를 체계적으로 설계해야 한다.
• 보안/권한: 키에 민감 정보를 넣지 말고, 토큰 만료·갱신 흐름을 명확히 해야 한다.

고급 팁

• 프리패칭: 예상되는 다음 화면의 키를 mutate로 미리 채워 체감 속도를 높인다.
• 키 그룹 무효화: 접두사 규약을 정해 관련 리소스를 한꺼번에 재검증한다. (예: /api/posts*)
• SSR/SSG와의 조합: 초기 HTML에 데이터를 주입해 첫 페인트를 빠르게 하고, 클라이언트에서 SWR로 신선도를 유지한다.

 

 

SWR은 캐시 우선과 배경 재검증을 결합해 속도와 최신성을 동시에 잡는 전략이다. 키 설계, 무효화 범위, 정합성 요구사항만 잘 정리한다면 사용자 경험은 크게 향상된다. 읽기 중심 화면, 반복 방문이 잦은 서비스, 오프라인 친화가 필요한 환경에서 좋을 거 같다. 하지만 강한 정합성이 필요한 화면에서는 로딩 정책과 표시 전략을 보수적으로 설계하는 것이 더 좋을 거 같다. 10개인 줄 알고 봤는데 갑자기 0개되면 화날 수도 있으니까 ㅋ ㅋ  

 

그런데 맨 위에 링크에도 나와있듯이 SWR에 대한 라이브러리가 있는데, 다음 글은 그거에 대해서 파볼 예정이다!