Jotai는 조-타이 라고 읽습니다.

사내 신규 프로젝트에 상태 관리를 도입하며 Jotai를 고른 과정과 사용법을 정리한 글이다. Redux, Context API, Recoil, Jotai를 비교해 선택 근거를 밝히고, atom과 useAtom의 동작 원리부터 WeakMap 기반 구현 컨셉, 자주 쓰는 유틸까지 이어진다. 제목대로 정확한 발음은 조타이가 아니라 조-타이라고 짚는다.

핵심 포인트

Context API는 Provider 값이 바뀌면 구독 중인 하위 컴포넌트가 모두 다시 렌더링돼 복잡한 업데이트에 비효율적이다.
Jotai는 Context의 리렌더링 문제를 풀려고 나왔고 Recoil에서 영감을 받은 atomic 방식이다.
번들 크기가 Recoil의 6분의 1 수준이라 가벼운 라이브러리가 필요한 상황에 맞았다.
Recoil과 달리 atom에 키를 요구하지 않는다.
atom 상태 추적에 WeakMap을 써서 더 이상 쓰이지 않는 atom이 가비지 컬렉션 대상이 된다.
atom config 객체는 참조 대상이 항상 같아야 하며 렌더링 중에 만들면 무한 루프에 빠진다.

상세 정리

문제의식: state와 props만으로는 공유할 상태가 늘어날수록 prop drilling 같은 한계에 부딪힌다.
Redux 평가: Flux에서 영감을 받아 상태를 중앙화해 prop drilling을 풀었고 자료와 커뮤니티가 방대하며 디버깅이 강점이지만, 러닝 커브와 초기 보일러플레이트가 단점이다.
Context API 평가: 리액트 내장이라 설치가 필요 없는 것이 최대 장점이지만 불필요한 리렌더링 때문에 최적화 부담이 늘어난다.
Recoil 평가: atom 단위로 선언하고 훅에 익숙하면 다루기 쉬운데 글 작성 시점 기준으로 베타라는 점이 걸렸다.
선택 결론: 프로젝트와 개발 규모, 라이브러리 안정화를 함께 보고 Context API의 단점을 보완할 정도의 가벼운 라이브러리가 필요해 Jotai를 골랐다.
기본 사용법: atom으로 초깃값을 만들고 useAtom으로 값과 setter를 받는다. useState와 형태가 거의 같아 배우기 쉽다.
atom의 의미: 더 쪼갤 수 없는 하나의 독립된 상태 조각을 뜻하며 내부 구현은 초깃값을 받아 config 객체를 반환하는 함수다.
파생 atom 세 가지: get으로 읽어 변환해 내려주는 읽기 전용, set으로 쓰기만 제공하는 쓰기 전용, 둘 다 가능한 읽기·쓰기 atom이 있다.
메모리 관리: 자바스크립트 엔진은 도달 가능한 값을 메모리에 유지하지만 WeakMap은 키로 쓰인 객체가 수거되므로 누수를 막는다. Jotai는 이 성질로 atom 상태를 추적한다.
구현 컨셉: atom별 상태를 담은 맵에서 상태를 꺼내고, useAtom이 그 상태의 리스너 집합에 콜백을 등록했다가 값이 바뀌면 리스너를 모두 호출하는 구조다.
주의점: useAtom 인자로 atom을 즉석에서 만들면 참조가 매번 달라져 무한 루프에 빠진다. 모듈 수준에 선언하거나 useMemo로 참조를 고정해야 한다.
Provider: atom 값은 Context처럼 컴포넌트 트리에 저장되며, 지정하지 않으면 기본 저장소를 쓰고 스코프를 나누려면 Provider로 감싼다. 같은 atom도 Provider마다 다른 값을 가진다.
유틸 1 atomWithStorage: 새로고침에도 상태를 유지해야 할 때 로컬 스토리지에 저장해주며 세 번째 인자로 다른 스토리지를 넘길 수도 있다.
유틸 2 useUpdateAtom과 useAtomValue: 값을 쓰기만 하거나 읽기만 할 때 useAtom 대신 쓰면 코드가 명확해진다.
유틸 3 useResetAtom: 지정한 초깃값으로 되돌리며 대상 atom이 atomWithReset으로 정의돼 있어야 동작한다.
유틸 4 selectAtom: 객체에서 필요한 값만 뽑아 별도 atom으로 만들면 그 부분이 바뀔 때 해당 컴포넌트만 리렌더링된다.
마무리 평가: 러닝 커브가 낮고 유틸이 다양한데도 번들이 가벼워, React State와 Context API를 고민 중이라면 검토할 만하다고 본다. Redux를 고려한다면 같은 팀이 만든 Zustand도 함께 보라고 덧붙인다.