소개
프런트엔드 애플리케이션이 복잡해질수록 상태 관리 역시 자연스럽게 어려워집니다. 새로운 상태 관리 라이브러리를 도입하는 것만으로 이러한 문제가 해결되지는 않습니다. 오히려 중요한 것은 어떤 상태를 어디에 두어야 하는지, 그리고 그 상태가 정말 전역으로 관리되어야 하는지를 판단하는 것입니다.
이 글은 특정 상태 관리 라이브러리의 사용법을 소개하기보다, 상태 관리 문제를 바라보는 관점과 원칙에 집중합니다. 애플리케이션의 상태를 어떻게 분류하고 소유권을 결정할 것인지, 상태를 필요한 곳 가까이에 두는 것이 왜 중요한지 등 우리가 익숙하게 사용해 온 상태 관리 방식에 대해 다시 생각해 볼 만한 질문들을 던집니다.
Redux, Zustand, React Query처럼 다양한 선택지가 존재하는 지금, 중요한 것은 어떤 도구가 가장 좋은지를 결정하는 것이 아니라 현재 다루고 있는 상태의 성격을 이해하고 그에 적합한 해결책을 선택하는 것입니다. 상태 관리에 대한 자신만의 기준을 한 번쯤 정리해 보고 싶은 프런트엔드 개발자라면 읽어볼 만한 글입니다.
팀원들의 의견
여러분은 React나 Zustand를 ‘상태 관리’ 도구라고 생각하시나요? 또, Redux, Zustand, React Query를 모두 ‘상태 관리 라이브러리’라고 부르는 것이 맞을까요?
‘상태 관리’와 ‘상태 전파’를 구분하는 저자의 주장에 공감하시나요?
💬. 의견 1
React 에서 기본적으로 상태를 관리할 수 있다는 점도 동의하는 부분이고, Tanstack Query, Zustand, Jotai 등의 라이브러리 에서도 ‘상태 관리’ 라는 관심사를 처리해준다는 점에서 충분히 상태 관리 도구라고 부를 수 있지 않나 싶습니다.
저자가 생각하는 상태 관리 라이브러리에 대한 기준이 일반적인 웹 애플리케이션에서 필요로하는 기준과는 거리가 좀 있다고 생각되어서.. PUB/SUB 패턴일 뿐이다 라고 하는건 개인적으로는 동의하기 어려운 부분이 있네요.
💬. 의견 2
저자가 말하고자 하는 바가 무엇인지는 알겠습니다. 전통적인 '상태 관리'의 개념을 흐리지 말고 제대로 이해해서 쓰자... 정도로 이해했는데요. UI 개발이건 뭐건 결국 프로그래밍이니 저자의 주장에는 어느정도 공감이 됩니다. 하지만 웹 프런트엔드 생태계에서 특히나 리액트가 주류인 현 상황에서 Redux, Zustand, React Query를 ‘상태 관리 라이브러리’라고 부르냐 아니냐가 얼마나 생산적인 논의일지에 대해서는 회의감이 드네요 ㅎㅎ
목차
그때, 지금, 그리고 앞으로
진지하게 바라보기