React Native 상태 관리 기초: useContext로 전역 상태 다루기

API 연동까지 했다면
이제 이런 고민이 자연스럽게 생긴다.

• 로그인 정보는 어디에 두지?
• 여러 화면에서 같은 데이터를 써야 하는데?
• props를 계속 내려야 하나?

이 시점이 바로
상태 관리가 필요해지는 순간이다.

이 글에서는
상태 관리 라이브러리를 바로 쓰기 전에,
React Native에서 useContext로 어디까지 가능한지를
실무 기준으로 정리한다.

---

이 글이 필요한 사람

• props drilling이 불편해지기 시작한 경우
• 전역 상태가 왜 필요한지 감이 안 오는 경우
• Redux 같은 라이브러리가 부담스러운 경우

---

상태(state)는 왜 문제가 될까

지금까지는
대부분 이런 구조였을 것이다.

• 화면 안에서만 쓰는 state
• 컴포넌트 하나에서 관리

하지만 앱이 커지면
상태가 여러 화면에 걸쳐 필요해진다.

예를 들면,

• 로그인 사용자 정보
• 토큰
• 다크모드 여부
• 공통 설정 값

이걸 매번 props로 넘기기 시작하면
구조가 빠르게 복잡해진다.

---

props drilling 문제

아래 구조를 떠올려보자.

App
 └─ Screen
     └─ Component
         └─ Child

App의 state를
Child에서 쓰고 싶다면?

• props를 계속 내려야 한다
• 중간 컴포넌트는 필요 없는 props를 받는다

이게 바로
props drilling 문제다.

---

useContext란 무엇인가

useContext는
컴포넌트 트리 전체에서 공유할 수 있는 상태를 만든다.

핵심 개념은 이거다.

“필요한 곳에서 바로 꺼내 쓴다”

• 중간 전달 없음
• 구조 단순화
• React 기본 기능

---

Context 기본 구조 먼저 보기

Context는 항상
3단계 구조로 사용된다.

1. Context 생성
2. Provider로 감싸기
3. 사용하는 곳에서 꺼내기

---

1️⃣ Context 생성

import { createContext } from 'react';

export const AuthContext = createContext(null);

보통 context 폴더를 따로 만들어
역할별로 분리한다.

---

2️⃣ Provider로 감싸기

import { useState } from 'react';
import { AuthContext } from './AuthContext';

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);

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

이 Provider가
전역 상태의 실제 주인이다.

---

3️⃣ 앱 전체를 Provider로 감싸기

보통 App.js에서 감싼다.

<AuthProvider>
  <NavigationContainer>
    {/* screens */}
  </NavigationContainer>
</AuthProvider>

이렇게 하면
모든 화면에서 해당 상태를 사용할 수 있다.

---

Context 값 사용하는 방법

import { useContext } from 'react';
import { AuthContext } from './AuthContext';

function ProfileScreen() {
  const { user, setUser } = useContext(AuthContext);

  return <Text>{user?.name}</Text>;
}

• props 전달 없음
• 필요한 곳에서 바로 접근

---

언제 useContext가 충분할까

실제로 써보면
useContext만으로도 꽤 많은 걸 처리할 수 있다.

useContext가 잘 맞는 경우

• 로그인 정보
• 테마 (다크모드)
• 앱 전역 설정
• 비교적 단순한 상태

상태 변경 빈도가 높지 않다면
useContext는 충분히 실용적이다.

---

useContext의 한계

물론 단점도 있다.

⚠️ 렌더링 범위

• Context 값이 바뀌면
• 해당 Context를 쓰는 컴포넌트가 전부 리렌더링됨

⚠️ 상태가 많아질수록 관리가 어려움

• Context가 여러 개로 늘어남
• 의존 관계 파악이 힘들어짐

이 시점부터
상태 관리 라이브러리를 고민하게 된다.

---

상태 관리 라이브러리는 언제 필요할까

아래 중 하나라도 해당되면
라이브러리를 고려할 시점이다.

• 상태 종류가 많아짐
• 상태 변경 로직이 복잡함
• 여러 Context가 서로 얽힘
• 디버깅이 어려워짐

다만,

“처음부터 Redux”는
대부분 과한 선택이다.

---

실무 기준 추천 흐름

현실적인 흐름은 보통 이렇다.

1. useState로 시작
2. useContext로 확장
3. 필요해지면 상태 관리 라이브러리 도입

이 순서를 지키면
과도한 구조를 피할 수 있다.

---

정리

• 전역 상태는 자연스럽게 필요해진다
• props drilling은 구조를 망가뜨린다
• useContext는 React 기본 전역 상태 도구다
• 단순한 앱에서는 충분히 실용적이다
• 복잡해지면 그때 라이브러리를 고민해도 늦지 않다

다음 글에서는
실무에서 많이 쓰는 상태 관리 라이브러리를
간단히 비교해보고,

• Redux
• Zustand
• Recoil

각각 언제 쓰면 좋은지 정리해보려고 한다.