1. Prop Drilling이 시작되면 신호가 온다

처음에는 props로 충분하지만 부모 -> 자식 -> 손자 -> 증손자까지 같은 값을 계속 전달하기 시작하면 코드 의도가 흐려진다.

특히 아래 상황에서 피로도가 확 올라가며 지역 상태만으로 버티기에 한계가 온다.

• 중간 컴포넌트는 값을 쓰지도 않는데 전달만 함
• 값 전달 경로가 길어져서 수정 시 영향 범위가 큼
• “이 값 어디서 바뀌는지” 추적이 느려짐

2. 리액트 기본 도구: Context API

Prop Drilling을 줄이기 위해 제일 먼저 쓰는 건 Context API였다.
공유할 값을 Provider에 넣고, 필요한 곳에서 useContext로 꺼내 쓰는 방식이다.

• 리액트 기본 기능이라 도입이 가볍다
• 깊은 트리에서도 직접 접근 가능
• 인증 정보/테마/로케일 같은 공통값에 잘 맞는다

2-1. Context를 “만능 상태관리”로 쓰면 생기는 문제

실수했던 지점도 분명했다.
Context 값이 자주 바뀌는 구조로 설계하면 구독 컴포넌트가 같이 리렌더되어 성능 비용이 커진다.

• Context에 적합:
  • 변경 빈도가 낮은 전역 설정값
  • 앱 전역 의존성 주입 성격의 값
• Context만으로 버겁다:
  • 자주 업데이트되는 복잡한 비즈니스 상태
  • 화면 단위로 세밀한 구독 최적화가 필요한 상태

즉, Context는 “공유 통로”로 훌륭하지만, 복잡한 상태 전이까지 전부 맡기면 관리가 어려워진다고 한다.

3. 전역 상태 라이브러리, 무엇을 기준으로 고를지

라이브러리를 비교할 때 기준을 우선시해야 한다.

• 팀이 상태 변경 추적을 얼마나 중요하게 보는가
• 보일러플레이트를 감수할 수 있는가
• 러닝 커브와 팀 경험 수준은 어떤가
• DevTools/미들웨어/생태계 지원이 필요한가

3-1. Redux

• 강점:
  • 상태 변경 흐름이 명시적이라 추적/디버깅이 강함
  • 대규모 프로젝트에서 규칙 강제에 유리
  • 툴링(특히 DevTools)이 탄탄함
• 주의점:
  • 개념과 설정이 많아 초반 진입 장벽이 있다
  • 소규모 앱엔 과할 수 있다

3-2. Recoil

• 강점:
  • 훅 기반 사용감이 자연스럽다
  • atom 단위로 쪼개서 관리하기 편하다
• 주의점:
  • 팀/조직 표준으로 삼기 전에 유지보수/생태계 상황 점검이 필요하다

3-3. Zustand

• 강점:
  • 보일러플레이트가 적고 시작이 빠르다
  • 필요한 상태만 구독하기 좋아 성능 설계가 수월하다
  • 훅 기반이라 기존 컴포넌트와 결합이 쉽다
• 주의점: