우연히 면접 질문을 준비하던 중 mobx와 redux의 차이에 대해 설명하라는 글이 있었다. 나는 redux에 대해서는 알고 있지만 mobx는 들어보기만 했지 정확히 어떤 건지 몰랐고 어떻게 작동하는 지 알길이 없었다. 나는 면접을 준비하기 위해서 mobx를 찾아보게 되었다.
먼저 나는 mobx가 이벤트 기반 방식의 상태 관리 매니저라는 사실을 먼저 알아야 했다. observer가 있고 데이터가 변화가 생기면 이벤트를 발생시켜 ui를 변경하도록 말이다. 다만 redux도 같은 역할을 하고 있으며 redux가 더 표준 같은 느낌은 존재했다. 그래서 난 일단 redux와 비교해보고 알아보기로 했다.
| 기준 | MobX | Redux |
|---|---|---|
| 데이터 관리 방식 | 반응형, 선언적 | 단방향, 불변 상태 |
| 스토어 구조 | 단일 또는 분산 | 중앙 |
| UI 연동 방식 | 자동, 선택적 제어 | 직접적, UI 프레임워크 연동 |
| 장점 | 간편, 유연, 선언적, performant | 예측 가능, 안정적, 디버깅 용이 |
| 단점 | 학습 곡선, 디버깅 어려움 | 복잡, 코드 양 증가, 성능 저하 가능성 |
일단 내가 알고 있는 redux와 관련된 지식을 가져와야 했다.
일단 중앙 집중식 이다.
데이터의 방향이 고정되어 있고 탑 다운의 방식이다.
action과 store reducer를 정의해야 한다.
프로젝트 루트 구성에 redux를 추가한다.
이정도가 내가 아는 것이었고 redux와 상대적으로 대척점에 서 있는 mobx는 추축하자면 이랬다.
중앙 집중식이 아니다. => 각각의 데이터 상태를 선언할 수 있다.
데이터의 방향이 일방향이 아니다. => 탑 다운 다운 탑 모두 가능하다.
action, store, reducer를 정의해야 한다. => 다른 문법이 필요하다.
프로젝트 루트 구성에 redux를 추가한다. => 필요한 폴더에서 mobx 설정을 정의한다.
현재 만들고 있는 앱은 지도 관련 정보와 마커 정보, 경로 정보, 파일 정보를 포함하고 있다. 각 컴포넌트가 독립적으로 상태를 관리해야 하는 경우가 많으므로, MobX를 사용하는 것이 적합할 것이다. MobX는 각 컴포넌트의 상태를 쉽게 선언하고 관리할 수 있어, 이런 구조에서는 더 유연하고 편리할 것이다.