[Flutter] 상태관리 뭐 써야 할까? Provider vs Riverpod vs BLoC 비교

[Flutter] 상태관리 뭐 써야 할까? Provider vs Riverpod vs BLoC 비교

Flutter로 앱을 개발하다 보면 상태관리에 대해 반드시 고민하게 됩니다.
처음에는 setState()로 간단히 처리하지만, 규모가 커지면 전역 상태 관리, 비동기 처리, 모듈화가 필요해지죠.

이 글에서는 대표적인 Flutter 상태관리 방식인 Provider, Riverpod, BLoC을 비교하고 언제 어떤 걸 선택하면 좋은지도 함께 정리해드립니다.

---

✅ 1. Provider – 공식이 인정한 기본 상태관리

provider는 Google에서 만든 공식 추천 패키지입니다.
간단한 구조 + 낮은 학습 난이도로 입문자가 쓰기 좋습니다.

// provider 예제: ChangeNotifier 사용
class Counter extends ChangeNotifier {
  int value = 0;
  void increment() {
    value++;
    notifyListeners();
  }
}

// 사용
ChangeNotifierProvider(
  create: (_) => Counter(),
  child: Consumer<Counter>(
    builder: (_, counter, __) => Text('${counter.value}'),
  ),
)

→ 위 구조는 단순한 로직에서는 충분히 강력합니다.

---

✅ 2. Riverpod – Provider의 진화형

riverpod은 Provider의 단점을 개선한 최신 상태관리 방식입니다.
전역 사용 가능, BuildContext 없이도 접근 가능, 더 강력한 타입 안전성이 특징입니다.

// Riverpod 예제 (flutter_riverpod)
final counterProvider = StateProvider((ref) => 0);

// 사용
Consumer(
  builder: (context, ref, _) {
    final count = ref.watch(counterProvider);
    return Text('$count');
  },
);

→ 모듈화, 테스트, 리팩토링에 강한 구조를 원한다면 Riverpod이 더 적합합니다.

---

✅ 3. BLoC – 복잡한 앱에 강한 구조화된 방식

bloc은 이벤트 기반의 구조로 동작하며, Stream과 Sink를 이용해 데이터 흐름을 제어합니다.
기업용 앱, 복잡한 상태 변화가 많은 앱에 적합합니다.

class CounterBloc extends Bloc<CounterEvent, int> {
  CounterBloc() : super(0) {
    on<Increment>((event, emit) => emit(state + 1));
  }
}

// UI에서 Bloc 사용
BlocBuilder<CounterBloc, int>(
  builder: (context, state) {
    return Text('$state');
  },
);

→ 구조가 무겁지만 대규모 협업, 테스트 자동화에 유리합니다.

---

📊 상태관리 방식 비교 요약

방식	장점	단점	추천 대상
Provider	간단하고 익히기 쉬움	대규모 앱에서는 관리 어려움	입문자, 간단한 앱
Riverpod	모듈화, 테스트 용이, 타입 안전	학습 곡선 약간 있음	중급 이상, 장기 운영 앱
BLoC	명확한 이벤트 흐름, 테스트 강점	초기 셋업 복잡	대규모 앱, 협업

---

📌 마무리

Flutter 상태관리는 앱 규모, 개발자 경험, 유지보수 계획에 따라 선택해야 합니다.
처음에는 Provider → 점점 Riverpod or BLoC으로 옮겨가는 것도 좋은 방법입니다.

✅ 실무에서 가장 많이 쓰는 조합은 Riverpod + Freezed입니다.

도움이 되셨다면 공감 / 댓글 부탁드립니다 😊