Todo App on jHoon

Ch05-4. Todo 앱 Riverpod 전환 - 이게 진짜 사기다

Sat, 02 May 2026 00:00:00 +0900

Ch05 시리즈 마지막이다. BLoC에서 Riverpod으로 전환한다. 솔직히 BLoC의 Event 기반 구조가 MVI 느낌이라 꽤 마음에 들었는데, Riverpod 써보니까 생산성이 말이 안 된다. 뷰에서 상태별 분기가 .when 하나로 되고, BLoC에서 필요했던 Event 클래스, State 래퍼, Emitter 전달 같은 보일러플레이트가 싹 사라진다.

이 글의 코드는 flutter_riverpod 2.6.1 기준이다. 최신 Riverpod 3.0과의 차이점은 글 하단에 정리했다.

BLoC → Riverpod, 뭐가 바뀌나

영역	BLoC	Riverpod
상태 클래스	`Bloc<Event, State>` 상속	`StateNotifier<T>` 상속
이벤트	`sealed class TodoEvent` 별도 정의	없음. 메서드 직접 호출
State 래퍼	`@freezed TodoBlocState`	직접 `List<Todo>`
등록	`BlocProvider(create: ...)`	`StateNotifierProvider(...)` 전역 선언
UI 위젯	`StatelessWidget` + `BlocBuilder`	`ConsumerWidget`
접근	`context.read<TodoBloc>()`	`ref.read(provider.notifier)`
구독	`BlocBuilder<TodoBloc, TodoBlocState>`	`ref.watch(provider)`
상태 발행	`emit(state.copyWith(...))`	`state = newValue`

요약하면 BLoC에서 Event 클래스 + State 래퍼 + Emitter 패턴이 전부 사라지고, 직접 메서드 호출 + state 재할당으로 단순해진다.

StateNotifierProvider — 핵심 구조

Provider 선언 (전역)

1
2
3


final todoDataProvider =
 StateNotifierProvider<TodoDataHolder, List<Todo>>(
 (ref) => TodoDataHolder());

이게 끝이다. BLoC에서는 BlocProvider로 위젯 트리에 감싸야 했는데, Riverpod은 전역 변수처럼 선언한다. “provider가 전역으로 선언되었다고 데이터도 전역으로 같이 쓰는 게 아니다” — 이건 뒤에서 Scope로 설명한다.

StateNotifier 구현

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


class TodoDataHolder extends StateNotifier<List<Todo>> {
 TodoDataHolder() : super(<Todo>[]);

 void addTodo() async {
 final result = await WriteTodoDialog().show();
 if (result != null) {
 state.add(
 Todo(
 id: DateTime.now().microsecondsSinceEpoch,
 title: result.text,
 dueDate: result.dateTime,
 ),
 );
 state = List.of(state); // 새 리스트로 재할당 → 리빌드 트리거
 }
 }

 void changeTodoStatus(Todo todo) async {
 switch (todo.status) {
 case TodoStatus.inComplete:
 todo.status = TodoStatus.onGoing;
 case TodoStatus.onGoing:
 todo.status = TodoStatus.complete;
 case TodoStatus.complete:
 final result = await ConfirmDialog('정말로 처음 상태로 변경하시겠어요?').show();
 result?.runIfSuccess((data) {
 todo.status = TodoStatus.inComplete;
 });
 }
 state = List.of(state);
 }

 void editTodo(Todo todo) async {
 final result = await WriteTodoDialog(todoForEdit: todo).show();
 if (result != null) {
 todo.title = result.text;
 todo.dueDate = result.dateTime;
 state = List.of(state);
 }
 }

 void removeTodo(Todo todo) {
 state.remove(todo);
 state = List.of(state);
 }
}

BLoC에서는 emit(state.copyWith(todoList: oldTodoList))로 새 State를 발행했는데, Riverpod에서는 state = List.of(state)로 직접 재할당한다. state에 새 값을 넣으면 구독 중인 위젯이 자동으로 리빌드된다.

BLoC과 비교하면:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// BLoC: Event를 정의하고, 핸들러를 등록하고, Emitter로 발행
sealed class TodoEvent {}
class TodoAddEvent extends TodoEvent {}

class TodoBloc extends Bloc<TodoEvent, TodoBlocState> {
 TodoBloc() : super(...) {
 on<TodoAddEvent>(_addTodo); // 핸들러 등록
 }
 void _addTodo(TodoAddEvent event, Emitter<TodoBlocState> emit) {
 emit(state.copyWith(todoList: newList)); // Emitter로 발행
 }
}

// Riverpod: 그냥 메서드 쓰면 됨
class TodoDataHolder extends StateNotifier<List<Todo>> {
 void addTodo() {
 state = List.of(state); // state 재할당이 곧 발행
 }
}

Event 클래스 정의 → 핸들러 등록 → Emitter 전달 → emit 호출. 이 4단계가 state 재할당 한 줄로 줄었다.

Extension으로 접근 축약

1
2
3


extension TodoListHolderProvider on WidgetRef {
 TodoDataHolder get readTodoHolder => read(todoDataProvider.notifier);
}

ref.read(todoDataProvider.notifier).addTodo() 대신 ref.readTodoHolder.addTodo()로 쓸 수 있다. BLoC에서 context.readTodoBloc으로 축약했던 것과 같은 패턴이다.

ConsumerWidget — UI에서 사용

ProviderScope 설정

1
2
3
4
5
6
7
8
9


// s_main.dart
class MainScreenWrapper extends StatelessWidget {
 const MainScreenWrapper({super.key});

 @override
 Widget build(BuildContext context) {
 return const ProviderScope(child: MainScreen());
 }
}

ProviderScope은 Riverpod의 DI 컨테이너다. 이 안에 있는 위젯들이 Provider에 접근할 수 있다. BLoC의 BlocProvider와 같은 역할이지만, 여러 Provider를 개별적으로 감쌀 필요 없이 하나의 ProviderScope만 있으면 된다.

ConsumerWidget으로 구독

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


// w_todo_list.dart
class TodoList extends ConsumerWidget {
 const TodoList({super.key});

 @override
 Widget build(BuildContext context, WidgetRef ref) {
 final todoList = ref.watch(todoDataProvider); // 구독

 return todoList.isEmpty
 ? const Expanded(
 child: Center(
 child: Text('할 일을 작성해 보세요.',
 style: TextStyle(fontSize: 32)),
 ),
 )
 : Column(
 children: todoList.map((e) => TodoItem(e)).toList(),
 );
 }
}

BLoC에서는 BlocBuilder<TodoBloc, TodoBlocState> 위젯으로 감싸야 했는데, Riverpod은 ConsumerWidget을 상속하면 build 메서드에 WidgetRef ref가 들어온다. ref.watch(provider)로 구독하면 state가 바뀔 때마다 자동 리빌드된다.

ref.watch vs ref.read

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


// w_todo_item.dart
class TodoItem extends ConsumerWidget {
 final Todo todo;

 const TodoItem(this.todo, {super.key});

 @override
 Widget build(BuildContext context, WidgetRef ref) {
 return Dismissible(
 key: ValueKey(todo.id),
 onDismissed: (direction) {
 ref.readTodoHolder.removeTodo(todo); // ref.read: 한 번 읽기
 },
 child: RoundedContainer(
 child: Row(
 children: [
 TodoStatusWidget(todo),
 Text(todo.title),
 const Spacer(),
 IconButton(
 onPressed: () {
 ref.readTodoHolder.editTodo(todo); // ref.read: 이벤트용
 },
 icon: const Icon(EvaIcons.editOutline),
 )
 ],
 ),
 ),
 );
 }
}

메서드	용도	리빌드
`ref.watch(provider)`	상태 구독 (UI 그릴 때)	O
`ref.read(provider.notifier)`	메서드 호출 (이벤트용)	X

