Flutter 튜토리얼 12편: 상태 관리 라이브러리 비교

요약#

핵심 요지#

문제 정의: Flutter에는 다양한 상태 관리 라이브러리가 있어서 어떤 것을 선택해야 할지 혼란스럽다.
핵심 주장: 팀 규모, 앱 복잡도, 유지보수 요구사항에 따라 적합한 라이브러리가 다르다.
주요 근거: Provider¹는 입문용으로 적합하고, Riverpod²은 신규 프로젝트의 표준이 되고 있으며, BLoC³은 대규모 엔터프라이즈에 적합하다.
실무 기준: 소규모 앱은 Provider나 setState, 중대규모 앱은 Riverpod, 엔터프라이즈는 BLoC을 권장한다.
한계: 완벽한 라이브러리는 없으며, 팀의 경험과 프로젝트 요구사항에 따라 선택해야 한다.

문서가 설명하는 범위#

Flutter의 기본 제공 상태 관리 방식
주요 상태 관리 라이브러리 비교 (Provider, Riverpod, BLoC, GetX)
라이브러리별 코드 예시
프로젝트 상황에 따른 선택 기준

읽는 시간: 18분 | 난이도: 중급

참고 자료#

List of state management approaches - Flutter 공식 상태 관리 옵션
State management packages on pub.dev - pub.dev 상태 관리 패키지

문제 상황#

Flutter 생태계에는 수십 개의 상태 관리 라이브러리가 존재합니다.
pub.dev에서 “state-management” 토픽으로 검색하면 100개 이상의 패키지가 나옵니다.

선택의 어려움#

1
상태 관리 라이브러리 선택 시 고민
2
├── Provider - Google 공식 권장, 간단함
3
├── Riverpod - Provider 개선, 컴파일 타임 안전성
4
├── BLoC - 이벤트 기반, 엔터프라이즈 표준
5
├── GetX - 올인원, 간편함
6
├── Redux - React 생태계에서 유명
7
├── MobX - 리액티브 프로그래밍
8
└── ... 수십 개 더

어떤 라이브러리가 “최고”인지 묻는 것은 의미가 없습니다. 중요한 것은 “내 프로젝트와 팀에 맞는” 라이브러리를 선택하는 것입니다.

해결 방법#

라이브러리를 선택하기 전에 각각의 특징과 적합한 상황을 이해해야 합니다. Flutter에서 가장 많이 사용되는 4가지 접근 방식을 비교합니다.

챕터 1: Flutter 기본 제공 방식 이해하기#

Why#

NOTE
외부 라이브러리 없이도 Flutter가 제공하는 기본 도구로 상태를 관리할 수 있습니다.
기본 방식을 이해해야 라이브러리들이 해결하려는 문제가 무엇인지 알 수 있습니다.
1
// Flutter 기본 제공 상태 관리
2
// 1. setState - 위젯 내부 상태
3
// 2. InheritedWidget - 위젯 트리 공유
4
// 3. ValueNotifier - 단일 값 변경 감지

What#

NOTE
Flutter는 세 가지 기본 상태 관리 도구를 제공합니다.

도구 용도 복잡도
setState 단일 위젯 내부 상태 낮음
InheritedWidget 위젯 트리에 데이터 공유 중간
ValueNotifier 단일 값 변경 감지 낮음

도구	용도	복잡도
`setState`	단일 위젯 내부 상태	낮음
`InheritedWidget`	위젯 트리에 데이터 공유	중간
`ValueNotifier`	단일 값 변경 감지	낮음

How#

TIP

setState - 가장 기본적인 방식

1
class Counter extends StatefulWidget {
2
  @override
3
  State<Counter> createState() => _CounterState();
4
}
5

6
class _CounterState extends State<Counter> {
7
  int _count = 0;
8

9
  @override
10
  Widget build(BuildContext context) {
11
    return Column(
12
      children: [
13
        Text('Count: $_count'),
14
        ElevatedButton(
15
          onPressed: () {
16
            setState(() {
17
              _count++;
18
            });
19
          },
20
          child: Text('Increment'),
21
        ),
22
      ],
23
    );
24
  }
25
}

ValueNotifier와 ValueListenableBuilder

1
class CounterWithNotifier extends StatefulWidget {
2
  @override
3
  State<CounterWithNotifier> createState() => _CounterWithNotifierState();
4
}
5

