[React] SWR은 언제 사용할까? (feat. 리액트에서 반복적인 useEffect 대신 SWR 사용하기)

1. 계기

최근 "리액트에서 반복적인 useEffect 대신 SWR 사용하기"라는 블로그 글을 읽었다. 평소 블로그 프로젝트를 진행하며 useEffect를 자주 사용해 왔고, 데이터 패칭 관련 고민도 많았던 터라 이 주제는 꽤 흥미롭게 다가왔다. 하지만 글을 읽으며 오히려 더 많은 궁금증이 생겼고, ChatGPT에게 여러 질문을 던지며 나만의 정리를 해보기로 했다.

---

2. ChatGPT에게 던졌던 질문들

내가 ChatGPT에게 던졌던 질문들을 나열해 보았다. 크게 SWR을 사용하는 이유, 현재 블로그 프로젝트에 SWR 적용여부, 개발 시 우선 순위 세 가지에 대해 질문해 보았다.

• 반복되는 useEffect를 SWR 대신 커스텀 훅으로 분리해서 사용할 수도 있지 않을까?
  • useSWR을 사용하면서 공통적인 요소들이 반복된다면, 이를 커스텀 훅으로 만드는 것이 더 효율적일까?
  • 언제 useSWR을 사용하는 것이 적절할까? 너무 과도하게 사용해서 오버스택이 되는 경우는 어느 정도일지 궁금하다.
• 현재 블로그 개발 프로젝트를 진행 중인데, 이 프로젝트에서 SWR을 도입하는 것이 적합할까?
  • 좋아요나 댓글 같은 기능은 동작 시 새로 받아온다면 굳이 캐싱이 필요 없을 것 같다. 또한 실시간으로 보여줘야 할 정보도 아닌 것 같은데, 로그인 유저 정보 캐싱에는 SWR을 어떻게 활용할 수 있을까?
  • 그런데 단순히 전역 상태로 관리하는 것과 SWR을 사용하는 것은 어떤 차이가 있을까? 장단점이 궁금하다.
  • 보통 데이터는 서버에서 받아와 여러 컴포넌트에서 사용하기 위해 전역 상태로 관리하는데, 이런 경우에도 SWR을 사용하는 게 좋을까?
  • 일반적인 블로그는 글쓰기를 제외하면 거의 모든 데이터가 서버에서 받아오는 정보다. 전체 목록 불러오기, 필터별 데이터, 카테고리별 목록, 상세 글 내용 등이다. 이런 경우 각 컴포넌트에서 SWR을 쓰는 게 더 나을까? 아니면 굳이 SWR 없이 지역 상태로만 관리하고 페이지를 벗어나면 초기화해도 될까? 자주 방문하는 경우에만 SWR을 쓰는 게 적절한 걸까?
• 그래서 전역 상태 관리는 가장 후순위로 생각하는 편이다. 우선은 지역 상태로 처리하고, 필요하면 SWR을 도입하며, 클라이언트에서만 반드시 공유해야 하는 상태일 때만 전역 상태를 활용하는 것이 좋겠다는 생각이다.

---

3. 질문에 대한 답변

내 질문을 바탕으로 이해하기 쉽게 QnA 형식으로 정리해 보았다.

Q1. 반복적인 useEffect를 커스텀 훅으로 빼는 것과 SWR 사용의 차이는?

A. 커스텀 훅은 로직 재사용에 초점을 맞춘 방식으로, 데이터 패칭, 캐싱, 갱신(revalidate) 등의 동작을 직접 구현해야 한다. 반면 SWR은 이런 네트워크 상태 관리 패턴을 추상화한 고수준 도구로, 캐싱, 자동 재검증, 오류 처리 등을 기본으로 제공한다. 즉, 커스텀 훅은 구현 방법이고, SWR은 완성된 솔루션이다.

Q2. useSWR을 사용할 때 부가 요소가 동일하면 커스텀 훅으로 분리해도 되는가?

