Zustand 도입 이유

0. 들어가며

특화 프로젝트에 사용할 상태 관리 라이브러리를 고민하던 중 Zustand를 사용하기로 결정한 이유에 대해 정리해보고자 한다.

1. 상태 관리 라이브러리는 왜 필요한가?

블로그를 보면 보통 전역 상태 관리만 상태 관리 라이브러리의 사용 이유로 언급하는 경우가 많은데, 여러 상태 관리 라이브러리의 공식 문서 또는 영어로 쓰여진 칼럼들을 보면 전역 상태 관리가 여러 이유 중 하나일 뿐이라는 것을 알 수 있다.

(1) 전역 상태 관리

props drilling을 해결하기 위해 사용 한다. 이 경우 Context API만으로도 해결할 수 있다. 단, 저번 프로젝트에서 사용해봤듯이 Context API는 불필요한 리렌더링이 존재하며 성능 최적화를 위해서는 보일러 플레이트 코드가 길어진다.
이러한 성능 최적화를 자동으로 해주길 바란다면 라이브러리를 사용하는 것이 좋다.

(2) 성능 최적화

상태가 실제로 변경되었을 때만 리렌더링 되도록 최적화를 해준다. 이 또한 early bailout로 리액트 자체에서 어느정도 최적화를 해주고 있지만 항상 최적화가 되는 것은 아니다.
React early bailout
React Redux 공식문서 설명에서도 내부적으로 많은 최적화를 해주고 있다고 한다.

(3) 유지보수 향상

라이브러리마다 상의하지만 store, selector등 상태 관리에 필요한 요소들을 한 곳에 모아두며, 로직을 분리하여 관리할 수 있다.
이렇게 로직을 분리하면 많은 이점이 있다.

1. 코드의 가독성 향상
2. 테스트 코드 작성 용이
3. 코드의 재사용성 향상
4. 디버깅 용이

이러한 이점들이 곧 유지보수 향상으로 이어진다.

(4) 비동기 처리

API 요청에서 여러가지 에러 처리를 도와주며, 여러번 요청을 보내는 경우 중복 요청을 방지, 또한 서버 상태(데이터)를 캐싱하고 관리를 용이하게 해준다.

2. 우리 프로젝트에서 상태 관리 라이브러리가 필요한 이유

사실 작은 규모의 프로젝트에서 상태 관리 라이브러리가 필요한 이유는 전역 상태 관리말고는 없다고 생각한다.
(2), (3), (4)의 이유는 프로젝트 규모가 커질수록 생각해야할 이슈이다, 실제로 우리 프로젝트에서도 필요한 몇몇 상태들을 전역으로 쉽게 관리하기 위해 도입하게 되었다.
Context API를 사용해도 되지만, 빠듯한 일정에 간결한 코드와 성능 최적화를 라이브러리에 위임하고 싶었다.

3. 왜 Zustand를 선택했는가?

(1) 매우 가벼운 라이브러리

우리 프로젝트에서 원하는 건 전역 상태 관리를 위한 간단한 기능이었다, 어떤 라이브러리를 사용해도 가능했지만, 불필요한 기능이 많은 라이브러리를 사용할 필요가 없었다.
Zustand는 187kb로 매우 가벼운 라이브러리이다. 마찬가지로 가볍다는 jotai의 830kb와 비교해도 매우 가볍다.

(2) 의외로 높은 npm trends

가볍다는 라이브러리들을 비교해보면 Zustand가 가장 높은 npm trends를 보여준다, npm trends가 높다는 것은 그 만큼 자료가 많고, 사용자가 많으며, 활발히 개발되고 있다 생각했다.

(3) flux 패턴

Atomic방식을 사용하는 Recoil, Jotai와 달리 Zustand는 flux 패턴을 사용한다.
관리할 상태가 그리 많지 않으므로 굳이 Atomic 방식으로 재사용성을 높이는 것보다 flux 패턴의 중앙 집중식으로 상태를 관리하는 것이 더 편리하다고 생각했다.

(4) devtools 지원

Zustand는 Redux devtools를 그대로 사용할 수 있어서 개발자 도구를 통해 상태를 확인하고 디버깅하기 편리하다.

4. 마치며

약 1년 전에 한글 블로그로만 공부했을 때는 상태 관리 라이브러리가 그저 전역 상태 관리를 위한 것이라고만 생각했었다. 그 당시에는 기능이 그것 밖에 없는데 Redux는 왜 이렇게 복잡한지 이해가 안되었다.
공식 문서와 영어로 쓰여진 칼럼들이 더 깊게 공부하는데 도움이 되는 것을 다시 한번 느꼈다.