6
class _CounterWithNotifierState extends State<CounterWithNotifier> {
7
  final ValueNotifier<int> _counter = ValueNotifier(0);
8

9
  @override
10
  void dispose() {
11
    _counter.dispose();
12
    super.dispose();
13
  }
14

15
  @override
16
  Widget build(BuildContext context) {
17
    return Column(
18
      children: [
19
        ValueListenableBuilder<int>(
20
          valueListenable: _counter,
21
          builder: (context, value, child) {
22
            return Text('Count: $value');
23
          },
24
        ),
25
        ElevatedButton(
26
          onPressed: () => _counter.value++,
27
          child: Text('Increment'),
28
        ),
29
      ],
30
    );
31
  }
32
}

InheritedWidget - 위젯 트리 공유

1
class CounterProvider extends InheritedWidget {
2
  final int count;
3
  final VoidCallback increment;
4

5
  const CounterProvider({
6
    required this.count,
7
    required this.increment,
8
    required Widget child,
9
  }) : super(child: child);
10

11
  static CounterProvider of(BuildContext context) {
12
    return context.dependOnInheritedWidgetOfExactType<CounterProvider>()!;
13
  }
14

15
  @override
16
  bool updateShouldNotify(CounterProvider oldWidget) {
17
    return count != oldWidget.count;
18
  }
19
}

Watch out#

WARNING

기본 제공 도구만으로는 복잡한 앱을 관리하기 어렵습니다.

1
// InheritedWidget의 한계
2
// 1. 상태 변경 로직을 별도로 구현해야 함
3
// 2. 위젯 재빌드 최적화가 어려움
4
// 3. 보일러플레이트 코드가 많음
5

6
// 이런 한계를 해결하기 위해 상태 관리 라이브러리가 등장

결론: 기본 도구는 간단한 상태에 적합하지만, 복잡한 앱에서는 라이브러리가 필요합니다.

챕터 2: Provider 이해하기#

Why#

NOTE
InheritedWidget을 직접 사용하기에는 보일러플레이트가 많습니다.
Provider는 InheritedWidget을 감싸서 사용하기 쉽게 만든 패키지입니다.
1
// InheritedWidget 직접 사용: 50줄 이상
2
// Provider 사용: 10줄 이하

What#

NOTE
Provider는 Flutter 팀이 공식 권장하는 상태 관리 패키지입니다.
간단한 API로 위젯 트리에 데이터를 제공하고 변경을 감지합니다.

특징 설명
장점 배우기 쉬움, 공식 권장, 안정적
단점 런타임 타입 체크, 복잡한 의존성 처리 어려움
적합한 상황 입문자, 소규모~중규모 앱

특징	설명
장점	배우기 쉬움, 공식 권장, 안정적
단점	런타임 타입 체크, 복잡한 의존성 처리 어려움
적합한 상황	입문자, 소규모~중규모 앱

How#

TIP

설치

1
dependencies:
2
  provider: ^6.1.0

ChangeNotifier 정의

1
import 'package:flutter/foundation.dart';
2

3
class CartModel extends ChangeNotifier {
4
  final List<String> _items = [];
5

6
  List<String> get items => List.unmodifiable(_items);
7

8
  int get totalItems => _items.length;
9

10
  void add(String item) {
11
    _items.add(item);
12
    notifyListeners();  // 리스너들에게 변경 알림
13
  }
14

15
  void remove(String item) {
16
    _items.remove(item);
17
    notifyListeners();
18
  }
19
}

Provider 제공

1
void main() {
2
  runApp(
3
    ChangeNotifierProvider(
4
      create: (context) => CartModel(),
5
      child: MyApp(),
6
    ),
7
  );
8
}

상태 사용 - Consumer

1
class CartPage extends StatelessWidget {
2
  @override
3
  Widget build(BuildContext context) {
4
    return Consumer<CartModel>(
5
      builder: (context, cart, child) {
6
        return Column(
7
          children: [
8
            Text('Total items: ${cart.totalItems}'),
9
            ListView.builder(
10
              shrinkWrap: true,
11
              itemCount: cart.items.length,
12
              itemBuilder: (context, index) {
13
                return ListTile(title: Text(cart.items[index]));
14
              },
15
            ),
16
          ],
17
        );
18
      },
19
    );
20
  }
21
}

상태 변경 - Provider.of

