GetX 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-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() 같은 함정이 어떻게 사라지는지 비교해보자.

Ch04. 상태관리를 왜 해야 하는가 - MVC에서 선언형 UI까지

Tue, 28 Apr 2026 03:00:00 +0900

Ch04부터는 상태관리다. 왜 상태관리를 해야 하는지, 어떤 방식들이 있는지 정리한다. 개인적으로 이 부분이 꽤 재밌었다.

상태관리를 왜 해야 하나

결론부터 말하면 앱을 더 쉽게 개발하기 위해서다.

처음 개발할 때 빠르게 만들기 위해
스펙이 바뀌었을 때 수정할 곳을 빠르게 찾기 위해

작은 앱에서는 setState만으로도 충분한데, 화면이 10개 넘어가고 여러 화면에서 같은 데이터를 공유해야 하면 어디서 상태를 관리하고 어떻게 전달할지가 문제가 된다. 이걸 체계적으로 정리한 게 상태관리 패턴이다.

MVC에서 선언형 UI까지 — 왜 이렇게 바뀌었나

MVC (Model-View-Controller)

1970년대에 나온 패턴이다. 근데 많이들 오해하는 게 있다:

원래 작은 컴포넌트 단위의 설계였다. 앱 전체 아키텍처용이 아니었다.
MVVM에서 말하는 데이터 Observing이 이미 포함돼 있던 개념이다.
Controller는 원래 키보드/마우스 입력을 처리하는 역할이었다.

문제는 모바일에서 Controller의 의미가 변질됐다는 거다. Android의 Activity, iOS의 UIViewController가 이미 Controller이면서 동시에 View였다. 화면 자체가 Controller 역할을 하는 짬뽕이 된 거다. 결과적으로 Controller가 뚱뚱해지면서(Massive View Controller라고 부른다) 유지보수가 힘들어졌다.

Swift에서 UIKit 개발해본 사람이면 ViewController에 네트워크 호출, 테이블뷰 delegate, 데이터 가공 로직까지 다 때려넣어본 경험이 있을 거다. 그게 바로 MVC의 한계다.

MVP (Model-View-Presenter)

MVC의 문제를 해결하려고 나온 게 MVP다.

Android는 View가 XML로 분리돼 있었고
iOS는 View가 ViewController + Storyboard로 분리돼 있었다

이렇게 코드와 분리된 View를 제어할 Presenter가 필요했다. Presenter가 로직을 담당하고, View는 그리기만 한다.

근데 문제가 있었다. Presenter가 View에게 일일이 명령을 내려야 화면이 갱신됐다. “이 라벨 텍스트 바꿔”, “이 버튼 숨겨”, “이 리스트 리로드해”… 하나하나 다 지시해야 했다. 코드가 장황해지고 빠뜨리면 UI 버그가 났다.

MVVM (Model-View-ViewModel)

MVP의 “일일이 명령” 문제를 해결한 게 MVVM이다.

1

ViewModel의 상태를 바꾸면 → View가 알아서 갱신된다

핵심은 데이터 바인딩이다:

Android에서는 DataBinding 라이브러리가 나왔고
iOS에서는 RxSwift 같은 Rx 라이브러리로 Observable 패턴을 구현했다

값만 세팅하면 알아서 뷰가 갱신되니까 UI 버그가 확 줄었다. 근데 완벽하진 않았다. 뷰가 내부적으로 코드와 분리돼 있었기 때문에(XML, Storyboard) ViewModel과 View를 연결하는 바인딩 코드가 노가다였다.

iOS에서 RxSwift 쓸 때를 떠올리면:

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


// iOS + RxSwift: 바인딩 노가다
viewModel.userName
 .bind(to: nameLabel.rx.text)
 .disposed(by: disposeBag)

viewModel.isLoading
 .bind(to: activityIndicator.rx.isAnimating)
 .disposed(by: disposeBag)

viewModel.items
 .bind(to: tableView.rx.items(cellIdentifier: "Cell")) { ... }
 .disposed(by: disposeBag)

프로퍼티 하나하나 다 바인딩해줘야 했다.

선언형 UI — 최종 보스

그리고 선언형 UI가 등장했다.

Android → Jetpack Compose
iOS → SwiftUI
크로스플랫폼 → Flutter, React

Flutter 공식 문서에서 설명하는 핵심 차이는 이거다:

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


