레드덕스

액션은 애플리케이션에서 발생하는 사건을 설명하는 정보의 묶음이다. 상태를 변화시키려는 모든 의도는 반드시 액션을 통해 전달되어야 한다. 액션은 자바스크립트 객체로 표현되며, 어떤 종류의 변화가 필요한지를 나타내는 type 필드를 반드시 가져야 한다. 이 type 필드는 일반적으로 문자열 상수로 정의된다. 액션 객체에는 type 외에도 해당 변화에 필요한 추가 데이터를 담은 payload 등의 필드를 포함할 수 있다.

액션 생성자는 액션 객체를 만들어내는 함수이다. 이는 액션 생성을 캡슐화하고, 필요한 데이터를 전달받아 올바른 형식의 액션 객체를 반환한다. 디스패치 함수를 통해 액션을 스토어에 보내면, 스토어는 현재의 상태와 함께 해당 액션을 리듀서 함수에 전달한다. 리듀서는 액션의 type을 확인하고, 그에 따라 새로운 상태를 계산하여 반환하는 역할을 한다.

액션은 애플리케이션 상태 변화의 유일한 원천이다. 상태를 직접 수정하는 대신, 어떤 일이 일어났는지를 설명하는 액션을 발생시키는 이 패턴은 상태 변화를 예측 가능하고 추적 가능하게 만든다. 이는 특히 디버깅과 상태 변화의 로깅에 유용하며, 시간 여행 디버깅과 같은 고급 기능을 구현하는 기반이 된다.

리듀서는 애플리케이션의 상태 변화를 결정하는 순수 함수이다. 현재의 상태와 발생한 액션 객체를 인자로 받아, 그 액션의 타입에 따라 다음 상태를 계산하여 반환하는 역할을 한다. 리듀서 함수는 반드시 순수 함수여야 하며, 이는 동일한 입력에 대해 항상 동일한 출력을 보장하고, 부수 효과를 발생시키지 않음을 의미한다. 이는 상태 변화의 예측 가능성을 높이고, 단위 테스트를 용이하게 만드는 핵심 원칙이다.

리듀서의 기본 구조는 (state, action) => newState 형태를 따른다. 함수 내부에서는 주로 switch 문을 사용하여 action.type을 구분하고, 각 케이스에 따라 새로운 상태 객체를 생성하여 반환한다. 중요한 점은 상태를 직접 변이시키지 않고, 스프레드 연산자 등을 활용하여 불변성을 유지한 새로운 상태 객체를 만들어내야 한다는 것이다. 이는 레드덕스가 상태 변화를 감지하고 구독된 UI 컴포넌트에 알리는 메커니즘의 기반이 된다.

복잡한 애플리케이션에서는 단일 리듀서 대신 여러 개의 리듀서를 조합하여 사용한다. 각 리듀서는 상태 트리의 서로 다른 부분을 관리하도록 설계되며, 레드덕스의 combineReducers 유틸리티를 사용하면 이러한 리듀서들을 하나의 루트 리듀서로 쉽게 결합할 수 있다. 이는 코드를 모듈화하고 유지보수성을 높이는 데 기여한다. 리듀서의 순수성과 예측 가능성은 디버깅과 상태 변화의 시간 여행을 가능하게 하는 Redux DevTools 같은 도구의 구현을 가능하게 하는 근간이 된다.

[정보 테이블 확정 사실]의 내용이 현재 작성 요청된 '레드덕스' 문서의 '스토어' 섹션과 전혀 관련이 없습니다. 제공된 정보는 '리그레션(Regression)' 현상에 대한 설명입니다. 따라서, 레드덕스의 스토어에 대한 일반적인 지식과 [주제 확정]에 명시된 내용을 바탕으로 섹션을 작성합니다.

레드덕스에서 스토어는 애플리케이션의 전체 상태 트리를 보유하는 객체이다. 애플리케이션에는 오직 하나의 스토어만 존재하며, 이는 단일 진실 공급원 원칙의 핵심 구현체이다. 스토어는 리듀서 함수를 인자로 받아 생성되며, 생성된 스토어는 애플리케이션의 현재 상태를 저장하고 관리하는 책임을 진다.

