🧩 01. Jotai 멘탈 모델 — "전역 useState"라는 오해와 진실

🎯 이 섹션을 읽고 나면:

• Jotai가 Redux, Zustand, React Context와 구조적으로 어떻게 다른지 설명할 수 있다.
• atom이 "값"이 아니라 "구독 채널의 설계도"라는 개념을 이해한다.
• SSR 환경(Next.js App Router)에서 Provider-less 모드가 왜 위험한지 설명할 수 있다.

📋 목차

• 📌 이 문서를 읽기 전에
• 🤔 왜 Jotai가 필요한가?
• 🏗️ 비유로 먼저 이해하기
• 🔍 Redux / Context / Zustand / Jotai 비교
• 🧬 Jotai 내부 동작 — WeakMap Store
• ⚡ Provider-less 모드와 그 위험성
• 💥 에러 해결 카탈로그
• 🏁 이번에 배운 내용 총정리
• 📝 마무리 퀴즈
• 🐣 영철이의 퇴근 일기
• 🔗 더 알아보기

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 20분 (전체) / 핵심 파트만: 12분

🗺️ 이 문서의 흐름

[왜 기존 방법이 불편한가] → [atom이라는 새 단위] → [라이브러리 비교] → [내부 동작 원리] → [실무 적용]

🎯 이 문서를 다 읽으면 할 수 있는 것

• "Jotai를 왜 쓰는 거야?" 라는 질문에 자신 있게 설명할 수 있다
• Context 의 리렌더링 문제를 Jotai 가 어떻게 해결하는지 설명할 수 있다
• Provider-less 모드를 언제 쓰고 언제 피해야 하는지 판단할 수 있다

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

영수네 팀은 "개발자 스터디 매칭 커뮤니티" 앱을 Next.js App Router + TanStack Query + TypeScript 로 개발 중이야.

• 영수 님 (PM/백엔드): "일단 Context 로 전역 상태 다 때려넣으면 안 돼? 배포가 코앞인데."
• 영호 님 (프론트 리드): "그러면 검색 필터 하나 바꿀 때마다 유저 아바타까지 반복해서 그려지면서 화면이 툭툭 끊깁니다. 배포 후에 성능 지표가 다 박살 날 거예요."
• 🐣 영철: (조심스럽게) "그럼 Context 를 상태마다 쪼개면 되는 거 아닌가요? 그게 싫으면... Jotai 가 Context 랑 뭐가 달라요? 어차피 전역 상태 공유하는 거잖아요."
• 🦁 영호 님: "Context 를 쪼개면 Provider 지옥이 펼쳐져요. Jotai 가 그 두 문제를 동시에 해결하는데, 어떻게 다른지가 딱 오늘 주제예요."

🤔 왜 Jotai가 필요한가? 🟢

🎯 이 섹션을 읽고 나면:

• React Context 가 왜 성능 문제를 일으키는지 이해한다
• "Provider 지옥" 이 무엇인지 알고, Jotai 가 이를 어떻게 해결하는지 설명할 수 있다

🤔 잠깐, 먼저 생각해봐
영수네 앱에서 로그인 유저 정보, 검색 필터, 모달 열림 여부, 선택된 스터디 ID 를 모두 Context 하나로 관리한다면 어떤 일이 생길까?
"상태 하나가 바뀌면 그걸 쓰는 모든 컴포넌트가 리렌더될 것 같다" 까지 떠올렸으면 충분해.

Context 의 리렌더링 폭탄

영철이가 처음 짠 코드야:

// 🐣 영철: "일단 Context 하나로 다 넣자! 간단하잖아"
interface AppState {
  user: User | null
  searchKeyword: string
  selectedFilter: FilterType
  isModalOpen: boolean
}
 
const AppContext = createContext<AppState>(null!)
 