// 명령형 (Imperative) — 어떻게 바꿀지 지시
button.setColor(red);
button.setText('완료');
container.removeChild(oldChild);
container.addChild(newChild);

// 선언형 (Declarative) — 어떤 상태인지 선언
return ElevatedButton(
 style: ButtonStyle(backgroundColor: MaterialStateProperty.all(Colors.red)),
 onPressed: onTap,
 child: Text('완료'),
);

명령형은 “빨간색으로 바꿔, 텍스트 바꿔, 자식 교체해” 하고 일일이 지시하는 거고, 선언형은 “이 상태일 때 UI는 이렇게 생겼다"고 선언만 하면 프레임워크가 알아서 그려준다.

SwiftUI에서 @State가 바뀌면 body가 다시 그려지는 것과 완전히 같은 원리다:

1
2
3
4
5
6
7


// SwiftUI
struct CounterView: View {
 @State var count = 0
 var body: some View {
 Button("\(count)") { count += 1 }
 }
}

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


// Flutter
class CounterWidget extends StatefulWidget {
 @override
 State<CounterWidget> createState() => _CounterWidgetState();
}

class _CounterWidgetState extends State<CounterWidget> {
 int count = 0;

 @override
 Widget build(BuildContext context) {
 return ElevatedButton(
 onPressed: () => setState(() => count++),
 child: Text('$count'),
 );
 }
}

선언형 UI가 나오면서 View의 패턴 구조를 논의할 필요가 없어졌다. MVC냐 MVP냐 MVVM이냐가 아니라, 상태와 데이터를 어떻게 관리할지가 더 중요해진 거다. 그게 바로 State Management다.

흐름 정리

1
2
3
4
5
6
7


MVC: 원래 작은 컴포넌트용이었는데 모바일에서 Controller가 비대해짐
 ↓
MVP: View와 로직을 Presenter로 분리. 근데 일일이 명령해야 함
 ↓
MVVM: 데이터 바인딩으로 자동 갱신. 근데 바인딩 코드가 노가다
 ↓
선언형 UI: 상태만 바꾸면 끝. 이제 "상태를 어떻게 관리할까"가 핵심

Scoped Model vs Static Model

Flutter 상태관리 구조는 크게 두 가지로 나뉜다.

Scoped Model

상태의 범위를 제한하는 방식이다. 특정 화면이나 위젯 트리 안에서만 상태가 유효하다.

1
2
3
4
5


// Provider 예시: 이 위젯 하위에서만 CartModel에 접근 가능
ChangeNotifierProvider(
 create: (_) => CartModel(),
 child: ShoppingPage(), // 이 안에서만 CartModel 사용 가능
)

특징:

해당 화면이 사라지면 자동으로 메모리 해제된다
자식 위젯에서 id 없이도 상위 데이터를 참조할 수 있다
내부적으로 Flutter의 InheritedWidget을 활용한다

대표적인 Scoped 방식: Provider, BLoC, Riverpod

Static Model

상태가 전역으로 떠 있는 방식이다. 앱 어디서든 접근할 수 있다.

1
2
3
4
5
6
7
8


// GetX 예시: 어디서든 접근 가능
Get.put(UserController());

// A 화면에서
Get.find<UserController>().user.value;

// B 화면에서도
Get.find<UserController>().user.value; // 같은 인스턴스

특징:

메모리 관리를 개발자가 직접 해야 한다
자식에서 데이터 참조할 때 id(tag)가 항상 필요하다
Scoped보다 구현이 훨씬 쉽다
어디서든 접근/수정 가능하니까 상태가 꼬일 위험이 있다

대표적인 Static 방식: GetX

뭐가 다른지 예시로 보면

유튜브 앱이라고 치자. 영상 재생 화면은 코드상으로는 같은 VideoScreen인데, 어떤 영상이냐에 따라 동영상 URL, 댓글, 좋아요 수가 전부 다르다.

Scoped 방식에서는:

1
2
3
4
5


// 각 영상 화면의 상위에 해당 영상의 상태를 넣어줌
ChangeNotifierProvider(
 create: (_) => VideoState(videoId: 'abc123'),
 child: VideoScreen(), // 이 안에서는 abc123 영상의 상태만 보임
)

Riverpod에서는 family라는 기능으로 더 깔끔하게 처리한다:

1
2
3
4
5
6
7
8


// Riverpod: videoId별로 자동으로 다른 상태 인스턴스 생성
final videoProvider = FutureProvider.family<Video, String>((ref, videoId) {
 return fetchVideo(videoId);
});