스토어의 주요 역할은 상태를 읽고, 액션을 통해 상태를 업데이트하며, 상태 변화를 구독하는 컴포넌트에게 알리는 것이다. 이를 위해 스토어는 getState(), dispatch(action), subscribe(listener)와 같은 핵심 메서드를 제공한다. getState()는 현재 상태를 반환하고, dispatch(action)은 주어진 액션을 처리하기 위해 리듀서를 호출하여 상태를 갱신한다. subscribe(listener)는 상태가 변경될 때마다 실행될 콜백 함수를 등록하는 인터페이스이다.

리액트와 같은 UI 라이브러리와 함께 사용될 때, 스토어는 보통 애플리케이션의 최상위 수준에서 생성되고, React-Redux와 같은 바인딩 라이브러리를 통해 하위 컴포넌트들에 상태와 상태 변경 함수가 제공된다. 또한 스토어는 미들웨어를 적용하여 액션이 리듀서에 도달하기 전에 비동기 작업이나 로깅과 같은 부가 기능을 수행할 수 있도록 확장할 수 있다.

디스패치는 레드덕스에서 애플리케이션의 상태를 변경하는 유일한 방법이다. 상태를 직접 수정하는 대신, 변경을 설명하는 액션 객체를 생성하여 디스패치 함수에 전달한다. 이 디스패치 함수는 스토어의 핵심 메서드로, 전달받은 액션을 현재 상태와 함께 리듀서 함수로 보낸다.

디스패치의 과정은 단방향 데이터 흐름의 핵심을 이룬다. 개발자는 store.dispatch(action)과 같은 형태로 액션을 발행하면, 스토어는 자동으로 해당 액션과 현재 상태를 리듀서에 전달하여 새로운 상태를 계산한다. 이 새로운 상태가 스토어에 저장된 후, 상태의 변경을 구독하고 있던 UI 컴포넌트들이 자동으로 갱신된다. 이는 상태 변경의 예측 가능성과 추적 가능성을 크게 높인다.

디스패치된 액션은 미들웨어를 통과할 수 있다. Redux Thunk나 Redux Saga와 같은 미들웨어를 사용하면, 일반 객체 형태의 액션뿐만 아니라 함수나 프로미스와 같은 비동기 작업을 디스패치할 수 있다. 이를 통해 API 호출과 같은 비동기 로직을 상태 관리 흐름 안에서 깔끔하게 처리할 수 있게 된다.

구독은 레드덕스 스토어의 상태 변화를 감지하고, 상태가 업데이트될 때마다 특정 함수(일반적으로 렌더링 함수)를 실행하도록 등록하는 메커니즘이다. 스토어의 상태는 읽기 전용이지만, 애플리케이션 UI는 이 상태의 변화에 반응하여 업데이트되어야 한다. 구독 패턴은 이러한 상태 변화와 UI 업데이트를 연결하는 핵심적인 역할을 한다.

스토어의 subscribe 메서드를 호출하여 구독자를 등록할 수 있다. 이 메서드는 리스너 함수를 인자로 받으며, 상태가 변경될 때마다 이 리스너 함수가 호출된다. 일반적으로 이 리스너 함수 내부에서는 store.getState()를 호출하여 최신 상태를 가져온 후, 해당 상태를 바탕으로 React 컴포넌트를 다시 렌더링하는 로직을 수행한다. React-Redux와 같은 바인딩 라이브러리는 내부적으로 이 구독 메커니즘을 사용하여 컴포넌트와 스토어를 효율적으로 연결한다.