export function AppProvider({ children }: { children: React.ReactNode }) {
  const [state, setState] = useState<AppState>({
    user: null,
    searchKeyword: '',
    selectedFilter: 'all',
    isModalOpen: false,
  })
  return <AppContext.Provider value={state}>{children}</AppContext.Provider>
}
 
// 검색어만 바꿔도... 이 컴포넌트도 리렌더됨
const UserAvatar = () => {
  const { user } = useContext(AppContext) // user 는 변하지 않았는데!
  return <img src={user?.avatar} alt="avatar" />
}

영호 님의 코드 리뷰:

🦁 영호: "영철 님, `searchKeyword` 만 바꿨는데 `UserAvatar` 까지 리렌더되고 있어요.
         Context 는 값 하나라도 바뀌면 Provider 하위의 모든 구독자를 리렌더시켜요.
         유저 아바타가 검색어랑 무슨 상관이에요?"

Context 를 쪼개면? — Provider 지옥

그래서 Context 를 분리하면:

// 🐣 영철: "쪼개면 되겠지!" (5개 분리 후...)
<UserContext.Provider value={userState}>
  <SearchContext.Provider value={searchState}>
    <FilterContext.Provider value={filterState}>
      <ModalContext.Provider value={modalState}>
        <NotificationContext.Provider value={notificationState}>
          {/* 앱이 커질수록 이 피라미드가 끝없이 깊어짐 */}
          <App />
        </NotificationContext.Provider>
      </ModalContext.Provider>
    </FilterContext.Provider>
  </SearchContext.Provider>
</UserContext.Provider>

📖 용어: Provider 지옥(Provider Hell) — Context 를 상태별로 분리할수록 <Provider> 중첩이 깊어지는 상황. 기능 추가마다 Provider 를 하나씩 추가해야 해서 유지보수가 어려워져.

Jotai 는 이 두 가지 문제를 동시에 해결해:

1. 불필요한 리렌더링 제거 — atom 을 구독하는 컴포넌트만 정확히 업데이트
2. Provider 지옥 탈출 — Provider 없이도 atom 을 어디서든 선언하고 구독

// ✅ 🦁 영호: "Jotai 로 이렇게 바꿔보세요"
import { atom, useAtom, useAtomValue } from 'jotai'
 
const userAtom = atom<User | null>(null)
const searchKeywordAtom = atom('')
const selectedFilterAtom = atom<FilterType>('all')
const isModalOpenAtom = atom(false)
 
// searchKeyword 가 바뀌어도 이 컴포넌트는 리렌더 안 됨!
const UserAvatar = () => {
  const user = useAtomValue(userAtom) // userAtom 만 구독
  return <img src={user?.avatar} alt="avatar" />
}
 
const SearchBar = () => {
  const [keyword, setKeyword] = useAtom(searchKeywordAtom) // searchKeywordAtom 만 구독
  return <input value={keyword} onChange={(e) => setKeyword(e.target.value)} />
}

💡 한 줄로 기억하기
Context 는 "한 방에 방송하는 라디오"야. 채널 하나가 신호를 바꾸면 라디오 전체가 깨어나.
Jotai atom 은 "개인 알림"이야. 내가 구독한 atom 만 나를 깨워.

🏗️ 비유로 먼저 이해하기 🟢

🎯 이 섹션을 읽고 나면:

• atom 이 "값을 담는 그릇" 이 아니라 "구독 채널의 설계도" 에 가깝다는 것을 이해한다
• atom config 와 atom value 의 차이를 설명할 수 있다

🧒 5살에게 설명한다면?
친구들 다 같이 아주 커다란 도화지 하나에 그림을 그린다고 생각해 봐. 한 명이 지우개를 막 쓰면 캔버스 전체가 덜컹거려서 다른 친구들의 그림도 엉망이 되겠지? (이게 기존의 Context 방식이야!)
하지만 Jotai는 각자 '자기만의 작은 전용 스케치북(atom)'을 방마다 가지고 그리는 거야. 내 스케치북을 마구 지우고 새로 그려도 옆방 친구의 스케치북은 전혀 흔들리지 않고 평화롭단다!

