💡 07. atom 설계 전략 — 파일 구조와 책임 분리

📋 개요

도메인별 atom 파일 분리, 네이밍 컨벤션, 순환 의존성 방지, atoms/hooks 레이어 설계 전략을 배웁니다.

🎯 이 섹션을 읽고 나면:

도메인별 atom 파일 분리 전략을 실무 프로젝트에 적용할 수 있다.

순환 의존성이 생기는 원인과 해결책을 설명할 수 있다.

atoms/ 레이어와 hooks/ 레이어의 역할을 명확히 구분할 수 있다.

📋 목차

📌 이 문서를 읽기 전에
🤔 왜 atom 구조 설계가 중요한가?
🏷️ 네이밍 컨벤션
🗂️ 도메인별 파일 분리 전략
🔄 순환 의존성 방지
🎯 atoms vs hooks 레이어 설계
🏢 Feature 단위 atom 슬라이싱 (대규모 앱)
💥 에러 해결 카탈로그
🏁 이번에 배운 내용 총정리
📝 마무리 퀴즈
🐣 영철이의 퇴근 일기
🔗 더 알아보기

📌 이 문서를 읽기 전에

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

🗺️ 이 문서의 흐름

[atoms.ts 하나에 100개 지옥] → [네이밍 컨벤션] → [도메인별 분리] → [순환 의존성 방지] → [atoms/hooks 레이어] → [Feature 슬라이싱]

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

영수네 앱이 슬슬 커지면서 atom 관리가 문제가 된 날이야.

🦁 영호 님: (스프린트 회의에서) "이번 스프린트에 기술 부채 하나 정리해야 할 것 같아요. atoms.ts 파일 한 번 열어볼게요."

(파일을 열자 스크롤이 끝없이 내려간다)

🐣 영철: (조용히) "...저도 지금 뭐가 어디 있는지 모르겠어요."

👔 영수 님: "atom 이 100개가 넘어가는데 파일이 하나야? 찾을 수가 있어?"

🦁 영호 님: "맞아요. 지금 searchKeywordAtom 이 auth 관련 코드 사이에 끼어있고, isModalOpenAtom 이 스터디 fetch 로직 밑에 있어요. 리팩토링 필요해요."

🐣 영철: (솔직하게) "제가 처음에 atom 추가할 때마다 그냥 파일 맨 밑에 붙였어요... 죄송합니다."

🦁 영호 님: "지금 알았으면 된 거예요. 오늘 같이 정리해봅시다. 도메인별로 나누는 전략부터 시작할게요."

🤔 왜 atom 구조 설계가 중요한가? 🟢

🎯 이 섹션을 읽고 나면:

atoms.ts 하나에 모든 atom 을 쌓는 방식의 문제점을 구체적으로 설명할 수 있다

구조 설계가 코드 유지보수성에 미치는 영향을 이해한다

무질서한 단일 파일의 문제들

// ❌ 🐣 영철의 atoms.ts — 실제로 이랬음 (100개 이상)
// src/atoms.ts
 
// 인증 관련
const userAtom = atom<User | null>(null)
const isLoggedInAtom = atom((get) => get(userAtom) !== null)
 
// 스터디 목록
const studyListAtom = atom<Study[]>([])
 
// 검색 (인증 관련 코드들 사이에 끼어있음)
const searchKeywordAtom = atom('')
 
// 또 인증 관련 (검색 코드 뒤에 뒤늦게 추가됨)
const authTokenAtom = atom<string | null>(null)
 
// 모달 (스터디 코드 중간에)
const isCreateStudyModalOpenAtom = atom(false)
 
// 스터디 필터 (모달 코드 다음에)
const selectedTagsAtom = atom<string[]>([])
const sortByAtom = atom<'latest' | 'popular'>('latest')
 
// 채팅 (필터 코드 사이에 끼어있음)
const chatRoomIdAtom = atom<string | null>(null)
 
// ... 이런 식으로 80개 더 ...

영호 님이 코드 리뷰에서 지적한 문제들:

🦁 영호: "지금 이 파일에는 세 가지 심각한 문제가 있어요:

1. 관심사 분리 실패: auth, study, search, chat 이 한 파일에 뒤섞여 있어요.
   'searchKeywordAtom 어디 있어?' 라고 물으면 전체 검색을 해야 해요.

