지난 글에서 폴더를 data와 ui로 나눴다. 이번엔 그 안에 무엇을 담는지를 다룬다. 먼저 나누지 않은 모습부터 보자. 화면 하나가 서버 요청, 파싱, 상태 관리를 전부 하는 코드다.

class _UserPageState extends State<UserPage> {
  List<User> users = [];
  bool isLoading = true;

  @override
  void initState() {
    super.initState();
    load();
  }

  Future<void> load() async {
    final response = await Dio().get('https://example.com/api/users'); // 화면이 서버를 직접 부름
    final list = response.data as List;
    setState(() {
      users = list.map((e) => User.fromJson(e as Map<String, dynamic>)).toList();
      isLoading = false;
    });
  }

  @override
  Widget build(BuildContext context) { /* ... */ }
}

돌아가긴 한다. 하지만 이런 일들이 생긴다.

• 화면을 시험하려면 실제 서버가 필요하다. 서버가 꺼져 있거나 인터넷이 없으면 화면을 만들다 말고 멈춘다
• 같은 사용자 목록을 다른 화면도 필요로 하면 이 코드를 복사해서 붙인다. 서버 주소가 바뀌면 복사한 곳을 전부 고쳐야 한다
• 화면 파일에 네트워크, 파싱, 상태, 그리기가 한꺼번에 섞여서 한 줄을 고칠 때 무엇이 깨질지 알기 어렵다

원인: 하나의 클래스가 너무 많은 책임을 지고 있다

화면(UserPage)의 일은 "상태를 받아서 그리는 것"뿐이어야 한다. 데이터를 어디서 어떻게 가져오는지는 화면이 알 필요가 없다. 책임을 나누는 방법으로 Flutter 공식 앱 아키텍처 가이드는 앱을 UI 계층과 데이터 계층으로 나누고, 각각을 둘로 쪼개라고 안내한다.

네 가지 역할

• View(UI 계층): 상태를 받아서 화면에 그린다. 사용자 입력을 ViewModel에 넘긴다. 위젯이다
• ViewModel(UI 계층): 화면에 필요한 상태를 들고, 데이터를 화면용으로 바꾸고, 사용자 동작을 처리한다. Cubit이나 Riverpod의 Notifier가 맡는 자리다
• Repository(데이터 계층): 한 종류의 데이터에 대한 단일 진실 공급원이다. 데이터가 어디서 오든(서버, 캐시, 로컬 DB) 화면은 Repository만 본다
• Service(데이터 계층): 서버 API나 플랫폼 기능 같은 외부 데이터 소스 하나를 감싸는 얇은 클래스다. 상태를 갖지 않는다

공식 가이드가 정한 짝도 있다. 앱의 데이터 종류마다 Repository 하나, 데이터 소스마다 Service 하나를 두고, 한 Repository가 여러 Service를 쓸 수 있다. 그리고 View와 ViewModel은 기능 하나당 한 쌍으로 만든다.

View  →  ViewModel  →  Repository  →  Service
(화면)    (화면의 상태)   (데이터의 주인)   (서버 호출)

화살표는 한 방향이고 이웃한 계층끼리만 말한다. View가 Service를 직접 부르면 앞에서 본 "화면이 서버를 직접 부르는" 코드로 돌아가 버린다.

해결: 계층별로 코드를 나눈다

이 글의 User는 id와 name만 가진 단순한 모델이라고 가정한다.

Service: 서버 호출만 한다

class UserApiService {
  final Dio _dio;
  UserApiService(this._dio);

  Future<List<dynamic>> fetchUsers() async {
    final response = await _dio.get('/users');
    return response.data as List<dynamic>; // 파싱은 하지 않고 JSON 그대로
  }
}

Repository: 데이터를 모델로 바꾸고 화면에 약속한다

