이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
둘의 핵심 차이를 저는 상태를 한 덩어리로 두느냐, 조각으로 쪼개느냐로 봅니다. Zustand는 하나의 저장소에 상태와 그걸 바꾸는 동작을 모아 두는 쪽이고, Jotai는 작은 상태 단위로 나눠 쓰는 컴포넌트만 그 조각을 구독하는 쪽입니다. 그래서 제 선택 기준은 상태가 서로 얽혀 같이 움직이느냐입니다.
여러 값이 한 흐름으로 묶여 같이 바뀌는 화면은 Zustand로 모아 두는 게 추적하기 쉽고, 서로 독립적인 작은 상태가 흩어진 화면은 Jotai가 필요한 조각만 구독해 불필요한 다시 그림이 적어 가볍습니다. 학부 프로젝트에서 작고 독립적인 상태를 한 저장소에 다 모았다가, 한 값만 바뀌어도 관련 없는 부분까지 다시 그려진 경험이 있어 이 기준을 세웠습니다. 다만 Jotai는 조각이 많아지면 어디서 무엇이 바뀌는지 흐름이 흩어지는 대가가 있어, 얽힘이 커지면 다시 모으는 쪽을 봅니다.
저는 상태관리를 고를 때 문제가 났을 때 어디서 틀어졌는지 따라가기 쉬운가를 가장 봅니다. Zustand는 상태와 변경 동작이 한곳에 모여 있어, 무엇이 왜 바뀌는지 한 자리에서 따라가기 쉽습니다. 대신 그 저장소가 커지면 작은 상태까지 거기 묶여 무거워집니다. Jotai는 작은 상태를 가볍게 다루기 좋지만, 변경이 여러 조각에 흩어지면 큰 버그가 났을 때 출처를 모으기 어렵습니다. 그래서 제 기준은 이 상태가 틀어졌을 때 추적이 중요한가입니다.
결제·흐름 제어처럼 틀어지면 크게 문제 되는 상태는 Zustand로 모으고, 틀어져도 영향이 작은 작은 UI 상태는 Jotai로 가볍게 둡니다. 학부 때 얽힌 핵심 상태를 잘게 쪼갰다가 디버깅에 한참 헤맨 경험이 이 기준의 근거입니다. 한쪽이 늘 옳은 게 아니라 추적 비용과 가벼움을 견주는 것이라고 봅니다.
솔직히 저는 하나만 고집하지 않습니다. 둘은 잘 맞는 규모가 다릅니다. 상태가 적고 독립적이면 한 저장소에 모으는 방식은 안 쓸 구조를 미리 까는 비용이 되고, 상태가 많고 서로 얽혀 한 변경이 여기저기 영향을 주는 화면은 조각만 다루다 전체 흐름을 잃기 쉽습니다. 그래서 저는 작고 흩어진 상태는 Jotai, 얽히고 추적이 중요한 핵심 흐름은 Zustand로 가릅니다. 학부 때 작은 화면을 무겁게 한 저장소로 잡았다가 코드만 늘어난 경험과, 반대로 복잡한 상태를 잘게 쪼개 추적이 안 돼 고생한 경험을 둘 다 겪어 이 기준을 세웠습니다. 한 화면에 둘이 섞일 수도 있는데, 그때는 핵심 도메인 상태와 지엽적 UI 상태의 경계를 분명히 그어 둡니다. 도구는 규모가 정한다고 봅니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스뱅크 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.