Redux 를 걷어낸 이유 :: 마이구미

Redux 의 문제점이 무엇이고 이를 SWR 로 어떻게 해결할 수 있는지 다뤄본다.
Redux 와 SWR 이 무엇인지에 대해서는 다루지 않는다.
Redux - https://github.com/reduxjs/redux
SWR - https://github.com/vercel/swr

 

Redux 는 이미 대중화되어있고 대부분 이미 서비스에 사용되고 있는 라이브러리이기에 본인도 실무에서는 여전히 사용하고 있다.

하지만 개인적으로는 Redux 는 사용하다가 걷어내고 20년 초?부터는 사용하지 않고 있다.

그 대안으로는 SWR 라이브러리를 사용하고 있다.

 

짚고 가고 싶은 게 있다.

"대안" 이라고 말하기가 조금 애매하다고 생각한다.

Redux 와 SWR 은 본질 자체가 다르기 때문에 직접 비교할 순 없고 특정 관점에서 비교해야한다.

왜냐하면 Redux 는 state management 라이브러리이고, SWR 은 data fetching 라이브러리이다.

 

그렇다면 어떤 관점에서 비교해야하는가?

 

크게 Client State, Server State 로 분류하겠다.

 

• Client State 는 모달에 대한 isOpen 와 같은 UI State, 폼 관련된 Form State 그리고 URL State 등을 의미한다.
• Server State 는 API 의 응답값을 의미한다.

 

결론적으로 Server State 관점에서 바라봐야한다.

즉, Redux 는 서버의 응답값을 Global Store 에 저장시켜놓는 용도로 사용하는 상황을 놓고 본다.

이러한 상황에서의 문제점을 알아보자.

 

Redux의 문제점은 무엇인가?

 

첫번째 문제점은 해야할 일이 너무 많다.

 

Redux 자체는 서버의 응답값을 저장해놓는 스토어 역할이 아니라 전역 상태 관리를 위한 라이브러리이다.

Server State 를 저장하는 스토어 기능으로 사용할 수 있는 것일 뿐, 그것을 위해 최적화되어있는 라이브러리는 아니다.

그래서 추가적으로 비동기 작업이 요구되면 redux-thunk, redux-saga 와 같은 미들웨어 라이브러리를 추가해줘야한다.

 

그리고 Redux 는 React 에서 제공하는 기능이 아니기 때문에 Redux 에 대한 새로운 학습이 필요하다.

Redux 를 통해 리스트 API 의 응답값을 활용한다면, 다음과 같은 흐름이 된다.

 

 

그림처럼 위 흐름을 이해해야하고 각각 직접 개발자가 구현해줘야한다.

리스트 API 를 요청하고 응답값을 그리는 과정에 필요한 것들이 너무 많다.

 

우리는 리스트 API 요청과 응답 단 2가지에만 집중하면 된다.

왜냐하면 Get 방식의 API 의 응답값은 대부분 클라이언트에서 ReadOnly 성격을 가진다.

즉, 응답받은 데이터를 가공할 필요도 없고 클라이언트에서 데이터를 변경할 필요도 없다.

요청과 함께 응답 데이터를 View 에 그대로 쓰면 된다. (가공이 필요할 수도 있으나 그건 문제되지 않는다)

결과적으로 action, store, reducer 개념을 알 필요가 없다.

 

 

하지만 Redux 를 활용하면 요청, 응답 이외의 것들을 학습과 이해해야하고 그것을 바탕으로 구현해야한다.

 

그래도 Redux 를 통해 전역 스토어를 활용하면 API 응답 데이터를 캐시 데이터로 활용할 수 있지 않나?

 

그렇다.

이미 가져온 데이터는 서버 요청 횟수를 절감하기 위해 캐시 데이터로 사용할 수 있는 이점이 있다.

 

하지만 다른 문제점이 있다.

두번째 문제점은 캐시 데이터를 사용하기에는 제약이 있다.

 

스토어에 존재하는 캐시 데이터는 구식(stale)인지 최신(fresh)인지 알 수 없다.

최신 데이터로 업데이트 하기 위해서는 다시 action 으로 새로운 API 요청이 필요하다.

하지만 캐시 데이터를 업데이트 하는 시점을 프론트에서 정할 수도 알 수도 없다.

이러한 문제를 해결하기 위해서는 결국 캐시 기능을 벗어나 캐시 기능을 없애는 방향으로 갈 수밖에 없다.

 

SWR 은 이것들을 해결할 수 있는가?

 

새로운 학습없이 기존 흐름을 벗어나지 않고 캐시 기능까지 해결할 수 있는 것이 SWR 이라고 본다.

SWR 는 data fetching 라이브러리로써, 우리가 흔히 사용하는 ajax, axios 를 이용한 비동기 방식 + Hooks 개념만 알고 있으면 된다.

같은 목적이더라도 Redux 스토어를 통해 직접 신경써야했다면, SWR 은 개발자가 신경쓸 부분이 크게 없다.

그 외 폴링, 무한 스크롤 등 유용한 기능들을 많이 제공해주고 있다.

 

상태 관리가 필요하면 어떻게 하는가?

 

처음에 언급했듯이 Server State 관점에서 바라보고 Redux 와 SWR 을 비교했다.

이 질문은 Client State 까지 관여해야한다.

Redux 는 상태 관리 라이브러리로써, Client State, Server State 모두 관여할 수 있다.

하지만 SWR 은 data fetching 라이브러리로써 Client State 관점과는 다른 이야기이다.

 

아무튼 상태 관리가 필요한 경우에는 본인은 Context API 를 사용하고 있다.

복잡해지거나 니즈가 더 확고해진다면 Recoil 을 도입해보면 되지 않을까? 생각하고 있다.

 

---

 

잘못된 이해와 내용이 있다면, 댓글로 알려주시면 잘 습득하겠다.