2. 팀 협업 충돌: 영철 님이 스터디 atom 추가하고, 내가 인증 atom 수정하면
   매번 같은 파일에 git conflict 가 나요.

3. 번들 경계 불명확: 검색 기능만 쓰는 페이지도 chat, auth 관련 atom 을
   전부 import 하게 돼요. 트리 쉐이킹이 힘들어져요."

💡 한 줄로 기억하기
atom 파일이 하나라는 건 "팀 전체가 하나의 서랍을 쓰는 것" 이야. 누가 뭘 넣었는지, 어디 있는지 찾기 어렵고 충돌도 잦아져.

🏷️ 네이밍 컨벤션 🟢

🎯 이 섹션을 읽고 나면:

*Atom 접미사 컨벤션이 왜 팀 협업에 도움이 되는지 이해한다

좋은 atom 이름과 나쁜 atom 이름을 구분할 수 있다

`*Atom` 접미사 — 식별의 기준

// ✅ 권장 — 접미사 Atom 으로 끝나도록
const searchKeywordAtom = atom('')
const userAtom = atom<User | null>(null)
const studyListAtom = atom<Study[]>([])
const isModalOpenAtom = atom(false)
const filteredStudyListAtom = atom((get) => ...)
const toggleStudyLikeAtom = atom(null, (_, set, id: string) => ...)
 
// ❌ 비권장 — atom 인지 식별 어려움
const searchKeyword = atom('')    // 일반 변수인지 atom 인지 불명확
const user = atom<User | null>(null)  // 같은 이름의 User 객체와 혼동
const STUDY_LIST = atom<Study[]>([])  // 상수처럼 보임

이름 자체로 역할이 드러나는 패턴

// 상태 성격이 이름에서 명확히 보여야 해
const isLoadingAtom = atom(false)           // boolean 상태 — is/has 접두사
const selectedStudyIdAtom = atom<string | null>(null)  // 선택 상태 — selected 접두사
const filteredStudyListAtom = atom(...)     // 파생 상태 — filtered/sorted 접두사
const toggleLikeAtom = atom(null, ...)      // action atom — 동사 접두사
 
// 🦁 영호: "이름만 봐도 '이건 boolean', '이건 action', '이건 derived' 가 보여야 해요"

🗂️ 도메인별 파일 분리 전략 🟡

🎯 이 섹션을 읽고 나면:

실무 프로젝트에 바로 적용 가능한 atom 파일 분리 구조를 알 수 있다

각 파일에 어떤 atom 이 들어가야 하는지 판단할 수 있다

영호 님이 제안한 영수네 팀의 파일 구조

src/atoms/
├── auth.ts        ← 인증 관련 atom
├── study.ts       ← 스터디 도메인 atom
├── search.ts      ← 검색 관련 atom
├── ui.ts          ← UI 상태 atom (모달, 탭 등)
├── chat.ts        ← 채팅 관련 atom
└── index.ts       ← 공개 API (re-export)

// src/atoms/auth.ts
import { atom } from 'jotai'
import type { User } from '@/types'
 
// 🦁 영호: "auth 도메인에 속하는 atom 만 여기에"
export const userAtom = atom<User | null>(null)
export const authTokenAtom = atom<string | null>(null)
export const isLoggedInAtom = atom((get) => get(userAtom) !== null)
export const userRoleAtom = atom((get) => get(userAtom)?.role ?? 'guest')

// src/atoms/study.ts
import { atom } from 'jotai'
import { searchKeywordAtom, selectedTagsAtom } from './search'
// ← search atom 에 의존 (auth 에는 의존 안 함)
import type { Study } from '@/types'
 
// 🦁 영호: "스터디 도메인 atom. 파생 atom 은 search atom 에 의존해도 OK"
export const studyListAtom = atom<Study[]>([])
export const selectedStudyIdAtom = atom<string | null>(null)
 
// search atom 으로부터 파생
export const filteredStudyListAtom = atom((get) => {
  const studies = get(studyListAtom)
  const keyword = get(searchKeywordAtom)
  const tags = get(selectedTagsAtom)
 
  return studies
    .filter((s) => s.title.toLowerCase().includes(keyword.toLowerCase()))
    .filter((s) => tags.length === 0 || tags.some((t) => s.tags.includes(t)))
})

// src/atoms/search.ts
import { atom } from 'jotai'
 