공식 가이드는 Repository를 추상 클래스로 먼저 정의하라고 권한다. 그러면 개발용, 테스트용 등 서로 다른 구현을 끼워 넣을 수 있다. 상속 글에서 본 implements가 여기서 쓰인다.

abstract class UserRepository {
  Future<List<User>> getUsers();
}

class UserRepositoryImpl implements UserRepository {
  final UserApiService _service;
  UserRepositoryImpl(this._service);

  @override
  Future<List<User>> getUsers() async {
    final json = await _service.fetchUsers();
    return json.map((e) => User.fromJson(e as Map<String, dynamic>)).toList();
  }
}

UserRepository는 "사용자 목록을 달라"는 약속(껍데기)만 정하고, UserRepositoryImpl이 실제로 서버에서 가져온다. 시험용 가짜 구현도 같은 약속을 따른다.

class FakeUserRepository implements UserRepository {
  @override
  Future<List<User>> getUsers() async => [
        User(id: 1, name: '홍길동'),
        User(id: 2, name: '김철수'),
      ];
}

ViewModel: 화면의 상태를 들고 있다

Riverpod을 쓰고 있으니 AsyncNotifier가 ViewModel 역할을 한다. 로딩, 데이터, 에러 상태를 AsyncValue가 이미 가지고 있어서 직접 만들 필요가 없다.

class UserListViewModel extends AsyncNotifier<List<User>> {
  @override
  Future<List<User>> build() {
    return ref.watch(userRepositoryProvider).getUsers(); // 처음 상태
  }

  Future<void> refresh() async {
    ref.invalidateSelf(); // 다시 불러오기
    await future;
  }
}

final userListViewModelProvider =
    AsyncNotifierProvider<UserListViewModel, List<User>>(UserListViewModel.new);

build()가 처음 값을 만든다. 이때 서버를 직접 부르지 않고 Repository를 거친다. 다시 불러오기(refresh)처럼 사용자 동작에 대한 처리도 ViewModel에 둔다.

조립: 누가 누구를 쓰는지 연결한다

final dioProvider = Provider<Dio>(
  (ref) => Dio(BaseOptions(baseUrl: 'https://example.com/api')),
);

final userApiServiceProvider = Provider<UserApiService>(
  (ref) => UserApiService(ref.watch(dioProvider)),
);

final userRepositoryProvider = Provider<UserRepository>(
  (ref) => UserRepositoryImpl(ref.watch(userApiServiceProvider)),
);

Dio를 Service에 넘기고, Service를 Repository에 넘기고, Repository를 ViewModel이 쓴다. 이렇게 필요한 걸 밖에서 넣어주는 구조를 의존성 주입이라고 부르고, 다음에서 따로 다룬다. 지금은 ref.watch(...)로 연결한다는 모양만 봐두자.

View: 상태를 그리기만 한다

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

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final users = ref.watch(userListViewModelProvider);

    return users.when(
      loading: () => const Center(child: CircularProgressIndicator()),
      error: (e, _) => ErrorView(
        message: errorMessage(e),
        onRetry: () => ref.read(userListViewModelProvider.notifier).refresh(),
      ),
      data: (list) => ListView.builder(
        itemCount: list.length,
        itemBuilder: (context, i) => ListTile(title: Text(list[i].name)),
      ),
    );
  }
}

화면 코드에 Dio도, fromJson도, 서버 주소도 없다. "상태를 받아 그리고, 버튼을 누르면 ViewModel에 알린다"만 남았다. ErrorView, errorMessage는 앞 글에서 만든 것을 그대로 쓴다.

효과: 가짜 Repository로 바꿔 끼우기

처음 겪었던 문제, 서버 없이는 화면을 만들 수 없다는 것이 풀린다.

void main() {
  runApp(
    ProviderScope(
      overrides: [
        userRepositoryProvider.overrideWithValue(FakeUserRepository()),
      ],
      child: const MyApp(),
    ),
  );
}

