React 상태관리 ( 지역, 전역, 서버 컴포넌트 )

React 상태관리

React를 처음 배울 때 상태 관리는 단순하다.

useState

그런데 프로젝트가 조금만 커지면 이런 질문이 나오기 시작한다.

• 이 상태를 어디에 둬야 하지?
• props로 내리기엔 너무 멀다
• 전역 상태가 필요한가?
• 이건 서버 데이터 아닌가?

React 상태관리는 “어떤 라이브러리를 쓰느냐”의 문제가 아니라
이 상태가 어디까지 영향을 미쳐야 하느냐의 문제다.

---

1. 컴포넌트 로컬 상태: 가장 먼저 고려해야 할 선택지

React의 기본 상태관리 메커니즘은 여전히 유효하다.

• useState
• useReducer

토글, 입력값, 모달 열림 여부처럼
컴포넌트 내부에서만 의미가 있는 상태라면 이 이상이 필요 없다.

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <p>{count}</p>
      <button onClick={() => setCount(c => c + 1)}>+1</button>
    </div>
  );
}

언제 쓰면 충분한가

• 상태의 영향 범위가 해당 컴포넌트에만 있을 때
• props만으로 구조가 명확하게 유지될 때

많은 상태 문제는 사실 “전역으로 만들지 않아도 되는데 전역으로 만든 것”에서 시작된다.

---

2. URL / Router 상태: 공유되어야 하는 상태의 자연스러운 위치

검색 조건, 필터, 페이지 번호 같은 상태는
사실 UI 상태이기 이전에 네비게이션 상태다.

이걸 컴포넌트 state로만 들고 있으면 문제가 생긴다.

• 새로고침하면 초기화됨
• 뒤로가기 동작이 어색함
• 링크 공유가 불가능함

그래서 이 상태들은 URL로 올라갔다.

function ProductList() {
  const [params, setParams] = useSearchParams();
  const category = params.get('category') ?? 'all';

  return (
    <select
      value={category}
      onChange={e => setParams({ category: e.target.value })}
    >
      <option value="all">전체</option>
      <option value="shoes">신발</option>
      <option value="bag">가방</option>
    </select>
  );
}

언제 URL 상태가 맞는가

• 새로고침 후에도 유지되어야 하는 상태
• 뒤로가기 / 북마크가 의미를 가져야 하는 상태
• “현재 페이지의 조건”을 설명하는 상태

URL은 생각보다 강력한 상태 저장소다.

---

3. 서버 데이터 상태: 이건 클라이언트 상태가 아니다

useEffect + fetch 조합은 처음엔 간단해 보인다.
하지만 곧 이런 문제를 마주한다.

• 로딩 상태
• 에러 상태
• 여러 컴포넌트 간 데이터 공유
• 캐시, 재요청, 동기화

이걸 매번 직접 구현하는 건 비효율적이다.
그래서 서버 데이터 전용 상태관리가 등장했다.

function Todos({ filter }) {
  const { data, isLoading, error } = useQuery({
    queryKey: ['todos', filter],
    queryFn: () => fetch(`/api/todos?f=${filter}`).then(r => r.json()),
    staleTime: 60_000,
  });

  if (isLoading) return <p>로딩중...</p>;
  if (error) return <p>에러!</p>;

  return <ul>{data.map(t => <li key={t.id}>{t.title}</li>)}</ul>;
}

중요한 관점

서버 데이터는 “상태”라기보다 “캐시된 결과”에 가깝다.

그래서 전역 상태 라이브러리로 관리하려 하면 오히려 복잡해진다.

---

4. 전역 클라이언트 상태: 진짜 전역만 남겨라

여러 컴포넌트에서 동시에 접근해야 하는 상태가 있다.

• 로그인 사용자 정보
• 테마
• 글로벌 알림

이걸 props로만 전달하려 하면
곧 props drilling 문제가 터진다.

const useUI = create((set) => ({
  theme: 'light',
  toggle: () => set(s => ({ theme: s.theme === 'light' ? 'dark' : 'light' })),
}));

언제 전역 상태가 필요한가

• 페이지를 넘어 공유되는 상태
• UI 전반에 영향을 주는 설정값
• 서버 데이터가 아닌 순수 클라이언트 상태

여기서 중요한 건 개수다.
전역 상태는 많아질수록 관리 비용이 급격히 증가한다.

---

5. 상태 머신: 흐름이 복잡해지는 순간 등장한다

로그인, 결제, 업로드 같은 로직을 떠올려보자.

• 요청
• 성공
• 실패
• 재시도
• 취소

이걸 boolean state 몇 개로 관리하기 시작하면
금방 상태 조합이 폭발한다.

idle → loading → success
        ↓
       error → retry

상태 머신은 이 흐름을 명시적으로 고정한다.

export const loginMachine = createMachine({
  initial: 'idle',
  states: {
    idle: { on: { SUBMIT: 'loading' } },
    loading: {
      invoke: {
        src: fakeLogin,
        onDone: 'success',
        onError: 'error',
      },
    },
    error: { on: { RETRY: 'loading' } },
    success: { type: 'final' },
  },
});

언제 고려할 만한가

• 상태 전이가 명확한 단계형 로직
• “이 상태에서 이 행동은 불가능해야 한다”가 중요한 경우

모든 곳에 쓸 필요는 없지만,
필요한 곳에서는 굉장히 강력하다.

---

6. 서버 컴포넌트 / 서버 액션: 상태를 없애는 선택

Next.js App Router 이후 등장한 방향성은 분명하다.

“클라이언트에서 상태를 관리하지 말자.”

서버에서 데이터 로직을 실행하고,
클라이언트는 결과만 받는다.

'use server';
export async function addTodo(formData) {
  const title = formData.get('title');
  await db.todo.create({ data: { title } });
}

언제 좋은 선택인가

• DB 접근, 인증, 보안이 중요한 로직
• 서버가 더 빠르게 처리할 수 있는 작업
• 클라이언트 상태 복잡도를 줄이고 싶을 때

이건 “또 다른 상태관리”라기보다
상태 자체를 줄이는 접근에 가깝다.

---

7. 폼 상태: 일반 상태관리로는 버겁다

폼은 특이하다.

• 입력값
• 에러
• touched
• submitting
• validation

이걸 useState로 관리하면 코드가 급격히 지저분해진다.

const { register, handleSubmit, formState } = useForm();

React Hook Form 같은 라이브러리는
폼 상태를 성능까지 고려해서 분리해준다.

언제 필요해지는가

• 필드가 많은 폼
• 실시간 유효성 검사
• 렌더링 성능이 중요한 경우

---

정리: 상태관리는 도구 선택 문제가 아니다

React 상태관리는 이렇게 정리할 수 있다.

• 범위가 작으면 → 컴포넌트 로컬
• 공유되어야 하면 → URL 또는 전역
• 서버에서 왔으면 → 서버 상태 라이브러리
• 흐름이 복잡하면 → 상태 머신
• 없앨 수 있으면 → 서버로 이동

모든 걸 하나로 통합하려는 순간,
상태관리는 복잡해진다.

잘 설계된 React 앱은
상태가 많은 앱이 아니라, 상태의 자리가 명확한 앱이다.