[안드로이드 개발 공식 가이드라인] 왜 구글은 안드로이드에서 MVVM을 사랑하였는가?

오늘은 첫 포스터에서 설명한 것 같이

이전 포스터들에서 챕터1에서는 잘못 사용하고 있었던 안드로이드 코드들을 고친 다음

오늘부터 챕터2의 핵심인 MVVM에 대해서 연구해보려고합니다.

 

여러분들이 MVVM은 많이 들어보기만 하신분들만 있기도 하고

회사 프로젝트에서 사용하고 있어서 그냥 사용하시고 있는분들이 많을거라 생각합니다.

MVVM은 여러 디자인 패턴중 하나입니다.

하지만 왜 다들 안드로이드 개발에서는 많은 패턴 중에 MVVM을 사용하고 있을까요?

 

저는 이 궁금중부터 시작하여 

역사적인 관점에서

- MVVM이전에는 어떤 패턴들을 사용하였고

- 어떤 문제들가 있어서 MVVM이라는 새로운 시도를 하게되었으며

- 이는 어떤 효과를 불러일으켰는지 살펴볼 예정입니다.

그럼 시작해보겠습니다.

 

Q1. ChatGPT, 안드로이드에서 MVVM이전에는 어떤 패턴을 사용하였는지 설명해줘

가장 일반적으로 사용되는 패턴은 MVC(Model-View-Controller) 패턴이었습니다.
하지만 안드로이드 앱이 복잡해짐에 따라 MVC 패턴은 다양한 문제들이 발생하였습니다.
- 새로운 기능을 추가하거나 기존 기능을 수정하는 유지 보수가 어려워짐.
- UI와 데이터간 동기화가 어려워져 UI가 복잡해짐.
- 기능별로 코드가 분리되어있지않아 테스트가 어려움.
다른 대안을 찾기위해 MVP와 MVVM을 사용하였고 많은 안드로이드 개발자들이 MVVM을 선택하였습니다.

안드로이드 개발자들은 MVVM을 사용하기 이전에 MVC패턴을 사용하고 있었네요.

하지만 MVC는 코드 규모가 커질수록 유지보수가 어렵다는 강력한 문제점이 있었네요.

 

 

Q2. 그러면 왜 구글은 안드로이드에서 MVP대신에 MVVM을 추천하기 시작한거야?

Google은 아키텍처 패턴을 통해 MVVM을 홍보하는 것이 아니다.

2017년 Google은 "안드로이드 아키텍처 컴포넌트"를 도입하여 많은 개발자들에게 권장해왔다.
이를 통해서 유지 보수성을 향상시켜왔다.
해당 도구들을 사용할 때 일부 개발자에게 MVP보다 MVVM이 더 매력적으로 다가왔다.

와우, Google은 MVVM 아키텍처 패턴 자체를 홍보한것이 아니라

Android Architecture Component(줄여서 AAC)라는 것을 안드로이드 개발자에게 권장하였고

개발자들은 AAC를 잘 활용할 수 있는 패턴이 MVP보다 MVVM이여서 선택하게된 결과였네요.

 

 

Q3. 그렇다면 MVVM은 어떤 장점들이 있니?

- DataBinding
안드로이드 아키텍처 컴포넌트의 DataBinding 라이브러리를 사용하면
개발자가 UI 구성 요소를 ViewModel에 직접 바인딩할 수 있으므로
UI를 데이터 모델과 동기화된 상태로 유지하기가 더 쉽습니다.

DataBinding이라는 AAC 라이브러리를 사용하여

유지보수가 쉽게 UI에 (findViewByid, viewBinding, extension)같은 데이터를 바인딩을 할 수 있는걸로 보이네요.

- 수명 주기 인식 구성요소
안드로이드 아키텍처 컴포넌트인 LiveData와 ViewModel와 같이
configuration changes(ex, 화면 회전)을 자동으로 처리하고, 일반적인 메모리 누수를 방지할 수 있는
ViewModel의 수명 주기 인식 구성요소를 제공합니다.

AAC라이브러리에는 LiveData와 AAC-ViewModel이라는 라이브러리들로

MVVM패턴의 ViewModel의 생명주기를 관리할 수 있어서

"화면 회전시 발생하는 문제"나 "메모리 누수"같은 문제를 해결할 수 있습니다.

 

- 반응형 프로그래밍
MVVM은 비동기 작업을 단순화하고 코드를 더 읽기 쉽고 간결하게 만들 수 있는
RxJava 및 Kotlin 코루틴과 같은 반응형 프로그래밍 라이브러리와 잘 작동합니다.

간단히 말하면 코루틴과 MVVM은 궁합이 잘 맞다는것 같습니다.

 

- 테스트 가능성
MVVM은 문제를 더 잘 분리하여 View와 독립적으로
ViewModel을 더 쉽게 테스트할 수 있도록 합니다.
이는 보다 신뢰할 수 있는 테스트와 보다 쉬운 유지 관리로 이어질 수 있습니다.

View와 ViewModel을 분리하여서

ViewModel에 대한 테스트, View에 대한 테스트를 각 각 잘할 수 있게 해주었네요.

해당 테스트에 관한 내용은 챕터3에서 자세히 살펴보겠습니다.

 

 

Q4. 그러면 MVP에서 Android 아키텍처 구성요소를 사용할 수 없나요?

MVP에서도 AAC를 사용할 수 있습니다. 다만 MVVM과는 달리 동작합니다.
게다가 데이터 바인딩을 사용하여 View를 업데이트하는 대신Presenter에서 ViewModel에서 제공하는 데이터를 사용하여 수동으로 View를 업데이트합니다.
즉, 이러한 구성요소와 원활하게 작동하도록 설계된 MVVM에 비해 추가 노력과 맞춤 구현이 필요할 수 있습니다.

MVP에서도 AAC를 사용가능하지만

Databinding처럼 수동으로 해주게 되는 해당 라이브러리를 사용하는 근본적인 문제가 발생하고
그 외의 라이브러리들을 사용하는데 다른 기능을 추가하여 구현을 필요로해보이네요.

 

---

오늘은 MVC, MVP 패턴들 중에서 MVVM이 많은 안드로이드 개발자들에게 사랑을 받은 역사를 살펴보았습니다.

구글은 안드로이드 아키텍처 컴포넌트라는 도구를 세상에 내놓았고

안드로이드 개발자들은 해당 도구를 잘 사용할 수 있는 MVVM을 자연스럽게 선택하게 되었네요.

 

그렇다면 구글 또한 왜 안드로이드 아키텍처 컴포넌트라는 도구를 만들었고

세상 밖으로 나오게 되었을까요?

그 내용을 다음 안드로이드 역사 수업에서 이어가겠습니다.