구독은 상태 변화에 대한 반응형 프로그래밍을 가능하게 하지만, 과도하거나 비효율적인 구독은 성능 문제를 일으킬 수 있다. 예를 들어, 상태의 작은 변화마다 불필요하게 많은 컴포넌트가 다시 렌더링되면 애플리케이션 성능이 저하된다. 따라서 구독된 컴포넌트는 실제로 필요한 상태의 일부만을 선택적으로 구독하도록 최적화하는 것이 중요하다. React-Redux는 connect 함수나 useSelector 훅을 통해 이러한 최적화를 제공한다.

구독 메커니즘은 레드덕스의 예측 가능한 상태 관리 흐름을 완성하는 중요한 부분이다. 디스패치에 의해 액션이 발생하고, 리듀서가 상태를 순수하게 계산한 후, 최종적으로 구독된 모든 리스너에게 상태 변경 사실이 알려지면서 단일 진실 공급원에 기반한 일관된 UI 업데이트가 보장된다.

단일 진실 공급원은 레드덕스의 핵심 설계 원칙 중 하나로, 애플리케이션의 전체 상태를 하나의 자바스크립트 객체 트리, 즉 단일 스토어 내에 저장하는 패턴을 의미한다. 이 원칙은 데이터의 흐름을 단순화하고 예측 가능하게 만드는 데 목적이 있다. 모든 컴포넌트는 이 중앙 집중화된 스토어를 구독하여 필요한 상태를 가져오며, 애플리케이션의 다른 부분에서 동일한 데이터를 다른 형태로 복제하거나 파생시키지 않는다.

이 접근 방식은 데이터 일관성을 보장하고 상태 동기화 문제를 방지한다. 여러 컴포넌트가 동일한 데이터를 독립적으로 관리하면, 한 곳에서 데이터를 업데이트했을 때 다른 곳의 데이터가 최신 상태를 반영하지 못하는 버그가 발생하기 쉽다. 단일 진실 공급원 원칙을 따르면 데이터의 업데이트와 흐름이 명확해져, 이러한 부작용을 효과적으로 줄일 수 있다.

또한 이 원칙은 디버깅과 애플리케이션 상태의 검사를 훨씬 용이하게 만든다. 개발자는 복잡하게 분산된 상태를 추적할 필요 없이 하나의 스토어만 살펴보면 현재 애플리케이션의 전체 상태를 직관적으로 이해할 수 있다. 레드덕스 데브툴즈와 같은 도구는 이 단일 스토어의 상태 변화를 시간에 따라 기록하고 재현할 수 있게 해주어, 개발 생산성을 크게 향상시킨다.

단일 진실 공급원은 상태 관리의 복잡성을 통제하는 강력한 규칙이지만, 모든 상태를 반드시 스토어에 넣어야 한다는 의미는 아니다. 폼의 임시 입력값이나 컴포넌트 자체의 내부 UI 상태처럼 지역적이고 독립적인 상태는 컴포넌트 내부에서 관리하는 것이 더 적합할 수 있다. 이 원칙은 애플리케이션 전반에 걸쳐 공유되고 중요한 데이터를 중심으로 적용된다.

레덕스의 두 번째 기본 원칙은 상태는 읽기 전용이라는 것이다. 이는 애플리케이션의 상태를 직접 수정하는 것을 금지한다는 의미이다. 상태를 업데이트하는 유일한 방법은 액션이라는 평범한 자바스크립트 객체를 발생시키는 것이다. 이 액션은 "무엇이 일어났는지"를 설명하며, 상태가 어떻게 변화해야 하는지는 리듀서라는 순수 함수에서 정의한다.

이 원칙을 지키면 상태 변화의 추적과 이해가 매우 쉬워진다. 상태는 직접 조작되지 않기 때문에, 특정 시점의 상태 스냅샷과 발생한 액션의 로그만으로 애플리케이션의 전체 상태 변화 흐름을 재현하거나 디버깅할 수 있다. 이는 소프트웨어 테스팅과 디버깅을 용이하게 한다.

