[mvvm] 뷰모델 지피티 물음 정리4

말랑돌·2025년 8월 14일

안드로이드 학습

목록 보기

17/17

결론부터 말씀드리면, NavigationGraph에서 viewModel()을 호출하고 관리하는 것이 더 좋습니다.

이는 Jetpack Compose의 설계 철학에 더 잘 맞고, 더 유연하며 재사용 가능한 코드를 만들어주기 때문입니다. 두 방식의 장단점을 비교해 보면 왜 그런지 명확하게 알 수 있습니다.

이 방식은 UI를 중심으로 하는 "Compose-first" 접근법입니다. UI가 자신이 필요로 하는 데이터를 직접 요청하고 생명주기를 관리합니다.

결합도 감소 및 재사용성 증가: NavigationGraph는 MainActivity가 자신에게 ViewModel을 넘겨줄 것이라고 기대하지 않습니다. 즉, Activity와 독립적입니다. 나중에 이 NavigationGraph를 다른 Activity나 화면에 가져다 붙여도 코드 수정 없이 재사용할 수 있습니다.
명확한 의존성: ViewModel이 필요한 NavigationGraph가 직접 viewModel()을 호출하므로, "이 화면은 이 ViewModel을 사용한다"는 사실이 코드 내에서 명확하게 드러납니다.
정교한 생명주기 관리: viewModel()은 가장 가까운 ViewModelStoreOwner(주인)에 ViewModel을 연결합니다. 만약 앱이 더 복잡해져서 중첩된 네비게이션 그래프(Nested Navigation Graph)를 사용한다면, 특정 기능 흐름(예: '로그인 과정')에만 살아있는 ViewModel을 만들 수도 있습니다. Activity에 종속시키는 것보다 훨씬 유연합니다.
미리보기(@Preview) 및 테스트 용이성: Activity로부터 ViewModel을 주입받는 컴포저블보다, 스스로 ViewModel을 생성하는 컴포저블이 프리뷰를 작성하거나 테스트하기가 훨씬 쉽습니다.

이 방식은 Activity나 Fragment가 모든 것을 제어하고 UI에 데이터를 주입해주던 기존의 안드로이드 개발 방식과 유사합니다.

강한 결합: NavigationGraph는 MainActivity가 ViewModel을 만들어서 넘겨줘야만 동작할 수 있습니다. 둘 사이의 관계가 매우 강하게 묶여버립니다.
매개변수 드릴링 (Prop Drilling): MainActivity -> MainScreenView -> NavigationGraph로 이어지는 것처럼, 중간에 있는 컴포저블들은 ViewModel을 사용하지도 않으면서 단지 전달만을 위해 불필요한 매개변수를 가져야만 합니다. 코드가 지저분해지기 쉽습니다.
불투명한 데이터 흐름: NavigationGraph 코드만 봐서는 viewModel이 어디서 오는지 알 수 없습니다. MainActivity까지 거슬러 올라가야 그 출처를 알 수 있어 코드 파악이 번거로워집니다.

물론 이 방식이 무조건 나쁜 것은 아닙니다.

ViewModel의 데이터가 Compose UI뿐만 아니라 Activity의 다른 로직(예: 권한 요청 결과 처리, BroadcastReceiver 수신)과도 상호작용해야 할 때 유용할 수 있습니다.
기존의 View 시스템 기반 앱을 Compose로 점진적으로 마이그레이션할 때 자연스러운 구조일 수 있습니다.

결론적으로, 특별한 이유가 없다면 ViewModel은 그것을 실제로 사용하는 가장 가까운 공통 상위 컴포저블(이 경우 NavigationGraph)에서 생성하고 관리하는 것이 현대적인 안드로이드 앱 개발의 모범 사례입니다.