A. 그렇다. useSWR 사용 시 fetcher, key 패턴, 공통 옵션(revalidateOnFocus, dedupingInterval 등)이 반복된다면 커스텀 훅으로 추출하는 것이 코드의 가독성과 유지 보수성 측면에서 효과적이다.

Q3. SWR은 언제 사용하는 게 좋고, 얼마나 써야 과하지 않은가?

A. 서버 데이터를 여러 컴포넌트에서 공유하거나, 자동 갱신이 필요한 경우 SWR이 특히 유용하다. 반면, 특정 페이지에서만 일시적으로 사용하는 데이터는 fetch와 지역 상태만으로도 충분할 수 있으며, 이런 경우에는 SWR이 과한 선택일 수 있다.

Q4. 블로그 프로젝트에 SWR이 과연 필요할까?

A. 블로그는 일반적으로 요청-응답 기반의 페이지 구조로 되어 있고, 실시간 갱신이 필요한 데이터가 많지 않다. 따라서 대부분의 경우 단순 fetch와 지역 상태로도 충분하다. 다만 로그인 사용자 정보나 자주 재요청되는 목록 등 일부는 SWR의 캐싱/갱신 기능이 도움이 될 수 있다.

Q5. 로그인 유저 정보를 캐싱할 땐 어떻게 활용할 수 있을까?

A. 로그인 유저 정보는 SWR로 패칭하면서 fallbackData를 활용해 초기 렌더링을 빠르게 하거나, mutate를 통해 로그인/로그아웃 시 즉각적인 UI 반영이 가능하다. 다만 suspense는 아직 실험적 기능이므로 안정성을 고려해 사용할 필요가 있다.

Q6. SWR로 캐싱하는 것과 전역 상태 관리와의 차이는?

A. SWR은 서버 상태를 캐싱하고, 전역 상태는 클라이언트 상태를 공유한다. SWR은 자동 갱신, 의존성 최소화가 장점이고, 전역 상태는 사용자 인터랙션 중심의 UI 상태에 적합하다.

Q7. 서버 데이터를 받아 여러 컴포넌트에서 전역 상태로 사용하는 경우에도 SWR이 나은가?

A. SWR은 동일한 키를 사용하는 한 컴포넌트 간에 데이터를 자동으로 캐싱 및 공유하므로, 서버 데이터를 굳이 전역 상태로 복사해서 관리할 필요는 없다. 하지만 UI 상에서 동기화되어야 하는 상태(예: 필터 값, 탭 선택 등)는 전역 상태로 관리하는 것이 더 자연스러울 수 있다.

Q8. SWR도 상위 컴포넌트에서만 fetch하고 내려보내면 전역 상태랑 다를 게 없지 않나?

A. 맞다. 상위 컴포넌트에서 데이터를 패칭하고 props로 하위에 전달한다면 SWR의 장점(캐싱, 공유, 갱신)을 충분히 활용하지 못하게 된다. SWR의 강점을 살리려면 필요한 컴포넌트에서 직접 호출하고, key 기반 캐싱 구조를 잘 설계하는 것이 중요하다.

Q9. 대부분 서버에서 불러오는 데이터인데 지역 상태, SWR, 전역 상태의 우선순위는?

A.

1. 지역 상태: 해당 컴포넌트에서만 쓰는 데이터
2. SWR: 서버에서 가져오고, 공유되거나 캐싱이 필요한 데이터
3. 전역 상태: 클라이언트 내부에서 공유되는 상태 (예: 선택된 카테고리, 필터 등)

---

4. 결론

• 반복되는 useEffect → 용도에 따라 커스텀 훅 or SWR로 대체
• SWR은 서버에서 자주 가져오는 공유 데이터에 적합 (ex. 로그인 정보, 리스트 등)
• 전역 상태는 클라이언트에서만 쓰는 UI 상태에 적합 (ex. 모달 열림 여부, 필터 상태)
• 모든 데이터는 아래 순서로 판단
  1. 해당 컴포넌트에서만 쓰면 → 지역 상태
  2. 서버에서 가져오고 공유되면 → SWR
  3. 클라이언트에서만 공유되면 → 전역 상태