// 사용: 같은 provider인데 id가 다르면 다른 상태
ref.watch(videoProvider('abc123')); // 영상 1의 상태
ref.watch(videoProvider('xyz789')); // 영상 2의 상태 (별도)

Static 방식(GetX)에서는:

1
2
3
4
5
6


// tag로 구분해서 따로 관리
Get.put(VideoController(), tag: 'abc123');
Get.put(VideoController(), tag: 'xyz789');

// 사용할 때 tag로 찾아와야 함
Get.find<VideoController>(tag: 'abc123');

둘 다 가능하다. 근데 Scoped는 화면 닫으면 알아서 정리되고, Static은 개발자가 직접 Get.delete(tag: 'abc123') 해줘야 한다.

또 다른 예시 — ID가 없는 경우

데스크탑 앱에서 “새 문서” 버튼을 3번 눌렀다고 치자. 각 문서는 아직 저장 전이라 고유 ID가 없다. 이때는 Scoped가 자연스럽다:

1
2
3
4
5
6
7


// Scoped: 각 문서 화면이 자기 스코프 안에 상태를 가짐
Navigator.push(context, MaterialPageRoute(
 builder: (_) => ChangeNotifierProvider(
 create: (_) => DocumentState(), // 각각 독립된 상태
 child: DocumentScreen(),
 ),
));

Static으로도 가능은 하다 — 임시 ID를 생성해서 tag로 관리하면 된다. 근데 굳이 그럴 필요 없이 Scoped가 더 깔끔한 케이스다.

그래서 뭘 써야 하나

정답은 스펙에 따라 다르다. 하지만 일반적인 기준은 있다:

	Scoped Model	Static Model
메모리 관리	자동 해제	직접 관리
데이터 접근	위젯 트리 통해서	어디서든 직접
구현 난이도	상대적으로 복잡	쉬움
상태 안정성	범위가 제한돼서 안전	어디서든 수정 가능해서 꼬일 수 있음
테스트	스코프 단위로 격리 가능	전역 상태라 격리 어려움
대표 패키지	Provider, BLoC, Riverpod	GetX

Swift 개발자 입장에서 비유하면:

Scoped = SwiftUI에서 @StateObject를 뷰 계층에 맞게 넣는 것
Static = 싱글톤으로 전역 접근하는 것 (AppState.shared)

iOS 개발할 때도 싱글톤 남발하면 테스트 힘들고 상태 꼬이는 걸 경험해봤을 텐데, Flutter에서도 똑같다. GetX가 쉬운 건 맞지만 앱이 커지면 Scoped 방식이 관리하기 편하다.

상태관리 패키지 현황

Flutter 공식 문서에서도 여러 접근법을 소개하고 있다. 현재 주요 패키지들의 포지션을 정리하면:

패키지	방식	특징
Provider	Scoped	Flutter 팀 추천 입문용. InheritedWidget 래퍼
BLoC	Scoped	Event → State 단방향 흐름. 엔터프라이즈 앱에 적합
Riverpod	Scoped	Provider의 진화형. 컴파일 타임 안전성. family로 키 기반 관리
GetX	Static	전역 접근, 쉬운 구현. tag로 인스턴스 구분

Flutter 공식 입장은 “setState로 시작하고, 복잡해지면 패키지를 도입하라"다. 어떤 패키지가 절대적으로 좋다기보다는 앱 규모와 팀 상황에 맞는 걸 고르는 게 맞다.

정리

상태관리의 역사를 보면 결국 한 방향으로 흘러왔다:

1

"UI를 어떻게 그릴까" → "상태를 어떻게 관리할까"

MVC에서 선언형 UI까지 오는 동안 패턴이 계속 바뀐 이유는 “상태가 바뀌면 UI가 알아서 반영되게” 하고 싶었기 때문이다. 선언형 UI가 그걸 해결했고, 이제 남은 문제는 그 상태를 어떤 범위에서 어떻게 관리할지다.

Scoped냐 Static이냐는 결국 트레이드오프다. 쉬운 걸 원하면 Static(GetX), 안전한 걸 원하면 Scoped(Provider/BLoC/Riverpod). iOS 개발할 때 싱글톤 vs 의존성 주입 고민했던 것과 본질적으로 같은 문제다.

Ch02. 토스 앱 클론 - 실전 UI와 상태관리

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

