프로덕션 Flutter 앱에서의 State Management: 규모 확장 시 실제로 지연되는 요인

Source: Dev.to

실제 Flutter 프로젝트에서의 상태 관리 여정

상태 관리는 Flutter 프로젝트의 첫 주에는 거의 긴급하게 느껴지지 않습니다.
화면을 빠르게 조합하고, setState가 작동하며, Provider나 Riverpod을 오후에 연결하고, 시뮬레이터에서 데모가 멋지게 보입니다.

전환점

4~5개월 차가 되면 상황이 달라집니다:

• 두 번째 개발자가 합류합니다.
• 오프라인 친화적인 흐름, 푸시 알림, 그리고 더 깊은 API 통합이 추가됩니다.
• 네비게이션 스택이 더 복잡해집니다.
• 같은 버그가 두 개의 서로 다른 화면에서 나타납니다.

갑자기 초기에 내린 선택들이 곳곳에 흩어져 있고, 이를 변경하는 것이 비용이 많이 드는 일처럼 느껴집니다.

프로덕션 앱에서 배운 점

이것은 프레임워크 순위가 아닙니다. 실제 사용자, 실제 릴리스, 그리고 실제 팀원이 등장했을 때 우리가 본 내용입니다.

Flutter는 아키텍처 결정을 미루기 쉽게 합니다. 위젯을 빠르게 조합할 수 있고, 핫‑리로드가 상황이 얼마나 복잡해지고 있는지 감추어 줍니다. 비동기 작업, 플랫폼 채널, 인증 흐름은 종종 첫 번째 스프린트 데모 이후에 등장합니다.

고통이 드러날 때쯤이면 상태가 다음과 같이 퍼져 있습니다:

• 부모 위젯
• Inherited Notifier
• 임시 서비스 싱글톤

리팩터링이 위험하게 느껴지는 이유는 어느 화면이 어떤 데이터를 소유하고 있는지 아무도 확신하지 못하기 때문입니다.

“잘못된 라이브러리를 선택했다”는 말을 하기 전에 나타나는 경고 신호

• 만들기는 빠르지만 변경하기는 고통스러운 화면
• 네비게이션 팝/푸시 사이클 후 중복된 API 호출
• 다른 위젯‑트리 브랜치에서 다시 나타나는 버그 수정
• 한 플랫폼 빌드에서만 재현되는 QA 보고서

이러한 문제는 Flutter에만 국한된 것이 아니라, UI 상태, 도메인 상태, API‑기반 데이터가 명확한 경계 없이 뒤섞일 때 발생하는 일반적인 현상입니다.

프로덕션 현실

우리 클라이언트 앱에서 “프로덕션 규모”는 보통 다음을 의미했습니다:

1. 더 많은 기능이 첫 번째 스토어 출시 이후에 배포됨
2. 더 많은 개발자가 동일한 모듈을 다룸
3. 더 많은 엣지 케이스가 느린 네트워크, 오래된 토큰, 부분적인 오프라인 동작과 관련됨
4. Post‑MVP 반복은 아직 App Store와 Google Play 검토를 통과해야 하는 코드베이스에서 진행됨

그때 상태 관리가 튜토리얼 주제가 아니라 배달 제약 조건이 됩니다.

로컬 상태 – 여전히 의미가 있을 때

로컬 상태는 독립적인 UI 관심사에 적합합니다:

• 토글
• 폼 필드 포커스
• 애니메이션 컨트롤러
• 짧은 기간의 모달 흐름

우리는 이러한 경우에 여전히 사용합니다.

문제: 비즈니스 로직이 StatefulWidget 클래스에 스며들고 있습니다.
데이터를 가져오고, 오류를 처리하며, 한 화면의 setState 블록에서 네비게이션을 조정하는 것은 해당 화면을 나중에 다른 기능들이 필요로 하는 동작의 숨겨진 소유자로 만들게 됩니다.

테스트 영향

레이아웃, 부수 효과, API 호출을 혼합한 위젯은 iOS와 Android CI 빌드 모두에서 테스트하기 어려웠습니다. 뷰 로직을 데이터 흐름과 분리하면(작은 단계라도) 회귀를 더 쉽게 잡을 수 있었습니다.