1
class AddButton extends StatelessWidget {
2
  @override
3
  Widget build(BuildContext context) {
4
    return ElevatedButton(
5
      onPressed: () {
6
        // listen: false는 변경을 구독하지 않음
7
        context.read<CartModel>().add('New Item');
8
      },
9
      child: Text('Add Item'),
10
    );
11
  }
12
}

Watch out#

WARNING
Provider는 런타임에 타입을 체크하므로 컴파일 타임에 오류를 잡지 못합니다.
1
// Provider가 없으면 런타임에 오류 발생
2
class SomePage extends StatelessWidget {
3
  @override
4
  Widget build(BuildContext context) {
5
    // CartModel Provider가 상위에 없으면?
6
    final cart = context.read<CartModel>();  // 런타임 오류!
7
    return Text('Items: ${cart.totalItems}');
8
  }
9
}
BuildContext에 의존하므로 위젯 밖에서 상태에 접근하기 어렵습니다.

결론: Provider는 입문자에게 적합하고, 소규모 앱에서 충분히 잘 동작합니다.

챕터 3: Riverpod 이해하기#

Why#

NOTE
Provider의 창시자가 Provider의 한계를 해결하기 위해 만든 패키지입니다.
BuildContext 없이도 상태에 접근할 수 있고, 컴파일 타임 안전성을 제공합니다.
1
// Provider: 런타임 오류
2
context.read<CartModel>();  // Provider 없으면 런타임 에러
3

4
// Riverpod: 컴파일 타임 체크
5
ref.watch(cartProvider);  // Provider 없으면 컴파일 에러

What#

NOTE
Riverpod은 현재 Flutter 신규 프로젝트의 표준으로 자리잡고 있습니다.
컴파일 타임 안전성, 자동 캐싱, 코드 생성 지원이 핵심 특징입니다.

특징 설명
장점 컴파일 타임 안전성, 테스트 용이, 자동 캐싱
단점 Provider보다 학습 곡선 있음, 기존 코드 마이그레이션 필요
적합한 상황 신규 프로젝트, 중대규모 앱, 테스트 중시

특징	설명
장점	컴파일 타임 안전성, 테스트 용이, 자동 캐싱
단점	Provider보다 학습 곡선 있음, 기존 코드 마이그레이션 필요
적합한 상황	신규 프로젝트, 중대규모 앱, 테스트 중시

How#

TIP

설치

1
dependencies:
2
  flutter_riverpod: ^2.5.0
3
  riverpod_annotation: ^2.3.0
4

5
dev_dependencies:
6
  riverpod_generator: ^2.4.0
7
  build_runner: ^2.4.0

Provider 정의 (코드 생성 방식)

1
import 'package:riverpod_annotation/riverpod_annotation.dart';
2

3
part 'cart_provider.g.dart';
4

5
@riverpod
6
class Cart extends _$Cart {
7
  @override
8
  List<String> build() {
9
    return [];  // 초기 상태
10
  }
11

12
  void add(String item) {
13
    state = [...state, item];
14
  }
15

16
  void remove(String item) {
17
    state = state.where((e) => e != item).toList();
18
  }
19
}

앱 설정

1
void main() {
2
  runApp(
3
    ProviderScope(  // Riverpod의 최상위 위젯
4
      child: MyApp(),
5
    ),
6
  );
7
}

상태 사용

1
class CartPage extends ConsumerWidget {
2
  @override
3
  Widget build(BuildContext context, WidgetRef ref) {
4
    final cartItems = ref.watch(cartProvider);  // 상태 구독
5

6
    return Column(
7
      children: [
8
        Text('Total items: ${cartItems.length}'),
9
        ListView.builder(
10
          shrinkWrap: true,
11
          itemCount: cartItems.length,
12
          itemBuilder: (context, index) {
13
            return ListTile(title: Text(cartItems[index]));
14
          },
15
        ),
16
      ],
17
    );
18
  }
19
}

상태 변경

1
class AddButton extends ConsumerWidget {
2
  @override
3
  Widget build(BuildContext context, WidgetRef ref) {
4
    return ElevatedButton(
5
      onPressed: () {
6
        ref.read(cartProvider.notifier).add('New Item');
7
      },
8
      child: Text('Add Item'),
9
    );
10
  }
11
}

Watch out#

WARNING
Riverpod은 Provider와 완전히 다른 패키지입니다.
기존 Provider 프로젝트를 마이그레이션하려면 상당한 작업이 필요합니다.
1
// Provider → Riverpod 마이그레이션
2
// 1. 모든 Provider를 Riverpod Provider로 변환
3
// 2. Consumer → ConsumerWidget 또는 Consumer로 변경
4
// 3. context.read → ref.read로 변경
5