atom 은 "값" 이 아니라 "설계도" 다

이게 Jotai 를 이해하는 핵심이야. atom() 함수를 호출하면 값을 만드는 게 아니라 설계도(config)를 만드는 거야.

import { atom } from 'jotai'
 
// 🐣 영철: "이게 값 0을 만드는 거 아닌가요?"
const studyCountAtom = atom(0)
// 🦁 영호: "아니에요. 이건 { init: 0, read: ..., write: ... } 같은 설계도 객체예요.
//          실제 값(0)은 컴포넌트가 useAtom 으로 구독할 때 비로소 store 에 저장됩니다."
 
const Component = () => {
  // 이 순간 store 에 0이 저장되고, 이 컴포넌트가 구독자로 등록됨
  const [count, setCount] = useAtom(studyCountAtom)
  return <div>{count}</div>
}

📖 용어: atom config — atom 의 초기값, 읽기 함수, 쓰기 함수를 담은 불변(immutable) 객체. 컴포넌트가 useAtom 으로 구독하기 전까지는 store 에 값이 없어.

구독 컴포넌트만 업데이트되는 이유

Jotai store (WeakMap 기반)
  ├── studyCountAtom   → { value: 5,        listeners: [StudyCard, StudyCounter] }
  ├── searchKeywordAtom → { value: 'React',  listeners: [SearchBar] }
  └── userAtom          → { value: { name: '영철' }, listeners: [Header, UserAvatar] }

searchKeyword 변경 → SearchBar 만 리렌더 → 나머지는 조용

💡 한 줄로 기억하기
atom 은 "레시피" 야. 레시피를 만든다고 음식이 만들어지는 게 아니듯,
atom() 호출이 값을 저장하는 게 아니야. useAtom 이 호출될 때 비로소 값이 생겨.

🔍 Redux / Context / Zustand / Jotai 비교 🟡

🎯 이 섹션을 읽고 나면:

• 4가지 상태 관리 방식의 철학적 차이를 설명할 수 있다
• 어떤 상황에서 Jotai 를 선택하는 게 유리한지 판단할 수 있다

철학 비교

코드로 비교 — 스터디 좋아요 기능

// ❌ Redux 방식 — 보일러플레이트가 너무 많아
// 🐣 영철: "스터디 좋아요 하나 추가하는데 파일이 3개나 필요해요...?"
const studySlice = createSlice({
  name: 'study',
  initialState: { likeCount: 0 },
  reducers: { increment: (state) => { state.likeCount += 1 } },
})
const likeCount = useSelector((state: RootState) => state.study.likeCount)
dispatch(studySlice.actions.increment())

// 🟡 Zustand 방식 — 하나의 스토어 객체
const useStudyStore = create<StudyStore>((set) => ({
  likeCount: 0,
  increment: () => set((s) => ({ likeCount: s.likeCount + 1 })),
}))
const { likeCount, increment } = useStudyStore()

// ✅ Jotai 방식 — useState 와 동일한 사용감
// 🦁 영호: "이게 전부예요. 선언 두 줄, 사용 한 줄."
const likeCountAtom = atom(0)
 
const LikeButton = () => {
  const [likeCount, setLikeCount] = useAtom(likeCountAtom)
  return (
    <button onClick={() => setLikeCount((prev) => prev + 1)}>
      ❤️ {likeCount}
    </button>
  )
}

언제 Jotai 를 선택하는가?

💡 한 줄로 기억하기
"Jotai 는 Recoil 과 비슷하고, Zustand 는 Redux 와 비슷해."
Bottom-up (작은 것부터 조합) vs Top-down (큰 것을 쪼개기) 의 철학 차이야.

🧬 Jotai 내부 동작 — WeakMap Store 🟡

🎯 이 섹션을 읽고 나면:

