처음 만난 리덕스 (Redux) 문서
1.1 Redux의 탄생
먼저 우리가 어떤 기술에 대해서 배울 때는 그 기술이 왜 탄생하게 되었는지, 그 역사를 이해하는 것이 중요합니다.
모든 기술들은 기존 기술의 단점을 보완하거나 새로운 기능을 제공하기 위해서 탄생하기 때문이죠.
Redux의 탄생 과정 또한 그런 역사를 가지고 있습니다.
먼저 Redux가 탄생하게 된 동기를 알아보도록 하겠습니다.
우리가 이미 아는 것처럼, 리액트는 SPA라고 부르는 Single Page Application을 개발하기 위한 라이브러리입니다.
SPA가 등장한 이후로 다양한 요구사항들을 적용하면서 웹사이트의 규모가 점점 커지게 되었습니다.
여기서 규모가 커졌다는 말은 그만큼 많은 state. 즉, 관리해야 할 상태들이 많아졌다는 말이기도 합니다.
상태관리의 복잡도가 크게 증가한 것이죠.
리액트 관점에서는 이 그림처럼 컴포넌트도 많아지고 컴포넌트들이 갖고 있는 state들도 너무 많아져서 상태관리의 복잡도가 증가했다고 볼 수 있습니다.
이러한 상태에는 서버로부터 받아와서 캐싱된 데이터뿐만 아니라, 로컬에서 사용하는 데이터들도 포함되어 있습니다.
그리고 페이지에서 사용하는 UI 컴포넌트들의 상태들도 포함될 수 있습니다.
이처럼 웹사이트의 규모가 커지고 수많은 상태들을 관리하게 되면서, 개발자들은 어려운 문제들에 직면하게 됩니다.
가장 대표적인 예로, 언제 어디서 어떻게 상태가 업데이트 되는지 파악하기가 힘들어진 것이죠.
계속해서 바뀌는 수많은 상태들을 제대로 관리하는 것은 굉장히 어려운 일입니다.
어떤 컴포넌트에서 언제, 어떻게, 왜 상태를 변경했는지 파악하기란 쉽지가 않죠.
특히 규모가 큰 웹사이트에서는 더더욱 그럴 것입니다.
개발자가 이 과정을 제대로 파악하지 못한다면, 버그의 원인을 찾고 수정하는데에도 시간이 오래 걸리게 됩니다.
버그를 제대로 수정하기 위한 첫 번째 단계는 바로 버그를 재현하는 것이기 때문입니다.
어떻게 이 상태가 업데이트 됐는지 그 원인을 파악할 수 없다면, 버그를 재현할 수도 없으며 결국 버그를 수정하기 힘들어집니다.
뿐만 아니라, 새로운 기능을 추가하기도 쉽지 않을 것입니다.
그래서 이런 문제를 겪게된 개발자들은 이런 생각을 떠올리게 됩니다.
"수많은 상태들을 어떻게 효과적으로 관리할 것인가?"
개발자들은 어떤 문제를 마주했을 때 도망치는 사람이 아닌 그 문제를 해결하는 사람들이죠.
이러한 문제를 해결하고 상태들을 명확하게 관리하기 위해서, 상태 관리만을 위한 기술이 등장하게 됩니다.
그렇게 등장한 것이 바로 Redux입니다.
마지막 업데이트: 2023년 07월 14일 00시 00분
이 문서의 저작권은 이인제(소플)에 있습니다. 무단 전재와 무단 복제를 금합니다.