또한, 상태의 불변성을 유지함으로써 예기치 않은 부작용을 방지하고 성능 최적화를 가능하게 한다. 리액트와 같은 뷰 레이어 라이브러리는 상태 객체의 참조가 변경되었는지 쉽게 확인하여 불필요한 리렌더링을 방지할 수 있다. 상태를 직접 변형(mutate)하면, 이전 상태와 새 상태의 비교가 어려워지고, 이는 버그를 유발하거나 성능 저하의 원인이 될 수 있다.

이 원칙은 코드의 예측 가능성을 높이고, 리팩토링을 안전하게 진행할 수 있도록 돕는다. 상태 변경의 통로가 액션 발생이라는 하나의 명확한 패턴으로 제한되므로, 코드의 특정 부분을 수정할 때 다른 부분에 미치는 영향을 추론하기 쉬워진다. 이는 소프트웨어 공학에서 말하는 결합도를 낮추고, 유지보수성을 향상시키는 데 기여한다.

레덕스의 세 번째 기본 원칙은 "변화는 순수 함수로" 이루어져야 한다는 것이다. 이는 애플리케이션 상태의 모든 변경이 순수 함수인 리듀서를 통해서만 발생해야 함을 의미한다. 순수 함수는 동일한 입력에 대해 항상 동일한 출력을 반환하며, 외부 상태를 변경하거나 외부 변수에 의존하지 않는 함수를 말한다.

이 원칙은 상태 변경의 예측 가능성과 디버깅의 용이성을 보장한다. 리듀서는 이전 상태와 액션 객체를 입력받아 새로운 상태를 반환하는 함수로, 네트워크 요청이나 랜덤 함수 호출 같은 부수 효과를 포함해서는 안 된다. 이러한 순수성 덕분에 상태 변화의 흐름을 명확하게 추적할 수 있으며, 시간 여행 디버깅과 같은 강력한 개발 도구의 사용이 가능해진다.

순수 함수를 통한 상태 관리의 또 다른 장점은 테스트의 용이성이다. 리듀서는 외부 의존성이 없기 때문에, 특정 입력에 대한 출력을 쉽게 예측하고 단위 테스트를 작성할 수 있다. 이는 소프트웨어의 신뢰성을 높이고, 코드 수정 시 다른 부분에 영향을 미치는 리그레션 현상을 방지하는 데 도움이 된다.

이 원칙을 지키기 위해, 비동기 작업이나 API 호출 같은 부수 효과는 리듀서 내부에서 직접 처리되지 않는다. 대신, 미들웨어나 Redux Thunk, Redux Saga 같은 별도의 라이브러리를 사용하여 액션이 디스패치되기 전이나 후에 처리하도록 구성한다. 이로써 상태 변경의 순수성은 유지하면서도 복잡한 애플리케이션 로직을 효과적으로 관리할 수 있다.

createStore는 레드덕스 라이브러리의 핵심 함수로, 애플리케이션의 전체 상태를 관리하는 스토어 객체를 생성하는 역할을 한다. 이 함수는 애플리케이션의 상태 트리를 보유하고, 상태를 업데이트하는 리듀서 함수, 그리고 초기 상태와 선택적 미들웨어를 인자로 받아 동작한다.

createStore를 통해 생성된 스토어는 몇 가지 주요 메서드를 제공한다. 가장 중요한 메서드는 디스패치로, 액션 객체를 전달받아 현재 상태와 함께 리듀서 함수를 실행하여 새로운 상태를 계산한다. 또한 구독 메서드를 통해 상태가 변경될 때마다 실행될 콜백 함수를 등록할 수 있어, 사용자 인터페이스를 최신 상태로 갱신하는 데 사용된다. getState 메서드는 현재 상태 트리를 읽기 전용으로 반환한다.

이 함수는 단일 진실 공급원 원칙을 구현하는 기초가 된다. 애플리케이션의 모든 상태 변화는 오직 이 스토어를 통해서만 이루어지며, 상태의 예측 가능성과 디버깅 용이성을 보장한다. 초기 자바스크립트 생태계에서 레드덕스를 사용할 때는 이 createStore 함수를 직접 호출하는 것이 표준적인 방법이었다.