// 🦁 영호: "검색 관련 순수 상태. 다른 도메인 atom 에 의존하지 않아요"
export const searchKeywordAtom = atom('')
export const selectedTagsAtom = atom<string[]>([])
export const sortByAtom = atom<'latest' | 'popular'>('latest')
export const isSearchActiveAtom = atom((get) => get(searchKeywordAtom).length > 0)

// src/atoms/ui.ts
import { atom } from 'jotai'
 
// 🦁 영호: "UI 상태는 비즈니스 로직과 무관하게 독립적으로 유지해요"
export const isCreateStudyModalOpenAtom = atom(false)
export const isProfileMenuOpenAtom = atom(false)
export const activeTabAtom = atom<'explore' | 'my-studies' | 'chat'>('explore')
export const sidebarWidthAtom = atom(280)

// src/atoms/index.ts — 공개 API
// 🦁 영호: "외부에서는 이 index.ts 에서만 import 하도록 강제하면
//          내부 구조가 바뀌어도 import 경로를 수정할 필요 없어요"
export * from './auth'
export * from './study'
export * from './search'
export * from './ui'
export * from './chat'

Before / After 비교

// ❌ Before — 모든 파일이 atoms.ts 를 import
import { userAtom, searchKeywordAtom, isModalOpenAtom } from '@/atoms'
// atoms.ts 에 100개 atom 이 있고, 이 파일에서 3개만 씀
// → 번들러가 100개를 전부 포함할 가능성
 
// ✅ After — 필요한 도메인 파일만 import (tree-shaking 친화적)
import { userAtom } from '@/atoms/auth'
import { searchKeywordAtom } from '@/atoms/search'
import { isCreateStudyModalOpenAtom } from '@/atoms/ui'
// 또는 index.ts 에서 — 경로 일관성 유지
import { userAtom, searchKeywordAtom, isCreateStudyModalOpenAtom } from '@/atoms'

🔄 순환 의존성 방지 🔴

🎯 이 섹션을 읽고 나면:

순환 의존성이 어떻게 발생하는지 이해한다

공통 atoms 분리로 순환 의존성을 해결하는 법을 알 수 있다

순환 의존성 발생 시나리오

auth.ts       → study.ts 를 import (스터디 atom 에 user 관련 필터 적용)
study.ts      → auth.ts 를 import (멤버 정보 가져오기)

→ 순환 의존성 발생! 모듈 로드 순서 불확실 → 런타임 에러

// ❌ 순환 의존성이 생기는 패턴
// src/atoms/auth.ts
import { selectedStudyIdAtom } from './study'  // study.ts 를 import
 
export const userStudyRoleAtom = atom((get) => {
  const studyId = get(selectedStudyIdAtom) // study atom 에 의존
  const user = get(userAtom)
  // ...
})
 
// src/atoms/study.ts
import { userAtom } from './auth'  // auth.ts 를 import ← 순환!
 
export const studyMembersAtom = atom((get) => {
  const user = get(userAtom)  // auth atom 에 의존
  // ...
})

해결책: 공통 atoms 를 별도 파일로 분리

src/atoms/
├── core.ts    ← 다른 atom 에 의존하지 않는 기반 atom (순환 의존 없음)
├── auth.ts    ← core.ts 에만 의존
├── study.ts   ← core.ts 에만 의존
├── derived.ts ← auth.ts, study.ts 에 의존하는 파생 atom
└── index.ts

// src/atoms/core.ts — 모든 파일의 기반
// 🦁 영호: "다른 파일에 의존하지 않는 순수 기반 atom 만 여기에"
export const userAtom = atom<User | null>(null)
export const studyListAtom = atom<Study[]>([])
export const searchKeywordAtom = atom('')

// src/atoms/auth.ts — core.ts 에만 의존
import { userAtom } from './core'
 
export const isLoggedInAtom = atom((get) => get(userAtom) !== null)
export const userRoleAtom = atom((get) => get(userAtom)?.role ?? 'guest')

// src/atoms/study.ts — core.ts 에만 의존
import { studyListAtom, searchKeywordAtom } from './core'
 
export const filteredStudyListAtom = atom((get) => {
  const studies = get(studyListAtom)
  const keyword = get(searchKeywordAtom)
  return studies.filter((s) => s.title.includes(keyword))
})

// src/atoms/derived.ts — auth.ts, study.ts 양쪽에 의존
// 🦁 영호: "두 도메인을 결합한 파생 상태는 별도 파일에 격리해요"
import { userAtom } from './auth'
import { studyListAtom } from './study'
 
