setState vs Provider, 무엇이 다를까?

Flutter로 첫 UI를 만들 때는 대부분 setState()만으로도 충분합니다. 하지만 앱이 커지고 여러 화면에서 같은 데이터를 써야 할 때, 코드가 점점 얽히는 경험을 하셨을 거예요. 그 지점을 깔끔하게 넘어가도록 도와주는 대표 솔루션이 Provider입니다. 오늘은 두 방법의 원리·탄생 배경·실전 사용처를 한눈에 정리해 보겠습니다.

---

1. setState: 가장 원초적인 상태 관리

setState(() { … })는 해당 StatefulWidget과 그 하위 트리 전체를 다시 빌드해 UI를 갱신합니다. 구현이 간단해 빠르게 화면을 그려 볼 때 탁월하지만,

• 상태가 여러 위젯으로 퍼질수록 prop drilling(부모→자식으로 값 전달)이 복잡해지고,
• 작은 변화에도 넓은 영역을 리빌드해 성능 저하가 나타나며,
• 전역(로그인 정보, 다크모드 설정 등)으로 쓰기엔 한계가 있습니다.

---

2. Provider: InheritedWidget을 감싼 ‘편의 레이어’

Provider는 Flutter 팀 멤버 Rémi Rousselet가 만든 패키지로, InheritedWidget + ChangeNotifier를 사용해 필요한 위젯만 선택적으로 다시 그립니다.

• ChangeNotifierProvider로 비즈니스 로직을 UI와 분리하고,
• context.watch / context.read로 의존성을 주입하며,
• 테스트 코드에서도 손쉽게 mock 객체를 끼워 넣을 수 있습니다.

---

3. 왜 Provider가 등장했을까?

초기 Flutter 커뮤니티는 setState만으로도 충분하다고 여겼지만, 앱 규모가 커지자 “상태를 어디에 두고 어떻게 공유할 것인가”가 화두가 됐습니다. 그때 등장한 InheritedWidget은 Boilerplate가 많아 접근 장벽이 높았고, 이를 감싸 코드를 간결하게 만든 것이 Provider입니다. 즉, “상태를 전역으로 올리되 코드 가독성과 성능까지 잡자”가 탄생 배경이었습니다.

---

4. 언제 setState, 언제 Provider를 쓸까?

• setState로 충분한 순간
  • 단일 화면·작은 위젯에서만 쓰는 일회성 UI 상태 (예: 버튼 토글, 텍스트 필드 포커스).
  • 빠른 프로토타이핑이나 학습용 샘플 앱.
• Provider가 유리한 순간
  • 로그인 상태, 테마, 장바구니처럼 여러 화면이 함께 쓰는 데이터.
  • 복수의 비동기 소스(API, DB, 로컬 저장소 등)를 한 객체에서 조합·캐싱해야 할 때.
  • 테스트·유지보수를 중시하는 팀 개발(의존성 주입 & mock 교체가 용이).