6
// 점진적 마이그레이션 불가능 - 한 번에 전환 필요
코드 생성 방식을 사용하면 build_runner를 실행해야 합니다.
Terminal window
1
dart run build_runner watch

결론: Riverpod은 신규 프로젝트에 권장되며, 컴파일 타임 안전성이 큰 장점입니다.

챕터 4: BLoC 이해하기#

Why#

NOTE
대규모 팀이나 엔터프라이즈 앱에서는 엄격한 아키텍처가 필요합니다.
BLoC은 이벤트 기반 아키텍처로 명확한 구조와 감사 추적(audit trail)을 제공합니다.
1
// BLoC의 핵심 원칙
2
// UI → Event → BLoC → State → UI
3
// 모든 상태 변경이 이벤트로 기록됨

What#

NOTE
BLoC(Business Logic Component)은 UI와 비즈니스 로직을 완전히 분리합니다.
이벤트 기반 아키텍처로 모든 상태 변경을 추적할 수 있습니다.

특징 설명
장점 엄격한 구조, 테스트 용이, 이벤트 추적 가능
단점 보일러플레이트 많음, 학습 곡선 가파름
적합한 상황 대규모 팀, 엔터프라이즈 앱, 규제 산업

특징	설명
장점	엄격한 구조, 테스트 용이, 이벤트 추적 가능
단점	보일러플레이트 많음, 학습 곡선 가파름
적합한 상황	대규모 팀, 엔터프라이즈 앱, 규제 산업

How#

TIP

설치

1
dependencies:
2
  flutter_bloc: ^8.1.0

이벤트 정의

1
abstract class CartEvent {}
2

3
class AddItem extends CartEvent {
4
  final String item;
5
  AddItem(this.item);
6
}
7

8
class RemoveItem extends CartEvent {
9
  final String item;
10
  RemoveItem(this.item);
11
}

상태 정의

1
class CartState {
2
  final List<String> items;
3

4
  const CartState({this.items = const []});
5

6
  CartState copyWith({List<String>? items}) {
7
    return CartState(items: items ?? this.items);
8
  }
9
}

BLoC 정의

1
import 'package:flutter_bloc/flutter_bloc.dart';
2

3
class CartBloc extends Bloc<CartEvent, CartState> {
4
  CartBloc() : super(const CartState()) {
5
    on<AddItem>(_onAddItem);
6
    on<RemoveItem>(_onRemoveItem);
7
  }
8

9
  void _onAddItem(AddItem event, Emitter<CartState> emit) {
10
    final updatedItems = List<String>.from(state.items)..add(event.item);
11
    emit(state.copyWith(items: updatedItems));
12
  }
13

14
  void _onRemoveItem(RemoveItem event, Emitter<CartState> emit) {
15
    final updatedItems = List<String>.from(state.items)..remove(event.item);
16
    emit(state.copyWith(items: updatedItems));
17
  }
18
}

BLoC 제공

1
void main() {
2
  runApp(
3
    BlocProvider(
4
      create: (context) => CartBloc(),
5
      child: MyApp(),
6
    ),
7
  );
8
}

상태 사용

1
class CartPage extends StatelessWidget {
2
  @override
3
  Widget build(BuildContext context) {
4
    return BlocBuilder<CartBloc, CartState>(
5
      builder: (context, state) {
6
        return Column(
7
          children: [
8
            Text('Total items: ${state.items.length}'),
9
            ListView.builder(
10
              shrinkWrap: true,
11
              itemCount: state.items.length,
12
              itemBuilder: (context, index) {
13
                return ListTile(title: Text(state.items[index]));
14
              },
15
            ),
16
          ],
17
        );
18
      },
19
    );
20
  }
21
}

이벤트 발생

1
class AddButton extends StatelessWidget {
2
  @override
3
  Widget build(BuildContext context) {
4
    return ElevatedButton(
5
      onPressed: () {
6
        context.read<CartBloc>().add(AddItem('New Item'));
7
      },
8
      child: Text('Add Item'),
9
    );
10
  }
11
}

Watch out#

WARNING

BLoC은 간단한 기능에도 많은 파일과 코드가 필요합니다.