BLoC의 context.watch / context.read와 정확히 같은 개념이다. 차이라면 BLoC은 context에서 꺼내고, Riverpod은 ref에서 꺼낸다.

ConsumerStatefulWidget

Rive 애니메이션처럼 lifecycle 메서드가 필요하면 ConsumerStatefulWidget을 쓴다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


class TodoStatusWidget extends ConsumerStatefulWidget {
 final Todo todo;

 const TodoStatusWidget(this.todo, {super.key});

 @override
 ConsumerState<TodoStatusWidget> createState() => _TodoStatusWidgetState();
}

class _TodoStatusWidgetState extends ConsumerState<TodoStatusWidget> {
 // initState, dispose 등 lifecycle 사용 가능
 // ref도 사용 가능

 @override
 Widget build(BuildContext context) {
 return Tap(
 onTap: () {
 ref.readTodoHolder.changeTodoStatus(widget.todo);
 },
 child: SizedBox(
 width: 50,
 height: 50,
 child: switch (widget.todo.status) {
 TodoStatus.complete => Checkbox(value: true, onChanged: null),
 TodoStatus.inComplete => const Checkbox(value: false, onChanged: null),
 TodoStatus.onGoing => _riveReady
 ? RiveWidget(controller: _controller!, fit: Fit.cover)
 : const SizedBox(),
 },
 ),
 );
 }
}

위젯 타입	BLoC 대응	언제 쓰나
`ConsumerWidget`	`StatelessWidget` + `BlocBuilder`	단순 UI
`ConsumerStatefulWidget`	`StatefulWidget` + `BlocBuilder`	lifecycle 필요

ProviderScope — 스코프 개념

Provider가 전역으로 선언되었다고 데이터도 전역으로 같이 쓰는 게 아니다. ProviderScope으로 나눠주면 별도의 데이터를 가지게 된다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 같은 Provider인데 Scope가 다르면 다른 데이터
ProviderScope(
 overrides: [todoDataProvider.overrideWith(() => TodoDataHolder())],
 child: ScreenA(), // 이 안에서는 독립된 TodoDataHolder
)

ProviderScope(
 overrides: [todoDataProvider.overrideWith(() => TodoDataHolder())],
 child: ScreenB(), // 여기도 독립된 TodoDataHolder
)

Ch04에서 다뤘던 Scoped Model의 진짜 실현이다. BLoC에서는 BlocProvider를 위젯 트리 특정 위치에 넣어서 스코프를 만들었는데, Riverpod은 ProviderScope의 overrides로 더 유연하게 스코프를 지정할 수 있다.

유튜브 앱에서 영상마다 다른 댓글 리스트를 보여줘야 한다면:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// BLoC: 각 화면에 BlocProvider를 별도로 감싸야 함
BlocProvider(
 create: (_) => CommentBloc(videoId: 'abc123'),
 child: CommentSection(),
)

// Riverpod: ProviderScope로 override
ProviderScope(
 overrides: [commentProvider.overrideWith(() => CommentNotifier(videoId: 'abc123'))],
 child: CommentSection(),
)

사실 결과적으로 비슷하지만, Riverpod은 Provider 선언이 전역이니까 어떤 Provider들이 있는지 한눈에 파악이 된다. BLoC은 각 화면의 BlocProvider를 찾아다녀야 한다.

FutureProvider — 비동기 상태의 끝판왕

Todo 앱에서는 안 썼지만, 실제 앱을 만들면 API 호출이 필수다. 여기서 Riverpod의 진가가 나온다.

기본 사용법

1
2
3
4


final userProvider = FutureProvider<User>((ref) async {
 final response = await http.get(Uri.parse('https://api.com/user'));
 return User.fromJson(jsonDecode(response.body));
});

이걸 뷰에서 쓰면:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


class UserPage extends ConsumerWidget {
 @override
 Widget build(BuildContext context, WidgetRef ref) {
 final userAsync = ref.watch(userProvider);

 return Scaffold(
 body: Center(
 child: userAsync.when(
 loading: () => CircularProgressIndicator(),
 error: (e, _) => Text('에러: $e'),
 data: (user) => Text(user.name),
 ),
 ),
 );
 }
}

.when 하나로 로딩/에러/데이터 분기가 끝난다. 세 가지 상태를 빠뜨릴 수가 없어서 안전하기도 하다. Swift에서 비슷하게 하려면:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// Swift - 직접 분기 처리
var body: some View {
 if isLoading {
 ProgressView()
 } else if let error {
 Text("에러: \(error)")
 } else if let user {
 Text(user.name)
 }
}

이걸 .when 하나로 끝내는 거다.

화면 일부만 분기하기

.when이 화면 전체를 교체하는 것만은 아니다. 부분에도 쓸 수 있다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Scaffold(
 appBar: AppBar(title: Text('마이페이지')), // 고정
 body: Column(
 children: [
 Text('항상 보이는 영역'), // 고정

 // 이 부분만 로딩/에러/데이터 처리
 ref.watch(userProvider).when(
 loading: () => CircularProgressIndicator(),
 error: (e, _) => Text('로드 실패'),
 data: (user) => UserCard(user: user),
 ),

 Text('여기도 항상 보임'), // 고정
 ],
 ),
)

프로필 페이지, 상품 목록, 검색 결과 같은 데서 엄청 자주 쓰는 패턴이다. loading이나 error 분기에도 커스텀 위젯을 자유롭게 넣을 수 있다:

1
2
3
4
5
6
7
8


ref.watch(userProvider).when(
 loading: () => ShimmerSkeleton(), // 스켈레톤 UI
 error: (e, _) => ErrorRetryWidget(
 message: '불러오기 실패',
 onRetry: () => ref.invalidate(userProvider), // 재시도
 ),
 data: (user) => UserProfileCard(user: user),
)

ref.listen — 오버레이 로딩

.when은 화면의 특정 영역을 교체하는 방식이다. 기존 화면 위에 오버레이로 로딩을 띄우고 싶다면 ref.listen을 쓴다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


class LoginPage extends ConsumerWidget {
 @override
 Widget build(BuildContext context, WidgetRef ref) {
 // 상태 변화를 '듣고' 오버레이 처리
 ref.listen(loginProvider, (prev, next) {
 if (next.isLoading) {
 showDialog(
 context: context,
 builder: (_) => Center(child: CircularProgressIndicator()),
 );
 } else {
 Navigator.of(context).pop(); // 로딩 닫기
 next.whenOrNull(
 error: (e, _) => ScaffoldMessenger.of(context)
 .showSnackBar(SnackBar(content: Text('실패: $e'))),
 data: (user) => Navigator.pushReplacement(...),
 );
 }
 });

 // 메인 UI는 그대로
 return Scaffold(
 body: Column(
 children: [
 TextField(...),
 ElevatedButton(
 onPressed: () => ref.read(loginProvider.notifier).login(),
 child: Text('로그인'),
 ),
 ],
 ),
 );
 }
}

상황	방식
화면 영역이 로딩/에러/데이터로 교체	`ref.watch` + `.when`
기존 화면 위에 오버레이 로딩	`ref.listen` + `showDialog`
데이터만 필요하고 로딩 무시	`.valueOrNull`

when은 화면 교체용, listen은 이벤트 반응용이다.

@riverpod — 코드 제너레이션

지금까지 StateNotifierProvider<TodoDataHolder, List<Todo>>((ref) => ...) 같은 긴 타입을 직접 썼는데, @riverpod을 쓰면 이 보일러플레이트도 자동 생성된다:

1
2
3
4
5
6
7
8
9


// @riverpod 방식: 함수 쓰듯이 로직만 짜면 끝
@riverpod
Future<User> user(ref) async {
 final response = await http.get(Uri.parse('https://api.com/user'));
 return User.fromJson(jsonDecode(response.body));
}