• Jotai store 가 WeakMap 기반이어서 메모리 누수 없이 동작하는 이유를 설명할 수 있다
• atom 의 구독/알림 메커니즘이 어떻게 선택적 리렌더링을 가능하게 하는지 이해한다

🤔 잠깐, 먼저 생각해봐
atom 을 구독하던 컴포넌트가 unmount 되면, 그 atom 의 값은 어떻게 될까?
"가비지 컬렉션 될 것 같다" 까지 떠올렸으면 충분해.

Jotai Store 의 구조 (단순화)

// Jotai 내부 의사 코드 (실제 코드는 더 복잡해)
type Store = {
  stateMap: WeakMap<Atom<unknown>, AtomState>
}
 
type AtomState = {
  value: unknown                // 현재 값
  deps: Set<Atom<unknown>>      // 이 atom 이 의존하는 atom 들 (derived atom 용)
  listeners: Set<() => void>    // 값 변경 시 호출할 리스너 (리렌더 트리거)
}

값이 바뀔 때 일어나는 일

setLikeCount(prev => prev + 1) 호출
  ↓
store 의 likeCountAtom 값 업데이트
  ↓
likeCountAtom.listeners 순회
  ↓
각 컴포넌트의 리렌더링 스케줄링 (내부적으로 useReducer dispatch 호출)
  ↓
likeCountAtom 을 구독 중인 컴포넌트만 리렌더링
  ↓
다른 atom 을 구독 중인 컴포넌트는 그대로

WeakMap 을 쓰는 이유 — 메모리 누수 방지

WeakMap 의 핵심 특성: 키(key)에 대한 강한 참조가 없으면 자동으로 가비지 컬렉션.

// StudyCard 가 unmount 되면 likeCountAtom 의 구독자 목록에서 자동 제거
// 구독자가 0이 되면 likeCountAtom 의 값도 GC 대상이 됨
const StudyCard = () => {
  const [likeCount] = useAtom(likeCountAtom) // 구독 시작
  // unmount 시 → listeners 에서 제거 → 참조 없으면 GC
  return <div>{likeCount}</div>
}

💡 한 줄로 기억하기
Jotai store 는 "자동 정리되는 구독 관리소" 야.
열쇠(atom config)를 반납하면(컴포넌트 unmount), 그 보관함(store entry)은 자동 삭제돼.

⚡ Provider-less 모드와 그 위험성 🟡

🎯 이 섹션을 읽고 나면:

• Provider 없이도 Jotai 가 동작하는 이유를 설명할 수 있다
• SSR(Next.js App Router)에서 Provider-less 모드가 왜 위험한지 설명할 수 있다

Provider-less 모드란?

Jotai 는 <Provider> 없이도 기본 동작해. 내부적으로 전역 싱글턴 store 가 있거든:

// 브라우저 CSR 에서는 이게 잘 동작함
const App = () => (
  // 🐣 영철: "Provider 없어도 되네? 편하다!"
  <StudyList /> // 내부적으로 전역 싱글턴 store 사용
)

⚠️ SSR 에서는 Provider 없이 절대 쓰지 마라

// ❌ 위험! Next.js App Router SSR 에서 Provider 없이 쓰면...
// 🐣 영철: (아무것도 모르고) "그냥 전역 store 써도 되겠지"
 
// 1번 요청 (영철의 세션): userAtom 에 { name: '영철', role: 'admin' } 저장
// 2번 요청 (영수의 세션): 전역 store 에 영철 데이터가 남아있음!
// → 영수가 로그인했는데 화면에 "영철" 이름이 보일 수도 있음
// → 이건 단순 버그가 아니라 개인정보 보안 사고야

해결책: layout.tsx 에서 반드시 Provider 로 감싸기

// ✅ app/layout.tsx
// 🦁 영호: "SSR 에선 이렇게 해야 요청마다 store 가 격리됩니다"
'use client'
 
import { Provider } from 'jotai'
 