1
// 카운터 하나를 위해 필요한 파일들
2
// 1. counter_event.dart - 이벤트 정의
3
// 2. counter_state.dart - 상태 정의
4
// 3. counter_bloc.dart - 로직 정의
5
// 4. counter_page.dart - UI
6

7
// 간단한 앱에는 과도한 구조

Cubit을 사용하면 이벤트 없이 간소화할 수 있습니다.

1
class CounterCubit extends Cubit<int> {
2
  CounterCubit() : super(0);
3

4
  void increment() => emit(state + 1);
5
  void decrement() => emit(state - 1);
6
}

결론: BLoC은 대규모 팀과 엔터프라이즈 앱에서 강력한 구조를 제공합니다.

챕터 5: GetX 이해하기#

Why#

NOTE
GetX는 상태 관리, 라우팅, 의존성 주입을 하나의 패키지에 제공합니다.
빠른 개발과 적은 보일러플레이트를 목표로 합니다.
1
// GetX는 "올인원" 솔루션
2
// 상태 관리 + 라우팅 + 의존성 주입 + 유틸리티

What#

NOTE
GetX는 간편한 API로 빠른 개발을 가능하게 하지만, 주의가 필요합니다.
최근 유지보수 지연과 Flutter SDK 호환성 문제가 보고되고 있습니다.

특징 설명
장점 적은 보일러플레이트, 올인원 솔루션, 배우기 쉬움
단점 유지보수 지연, 전역 상태 디버깅 어려움, 메모리 누수 위험
적합한 상황 프로토타입, 소규모 개인 프로젝트

특징	설명
장점	적은 보일러플레이트, 올인원 솔루션, 배우기 쉬움
단점	유지보수 지연, 전역 상태 디버깅 어려움, 메모리 누수 위험
적합한 상황	프로토타입, 소규모 개인 프로젝트

How#

TIP

설치

1
dependencies:
2
  get: ^4.6.6

Controller 정의

1
import 'package:get/get.dart';
2

3
class CartController extends GetxController {
4
  final items = <String>[].obs;  // .obs로 반응형 변수 생성
5

6
  int get totalItems => items.length;
7

8
  void add(String item) {
9
    items.add(item);
10
  }
11

12
  void remove(String item) {
13
    items.remove(item);
14
  }
15
}

Controller 등록

1
void main() {
2
  Get.put(CartController());  // 의존성 주입
3
  runApp(MyApp());
4
}

상태 사용

1
class CartPage extends StatelessWidget {
2
  final CartController cart = Get.find();  // Controller 찾기
3

4
  @override
5
  Widget build(BuildContext context) {
6
    return Column(
7
      children: [
8
        Obx(() => Text('Total items: ${cart.totalItems}')),  // 반응형 빌더
9
        Obx(() => ListView.builder(
10
          shrinkWrap: true,
11
          itemCount: cart.items.length,
12
          itemBuilder: (context, index) {
13
            return ListTile(title: Text(cart.items[index]));
14
          },
15
        )),
16
      ],
17
    );
18
  }
19
}

상태 변경

1
class AddButton extends StatelessWidget {
2
  @override
3
  Widget build(BuildContext context) {
4
    return ElevatedButton(
5
      onPressed: () {
6
        Get.find<CartController>().add('New Item');
7
      },
8
      child: Text('Add Item'),
9
    );
10
  }
11
}

Watch out#

WARNING
GetX는 전문가들 사이에서 신규 프로젝트에 권장되지 않습니다.
1
// GetX의 문제점
2
// 1. 유지보수자 1명 의존 - "버스 팩터" 위험
3
// 2. Flutter SDK 업데이트 지연
4
// 3. 전역 싱글톤 아키텍처 - 디버깅 어려움
5
// 4. Controller 해제 불확실 - 메모리 누수 위험
6

7
// 기존 GetX 프로젝트는 마이그레이션 계획 권장
빠른 프로토타이핑에는 유용하지만, 프로덕션 앱에서는 다른 솔루션을 권장합니다.

결론: GetX는 빠른 개발에 유용하지만, 장기적인 프로젝트에서는 신중히 고려해야 합니다.

챕터 6: 라이브러리 선택 기준#

Why#

NOTE
“최고의” 라이브러리는 없습니다.
프로젝트 상황, 팀 경험, 유지보수 요구사항에 따라 적합한 선택이 달라집니다.

What#

NOTE
선택 기준을 정리하면 다음과 같습니다.