// build_runner 돌리면 userProvider가 자동 생성됨
// 뷰에서 ref.watch(userProvider).when(...) 으로 사용

알아야 하는 건 3개뿐이다:

@riverpod 붙이고 로직 짜기
build_runner 돌려서 코드 생성
뷰에서 ref.watch / ref.read로 사용

StateNotifierProvider<TodoNotifier, List<Todo>>((ref) => ...) 이런 보일러플레이트를 직접 안 짜도 된다. 요즘 새 프로젝트는 대부분 @riverpod 방식을 쓴다.

BLoC vs Riverpod 최종 비교

코드 비교

항목	BLoC	Riverpod
방식	Event → Bloc → State	직접 메서드 호출
이벤트 정의	`sealed class TodoEvent` + 하위 클래스 4개	없음
State 래퍼	`@freezed TodoBlocState` (BlocStatus 포함)	직접 `List<Todo>`
등록	`BlocProvider` (위젯 트리)	`StateNotifierProvider` (전역 선언)
UI 위젯	`BlocBuilder` 래퍼	`ConsumerWidget` 상속
상태 발행	`emit(state.copyWith(...))`	`state = newValue`
비동기 분기	직접 처리	`.when(loading, error, data)`
Event 추적	BlocObserver로 가능	직접 로깅 필요
보일러플레이트	많음	적음
스코프	BlocProvider 위치	ProviderScope overrides

같은 “Todo 삭제” 동작

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


// BLoC: Event 정의 → 핸들러 등록 → Event dispatch
// 1. Event 정의
class TodoRemoveEvent extends TodoEvent {
 final Todo removedTodo;
 TodoRemoveEvent(this.removedTodo);
}

// 2. 핸들러 등록
on<TodoRemoveEvent>(_removeTodo);

// 3. 핸들러 구현
void _removeTodo(TodoRemoveEvent event, Emitter<TodoBlocState> emit) {
 final oldTodoList = List<Todo>.from(state.todoList);
 oldTodoList.removeWhere((e) => e.id == event.removedTodo.id);
 emit(state.copyWith(todoList: oldTodoList));
}

// 4. UI에서 dispatch
context.readTodoBloc.add(TodoRemoveEvent(todo));


// Riverpod: 메서드 하나
// 1. 메서드 구현
void removeTodo(Todo todo) {
 state.remove(todo);
 state = List.of(state);
}

// 2. UI에서 호출
ref.readTodoHolder.removeTodo(todo);

BLoC은 4단계, Riverpod은 2단계. 추적성 vs 생산성의 트레이드오프다.

언제 뭘 쓸까

상황	추천
대규모 팀 (10명+)	BLoC — Event 히스토리 추적, 팀 컨벤션 강제
소규모 팀 / 개인	Riverpod — 생산성, 적은 보일러플레이트
API 호출 많은 앱	Riverpod — `.when` 패턴이 압도적
Event 로깅 필수	BLoC — BlocObserver
프로토타입	Riverpod (또는 GetX)

2026년 기준으로 새 프로젝트는 대부분 Riverpod이 기본 선택이고, BLoC은 대규모 엔터프라이즈에서 쓰이는 추세다.

4가지 방식 총 비교

Ch05 전체를 통해 같은 Todo 앱을 4가지 방식으로 만들어봤다:

	ValueNotifier	GetX	BLoC	Riverpod
방식	Scoped (내장)	Static	Scoped	Scoped
상태 변경	`notifyListeners()`	`.obs` 자동	`emit()`	`state =` 재할당
UI 구독	`ValueListenableBuilder`	`Obx`	`BlocBuilder`	`ref.watch`
비동기 분기	직접 처리	직접 처리	직접 처리	`.when` 자동
보일러플레이트	중간	적음	많음	적음
추적성	낮음	낮음	높음	중간
메모리 관리	자동	수동	자동	자동

내가 느낀 점

BLoC의 Event 기반 구조가 사실상 Scope 역할을 하는 거라고 느꼈다. 어떤 이벤트가 어떤 상태를 바꾸는지 명확히 분리되니까. 근데 Riverpod은 Provider 단위로 관심사를 나누면서도 코드량이 훨씬 적다.

1
2
3
4


// 관심사 분리: Provider 단위로 나누면 됨
final todoDataProvider = StateNotifierProvider<TodoDataHolder, List<Todo>>(...);
final userProvider = FutureProvider<User>(...);
final settingsProvider = StateNotifierProvider<SettingsNotifier, Settings>(...);

젤 좋은 건 뷰에서 상태별 화면 분기가 .when 하나로 되는 점이다. 로딩/에러/데이터를 빠뜨릴 수 없게 강제하니까 안전하고, 각 분기에 아무 위젯이나 넣을 수 있으니까 커스텀도 자유롭다.

앱이 커져서 상태가 많아지면 Provider를 나누면 되고, Scope가 필요하면 ProviderScope의 overrides로 해결된다. 개인 프로젝트에서 쓴다면 Riverpod이 정답인 것 같다.

Riverpod 3.0 — 2025년 9월 기준 변경점

이 글에서 쓴 코드는 Riverpod 2.x 기반이다. 2025년 9월에 Riverpod 3.0이 나왔는데, 핵심 개념(ref.watch, ref.read, .when, ProviderScope)은 그대로고 보일러플레이트가 더 줄었다.

	Riverpod 2.x (이 글)	Riverpod 3.0
Provider 선언	`StateNotifierProvider<T, S>((ref) => ...)` 직접 작성	`@riverpod` 붙이면 자동 생성
상태 클래스	`StateNotifier<T>`	`Notifier<T>` (`StateNotifier` deprecated)
비동기	`FutureProvider` 별도 선언	`@riverpod Future<T>` 함수로 통일
Mutation	없음	`@mutation`으로 폼 제출/버튼 액션의 로딩/에러 자동 관리 (experimental)
AsyncValue	일반 클래스	`sealed class` — 패턴 매칭 시 빠뜨리면 컴파일 에러

3.0에서 가장 큰 변화는 StateNotifier가 Notifier로 대체된 것과, @riverpod 코드 제너레이션이 기본이 된 것이다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


// 2.x: 직접 선언
final todoDataProvider = StateNotifierProvider<TodoDataHolder, List<Todo>>(
 (ref) => TodoDataHolder());

class TodoDataHolder extends StateNotifier<List<Todo>> {
 TodoDataHolder() : super([]);
 // ...
}

// 3.0: @riverpod + Notifier
@riverpod
class TodoDataHolder extends _$TodoDataHolder {
 @override
 List<Todo> build() => []; // 초기 상태

 void addTodo(Todo todo) {
 state = [...state, todo];
 }
}
// build_runner가 todoDataHolderProvider 자동 생성

Mutation API는 아직 experimental이라 API가 바뀔 수 있지만, 폼 제출 같은 액션의 로딩/성공/에러 상태를 자동으로 관리해주는 기능이다. 정식 출시되면 ref.listen으로 수동 처리하던 부분이 더 간결해질 예정이다.

Ch05-3. Todo 앱 BLoC + freezed 전환 - 이벤트 기반 상태관리

Fri, 01 May 2026 00:00:00 +0900

Ch05 시리즈 세 번째다. GetX에서 BLoC으로 전환한다. 핵심 변화는 2가지다: (1) 상태 변경을 Event로 제한하고, (2) Todo 모델을 freezed로 immutable하게 바꾸는 것. 코드량은 늘어나지만 “상태가 어디서 왜 바뀌었는지” 추적이 확실해진다.

BLoC이란

Business Logic Component. UI에서 Event를 보내면, Bloc이 처리해서 새로운 State를 내보내는 단방향 흐름이다.

1
2
3


[UI] --Event--> [Bloc] --State--> [UI]
 |
 비즈니스 로직