export const myStudiesAtom = atom((get) => {
  const user = get(userAtom)
  const studies = get(studyListAtom)
  if (!user) return []
  return studies.filter((s) => s.members.some((m) => m.id === user.id))
})

💡 한 줄로 기억하기
순환 의존성의 해법은 항상 같아. "두 모듈이 서로를 바라보면, 두 모듈이 공통으로 바라볼 세 번째 모듈을 만들어."

🎯 atoms vs hooks 레이어 설계 🟡

🎯 이 섹션을 읽고 나면:

atoms/ 레이어와 hooks/ 레이어의 책임 차이를 명확히 설명할 수 있다

커스텀 훅으로 atom 을 캡슐화하는 실무 패턴을 적용할 수 있다

두 레이어의 역할 분리

src/
├── atoms/         ← "무엇을 저장할 것인가" — 순수한 상태 선언
│   ├── auth.ts
│   ├── study.ts
│   └── search.ts
│
└── hooks/         ← "컴포넌트에게 어떤 인터페이스를 줄 것인가" — 비즈니스 로직 조합
    ├── useStudySearch.ts
    ├── useAuth.ts
    └── useStudyActions.ts

// src/hooks/useStudySearch.ts
// 🦁 영호: "컴포넌트는 atom 을 직접 쓰는 것보다 이 훅을 쓰는 게 좋아요.
//          atom 이 바뀌어도 컴포넌트 코드를 수정할 필요가 없거든요."
import { useAtom, useAtomValue, useSetAtom } from 'jotai'
import { searchKeywordAtom, selectedTagsAtom, sortByAtom } from '@/atoms/search'
import { filteredStudyListAtom } from '@/atoms/study'
import { resetSearchAtom } from '@/atoms/search'
 
export function useStudySearch() {
  const [keyword, setKeyword] = useAtom(searchKeywordAtom)
  const [selectedTags, setSelectedTags] = useAtom(selectedTagsAtom)
  const [sortBy, setSortBy] = useAtom(sortByAtom)
  const results = useAtomValue(filteredStudyListAtom)
  const resetSearch = useSetAtom(resetSearchAtom)
 
  const addTag = (tag: string) => {
    setSelectedTags((prev) => [...new Set([...prev, tag])])
  }
 
  const removeTag = (tag: string) => {
    setSelectedTags((prev) => prev.filter((t) => t !== tag))
  }
 
  return {
    keyword,
    setKeyword,
    selectedTags,
    addTag,
    removeTag,
    sortBy,
    setSortBy,
    results,
    resetSearch,
    hasActiveFilter: keyword.length > 0 || selectedTags.length > 0,
  }
}

// 컴포넌트 — atom 을 직접 알 필요 없음
const StudySearchPanel = () => {
  // 🐣 영철: "컴포넌트에서 atom import 를 하나도 안 해도 되는 거예요?"
  // 🦁 영호: "맞아요. 훅이 atom 의 복잡성을 감춰줘요.
  //          나중에 atom 이름이 바뀌어도 이 컴포넌트는 수정 안 해도 돼요."
  const { keyword, setKeyword, results, selectedTags, addTag, removeTag, hasActiveFilter } =
    useStudySearch()
 
  return (
    <div>
      <input value={keyword} onChange={(e) => setKeyword(e.target.value)} placeholder="검색..." />
      <TagFilter tags={selectedTags} onAdd={addTag} onRemove={removeTag} />
      {hasActiveFilter && <span>{results.length}개 결과</span>}
      <StudyList studies={results} />
    </div>
  )
}

// src/hooks/useAuth.ts
import { useAtom, useAtomValue, useSetAtom } from 'jotai'
import { userAtom, isLoggedInAtom, authTokenAtom } from '@/atoms/auth'
 
export function useAuth() {
  const [user, setUser] = useAtom(userAtom)
  const isLoggedIn = useAtomValue(isLoggedInAtom)
  const setToken = useSetAtom(authTokenAtom)
 
  const login = async (credentials: LoginCredentials) => {
    const { user, token } = await authApi.login(credentials)
    setUser(user)
    setToken(token)
  }
 
  const logout = () => {
    setUser(null)
    setToken(null)
  }
 
  return { user, isLoggedIn, login, logout }
}

atoms/ 레이어의 순수성 유지

