지난 글에서 View, ViewModel, Repository, Service로 계층을 나눴다. 그런데 이 계층들을 누가 만들어서 연결하는지는 아직 얼버무렸다. 가장 쉬운 방법은 ViewModel 안에서 필요한 걸 직접 만드는 것이다.

class UserViewModel {
  final UserRepository repo = UserRepositoryImpl(
    UserApiService(
      Dio(BaseOptions(baseUrl: 'https://example.com/api')),
    ),
  ); // 필요한 걸 안에서 직접 만듦

  Future<List<User>> load() => repo.getUsers();
}

돌아간다. 하지만 이 UserViewModel을 시험하려고 가짜 Repository를 끼우려는 순간 막힌다. UserRepositoryImpl이 클래스 안에 박혀 있어서 바꿔 끼울 수가 없다. 사용자 화면이 둘이면 Dio도 둘 만들어져서 서버 주소 설정이 두 군데로 흩어지고, UserApiService가 생성자를 바꾸면 이걸 쓰는 모든 곳을 고쳐야 한다.

원인: 자기가 쓸 것을 자기가 만들고 있다

ViewModel이 UserRepositoryImpl이라는 구체적인 클래스를 직접 알고 만든다. 이러면 ViewModel과 그 구현이 단단히 붙어버린다. 해결의 핵심은 단순하다. 필요한 건 밖에서 받는다. 생성자 글에서 본 this.필드 문법 그대로다.

class UserViewModel {
  final UserRepository repo; // 어떤 구현인지 모른다. 약속(추상 클래스)만 안다
  UserViewModel(this.repo);

  Future<List<User>> load() => repo.getUsers();
}

이제 UserViewModel은 UserRepository라는 약속만 안다. 진짜가 올지 가짜가 올지는 만드는 쪽이 정한다. 이렇게 필요한 걸 밖에서 넣어주는 방식이 의존성 주입(Dependency Injection, DI)이다.

그런데 새로운 문제가 생긴다. UserViewModel(repo)를 만들려면 repo가 필요하고, repo를 만들려면 UserApiService가, 그걸 만들려면 Dio가 필요하다. 이 조립 과정을 어디에 쓸 것인가가 DI의 실제 고민이다. 두 가지 도구가 있다.

해결 1: get_it - 한 곳에 등록해두고 꺼내 쓴다

flutter pub add get_it

get_it은 서비스 로케이터다. 앱 시작 때 "이 타입이 필요하면 이렇게 만들어라"를 한 곳에 등록하고, 필요한 곳에서 꺼내 쓴다.

import 'package:get_it/get_it.dart';

final getIt = GetIt.instance;

void setupDependencies() {
  getIt.registerLazySingleton<Dio>(
    () => Dio(BaseOptions(baseUrl: 'https://example.com/api')),
  );
  getIt.registerLazySingleton<UserApiService>(
    () => UserApiService(getIt<Dio>()),
  );
  getIt.registerLazySingleton<UserRepository>(
    () => UserRepositoryImpl(getIt<UserApiService>()),
  );
  getIt.registerFactory<UserViewModel>(
    () => UserViewModel(getIt<UserRepository>()),
  );
}

void main() {
  setupDependencies(); // 앱이 시작되기 전에 한 번
  runApp(const MyApp());
}

필요한 곳에서는 getIt<타입>()으로 꺼낸다.

final viewModel = getIt<UserViewModel>();

getIt<UserViewModel>()을 부르면 UserViewModel을 만드는 데 필요한 UserRepository, UserApiService, Dio가 알아서 이어져서 만들어진다. 등록하는 곳에서 조립을 한 번 쓰면 끝이다.

등록 방식은 세 가지다

• registerSingleton<T>(T instance): 이미 만든 객체를 등록한다. 앱 내내 같은 객체를 쓴다. 등록하는 순간 이미 만들어져 있다
• registerLazySingleton<T>(() => ...): 처음 꺼낼 때 한 번 만들고 그 뒤로는 같은 객체를 쓴다. Dio, Repository처럼 앱 전체에서 하나면 되는 것에 알맞다
• registerFactory<T>(() => ...): 꺼낼 때마다 새로 만든다. 화면마다 따로 있어야 하는 ViewModel에 알맞다

registerSingleton과 registerFactory를 헷갈리는 실수가 가장 흔하다. registerSingleton은 함수가 아니라 만들어진 객체를 받는다.

getIt.registerSingleton<UserService>(() => UserService()); // 에러: 객체가 아니라 함수를 넘김
getIt.registerSingleton<UserService>(UserService());       // OK
getIt.registerLazySingleton<UserService>(() => UserService()); // 함수로 넘기려면 이쪽

삽질 포인트 1: 등록하지 않은 걸 꺼낸다

getIt<UserRepository>()를 부르는데 등록을 빠뜨렸다면 "등록되지 않았다"는 취지의 에러가 실행 중에 난다. Provider 글의 ProviderNotFoundException과 같은 유형으로, 컴파일러는 getIt<무엇이든>()이 맞는지 확인하지 못한다. 반대로 같은 타입을 두 번 등록하면 이미 등록되었다는 에러가 난다.

삽질 포인트 2: 시험에서 가짜로 바꾸려면 초기화부터