GetX에서는 todoData.addTodo(todo) 처럼 직접 메서드를 호출했다. BLoC에서는 bloc.add(TodoAddEvent()) 처럼 이벤트를 보낸다. 뷰에서는 호출만 하고, Bloc 내부에서 이벤트를 받아 해당하는 로직을 수행하고, 상태를 변경하면, BlocBuilder가 돌아간다.

차이가 뭐냐: 모든 상태 변경이 Event로 기록된다. 어떤 이벤트가 언제 발생했는지 로그로 추적할 수 있고, 디버깅이 쉬워진다. GetX는 “야 이거 바꿔"라고 직접 수정하는 거고, BLoC은 “이거 바꿔달라"는 요청서를 제출하는 거다.

Swift에서 TCA(The Composable Architecture)를 써봤다면 Action → Reducer → State 흐름과 거의 같은 패턴이다.

freezed로 불변 모델 만들기

mutable의 문제 (Ch05-2 복습)

GetX에서 Todo의 상태를 바꿀 때 이런 식이었다:

1
2
3


// GetX 시절: mutable 객체를 직접 수정
todo.status = TodoStatus.complete;
todoList.refresh(); // 수동 refresh 필요

문제점:

어디서 todo.status를 바꿨는지 추적 불가
refresh() 까먹으면 UI 안 바뀜
같은 Todo 인스턴스를 여러 곳에서 참조하면 의도치 않은 사이드 이펙트

freezed 적용

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


@freezed
class Todo with _$Todo {
 const factory Todo({
 required int id,
 required String title,
 required DateTime createdTime,
 DateTime? modifyTime,
 required DateTime dueDate,
 required TodoStatus status,
 }) = _Todo;
}

const factory로 선언하면 모든 필드가 final이 된다. 직접 수정이 불가능하다. 대신 copyWith로 새 인스턴스를 만들어야 한다.

1
2
3
4
5


// Before (mutable class)
todo.status = TodoStatus.complete; // 직접 수정

// After (freezed)
final newTodo = todo.copyWith(status: TodoStatus.complete); // 새 인스턴스 생성

Swift의 struct(value type)와 거의 같다. Swift에서는 struct가 기본 제공하는 ==, hashCode, copyWith(없지만 멤버와이즈 이니셜라이저가 비슷한 역할)를 Dart에서는 freezed가 코드 생성으로 만들어준다.

처음에는 좀 번거로웠다. 기존처럼 switch문으로 상태를 변경하고 할당시켜도 안 됐다. 내부에서 상태를 수정할 수 없으니까 copyWith로 별도 수정해줘야 한다. 근데 이 불편함이 안전함의 대가다.

BlocState도 freezed로

1
2
3
4
5
6
7
8
9


enum BlocStatus { initial, loading, success, error }

@freezed
class TodoBlocState with _$TodoBlocState {
 const factory TodoBlocState({
 required BlocStatus status,
 required List<Todo> todoList,
 }) = _TodoBlocState;
}

State에 BlocStatus를 포함시켜서 로딩/에러 상태도 관리할 수 있다. todoList와 status를 하나의 immutable State 객체로 묶었다.

build_runner로 코드 생성

1

flutter pub run build_runner build

이 명령어로 vo_todo.freezed.dart, todo_bloc_state.freezed.dart가 생성된다. copyWith, ==, hashCode, toString이 전부 자동으로 만들어진다.

Event 설계 — sealed class

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


sealed class TodoEvent {}

class TodoAddEvent extends TodoEvent {}

class TodoStatusUpdateEvent extends TodoEvent {
 final Todo updatedTodo;
 TodoStatusUpdateEvent(this.updatedTodo);
}

class TodoContentUpdateEvent extends TodoEvent {
 final Todo updatedTodo;
 TodoContentUpdateEvent(this.updatedTodo);
}

class TodoRemoveEvent extends TodoEvent {
 final Todo removedTodo;
 TodoRemoveEvent(this.removedTodo);
}

처음에는 abstract class로 했다가 sealed class로 바꿨다. sealed로 바꾸면 switch문에서 모든 이벤트를 빠짐없이 처리했는지 컴파일 타임에 체크해준다. 이벤트를 하나 추가했는데 핸들러를 안 만들면 컴파일 에러가 나니까 실수를 방지할 수 있다.

Swift의 enum + associated values와 거의 같은 역할이다:

1
2
3
4
5
6
7


// Swift equivalent
enum TodoAction {
 case add
 case updateStatus(Todo)
 case updateContent(Todo)
 case remove(Todo)
}

이벤트를 sealed class로 만드는 이유는 각 이벤트가 서로 다른 데이터를 가져야 할 때 유연하기 때문이다. TodoAddEvent는 데이터가 필요 없고(다이얼로그에서 받으니까), TodoRemoveEvent는 어떤 Todo를 삭제할지 알아야 하고, 이런 차이를 타입으로 표현할 수 있다.

TodoBloc — 핵심 로직

Bloc 클래스 구조

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


class TodoBloc extends Bloc<TodoEvent, TodoBlocState> {
 TodoBloc() : super(const TodoBlocState(
 status: BlocStatus.initial,
 todoList: <Todo>[],
 )) {
 on<TodoAddEvent>(_addTodo);
 on<TodoStatusUpdateEvent>(_changeTodoStatus);
 on<TodoContentUpdateEvent>(_editTodo);
 on<TodoRemoveEvent>(_removeTodo);
 }
}

super(initialState)로 초기 상태를 설정하고, on<EventType>(handler)로 각 이벤트별 핸들러를 등록한다. 이벤트가 들어오면 해당 핸들러가 실행되는 구조다.

추가

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


void _addTodo(TodoAddEvent event, Emitter<TodoBlocState> emit) async {
 final result = await WriteTodoDialog().show();
 if (result != null) {
 final oldTodoList = List.of(state.todoList);
 oldTodoList.add(
 Todo(
 id: DateTime.now().microsecondsSinceEpoch,
 title: result.text,
 dueDate: result.dateTime,
 createdTime: DateTime.now(),
 status: TodoStatus.inComplete,
 ),
 );
 emitNewList(oldTodoList, emit);
 }
}

핵심 패턴: List.of(state.todoList)로 기존 리스트를 복사 → 수정 → emit으로 새 State를 발행한다. BLoC에서는 add를 사용할 수 없기 때문에(state.todoList가 immutable) 새 List로 감싸서 조작해야 한다.

1
2
3


void emitNewList(List<Todo> oldTodoList, Emitter<TodoBlocState> emit) {
 emit(state.copyWith(todoList: oldTodoList));
}

emit을 호출하면 BLoC이 새 State를 내보내고, 구독 중인 BlocBuilder가 리빌드된다.

상태 전환 (가장 복잡한 부분)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


void _changeTodoStatus(TodoStatusUpdateEvent event, Emitter<TodoBlocState> emit) async {
 final oldTodoList = List.of(state.todoList);
 final todo = event.updatedTodo;
 final todoIndex = oldTodoList.indexWhere((e) => e.id == todo.id);

 TodoStatus status = todo.status;
 switch (todo.status) {
 case TodoStatus.inComplete:
 status = TodoStatus.onGoing;
 case TodoStatus.onGoing:
 status = TodoStatus.complete;
 case TodoStatus.complete:
 final result = await ConfirmDialog('정말로 처음 상태로 변경하시겠어요?').show();
 result?.runIfSuccess((data) {
 status = TodoStatus.inComplete;
 });
 }
 oldTodoList[todoIndex] = todo.copyWith(status: status);
 emitNewList(oldTodoList, emit);
}

GetX에서는 todo.status = status로 직접 수정했는데, BLoC에서는 todo.copyWith(status: status)로 새 인스턴스를 만들고, indexWhere로 찾아서 교체한다. immutable이라 기존 객체를 수정할 수 없으니까 새 객체로 대체하는 거다.