export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="ko">
      <body>
        {/* Provider 가 각 요청마다 새 store 인스턴스를 만들어 격리 */}
        <Provider>
          {children}
        </Provider>
      </body>
    </html>
  )
}

💡 한 줄로 기억하기
Provider-less 모드는 브라우저에서만 써. 서버에서 전역 store 는 "공용 냉장고" 야 — 다른 사람 음식이 섞여.

🔗 연결 고리
Provider 의 스코프 제어와 createStore 직접 생성은 08. Provider 와 스코프 에서 깊게 다뤄.

💥 에러 해결 카탈로그

에러 메시지가 뜨면 Ctrl+F 로 검색해봐. 대부분 여기 있어.

❌ 무한 리렌더링 (렌더 함수 내 atom 생성)

증상: 컴포넌트가 멈추지 않고 계속 리렌더됨, 브라우저 탭 멈춤

원인:

// 🐣 영철의 실수 — 렌더마다 새 atom config 생성
const StudyItem = ({ id }: { id: string }) => {
  const itemAtom = atom({ id }) // ❌ 렌더마다 새 객체 → 무한 루프
  const [item] = useAtom(itemAtom)
}

해결책:

// ✅ useMemo 로 atom config 를 메모이제이션
const StudyItem = ({ id }: { id: string }) => {
  const itemAtom = useMemo(() => atom({ id }), [id])
  const [item] = useAtom(itemAtom)
}
// 또는 모듈 최상단에 선언 (id 가 고정일 때)

❌ SSR 에서 상태 공유 버그 (서버 요청 간 오염)

증상: A 유저가 로그인했는데 B 유저의 정보가 보임

원인: Next.js App Router 에서 Provider 없이 전역 store 사용

해결책:

// app/layout.tsx 에 Provider 추가 (위 예시 참고)

❌ useAtom 이 값을 반환하지 않음 (undefined)

원인: atom 초기값이 undefined 이거나 타입 가드 누락

해결책:

const userAtom = atom<User | null>(null) // 명확한 초기값
 
const UserAvatar = () => {
  const user = useAtomValue(userAtom)
  if (!user) return <Skeleton /> // 타입 가드 필수
  return <img src={user.avatar} alt={user.name} />
}

🏁 이번에 배운 내용 총정리

📋 Jotai 핵심 개념 요약

⚠️ 절대 하지 말 것

📝 마무리 퀴즈

Q1. 🔴 시니어 면접 질문 (영철의 면접 도전)

영철이가 이직 면접을 봤어. 면접관이 물었어:
"Jotai 의 atom() 호출 직후 store 에 값이 저장되나요? 컴포넌트에서 어떻게 값이 초기화되는지 설명해보세요."

• A) atom(0) 을 호출하는 순간 전역 store 에 0 이 즉시 저장된다
• B) atom(0) 은 설계도 객체를 반환할 뿐이며, 컴포넌트에서 useAtom 을 호출할 때 store 에 값이 저장되고 구독이 시작된다
• C) atom(0) 은 React useState(0) 과 동일하게 동작한다
• D) Provider 를 선언해야 atom 이 초기화된다

✅ 정답: B

💡 상세 해설:

• 원리 설명: atom() 은 { init, read, write } 형태의 불변 설계도 객체를 반환해. 실제 값은 컴포넌트가 useAtom(myAtom) 을 처음 호출할 때 store 의 WeakMap 에 저장돼. 컴포넌트가 unmount 되고 다른 참조가 없으면 GC 로 자동 정리돼.
• 오답 피드백: A 는 틀렸어. atom() 호출 시점엔 store 에 아무것도 없어. C 는 사용감이 비슷하지만 useState 는 컴포넌트 내부 상태고 atom 은 외부 store 를 통해 여러 컴포넌트가 공유하는 상태야. D 는 Provider-less 모드로도 동작해 (단, SSR 에선 Provider 필수).
• 📌 핵심 기억법: "atom 은 레시피, useAtom 은 요리 시작." 레시피만 있으면 음식이 안 생겨.

