본문 바로가기
framework_library/react

코드 디벨럽

by 죄니안죄니 2026. 1. 10.

좋다. 이제 **“무엇을 전역으로 빼도 되는가 / 절대 빼면 안 되는가”**를
지금 이 App 코드 기준으로 아주 냉정하게 가르자.
원칙 → 적용 → 결론 순서로 간다.


기준부터 다시 고정 (짧게)

전역으로 빼도 되는 상태는 모두를 만족해야 한다.

  1. 여러 페이지에서 동시에 필요
  2. 화면 전환 후에도 유지 가치가 있음
  3. 누가 바꿔도 의미가 동일
  4. 앱의 동작 규칙에 영향

이 중 하나라도 아니면 전역 후보 탈락이다.


✅ 전역으로 빼면 “좋은 후보”

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

댓글