GetX에서 todoList.refresh()를 수동으로 호출해야 했던 문제가 여기서 사라진다. 새 리스트를 emit하면 BLoC이 자동으로 상태 변경을 감지한다.

삭제

1
2
3
4
5
6


void _removeTodo(TodoRemoveEvent event, Emitter<TodoBlocState> emit) {
 final oldTodoList = List<Todo>.from(state.todoList);
 final todo = event.removedTodo;
 oldTodoList.removeWhere((e) => e.id == todo.id);
 emitNewList(oldTodoList, emit);
}

수정

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


void _editTodo(TodoContentUpdateEvent event, Emitter<TodoBlocState> emit) async {
 final todo = event.updatedTodo;
 final result = await WriteTodoDialog(todoForEdit: todo).show();
 if (result != null) {
 final oldTodoList = List<Todo>.from(state.todoList);
 oldTodoList[oldTodoList.indexOf(todo)] = todo.copyWith(
 title: result.text,
 dueDate: result.dateTime,
 modifyTime: DateTime.now(),
 );
 emitNewList(oldTodoList, emit);
 }
}

UI에서 BLoC 사용

BlocProvider로 등록

1
2
3
4
5
6
7


// app.dart
BlocProvider(
 create: (BuildContext context) => TodoBloc(),
 child: MaterialApp(
 home: const MainScreen(),
 ),
)

InheritedWidget을 직접 만들 필요 없이 BlocProvider가 대신해준다. 내부적으로 InheritedWidget 기반이지만 보일러플레이트가 없다. GetX의 Get.put()과 비교하면, BlocProvider는 위젯이 dispose될 때 자동으로 Bloc도 close해준다. 메모리 관리를 신경 쓸 필요가 없다.

BlocBuilder로 구독

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// w_todo_list.dart
BlocBuilder<TodoBloc, TodoBlocState>(
 builder: (context, state) {
 return state.todoList.isEmpty
 ? const Center(child: Text('할 일을 작성해 보세요.'))
 : Column(
 children: state.todoList.map((e) => TodoItem(e)).toList(),
 );
 },
)

state로 현재 상태 전체를 받는다. GetX의 Obx처럼 .obs 변수를 직접 접근하는 게 아니라, Bloc이 emit한 State 객체를 통해 데이터에 접근한다.

context.read vs context.watch

1
2
3
4
5


// context_extension.dart
extension ContextExtension on BuildContext {
 TodoBloc get readTodoBloc => read(); // 이벤트 보낼 때 (리빌드 안 함)
 TodoBloc get watchTodoBloc => watch(); // 상태 구독할 때 (리빌드 함)
}

read: 한 번 읽고 끝. 이벤트를 보낼 때 사용한다. 리빌드를 트리거하지 않는다.
watch: 상태 변경을 구독한다. State가 바뀌면 해당 위젯이 리빌드된다.

1
2
3
4
5
6


// 이벤트 보내기: read (리빌드 불필요)
context.readTodoBloc.add(TodoAddEvent());
context.readTodoBloc.add(TodoRemoveEvent(todo));
context.readTodoBloc.add(TodoStatusUpdateEvent(todo));

// 상태 구독: BlocBuilder 안에서 자동으로 처리

주로 이벤트를 보낼 때는 read, UI를 그릴 때는 BlocBuilder 안에서 state를 받아 쓴다.

실제 위젯에서 사용

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// w_todo_item.dart - 스와이프 삭제
Dismissible(
 key: ValueKey(todo.id),
 onDismissed: (direction) {
 context.readTodoBloc.add(TodoRemoveEvent(todo));
 },
 child: RoundedContainer(
 child: Row(
 children: [
 TodoStatusWidget(todo),
 Text(todo.title),
 const Spacer(),
 IconButton(
 onPressed: () {
 context.readTodoBloc.add(TodoContentUpdateEvent(todo));
 },
 icon: const Icon(EvaIcons.editOutline),
 )
 ],
 ),
 ),
)

1
2
3
4
5
6
7


// s_main.dart - FAB으로 추가
FloatingActionButton(
 onPressed: () {
 context.readTodoBloc.add(TodoAddEvent());
 },
 child: const Icon(EvaIcons.plus),
)

UI에서는 add(Event)로 이벤트를 보내기만 한다. 로직은 전부 Bloc 내부에 있다. 이게 관심사 분리다.

Rive 애니메이션 (보너스)

상태관리와 직접 관련은 없지만, Todo 상태가 onGoing일 때 Rive 애니메이션이 재생되는 게 꽤 재밌었다.

1
2
3
4
5
6
7


child: switch (widget.todo.status) {
 TodoStatus.complete => Checkbox(value: true, onChanged: null),
 TodoStatus.inComplete => const Checkbox(value: false, onChanged: null),
 TodoStatus.onGoing => _riveReady
 ? RiveWidget(controller: _controller!, fit: Fit.cover)
 : const SizedBox(),
}

Dart 3의 switch expression으로 상태별 위젯을 깔끔하게 분기한다. _cachedFile을 static으로 캐싱해서 .riv 파일을 한 번만 로드하는 것도 포인트다.

3가지 방식 최종 비교

코드 비교

항목	ValueNotifier	GetX	BLoC
방식	Scoped (내장)	Static	Scoped (패키지)
상태 객체	mutable	mutable	immutable (freezed)
변경 알림	`notifyListeners()` 수동	`.obs` 자동	`emit()`
UI 구독	`ValueListenableBuilder`	`Obx(() =>)`	`BlocBuilder`
등록	InheritedWidget 직접 구현	`Get.put()`	`BlocProvider`
접근	`of(context)`	`Get.find()`	`context.read/watch`
상태 변경	메서드 직접 호출	메서드 직접 호출	Event dispatch
추적성	낮음	낮음	높음 (Event 로깅)
보일러플레이트	중간	적음	많음
메모리 관리	위젯 트리 자동	개발자 직접	위젯 트리 자동

같은 “Todo 추가” 동작

1
2
3
4
5
6
7
8


// ValueNotifier
context.todoHolder.addTodo(todo);

// GetX
Get.find<TodoDataHolder>().addTodo(todo);

// BLoC
context.readTodoBloc.add(TodoAddEvent());

Swift/iOS 대응표

Flutter	Swift/iOS
ValueNotifier	`ObservableObject` + `@Published`
InheritedWidget	`@EnvironmentObject`
GetX (`.obs` + `Obx`)	`Combine` + `@Published` (싱글톤)
BLoC (Event → State)	TCA (`Action` → `Reducer` → `State`)
freezed	`struct` (value type)
sealed class	`enum` + associated value
BlocProvider	DI Container (Scoped)

어떤 걸 써야 하나

프로토타입/작은 앱 → GetX가 빠르다
중간 규모 → Provider나 Riverpod이 적당하다
대규모/팀 프로젝트 → BLoC이 Event 추적, 테스트 용이성에서 유리하다
Flutter 원리 학습 → ValueNotifier + InheritedWidget부터 이해하자

개인 프로젝트에서 정답은 없다. 트레이드오프를 이해하고 고르면 된다.

정리

Ch05 시리즈를 통해 같은 Todo 앱을 3가지 방식으로 만들어봤다. 어떤 방식이든 하는 일은 같다. 상태를 만들고, 변경하고, UI에 반영하는 것. 차이는 “변경을 얼마나 통제할 것인가”, “추적성을 얼마나 확보할 것인가"에 있다.

iOS 개발할 때도 RxSwift → Combine → TCA 순서로 더 구조화된 방향으로 흘러왔는데, Flutter에서도 비슷한 흐름을 체감했다. Ch04에서 이론을 정리하고 Ch05에서 실전을 해보니까 왜 상태관리가 중요한지 확실히 느꼈다.

