AAC가 뭔가 했더니 Android Architecture Component의 약자네요. 참고로 안드로이드는 IOS처럼(Objective-C MVC, Swif-UI- MVVM) 공식화된 아키텍쳐가 없습니다. 그냥 관련 클래스를 제공하는 것 뿐이죠. 아니, 권장 아키텍쳐가 있긴한데, 그건 아주 심플한 앱에 적용할만하고 실제로는 잘 사용하지는 않습니다. 왜냐하면 라이프사이클 관리가 아주 숙련된 개발자들조차도 해당 문제를 접할 때마다 문서를 들여다 보고 또 들여다 봐야 하는 문제 때문에 오래전 부터 구글에 요청을 했다가, 최근 몇 년사이에 관련 라이브러리를 추가했습니다. 개인적으로는 별로 완성도 높은 라이브러리를 내놓지는 못한 것으로 생각하고 있습니다.
AAC의 ViewModel은 클래스 이름이 ViewModel이라서 Model-View-ViewModel 패턴에서 사용하는 ViewModel클래스라고 부릅니다. 딱히 이게 ViewModel이 아니라고 하기에도 그렇고 맞다고 하기도 그런 것 같아요. ViewModel이 Android 시스템이 종속적일 필요는 없는데, AAC의 ViewModel은 그렇거든요.(Lifecycle aware component라고 하죠.)
원래 VMx 계열 디자인 패턴 - MVC, MVP, MVVM, MVI 등등은 기본 개념은 대동소이 합니다. 뷰관련 로직과 비지니스 로직을 분리하기 위한 겁니다. 이렇게 하는 장점을 굳이 설명을 하지 않아도 아실 겁니다. 코드를 읽기가 쉽고 당연히 변경이 용이해 집니다. 물론 유닛테스트의 장점도 생기구요.
ViewModel은 말그대로 View와 Model의 브릿지 역할을 하는 겁니다. 한가지 헷갈리지 말아야 할 것은 MVx 패턴에서 말하는 모델이라는 것은 비지니스 로직이 들어간 클래스를 말하는 겁니다. 예를 들면 서버의 API를 호출하거나 데이터베이스에 접근해서 데이터를 처리하는 로직이 들어가 있는 거죠. ViewModel은 이 Model을 호출하여 View가 화면에 데이터를 보여줄 수 있는 형태로 가공 또는 번역해주는 중간자 역할을 합니다. 여기에 어떤 비지니스 로직이 들어가서는 안되고 뷰에 대한 레퍼런스를 가지고 있어서도 안됩니다. 안드로이드에서는 LiveData를 통해 이 부분을 처리하고 있고, 보통은 Observer 패턴 같은 것을 사용하면 쉽게 구현이 가능합니다.
안드로이드 ViewModel가 등장하게 된 이유 중의 하나가 Device rotation, Process death 같은 라이프 사이클 관련 문제를 해결하기 위한 겁니다. ViewModel은 이런 경우에도 살아남을 수 있도록 설계되었기 때문이죠.. 내부적으로는 별로 깔끔한 방법이라고 보여지지 않는 Headless Fragment라고 하는 걸 사용하고 있긴하지만요.
AAC로 인해 해결되는 문제들도 있지만, 새롭게 파생되는 문제들도 있습니다. 저 같은 경우는 Navigation Component를 사용 중인데, 이로 인해 겪는 문제가 한두가지가 아닙니다.
그리고 조만간 구글에서 Jetpack Compose를 발표할건데, 아마 그전에도 그랬듯이 엄청나게 홍보를 할겁니다. 물론 이게 장기적인 관점에서는 좀 더 나은 방법이긴 하지만, 아직 안정적으로 돌아가려면 한참 걸리거라고 생각합니다. 최근 구글은 예전보다 훨씬 자주 덜 만들어진 라이브리를 출시해놓고 개발자들에게 테스트를 시키는 것 같이 보여요.. 개인적으로는 안드로이드가 퍼포먼스 상으로는 아직은 IOS에 비해서 좀 뒤쳐져있다는 생각인데, 이 갭이 잘 좀혀지지 않는 것 같아요.. 뭐 당연한 결과일 수도 있겠지만요.