// ✅ atoms/ 에는 이것만 — 상태 선언과 파생 계산
// src/atoms/search.ts
export const searchKeywordAtom = atom('')
export const selectedTagsAtom = atom<string[]>([])
 
// write-only reset atom (action 에 해당하지만 순수한 상태 조작)
export const resetSearchAtom = atom(null, (_get, set) => {
  set(searchKeywordAtom, '')
  set(selectedTagsAtom, [])
})
 
// ❌ atoms/ 에는 이런 것이 들어가면 안 됨
// fetch, console.log, router.push 같은 사이드 이펙트
// 컴포넌트 라이프사이클 연동 (useEffect 등)
// 이런 건 hooks/ 레이어에서 처리

🏢 Feature 단위 atom 슬라이싱 (대규모 앱) 🔴

🎯 이 섹션을 읽고 나면:

Feature 기반 atom 구조와 도메인 기반 구조의 차이를 이해한다

대규모 앱에서 Feature 슬라이싱이 왜 유리한지 설명할 수 있다

Feature 슬라이싱 구조

src/features/
├── auth/
│   ├── atoms/
│   │   ├── user.ts
│   │   └── session.ts
│   ├── hooks/
│   │   └── useAuth.ts
│   └── components/
│       ├── LoginForm.tsx
│       └── UserAvatar.tsx
│
├── study/
│   ├── atoms/
│   │   ├── list.ts
│   │   ├── detail.ts
│   │   └── filter.ts
│   ├── hooks/
│   │   ├── useStudyList.ts
│   │   └── useStudyActions.ts
│   └── components/
│       ├── StudyCard.tsx
│       └── StudyList.tsx
│
└── chat/
    ├── atoms/
    │   └── chatRoom.ts
    ├── hooks/
    │   └── useChatRoom.ts
    └── components/
        └── ChatWindow.tsx

// src/features/study/atoms/filter.ts
// 🦁 영호: "feature 내부에서만 쓰는 atom 은 feature 안에 격리해요"
import { atom } from 'jotai'
 
export const studyFilterAtom = atom({
  keyword: '',
  tags: [] as string[],
  sortBy: 'latest' as 'latest' | 'popular',
  category: null as string | null,
})
 
// feature 내부에서만 쓰는 derived atom
export const hasActiveFilterAtom = atom((get) => {
  const filter = get(studyFilterAtom)
  return filter.keyword.length > 0 || filter.tags.length > 0 || filter.category !== null
})

전역 공유 vs Feature 로컬 — 선택 기준

어디에 atom 을 배치할지 판단하는 기준:

✅ src/atoms/ (전역)
  - 두 개 이상의 feature 에서 사용
  - 앱 전체 수명 동안 유지
  - 예: userAtom, authTokenAtom

✅ src/features/{feature}/atoms/ (로컬)
  - 이 feature 에서만 사용
  - feature 의 라이프사이클과 동일
  - 예: studyFilterAtom, chatRoomStateAtom

💡 팁 처음에는 전역 src/atoms/ 으로 시작하고, feature 가 독립적으로 배포/분리될 가능성이 보이면 feature 내부로 이동하는 전략이 좋아. 과도한 사전 설계보다 점진적 리팩토링이 현실적이야.

💥 에러 해결 카탈로그

❌ ReferenceError: Cannot access 'atomX' before initialization

증상: 앱 시작 시 "Cannot access before initialization" 에러

원인:

// src/atoms/study.ts
import { userFilteredStudiesAtom } from './derived'
// derived.ts 가 study.ts 를 import 하고, study.ts 가 derived.ts 를 import → 순환!

해결책:

// 공통 기반 atom 을 core.ts 로 분리 (위 순환 의존성 섹션 참고)
// 또는 derived atom 을 사용하는 파일로 이동 (인라인화)

❌ ESLint import/no-cycle 경고

증상: ESLint 가 순환 import 를 경고

해결책:

// .eslintrc.js 에 import/no-cycle 규칙 추가 (사전 방지)
rules: {
  'import/no-cycle': 'error'
}
 
// 경고 발생 시 위의 "순환 의존성 방지" 섹션의 해결책 적용

❌ atom 을 어디서 import 해야 할지 모르겠음

증상: 팀원이 각자 다른 경로로 atom 을 import 해서 일관성 없음

해결책:

// src/atoms/index.ts 를 공개 API 로 설정 후
// eslint 의 no-restricted-imports 로 직접 import 금지
 
