React 라이브러리 조합 가이드: Zustand·TanStack Query·shadcn/ui 선택 기준

• 이 글의 역할과 대표 글과의 차이
• 상태관리: Zustand와 Redux Toolkit 선택 기준
• 서버 상태: TanStack Query가 필요한 상황
• UI 라이브러리: shadcn/ui와 Radix UI 역할
• 폼과 검증: React Hook Form과 Zod 기준
• 실무 선택 체크리스트

이 글은 React 프로젝트 내부 라이브러리 조합 기준입니다

프론트엔드 기술 선택은 두 단계로 나눠야 합니다. 첫 단계는 React, Vue, Svelte처럼 화면을 만드는 큰 축을 고르는 일입니다. 이 비교는 React Vue Svelte 점유율 비교와 선택 기준에서 다룹니다. 이 글은 그 다음 단계, 즉 React 프로젝트 안에서 어떤 라이브러리 조합을 쓸지 결정하는 기준에 집중합니다.

따라서 이 글의 핵심 질문은 “React가 좋은가, Vue가 좋은가”가 아닙니다. “전역 상태는 Zustand로 충분한가”, “서버 데이터 캐시는 TanStack Query로 분리할 것인가”, “UI는 shadcn/ui와 Radix UI 중 어느 수준으로 조합할 것인가”처럼 React 내부 구현 단계의 판단입니다.

React 클라이언트 상태관리: Zustand와 Redux Toolkit 선택 기준

React 프로젝트에서 가장 먼저 나눌 것은 클라이언트 상태와 서버 상태입니다. 모달 열림 여부, 선택된 탭, 임시 입력값처럼 브라우저 안에서만 의미가 있는 값은 클라이언트 상태입니다. 이런 상태가 작고 단순하면 React state만으로도 충분하고, 여러 컴포넌트가 공유해야 한다면 Zustand가 가벼운 선택지가 됩니다.

Redux Toolkit은 상태 변경 이력을 명확하게 추적해야 하거나, 팀 전체가 엄격한 패턴을 공유해야 하는 프로젝트에서 여전히 의미가 있습니다. 반대로 작은 서비스에서 단순 전역 값 몇 개를 관리하려고 Redux를 도입하면 코드량과 학습 비용이 먼저 커질 수 있습니다.

• 작은 공유 상태: React state 또는 Zustand
• 복잡한 도메인 상태와 명확한 액션 흐름: Redux Toolkit
• 서버에서 가져온 목록·상세 데이터: 상태관리 라이브러리보다 TanStack Query 우선 검토

React 서버 상태 관리: TanStack Query가 필요한 상황

API로 가져온 데이터는 일반 전역 상태와 성격이 다릅니다. 데이터에는 로딩, 실패, 재시도, 캐시, 만료 시간, 백그라운드 갱신이 함께 따라옵니다. 이 처리를 직접 만들기 시작하면 전역 store가 금방 복잡해집니다.

TanStack Query는 서버 상태를 별도 계층으로 분리할 때 유용합니다. 게시글 목록, 상품 상세, 사용자 프로필처럼 서버 원본이 따로 있고 화면은 그 데이터를 보여주는 역할이라면 서버 상태 라이브러리를 먼저 고려하는 편이 안전합니다. 반대로 API 호출이 거의 없고 로컬 인터랙션 중심이라면 굳이 도입하지 않아도 됩니다.

React UI 조합: shadcn/ui와 Radix UI 역할 차이

UI 라이브러리는 “빨리 화면을 만드는 도구”인지 “접근성과 인터랙션 구조를 빌리는 도구”인지 구분해야 합니다. shadcn/ui는 복사해서 프로젝트 코드로 소유하는 방식에 가깝고, Tailwind 기반 디자인 시스템을 빠르게 만들 때 좋습니다. Radix UI는 스타일보다 접근성·키보드 인터랙션·상태 제어 같은 primitive 역할이 강합니다.

이미 디자인 시스템이 있고 세밀한 커스터마이징이 중요하다면 Radix UI처럼 낮은 수준의 도구가 맞을 수 있습니다. 빠르게 관리자 화면이나 MVP를 만들어야 한다면 shadcn/ui가 생산성 면에서 유리합니다.

폼과 검증: React Hook Form과 Zod 기준

폼 라이브러리는 입력 필드 수, 검증 복잡도, 서버 전송 전 데이터 정리 방식에 따라 선택합니다. 간단한 검색창이나 필터라면 React state로 충분합니다. 회원가입, 결제, 관리자 입력 화면처럼 필드가 많고 오류 메시지가 복잡하면 React Hook Form을 쓰는 편이 관리하기 쉽습니다.

Zod는 입력값의 타입과 검증 규칙을 함께 다루고 싶을 때 유용합니다. 특히 TypeScript 프로젝트에서는 폼 데이터 구조를 코드에서 명확히 유지할 수 있어, 백엔드 API와 맞추는 과정에서 실수를 줄여 줍니다.

React 라이브러리 조합을 정하는 실무 체크리스트

• 서버 상태와 클라이언트 상태를 먼저 분리했는가?
• 팀원이 이미 알고 있는 도구인지, 새로 배울 비용이 큰지 확인했는가?
• 디자인 시스템과 접근성 요구를 충족하는가?
• 라이브러리 하나가 해결하는 문제가 명확한가?
• 번들 크기와 유지보수 비용이 프로젝트 규모에 맞는가?

선택 기준은 “가장 인기 있는 라이브러리”가 아니라 “현재 프로젝트의 문제를 가장 작게 해결하는 조합”이어야 합니다. React 자체를 선택할지 Vue나 Svelte와 비교해야 하는 단계라면 먼저 2025 프론트엔드 라이브러리 선택 기준을 읽고, React를 선택한 뒤 이 글로 돌아오는 흐름이 자연스럽습니다.

React 생태계 라이브러리 FAQ

Q. React 프로젝트에는 Zustand를 무조건 써야 하나요?
A. 아닙니다. 공유 상태가 작으면 React state와 context만으로 충분할 수 있습니다. 여러 화면에서 같은 클라이언트 상태를 다룰 때 Zustand를 검토하면 됩니다.

Q. 서버 데이터도 Zustand에 넣어도 되나요?
A. 가능은 하지만 권장 흐름은 아닙니다. 캐시, 재요청, 실패 처리, 동기화가 필요하다면 TanStack Query 같은 서버 상태 도구가 더 적합합니다.

Q. shadcn/ui와 Radix UI는 경쟁 관계인가요?
A. 완전히 그렇지는 않습니다. shadcn/ui는 Radix UI 기반 컴포넌트를 프로젝트 코드로 가져와 쓰는 경우가 많고, Radix UI는 접근성 primitive에 더 가깝습니다.

같이 읽으면 좋은 글

• React Vue Svelte 점유율 비교: 2025 프론트엔드 라이브러리 선택 기준
• React state vs Zustand: 언제 전역 상태가 필요할까
• React 처음 배우는 순서: 컴포넌트부터 state, Zustand까지