Q2. 🔥 긴급 디버깅 (영수의 호통)

영수 님이 슬랙에 메시지를 보냈어: "배포하고 나서 A 유저로 로그인했는데 화면에 B 유저 이름이 보인다. 당장 고쳐."
영철이가 확인하니 코드는 이랬어:

// app/layout.tsx
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="ko">
      <body>{children}</body>  {/* Provider 없음 */}
    </html>
  )
}
 
// app/page.tsx
const userAtom = atom<User | null>(null)

제일 먼저 해야 할 수정은?

• A) userAtom 의 초기값을 null 에서 {} 로 바꾼다
• B) layout.tsx 에 <Provider> 를 추가해서 요청마다 store 를 격리한다
• C) userAtom 을 컴포넌트 내부로 이동시킨다
• D) 서버 컴포넌트에서 atom 을 사용하지 않도록 한다

✅ 정답: B

💡 상세 해설:

• 원리 설명: Next.js App Router 의 SSR 환경에서 Provider 없이 전역 store 를 쓰면, 서버 인스턴스 간에 store 가 공유돼. A 유저의 요청이 store 에 값을 쓰면, B 유저의 요청에서 그 값을 읽을 수 있어. <Provider> 를 추가하면 요청마다 새 store 인스턴스가 생성되어 완전히 격리돼.
• 오답 피드백: A, C, D 는 문제의 근본 원인(store 격리 실패)을 해결하지 못해.
• 📌 핵심 기억법: "SSR + Jotai = 반드시 Provider." 공용 냉장고에 내 음식을 넣으면 누군가 가져가.

Q3. 친구에게 설명한다면?

Jotai atom 이 React Context 보다 리렌더링이 적은 이유를 개발자 친구에게 한 문장으로 설명해봐.
(정답 없어, 본인만의 비유로 설명할 수 있으면 충분해.)

예시 답변:

"Context 는 값 하나가 바뀌면 그 Context 를 구독하는 모든 컴포넌트를 깨우는 '단체 카톡 알림' 이고, Jotai atom 은 내가 팔로우한 atom 만 바뀔 때 나를 깨우는 '개인 팔로우 알림' 이야."

💡 이 비유를 직접 만들었다면: Jotai 의 핵심 원리를 이해한 거야. 다음 가이드로 넘어가도 충분해! 🎉

🐣 영철이의 퇴근 일기

퇴근길 지하철 안. 핸드폰 메모장을 열었다.

오늘 영호 님한테 처음으로 Jotai 를 제대로 배운 날이었다. 솔직히 처음엔 "그냥 전역 useState 아닌가?" 싶었는데... 완전히 틀렸더라고.

💡 오늘의 교훈: "atom 은 값이 아니라 설계도다. useAtom 이 호출될 때 비로소 값이 생기고, 구독이 시작된다."

Context 로 전부 때려넣었다가 영숙 님한테 "필터 바꿀 때마다 화면 전체가 깜빡거려요" 라는 피드백 받고... 그때 얼마나 창피했는지. WeakMap 이 구독자를 관리한다는 것도, SSR 에서 Provider 없이 쓰면 다른 유저 데이터가 보일 수도 있다는 것도 — 오늘 처음 알았다.

영호 님이 "영철 님, 이건 단순 버그가 아니라 보안 사고예요" 라고 했을 때 등줄기가 서늘했다. 다음에는 내가 먼저 Provider 챙겨야지.

오늘 배운 거 까먹기 전에 집 가서 한 번 더 정리해야겠다. 오늘따라 지하철이 왜 이렇게 느리냐... 🚇

🔗 더 알아보기

• 02. atom() 완전 정복 — primitive atom 과 핵심 훅
• 08. Provider 와 스코프 — atom 의 생명주기 제어
• 11. Next.js App Router + Jotai SSR 전략