Redux vs Bloc 상태 관리 패러다임 비교

1. 패러다임: 함수형 프로그래밍 vs 리액티브 프로그래밍

Redux와 Bloc의 가장 큰 차이점은 어떤 프로그래밍 패러다임에서 영감을 받았느냐에 있다.

• Redux Redux는 함수형 프로그래밍(Functional Programming) 개념을 기반으로 한다.

  • 상태(state)는 불변(immutable) 해야 하며,

  • 상태를 변경하는 함수는 순수 함수(pure function) 이어야 한다.

  • 이러한 특성 덕분에 Redux를 사용하면 예측 가능한( predictable ) 상태 관리가 가능하다.

• Bloc 반면, Bloc은 리액티브 프로그래밍(Reactive Programming) 개념을 기반으로 한다.

  • 스트림(Stream) 을 활용하여 데이터를 전달하고,

  • Observer 패턴(발행-구독 패턴, Publish-Subscribe) 을 사용해 변화를 감지한다.

  • 즉, 특정 데이터 흐름을 감시(Observe) 하고 있다가 새로운 데이터가 들어오면 자동으로 반응(React)하도록 설계된다.

리액티브 프로그래밍은 처음 접하면 복잡하게 느껴질 수 있지만, 데이터를 효율적으로 처리하고 반응형 UI를 구현하는 데 강력한 패러다임이다. 앞으로 더욱 중요한 개념이 될 가능성이 크다.

2. 전역 저장소 vs 분산된 상태 관리

Redux와 Bloc의 또 다른 차이점은 상태 관리 방식이다.

• Redux: 하나의 전역 Store

  • Redux는 전역 상태 저장소(Global Store) 를 중심으로 동작한다.

  • 애플리케이션 내 모든 상태를 단 하나의 전역 Store에서 관리한다.

  • 하나의 Store만 유지하는 이유는 데이터 일관성(Consistency) 을 보장하기 위함이다.

  • 만약 여러 개의 Store를 사용한다면, 데이터가 서로 다른 Store에 분산되면서 일관성이 깨질 위험이 있다.

• Bloc: 여러 개의 Blocs

  • Bloc은 하나의 거대한 Store를 사용하지 않고, 여러 개의 Bloc을 필요에 따라 생성하여 관리한다.

  • 즉, 각각의 기능(feature)이나 위젯(widget) 단위로 독립적인 Bloc을 만들고 데이터를 분배한다.

  • 이러한 방식은 모듈화(Modularization)에 유리하며, 특정 화면이나 기능에서만 필요한 상태를 관리할 수 있어 더 유연하다.

3. Redux와 Bloc, 어떤 경우에 사용할까?

• Redux가 적합한 경우

  • 앱의 전역적인 상태(State)를 체계적으로 관리할 필요가 있을 때

  • 예측 가능한 상태 관리가 중요한 프로젝트 (e.g. 대형 애플리케이션, 복잡한 비즈니스 로직)

• Bloc이 적합한 경우

  • 각 기능별로 독립적인 상태 관리를 원할 때

  • 리액티브 프로그래밍이 필요한 경우 (e.g. 실시간 데이터 스트리밍, 이벤트 기반 UI 업데이트)

정리

Redux와 Bloc은 각각 다른 철학과 패러다임을 기반으로 하는 상태 관리 라이브러리이다. Redux는 함수형 프로그래밍을 따르며 전역 Store를 통해 일관된 상태 관리를 제공하는 반면, Bloc은 리액티브 프로그래밍을 활용해 다수의 Bloc을 통해 유연한 상태 관리를 가능하게 한다.

Redux vs Bloc: 코드 작성량과 학습 곡선 비교

1. 코드 작성량: Redux가 더 많을까?

상태 관리를 도입할 때 개발자가 가장 먼저 고민하는 것 중 하나는 얼마나 많은 코드를 작성해야 하는지이다.

• Redux: 코드 작성량이 많음

  • Redux를 사용하려면 다음과 같은 요소들을 직접 만들어야 한다.

    1. Store 생성 및 루트 컴포넌트에 주입

    2. Reducer 생성 (상태 변화 로직)

    3. Action 및 Event 정의

    4. (선택사항) Thunk/Middleware 추가

  • 즉, 각 Reducer마다 Action과 Event를 따로 정의해야 하기 때문에 코드량이 많아진다.

  • 처음부터 Redux를 적용하려면 구조를 잘 이해해야 하므로 초반 진입 장벽이 높다.