Ch01에서 기본기를 다졌으니 이번엔 토스 앱을 클론하면서 실전 UI를 만들어봤다. 멀티탭 네비게이션, 상태관리, 테마 시스템처럼 실제 앱에서 꼭 필요한 것들 위주로 정리한다.

멀티탭 네비게이션 - IndexedStack

토스처럼 하단 5개 탭을 만들 때 가장 먼저 고민되는 게 “탭을 전환할 때 이전 탭의 상태를 유지할 것인가"다. SwiftUI에서는 TabView 안에 각각 NavigationStack을 넣으면 알아서 상태가 유지되는데, Flutter는 직접 해줘야 한다.

여기서 쓰는 게 IndexedStack이다. Flutter 공식 문서에 따르면, Stack의 서브클래스로 index에 해당하는 자식만 화면에 그리되 나머지 자식도 메모리에 유지한다. 즉 탭을 왔다갔다 해도 스크롤 위치나 입력 값이 그대로 남아있다.

 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


class MainScreen extends StatefulWidget {
 @override
 State<MainScreen> createState() => _MainScreenState();
}

class _MainScreenState extends State<MainScreen> {
 int _tabIndex = 0;
 final _pages = [HomePage(), StockPage(), BenefitPage()];

 @override
 Widget build(BuildContext context) {
 return Scaffold(
 body: IndexedStack(
 index: _tabIndex,
 children: _pages,
 ),
 bottomNavigationBar: BottomNavigationBar(
 currentIndex: _tabIndex,
 onTap: (i) => setState(() => _tabIndex = i),
 type: BottomNavigationBarType.fixed,
 items: const [
 BottomNavigationBarItem(icon: Icon(Icons.home), label: '홈'),
 BottomNavigationBarItem(icon: Icon(Icons.candlestick_chart), label: '주식'),
 BottomNavigationBarItem(icon: Icon(Icons.star), label: '혜택'),
 ],
 ),
 );
 }
}

PageView랑 비교하면 차이가 명확하다:

	IndexedStack	PageView
상태 유지	자동 (전부 메모리 유지)	`AutomaticKeepAliveClientMixin` 필요
전환 애니메이션	없음 (즉시 전환)	스와이프 애니메이션
지연 로딩	안 됨 (전부 빌드)	됨 (보이는 것만 빌드)

탭이 3~5개 정도면 IndexedStack으로 충분한데, 탭 수가 많아지면 메모리를 잡아먹으니까 주의해야 한다.

탭마다 독립 네비게이션 스택

토스 앱에서 주식 탭에서 종목 상세 화면으로 들어갔다가 홈 탭으로 전환하고, 다시 주식 탭으로 돌아오면 종목 상세가 그대로 남아있다. 이걸 구현하려면 탭마다 별도의 Navigator를 줘야 한다.

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


// 각 탭에 독립 Navigator를 부여
class TabNavigator extends StatelessWidget {
 final GlobalKey<NavigatorState> navigatorKey;
 final Widget rootPage;

 const TabNavigator({required this.navigatorKey, required this.rootPage});

 @override
 Widget build(BuildContext context) {
 return Navigator(
 key: navigatorKey,
 onGenerateRoute: (_) => MaterialPageRoute(builder: (_) => rootPage),
 );
 }
}

GlobalKey<NavigatorState>로 각 탭의 네비게이터에 접근할 수 있어서, 뒤로가기 버튼을 누르면 현재 탭 내부에서만 pop이 일어난다. SwiftUI의 TabView 안에 각각 NavigationStack을 넣는 것과 같은 구조인데, Flutter는 Navigator를 직접 배치하는 거라 좀 더 수작업이 많다.

뒤로가기 처리도 PopScope로 직접 해야 한다. Flutter는 Android 14의 Predictive Back 제스처를 지원하기 위해 WillPopScope를 deprecated 시키고 PopScope로 교체했다. canPop으로 pop 가능 여부를 미리 선언하고, onPopInvokedWithResult에서 실제 처리를 한다.

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


PopScope(
 canPop: false,
 onPopInvokedWithResult: (didPop, _) {
 if (didPop) return;
 // 현재 탭에서 pop 가능하면 탭 내부 pop
 if (navigatorKeys[_tabIndex].currentState?.canPop() == true) {
 navigatorKeys[_tabIndex].currentState!.pop();
 return;
 }
 // 홈 탭이 아니면 홈으로 이동
 if (_tabIndex != 0) {
 setState(() => _tabIndex = 0);
 }
 },
 child: // ...
)

