Redux에 대해서 알아보자!
1. Redux란?
Redux는 2015년, JavaScript 개발자인 Dan Abramov와 Andrew Clark에 의해 탄생한 상태 관리 라이브러리이다. 이 도구는 애플리케이션의 상태를 예측 가능하고 일관성 있게 관리하기 위해 만들어졌다.
2. Redux의 탄생 배경
1) 복잡한 상태 관리하기 위해
단일 페이지 애플리케이션(SPA)의 인기가 높아지면서, 컴포넌트 간 상태를 효율적으로 공유하고 관리하는 것이 점점 더 어려워졌다. 특히 React를 사용하는 프로젝트에서 상태를 props를 통해 자식 컴포넌트로 전달하거나, 서로 다른 컴포넌트 간 상태를 동기화하는 과정이 번거롭고 비효율적이라는 문제가 있었다.
2) Flux 아키텍처의 한계를 극복하기 위해
Redux는 이러한 Flux의 단방향 데이터 흐름 패턴을 기반으로 만들어진 라이브러리로, Flux 아키텍처를 더 쉽게 구현하고 활용할 수 있도록 설계되었다. Flux가 여러 Store를 관리해야 하는 복잡성과 Boilerplate 코드의 증가 같은 불편함을 가졌다면, Redux는 단일 Store와 간결한 API를 통해 이를 개선하며, Flux 아키텍처의 철학을 유지하면서도 실제 프로젝트에 더 적합한 방식으로 발전시킨 것이다.
3) Time Travel Debugging을 위해
Dan Abramov는 "시간을 되돌릴 수 있는 디버깅 도구"를 만들고 싶어 했다. 그는 React Europe 2015 컨퍼런스에서 Redux를 처음 발표하며 Time Travel Debugging이라는 혁신적인 기능을 시연했다. 이 기능은 상태 변화 과정을 기록하여 디버깅을 더욱 직관적으로 만들어 준다.
2. Redux 의 3가지 원칙
Redux는 다음 세 가지 원칙을 바탕으로 설계되었다.
1) 단일 진실의 원천 (Single Source of Truth)
- 진실이라고 여겨지는 값이 여러곳이 아닌 단 한곳에만 존재해야한다.
- 애플리케이션의 모든 상태는 Redux Store라는 단 하나의 장소에만 저장되어야 하는데, 이 Redux Store가 바로 Single Source of Truth이다.
- 상태가 단일 Store에 집중되면, 상태의 출처가 명확해지고 디버깅이나 상태 추적이 용이해지고, 일관성과 예측가능성이 생긴다.
2) 상태는 읽기 전용 (State is Read-Only)
- 사전에 정의해둔(정해진) 어떤 상황이 발생했을 경우에, 사전에 정해진 대로만 (정해진 규칙에 따라서) 상태를 변경할 수 있다.
- 즉, 상태는 직접 변경할 수 없으며, 상태를 변경하려면 반드시 Action을 통해야 한다.
- 이 원칙은 상태 변경 과정을 투명하게 만들어, 상태의 흐름을 더 잘 이해할 수 있도록 한다.
3) 변화는 순수 함수로 정의 (Changes are Made with Pure Functions)
- 상태 변경은 순수 함수인 Reducer에 의해 정의된다.
- 순수함수란, 입력값(input)을 변경하지 않으며, 같은 입력 값에 대해서는 항상 같은 출력값(output)만 리턴한다는 것이다.
- pure function으로 작동한다는 것은, 입력으로 받은 이전 상태를 직접 변경하는 대신, 새로운 상태 객체를 만들어 반환한다는 것이다.
- Redux에서 상태는 불변성(immutability)을 유지해야 한다. 즉, Redux State는 생성된 이후 값을 변경할 수 없으며, 상태를 업데이트할 때는 기존 상태를 변경하지 않고 새로운 상태 객체를 만들어야 한다.
- Redux Toolkit은 불변성을 지키기 위해 immer.js를 사용한다.
3. Redux vs Context api의 공통점
1) 상태 관리 도구
- Redux와 Context API 모두 애플리케이션 전역에서 공유해야 하는 상태를 관리하는 데 사용된다.
- 부모-자식 간 props를 여러 단계로 전달하는 "prop drilling" 문제를 해결할 수 있다.
2) React와 통합
- 둘 다 React에 최적화되어 있으며, React의 생태계에서 사용됩니다.
- React 컴포넌트 트리 전체에 상태를 제공할 수 있는 Provider 패턴을 사용한다.
4. Redux와 Context API의 차이점
1) 디버깅 및 개발 도구
Redux
- Redux DevTools를 사용할 수 있다.
- Redux DevTools는 상태 변화 기록 및 액션 히스토리를 시각적으로 확인할 수 있도록 지원한다.
- 이전 상태로 돌아가거나, 하나씩 액션을 실행하면서 상태 변경 과정을 디버깅할 수 있다.
Context API
- 별도의 개발 도구는 제공되지 않는다.
- 상태 변화 과정을 추적하거나 디버깅하려면 개발자가 직접 로그를 추가하거나, React Developer Tools로 추적해야 한다.
2) 컴포넌트 범위 및 사이드 이펙트 관리
Redux
- 모든 애플리케이션 상태가 단일 Redux Store에서 관리되며, 전역적으로 상태를 공유할 수 있다.
- 상태는 구독하고 있는 컴포넌트만 영향을 받으므로, 불필요한 리렌더링이 발생하지 않는다.
Context API
- 여러 Context를 만들어, 특정 Context와 관련된 컴포넌트들을 묶어 분리할 수 있다.
- 이렇게 분리하면, 관련 없는 컴포넌트는 Context 데이터에 접근할 수 없으므로 사이드 이펙트를 방지할 수 있다.
- 하지만 Context의 상태가 변경되면 해당 Context를 사용하는 모든 컴포넌트가 리렌더링된다.
3) 데이터 관리 방식
Redux
- 전체 애플리케이션의 상태를 Redux Store라는 단일 객체로 중앙 집중 관리한다.
- 상태 변경은 반드시 사전에 정의된 Action과 Reducer를 통해 이루어지며, 상태 변경 과정이 명확하고 예측 가능하다.
Context API
- Context는 데이터를 관리하지 않고, 데이터를 전달하기 위한 통로 역할만 한다.
- Context를 통해 상태를 전달하려면, 상태는 상위 컴포넌트에서 관리되며, 상위 컴포넌트의 상태 변경이 Context를 통해 하위 컴포넌트에 전달된다.
- 즉, 상태 관리는 Context가 아닌 상위 컴포넌트의 책임이다.
요약 정리
| 특징 | Redux | Context API |
| 디버깅 도구 | Redux DevTools로 상태 변화와 디버깅 지원 | 별도의 디버깅 도구 없음 |
| 컴포넌트 범위 관리 | 전역 상태 관리에 적합, 구독된 컴포넌트만 리렌더링 | Context 분리를 통해 관련 없는 컴포넌트에 데이터 접근 차단 가능, 하지만 상태 변경 시 전체 리렌더링 발생 |
| 데이터 관리 방식 | 단일 Store에서 상태를 중앙 집중 관리, Action과 Reducer로 상태 변경 | 데이터를 전달하는 통로 역할, 상태 관리는 상위 컴포넌트에 의존 |
4. 어떤걸 사용해야할까?
✅ 규모가 크고 관리해야 할 상태가 많다 ➡️ Redux
중앙 집중식 상태 관리와 예측 가능한 상태 변경 로직이 필요한 대규모 애플리케이션에서 효과적이다.
✅ 규모가 작고 관리해야 할 상태가 적다 ➡️ Context API
간단한 데이터 전달이나 소규모 상태 공유에 유리하며, 설정이 간단하다.
'Libraries > Redux' 카테고리의 다른 글
| [Redux] Redux와 React를 연동하기 (1) | 2025.01.18 |
|---|---|
| [Redux] Reducer (0) | 2025.01.12 |
| [Redux] Action (0) | 2025.01.12 |
| [Redux] Dispatch (0) | 2025.01.01 |
| [Redux] Store (0) | 2025.01.01 |