Ch05-2. Todo 앱 GetX로 전환 - .obs와 Obx의 마법

Thu, 30 Apr 2026 00:00:00 +0900

Ch05-1에서 ValueNotifier + InheritedWidget으로 만든 Todo 앱을 GetX로 전환한다. Ch04에서 다뤘던 Static Model의 실전 적용 버전이다. 결론부터 말하면, 일일이 업데이트 걸어줄 필요 없이 심플하게 상태관리가 가능해진다. 근데 그 대가가 있다.

뭐가 바뀌나

바꾸는 곳은 정해져 있다. 상태 클래스, 등록, 구독, 접근. 이 4가지만 바꾸면 된다.

영역	Before (ValueNotifier)	After (GetX)
상태 클래스	`ValueNotifier` 상속	`GetxController` 상속
상태 변수	`List<Todo>` + `notifyListeners()`	`RxList<Todo>` (`.obs`)
UI 구독	`ValueListenableBuilder`	`Obx(() =>)`
등록	`InheritedWidget` 직접 구현	`Get.put()`
접근	`context.dependOn...`	`Get.find()`

.obs — 자동 변경 감지

변환 핵심

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// Before: ValueNotifier
class TodoDataNotifier extends ValueNotifier<List<Todo>> {
 TodoDataNotifier() : super([]);

 void addTodo(Todo todo) {
 value.add(todo);
 notifyListeners(); // 수동 호출 필수!
 }
}

// After: GetX
class TodoDataHolder extends GetxController {
 final RxList<Todo> todoList = <Todo>[].obs;

 void addTodo(Todo todo) {
 todoList.add(todo);
 // notifyListeners 불필요! .obs가 변경을 자동 감지
 }
}

핵심 차이는 .obs다. .obs를 붙이면 Rx<T> 타입으로 래핑되면서, add, remove, []= 같은 List 조작을 전부 intercept한다. 변경이 생기면 자동으로 구독자에게 알림을 보내기 때문에 ValueNotifier에서 notifyListeners() 까먹어서 UI가 안 바뀌는 버그가 사라진다.

다양한 타입에 .obs

1
2
3
4


final count = 0.obs; // RxInt
final name = ''.obs; // RxString
final items = <Todo>[].obs; // RxList<Todo>
final user = User().obs; // Rx<User>

기본 타입은 .value로 접근하고, List는 직접 메서드를 호출할 수 있다. Swift에서 @Published가 프로퍼티 단위로 감시하는 것과 비슷한데, .obs는 변수 단위로 감시한다.

같은 값이면 리빌드 안 함

1
2
3


final count = 0.obs;
count.value = 0; // 같은 값 → Obx 리빌드 안 함
count.value = 1; // 다른 값 → Obx 리빌드

ValueNotifier의 notifyListeners()는 값이 같아도 무조건 알림을 보내는데, GetX는 내부적으로 이전 값과 비교해서 불필요한 리빌드를 막아준다.

Obx — 반응형 UI 빌더

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// Before: ValueListenableBuilder
ValueListenableBuilder<List<Todo>>(
 valueListenable: todoNotifier,
 builder: (context, todoList, child) {
 return Column(
 children: todoList.map((e) => TodoItem(e)).toList(),
 );
 },
)

// After: Obx
Obx(() => Column(
 children: todoDataHolder.todoList.map((e) => TodoItem(e)).toList(),
))

Obx가 내부에서 어떤 .obs 변수를 읽었는지 자동으로 추적한다. 해당 변수가 바뀌면 Obx 블록만 리빌드된다. SwiftUI에서 @Published 프로퍼티가 바뀌면 body가 리빌드되는 것과 같은 원리인데, Obx 단위로 범위를 좁힐 수 있어서 더 세밀한 제어가 가능하다.

코드량으로만 보면 ValueListenableBuilder 대비 거의 반으로 줄었다. builder 패턴의 보일러플레이트가 사라진 게 크다.

InheritedWidget 제거 — Get.put / Get.find

등록

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// Before: InheritedWidget으로 위젯 트리 감싸기
TodoDataHolder(
 notifier: TodoDataNotifier(),
 child: MaterialApp(
 home: const MainScreen(),
 ),
)

// After: Get.put 한 줄
@override
void initState() {
 super.initState();
 Get.put(TodoDataHolder());
}

InheritedWidget 클래스를 만들고, 위젯 트리에 감싸고, of(context) 패턴을 구현하는 보일러플레이트가 전부 사라진다. Get.put() 한 줄이면 끝이다.

접근

1
2
3
4
5


// Before: context 필요
context.todoHolder.addTodo(todo);

// After: context 불필요
Get.find<TodoDataHolder>().addTodo(todo);

Get.find()로 어디서든 접근할 수 있다. context가 필요 없으니까 StatelessWidget이든, 일반 클래스든, 어디서든 상태에 접근 가능하다.

mixin으로 더 축약할 수도 있다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


mixin TodoDataProvider {
 TodoDataHolder get todoData => Get.find<TodoDataHolder>();
}

// 사용
class SomeWidget extends StatelessWidget with TodoDataProvider {
 @override
 Widget build(BuildContext context) {
 todoData.addTodo(todo); // 깔끔
 }
}

상태 변경 로직 — mutable의 함정

추가, 삭제

1
2
3
4
5
6
7
8
9


void addTodo(Todo todo) {
 todoList.add(todo);
 // 끝. RxList가 자동으로 감지한다.
}

void removeTodo(Todo todo) {
 todoList.remove(todo);
 // 역시 자동.
}

List의 add, remove는 RxList가 감지해서 자동으로 UI가 갱신된다.

상태 전환 — refresh()가 필요한 순간

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


void changeTodoStatus(Todo todo) async {
 switch (todo.status) {
 case TodoStatus.inComplete:
 todo.status = TodoStatus.onGoing;
 case TodoStatus.onGoing:
 todo.status = TodoStatus.complete;
 case TodoStatus.complete:
 final result = await ConfirmDialog('정말로 처음 상태로 변경하시겠어요?').show();
 result?.runIfSuccess((data) {
 todo.status = TodoStatus.inComplete;
 });
 }
 todoList.refresh(); // 이거 없으면 UI 안 바뀜!
}

여기서 함정이 하나 있다. todo.status를 직접 바꾸면 Todo 객체의 프로퍼티만 변경되고, List 자체는 변경이 없다. RxList 입장에서는 “List에 아무 변화 없는데?“라고 판단하기 때문에 refresh()를 수동으로 호출해야 한다.

mutable 객체를 직접 수정할 때 생기는 문제다. ValueNotifier에서 notifyListeners()를 수동으로 호출해야 했던 것과 본질적으로 같은 문제가 형태만 바뀌어서 다시 등장한 거다.

수정도 마찬가지

1
2
3
4
5
6


void editTodo(Todo todo, WriteTodoResult result) {
 todo.title = result.text;
 todo.dueDate = result.dateTime;
 todo.modifyTime = DateTime.now();
 todoList.refresh(); // 수동 refresh
}

GetX의 편리함과 위험성

코드량 비교

항목	ValueNotifier + InheritedWidget	GetX
상태 클래스	ValueNotifier 상속 + InheritedWidget 별도 클래스	GetxController 하나
등록	InheritedWidget 래퍼로 위젯 트리 감싸기	`Get.put()` 한 줄
구독	`ValueListenableBuilder` (builder 패턴)	`Obx(() =>)`
변경 알림	`notifyListeners()` 수동	`.obs` 자동
접근	`context.dependOnInheritedWidgetOfExactType`	`Get.find()`

확실히 코드량은 GetX가 압도적으로 적다.

근데 왜 GetX를 안 쓰는 프로젝트가 있을까?