SwiftUI에서는 이런 뒤로가기 분기 처리를 할 일이 거의 없는데, Flutter에서는 Android 하드웨어 백 버튼 때문에 필수다.

CustomScrollView와 Sliver

주식 탭처럼 스크롤하면 AppBar가 접히는 효과를 만들려면 CustomScrollView + Sliver를 써야 한다.

Sliver는 Flutter에서 스크롤 가능한 영역의 조각을 뜻한다. 일반 위젯이 BoxConstraints로 레이아웃하는 것과 달리, Sliver는 SliverConstraints라는 별도 프로토콜을 써서 스크롤 위치에 따라 동적으로 크기와 위치를 결정한다. Flutter 공식 가이드에서 자세히 설명하고 있다.

왜 ListView로는 안 되냐면, ListView는 자체적으로 하나의 스크롤 컨텍스트를 만든다. 접히는 AppBar + 리스트 + 그리드를 하나의 스크롤로 묶으려면 같은 스크롤 컨텍스트를 공유해야 하는데, 그게 CustomScrollView다.

 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


CustomScrollView(
 slivers: [
 SliverAppBar(
 pinned: true, // 스크롤해도 AppBar 고정
 expandedHeight: 120,
 flexibleSpace: FlexibleSpaceBar(
 title: Text('주식'),
 ),
 actions: [
 IconButton(icon: Icon(Icons.search), onPressed: () {}),
 IconButton(icon: Icon(Icons.settings), onPressed: () {}),
 ],
 ),
 SliverToBoxAdapter(
 child: Padding(
 padding: EdgeInsets.all(16),
 child: Text('S&P 500 3,919.29', style: TextStyle(fontSize: 24)),
 ),
 ),
 SliverList(
 delegate: SliverChildBuilderDelegate(
 (context, index) => ListTile(
 title: Text(stockNames[index]),
 trailing: Text(stockPrices[index]),
 ),
 childCount: stockNames.length,
 ),
 ),
 ],
)

SwiftUI에서는 ScrollView 안에 .toolbar를 넣으면 접히는 효과가 자동으로 되는데, Flutter는 Sliver 조합으로 직접 구성해야 한다. 대신 세밀한 제어가 가능하다.

SliverAppBar의 옵션을 정리하면:

속성	동작
`pinned: true`	스크롤해도 AppBar가 상단에 고정
`floating: true`	위로 스크롤하면 AppBar가 바로 나타남
`snap: true`	floating과 함께 쓰면 중간 상태 없이 딱 열리거나 닫힘
`expandedHeight`	완전히 펼쳤을 때 높이

SliverToBoxAdapter는 일반 위젯을 Sliver 안에 넣을 때 쓰는 어댑터다. Sliver 프로토콜을 모르는 일반 위젯(Text, Container 등)을 감싸서 CustomScrollView에 넣을 수 있게 해준다.

TabBar + CustomScrollView 조합

주식 탭 안에 “내 주식” / “오늘의 발견” 같은 하위 탭을 넣을 때 주의할 점이 있다. 보통 TabBar + TabBarView를 쓰는데, TabBarView는 내부적으로 PageView를 사용하기 때문에 CustomScrollView 안에서 높이 계산 문제가 생긴다.

그래서 TabBarView 대신 currentIndex로 직접 전환하는 방식을 썼다:

 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


class _StockPageState extends State<StockPage>
 with SingleTickerProviderStateMixin {
 late TabController _tabController;

 @override
 void initState() {
 super.initState();
 _tabController = TabController(length: 2, vsync: this);
 _tabController.addListener(() => setState(() {}));
 }

 @override
 void dispose() {
 _tabController.dispose();
 super.dispose();
 }

 @override
 Widget build(BuildContext context) {
 return CustomScrollView(
 slivers: [
 SliverAppBar(pinned: true, title: Text('주식')),
 SliverToBoxAdapter(
 child: TabBar(
 controller: _tabController,
 tabs: [Tab(text: '내 주식'), Tab(text: '오늘의 발견')],
 ),
 ),
 SliverToBoxAdapter(
 child: _tabController.index == 0
 ? MyStockList()
 : TodayDiscoveryList(),
 ),
 ],
 );
 }
}

TabController의 addListener로 탭 변경을 감지하고 setState로 리빌드한다. dispose에서 컨트롤러 정리하는 것도 잊으면 안 된다.

GetX 상태관리

