AAC 와 MVVM

디자인 패턴

소프트웨어를 여러 사람이 협업해서 개발할 때, 정해진 패턴이 없다면 다른 사람의 코드 구조를 이해하는 것이 어렵습니다. 또한 이를 유지 보수하는데 많은 노력이 들 거라고 생각합니다.

이러한 문제를 해결하기 위해, 디자인 패턴이 존재합니다. 디자인 패턴은 개발자끼리의 일종의 약속이라고 생각합니다, 이 약속을 서로 지키게 되면, 서로의 코드를 이해할 때 많은 노력을 들이지 않아도 쉽게 이해할 수 있을 거라고 생각합니다.

예를 들어 구글에서 제공하는 MVP패턴이 있습니다. 그러면 100명의 개발자에게 하나의 기획을 주고 개발을 하라고 했을 때와, 구글에서 제공하는 MVP패턴을 참고해서 작성하라고 한다면, 전자는 서로 각기 다른 구조의 앱이 될 거라고 생각하고, 후자의 경우 서로 다른 실력에도 비슷한 구조가 나올 수 있을 거라고 생각합니다.

물론 그냥 자기가 하고 싶은데로 개발을 하는 게 개발 속도는 빠를 거라고 생각하지만, 여러 사람이 개발할 때 필수인 거 같습니다. 또한 많은 사람들의 코드 구조를 상향 평준화해주는 느낌이 없지 않은 거 같습니다.

MVVM

MVVM이란 Model - View - ViewModel의 줄임말로 흔히 사용되는 디자인 패턴 중 하나입니다. 여러 내용을 책임 별로 3가지로 분리시켰습니다.

 

Model: 실제 데이터를 표현하고 저장하고 관리하는 책임을 가지고 있습니다.

 

View: 뷰는 사용자가 실제로 화면에서 보는 것들의 배치, 구조등을 관리하는 책임을 가지고 있습니다. 또한 사용자와 뷰의 상호 작용을 수신하여 처리하는 책임이 있습니다.

 

ViewModel: View의 데이터들을 가지고 있으며, 로직적인 처리, 모델에 대한 접근 등 책임을 가지고 있습니다.

 

처음 여러 디자인 패턴을 배우다 보니, 많은 의문점이 있었습니다. MVC는 확실하게 책임 분리가 좀 더 모호하다고 느꼈지만, MVP와 MVVM은 너무 비슷하다고 생각을 했습니다. 둘의 View와 Model은 똑같지만, Presenter인지 ViewModel인지 차이가 있었습니다. 

 

제 개인적인 생각이지만 둘의 가장 큰 차이점은 MVP는 View와 Presenter 사이에 강한 의존성이 존재하며 1대 1 구조라 다른 View에서 재활용이 어렵지만, MVVM의 경우 View가 ViewModel을 구독하여 느슨한 결합성을 가지고 있으며 1 대 n의 구조를 가지게 되어 여러 View에서 사용이 가능하다는 점입니다.

 

MVVM패턴은 View와 ViewModel사이를 Data Binding을 통해 관리하고 있습니다.  바인더를 통해 뷰와 뷰모델을 동기화시키고 있으며, 개발자가 관리해줘야 할 책임을 대신해주고 있습니다.

이렇게 분명하게 책임이 나눠져 있기 때문에, GUI 관련 코드는 View에만 남겨둬야 합니다. 

 

 

AAC (Android Architecture Component)

AAC란 구글에서 발표한 안드로이드 개발 가이드입니다. 구글은 많은 개발자들에게 앱을 잘 만들게 하기 위해 이런 가이드라인을 주었습니다. 앱 내부에는 수많은 Activity, BroadcastReceiver, Service, ContentProvider들이 있는데, 이를 부드럽게 연결하고, 관심사 분리를 위해 이런 가이드라인을 주었다고 생각합니다.

 

구글이 권장하는 아키택쳐

많은 분들이 이 그림을 보고 구조에 대해 고민하게 되는 거 같습니다. 저 또한 이 그림을 처음 봤을 때는 디자인 패턴을 처음 경험하다 보니 이게 뭔지 잘 이해하지 못한 거 같습니다.

처음 안드로이드 개발을 접했을 때는, 모든 코드를 Activity 안에다가 작성을 했던 기억이 있습니다. 그 후로 디자인 패턴이라는 걸 접하게 되었고, 처음에는 이런 걸 굳이? 왜 할까라는 생각이 많았지만, 협업을 경험하면서 생각이 바뀌게 된 거 같습니다.

안드로이드에서 MVVM을 더 편리하게 사용하기 위해 지원하고 있는 것들이 있습니다. 그중 가장 많이 헷갈리게 되는 건 바로 ViewModel인 거 같습니다.

많은 사람들이 처음으로 MVVM을 배우게 될 때 MVVM의 ViewModel과 AAC의 ViewModel에 혼동이 오는 거 같습니다, 물론 저도 그랬구요. AAC에서는 ViewModel이라는 클래스를 따로 지원하고 있습니다. 이는 안드로이드에서 MVVM을 구현할 때 도움은 주지만 MVVM을 위해 있는 구조는 아니라고 생각합니다. 실제로 Android공식문서를 확인해도 ViewModel에 딱히 MVVM을 위해 설계되어있다고 나와있지 않습니다.

 

어떻게 프로젝트에 적용을 할까

사실 처음에 MVVM이라는 구조를 접하게 됐을 때는 좀 당황스러웠습니다. MVVM을 제대로 사용하지 못하면 구조만 복잡하게 짜고 MVVM의 이점은 살리지 못하는 그런 프로젝트가 되기 때문이었죠. 각각 기능을 어떻게 분류할지, MVVM패턴을 어떤 식으로 적용할지 수많은 고민을 하게 되는 거 같습니다. 막상 이론상으로 이해를 해도 개발하는 건 다른 일이기 때문이죠.

 

MVVM을 실제로 Android 프로젝트에 구현했을 이런 순서를 많이 따랐던 거 같습니다.

1. View를 작성한다.

2. ViewModel에 View의 데이터들을 가지고 있는다.

3. View에 ViewModel의 데이터들을 Observe 할 수 있게 만든다.

4. View에서 동작이 있을 경우, ViewModel의 함수를 통해 데이터 로직을 처리한다.

5. ViewModel은 바로 로직을 처리하거나, Model에 접근해 데이터에 대한 동작을 한다.

6. ViewModel에서 View에 관한 데이터가 변경이 있을 시, View는 Observe 하고 있기 때문에 상호작용으로 View와 관련된 코드를 작동시킨다.

 

간단하게 작성했지만, 어떻게 해야 더욱 MVVM스러운 코드가 될까 많은 고민을 하게 되는 거 같습니다.