작은 상태에는 작은 도구가 더 낫습니다

토글 하나에 얹혀 있던 전역 상태 코드

설정 화면에 알림 토글 스위치 하나를 붙이는 작업이었습니다.
정말 스위치 하나였는데, 저는 습관처럼 전역 provider부터 만들었습니다.
StateNotifierProvider를 선언하고, 상태를 담을 클래스를 만들고, on/off 메서드를 붙이고, 그걸 위한 파일을 따로 뺐습니다.
스위치 하나에 파일이 세 개 늘었습니다.

코드리뷰에서 질문 하나가 돌아왔습니다.
"이 토글 상태, 이 화면 밖에서 읽는 데가 있어요?" 잠깐 멈칫했습니다.
없었습니다.
저장은 스위치를 누르는 순간 바로 서버로 보냈고, 다른 화면은 그 값을 화면에 들고 있을 필요가 없었습니다.
그 질문 하나에, 제가 작은 상태에 큰 도구를 얹고 있었다는 게 드러났습니다.

큰 도구가 항상 안전한 건 아닙니다

전역 상태관리를 기본값으로 쓰면 마음이 편합니다.
나중에 어디서 필요해질지 모르니까, 일단 provider로 올려 두면 안전하다고 느낍니다.
"확장성"이라는 말로 스스로를 설득하기도 쉽고요.
그런데 이 토글은 "나중에"가 오지 않는 상태였습니다.
화면이 사라지면 같이 사라져도 되는, 이 화면만의 값이었습니다.

그런 값을 전역에 올리면 대가가 따라옵니다.
이 상태가 어디서 바뀌는지 추적할 범위가 앱 전체로 넓어집니다.
코드를 읽는 사람은 provider 이름을 보고 "이거 다른 화면에서도 건드리나?"를 한 번 확인해야 합니다.
정작 답은 "아니요, 이 스위치뿐인데요"인데도, 그 확인 비용은 코드를 읽을 때마다 듭니다.

리뷰어가 물었을 때 제가 잠깐 멈칫한 것도 그래서였습니다.
"밖에서 읽는 데 있어요?"라는 질문에 바로 "없어요"가 안 나왔거든요.
확인하려고 provider 이름을 검색해 봤는데, 결과는 제가 방금 만든 그 파일들뿐이었습니다.
아무도 안 읽는 값을 앱 전체가 볼 수 있는 자리에 올려 둔 거였죠.

// 이 화면만 쓰는 토글 하나 때문에 파일 세 개가 늘었습니다.
class NotifyToggle extends StateNotifier<bool> {
  NotifyToggle() : super(false);
  void toggle() => state = !state;
}
final notifyToggleProvider =
    StateNotifierProvider<NotifyToggle, bool>((ref) => NotifyToggle());

한 줄로 줄어든 스위치

리뷰어가 제안한 건 ValueNotifier 하나였습니다.
값 하나의 변화를 위젯에 전달하는 데는 이걸로 충분했습니다.
provider도, 상태 클래스도, 별도 파일도 필요 없었습니다.
화면 위젯 안에 값 하나를 두고, 그 값이 바뀌면 스위치가 다시 그려지게 하면 끝이었습니다.

final notifyOn = ValueNotifier(false);

ValueListenableBuilder<bool>(
  valueListenable: notifyOn,
  builder: (_, on, __) => Switch(
    value: on,
    onChanged: (v) {
      notifyOn.value = v;
      api.saveNotifyPref(v); // 저장은 바로 서버로
    },
  ),
)

파일 세 개가 한 줄과 위젯 하나로 줄었습니다.
읽는 사람이 "이 값 어디서 또 바뀌지"를 고민할 범위도 이 위젯 안으로 좁아졌고요.
PR을 다시 열어 보니, 제가 처음에 만들었던 상태 클래스와 provider 선언, 그걸 감싸던 파일이 통째로 지워지고 diff가 오히려 짧아져 있었습니다.
기능을 덜어낸 것도 아닌데 코드가 줄어드는 건, 애초에 안 필요한 걸 넣었다는 신호였겠죠.

물론 공짜는 아닙니다.
화면이 사라질 때 dispose에서 notifier를 정리해 주는 건 잊으면 안 됩니다.
(이것도 같은 리뷰에서 한 번 더 짚였습니다.
습관이 무섭습니다.) provider를 쓸 때는 프레임워크가 알아서 해 주던 정리를, 직접 도구를 들면 제 손으로 챙겨야 한다는 것도 이때 같이 배웠습니다.

그럼 Riverpod은 언제 쓰냐면

오해를 피하고 싶은 게, Riverpod이 과하다는 이야기가 아닙니다.
로그인한 사용자 정보처럼 여러 화면이 공유하는 값, 서버에서 받아와 여기저기서 읽는 데이터라면 저는 여전히 provider로 갑니다.
그런 값을 ValueNotifier로 화면 안에 숨기면 이번엔 반대 방향으로 아파집니다.
어느 화면이 그 값을 바꿨는지 추적이 안 되거든요.
화면 A에서 바꾼 값이 화면 B에 반영이 안 돼서, 아까 좋아요 카운트 때처럼 값이 갈라지는 거죠.

그러니까 이건 "작은 도구가 항상 옳다"는 이야기도 아닙니다.
토글에 전역을 얹은 것과, 공유 상태를 화면 안에 가두는 것은 방향만 반대일 뿐 같은 실수예요.
도구를 값의 크기에 맞추지 않은 것.

한동안은 상태관리라고 하면 provider 하나로 다 해결하려 했는데, 지금은 그게 오히려 게으른 기본값이었다는 생각이 듭니다.
화면 안에서만 사는 값에는 setState나 ValueNotifier, 여러 화면이 나눠 갖는 값에는 provider.
그 사이 어디쯤인지 잠깐 가늠하는 게, 나중에 값이 갈라지는 걸 막는 가장 싼 순간이더라고요.

결국 기준은 도구가 크냐 작냐가 아니라 값이 사는 범위였습니다.
그 뒤로 상태를 하나 만들 때, 큰 도구부터 꺼내는 대신 질문 하나를 먼저 합니다.
"이 값, 이 화면 밖에서 누가 읽나?" 아무도 안 읽으면 굳이 전역으로 올리지 않습니다.
다음에 토글을 붙일 땐, 파일을 늘리기 전에 그 질문부터 꺼낼 것 같습니다.

원문 기준

원문 기준: https://api.flutter.dev/flutter/foundation/ValueNotifier-class.html

원문 본 날짜: 2026-07-01.