그러나 현대적인 레드덕스 툴킷에서는 configureStore라는 고수준 API를 주로 사용하며, 이는 내부적으로 createStore를 활용하면서도 미들웨어 설정이나 개발자 도구 통합과 같은 보일러플레이트 코드를 크게 줄여준다. 따라서 새로운 프로젝트에서는 createStore를 직접 사용하기보다는 레드덕스 툴킷의 추상화된 API를 이용하는 것이 권장된다.

combineReducers는 레드덕스 애플리케이션에서 가장 일반적으로 사용되는 헬퍼 함수이다. 이 함수의 주요 역할은 애플리케이션의 상태를 도메인별로 나누어 관리하는 여러 개의 독립적인 리듀서 함수를 하나로 합쳐주는 것이다. 이를 통해 복잡한 애플리케이션의 상태 관리를 모듈화하고 구조화할 수 있다.

combineReducers를 사용하면 각 리듀서는 전체 상태 트리 중 자신이 담당하는 특정 조각(슬라이스)만을 관리하게 된다. 예를 들어, 할일 목록 애플리케이션에서는 todos 리듀서와 visibilityFilter 리듀서를 별도로 작성한 후, combineReducers를 이용해 하나의 루트 리듀서로 결합한다. 이렇게 생성된 루트 리듀서는 스토어를 생성할 때 createStore 함수에 전달된다.

이러한 접근 방식은 코드의 모듈성과 가독성을 크게 향상시킨다. 또한, 서로 다른 팀이나 개발자가 애플리케이션의 서로 다른 기능 영역에 해당하는 리듀서를 독립적으로 개발하고 테스트할 수 있게 한다. 이는 소프트웨어 공학에서 흔히 발생하는 리그레션 문제, 즉 한 부분을 수정했을 때 다른 부분에서 예기치 않은 결함이 발생하는 현상을 방지하는 데 도움이 된다.

결과적으로 combineReducers는 레드덕스의 핵심 원칙 중 하나인 상태의 예측 가능성을 유지하면서도 대규모 애플리케이션 개발을 체계적으로 진행할 수 있는 기반을 제공한다. 이는 유지보수 비용을 절감하고 애플리케이션의 품질 보증을 강화하는 데 기여한다.

미들웨어는 액션이 디스패치되어 리듀서에 도달하기 전, 그 사이에 실행되는 확장 메커니즘이다. 이는 로그 기록, 비동기 작업 처리, 에러 보고, 액션 변형 또는 취소 등 다양한 부가 기능을 애플리케이션의 핵심 로직 변경 없이 적용할 수 있게 해준다. 미들웨어는 함수형 프로그래밍의 체이닝 개념을 활용하여 구현되며, 스토어의 dispatch 메서드를 감싸고 확장하는 역할을 한다.

미들웨어의 일반적인 구조는 store -> next -> action의 세 가지 매개변수를 받는 함수 형태를 가진다. 여기서 store는 Redux 스토어의 일부 메서드에 접근할 수 있는 객체이며, next는 다음 미들웨어나 최종적으로 리듀서로 액션을 전달하는 함수이다. 개발자는 이 구조 안에서 들어오는 모든 액션을 가로채고, 필요한 작업을 수행한 후 next(action)을 호출하여 체인을 계속 진행하거나, 특정 조건에서 액션 전달을 중단할 수도 있다.

Redux 생태계에는 여러 공식 및 서드파티 미들웨어가 존재한다. 대표적으로 비동기 액션을 처리하기 위한 Redux Thunk나 더 복잡한 비동기 흐름을 제어하는 Redux Saga가 널리 사용된다. 또한, Redux Toolkit에는 Redux Thunk가 기본적으로 내장되어 있어 별도 설치 없이 비동기 로직을 쉽게 구현할 수 있다. 이러한 미들웨어들을 조합하여 사용함으로써 애플리케이션의 부가 요구사항을 깔끔하게 분리하고 관리할 수 있다.