get_it은 앱 전체에서 하나만 있는 객체라서, 시험 하나가 등록한 걸 다음 시험이 이어받는다. 시험 전에 getIt.reset()으로 모두 비우고 가짜를 등록한다.

setUp(() async {
  await getIt.reset();
  getIt.registerSingleton<UserRepository>(FakeUserRepository());
  getIt.registerFactory<UserViewModel>(() => UserViewModel(getIt<UserRepository>()));
});

get_it의 한계: 의존성이 숨는다

get_it의 공식 설명은 "상태 관리 도구가 아니다"라고 못 박는다. 값을 꺼내는 것일 뿐, 값이 바뀌었을 때 화면을 다시 그려주지 않는다. 그래서 ChangeNotifier나 Cubit 같은 상태 관리와 같이 쓴다.

또 하나의 약점이 있다. UserViewModel(this.repo)처럼 생성자로 받으면 "이 클래스가 무엇을 필요로 하는지" 생성자만 봐도 알 수 있다. 그런데 클래스 안 어디서든 getIt<UserRepository>()를 부를 수 있어서, 이런 식으로 쓰면 의존하는 것이 코드 속에 숨는다. 이 방식은 생성자에서만 getIt을 쓰고, 클래스 안쪽에서는 받은 걸 쓰는 식으로 규칙을 정해두는 게 좋다.

해결 2: Riverpod - provider가 곧 DI

지난 글에서 이미 했다. 사실 Riverpod은 DI 도구이기도 하다.

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)),
);

ref.watch(다른Provider)로 의존하는 것을 꺼내 연결한다. get_it의 registerLazySingleton과 같은 역할을 provider 하나가 한다. 그리고 가짜로 바꾸는 방법은 지난 글에서 본 overrideWithValue다.

ProviderScope(
  overrides: [userRepositoryProvider.overrideWithValue(FakeUserRepository())],
  child: const MyApp(),
)

시험이 끝날 때 ProviderScope가 같이 사라지니 reset()을 부를 필요가 없다. 변수로 찾으므로 등록 누락이 컴파일 때 에디터에 잡히는 것도 get_it보다 나은 점이다.

어느 쪽을 쓰나

• Riverpod을 상태 관리로 쓰고 있다면: 별도 DI 라이브러리가 필요 없다. provider가 DI를 겸한다
• Provider, Bloc, Cubit을 쓴다면: get_it을 같이 쓰는 조합이 흔하다. 상태 관리는 Bloc이 하고, 객체를 만들고 연결하는 건 get_it이 한다
• 아주 작은 앱이라면: main에서 직접 UserViewModel(UserRepositoryImpl(...))을 조립해서 생성자로 넘겨도 충분하다. DI 도구가 없어도 "밖에서 받는다"는 원칙은 지킬 수 있다

Android, iOS와 비교하면

// Kotlin - Hilt
@HiltViewModel
class UserViewModel @Inject constructor(
    private val repo: UserRepository
) : ViewModel()

@Module @InstallIn(SingletonComponent::class)
object AppModule {
    @Provides @Singleton
    fun provideRepo(api: UserApi): UserRepository = UserRepositoryImpl(api)
}

// Swift - 이니셜라이저로 직접 주입
final class UserViewModel {
    private let repo: UserRepository
    init(repo: UserRepository) { self.repo = repo }
}

• 필요한 걸 밖에서 받기: 세 곳 모두 생성자(이니셜라이저)로 받는다
• 조립하는 곳: Flutter get_it 등록이나 Riverpod provider / Android Hilt @Module / iOS는 직접 조립하거나 의존성 주입 라이브러리
• 만드는 규칙: Flutter registerLazySingleton(앱에 하나), registerFactory(매번 새로) / Hilt @Singleton(앱에 하나), 기본값(매번 새로)
• 빠뜨렸을 때: get_it은 실행 중 에러 / Riverpod은 컴파일 때 에디터가 잡음 / Hilt는 컴파일 때 빌드가 실패

Hilt는 등록이 빠지면 빌드가 실패하는데, get_it은 실행해봐야 안다. 이 차이는 get_it이 코드 생성 없이 실행 중에 찾는 서비스 로케이터이기 때문이다. Riverpod은 변수로 찾아서 컴파일러의 도움을 받는다.

정리

• 클래스 안에서 필요한 걸 직접 만들면 가짜로 바꿔 끼울 수 없으므로, 생성자로 밖에서 받는 의존성 주입을 쓴다
• 받는 쪽은 구체적인 클래스가 아니라 UserRepository 같은 추상 클래스(약속)만 안다
• get_it은 registerSingleton(만든 객체), registerLazySingleton(처음 꺼낼 때 한 번), registerFactory(매번 새로)로 등록하고 getIt<T>()로 꺼낸다
• registerSingleton은 함수가 아니라 객체를 받고, 등록을 빠뜨리면 실행 중에 에러가 나며, 시험에서는 getIt.reset()으로 비우고 가짜를 등록한다
• get_it은 상태 관리 도구가 아니고, 의존하는 것이 코드 속에 숨을 수 있으니 생성자에서만 꺼내는 식으로 규칙을 둔다
• Riverpod은 provider가 DI를 겸하므로 별도 라이브러리가 필요 없고, overrideWithValue로 가짜를 끼운다

다음 글에서는 화면에 움직임을 주는 애니메이션(암시적, 명시적, Hero)을 다뤄보겠다.