// .eslintrc.js
rules: {
  'no-restricted-imports': ['error', {
    patterns: ['@/atoms/*'], // 하위 파일 직접 import 금지
  }],
}
 
// ✅ 허용
import { userAtom } from '@/atoms'
 
// ❌ 금지 (eslint 에러)
import { userAtom } from '@/atoms/auth'

🏁 이번에 배운 내용 총정리

📋 atom 구조 설계 원칙

원칙	설명
*`Atom` 접미사**	모든 atom 이름에 `Atom` 접미사 → 즉각적인 식별
도메인별 파일 분리	`auth.ts`, `study.ts`, `search.ts`, `ui.ts` 등
의존성 방향 단일화	A → B (OK), A ↔ B (순환 — 금지)
공통 분리	순환 발생 시 공통 부분을 `core.ts` 로 추출
atoms/hooks 레이어	atoms 는 순수 상태 선언, hooks 는 비즈니스 로직 조합

⚠️ 절대 하지 말 것

상황	❌ 나쁜 예	✅ 좋은 예
파일 구조	모든 atom 을 `atoms.ts` 하나에	도메인별로 분리
순환 의존성	A 가 B 를 import, B 가 A 를 import	공통 `core.ts` 로 분리
atoms 레이어	fetch, sideEffect 를 atoms 에서 실행	사이드 이펙트는 hooks 레이어로

📝 마무리 퀴즈

Q1. 🏗️ 아키텍처 설계 (팀 전체 회의)

영수네 팀이 기술 부채 회의를 했어. 현재 atoms.ts 파일 하나에 120개의 atom 이 있어.
영호 님이 제안한 리팩토링 방향으로 가장 적절한 것은?

A) atom 의 숫자를 줄이기 위해 여러 atom 을 하나의 큰 객체 atom 으로 합친다
B) 도메인별(auth, study, search, ui)로 파일을 분리하고, index.ts 에서 re-export 하여 공개 API 를 일원화한다
C) atom 을 쓰는 컴포넌트 파일 안에 각각 선언한다
D) 모든 atom 을 하나의 Redux 스토어로 마이그레이션한다

✅ 정답: B

💡 상세 해설:

원리 설명: 도메인별 파일 분리는 세 가지 문제를 동시에 해결해. (1) 관심사 분리: 같은 도메인 atom 이 한 파일에 → 찾기 쉬움. (2) 팀 협업: 각자 다른 파일에서 작업 → git conflict 감소. (3) 번들 최적화: 필요한 도메인 파일만 import 가능. index.ts re-export 는 내부 구조 변경 시 외부 import 경로를 바꾸지 않아도 되게 해줘.
오답 피드백: A 는 오히려 컴포넌트 리렌더링 최적화가 깨져 — Jotai 의 핵심 장점인 원자 단위 구독이 사라져. C 는 atom 이 컴포넌트 수만큼 분산 → 재사용 불가. D 는 완전히 다른 라이브러리로의 전환 — 기술 부채 해결이 아니야.
📌 핵심 기억법: "atom 도 코드야. 코드는 관심사별로 모아야 해."

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

배포 후 영수 님이 연락왔어: "앱 처음 로드할 때 콘솔에 ReferenceError 가 간헐적으로 나요."
영철이가 코드를 보니:

// atoms/auth.ts
import { selectedStudyAtom } from './study'
export const userStudyRoleAtom = atom((get) => {
  const studyId = get(selectedStudyAtom)?.id
  const user = get(userAtom)
  // ...
})
 
// atoms/study.ts
import { userAtom } from './auth'
export const studyMembersAtom = atom((get) => {
  const user = get(userAtom)
  // ...
})

원인과 해결책은?

A) atom 의 초기값이 잘못됐다. 초기값을 null 에서 undefined 로 바꾼다
B) auth.ts 와 study.ts 사이에 순환 의존성이 있다. 공통 기반 atom 을 core.ts 로 분리한다
C) Provider 가 없어서 생기는 문제다. layout.tsx 에 Provider 를 추가한다
D) atom 이 너무 많아서 생기는 문제다. atom 수를 줄인다

✅ 정답: B

💡 상세 해설:

