이번 글은 MobX의 사용에 관한 부분이나 코드 등을 다루진 않는다. 그냥 배워보기 전에 약간의 배경지식(?)이라고 하면 될 거 같다. 꼭 필요한 글은 아니니, 궁금하지 않다면 바로 다음 글을 읽어봐도 좋다.
시작 전 넋두리..
리액트로 앱을 만들면서 얼마 안돼, 우리는 상태 관리에 대한 고민을 시작한다. 특정 컴포넌트의 상태 값을 다른 컴포넌트와 공유하고 싶다는 생각이다. 그래서 처음에는 prop을 통해 상위 컴포넌트로 상태 값을 전달하기 시작한다. 물론 매우 훌륭한 방법이다. 하지만, 또다시 위기에 봉착한다. 컴포넌트가 많아지고 그 깊이가 깊어질수록 상태 값을 전달하는 게 너무 복잡해지기 때문이다.
Redux is a predictable state container for JavaScript apps.
그러다보면 가장 많이 사용되고 있는 Redux를 접하게 되고 사용한다(물론 리액트 앱을 만드는 경우를 예로 들었지만, Redux를 포함한 많은 상태 관리 라이브러리들은 특정 프레임웍 또는 라이브러리에 종속적이지 않는다). Redex는 앱의 상태를 store라는 단일 저장소에 객체 트리(object tree)로 저장한다.
* Reducer
(state, action) => state signature
그리고 그 스토어를 변경하기 위해서는 순수한 reducer함수를 통해 state와 action을 전달해 주면된다. 여기서 액션이란 현재의 상태(state)를 다음 상태로 변환하는 방법을 나타낸다.
여기까지만 배워도 사실 상태관리를 하는 데에는 아무런 지장이 없다. 다만 Redux를 잘 다루기 위한 러닝 커브는 큰 편에 속하기 때문에 만만치 않는 작업임에는 틀림없다. 그래서 redux-toolkit이라는 별도의 애드온 패키지가 존재한다. redux 저장소 구성이 복잡해 지고, 불필요하게 반복되는 상용구 코드가 많기 때문에 이를 개선한 패키지라고 생각하면 된다. 레딧이라는 커뮤니티에서는 redux-toolkit이 "redux가 살아남을 수 있는 유일한 길"이라고까지 표현한 글을 본 적이 있다.
redux-toolkit이 "redux가 살아남을 수 있는 유일한 길" 이라고??
redux가 상태 관리의 독보적인 위치에 선두주자임에는 틀림없다. 그런데 살아남을 수 있는 유일한 길이라니... 사실 납득이 안 가는 말이다. 그렇다면 어떤 후발 주자들이 이렇게 무섭게 달려오고 있기 때문에 redux-toolkit을 만들어지게 하고 저런 말이 나오게 된 것일까?
안녕 MobX?
Anything that can be derived from the application state, should be derived. Automatically.
사실 redux의 하락세를 주도하고 있는 것이 Mobx라곤 할 수 없다. GraphQL이라는 멋진 쿼리(query) 언어가 더 큰 영향을 미치고 있다(GraphQL에 대해서는 다른 글에서 좀 더 심도 있게 다뤄볼 생각이다). 그럼에도 불구하고 MobX를 소개하는 이유는 분명 React랑 MobX랑 같이 사용했을 때 아주 멋진(?) 상태 관리가 가능하기 때문이다. MobX를 사용한다면 Redux가 가지고 있던 높은 러닝 커브와 불필요한 상용구 코드들을 잠시 잊어버려도 좋다.
나 또한 MobX를 배우면서 분명 너무 편하고 마법 같은 일들이 많이 벌어져서 놀랍기도 하고, 사용하기가 매우 편리했다. MobX에서는 여러 store가 존재할 수 있었고 상용구 코드가 정말 많이 줄어들었다. 하지만 가장 큰 차이는 Redux는 일반적인 자바스크립트 객체를 사용하여 데이터를 저장했다면, MobX는 Observable을 사용하여 데이터를 저장하기 때문에 데이터에 발생하는 변경 사항을 자동으로 추적해 주었다. 처음 RxJS를 접했을 때의 신선 함이라고 할까?
MobX는 높은 수준의 추상화로 사용하기에 정말 편리하고 불필요한 코드가 적은 축에 속한다. 개발자는 많은 것에 신경 쓰지 않아도 되고 러닝 커브 또한 줄어들게 해 준다. 반면 이런 높은 추상화로 디버깅이 힘들어진다. 개발자 도구도 존재하지만, Redux Dev Tools만큼은 아니다. 그리고 순수하지 않기 때문에 때로는 예측할 수 없는 결과가 발생할 수도 있다(물론 이런 상황을 만들면 안 되겠지만...).
대체제가 분명 많은 거 같은데 왜 아직도 Redux를 사용하지?
MobX, GraphQL 등 정말 멋진 대체제들이 존재한다. 그럼에도 불구하고 Redux를 많은 개발자들이 사용하는 것은 여러 가지 이유가 있다.
- 높은 러닝 커브를 극복하면, 높은 확장성과 순수한 특성으로 인해 예측 가능하고 테스트하기가 더 쉽다.
- Redux Dev Tools라는 멋진 디버깅 도구로 높은 수준의 디버깅이 지원된다.
- 큰 커뮤니티와 이미 수많은 예제, 문서, 경험 등이 존재한다.
- ImmutableJS 같은 라이브러리를 통해 불변성을 높게 유지할 수 있다(추가 라이브러리 사용에 대한 러닝 커브도 있지만...).
참고
npm 다운로드 수
(MobX가 아래 다른 라이브러리들에 비해 다운로드 수가 낫다고 저평가하지 말자. 정말 멋진 라이브러리이다)
참고 URL
https://mobx.js.org/README.html
https://woowabros.github.io/experience/2019/01/02/kimcj-react-mobx.html
https://trends.google.co.kr/trends/explore?q=redux,MobX,graphql
'상태관리' 카테고리의 다른 글
Redux Reducer와 Array.reduce (0) | 2019.12.26 |
---|---|
[Redux & Reducer] 기초 개념 2 (0) | 2019.12.10 |
[Redux & Reducer] 기초 개념 1 (0) | 2019.12.10 |