상황 권장 라이브러리 이유
입문/학습 Provider 공식 권장, 낮은 학습 곡선
신규 프로젝트 Riverpod 컴파일 타임 안전성, 현대적
대규모/엔터프라이즈 BLoC 엄격한 구조, 이벤트 추적
프로토타입 GetX/setState 빠른 개발, 적은 설정
레거시 유지보수 기존 라이브러리 유지 마이그레이션 비용 고려

상황	권장 라이브러리	이유
입문/학습	Provider	공식 권장, 낮은 학습 곡선
신규 프로젝트	Riverpod	컴파일 타임 안전성, 현대적
대규모/엔터프라이즈	BLoC	엄격한 구조, 이벤트 추적
프로토타입	GetX/setState	빠른 개발, 적은 설정
레거시 유지보수	기존 라이브러리 유지	마이그레이션 비용 고려

How#

TIP
보일러플레이트 비교
1
// 같은 카운터 기능 구현 시 코드량 비교
2

3
// setState: ~20줄
4
// Provider: ~30줄
5
// Riverpod: ~25줄 (코드 생성 후)
6
// BLoC: ~50줄+ (이벤트, 상태, BLoC 분리)
7
// GetX: ~15줄
결정 플로우차트
flowchart TD A[프로젝트 시작] --> B{팀 규모} B -->|1-3명| C{앱 복잡도} B -->|4명 이상| D[BLoC 또는 Riverpod] C -->|간단함| E[Provider 또는 setState] C -->|복잡함| F[Riverpod] D --> G{규제 산업?} G -->|예| H[BLoC] G -->|아니오| I[Riverpod]
팀 경험 고려
1
// 팀에 React 경험자가 많으면
2
// → Redux 패턴이 익숙할 수 있음
3

4
// 팀에 Angular 경험자가 많으면
5
// → RxDart와 BLoC이 익숙할 수 있음
6

7
// Flutter 초보 팀이면
8
// → Provider로 시작, 필요시 Riverpod으로 전환

Watch out#

WARNING
라이브러리를 혼합해서 사용하면 코드 일관성이 떨어집니다.
1
// 나쁜 예: 여러 라이브러리 혼용
2
// 화면 A: Provider
3
// 화면 B: GetX
4
// 화면 C: BLoC
5
// → 유지보수 어려움, 팀원 혼란
6

7
// 좋은 예: 하나의 라이브러리로 통일
8
// 전체 앱: Riverpod
9
// → 일관된 패턴, 예측 가능한 코드
한 번 선택하면 변경 비용이 크므로 신중하게 결정하세요.

결론: 팀 규모, 앱 복잡도, 유지보수 요구사항을 고려해 라이브러리를 선택합니다.

한계#

상태 관리 라이브러리 선택에는 정답이 없습니다.

트레이드오프: 모든 라이브러리는 장단점이 있으며, 하나가 모든 상황에 완벽하지 않습니다.
마이그레이션 비용: 라이브러리 변경은 많은 시간과 노력이 필요합니다.
생태계 변화: Flutter 생태계는 빠르게 변하므로 현재 권장이 미래에도 유효하지 않을 수 있습니다.
팀 합의: 기술적 우수성보다 팀의 합의와 일관성이 더 중요할 수 있습니다.

Provider: Flutter 팀이 공식 권장하는 상태 관리 패키지로, InheritedWidget을 감싸서 사용하기 쉽게 만든 것이다. ↩
Riverpod: Provider의 창시자가 만든 차세대 상태 관리 패키지로, 컴파일 타임 안전성과 BuildContext 독립성이 특징이다. ↩
BLoC(Business Logic Component): 이벤트 기반 아키텍처로 UI와 비즈니스 로직을 분리하는 패턴이다. ↩

Flutter 튜토리얼 12편: 상태 관리 라이브러리 비교

요약#

핵심 요지#

문서가 설명하는 범위#

참고 자료#

문제 상황#

선택의 어려움#

해결 방법#

챕터 1: Flutter 기본 제공 방식 이해하기#

Why#

What#

How#

Watch out#

챕터 2: Provider 이해하기#

Why#

What#

How#

Watch out#

챕터 3: Riverpod 이해하기#

Why#

What#

How#

Watch out#

챕터 4: BLoC 이해하기#

Why#

What#

How#

Watch out#

챕터 5: GetX 이해하기#

Why#

What#

How#

Watch out#

챕터 6: 라이브러리 선택 기준#

Why#

What#

How#

Watch out#

한계#

Footnotes#

공유

목차