Ch04에서 다뤘던 Static Model의 위험성이 그대로 적용된다:

Get.find()로 어디서든 접근/수정 가능 → 상태 변경 추적이 어려움
메모리 관리를 개발자가 직접 → Get.delete() 안 하면 메모리 누수
mutable 상태 + 전역 접근 → 디버깅 지옥이 될 수 있음

iOS 개발할 때 싱글톤 패턴의 교훈과 정확히 같다. AppState.shared.user = newUser를 아무 데서나 부르면 어디서 바뀌었는지 추적이 안 되는 것처럼, GetX의 Get.find()도 어디서든 상태를 수정할 수 있기 때문에 같은 문제가 생긴다.

Swift 커뮤니티가 싱글톤에서 DI(의존성 주입)로 이동한 것처럼, Flutter 커뮤니티에서도 GetX에서 Scoped 방식(Provider, BLoC, Riverpod)으로 이동하는 추세가 있다. 물론 작은 앱이나 프로토타이핑에는 GetX가 여전히 최고의 선택이다.

정리

개념	ValueNotifier	GetX
방식	Scoped (내장)	Static (패키지)
변경 알림	`notifyListeners()` 수동	`.obs` 자동
UI 구독	`ValueListenableBuilder`	`Obx(() =>)`
등록/접근	InheritedWidget / `of(context)`	`Get.put()` / `Get.find()`
context 필요	필요	불필요
메모리 관리	위젯 트리가 자동 해제	개발자가 직접 `Get.delete()`

GetX는 확실히 편하다. notifyListeners() 안 불러도 되고, InheritedWidget 만들 필요도 없다. 근데 mutable 객체의 refresh() 함정이 있고, 앱이 커지면 상태 추적이 힘들어진다. 다음 Ch05-3에서는 BLoC으로 전환한다. Event-driven 구조가 이 추적 문제를 어떻게 해결하는지, 그리고 mutable Todo를 freezed로 immutable하게 만들면 refresh() 같은 함정이 어떻게 사라지는지 비교해보자.

Ch05-1. Todo 앱으로 상태관리 입문 - ValueNotifier + InheritedWidget

Wed, 29 Apr 2026 00:00:00 +0900

Ch04에서 상태관리의 역사와 Scoped vs Static을 다뤘으니, 이제 실전이다. Todo 앱 하나를 만들고, 같은 앱을 3가지 상태관리 방식으로 리팩토링하는 시리즈다. 첫 번째는 Flutter 내장 도구만 쓴다. 외부 패키지 없이 원리부터 이해하는 게 목적이다.

Todo 앱 구조

먼저 전체 프로젝트 구조를 보자.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


lib/
├── app.dart // 앱 진입점
├── data/
│ └── memory/
│ ├── vo_todo.dart // Todo 모델
│ ├── todo_status.dart // 상태 enum
│ ├── todo_data_notifier.dart // ValueNotifier
│ └── todo_data_holder.dart // InheritedWidget
├── screen/
│ └── main/
│ ├── s_main.dart // 메인 화면 (탭 네비게이션)
│ ├── todo/
│ │ ├── f_todo.dart // Todo 탭 전체
│ │ ├── w_todo_list.dart // 리스트 위젯
│ │ ├── w_todo_item.dart // 개별 아이템
│ │ └── w_todo_status.dart // 상태 표시 (Rive 애니메이션)
│ └── write/
│ ├── d_write_todo.dart // 추가/수정 다이얼로그
│ └── vo_write_result.dart

파일 이름에 접두어가 붙는다. s_는 screen, f_는 fragment, w_는 widget, d_는 dialog, vo_는 value object. iOS에서 ViewController, ViewModel 같은 네이밍 컨벤션과 비슷한 느낌이다.

Todo 모델

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


class Todo {
 int id;
 String title;
 final DateTime createdTime;
 DateTime? modifyTime;
 DateTime dueDate;
 TodoStatus status;

 Todo({
 required this.id,
 required this.title,
 required this.dueDate,
 this.status = TodoStatus.inComplete,
 }) : createdTime = DateTime.now();
}

그냥 평범한 mutable class다. id, title, dueDate, status를 가지고 있고, 직접 프로퍼티를 수정할 수 있다. Swift로 치면 class(reference type)에 var 프로퍼티들을 쓴 거다. 나중에 Ch05-3에서 이걸 freezed로 immutable하게 바꾸면 뭐가 달라지는지 비교할 예정이다.

1
2
3
4
5


enum TodoStatus {
 inComplete,
 onGoing,
 complete,
}

상태 흐름은 inComplete → onGoing → complete 순서다. complete에서 한 번 더 누르면 확인 다이얼로그가 뜨고, 승인하면 다시 inComplete로 돌아간다.

UI 위젯들

UI는 간단하게 넘어가자. 핵심만 보면:

MainScreen: 하단 탭 네비게이션 + FloatingActionButton으로 할 일 추가
TodoItem: Dismissible 위젯으로 스와이프 삭제 지원. SwiftUI의 .swipeActions와 같은 역할인데, Flutter는 위젯 자체가 스와이프를 지원해서 편하다
TodoStatusWidget: 상태에 따라 체크박스 표시. onGoing일 때는 Rive 애니메이션이 재생된다
WriteTodoDialog: 할 일 추가/수정 다이얼로그. todoForEdit이 있으면 수정 모드, 없으면 추가 모드

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


// TodoItem에서 스와이프 삭제
Dismissible(
 key: ValueKey(todo.id),
 onDismissed: (direction) {
 // 여기서 삭제 로직 호출
 },
 child: RoundedContainer(
 child: Column(
 children: [
 Text(todo.dueDate.toString()),
 Row(
 children: [
 TodoStatusWidget(todo),
 Text(todo.title),
 const Spacer(),
 IconButton(
 onPressed: () {
 // 수정 로직 호출
 },
 icon: const Icon(EvaIcons.editOutline),
 )
 ],
 ),
 ],
 ),
 ),
)

ValueNotifier — setState의 진화

setState의 한계

setState는 해당 위젯 내부에서만 작동한다. 부모에서 만든 todoList를 여러 자식 위젯이 공유해야 할 때, 콜백으로 내려보내거나 prop drilling을 해야 한다. SwiftUI에서 @Binding을 n단계 내려보내는 고통과 같다.

ValueNotifier란

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


class TodoDataNotifier extends ValueNotifier<List<Todo>> {
 TodoDataNotifier() : super([]); // 최초 빈 리스트로 시작

 void addTodo(Todo todo) {
 value.add(todo);
 notifyListeners();
 }

 void notify() {
 notifyListeners();
 }
}

ValueNotifier<T>는 Flutter 내장 클래스다. value가 바뀌면 notifyListeners()를 호출해서 구독 중인 위젯을 리빌드시킨다.

Swift랑 비교하면:

Flutter	SwiftUI
`ValueNotifier<T>`	`ObservableObject` + `@Published`
`notifyListeners()`	`objectWillChange.send()` (수동)
`value`	`@Published var value: T`

핵심 차이는, Swift의 @Published는 값이 바뀌면 자동으로 알림을 보내는데, Flutter의 ValueNotifier에서는 List 내부를 수정하면(value.add()) 참조 자체는 안 바뀌니까 수동으로 notifyListeners()를 호출해야 한다. 이걸 까먹으면 UI가 안 바뀌는 버그가 생긴다.

ValueListenableBuilder로 UI 연결

1
2
3
4
5
6
7
8


ValueListenableBuilder<List<Todo>>(
 valueListenable: todoNotifier,
 builder: (context, todoList, child) {
 return Column(
 children: todoList.map((e) => TodoItem(e)).toList(),
 );
 },
)

