Android 앱 개발을 하다보면, Activity 클래스에 모든 앱 동작 코드를 다 집어넣는 경우가 많았다.
물론 동작에 있어 큰 문제는 없지만 체계적인 구조가 전혀 없어 추후에 유지 보수가 어렵다.
실제로 몇몇 프로젝트를 진행함에 있어 이러한 방식으로 앱을 개발하다 보면,
기능을 바꾸거나 추가할 때 어떤 부분을 수정해야 할지 머리가 아득해졌던 경험이 있다.
문득 여태 짠 지저분한 코드들을 보면서 이러한 생각이 자연스레 들었다.
'아무래도 MVVM 디자인 패턴 공부를 해야겠다'
그래도 새로이 등장한 MVVM 패턴에 따른 앱 개발이 대세가 대세인만큼 구글에서도 이를 도와주는 듯 Android Jetpack 의
구성 요소로서 AAC (Android Architecture Component) 라는 것을 제공하고 있다.
( 물론 AAC 가 있다고 MVVM 을 정복할 수 있으리라는 자신감은 접어두는 것이 좋은 것 같다. )
따라서 필자가 여러 자료를 찾아보면서 익힌 MVVM 패턴과 AAC 에 대해서 소개하고자 한다.
* 이 글은 기존의 MVC 패턴에 대한 이해도가 있다면 더욱 읽기 수월하다.
MVC vs MVVM
기존 성행했던 단순한 모양의 MVC 패턴에 따라 Activity 에 모든 코드를 다 집어넣으면 이런 단점들이 발생했다.
- 앱 동작이 많아질 수록 Activity 자체가 무거워 짐
- View 와 Model 간의 의존성이 높아져 코드가 복잡해 짐
- View 의 UI Refresh 를 위해 Model 을 참조하므로 앱 규모가 커질수록 코드가 복잡해 짐
단점들을 봤을 때 MVC 패턴은 규모가 커질수록 공통적으로 유지 보수가 어려워진다는 단점이 존재한다.
왜냐하면 MVC 패턴의 동작이 이렇기 때문이다.
- Controller 가 사용자의 동작을 받아들임 ( 텍스트 입력, 터치 등 )
- Controller 가 사용자의 동작에 따른 Model 업데이트 요청
- Controller 가 Model 을 나타낼 View 선택
- Viwe 는 Model 을 참조하여 UI 업데이트
자연스레 View 와 Model 간의 의존성이 높아질 수 밖에 없다.
또한 Controller (Activity) 가 Model 과 View 사이에서 바쁘게 움직임을 알 수 있다.
혼자서 여기 저기 요청을 보내야 하고 가운데에 껴서 고생하는 Controller 는 당연히 동작이 무거워질 수 밖에 없다.
따라서 코드 유지 보수를 하다가 까딱했다간 UI 프레임 스킵 현상 및 메모리 릭 (Memory Leak) 의 위험에 빠질지도 모른다.
한 마디로 MVC 패턴은 구현하기 쉬운 장점이 있는 반면 기능 추가 및 변경에 있어 유지 보수가 어렵다.
이러한 MVC 패턴의 단점을 보완하고자 (Controller 를 구제해주고자) 등장한 디자인 패턴이 바로 MVVM 이다.
MVVM 은 기존 MVC 에서 'Controller' 에게 막중한 역할을 주기보다,
이 동작을 분리하여 동작 흐름을 더욱 체계적으로 만들어 주고 유지 보수에 용이한 디자인 패턴이다.
MVVM 은 Model, View, ViewModel 로 이루어져 아래와 같은 동작을 한다.
-
View
- Activity / Fragment 가 View 역할을 함
- 사용자의 Action 을 받음 ( 텍스트 입력, 버튼 터치 등)
- View Model 의 데이터를 관찰하여 UI 갱신
-
ViewModel
- View 가 요청한 데이터를 Model 로 요청함
- Model 로 부터 요청한 데이터를 받음
-
Model
- View Model 이 요청한 데이터를 반환함
- Room, Realm 과 같은 DB 사용이나 Retrofit 을 통한 백 엔드 API 호출이 보편적
결국 View 가 필요로 하는 데이터는 ViewModel 이 쥐고 있고,
View 는 그것을 필요로 하고 있는 만큼 쥐고 있는 데이터를 관찰 (Observing) 한다.
때문에 MVC 패턴과 다르게, DB 에 직접 접근하는 것이 아닌 UI 업데이트에만 집중한다.
또한 관찰하고 있는 만큼 데이터 변화에도 능동적으로 움직이게 된다.
따라서 MVVM 패턴은 다음과 같은 장점을 가진다.
-
View 가 View Model 의 Data 를 관찰하고 있으므로 UI 업데이트가 간편
-
View Model 이 데이터를 홀드하고 있으므로 Memory Leak 이 발생할 가능성 배제
( View 가 직접 Model 에 접근하지 않아 Activity / Fragment Life Cycle 에 의존하지 않기 때문 )
-
기능 별 모듈화가 잘 되어 유지 보수에 용이 ( e.g. View Model 재사용 및 DB 교체 등의 작업이 편리함 )
이러한 장점을 가지고 있는 MVVM 패턴은 '잘만' 사용한다면 훌륭한 앱을 만들 수 있을지도 모른다.
그렇지만 그만큼 구조가 복잡하다는 단점이 크게 다가온다.. ( 당연하게도 공짜는 없었다 )
그래도 MVVM 디자인 패턴을 간편하게 적용해 볼 수 있게끔 구글에서는 AAC 라는 것을 제공한다.
AAC (Android Architecture Component)
지금까지 알아봤던 MVVM 의 구성 요소를 Android Jetpack 의 구성요소 AAC 와 함께 구현하자면 아래 그림과 같을 것이다.
View Model 은 앞서 설명한대로 화면 변화 시에도 변하지 않는 ( 혹은 사라지지 않는 ) 데이터를 갖고 있다.
Live Data 는 View 가 View Model 을 관찰할 때 대상이 되는 데이터 홀더 클래스이다. Live Data 는 Activity 및 Fragment 의
Life Cycle 을 인지 하므로, 화면이 활성화 되어 있을 때만 동작하여 메모리 릭을 줄여 준다.
Repository 는 View Model 과 데이터를 주고받기 위해 데이터 API 를 포함하는 클래스다. 사용자 동작에 따라 필요한 데이터나
외부 백 엔드 서버 등에서 데이터를 가져오게 된다. Repository 의 존재 덕분에 View Model 이 데이터를 관리할 필요가 없게 된다.
Room 은 SQLite 를 사용함에 있어 별도의 Query 문 작성 없이 간편하게 Insert, Delete 등의 동작을 할 수 있게끔 도와주는
ORM 라이브러리이다. ( 공식 문서에 따르면 Realm 같은 친구를 써도 상관없다고 한다. )
AAC 에서 이러한 구성 요소들을 기본적으로 제공해주기 때문에, 쉽게 MVVM 디자인 패턴을 익히고 사용할 수 있다.
물론, MVVM 도 이점을 살리지 못하고 잘 활용하지 못하면 괜히 구조만 복잡 해지게 될 것이다.
따라서 기능 각각을 어떻게 분류하여 어떤 컴포넌트에 포함해야 제일 효율적일지 생각하는 것이 과제가 될 것이다.
또한 자기가 개발하고자 하는 앱에 가장 알맞는 디자인 패턴이 무엇인지 생각해볼 필요도 있다.
필자도 MVVM 패턴을 유심히 익혀보며 앞으로 프로젝트에 적용하여 유지 보수가 용이한 개발을 해 볼 예정이다.
후속 포스트로는 AAC 를 활용하여 MVVM 패턴을 연습해볼 수 있는 예제를 만들어볼 예정이다.
+ 본문 이해에 도움이 될 것 같은 영상도 추가하였다.
'안드로이드 스터디' 카테고리의 다른 글
[Kotlin] 언제 뭘 써야 돼? 헷갈리는 스코프 함수 한 방 정리 (2) | 2021.03.15 |
---|---|
[Android] 대체 사람들이 RxJava 거리는 게 뭐야? (0) | 2020.11.23 |