지역 상태
입력값, 열림 여부, 선택된 탭처럼 한 컴포넌트 안에서 끝나는 값입니다. useState로 충분하며 대부분의 상태가 여기 속합니다.
이 파트에서 다루는 내용
상태의 네 가지 종류Context의 용도와 한계전역 상태 도구선택 기준
01
상태 관리의 첫 단계는 분류입니다
상태 관리 문제를 라이브러리 선택 문제로 접근하면 답이 나오지 않습니다. 먼저 다루려는 값이 어떤 종류인지 구분해야 합니다.
종류가 다르면 필요한 도구도 다릅니다. 특히 서버에서 온 데이터를 전역 상태에 넣는 것이 가장 흔한 실수입니다.
공유 상태
형제 컴포넌트가 같이 봐야 하는 값입니다. 공통 부모로 올려 props로 내려보냅니다. Part 3의 상태 끌어올리기입니다.
전역 상태
로그인 사용자, 테마, 언어처럼 여러 화면에서 필요한 값입니다. 실제로는 생각보다 적습니다.
서버 상태
목록, 상세 데이터처럼 서버가 원본을 갖고 우리는 사본을 보여 주는 값입니다. 성격이 완전히 달라 전용 도구를 씁니다. Part 9에서 다룹니다.
가장 흔한 실수
서버에서 받은 목록을 전역 상태에 저장하고 직접 갱신 로직을 만드는 경우입니다. 서버 상태는 언제든 낡을 수 있고 다시 가져와야 하는 값이라 지역·전역 상태와 다루는 방식이 다릅니다. 이 구분만 해도 상태 관리 복잡도가 크게 줄어듭니다.
02
Context는 전달 도구이지 상태 관리 도구가 아닙니다
Context는 props를 여러 단계 내려보내는 번거로움을 없애 줍니다. 값을 필요한 컴포넌트가 직접 꺼내 쓸 수 있습니다.
다만 Context 자체에는 성능 최적화 장치가 없습니다. 값이 바뀌면 그 값을 쓰는 모든 컴포넌트가 다시 렌더링됩니다.
Context가 맞는 경우
- 테마, 언어처럼 거의 바뀌지 않는 값
- 로그인 사용자 정보
- 여러 단계 아래로만 전달하면 되는 설정값
Context가 부담되는 경우
- 자주 바뀌는 값 (입력값, 실시간 데이터)
- 값 하나가 바뀌어도 전체가 리렌더링되는 큰 객체
- 여러 관심사를 하나의 Context에 묶은 경우
Context 분리jsx
// 문제: 값 하나만 바뀌어도 이 Context를 쓰는 모든 곳이 리렌더링됩니다
const AppContext = createContext();
<AppContext.Provider value={{ user, theme, cart, notifications }}>
// 개선: 변경 주기가 다른 값을 나눕니다
<UserContext.Provider value={user}>
<ThemeContext.Provider value={theme}>
{children}
</ThemeContext.Provider>
</UserContext.Provider>value에 객체 리터럴을 그대로 넣으면 부모가 렌더링될 때마다 새 객체가 되어 소비자 전체가 리렌더링됩니다. 값이 자주 바뀌지 않는다면 메모이제이션하거나, Compiler를 쓰면 이 부분이 자동 처리됩니다.
03
전역 상태 도구는 필요해진 뒤에 도입합니다
프로젝트를 시작하면서 전역 상태 라이브러리부터 설치하는 경우가 많습니다. 그런데 실제로 전역이 필요한 값은 적고, 대부분은 지역 상태와 서버 상태로 나뉩니다.
도구를 먼저 정하면 모든 상태를 그 도구에 넣게 되고, 값이 어디서 바뀌는지 추적하기 어려워집니다.
Context + useReducer
라이브러리 없이 React 기능만으로 전역 상태를 만듭니다. 규모가 작으면 충분하지만 렌더링 범위를 직접 관리해야 합니다.
Redux Toolkit
상태 변경 흐름이 정해져 있고 개발 도구 지원이 좋습니다. 팀이 크거나 상태 변경 이력을 추적해야 할 때 유리합니다. 작성해야 할 코드는 상대적으로 많습니다.
Zustand 계열
적은 코드로 전역 스토어를 만들고, 필요한 값만 골라 구독해 렌더링 범위를 줄입니다. 최근 신규 프로젝트에서 많이 쓰입니다.
도입 신호
- 같은 값을 서너 단계 이상 내려보내고 있다
- 서로 먼 화면들이 같은 값을 봐야 한다
- Context가 늘어나 관리가 어려워졌다
04
판단 순서를 정해 두면 흔들리지 않습니다
- 1. 이 값이 서버가 원본인가? 그렇다면 서버 상태 도구로 다룹니다. Part 9입니다.
- 2. 한 컴포넌트에서만 쓰는가? useState로 둡니다.
- 3. 형제끼리 공유하는가? 공통 부모로 올립니다.
- 4. 여러 단계 아래로만 내려보내면 되는가? Context를 씁니다.
- 5. 앱 곳곳에서 읽고 쓰며 자주 바뀌는가? 그때 전역 상태 도구를 검토합니다.
URL도 상태입니다
검색 조건, 페이지 번호, 선택된 탭은 URL에 두면 새로고침과 공유가 자연스럽게 동작합니다. 전역 상태에 넣기 전에 URL을 먼저 검토합니다.
폼 상태
제출 전 입력값은 대부분 지역 상태입니다. 전역으로 올리면 다른 화면에 값이 남아 예상치 못한 동작이 생깁니다.
도구를 섞을 때
서버 상태 도구와 전역 상태 도구를 함께 쓰는 구성이 일반적입니다. 역할이 겹치지 않게 경계를 정해 둡니다.
실무 기준
상태 관리에서 중요한 것은 도구가 아니라 이 값이 어디에 있어야 하는지에 대한 합의입니다. 팀이 기준을 정하지 않으면 같은 프로젝트 안에서도 화면마다 방식이 달라집니다.
버전
버전별 참고
본문은 React 19 기준입니다. 18과 달라지는 부분은 아래에 정리합니다.
- React 19에서는 Context를 쓸 때 Provider를 생략하고 Context 자체를 컴포넌트로 쓸 수 있습니다. 18 이하에서는 기존 방식을 씁니다.
- React Compiler를 적용하면 Context value 객체의 메모이제이션이 자동 처리돼, 이 파트에서 언급한 리렌더링 부담이 줄어듭니다.
- 전역 상태 라이브러리는 React 버전보다 라이브러리 자체 버전 정책을 확인해야 합니다.
체크