ValueNotifier on jHoon

Ch05-6. 아키텍처와 상태관리 총정리 - 정답은 없고 차이만 있다

Sun, 03 May 2026 02:00:00 +0900

Ch05 시리즈를 통해 같은 Todo 앱을 ValueNotifier → GetX → BLoC → Riverpod → Hooks까지 5가지 방식으로 다뤄봤다. 강의 마지막에 “그래서 뭘 써야 하나"에 대한 총정리가 나왔는데, 여기에 내 생각도 섞어서 정리한다.

왜 아키텍처를 고민하는가

많은 개발자들이 앱의 아키텍처를 궁금해하고, 어떻게 해야 좋은지 고뇌한다. 내 생각은 결국 쉬운 구조를 위해서가 아닐까 싶다.

그 “쉬운 구조"를 판단하는 기준은 크게 5가지로 나눌 수 있다.

1. 쉬운 개발

가장 직관적인 기준이다.

구조 파악이 쉬운가 — 코드를 처음 보는 사람도 흐름을 빠르게 이해할 수 있는가
작성하는 코드의 양이 적은가 — 보일러플레이트가 적을수록 생산성이 올라간다
가독성이 좋은가 — 6개월 뒤의 내가 봐도 바로 이해되는가

Ch05에서 직접 체감한 걸 돌아보면:

방식	보일러플레이트	진입 장벽	구조 파악
ValueNotifier	중간	낮음	쉬움
GetX	적음	낮음	쉬움
BLoC	많음	높음	Event 따라가면 명확
Riverpod	적음	중간	Provider 단위로 명확
Hooks + Riverpod	적음	중간	역할 분리 깔끔

BLoC은 Event/State/Bloc 클래스를 다 만들어야 하니까 코드량이 확실히 많다. 근데 그 대신 “이 이벤트가 이 상태를 바꾼다"가 명확해서 대규모 팀에서는 오히려 파악이 쉬울 수 있다. 결국 “쉬움"의 기준도 상황마다 다르다.

2. 안정성

여기서 말하는 안정성은 “앱이 잘 돌아가느냐"가 아니다.

일반적으로 코드를 짜면 코딩한 대로 동작하기 마련이다. 어떤 아키텍처를 쓰든, 어떤 상태관리를 쓰든, 출시 전에 개발자와 테스터가 테스트를 마치고 앱이 나가기 때문에 작동하지 않는 경우는 없다. 이런 관점에서는 모두 안정적이고 차이가 거의 없다.

여기서 말하는 안정성은 Test Code를 작성할 수 있는가다.

스펙이 변경되고 그에 따른 수정을 할 때, 예상하지 못한 버그가 일어나는 걸 최소화하려면 테스트 코드가 필요하다. 새 기능을 추가했는데 기존 기능이 깨지는 걸 사전에 잡아내는 것. 이게 진짜 안정성이다.

방식	테스트 용이성	이유
GetX (Static)	어려움	전역 상태라 격리가 힘듦
BLoC (Scoped)	좋음	Event 입력 → State 출력 검증이 깔끔
Riverpod (Scoped)	좋음	ProviderScope로 격리, override로 mock 주입
ValueNotifier (Scoped)	보통	가능하지만 편의 기능이 적음

3. 성능

사실 성능은 일반적인 모바일 앱에서는 거의 동일하다.

약 500만 번 정도의 연산이 일어나야 120Hz 렌더링을 방해할 수 있다 (애니메이션 예제 기준)
코드를 잘못 짜서 상호참조나 무한루프를 만드는 게 아닌 이상, 성능 차이를 체감하기는 어렵다
Flutter 자체가 **C 레벨의 네이티브(Skia/Impeller)**로 렌더링하기 때문에 성능이 워낙 좋다

물론 위젯 트리 구조대로 필요한 곳만 빌드하게 해서 성능을 최적화할 수는 있다. const 위젯이나 Consumer/BlocBuilder 같은 걸로 리빌드 범위를 줄이는 식으로.

하지만 배터리 타임이나 CPU 타임에 영향을 줄 정도로 아키텍처나 상태관리 패키지가 차이를 만들지는 않는다. 아키텍처 선택이 성능을 좌우한다는 건 사실상 미신이다.

4. 확장성

스펙이 바뀌거나 기능이 추가될 때, 기존 아키텍처가 유지되는 게 베스트다.

새 화면 추가할 때 기존 구조를 건드리지 않아도 되는가
상태 하나 추가할 때 수정 범위가 해당 모듈 안에서 끝나는가
팀원이 늘어나도 각자 독립적으로 작업할 수 있는가

Scoped 방식(BLoC, Riverpod)은 Provider/Bloc 단위로 관심사가 나뉘어 있어서 확장할 때 기존 코드를 건드릴 일이 적다. GetX도 Controller 단위로 나누면 되지만, 전역 접근이 가능하다는 특성상 의도치 않은 의존성이 생길 수 있다.

5. 제공되는 추가 기능들

각 패키지마다 별도로 제공하는 기능들이 있고, 이것도 선택에 영향을 준다.

패키지	특화 기능
GetX	라우팅, 다이얼로그, 스낵바, 다국어 — 올인원
BLoC	BlocObserver (Event 로깅), bloc_test
Riverpod	`.when` (비동기 분기), `family` (키 기반 상태), `@riverpod` 코드 생성
Hooks	Controller 자동 dispose, Custom Hook 재사용

