이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
상태 관리 복잡도는 전역 상태와 서버 상태를 같은 스토어에서 관리하려 할 때 급격히 올라간다고 경험했습니다. Redux로 서버 응답 캐시까지 전부 관리했는데, 캐시 만료·리패치·로딩 상태를 직접 구현하면서 보일러플레이트가 폭발적으로 늘었습니다. 서버 상태는 `React Query`로 분리하고 클라이언트 UI 상태만 전역 스토어에 남기는 구조로 바꾸니 코드가 절반 수준으로 줄었습니다. 팀과 Zustand로 전환하면서 스토어 슬라이스를 기능 단위로 나눴고, 한 기능 변경이 다른 기능의 상태에 영향을 주는 경우가 눈에 띄게 줄었습니다.
상태를 어디에 둘지는 데이터의 수명과 공유 범위로 판단하는 게 가장 실용적인 기준이라고 봅니다.
상태 관리 툴을 도입한 뒤 오히려 코드가 복잡해지는 경험을 했습니다. 팀 프로젝트에서 모든 상태를 Zustand 스토어에 넣다 보니, 화면 하나에서만 쓰는 모달 열림 상태까지 전역으로 관리하게 됐습니다. 스토어 파일이 커지면서 어떤 컴포넌트가 어떤 상태를 건드리는지 추적이 안 됐고, 버그 원인을 찾는 데 기능 구현보다 더 많은 시간이 걸렸습니다. 이후 코드 리뷰에서 시니어가 "이건 useState로도 충분한데" 한 마디 하는 것을 듣고, 상태의 범위를 먼저 정하고 도구를 고르는 순서가 맞다는 걸 알게 됐습니다. 전역 상태를 줄이고 로컬로 내리니 컴포넌트 단위 테스트도 쉬워졌습니다. 라이브러리가 있다고 모든 상태를 넣어도 된다는 건 착각이었습니다.
모든 상태 관리 문제에 외부 라이브러리가 필요한 건 아니라는 걸 직접 확인했습니다. 개인 프로젝트에서 useReducer + Context 조합만으로 장바구니 상태를 관리했는데, 추가 설치 없이 상태 전환 로직을 한곳에 모을 수 있었습니다. 리듀서를 쓰면 상태 변경이 어떤 액션에서 시작됐는지 명확히 추적할 수 있었고, 코드 리뷰 때 팀원이 흐름을 바로 이해했습니다. 한계는 분명했습니다. 상태 종류가 5개를 넘어가니 Context 리렌더링 문제가 발생했고, 범위를 여러 Context로 쪼개는 작업이 번거로워졌습니다. 그 경험 이후로는 상태 수가 적고 단방향 흐름이 명확할 때는 내장 API로 먼저 시도하고, 규모가 커질 것 같은 시점에 라이브러리를 도입하는 순서를 지키고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.