전역 상태 관리 라이브러리는 왜 사용하나요?
전역 상태 관리 라이브러리, 왜 쓸까요? 🤔
안녕하세요! 오늘은 프론트엔드 개발을 하면서 한 번쯤 고민해봤을 전역 상태 관리 라이브러리에 대해 이야기해보려고 해요.
1. 컴포넌트 간 상태 공유가 쉬워져요! 🔄
Props Drilling의 지옥에서 탈출 😵💫
일반적인 React 개발을 하다 보면 이런 상황을 만나게 돼요:
할아버지 컴포넌트 → 아버지 컴포넌트 → 아들 컴포넌트 → 손자 컴포넌트
사용자 정보를 손자 컴포넌트에서 써야 하는데, 중간에 있는 아버지와 아들 컴포넌트는 그 정보가 전혀 필요 없어요. 하지만 props로 계속 전달해야 하죠. 마치 택배를 전달하는 중간 배송기사들처럼요! 📦
전역 상태 관리를 쓰면? 손자 컴포넌트가 직접 창고(전역 스토어)에서 필요한 물건을 가져올 수 있어요.
실생활 예시 🏠
- Redux/Zustand 없을 때: 1층에서 3층으로 물건을 전달하려면 2층을 거쳐야 함
- Redux/Zustand 있을 때: 엘리베이터처럼 바로 3층으로 이동 가능!
2. 관심사 분리로 코드가 깔끔해져요! ✨
UI와 비즈니스 로직의 분리
컴포넌트는 "어떻게 보여줄까?"에만 집중하고, 상태 관리는 "어떻게 동작할까?"에만 집중할 수 있어요.
예시: 쇼핑몰 장바구니 🛒
- 컴포넌트: "장바구니 아이콘에 빨간 뱃지 보여주기"
- 상태 관리: "상품 추가/삭제 로직, 수량 계산 로직"
이렇게 분리하면 나중에 디자인이 바뀌어도 비즈니스 로직은 그대로 쓸 수 있어요!
테스트하기도 쉬워져요 🧪
상태 관리 로직만 따로 테스트할 수 있어서, UI 컴포넌트 렌더링 없이도 비즈니스 로직을 검증할 수 있어요.
3. 성능 최적화의 마법! ⚡
똑똑한 리렌더링
최신 상태 관리 라이브러리들은 정말 똑똑해요:
- 변경된 부분만 리렌더링 해요
- 구독한 컴포넌트만 업데이트 해요
실생활 예시: 아파트에서 택배가 와도 해당 호수에만 벨이 울리지, 전체 아파트에 방송하지 않죠? 전역 상태도 마찬가지예요! 📢
주의사항: 과유불급! ⚠️
언제 쓰면 안 될까요?
작은 프로젝트에서는 오히려 독이 될 수 있어요:
- To-do 앱 정도라면 useState로 충분해요
- 팀원 2-3명, 컴포넌트 10개 이하라면 고민해보세요
실생활 비유: 혼자 사는데 창고를 따로 빌리는 격이에요! 💸
언제 써야 할까요?
✅ 이런 상황이라면 도입 고려:
- 여러 페이지에서 공유하는 상태 (로그인 정보, 테마 설정)
- 복잡한 상태 변경 로직
- 팀 규모가 5명 이상
- 컴포넌트 depth가 깊어서 props drilling이 심각함
어떤 라이브러리를 선택할까? 🤷♂️
Next.js 개발자에게 추천하는 선택지:
🏆 Zustand: 가볍고 사용하기 쉬움 (요즘 핫한 선택!)
🛠️ Redux Toolkit: 복잡한 프로젝트, 팀 표준이 필요할 때
⚛️ Jotai: 아토믹한 상태 관리가 필요할 때
추가 팁! 💡
Server State vs Client State 구분하기:
- Server State (API 데이터): TanStack Query(React Query)
- Client State (UI 상태): 전역 상태 관리 라이브러리
이 둘을 구분해서 사용하면 더욱 효율적이에요!
면접 답변 💼
Q: 전역 상태 관리 라이브러리를 왜 사용하나요?
A: 전역 상태 관리 라이브러리를 사용하는 주요 이유는 세 가지입니다.
첫째, Props Drilling을 해결하여 컴포넌트 간 상태 공유를 용이하게 합니다.
둘째, UI 로직과 상태 관리 로직을 분리하여 관심사 분리와 코드 재사용성을 높입니다.
셋째, 필요한 컴포넌트만 선택적으로 리렌더링하여 성능을 최적화합니다.
다만 작은 규모 프로젝트에서는 React의 내장 상태 관리만으로도 충분할 수 있어, 프로젝트 복잡도를 고려하여 도입 여부를 결정해야 합니다.
전역 상태 관리 라이브러리는 왜 사용하나요?
전역 상태 관리 라이브러리를 사용하는 이유에 대해 크게 세 가지를 설명드리겠습니다.
첫째, 컴포넌트 간 상태 공유가 용이해집니다. 여러 컴포넌트에서 공통적으로 사용되는 상태를 중앙화하여 관리하고, 여러 곳에서 쉽게 접근할 수 있습니다. 부모 컴포넌트에서 자식 컴포넌트에게 상태를 전달하기 위해 여러 컴포넌트를 거치는 "props drilling"을 겪지 않고 상태를 공유할 수 있습니다.
둘째, 관심사 분리가 용이해집니다. 상태 관리 로직을 컴포넌트에서 분리하여 별도로 관리함으로써, 컴포넌트는 UI 로직에만 집중할 수 있게 됩니다. 예를 들어 Redux에서는 상태 변경 로직을 Reducer에 정의해두고, 컴포넌트 단에서는 Dispatch를 통해 Reducer를 호출하는 방식으로 동작합니다. 이러한 분리는 "관심사의 분리 원칙"을 따르며 코드 재사용성과 테스트 용이성을 높여줍니다.
셋째, 성능 최적화에 도움이 됩니다. 현대의 상태 관리 라이브러리들은 불필요한 리렌더링을 방지하는 메커니즘을 제공합니다. 예를 들어 Zustand는 구독 메커니즘을 통해 실제로 상태가 변경된 컴포넌트만 리렌더링되도록 보장합니다.
전역 상태 관리 라이브러리 도입을 고려할 때 주의할 점이 있나요? 🤔
작은 규모의 프로젝트에서는 전역 상태 관리 라이브러리가 오버엔지니어링이 될 수 있다는 점을 고려해야 합니다. 작은 규모임에도 도입한다면 오히려 불필요한 복잡성이 추가되어 개발 생산성이 저하될 수 있습니다. React의 내장 기능인 useState, useContext만으로도 충분할 수 있습니다.
프로젝트 규모가 크고 복잡한 상태 관리가 필요하거나, 여러 컴포넌트에서 공유해야 하는 상태가 많은 등 실제로 필요성이 느껴질 때 도입하는 것이 오버엔지니어링을 막을 수 있습니다.