좋다. 이제 **“무엇을 전역으로 빼도 되는가 / 절대 빼면 안 되는가”**를
지금 이 App 코드 기준으로 아주 냉정하게 가르자.
원칙 → 적용 → 결론 순서로 간다.
기준부터 다시 고정 (짧게)
전역으로 빼도 되는 상태는 모두를 만족해야 한다.
- 여러 페이지에서 동시에 필요
- 화면 전환 후에도 유지 가치가 있음
- 누가 바꿔도 의미가 동일
- 앱의 동작 규칙에 영향
이 중 하나라도 아니면 전역 후보 탈락이다.
✅ 전역으로 빼면 “좋은 후보”
1️⃣ userInfo, nickname (인증 정보)
const [userInfo, setUserInfo] = useState(...)
const [nickname, setNickname] = useState(...)
왜 전역 후보인가
- 모든 화면에서 필요 (헤더, 모바일, 권한 체크)
- 페이지 이동해도 유지됨
- 앱 전체 동작을 결정함
- “누가 바꿔도 의미 동일”
👉 전형적인 앱 상태
추천 형태
- Context (읽기 위주면)
- Zustand (로그인/로그아웃 동작 포함하면)
// 예: zustand
useAuthStore = {
userInfo,
isAuthenticated,
login(),
logout()
}
✔ 이건 전역으로 빼는 게 설계적으로 더 깔끔하다.
2️⃣ menus
const [menus, setMenus] = useState([])
왜 전역 후보인가
- LeftMenu, MobileApp 등 여러 레이아웃에서 사용
- 인증 상태와 강하게 결합
- 메뉴는 앱 네비게이션의 일부
👉 App Shell 상태
단, 조건 있음
- 메뉴가 유저별 / 권한별이면 → auth store와 묶기
- 메뉴가 단순 렌더용이면 → App에 둬도 무방
✔ 전역 OK / 필수는 아님
❌ 전역으로 빼면 “나쁜 후보”
이 아래는 전역으로 빼는 순간 유지보수 비용이 폭증한다.
❌ openTabs, activeId
const [openTabs, setOpenTabs] = useState([])
const [activeId, setActiveId] = useState(null)
왜 나쁜가
- PC 레이아웃에서만 의미 있음
- MobileApp에서는 안 씀
- UI 상태 그 자체
전역으로 빼면 생기는 문제:
- 모바일에서도 상태가 살아 있음
- 초기화 타이밍 필요
- “왜 탭이 남아있지?” 발생
👉 전형적인 ‘화면 전용 UI 상태’
✔ 지금 위치(App) 완벽함
❌ 전역 ❌
❌ tabletMenuOpen
const [tabletMenuOpen, setTabletMenuOpen] = useState(false)
이건 설명도 필요 없다.
- 특정 디바이스
- 특정 레이아웃
- 순수 UI 토글
👉 로컬 상태의 교과서
❌ alert, detail, showLogoutConfirm
const [alert, setAlert] = useState(null)
const [detail, setDetail] = useState(null)
const [showLogoutConfirm, setShowLogoutConfirm] = useState(false)
흔한 실수
“팝업이 여러 군데서 뜨니까 전역으로 빼자”
이건 아주 위험한 판단이다.
이 상태들의 본질:
- UI 표현 상태
- 화면 흐름에 종속
- 생명주기 짧음
전역으로 빼면:
- 이전 화면 팝업이 남음
- 원인 추적 어려움
- 닫힘/열림 꼬임
👉 전역 팝업 지옥의 시작
✔ App에 두는 게 맞다
✔ 더 커지면 “PopupManager 컴포넌트”로 분리
❌ 전역 store ❌
⚠️ 애매하지만 “분리 가능 후보”
isAuthenticated
const isAuthenticated = !!nickname
이건 state가 아니라 파생 값이다.
- 전역 store로 빼지 않는다
- authStore.isAuthenticated 같은 computed 값으로 둔다
❌ 별도 상태로 만들면 중복
⭕ 계산으로 유지
전체를 표로 정리
상태전역 적합성이유
| userInfo / nickname | ✅ 매우 적합 | 앱 상태의 핵심 |
| menus | ⚠️ 선택 | 네비게이션 성격 |
| openTabs / activeId | ❌ 부적합 | PC 전용 UI 상태 |
| tabletMenuOpen | ❌ 부적합 | 로컬 UI 토글 |
| alert / detail / confirm | ❌ 부적합 | 화면 종속 UI |
| isAuthenticated | ❌ state 아님 | 파생 값 |
한 문장으로 결론
이 코드에서 전역으로 빼야 할 건
“앱의 정체성을 설명하는 상태”뿐이고,
“화면을 어떻게 보여줄지”에 대한 상태는
끝까지 로컬로 남겨야 한다
지금 이 App은
전역 상태 라이브러리 없이도 충분히 잘 설계된 상태다.
다음으로 가면 자연스럽다.
- 👉 “이 App을 Zustand로 옮긴다면 최소 구성은?”
- 👉 “Redux가 필요해지는 시점은 어디일까?”
- 👉 “Context로 auth만 빼면 어떤 변화가 생길까?”
원하는 방향 하나 찍어줘.
'framework_library > react' 카테고리의 다른 글
| 코드디벨럽3 (0) | 2026.01.11 |
|---|---|
| 코드디벨럽2 (0) | 2026.01.10 |
| React 소스 적용 (0) | 2026.01.10 |
| Redux는 왜 아직도 쓰이는가 (0) | 2026.01.10 |
| 그럼 Zustand는 왜 덜 위험한가 (0) | 2026.01.10 |
댓글