레덕스 데브툴스는 레덕스 애플리케이션의 상태 변화를 실시간으로 관찰하고 디버깅할 수 있게 해주는 브라우저 확장 도구이다. 주로 크롬과 파이어폭스 브라우저에서 사용 가능하며, 애플리케이션의 상태 트리를 시각적으로 탐색하고, 발생한 모든 액션의 히스토리를 타임라인 형태로 확인할 수 있다. 개발자는 특정 시점의 상태로 시간 여행을 하거나 액션을 재발생시켜 상태 변화를 단계별로 검증할 수 있어, 복잡한 상태 관리에서 발생하는 버그를 효과적으로 추적하는 데 필수적이다.

이 도구는 스토어 생성 시 미들웨어로 간단히 연결하여 사용한다. 주요 기능으로는 상태의 실시간 모니터링, 액션 로그 기록 및 필터링, 상태의 JSON 형태로의 내보내기 및 불러오기, 액션 히스토리를 통한 상태 변화의 되돌리기와 재실행 등이 포함된다. 이를 통해 개발 과정에서 상태의 불변성을 유지하며 디버깅하는 레덕스의 핵심 원칙을 시각적으로 지원받을 수 있다.

레덕스 데브툴스는 리액트 생태계와의 긴밀한 통합으로도 유명하다. React-Redux와 함께 사용될 때 컴포넌트 계층 구조에서의 상태 구독 관계를 확인하는 등 더 풍부한 디버깅 환경을 제공한다. 또한, Redux Toolkit 같은 현대적 레덕스 도구 키트를 사용할 경우 기본 설정에 포함되어 있어 초기 설정 부담 없이 바로 활용할 수 있는 장점이 있다.

레덕스의 가장 큰 장점은 애플리케이션의 상태를 예측 가능하고 일관된 방식으로 관리할 수 있게 해준다는 점이다. 상태 변화의 흐름이 엄격하게 단방향으로 이루어지기 때문에, 특정 상태가 어떻게 변화했는지 그 경로를 명확히 추적할 수 있다. 이는 복잡한 애플리케이션에서 디버깅을 용이하게 하며, 버그를 재현하고 원인을 파악하는 데 큰 도움을 준다.

또한, 상태 관리 로직이 애플리케이션의 UI 로직과 완전히 분리된다는 점도 주요 장점이다. 리듀서는 순수 함수로 작성되므로, 동일한 입력에 대해 항상 동일한 출력을 보장한다. 이러한 특성은 코드의 테스트 가능성을 극대화하며, 단위 테스트를 작성하기 매우 쉽게 만든다. 상태 관리 로직을 독립적으로 테스트할 수 있어 개발 생산성을 높인다.

레덕스의 구조는 애플리케이션의 상태를 하나의 중앙 집중식 스토어에서 관리하는 '단일 진실 공급원' 원칙을 따르기 때문에, 상태의 일관성을 유지하기 쉽다. 여러 컴포넌트가 동일한 상태를 참조할 때 발생할 수 있는 데이터 불일치 문제를 근본적으로 방지한다. 이는 대규모 협업 프로젝트나 긴 생명주기를 가진 프로젝트에서 특히 유용하며, 유지보수성을 크게 향상시킨다.

마지막으로, 레덕스는 강력한 생태계와 미들웨어 지원을 자랑한다. Redux DevTools와 같은 개발자 도구를 통해 상태 변화의 타임라인을 시각적으로 확인하고, 특정 시점의 상태로 시간 여행 디버깅을 할 수 있다. 또한, Redux Thunk나 Redux Saga 같은 미들웨어를 통해 비동기 작업을 우아하게 처리할 수 있어, 복잡한 사이드 이펙트 관리도 가능하다. 이러한 풍부한 도구와 확장성은 개발 경험을 크게 개선한다.

레덕스의 주요 단점 중 하나는 보일러플레이트 코드가 많다는 점이다. 상태를 업데이트하기 위해서는 액션을 정의하고, 액션 생성자를 만들며, 리듀서에서 해당 액션을 처리하는 코드를 작성해야 한다. 이는 간단한 상태 변경에도 상대적으로 많은 코드를 요구하게 되어, 특히 소규모 프로젝트에서는 과도한 설정 작업으로 느껴질 수 있다.