경험 법칙: 다른 화면이 두 스프린트 이내에 이 데이터를 필요로 할 수 있다면, 로컬 setState는 아마도 너무 국한된 것입니다.

스택의 진화

Riverpod vs. Bloc – 우리에게 도움이 된 점

• Riverpod – 명시적인 프로바이더와 오버라이드 덕분에 대규모 앱에서 의존성을 쉽게 파악할 수 있었습니다.
• Bloc – 이벤트/상태 분리를 통해 복잡한 흐름(인증 새로 고침, 페이지네이션 리스트, 다단계 폼)을 코드 리뷰 시 명확히 할 수 있었습니다.

우리는 한 번에 모든 것을 마이그레이션하지 않았습니다; 의도적이고 문서화된 경우 혼합 패턴도 괜찮습니다.

재사용 가능한 패턴 (Riverpod 예시)

// orders_provider.dart
final ordersProvider = FutureProvider.autoDispose((ref) async {
  final repo = ref.watch(orderRepositoryProvider);
  return repo.fetchOrders();
});

문법 자체가 중요한 것이 아니라, 로드, 성공, 실패가 위젯의 initState 안에 존재하는 것이 아니라 예측 가능한 위치에 있다는 점이다.

Riverpod 문서와 Bloc 라이브러리 문서를 참고하면 더 깊이 이해할 수 있습니다. 우리는 이를 정체성이 아니라 도구로 다룹니다.

기능별 상태 스코핑

앱 상태를 하나의 전역 스토어에 넣으려고 하면 금방 관리가 어려워집니다. 우리에게 더 효과적이었던 방법은 기능별로 상태를 스코핑하고 레이어를 구분하는 것이었습니다:

리포지토리 레이어는 백엔드 통합을 위한 안정적인 경계가 되었습니다. 위젯과 알림자는 트리 전체에 흩어져 있던 원시 HTTP 클라이언트가 아니라 리포지토리에 의존했습니다. 엔드포인트가 변경될 때, 우리는 다섯 개 화면을 수정하는 대신 한 곳만 고쳤습니다.

글로벌 싱글톤 (세션, 환경 설정, 분석)은 여전히 존재하지만, 기능 로직이 위치하는 곳은 아닙니다.

해피‑패스‑전용 UI에서 안정적인 프로덕션 앱으로

해피 패스만을 포함한 데모를 배포하는 것이 프로토타입을 가장 빠르게 만들 수 있는 방법이지만, 프로덕션 앱을 안정화하는 가장 느린 방법이기도 합니다.

누락된 상태 모델이 시간을 낭비하게 함

• API가 빈 리스트를 반환했을 때 무한 스피너가 표시됨
• 새로 고침 실패 후 오래된 데이터가 표시됨
• 중복 요청을 발생시키는 재시도 버튼
• 네비게이션 시 사라지고 다시 나타나지 않는 오류 메시지

비동기 작업을 명시적으로 만들기

비동기 작업을 명시적인 단계(loading, success, empty, error)로 모델링한 뒤, 테스트가 유용해지고 지원 티켓이 감소했습니다.

• Riverpod – AsyncValue가 이 패턴을 따르도록 유도합니다.
• Bloc – sealed 상태 클래스가 동일한 역할을 합니다.

Provider를 사용할 때도 Resource와 같은 작은 래퍼 타입(또는 유사한 것)을 사용하면 null을 “아직 로딩 중”으로 취급하는 것보다 더 좋습니다.

Source:

오프라인‑인접 동작

전체 오프라인‑퍼스트 아키텍처가 첫 날에 필요하지는 않지만, 사용자가 네트워크가 느리거나 사용할 수 없게 되는 상황을 마주하기 전에 UI가 무엇을 보여줄지 결정해야 합니다.

TL;DR

1. 작게 시작하고 MVP 속도를 위해 로컬 setState와 Provider를 사용합니다.
2. Riverpod/Bloc을 도입해 비동기 경계와 테스트 가능성이 중요해지면 전환합니다.
3. 기능별로 상태를 구분합니다 (UI, 도메인, 원격) 그리고 레포지토리 시임을 유지합니다.
4. 기능별 혼합 패턴을 문서화하여 의도치 않은 변화를 방지합니다.
5. 비동기 단계들을 명시적으로 모델링해 버그를 줄이고 테스트 가능성을 높입니다.
6. 오프라인 UI를 조기에 계획하되, 전체 오프라인 스택은 나중에 추가해도 됩니다.

