Flutter 개발을 시작하면 가장 먼저 마주하는 난관이 바로 ‘상태 관리’입니다. 처음에는 쉽고 빠른 GetX에 매료되기 쉽지만, 프로젝트 규모가 커질수록 아키텍처의 견고함에 대해 고민하게 됩니다. 오늘은 제가 실제 대규모 프로젝트를 리팩토링하며 느꼈던 상태 관리 라이브러리 선택의 기준과 그 고찰을 공유합니다.
1. GetX의 편리함이 주는 독(Poison)
GetX는 Context 없이 어디서든 상태에 접근할 수 있다는 강력한 장점이 있습니다. 초기 개발 속도는 압도적이죠. 하지만 이것은 동시에 **의존성 추적을 어렵게 만듭니다.**
[그림 1] Provider의 구조적 접근 vs GetX의 자유로운 접근 비교
프로젝트가 커질수록 특정 상태가 어디서 변경되었는지 추적하기 힘들어졌고, 이는 곧 디버깅 지옥으로 이어졌습니다. 저는 ‘속도’보다 ‘예측 가능성’이 더 중요하다는 판단하에 Provider로의 전환을 결심했습니다.
2. Provider: Flutter의 철학을 따르는 가장 정석적인 방법
Provider는 Widget Tree의 계층 구조를 그대로 활용합니다. 이는 Flutter의 `InheritedWidget`을 래핑한 것으로, 프레임워크의 생명주기와 완벽하게 동기화됩니다.
// Provider를 활용한 선언적 상태 관리 예시
class CounterProvider with ChangeNotifier {
int _count = 0;
int get count => _count;
void increment() {
_count++;
notifyListeners(); // 상태 변경을 알림
}
}
// UI에서의 사용
Consumer<CounterProvider>(
builder: (context, provider, child) {
return Text('Count: ${provider.count}');
},
)
코드는 조금 더 길어질 수 있지만, 데이터의 흐름이 명확히 위에서 아래로 흐른다는 점에서 팀 단위 협업 시 코드 리뷰와 유지보수가 훨씬 수월해졌습니다.
3. 리팩토링을 통해 배운 것들
[문제 상황]
기존 GetX 기반 코드에서는 비즈니스 로직과 UI가 강하게 결합되어 있어 단위 테스트(Unit Test) 작성이 매우 까다로웠습니다.
[해결 전략]
Provider를 도입하면서 Logic 클래스(ViewModel)를 순수하게 분리했고, Mocking을 통한 테스트 가능성을 확보했습니다. 시스템의 안정성이 확보되자 기능 추가 시 발생하던 사이드 이펙트가 80% 이상 감소했습니다.
마치며
특정 라이브러리가 무조건 나쁘다는 것은 아닙니다. 하지만 **’유지보수 가능한 아키텍처’**를 고민한다면, 프레임워크의 원천 기술을 잘 활용하는 도구를 선택하는 것이 장기적으로 옳은 방향임을 깨달었습니다. 여러분의 선택은 무엇인가요?