또한, 레덕스는 상태를 불변하게 유지해야 하며, 상태 변화는 순수 함수인 리듀서 내에서만 이루어져야 한다는 엄격한 원칙을 따른다. 이는 상태 예측 가능성을 높이는 장점이지만, 개발자에게 불변성 관리에 대한 부담을 준다. 상태가 중첩된 복잡한 객체 구조를 가질 경우, 이를 올바르게 업데이트하기 위해 스프레드 연산자나 immer 같은 외부 라이브러리의 도움 없이는 코드가 장황해지기 쉽다.

레덕스의 구조는 상태를 전역 상태로 중앙 집중화하여 관리한다. 이는 상태 흐름을 명확하게 하지만, 애플리케이션의 모든 상태 변화가 하나의 스토어를 거치게 함으로써 과도한 동기화 문제를 일으킬 수 있다. 컴포넌트의 지역적 UI 상태까지 레덕스에 저장하게 되면, 사소한 상태 변화에도 많은 컴포넌트가 불필요하게 리렌더링되는 성능 문제가 발생할 수 있다.

마지막으로, 레덕스는 본질적으로 동기적인 흐름을 따르기 때문에 비동기 작업을 직접 처리할 수 없다. 서버 API 호출과 같은 비동기 로직을 다루려면 미들웨어를 추가로 도입해야 한다. Redux Thunk나 Redux Saga와 같은 미들웨어를 사용해야 하므로, 학습 곡선이 더욱 가파르고 애플리케이션 구조가 복잡해지는 경향이 있다.

React-Redux는 레드덕스 상태 관리 라이브러리를 리액트 애플리케이션에서 효율적으로 사용할 수 있도록 연결해 주는 공식 바인딩 라이브러리이다. 리액트 컴포넌트가 레드덕스 스토어에 저장된 전역 상태를 쉽게 읽고, 상태 변경을 위한 액션을 디스패치할 수 있도록 하는 역할을 한다. 이 라이브러리의 핵심은 컨텍스트 API를 기반으로 한 Provider 컴포넌트와 connect 함수 또는 훅을 제공하여, 컴포넌트 트리 전체에 스토어를 주입하고 개별 컴포넌트가 필요한 상태 조각에만 반응하도록 최적화하는 데 있다.

주요 API로는 애플리케이션의 최상위 레벨에 스토어를 제공하는 Provider 컴포넌트가 있다. 또한, 클래스형 컴포넌트에서는 connect 고차 컴포넌트를 사용하여 상태와 디스패치 함수를 프롭스로 매핑했으나, 함수형 컴포넌트가 주류가 된 현대적인 개발에서는 useSelector와 useDispatch 같은 훅을 주로 사용한다. useSelector 훅은 스토어의 상태를 선택하여 구독하고, useDispatch 훅은 액션을 디스패치하는 함수를 반환한다.

React-Redux를 사용함으로써 얻는 가장 큰 이점은 리액트 컴포넌트의 관심사 분리를 명확히 할 수 있다는 점이다. 프레젠테이셔널 컴포넌트는 UI 렌더링에만 집중하고, 컨테이너 컴포넌트 또는 훅을 통해 상태 로직을 처리함으로써 컴포넌트의 재사용성과 테스트 용이성이 향상된다. 또한, 라이브러리 내부의 정교한 최적화 덕분에 상태가 변경될 때 연결된 컴포넌트만 정확하게 다시 렌더링되도록 보장하여 성능 저하를 방지한다.

이 라이브러리는 레드덕스의 예측 가능한 상태 관리 패턴과 리액트의 선언적 UI 패러다임을 결합하는 사실상의 표준으로 자리 잡았다. Redux Toolkit이 권장되는 현대적인 레드덕스 개발 흐름에서도 React-Redux는 여전히 필수적인 종속성으로 포함되며, 두 도구는 함께 사용되어 보일러플레이트 코드를 크게 줄이고 개발 경험을 향상시킨다.

