라이브러리 이름과 기능을 외워 왔는지, 아니면 도입 기준·로컬 상태와의 경계·서버 상태와의 분리까지 같이 풀 수 있는지를 가른다.
전역 상태 관리 라이브러리(Redux·Zustand·Jotai·Recoil 등)는 여러 컴포넌트가 같은 데이터를 봐야 할 때 props drilling을 줄이고, 상태 변경 로직을 UI에서 떼어 내 테스트·재사용을 쉽게 만들어 준다. 선택적 구독(selector·atom) 같은 메커니즘으로 "내가 보는 값이 바뀔 때만 리렌더" 같은 최적화도 가능하다. 다만 작은 프로젝트에서 무작정 도입하면 상태가 여기저기 흩어져 추적이 어려워지고, 사실은 컴포넌트 트리 안에서 끝났을 일이 전역으로 새 나간다. 그래서 "무엇이 전역이어야 하는가"를 먼저 정하는 게 도구 선택보다 앞선다.
props drilling이 심해진 화면을 전역 스토어로 정리하며 코드 응집도가 올라간 경험이 있다면 도입 신호의 사례로 풀어낼 수 있다
전역 스토어에 모든 걸 담았다가 디버깅이 어려워져 다시 로컬·서버 상태로 분리한 경험이 있다면 "무엇이 전역이어야 하는가"의 기준 이야기로 이어갈 수 있다
서버 상태를 TanStack Query로 빼고 클라이언트 상태만 전역 스토어에 둔 경험이 있다면 "두 종류 상태의 분리" 관점으로 일반화할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.