전역 상태관리 도구들 비교와 분석 정리 1. Redux

 

 

 

처음 동아리에 들어가 스터디를 하며 Redux에 배웠고, 실제로 개발을 하며 더 가벼운 상태 관리 도구가 필요하다고 생각해 Recoil을 사용해 봤고, 스타트업에서 알바를 할 때는 Zustand로 상태 관리를 하라고 했다.

 

상태 관리는 다 거기서 거기 아닌가라고 생각이 들었지만, 상태 관리 도구에 따라 기본 원리와 사용법이 다르다.

 

각각의 상태 관리의 특성들을 이해하고 있어야 상황과 환경에 맞춰 알맞은 상태관리 도구들을 선택할 수 있겠다는 생각이 들어 미리 각 도구들에 대해 이해해놓고자 한다.

 

사실 이미 가볍게 한 번 공부한 적이 있으나 좀 대충 공부했나.. 잘 생각이 나지 않는다. 

(그래서 복습 겸 .. 오블완 겸 ..)

 

https://asmallroom.tistory.com/19

React (Redux , Context API, 클래스형과 함수형)

 

좀 더 심화적으로 공부해야겠다.

 

특히 후의 개발 면접 등을 생각해봤을 때 프로젝트에서 특정 스택을 사용한 이유를 설명할 수 있어야 한다고 생각하니 그 중요성이 더 체감이 된다. 

 

오늘은 첫번째 상태 관리 도구인 Redux이다. 

 

---

Redux

 

https://ko.redux.js.org/introduction/getting-started/

Redux 시작하기 | Redux

 

 

Redux는 내가 처음 접한 상태 관리 도구이다. 하지만 스터디 당시 너무 어렵고 활용하기가 어렵다는 생각이 들어 제대로 이해하지 못했던 도구이기도 하다.

 

Redux란 뭘까?

 

- 자바스크립트 앱을 위한 상태 관리 애플리케이션으로, Redux는 React와 함께 자주 사용되지만 리액트에 한정되지 않고 모든 애플리케이션에서 사용할 수 있다.

 

Redux의 핵심 개념

 

- 스토어 : 애플리케이션의 상태를 담고 있는 객체. 단 하나만 존재하며 애플리케이션의 모든 상태가 저장된다.

- 액션 : 상태를 변화시키기 위한 의도를 나타내는 객체

- 리듀서 : 액션을 받아 상태를 업데이트하는 함수이다. 이전 상태와 액션을 인자로 받아 새로운 상태를 반환하는 순수 함수이다.

- 디스패치 : 액션을 스토어에 전달하는 함수이다. 디스패치된 액션은 리듀서를 통해 상태를 업데이트 하게 된다.

 

=> Redux에서 액션을 보내면, Reducer 함수를 작동시켜, 스토어를 업데이트 한다.

 

아래의 움짤을 통해 이 과정을 쉽게 이해할 수 있다. 

 

 

 

 

아래는 이 글을 쓰면서 발견한 칼럼이다. 이 글을 읽고 Redux를 사용해야하는 규모와 이유, 상황에 대해 이해했다.

 

리덕스가 필요한 이유

Redux가 필요하다는 것을 언제 알 수 있나요?

 

위의 칼럼에서 말하는 Redux를 사용해야하는 순간은 다음과 같다.

 

- 앱 상태의 형태가 여러 컴포넌트에 걸쳐 퍼져있을 때

- 상태를 바꾸는 함수가 여러 컴포넌트에 걸쳐 퍼져있을 때

- 앱 상태의 개요 파악을 위해 마음속에 앱 구조에 대한 모델을 가지고 있어야 할 때

- 여러 단계의 컴포넌트에 걸쳐 같은 props를 전달해야 할 때

- 디버깅할 때 상태 변경을 추적하기가 힘들어졌을 때

 

사실 전역 상태 관리 도구인 만큼 작거나 간단한 앱은 이런 상황을 이르지 않기 때문에 굳이 상태 관리 앱을 적용해 사용할 필요는 없는 것 같다. 특히 Redux는 너무 장황하고 익히는 데 시간이 걸리기 때문에 급하게 상태 관리를 도입해야 하는 경우에는 선택하고 싶지 않다. 

 

하지만, 기업별 기술 스택을 확인할 수 있는 페이지인 Codenary에 Redux를 검색해보니 많은 기업, 특히 대기업들도 Redux를 많이 사용하는 것을 확인할 수 있었다.

 

실제로 나도 공고들을 보면서 Redux 사용 경험에 대해 써져있는 공고들을 심심찮게 발견하기도 했다.

 

아무래도 기업들의 프로젝트는 사이즈가 크고, 데이터가 많기 때문이다.

관리해야 할 데이터가 많을수록 데이터를 데이터를 엄격하기 관리해야 하기 때문일 것이다.

 

Redux의 공식 홈페이지에서도 다음 처럼 말하고 있다.

 

 

단지 누군가가 사용하라고 했다는 이유만으로 Redux를 사용하지는 마세요. - 시간을 들여서 잠재적인 이점과 그에 따르는 단점을 이해하세요.  

 

그럼 Redux는 언제 쓰란거지.. 웬만한 상태 관리는 다른 쉬운 상태 관리 툴들로 커버가 될 것 같은데 왜 다들 쓰고 있는 걸까.

공식에서 제시하는 Redux가 사용되어야 하는 상황은 다음과 같다.

 

- 계속해서 바뀌는 상당한 양의 데이터가 있다

- 상태를 위한 단 하나의 근원이 필요하다

- 최상위 컴포넌트가 모든 상태를 가지고 있는 것은 더 이상 적절하지 않다

 

 

---

 

어려워요 언제 써야되는 지 몰겠어요

 

 

다만 확실한 거는 제가 해왔던 자그마한 플젝들 중에서는 Redux가 쓰일만한 복잡한 상태 관리도 상태가 왔다갔다해야하는 트리구조도 없었기 때문에 딱히 도입할 필요가 없었다는 것을 느꼈다.

 

근데 어떤 방면에서 보면 Redux가 필요하지 않은 가벼운 프로젝트들만 진행한 것이기 때문에 복잡한 로직 구조와 데이터의 상태 분리 경험도 못 해본 것이기 때문에 약간의 아쉬움이 느껴진다.

 

이후 사용할 일이 있거나 더 배운 것이 있어서 이 글이 수정되기를 ...🙏