지난 글에서 Provider로 상태를 공유해봤다. 작은 앱에서는 충분한데, 앱이 커지면 Provider가 가진 약점이 하나씩 드러난다. 이번엔 그 약점을 먼저 확인하고, 그걸 보완한 Riverpod으로 같은 카운터를 만들어보자. 이 글은 flutter_riverpod 3.x 기준이다.

Provider의 약점 세 가지

먼저 지난 글에서 이미 한 번 겪은 일이다.

final count = context.watch<CounterModel>().count; // Provider를 걸어두지 않았다면?

이 코드는 컴파일이 된다. CounterModel을 걸어두지 않았어도 에디터는 아무 말이 없고, 앱을 실행해서 그 화면에 들어간 순간 ProviderNotFoundException이 터진다. Provider는 값을 CounterModel이라는 타입으로 찾기 때문에, 있는지 없는지를 컴파일러가 미리 알 수 없다.

두 번째는 context가 꼭 필요하다는 점이다.

// 위젯이 아닌 곳에서 CounterModel을 읽고 싶다면?
void saveCount() {
  // context가 없는데 어떻게 읽지?
}

context.read는 위젯 트리 안의 위치에서만 쓸 수 있다. 위젯이 아닌 일반 함수나 다른 모델 안에서 값을 읽으려면 context를 일일이 넘겨줘야 한다.

세 번째는 같은 타입의 값을 둘 이상 걸어둘 수 없다는 점이다. Provider가 타입으로 찾으니, int 값을 두 개 걸어도 가까운 쪽 하나만 보인다. 두 개의 카운터가 필요하면 각각 다른 클래스로 감싸야 한다.

해결: Riverpod - 타입이 아니라 변수로 찾는다

Riverpod은 Provider를 만든 사람이 같은 문제를 풀려고 새로 만든 라이브러리다. 설치부터 한다.

flutter pub add flutter_riverpod

값을 final 변수로 전역에 선언한다.

import 'package:flutter_riverpod/flutter_riverpod.dart';

final counterProvider = NotifierProvider<Counter, int>(Counter.new);

class Counter extends Notifier<int> {
  @override
  int build() => 0; // 처음 값

  void increment() => state++;
}

한 줄씩 보면 이렇다.

• Notifier<int>: 값의 타입이 int인 상태 관리자다. 지난 글의 ChangeNotifier와 비슷한 자리다.
• build(): 처음 값을 돌려준다. 여기서 0을 돌려주면 처음 상태가 0이다.
• state: 지금 값이다. 값을 새로 대입하면(state++) 자동으로 구독자에게 알려진다. notifyListeners()를 부를 필요가 없다.
• NotifierProvider<Counter, int>(Counter.new): 이 Notifier를 만들어서 counterProvider라는 변수로 걸어둔다. Counter.new는 생성자를 값처럼 넘기는 문법이다.

앱 맨 위에는 ProviderScope를 한 번 걸어둔다. Riverpod의 값들이 이 안에 보관된다.

void main() {
  runApp(const ProviderScope(child: MyApp()));
}

화면에서는 StatelessWidget 대신 ConsumerWidget을 쓰고, build가 ref를 하나 더 받는다.

