MVVM 패턴, 뷰모델로 화면 로직을 ‘깨끗하게’ 분리하는 법

MVVM(Model–View–ViewModel)은 화면(UI) 코드에서 상태·로직을 떼어내 ViewModel에 모으는 아키텍처예요. 핵심은 상태 홀더(state holder)인 ViewModel이 화면 수명주기와 느슨하게 연결되어, 회전/재생성 같은 상황에도 상태를 안전하게 유지하고 테스트가 쉬워진다는 점입니다. 안드로이드·iOS·웹 어디서든 통하는 사고방식이고, 국내 실무 사례도 많습니다

---

MVVM 한 줄 정의

View는 그리기만, ViewModel은 상태와 화면 로직을 관리, Model은 도메인/데이터를 담당.
View는 ViewModel을 ‘구독’해 화면을 갱신하고, 사용자 입력은 View→ViewModel로 전달됩니다. 안드로이드에선 ViewModel이 구성 변경에도 상태를 보존해 데이터 재로딩을 줄이고 UI 안정성을 높입니다.

---

왜 MVVM이 요즘도 사랑받나

• 상태 관리의 중심이 분명: “어떤 값을, 왜, 언제 갱신하나?”가 ViewModel에 모여 디버깅이 쉬워집니다.
• 테스트 친화적: UI 프레임워크 없이도 ViewModel 단위테스트로 포맷·검증·로딩 상태 등을 빠르게 검증할 수 있어요.
• 수명주기 안전: LiveData/Flow 같은 관찰 가능 상태를 쓰면 액티비티/프래그먼트 생명주기를 존중하며 안전하게 업데이트됩니다.
• 실무 검증: 카카오페이 등 국내 팀들이 MVVM 적용·전환 사례를 공개하고 있어 참고하기 좋습니다.

---

안드로이드에서의 MVVM 빠른 가이드

• ViewModel = 상태 홀더
  화면에 필요한 데이터/로딩·에러 상태를 보유하고, 비즈니스 유스케이스를 호출해 결과를 가공합니다. ViewModel은 Context 직접 참조 금지(메모리 릭 위험).
• 관찰 가능한 상태
  기존 LiveData부터 코루틴 Flow까지 선택지 다양. 비동기 스트림에 강한 Flow, 수명주기와의 궁합이 좋은 LiveData—둘 다 공식 가이드·코드랩이 잘 정리돼 있어요.
• 데이터 바인딩/선언형 UI
  Data Binding/Compose(또는 iOS의 RxSwift/Combine)로 View는 상태를 선언하고, 실제 변화는 ViewModel이 주도합니다. 우아한형제들 iOS 사례도 MVVM+리액티브 조합을 소개합니다.

---

자주 하는 실수와 예방책

• Massive ViewModel: 네트워크·캐시·매핑을 몽땅 넣으면 또 비대해져요. 유스케이스(서비스)로 분리하고, ViewModel은 오케스트레이션과 상태만 책임지게.
• 양방향 바인딩 남용: 편하지만 흐름을 추적하기 어렵습니다. 단방향 데이터 흐름(UDF) 을 기본으로 두고 꼭 필요한 곳에만 쓸 것. (실무 팁과 DTO 분리는 최근 국내 글에서도 강조됩니다.)
• 수명주기 무시: View에서 LiveData/Flow 수집 시 생명주기를 지키고, ViewModel에 UI 객체 넣지 않기.

---

서버 개발자를 위한 짧은 브릿지

MVP에서 Presenter가 응답 DTO를 만들듯, MVVM의 ViewModel은 UI 친화 상태를 만든다는 점이 닮았습니다. 서버에선 컨트롤러 밖에서 DTO/뷰모델을 조립해 테스트하듯, 클라이언트에선 ViewModel을 순수하게 테스트하면 됩니다. (MVVM은 여전히 UI 아키텍처라는 점만 기억!)

 

---

마무리

MVVM의 가치는 “상태와 화면 로직을 View에서 떼어내 가독성·테스트성·유지보수성을 모두 가져간다”는 데 있어요. 팀의 규모가 커질수록 단방향 흐름 + 얇은 View + 유스케이스 분리를 기본으로 잡으면, 기능 추가와 리팩터링 속도가 확 달라집니다.