SwiftUI에서 @ObservedObject를 쓰면 body가 자동 리빌드되는 것과 같은 역할이다. builder 안에서 todoList가 바뀔 때마다 UI가 다시 그려진다. child 파라미터는 리빌드할 필요 없는 자식을 캐싱하는 용도인데, 이건 성능 최적화 포인트다.

InheritedWidget — 위젯 트리로 데이터 전파

왜 필요한가

ValueNotifier만으로는 “누가 이 Notifier를 들고 있느냐"가 문제다. 생성자로 내려보내면 결국 prop drilling이 다시 발생한다. InheritedWidget은 위젯 트리에 데이터를 심어두고, 하위 어디서든 꺼내 쓸 수 있게 해주는 메커니즘이다.

사실 이 프로젝트에서 이미 다크모드 테마 시스템으로 InheritedWidget을 쓰고 있었다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// 이미 있던 테마용 InheritedWidget
class CustomThemeHolder extends InheritedWidget {
 final AbstractThemeColors appColors;
 final CustomTheme theme;
 final Function(CustomTheme) changeTheme;

 static CustomThemeHolder of(BuildContext context) {
 return context.dependOnInheritedWidgetOfExactType<CustomThemeHolder>()!;
 }

 @override
 bool updateShouldNotify(CustomThemeHolder old) {
 return theme != old.theme;
 }
}

같은 원리를 상태관리에 적용하는 거다.

TodoDataHolder 구현

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


class TodoDataHolder extends InheritedWidget {
 final TodoDataNotifier notifier;

 const TodoDataHolder({
 required this.notifier,
 required Widget child,
 Key? key,
 }) : super(key: key, child: child);

 static TodoDataNotifier of(BuildContext context) {
 return context
 .dependOnInheritedWidgetOfExactType<TodoDataHolder>()!
 .notifier;
 }

 @override
 bool updateShouldNotify(TodoDataHolder old) {
 return notifier != old.notifier;
 }
}

of(context) 패턴은 Flutter에서 아주 관용적인 접근법이다. Theme.of(context), MediaQuery.of(context) 등 전부 이 패턴이다. 내부적으로 context.dependOnInheritedWidgetOfExactType은 Element의 해시 테이블을 조회해서 O(1)로 찾는다.

SwiftUI 비교:

Flutter	SwiftUI
`InheritedWidget` + `of(context)`	`@EnvironmentObject`
직접 InheritedWidget 클래스 작성	Property Wrapper가 자동 처리
`context.dependOn...`	`@EnvironmentObject var vm: ViewModel`

SwiftUI가 확실히 간편하다. Flutter에서는 InheritedWidget 클래스를 직접 만들어야 하는데, SwiftUI는 @EnvironmentObject만 붙이면 끝이다. 근데 원리는 같다.

context extension으로 축약

1
2
3
4
5
6


extension ContextExtension on BuildContext {
 TodoDataHolder get todoHolder => TodoDataHolder.of(this);
}

// 사용
context.todoHolder.addTodo(todo);

매번 TodoDataHolder.of(context).notifier.addTodo()라고 쓰면 너무 기니까 extension으로 축약한다. 테마에서도 context.appColors로 이미 같은 패턴을 쓰고 있었다.

App에서 Provide

1
2
3
4
5
6
7
8
9


// app.dart
CustomThemeApp(
 child: TodoDataHolder(
 notifier: TodoDataNotifier(),
 child: MaterialApp(
 home: const MainScreen(),
 ),
 ),
)

MaterialApp 위에 InheritedWidget을 감싸서 앱 전체에서 접근 가능하게 한다. SwiftUI에서 .environmentObject(todoVM)을 최상위에 넣는 것과 같은 구조다.

mounted — 비동기에서 context 안전하게 쓰기

상태관리와 별개로 중요한 포인트가 하나 있었다. 비동기 작업 중에 위젯이 dispose되면 context를 쓸 수 없는 문제다.

1
2
3
4
5
6
7
8
9


void _loadRive() async {
 _cachedFile = await File.asset('assets/rive/fire_button.riv');

 // 비동기 작업이 끝났는데 위젯이 이미 사라졌다면?
 if (_cachedFile != null && mounted) { // mounted로 체크!
 _controller = RiveWidgetController(_cachedFile!);
 setState(() => _riveReady = true);
 }
}

await 후에 setState를 부르는데, 그 사이에 사용자가 화면을 나갔다면 위젯이 dispose된 상태다. 이때 setState를 호출하면 에러가 난다. mounted 프로퍼티로 위젯이 아직 살아있는지 체크하는 게 안전하다.

iOS에서 [weak self]로 self가 nil인지 체크하는 것과 비슷한 맥락이다:

1
2
3
4
5
6


// Swift
Task { [weak self] in
 let data = await fetchData()
 guard let self else { return } // self가 살아있는지 체크
 self.updateUI(data)
}

1
2
3
4
5
6
7


// Flutter
void someAsyncWork() async {
 final data = await fetchData();
 if (mounted) { // 위젯이 살아있는지 체크
 setState(() => _data = data);
 }
}

상태 변경 흐름 정리

추가

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


void _addTodo() async {
 final result = await WriteTodoDialog().show();
 if (result != null) {
 context.todoHolder.addTodo(
 Todo(
 id: DateTime.now().microsecondsSinceEpoch,
 title: result.text,
 dueDate: result.dateTime,
 ),
 );
 }
}

다이얼로그에서 결과를 받아와서 Notifier에 추가한다. WriteTodoDialog는 제네릭 타입으로 WriteTodoResult를 반환하는 구조다.

상태 전환

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


void _changeTodoStatus(Todo todo) async {
 switch (todo.status) {
 case TodoStatus.inComplete:
 todo.status = TodoStatus.onGoing;
 case TodoStatus.onGoing:
 todo.status = TodoStatus.complete;
 case TodoStatus.complete:
 final result = await ConfirmDialog('정말로 처음 상태로 변경하시겠어요?').show();
 result?.runIfSuccess((data) {
 todo.status = TodoStatus.inComplete;
 });
 }
 context.todoHolder.notify(); // 수동으로 알림
}

mutable이니까 todo.status를 직접 바꾸고, notify()로 UI를 갱신한다. ConfirmDialog는 SimpleResult 패턴으로 결과를 체이닝한다. Swift의 Result<Success, Failure> 패턴과 비슷하다.

삭제

1
2
3


// Dismissible의 onDismissed에서
context.todoHolder.value.remove(todo);
context.todoHolder.notify();

스와이프로 삭제하면 리스트에서 제거하고 알림을 보낸다.

이 접근법의 장단점

장점:

외부 패키지 0개. Flutter 기본 API만으로 구현
InheritedWidget 동작 원리를 이해하면 Provider, BLoC 등 모든 Scoped 방식의 기반을 이해한 거다
간단한 앱에는 충분

한계:

notifyListeners() 수동 호출을 까먹기 쉬움
mutable 객체를 직접 수정하니까 어디서 바뀌었는지 추적이 어려움
비즈니스 로직이 Notifier, UI 여기저기에 흩어질 수 있음
InheritedWidget을 직접 만드는 보일러플레이트가 꽤 있음

정리

개념	Flutter (ValueNotifier)	SwiftUI
상태 홀더	`ValueNotifier`	`ObservableObject`
변경 알림	`notifyListeners()` 수동	`@Published` 자동
UI 구독	`ValueListenableBuilder`	`@ObservedObject` / body 자동
트리 전파	`InheritedWidget` + `of(context)`	`@EnvironmentObject`
비동기 안전	`mounted` 체크	`[weak self]` / `guard let self`

Flutter 내장만으로 상태관리를 해봤다. 동작은 하는데 notifyListeners() 수동 호출이 좀 거슬린다. 다음 Ch05-2에서는 GetX로 전환하면서 이 수동 호출이 .obs로 바뀌면 얼마나 코드가 줄어드는지 비교해보자.