데브캠프를 시작하면서부터 거의 매일 듣게된 단어들.. 상태 관리, 로컬 상태, 전역 상태... 상태.. 상태... 상태....
쏟아지는 정보에 정신을 못 차리고 그저 데이터를 관리하는 거구나! 상태는 데이터고 데이터는 상태구나! 결국 같은 개념이군! 이렇게 제대로 이해하지 못한채 뇌속이 와글와글 시끌벅적한(?) 상태로 어떻게 토이프로젝트를 마무리했는지 모르겠다.
그러나, 세 번째 토이 프로젝트가 시작되면서 서버 상태 관리가 요구사항에 등장해버렸고, 더 이상 미룰 수 없다고 판단하여 상태 관리에 대한 내용을 정리하면서 내 뇌도 함께 정리해보고자 한다.
상태란 무엇일까?
뇌속이 와글와글 시끌벅적한 현재 내 "상태".
내 뇌의 상태는 언제나 와글와글 시끌벅적하지 않을 것이다. 열심히 공부하고 경험이 쌓이고 내공이 쌓이면 언젠가 차분해지는 것 처럼 상태는 사용자의 상호작용에 따라 변할 수 있는 데이터이다. 그저 막연하게 모든 데이터를 아우른다고 생각하면 안 된다.
한마디로 정리하면 현재 데이터와 UI의 시각적 표현을 나타내는 정보라고 할 수 있다.
말장난이라고 생각할 수도 있겠지만, 정확하게 짚고 넘어가는 것이 좋을 것 같았다. 데이터에는 상태뿐 아니라 로그 데이터나 캐싱된 데이터처럼 모든 정보를 아우를 수 있는 포괄적인 개념이고, 상태는 데이터 중에서도 주로 사용자 인터페이스(UI)와 관련된 정보에 국한된다.
로컬 상태 vs 전역 상태
로컬 상태와 전역 상태를 구분하는 기준은 주로 상태의 범위와 접근성에 따라 달라지는데, 정리해보면 다음과 같다.
로컬 상태 (Local State)
- 특정 컴포넌트나 모듈 내에서만 사용되는 상태
- 해당 컴포넌트가 소멸되면 로컬 상태도 사라진다
- 다른 컴포넌트와의 의존성이 적고, 주로 컴포넌트의 내부 동작이나 UI 상태를 관리하는 데 사용
전역 상태 (Global State)
- 애플리케이션 전체에서 접근할 수 있는 상태
- 여러 컴포넌트 간에 공유되며, 애플리케이션의 여러 부분에서 사용될 수 있다
- 전역 상태는 보통 애플리케이션의 전반적인 데이터나 설정을 관리하는 데 사용된다
전역 상태를 언제 사용하나요?
개념적으로 정리했을 때, 음 그렇군 알겠어! 해놓고 뒤돌아서면 그래서 언제 사용하는 걸까?
사용자 인증 정보 말고 사용할 곳이 있을까 싶었다...
그래서 예시를 찾다보니 장바구니가 이해하기 아주 좋았다.
장바구니
예를 들어 장바구니는 상품 목록 페이지, 상품 상세 페이지 등 다양한 위치에서 장바구니에 상품을 추가할 수 있어야 하는데, 여기서 상태를 어디서 관리하느냐의 문제가 발생한다.
상품 목록 페이지에서 관리하게 되면 상품 상세 페이지에서는...? 🤔
물론 App.js에서 관리할 수 있겠지만, props drilling, 코드의 복잡성, 상태 변경 시 App의 모든 하위 컴포넌트가 리렌더링되는 문제 등 다양한 문제가 발생할 수 있다.
그렇기 때문에 장바구니 상태는 전역으로 관리하면 좋겠다는 생각을 자연스럽게 할 수 있게 된다.
정리
결론적으로 처음부터 어렵게 고민하지 말고 상태를 어디서 관리해야 하는지 모호해지는 상황이 온다면 전역 상태로 관리해보는 것을 고려해보면 될 것 같다는 생각이 들었다.
굳이 초반부터 어떤 상태를 전역으로 관리해야 하는지 고민하고 찾기보다 경험하면서 자연스럽게 전역 상태 관리의 필요성을 느끼게 될 것 같은 느낌...? (그런 의미에서 토이 2에서는 전역 상태로 관리할 게 딱히 없었다고 생각했던 게 틀린 건 아니었다는 것을 다시금 느꼈다!)
TMI를 하자면, 토이 프로젝트 2에서 논의 끝에 학습의 목적으로 Redux를 사용해서 대부분의 상태를 전역으로 관리하게 되었고, 이를 통해 Redux와 Redux Toolkit을 사용한 전역 상태 관리 흐름을 이해할 수 있었다. 하지만 명확한 이유 없이 모든 상태를 전역으로 관리하는 것은 지양해야 한다는 피드백을 받았던 만큼, 세 번째 토이프로젝트에서는 상태 관리에 대해 조금 더 고민해보고 아름다운 코드를 짤 수 있도록 노력해야겠다!
화이팅~👊
