React
클라이언트 상태·서버 캐시와 상태 관리 도구
데이터의 소유자와 수명, 변경 패턴에 따라 Redux·Context·서버 캐시 도구를 구분해 선택합니다.
이럴 때 필요해요
하나의 전역 도구로 성격이 다른 모든 데이터를 다루다 생기는 동기화 보일러플레이트와 불필요한 리렌더링을 줄입니다.
어떻게 동작하나요?
프론트엔드에서 다루는 데이터라고 해서 모두 같은 성격의 상태는 아닙니다. 사이드바 열림 여부나 다크 모드, 작성 중인 다단계 폼처럼 브라우저 안에서 결정되는 '클라이언트 상태'가 있는 반면, 상품 목록이나 주문 내역처럼 백엔드 서버가 원본을 가지고 있고 우리는 잠시 복사본을 받아 보여 주는 '서버 상태(Server State)'가 있습니다. 이 둘을 구분하는 것이 현대 React 상태 관리의 출발점입니다.
여러 화면에 걸친 복잡한 클라이언트 상태 전이를 명확한 규칙으로 추적하고 재현해야 할 때는 단일 store, 읽기 전용 상태, 순수 reducer라는 세 원칙을 따르는 Redux(실무에서는 Redux Toolkit)가 유용합니다. 반면 서버에서 가져오는 원격 데이터는 로딩·에러·중복 요청 제거·백그라운드 재검증(staleTime)과 캐시 무효화가 핵심이므로 TanStack Query(React Query) 같은 서버 캐시 도구를 사용하면 수동 useEffect 패칭 코드를 크게 줄일 수 있습니다.
한편 상태를 작은 atom 조각과 파생 selector 그래프로 다루는 Recoil에서는 비동기 상태를 Loadable 객체의 state('loading' | 'hasValue' | 'hasError')와 contents로 표현합니다. 기존 코드를 읽을 때는 이 상태 분기를 이해하는 것이 중요하지만, 현재 Recoil 공식 저장소가 아카이브(유지보수 중단) 상태이므로 신규 프로젝트에 상태 라이브러리를 도입할 때는 유지보수 활성도와 React 버전 호환성까지 함께 검토해야 합니다.
코드 예제
동작을 설명하는 읽기 전용 예제입니다.
// 설명용 reducer: 기존 상태를 바꾸지 않고 다음 상태 반환
function reducer(state, action) {
if (action.type === 'itemAdded') {
return { ...state, items: [...state.items, action.payload] };
}
return state;
}라이브러리 설정을 생략한 설명용 순수 reducer 예제입니다. 기존 상태 객체를 직접 수정하지 않고 새로운 상태 객체를 반환하며, 네트워크 요청 같은 부작용은 reducer 밖에서 처리합니다.
자주 헷갈리는 포인트
- 단순히 값을 하위 트리로 전달하는 Context와 상태 전이·선택적 구독 체계를 제공하는 Redux를 완전히 동일한 대체재로 취급하지 않습니다.
- 서버 캐시 도구의 stale(오래됨) 상태를 데이터가 삭제되었거나 에러가 난 상태로 오해하지 않습니다.
내 말로 설명해 보기
서버에서 받아오는 상품 카탈로그 목록과 사용자가 화면에서 조작 중인 필터 패널 열림 상태는 각각 어디에서 관리하는 것이 자연스러울까요?
함께 읽으면 좋은 개념
관련 면접 질문 9개
유용했던 React 패키지는 면접에서 어떤 근거로 설명할까요?
실제 프로젝트에서 직접 사용해 본 패키지 하나를 골라, 당시 해결하려던 구체적인 문제와 기본 React API나 다른 대안 대신 그 도구를 선택한 기준을 중심으로 설명합니다. 단순히 라이브러리 기능 목록을 나열하기보다 프로젝트의 어떤 화면에 어떤 범위로 적용했는지, 도입 후 복잡도나 버그·성능을 어떻게 검증했는지 함께 말씀드리면 좋습니다. 만약 실무 적용 경험이 없다면 솔직히 밝히고 토이 프로젝트나 공식 문서 실습을 통해 확인한 장단점과 도입 제약을 구분해 설명합니다.
꼬리질문과 참고자료 →Redux는 어떤 상태 관리 요구에 유용한가요?
Redux는 전역 상태를 중앙 store에 두고 액션(Action)과 순수 함수인 reducer를 통해서만 상태를 변경하도록 강제하는 예측 가능한 상태 관리 라이브러리입니다. 여러 화면과 컴포넌트가 공유하는 상태 전이 규칙이 복잡하거나, 상태가 언제·왜 바뀌었는지 액션 로그와 DevTools로 명확히 추적하고 재현해야 하는 요구에 유용합니다. 오늘날 실무에서는 보일러플레이트를 줄이고 모범 사례를 기본 제공하는 Redux Toolkit(RTK)으로 구성하며, 단순한 지역 UI 상태나 순수 서버 캐시까지 모두 Redux에 넣기보다 역할을 나누어 사용합니다.
꼬리질문과 참고자료 →Flux의 단방향 데이터 흐름은 무엇인가요?
Flux는 사용자 상호작용으로 발생한 변경 의도를 Action으로 만들고, Dispatcher를 거쳐 Store의 상태를 갱신한 뒤 View가 그 상태를 읽어 화면을 다시 그리는 단방향 데이터 흐름 아키텍처 패턴입니다. 과거 양방향 데이터 바인딩에서 모델과 뷰가 서로를 연쇄적으로 바꾸며 상태 변경 원인을 찾기 어려워지던 문제를 해결하기 위해 등장했습니다. Redux 역시 이 단방향 흐름 철학을 계승했지만, 여러 Store와 Dispatcher를 두는 오리지널 Flux와 달리 단일 Store와 순수 Reducer 함수를 사용한다는 구체적인 설계 차이가 있습니다.
꼬리질문과 참고자료 →