overrideWithValue는 userRepositoryProvider가 돌려줄 값을 가짜로 바꿔 끼운다. 서버가 없어도 FakeUserRepository의 두 사람이 화면에 뜬다. 같은 방식으로 테스트에서도 가짜를 넣을 수 있다. 공식 가이드도 Service, Repository, ViewModel 클래스마다 단위 테스트를 쓰라고 권하는데, 계층이 나뉘어 있어야 가능한 일이다.

삽질 포인트: ViewModel에 BuildContext를 넣고 싶어진다

저장이 끝나면 스낵바를 띄우고 싶어서 ViewModel 함수에 BuildContext를 넘기는 코드를 쓰기 쉽다. 하지만 BuildContext는 위젯 트리에서의 위치이고, ViewModel이 화면에 붙어버리면 시험하기 어렵고 await 뒤에 화면이 사라졌을 때 문제가 된다. 화면을 그리는 일(스낵바, 이동)은 View가 하고, ViewModel은 "저장이 끝났다"는 상태나 결과만 알린다. View가 그 상태를 보고 스낵바를 띄운다.

또 하나, Repository가 사용자 목록 캐시를 들고 있다면 "서버에서 새로 받을지, 캐시를 쓸지"를 정하는 일도 Repository의 책임이다. ViewModel이 Service를 우회해서 직접 부르는 순간 이 규칙이 깨진다.

Android, iOS와 비교하면

// Kotlin - Android 공식 아키텍처
class UserRepository(private val api: UserApi) {
    suspend fun getUsers(): List<User> = api.users().map { it.toUser() }
}

class UserViewModel(private val repo: UserRepository) : ViewModel() {
    val state = MutableStateFlow<UiState>(UiState.Loading)
}

// Swift - protocol로 Repository 추상화
protocol UserRepository {
    func getUsers() async throws -> [User]
}

@Observable class UserViewModel {
    var users: [User] = []
    init(repo: UserRepository) { self.repo = repo }
}

• View: Flutter 위젯 / Compose @Composable / SwiftUI View
• ViewModel: Flutter Notifier, Cubit / Android ViewModel / SwiftUI @Observable 클래스
• Repository: 세 곳 모두 같은 이름, 같은 역할(데이터의 단일 출처)
• Service: Flutter Service / Android의 DataSource, Retrofit 인터페이스에 가까움 / iOS API 클라이언트
• 추상화: Flutter abstract class와 implements / Kotlin interface / Swift protocol

Android의 공식 아키텍처와 구조가 거의 같다. Flutter 가이드의 Service가 안드로이드의 데이터 소스(Retrofit API 인터페이스 등)에 가깝다고 보면 이해가 빠르다. Swift의 protocol로 Repository를 추상화하는 것도 오늘 쓴 abstract class + implements와 같은 발상이다.

정리

• 화면이 서버 호출, 파싱, 상태를 모두 하면 시험하기 어렵고 같은 코드가 복사되므로, 책임을 View, ViewModel, Repository, Service로 나눈다
• View는 상태를 그리기만 하고, ViewModel은 화면의 상태와 사용자 동작을 맡으며, Repository는 한 종류 데이터의 단일 출처이고, Service는 외부 데이터 소스 하나를 감싼다
• 이웃한 계층끼리만 대화하고, View가 Service를 직접 부르지 않는다
• Repository는 추상 클래스로 약속을 먼저 정하고, 실제 구현과 가짜 구현을 implements로 바꿔 끼운다
• Riverpod에서는 AsyncNotifier가 ViewModel 역할을 하고 로딩, 데이터, 에러를 AsyncValue가 가지고 있다
• 스낵바나 화면 이동 같은 화면 일은 ViewModel이 아니라 View가 하고, BuildContext를 ViewModel에 넘기지 않는다

다음 글에서는 계층을 서로 연결하는 의존성 주입(get_it, Riverpod)을 다뤄보겠다.