원리 설명: auth.ts 가 study.ts 를 import 하고, study.ts 가 auth.ts 를 import 하면 순환 의존성이 생겨. JavaScript 모듈 로더는 순환 참조가 있을 때 일부 모듈이 완전히 초기화되기 전에 사용되는 상황이 생기고, 이 때 "Cannot access before initialization" 에러가 나. 해결책은 userAtom 처럼 두 파일이 공통으로 필요한 atom 을 core.ts 같은 별도 파일로 이동해서 A → core, B → core 의 단방향 의존성을 만드는 거야.
📌 핵심 기억법: "순환 의존성 = 둘이 서로 바라봄. 해결책 = 공통으로 바라볼 세 번째를 만들기."

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

atoms/ 레이어와 hooks/ 레이어를 분리하는 이유를 개발자 친구에게 설명해봐.

예시 답변:

"atoms/ 는 '상태를 어떻게 저장할 것인가' 만 담당하고, hooks/ 는 '컴포넌트에게 어떤 인터페이스를 줄 것인가' 를 담당해. 분리하면 두 가지 이점이 있어. 첫째, atom 이름이 바뀌어도 hooks 만 고치면 컴포넌트는 수정 안 해도 돼. 둘째, 컴포넌트가 atom 의 복잡한 조합 로직을 몰라도 되니까 단순해져. hooks 가 atom 들의 복잡성을 캡슐화해주는 거야."

💡 이 개념을 이해했다면: 레이어드 아키텍처의 핵심 가치인 "캡슐화와 의존성 역전" 을 이해한 거야. 다음 가이드로 넘어가도 충분해!

🐣 영철이의 퇴근 일기

오늘 atoms.ts 를 열었을 때 영호 님이 잠깐 침묵하신 게 자꾸 생각난다. 그 침묵이 나한텐 "영철아, 이게 맞니?" 처럼 들렸어.

솔직히 atom 추가할 때마다 그냥 파일 맨 밑에 붙인 게 맞아. 귀찮기도 했고, 어디 넣어야 하는지 규칙이 없으니까. 근데 그게 쌓이니까 이제 100개 넘는 atom 이 한 파일에서 뒤엉킨 거잖아.

리팩토링하면서 auth.ts, study.ts, search.ts, ui.ts 로 나누고 나니까, 진짜 신기하게도 뭐가 어디 있는지 바로 보이더라고. 2분이면 찾을 거 10분 뒤지던 때가 이미 옛날 일 같아.

💡 오늘의 교훈: "코드가 어디 있는지 찾는 데 시간이 걸리기 시작하면, 그게 구조를 바꿀 신호다."

순환 의존성 얘기도 충격이었어. A 가 B 를 보고 B 가 A 를 보면 서로 무한 거울이 된다 는 비유가 너무 찰졌어서 이제 절대 못 잊을 것 같아.

오늘 하루 폴더 구조 다듬고 나니까 왠지 뭔가 정돈된 느낌. 집 대청소한 것 같은 기분이랄까. 퇴근하고 헬스장이나 가야겠다. 다음 달 등록한 PT 세션 이번 주도 빠지면 안 되는데.

💡 07. atom 설계 전략 — 파일 구조와 책임 분리

📋 목차

📌 이 문서를 읽기 전에

🤔 왜 atom 구조 설계가 중요한가? 🟢

무질서한 단일 파일의 문제들

🏷️ 네이밍 컨벤션 🟢

*Atom 접미사 — 식별의 기준

이름 자체로 역할이 드러나는 패턴

🗂️ 도메인별 파일 분리 전략 🟡

영호 님이 제안한 영수네 팀의 파일 구조

Before / After 비교

🔄 순환 의존성 방지 🔴

순환 의존성 발생 시나리오

해결책: 공통 atoms 를 별도 파일로 분리

🎯 atoms vs hooks 레이어 설계 🟡

두 레이어의 역할 분리

atoms/ 레이어의 순수성 유지

🏢 Feature 단위 atom 슬라이싱 (대규모 앱) 🔴

Feature 슬라이싱 구조

전역 공유 vs Feature 로컬 — 선택 기준

💥 에러 해결 카탈로그

❌ ReferenceError: Cannot access 'atomX' before initialization

❌ ESLint import/no-cycle 경고

❌ atom 을 어디서 import 해야 할지 모르겠음

🏁 이번에 배운 내용 총정리

📋 atom 구조 설계 원칙

⚠️ 절대 하지 말 것

📝 마무리 퀴즈

🐣 영철이의 퇴근 일기

🔗 더 알아보기

`*Atom` 접미사 — 식별의 기준