검색 자동완성 기능에서 GetX를 써봤다. GetX는 상태관리 + 의존성 주입 + 라우팅을 한 패키지로 제공하는데, 여기서는 상태관리와 DI만 사용했다.

반응형 상태 - .obs와 Obx

GetX의 반응형 시스템은 .obs로 시작한다. 변수 뒤에 .obs를 붙이면 값 변경을 추적하는 반응형 타입(Rx<T>)이 된다. Provider의 ChangeNotifier나 BLoC의 Stream과 달리 GetX는 자체 반응형 시스템을 쓴다.

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


class SearchController extends GetxController {
 final results = <String>[].obs; // RxList<String>
 final query = ''.obs; // RxString

 @override
 void onInit() {
 super.onInit();
 // debounce: 입력 멈추고 300ms 후에 검색 실행
 debounce(query, (_) => _doSearch(), time: 300.ms);
 }

 void updateQuery(String text) => query.value = text;

 void _doSearch() {
 if (query.value.isEmpty) {
 results.clear();
 return;
 }
 results.value = allItems
 .where((item) => item.contains(query.value))
 .toList();
 }
}

Obx로 감싸면 내부에서 사용하는 .obs 변수가 바뀔 때만 해당 위젯이 리빌드된다. setState처럼 전체를 다시 그리는 게 아니라 Obx 블록만 갱신하니까 효율적이다.

1
2
3
4


Obx(() => ListView.builder(
 itemCount: controller.results.length,
 itemBuilder: (_, i) => ListTile(title: Text(controller.results[i])),
))

하나 편한 점은, 같은 값으로 세팅하면 리빌드가 안 일어난다. 내부적으로 이전 값과 비교해서 실제로 바뀔 때만 UI를 갱신하는 거다.

의존성 주입 - Get.put과 Get.find

GetX의 DI는 전역 컨테이너 방식이다. Get.put()으로 등록하고 Get.find()로 어디서든 꺼내 쓴다.

 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


// 화면 진입 시 등록
class _SearchScreenState extends State<SearchScreen> {
 @override
 void initState() {
 super.initState();
 Get.put(SearchController());
 }

 @override
 void dispose() {
 Get.delete<SearchController>();
 super.dispose();
 }
}

// 자식 위젯에서 사용
class ResultListView extends StatelessWidget {
 final controller = Get.find<SearchController>();

 @override
 Widget build(BuildContext context) {
 return Obx(() => ListView.builder(
 itemCount: controller.results.length,
 itemBuilder: (_, i) => ListTile(title: Text(controller.results[i])),
 ));
 }
}

SwiftUI 비교로 정리하면:

GetX	SwiftUI	역할
`GetxController`	`ObservableObject`	상태 클래스
`.obs`	`@Published`	변경 감지
`Obx(() =>)`	자동	UI 리빌드
`Get.put()`	`.environmentObject()`	등록
`Get.find()`	`@EnvironmentObject`	접근

차이는 @EnvironmentObject가 위젯 트리 안에서만 접근 가능한 반면, Get.find()는 BuildContext 없이 어디서든 전역 접근이 된다는 것이다. 편하긴 한데 남용하면 의존성 추적이 어려워진다.

Mixin으로 접근 축약

여러 위젯에서 같은 컨트롤러를 Get.find()로 가져오는 게 반복되면 mixin으로 묶을 수 있다:

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


mixin SearchDataProvider {
 SearchController get searchData => Get.find<SearchController>();
}

class AutoCompleteList extends StatelessWidget with SearchDataProvider {
 @override
 Widget build(BuildContext context) {
 return Obx(() => ListView.builder(
 itemCount: searchData.results.length,
 itemBuilder: (_, i) => Text(searchData.results[i]),
 ));
 }
}

GetX에는 GetView<T>라는 내장 클래스도 있어서, 상속하면 controller로 바로 접근할 수 있다. 다만 하나의 컨트롤러 타입만 바인딩되니까 여러 컨트롤러가 필요하면 mixin이 낫다.

GetX에 대한 솔직한 생각

GetX가 편한 건 맞는데, 커뮤니티에서 논쟁이 좀 있다. 메인테이너가 한 명이라 업데이트가 느리고, 전역 상태 접근이 너무 쉬워서 코드가 커지면 의존성 파악이 어려워진다는 비판이 있다. 요즘은 새 프로젝트에서 Riverpod을 많이 쓰는 추세인 것 같다. 나도 다음 프로젝트에서는 Riverpod을 써볼 예정이다.