이 교훈들은 Flutter 프로젝트를 실제로 배포하고 유지보수하면서 얻은 것이며, 단순히 패키지만 비교한 결과가 아닙니다. 여러분의 스택이 다를 수는 있지만, 트레이드‑오프는 비슷할 것입니다.

프로덕션 Flutter 앱에서 배운 상태 관리 및 온보딩 교훈

“한 사람만 이해하는 영리한 추상화는 금방 구식이 된다.”

우리는 위젯 트리 깊숙이 숨겨진 리스너들, 비동기 간격 뒤에 나타나는 마법 같은 context.read 호출, 그리고 절대 사라지지 않은 “임시” 전역 노티파이어들을 보았습니다. 리팩터링은 조용히 깨졌고, 새로운 개발자들은 녹색 빌드를 가장 빠르게 얻을 수 있는 경로였기 때문에 잘못된 패턴을 그대로 복제했습니다.

온보딩에 도움이 된 것

• 예측 가능한 폴더 구조
  features/orders/data
features/orders/presentation

• 기능당 하나의 문서화된 상태 접근 방식

• 테스트 전략

  • UI 경계 사례를 위한 위젯 테스트
  • 핵심 흐름(로그인, 결제, 제출)을 위한 통합 테스트

  통합 테스트는 유지 관리 비용이 더 많이 들지만, 위젯 테스트만으로 놓친 인증 및 결제 경로의 네비게이션 회귀를 방지하는 데 큰 도움이 되었습니다.

Flutter 통합 테스트 문서는 지속할 수 없는 커버리지를 약속하기 전에 반드시 읽어볼 가치가 있습니다.

Architectural Checklist (First Six Weeks of a Typical Client Project)

1. Scope state by feature, not by screen count alone.
2. Define async contracts early – loading, error, empty, success (and when to retry).
3. Pick one primary pattern per layer and stick to it unless there is a written reason to diverge.
4. Document where state lives before the team doubles in size.
5. Plan for post‑MVP growth before the first App Store or Play Store submission

None of that blocks an MVP. It prevents the MVP from becoming a rewrite trigger at month six.

아키텍처 체크리스트 (전형적인 클라이언트 프로젝트의 첫 6주)

1. 기능별로 상태 범위 지정, 화면 수만으로는 하지 않기.
2. 비동기 계약을 일찍 정의 – 로딩, 오류, 빈 상태, 성공 (그리고 재시도 시점).
3. 레이어당 하나의 주요 패턴 선택하고, 서면으로 다른 이유가 없는 한 그대로 유지.
4. 팀 규모가 두 배가 되기 전에 상태가 어디에 존재하는지 문서화.
5. 첫 App Store 또는 Play Store 제출 전에 MVP 이후 성장 계획 수립

그 어느 것도 MVP를 방해하지 않는다. 6개월 차에 MVP가 리팩터링 트리거가 되는 것을 방지한다.

주요 요점

• 상태 관리는 팀 계약이다 – 라이브러리는 이를 구현하는 방법일 뿐이다.
• 튜토리얼은 개별적으로 명확성을 최적화하지만, 클라이언트 작업은 시간에 따른 변화(새 엔드포인트, 새로운 팀원, 새로운 스토어 빌드, 새로운 플랫폼 특성)를 최적화한다.
• Riverpod, Bloc, Provider는 계속 진화할 것이며, 변하지 않는 것은 경계, 비동기 동작, 그리고 다음 개발자가 레포를 열었을 때 가정할 내용에 주의를 기울이는 것이다.

Discussion Prompt

Flutter 앱을 데모 단계에서 벗어나면 가장 먼저 어떤 것이 깨졌나요?
어떤 교훈이 여러분의 경험과 맞닿아 있는지 궁금합니다.

TL;DR for Flutter MVP Planners

모바일 MVP를 초기에 스코핑하면(상태 경계, 비동기 계약, 스토어 준비) 나중에 고통을 줄일 수 있습니다.