전역 상태를 과도하게 만들었을 때 생기는 리렌더링 문제 (Provider 분리 전략까지)

전역 상태를 과도하게 만들었을 때 생기는 리렌더링 문제 (Provider 분리 전략까지)

전역 상태는 분명 구조를 단순하게 만든다. 하지만 잘못 설계하면 오히려 성능을 망가뜨린다.

특히 React Context API는 사용법은 간단하지만, 렌더링 구조를 이해하지 않으면 리렌더링 지옥에 빠질 수 있다.

---

1. Context가 리렌더링을 유발하는 구조

Context는 value가 변경되면, 해당 Provider 하위의 모든 소비 컴포넌트가 다시 렌더링된다.

const value = { user, theme, sidebarOpen };

이 객체가 매번 새로 생성되면 어떻게 될까?

• user만 변경되어도
• theme만 변경되어도
• sidebarOpen만 변경되어도

value 전체가 바뀐 것으로 인식된다. 결과적으로 모든 useContext 소비 컴포넌트가 다시 렌더링된다.

---

2. 초보자가 가장 많이 하는 실수

모든 상태를 하나의 Provider에 몰아넣는 것이다.

// ❌ 나쁜 예

<AppProvider>
  {children}
</AppProvider>

AppProvider 안에 이런 것들이 다 들어간다:

• 사용자 정보
• 테마 설정
• 모달 상태
• 사이드바 열림 여부
• 폼 입력값

이렇게 되면 작은 UI 변경 하나에도 앱 전체가 리렌더링된다.

---

3. 해결 전략 1: Provider 분리

상태는 역할 단위로 분리하는 것이 좋다.

<UserProvider>
  <ThemeProvider>
    <LayoutProvider>
      {children}
    </LayoutProvider>
  </ThemeProvider>
</UserProvider>

이렇게 하면:

• 사용자 변경 → UserProvider 하위만 영향
• 테마 변경 → ThemeProvider 하위만 영향
• 레이아웃 변경 → LayoutProvider 하위만 영향

리렌더 범위를 최소화할 수 있다.

---

4. 해결 전략 2: value를 useMemo로 고정

Provider의 value는 항상 메모이제이션해야 한다.

const value = useMemo(
  () => ({ user, setUser }),
  [user]
);

이렇게 하지 않으면, 렌더링마다 새로운 객체가 생성되어 불필요한 리렌더링이 발생한다.

---

5. 해결 전략 3: 정말 전역이 필요한가 다시 생각하기

전역 상태는 다음 질문을 통과해야 한다.

• 이 상태는 정말 여러 페이지에서 필요한가?
• 단일 컴포넌트 내부 상태로 충분하지 않은가?
• 상위 컴포넌트로 끌어올리는 것만으로 해결되지 않는가?

전역은 마지막 선택지다.

---

6. Context의 한계

Context는 전역 공유 도구이지, 성능 최적화 도구는 아니다.

데이터 캐싱, 서버 동기화, 자동 재요청이 필요하다면 React Query, SWR 같은 도구가 더 적합할 수 있다.

---

7. 실무 권장 구조

context/
 ├ UserProvider.tsx
 ├ ThemeProvider.tsx
 ├ LayoutProvider.tsx

각 Provider는 자신의 책임만 가진다.

---

마무리

전역 상태는 강력하지만, 잘못 설계하면 오히려 성능과 유지보수를 망친다.

핵심은 이것이다:

전역은 최소화하고, 역할은 분리하고, value는 안정화하라.

다음 글에서는 Context와 Redux, Zustand를 비교하며 언제 어떤 도구를 선택해야 하는지 정리하겠다.