다크모드 - InheritedWidget 기반 테마

Flutter 기본 ThemeData만으로도 다크모드를 할 수 있지만, 토스 앱처럼 커스텀 컬러가 많으면 InheritedWidget로 직접 테마 시스템을 만드는 게 편하다.

InheritedWidget은 위젯 트리를 통해 데이터를 하위로 전파하는 메커니즘이다. Flutter 공식 문서에 따르면, 내부적으로 각 Element에 InheritedWidget 해시 테이블을 유지해서 O(1)로 조회가 가능하다. Provider 패키지도 사실 이걸 감싼 래퍼다.

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


// 1. 색상 추상 클래스
abstract class AppColors {
 Color get background;
 Color get text;
 Color get card;
 Color get accent;
}

class LightColors implements AppColors {
 Color get background => Colors.white;
 Color get text => Colors.black87;
 Color get card => Colors.grey.shade100;
 Color get accent => Color(0xFF3182F6); // 토스 블루
}

class DarkColors implements AppColors {
 Color get background => Color(0xFF1B1B1E);
 Color get text => Colors.white;
 Color get card => Color(0xFF2C2C2E);
 Color get accent => Color(0xFF5B9BF5);
}

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


// 2. InheritedWidget으로 트리에 전파
class ThemeHolder extends InheritedWidget {
 final AppColors appColors;
 final VoidCallback onToggle;

 const ThemeHolder({
 required this.appColors,
 required this.onToggle,
 required super.child,
 });

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

 @override
 bool updateShouldNotify(ThemeHolder old) => appColors != old.appColors;
}

1
2
3
4
5
6
7
8
9


// 3. extension으로 축약
extension ThemeContext on BuildContext {
 AppColors get appColors => ThemeHolder.of(this).appColors;
 VoidCallback get toggleTheme => ThemeHolder.of(this).onToggle;
}

// 사용
Container(color: context.appColors.background)
Text('제목', style: TextStyle(color: context.appColors.text))

Theme.of(context).colorScheme.primary 이렇게 길게 쳐야 하는 걸 context.appColors.accent로 줄인 거다. SwiftUI의 @Environment(\.colorScheme)과 비슷한 역할이지만, Flutter는 InheritedWidget + extension 조합으로 직접 만드는 거라 초기 작업이 좀 필요하다.

테마 전환은 상위 StatefulWidget에서 setState로 InheritedWidget을 리빌드하면 된다. updateShouldNotify가 true를 반환하면 dependOnInheritedWidgetOfExactType을 호출한 모든 하위 위젯이 자동으로 리빌드된다.

애니메이션 - flutter_animate

Flutter 기본 애니메이션은 AnimationController + StatefulWidget + TickerProviderStateMixin + dispose까지 써야 해서 보일러플레이트가 상당하다. flutter_animate 패키지를 쓰면 한 줄로 끝난다.

1
2
3
4
5
6
7


// flutter_animate - 체이닝 API
Column(
 children: [
 Text('토스뱅크').animate().fadeIn(duration: 600.ms).slideY(begin: 0.3),
 BankAccountCard().animate().fadeIn(delay: 200.ms).slideX(begin: -0.1),
 ],
)

기본 AnimationController 방식이랑 비교하면:

 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


// 기본 방식 - 이만큼 써야 한다
class _MyWidgetState extends State<MyWidget>
 with SingleTickerProviderStateMixin {
 late AnimationController _controller;
 late Animation<double> _fadeAnim;

 @override
 void initState() {
 super.initState();
 _controller = AnimationController(vsync: this, duration: 600.ms);
 _fadeAnim = Tween(begin: 0.0, end: 1.0).animate(_controller);
 _controller.forward();
 }

 @override
 void dispose() {
 _controller.dispose();
 super.dispose();
 }

 @override
 Widget build(BuildContext context) {
 return FadeTransition(opacity: _fadeAnim, child: Text('토스뱅크'));
 }
}

flutter_animate는 이 모든 걸 .animate().fadeIn() 한 줄로 처리한다. 효과를 체이닝하면 기본적으로 동시에 실행되고, .then()을 쓰면 순차 실행으로 바꿀 수 있다.

1
2
3
4
5
6
7
8


// 동시 실행: fade + slide가 같이
widget.animate().fadeIn().slide()