• Bloc: 상대적으로 코드 작성량이 적음

  • Bloc을 사용할 때는 보통 다음과 같은 요소들만 필요하다.

    1. Bloc 또는 Cubit 생성

    2. Event (Bloc을 사용할 경우) 및 State 정의

    3. Bloc을 UI에 연결하여 상태 변화 감지

  • Redux처럼 별도의 Reducer를 만들고 Store를 전역으로 관리할 필요가 없기 때문에 코드량이 줄어든다.

  • 특히 Cubit을 사용하면 이벤트(Event) 없이도 간단한 상태 관리를 할 수 있어 코드가 더 짧아진다.

2. 학습 곡선: Redux vs Bloc

코드량이 적다고 해서 반드시 쉽게 배울 수 있는 것은 아니다.

• Redux: 코드 작성량은 많지만, 개념은 직관적

  • Redux는 함수형 프로그래밍에 익숙하다면 개념적으로 이해하기 쉽다.

  • 상태가 어떻게 변하는지(불변성, 순수 함수) 직관적으로 볼 수 있어서 예측 가능성(Predictability)이 높다.

  • 하지만 코드 구조가 다소 번거롭고 boilerplate(반복되는 코드)가 많아 처음 도입할 때 부담이 될 수 있다.

• Bloc: 코드량은 적지만, 개념이 더 어려움

  • Bloc은 리액티브 프로그래밍(Reactive Programming) 을 기반으로 하므로,

    • Stream 개념

    • Observer 패턴(구독-발행 모델)

    • 비동기 상태 관리 같은 개념들을 잘 이해해야 한다.

  • 처음 접하면 복잡하게 느껴질 수 있지만, 일단 개념을 익히고 나면 코드량이 적고 유지보수가 쉬운 장점이 있다.

3. Redux vs Bloc, 어떤 개발자에게 적합할까?

	Redux	Bloc
코드량	많음 (boilerplate가 많음)	적음 (Cubit 사용 시 더 단순)
학습 난이도	상대적으로 쉬움 (함수형 프로그래밍 기반)	상대적으로 어려움 (리액티브 프로그래밍 개념 필요)
예측 가능성	높음 (순수 함수 기반)	중간 (비동기 이벤트 기반)
유지보수	복잡할 수 있음	기능별로 Bloc을 나눌 수 있어 유리

4. 정리

• Redux는 다소 많은 코드를 작성해야 하지만, 상태 변화를 예측하기 쉽고 함수형 프로그래밍 개념에 익숙하다면 직관적으로 사용할 수 있다.

• Bloc은 코드량이 적고 유지보수가 쉽지만, 리액티브 프로그래밍 개념(Stream, Observer 패턴)을 익히는 것이 어려울 수 있다.

Redux

Redux 3원칙

1. Single Source of Truth

• 상태(State)는 하나의 스토어(Store)에서 관리된다.

• 애플리케이션의 전체 상태는 단일 스토어에 집중되어 있어야 한다.

• 모든 컴포넌트는 이 스토어를 통해 상태를 읽고 변경해야 한다.

2. State is Read-Only

• 직접 상태를 변경할 수 없다.

• 상태를 변경하려면 반드시 새로운 상태 객체를 만들어야 한다.

• 상태 변경은 오직 Action → Reducer 를 통해서만 가능하다.

3. Changes are Made with Pure Functions

• 상태 변경을 담당하는 Reducer 는 순수 함수여야 한다.

• 순수 함수란:

  • 동일한 입력이 주어지면 항상 동일한 결과를 반환한다.

  • 외부 상태를 변경하지 않는다.

  • 부수 효과(Side Effect)가 없다.

• Reducer는 이전 상태 + 액션을 받아 새로운 상태를 반환해야 한다.

✔ 상태 관리가 체계적으로 이루어진다. ✔ 상태 변경 과정이 예측 가능하고 추적 가능하다. ✔ 디버깅과 유지보수가 쉬워진다.