[Redux] 사용법부터 이론까지 살펴보는 Redux: 1 기본 컨셉

redux는 오늘날 프론트엔드 생태계에서 가장 인기있는 상태관리 라이브러리다. npm trend를 살펴보면 recoil이나 zustand, zutai, mobx 등과 비교했을 때 더 높은 다운로드 수를 봐도 그 인기를 알 수 있다. 하지만, 리덕스는 모든 곳에서 만능이 아니며, 그 컨셉을 제대로 이해해야 효력을 볼 수 있다. 이 시리즈에서는 리덕스 사용법과 이론에 대해 살펴본다.

 

 

상태관리 라이브러리의 등장 배경과 리덕스

---

FLUX 디자인은 왜 등장했는가

리엑트는 상태관리를 위해서 state를 props와 단방향(하향식) 데이터 바인딩으로 사용한다. 여기서 state는 ui에 삽입되는 데이터 값을 의미한다. 데이터 값이 변환될 때는 다음 과정을  거친다.

1. 이벤트 리스너나 fetch 등의 비동기적 로직에서 setState로 데이터 변경을 요청
2. 비동기적으로 데이터 변환
3. 리엑트에서 데이터 변환을 감지하면 해당 상태값이 할당된 컴포넌트를 리렌더링
4. 컴포넌트의 하위 컴포넌트까지 리렌더링되며 갱신된 props 값이 전달

여기서 중요한 건 리렌더링을 촉발하는 state setter와 setter의 로직이 각 컴포넌트에 분산되어 있다는 점이다. 이 상태에서 앱의 규모가 커진다면 분산 현상은 더욱 심해진다. 게다가 여러 model 간에 종속성까지 존재한다면 어떻게 될까. 리엑트는 파이버 노드 아키텍처에 기반하여 state 업데이트를 비동기적으로 실행한다. 따라서 순차적인 state 업데이트에서 한 state업데이트 로직이 다른 state 업데이트의 결과값을 보장받지 못한다. 그러면 개발자가 예상한 것과 다른 업데이트가 일어날 수 있을 뿐만 아니라 데이터 흐름을 추적하고 디버깅하는 것이 어려워진다.

 

이런 배경에서 리엑트는 FLUX 디자인을 도입했다. 이 디자인은 기존의 분산된 state setter와 갱신 로직을 하나의 허브로 옮기는 것이다. dispather라 불리는 이 허브로, view는 무엇을 업데이트할지, 그리고 어떤 값을 반영할지에 대한 메시지(aciton)을 보낸다. dispather은 view가 보낸 action을 보고 적절하게 다른 store로 전송한다. store들은 이를 반영하여 상태값을 업데이트하면 이를 구독한 다른 view에 데이터 바인딩 요청을 보낸다.

 

이 방식의 핵심은 예전에 view가 가진 setter와 업데이트 로직을 dispather로 모두 집결시킨다는 점이다. 이 때문에 개발자는 데이터흐름을 dispather를 통해 추적하기 용이해지고 복잡한 업데이트 로직을 보기 좋게 만들 수 있다.

 

(이전에 쓴 관련 글)

2024.03.17 - [react] - [react] FLUX 디자인 패턴의 이해2

[react] FLUX 디자인 패턴의 이해2

 

 

2. props drilling 문제

리엑트는 하향식으로만 상태값을 전달할 수 있다. 따라서 형제 컴포넌트 간에 데이터를 공유하려면 반드시 부모 컴포넌트에 상태값을 할당되어야 한다. 데이터가 공유되어야할 컴포넌트간에 거리가 멀수록 더 높은 상위 조상 단계에서 상태값을 할당하고 props로 내려줘야 한다. 그 과정에서 중간에 있는 컴포넌트들은 그저 props를 전달하는 매개체로 있어야 한다. 이를 props traveling 혹은 props drilling 이라 부른다. props를 전달해줘야 하는 중간 컴포넌트는 재사용성이 떨어지고 불필요한 코드가 추가된다.

 

 

3. 리덕스

리덕스는 2. props drilling의 문제를 해결하기 위해 전역에서 상태값을 관리하는 상태관리 라이브러리의 일종이며 1.FLUX 디자인 패턴과 유사하게 모델 업데이트를 dispather 로 집약시켰다. 여기서 FLUX와 차이점이라면, 리덕스는 단일 스토어를 사용한다는 점이다. 여기서는 리덕스가 이 두 가지 문제를 해결하면서 중앙집중식 단일 스토어 컨셉으로 등장한 라이브러리라는 점만 이해하고 자세한 이론과 동작방식은 다음 기회에 소개하겠다.