// 순차 실행: fade 끝나고 200ms 뒤에 slide
widget.animate()
 .fadeIn(duration: 500.ms)
 .then(delay: 200.ms)
 .slide()

SwiftUI의 .transition(.opacity), .animation(.easeInOut) 같은 선언적 방식과 비슷한데, 체이닝이 가능해서 복합 애니메이션 조합이 더 유연한 편이다.

자주 만나는 레이아웃 에러들

Flutter 하면서 이것저것 삽질한 것들을 정리해둔다.

1. Row/Column 안에서 Unbounded 에러

1
2
3
4
5


// 에러: Row 안의 TextField가 너비를 못 잡음
Row(children: [TextField()])

// 해결: Expanded로 남은 공간 차지하게
Row(children: [Expanded(child: TextField())])

Row는 자식에게 무한 너비를 허용하는데 TextField는 가능한 너비를 전부 쓰려고 해서 충돌이 난다.

2. 스크롤 안에 스크롤 - 높이 충돌

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 에러: SingleChildScrollView 안에 ListView가 무한 높이 요구
SingleChildScrollView(
 child: Column(children: [ListView.builder(...)]),
)

// 해결: shrinkWrap + 스크롤 비활성화
ListView.builder(
 shrinkWrap: true, // 콘텐츠 높이만큼만
 physics: NeverScrollableScrollPhysics(), // 스크롤은 부모가
)

Ch01 인스타 클론에서도 나온 패턴인데, shrinkWrap은 성능에 영향을 주니까 아이템이 많으면 CustomScrollView + SliverList를 쓰는 게 맞다.

3. GestureDetector 빈 영역 터치 안 됨

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


// 안 됨: Spacer 영역은 터치 이벤트가 안 먹힘
GestureDetector(
 onTap: () {},
 child: Row(children: [Text('메뉴'), Spacer(), Icon(Icons.arrow_right)]),
)

// 해결: behavior 설정
GestureDetector(
 behavior: HitTestBehavior.opaque, // 투명 영역도 터치 감지
 onTap: () {},
 child: Row(children: [Text('메뉴'), Spacer(), Icon(Icons.arrow_right)]),
)

기본적으로 GestureDetector는 자식이 그려진 영역만 터치를 감지한다. HitTestBehavior.opaque를 주면 빈 공간도 터치 영역에 포함된다.

dispose 잊으면 메모리 누수

initState에서 만든 리소스는 dispose에서 반드시 정리해야 한다. 안 하면 메모리 누수가 생긴다.

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


@override
void initState() {
 super.initState();
 _scrollController = ScrollController();
 _textController = TextEditingController();
 _tabController = TabController(length: 3, vsync: this);
}

@override
void dispose() {
 _scrollController.dispose();
 _textController.dispose();
 _tabController.dispose();
 super.dispose();
}

정리 대상: TextEditingController, ScrollController, AnimationController, TabController, Timer, StreamSubscription. 규칙은 간단하다 - 내가 만든 건 내가 정리한다.

SwiftUI에서는 @StateObject가 알아서 해주는 부분인데, Flutter는 수동이다. 번거롭지만 정확히 뭘 정리하는지 보이니까 디버깅할 때는 오히려 낫다.

정리

주제	SwiftUI	Flutter
멀티탭	TabView + NavigationStack	IndexedStack + GlobalKey<NavigatorState>
뒤로가기 제어	기본 제공	PopScope (canPop + onPopInvokedWithResult)
접히는 헤더	ScrollView + .toolbar	CustomScrollView + SliverAppBar
리스트 in 스크롤	List + ScrollView	SliverList or shrinkWrap
상태관리	@State, @Published	setState, GetX (.obs + Obx)
의존성 주입	@EnvironmentObject	Get.put() / Get.find()
다크모드	@Environment(.colorScheme)	InheritedWidget + context extension
생명주기 정리	@StateObject 자동	dispose에서 수동 정리
애니메이션	.transition + .animation	flutter_animate or AnimationController

전체적으로 SwiftUI 대비 보일러플레이트가 확실히 많다. 특히 네비게이션 직접 관리하는 부분이랑 dispose 수동 정리가 번거로운데, 그만큼 코드에 마법이 없어서 흐름 파악은 더 쉬운 것 같다. GetX를 쓰면 StatelessWidget만으로도 거의 다 되니까 익숙해지면 개발 속도가 꽤 빨라진다.

다음 Ch03에서는 Dart 문법을 좀 더 깊게 파볼 예정이다.