GetX는 상태관리 외에도 네비게이션, UI 유틸리티까지 한 패키지에 들어있다. BLoC은 이벤트 추적에 강하다. Riverpod은 비동기 처리가 압도적이다. 프로젝트에서 어떤 기능이 중요한지에 따라 선택이 달라진다.

정답은 없다, 차이만 있다

아키텍처와 상태관리는 맞고 틀리고의 정답이 없다. ‘차이점’만 존재한다.

5가지 기준을 한눈에 정리하면:

기준	GetX	BLoC	Riverpod
쉬운 개발	쉬움	보일러플레이트 많음	적당함
안정성 (테스트)	격리 어려움	Event/State 검증 용이	override로 mock 주입
성능	동일	동일	동일
확장성	전역이라 의존성 주의	Bloc 단위 분리	Provider 단위 분리
추가 기능	올인원	Event 로깅	`.when`, `family`

Scoped vs Static — 접근성 다시 보기

Ch04에서 Scoped Model과 Static Model을 다뤘었다. 실제로 써보고 나니 “접근"에 대한 생각이 좀 바뀌었다.

모델	상태 접근 방식	대표
Scoped	`context.read()` (BLoC), `ref.read()` (Riverpod)	BLoC, Riverpod
Static	`Get.find()` — 어디서나 접근	GetX

Static이 언뜻 보면 쉬워 보인다. context니 ref니 하는 참조 엘리먼트를 안 써도 되니까. 하지만 실무적으로 살짝 불편할 뿐, 구조적으로는 접근에 문제가 없다.

애초에 앱을 실행시키는 main 함수에서 앱 객체를 만들 때부터 코드에서는 context와 ref를 참조할 수 있다. initState나 afterFirstLayout에서 context 접근이 가능하고, Riverpod은 ConsumerWidget만 쓰면 ref로 필요한 접근이 다 된다.

그렇기 때문에 “접근” 자체는 정말 사소하게 불편할 뿐, 참조를 연결만 한다면 구조적으로 언제나 접근이 된다고 봐도 무방하다.

진짜 차이가 나는 건 Widget Tree에 기반한 설계다.

Scoped 방식(BLoC, Riverpod)은 위젯 트리 위치에 따라 상태의 범위가 자연스럽게 정해진다. 화면이 닫히면 해당 스코프의 상태도 자동으로 정리된다.

GetX로 같은 걸 하려면 직접 구조를 구현해야 한다. 이전 블로그에서 다뤘듯이 임시 ID(tag)를 부여해서 관리해야 하는데, 해당 트리에 해당되는 위젯 생성자에 ID를 매번 전달하거나, InheritedWidget을 직접 구현해야 한다. 메모리 관리도 따로 해줘야 해서 오히려 더 불편해진다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// Riverpod: 스코프가 자연스럽게 관리됨
ProviderScope(
 overrides: [commentProvider.overrideWith(() => CommentNotifier(videoId: id))],
 child: CommentSection(),
)
// 화면 닫히면 자동 정리

// GetX: tag로 직접 관리해야 함
Get.put(CommentController(videoId: id), tag: id);
// ...
Get.delete<CommentController>(tag: id); // 직접 정리

4가지 방식 최종 비교

Ch05 전체를 통해 같은 Todo 앱을 돌려본 결과:

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

여기에 Hooks를 더하면 로컬 UI 상태(useState, useTextEditingController)는 Hooks가, 공유 비즈니스 상태는 Riverpod이 맡아서 역할 분리가 깔끔해진다.

공부법에 대한 생각

Flutter를 공부해보니 몇 개월, 몇 년 이상 공부한 사람들은 패키지, 아키텍처, 상태관리 관련해서 블로그나 유튜브 등을 찾아보면서 시간을 꽤 많이 쓰지 않았을까 싶다. 물론 좋은 방향이지만, 너무 알아보고 너무 살펴보는 데 많은 시간을 쏟는다면 조금은 낭비가 아닐까 조심스레 생각해본다.

필자의 성격은 새로운 하나를 접하면(개발 외 모든 분야) A에서 Z까지 파보는 성격이다. 처음 개발을 접할 때도 그렇게 공부했다가 몇 달 만에 번아웃이 와버렸다.

이번에 Flutter를 새로 공부하면서 그 습관은 버리고, 직접 프로젝트에 적용해 가며 안 되는 것들을 찾아가고, 이를 해결하기 위해 직접 코드를 구현하거나 다른 패키지들을 도입해보면서 해결할 수 있는 능력을 길렀다. 해보지도 않고 이론에만 시간 쏟는 것보다 와닿는 게 훨씬 빨랐다.

물론 매우 주관적인 의견일 수 있다. 하지만 적어도 나한테는 이 방법이 맞았다:

일단 만들어본다 — Todo 앱 하나를 4가지 방식으로 전환해본 게 블로그 10개 읽는 것보다 나았다
안 되는 걸 찾아본다 — 필요할 때 찾아보는 게 기억에 남는다
비교는 직접 해본 뒤에 — 써보지도 않고 “BLoC vs Riverpod” 비교 글만 읽으면 감이 안 온다

마무리

앞으로 많은 프로젝트를 할 예정이고, 현재 운영 중인 iOS 네이티브 앱을 Flutter로 전환하는 계획도 있다. 상태관리, 아키텍처, 각종 패키지 등 프로젝트 상황에 맞게 잘 적용해보자.

Ch05 시리즈를 한 문장으로 정리하면:

아키텍처와 상태관리는 정답이 없다. 차이점만 있을 뿐이다. 직접 써보고 프로젝트에 맞는 걸 고르자.

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로 바뀌면 얼마나 코드가 줄어드는지 비교해보자.