Context는 왜 상태 관리 도구가 아닌가

 

 

 

Context는 왜 상태 관리 도구가 아닌가

— 전달은 편해지지만, 설계는 더 어려워지는 이유

Context를 처음 쓰면 이런 느낌이 든다.

“props 안 내려도 되네?”
“전역 상태처럼 쓰면 되겠네?”

그리고 어느 순간부터
렌더링이 어디서 터졌는지 모르겠고,
값이 왜 바뀌었는지 추적이 안 된다.

이건 실수라기보다 구조적 오해다.
Context는 애초에 상태 관리용으로 설계되지 않았다.

---

1️⃣ Context의 본래 목적은 아주 단순하다

React 공식 정의를 한 문장으로 줄이면 이거다.

Context는
컴포넌트 트리를 통해
값을 “전달”하기 위한 메커니즘이다

여기엔 중요한 단어가 하나 있다.

👉 전달

Context는:

• 상태를 저장하지 않고
• 상태 변경 규칙을 만들지 않고
• 변경 이력을 관리하지 않는다

그냥 props를 멀리 보내는 파이프다.

---

2️⃣ 왜 Context를 “상태 관리”로 착각할까

이 코드 때문에 착각이 생긴다.

const UserContext = createContext(null);

function App() {
  const [user, setUser] = useState(null);

  return (
    <UserContext.Provider value={{ user, setUser }}>
      <Page />
    </UserContext.Provider>
  );
}

겉보기엔 이렇다.

• 전역에서
• state를 만들고
• 어디서든 접근 가능

그래서 이렇게 느낀다.

“어? 이거 전역 상태잖아?”

하지만 실체를 보면 다르다.

---

3️⃣ Context는 “상태”가 아니라 “통로”다

여기서 실제 상태는 어디에 있나?

const [user, setUser] = useState(null);

👉 상태는 App 컴포넌트에 있다

Context는 그 상태를:

• 저장하지 않고
• 감시하지 않고
• 규칙을 적용하지 않는다

그냥 이걸 한다.

“이 값을 하위에 그대로 흘려보내자”

---

4️⃣ Context를 상태 관리로 쓰면 생기는 구조적 문제

❌ 문제 1: 변경 범위가 너무 크다

Context의 치명적인 특성.

Provider의 value가 바뀌면
그 Context를 구독하는 모든 컴포넌트가
렌더 후보가 된다

<UserContext.Provider value={{ user, setUser }}>

여기서 user가 바뀌는 순간:

• Header
• Sidebar
• Footer
• Page 내부 컴포넌트

👉 전부 다시 계산 대상

부분 구독? 없다.
선택적 렌더? 기본 제공 안 된다.

---

❌ 문제 2: 상태 변경 위치가 숨겨진다

 

const { setUser } = useContext(UserContext);

이 코드의 의미는 이거다.

“이 컴포넌트가
전역 상태를 바꿀 수 있다”

그 결과:

• 누가 user를 바꾸는지
• 어떤 흐름으로 바뀌는지
• 언제 바뀌는지

👉 코드만 봐서는 추적이 어렵다.

Redux가 괜히 액션을 강제한 게 아니다.

---

❌ 문제 3: 생명주기 개념이 사라진다

Context 상태는 보통 이렇게 만들어진다.

<App>
  <Provider>
    <Routes />
  </Provider>
</App>

즉,

• 앱 시작 → 생성
• 앱 종료 → 제거

페이지 전환과 무관하다.

그래서 이런 문제가 생긴다.

• 이전 화면의 상태가 남아 있음
• 초기화 시점을 따로 관리해야 함
• “왜 이 값이 아직 살아있지?” 발생

---

5️⃣ “그럼 Context는 언제 쓰는 게 맞나”

Context가 빛나는 순간은 아주 명확하다.

✔ Context가 딱 맞는 경우

• 테마 (dark / light)
• 언어 설정
• 인증 정보 (읽기 위주)
• 환경 설정
• 깊은 트리에서 동일한 값 필요

공통점:

- 값이 비교적 정적
- 변경 빈도 낮음
- 변경 주체 제한적

👉 읽기 중심, 변경 드문 값

---

6️⃣ Context vs 전역 상태 라이브러리의 결정적 차이

Context

• 전달 중심
• 부분 구독 ❌
• 변경 추적 ❌
• 규칙 강제 ❌

Zustand / Redux

• 저장 중심
• 선택적 구독 ⭕
• 변경 경로 명확 ⭕
• 디버깅 도구 ⭕

그래서 이렇게 정리할 수 있다.

Context는 “배관”이고
상태 라이브러리는 “저장소 + 규칙”이다

---

7️⃣ 실무에서 Context가 지옥이 되는 순간들

아래 중 하나라도 보이면 위험 신호다.

• Context 안에 setX, setY, setZ가 가득
• Provider value에 객체를 계속 새로 만들어 전달
• Context가 여러 개 중첩됨
• Context 변경 때문에 화면 전체가 리렌더

이건 Context 문제가 아니다.

👉 상태 배치가 잘못된 것이다.

---

8️⃣ 핵심 문장 하나로 끝내자

이 글의 결론은 이 문장이다.

Context는
상태를 “관리”하기 위한 도구가 아니라
상태를 “전달”하기 위한 도구다

그래서:

• 상태가 복잡해질수록 ❌ Context
• 변경이 많아질수록 ❌ Context
• 추적이 필요해질수록 ❌ Context

---

다음 글에서는 이걸 자연스럽게 이어간다.

👉 다음 글

“그럼 Zustand는 왜 덜 위험한가”

• 왜 Zustand는 Context보다 안전한지
• 어떤 구조적 차이가 있는지
• 실무에서 Zustand가 사랑받는 이유

여기까지 왔다면,
이제 도구 선택이 아니라
상태의 성질을 보고 판단할 수 있는 단계다.