class CountText extends ConsumerWidget {
  const CountText({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final count = ref.watch(counterProvider); // 값을 읽고 구독
    return Text('$count');
  }
}

class PlusButton extends ConsumerWidget {
  const PlusButton({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    return ElevatedButton(
      onPressed: () => ref.read(counterProvider.notifier).increment(),
      child: const Text('+1'),
    );
  }
}

ref.watch(counterProvider)가 지금 값(int)을 돌려주고, 값이 바뀌면 이 위젯을 다시 그린다. 값을 바꾸는 함수를 부를 땐 ref.read(counterProvider.notifier)로 Counter 객체 자체를 꺼내서 increment()를 호출한다.

왜 약점이 사라지나

• 컴파일 때 알 수 있다: counterProvider는 변수라서, 이름을 틀리거나 지운 변수를 쓰면 에디터가 바로 빨간 줄을 친다. ProviderNotFoundException이 실행 중에 터지는 일이 없다.
• context가 필요 없다: ref만 있으면 읽는다. 다른 provider 안에서도 ref로 읽을 수 있어서, 값끼리 서로 의존하는 구조가 쉽다.
• 같은 타입도 여러 개 가능하다: 변수 이름으로 찾으니 int provider를 몇 개든 만들 수 있다.

삽질 포인트 1: 콜백 안에서 ref.watch를 쓰면 조용히 틀린다

onPressed: () {
  final count = ref.watch(counterProvider); // 여기서 문제
  print(count);
},

이 코드는 에러 없이 돌아가서 더 위험하다. watch는 구독하는 동작인데 버튼 콜백은 build가 아니라서, 의도와 다르게 동작한다. 지난 글과 같은 규칙이다. build 안에서는 ref.watch, 버튼 같은 이벤트 안에서는 ref.read를 쓴다.

삽질 포인트 2: ProviderScope를 빼먹으면 시작부터 에러

void main() {
  runApp(const MyApp()); // ProviderScope가 없음
}

ConsumerWidget이 값을 찾을 곳이 없어서 ProviderScope가 없다는 취지의 에러가 난다. ProviderScope는 앱 맨 위에서 한 번만 감싸면 된다.

ConsumerWidget이 번거로울 때

StatefulWidget에서 쓰려면 ConsumerStatefulWidget을, 위젯 하나 안에서 일부만 구독하려면 Consumer를 쓴다.

Consumer(
  builder: (context, ref, child) {
    final count = ref.watch(counterProvider);
    return Text('$count');
  },
)

역할은 같고 위젯을 만드는 방식만 다르다. 처음에는 ConsumerWidget만 알아도 된다.

값의 종류는 Provider 하나가 아니다

NotifierProvider는 값이 바뀌는 상태에 쓴다. 바뀌지 않는 값이나 서버 응답은 다른 종류를 쓴다.

• Provider: 바뀌지 않는 값, 다른 provider로 계산한 값
• NotifierProvider: 값이 바뀌고, 바꾸는 함수도 필요할 때
• FutureProvider: 서버 요청처럼 나중에 도착하는 값 (Future)
• AsyncNotifierProvider: 나중에 도착하는 값에 바꾸는 함수까지 필요할 때

예전 튜토리얼에는 StateProvider, StateNotifierProvider도 많이 보이는데, 새로 시작한다면 NotifierProvider를 기준으로 배우면 된다. 비동기 쪽은 데이터를 다루는 단계에서 AsyncValue와 함께 다시 본다.

3.0부터는 실패한 provider를 기본으로 다시 시도한다. 서버 요청이 실패했을 때 자동으로 재시도가 일어나서 놀랄 수 있으니 기억해 두자.

Provider와 Riverpod 비교

• 값을 찾는 방법: Provider는 타입 / Riverpod은 변수
• 없을 때: Provider는 실행 중 ProviderNotFoundException / Riverpod은 컴파일 때 에디터가 알려줌
• context 필요 여부: Provider는 필요 / Riverpod은 ref만 있으면 됨
• 값을 바꿔 알리기: Provider는 notifyListeners() / Riverpod은 state에 대입
• 위젯: Provider는 StatelessWidget + context.watch / Riverpod은 ConsumerWidget + ref.watch
• 설정: Provider는 위젯 트리에 걸어둠 / Riverpod은 변수 선언 + 맨 위 ProviderScope

Compose, SwiftUI와 비교하면

// Compose - Hilt ViewModel
@HiltViewModel
class CounterViewModel @Inject constructor() : ViewModel() {
    private val _count = MutableStateFlow(0)
    val count = _count.asStateFlow()
    fun increment() { _count.value++ }
}

// SwiftUI - @Observable (iOS 17+)
@Observable
class CounterModel {
    var count = 0
    func increment() { count += 1 }
}

• 상태를 가진 클래스: Flutter Notifier / Compose ViewModel / SwiftUI @Observable 클래스
• 값이 바뀌면 알림: Flutter state 대입 / Compose StateFlow 값 변경 / SwiftUI 프로퍼티 변경이 자동으로
• 가져오는 방법: Flutter ref.watch(provider) / Compose viewModel() + collectAsState / SwiftUI 프로퍼티를 직접 읽기
• 의존성 주입: Flutter는 ref가 provider끼리 연결 / Compose는 Hilt / SwiftUI는 환경이나 이니셜라이저로 전달

Compose에서 Hilt가 ViewModel을 만들어서 넣어주는 역할을, Flutter에서는 Riverpod이 ref로 provider끼리 연결하며 대신한다. 그래서 Riverpod은 상태 관리와 의존성 주입을 함께 해결하는 도구라고도 한다.

정리

• Provider는 값을 타입으로 찾아서 걸어두지 않았을 때 실행 중에야 에러가 나고, context가 필요하고, 같은 타입을 여러 개 둘 수 없다
• Riverpod은 값을 final 변수로 전역에 선언하고, 앱 맨 위에 ProviderScope를 한 번 감싼다
• 바뀌는 값은 Notifier의 build()가 처음 값을 돌려주고 state에 대입해서 바꾸며, notifyListeners()가 필요 없다
• 위젯은 ConsumerWidget으로 만들고 build 안에서는 ref.watch, 버튼 같은 이벤트 안에서는 ref.read(provider.notifier)를 쓴다
• 서버에서 오는 값은 FutureProvider, 바뀌지 않는 값은 Provider를 쓴다

다음 글에서는 또 다른 선택지인 Bloc/Cubit을 살펴보고, 프로젝트 규모와 팀에 맞춰 상태 관리를 고르는 기준을 정리하겠다.