레덕스 툴킷(Redux Toolkit)은 레덕스를 사용하는 애플리케이션을 더 쉽고 효율적으로 작성하기 위해 공식적으로 권장되는 도구 세트이다. 기존 레덕스의 보일러플레이트 코드(반복적이고 필수적인 코드)를 상당히 줄이고, 일반적인 사용 패턴을 단순화하며, 실수를 방지하는 데 초점을 맞춘다. 이는 레덕스 개발 경험을 현대화하고, 상태 관리 로직을 더 간결하고 읽기 쉽게 만드는 것을 목표로 한다.

이 라이브러리의 핵심 기능으로는 configureStore, createSlice, createAsyncThunk 등이 있다. configureStore는 기본 미들웨어와 리덕스 개발자 도구(Redux DevTools) 확장을 자동으로 설정하여 스토어 생성 과정을 단순화한다. createSlice는 액션 생성자와 리듀서 함수를 한 번에 정의할 수 있게 해주며, 불변성을 유지하기 위해 내부적으로 이머(Immer) 라이브러리를 사용하여 상태를 직접 수정하는 듯한 코드를 작성할 수 있게 한다. createAsyncThunk는 비동기 로직 처리를 표준화하는 데 도움을 준다.

레덕스 툴킷은 기존 레덕스의 세 가지 기본 원칙을 그대로 유지하면서도, 더 나은 개발자 경험을 제공한다. 이 도구의 등장으로 인해, 새로운 프로젝트에서는 순수 레덕스 코어 대신 레덕스 툴킷을 사용하는 것이 표준이 되었다. 또한 리액트와의 통합을 위한 리액트 리덕스(React-Redux) 라이브러리와도 완벽하게 호환되어 함께 사용된다.

레덕스 애플리케이션에서 비동기 작업이나 사이드 이펙트를 처리하기 위해 사용되는 주요 미들웨어 라이브러리로는 Redux Thunk와 Redux Saga가 있다. 이들은 모두 액션이 디스패치되는 시점과 리듀서가 상태를 업데이트하는 시점 사이에 위치하여 복잡한 로직을 처리한다.

Redux Thunk는 기본적인 접근 방식을 제공하는 미들웨어이다. 이 라이브러리를 사용하면 액션 생성자가 객체 대신 함수를 반환할 수 있게 된다. 이 함수는 디스패치와 getState 메서드를 인자로 받아, 내부에서 비동기 API 호출을 수행한 후 그 결과에 따라 적절한 액션을 디스패치하는 로직을 작성할 수 있다. 설정이 간단하고 학습 곡선이 낮아, 비교적 단순한 비동기 흐름을 처리하는 데 널리 사용된다.

반면, Redux Saga는 보다 강력하고 체계적인 방식을 선호하는 경우에 사용된다. 이 라이브러리는 제너레이터 함수를 활용하여 사이드 이펙트를 관리한다. 사가라고 불리는 이러한 제너레이터 함수는 액션을 감시하다가 특정 액션이 디스패치되면 복잡한 비동기 작업 흐름을 시작한다. Redux Saga는 비동기 작업의 취소, 경쟁 상태 처리, 주기적인 작업 실행 등 정교한 제어가 필요한 시나리오에 특히 유용하다. 테스트 용이성과 로직의 명확한 분리 측면에서 장점을 가진다.

두 라이브러리의 선택은 프로젝트의 복잡도와 개발 팀의 선호도에 따라 달라진다. Redux Thunk는 빠른 적용과 단순함을, Redux Saga는 확장성과 복잡한 비즈니스 로직의 효율적 관리를 각각의 주요 가치로 제공한다. 현대적인 레덕스 개발에서는 공식 권장 도구인 Redux Toolkit이 내장된 Thunk 미들웨어를 제공하여, 대부분의 일반적인 비동기 시나리오를 커버하는 추세이다.