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