😇 안드로이드 권장 아키텍처에 대해서 (MVVM 패턴과 비슷!)

AUSG·2020년 7월 7일

필자는 안드로이드 개발 및 관련 공부를 약 1년 반 정도 해왔습니다..! 우연한 기회로 접하게 된 안드로이드 개발이였지만 필자의 개발 적성과 성향에 잘 맞아 꾸준히 공부하고 있습니다 ㅎㅎ

이 포스팅에서는 필자가 약 한 달 전쯤 공부하고, 실제 프로젝트에 적용해본 안드로이드 권장 아키텍처 에 대해 소개해보려 합니다!

본 포스팅 내용의 대부분은 Android Developer 사이트의 "앱 아키텍처 가이드" 문서를 바탕으로 작성될 것이며 해당 문서를 필자가 이해한대로 작성할 예정입니다. (잘못된 이해로 오개념이 있을 수 있으니 피드백 환영입니다~ ㅎㅎ)

💁🏻‍♀️ 안드로이드 권장 아키텍처를 따라야 하는 이유가 무엇일까?

안드로이드 권장 아키텍처에 대해 소개하기 전에!
안드로이드 권장 아키텍처가 존재하는 이유와 이에 따라야 하는 이유에 대해 알아봅시다~

안드로이드 개발자가 앱을 개발하는데 있어 고려해야 하는 것이 있습니다. 바로 모바일 앱 사용자 환경 이라는 것입니다.

모바일 앱 사용자 환경이라는 것이 무엇인지 이해하기 위해 이제부터 우리는 모바일 폰을 사용하는 사용자가 되어봅시다!

유저가 되어 SNS 앱에 사진을 업로드 하는 과정을 생각해 봅시다.
SNS 앱에 사진을 업로드 하기 위해서는 제일 먼저 SNS 앱에서 카메라 기능을 실행시켜야 할 것 입니다. 이를 위해 SNS 앱이 카메라 인텐트를 트리거할 것이고, Android 운영체제는 이 요청에 따라 카메라 앱을 실행시킬 것 입니다.

이 순간에 사용자는 카메라 앱으로 이동함으로써 SNS 앱에서 나간 상황이지만 사용자 환경은 끊임없이 연결되어 있는 상태라고 볼 수 있습니다.

카메라 앱으로 사진을 찍은 유저는 다시 SNS 앱으로 돌아와서 앨범을 보기 위해 앨범 인텐트를 트리거 할 것입니다. 앨범에서 업로드할 사진을 선택한 유저는 다시 SNS 앱으로 돌아와서 업로드 기능을 통해 사진을 업로드 하게 됩니다.

여기서 중요한 것은 이 과정에서 언제든지 전화나 알람 등에 의해 이어지던 사용자 환경의 흐름이 끊길 수도 있다 는 것입니다!

위와 같은 과정을 모바일 앱 사용자 환경이라고 이해하면 쉽습니다. 모바일 환경에서는 사용자들이 다양한 앱을 시도 때도 없이 바꾸면서 사용하기 때문에 모바일 앱 사용자 환경이 중단되고 다시 이어지는 경우가 많이 발생합니다.

따라서 앱은 이러한 사용자 환경 흐름을 올바르게 처리하도록 설계되어야 합니다.

위 설명을 통해 안드로이드 앱을 구성하는 컴포넌트들은 사용자 환경 흐름에 따라 개별적이고 비순차적으로 실행될 수 있으며 사용자가 언제든지 앱 컴포넌트를 제거할 수 있다는 것도 이해할 수 있을 것입니다.

개발자가 이러한 여러 사용자 환경 흐름을 직접 제어할 수 없기 때문에 "앱 구성요소가 서로 종속되어 있어서는 안되며 앱 구성요소가 앱 데이터나 상태를 저장하고 있어서는 안됩니다."

💁🏻‍♀️ 안드로이드 권장 아키텍처!

위 내용을 통해 우리는 앱 구성요소가 서로 종속되어 있거나 앱 구성요소가 앱 데이터나 상태를 저장하고 있어서는 안된다는 사실을 알게 되었을 것입니다.

그렇다면 이제 이러한 원칙을 어떤 방법으로 지켜야 하는지가 궁금해질 것 입니다.
이 궁금증에 대한 답은 바로 안드로이드 권장 아키텍처 를 지키자 입니다!

안드로이드 권장 아키텍처를 그림으로 표현하자면 위 그림과 같습니다.

위 그림을 통해 각 구성요소(Activity/Fragment, ViewModel, Repository, Model 등)들이 딱 한 단계 아래의 구성요소에만 종속되어 있는 것을 확인할 수 있습니다.

예를 들어, Activity/Fragment는 ViewModel에만 종속되어 있으며 Repository 나 Model에는 종속되어 있지 않습니다.

그럼 이제부터 위와 같은 안드로이드 권장 아키텍처 구조를 만족시키는 사용자 프로필 기능 을 구현해봅시다!
(실제 코드를 통한 구현은 아니며 이해를 돕기 위한 설명입니다~)

가장 먼저 사용자 프로필 UI를 위해 user_profile_layout.xml 파일과 UserProfileFragment.kt 파일을 작성했다고 가정합시다.

이 두 파일을 작성한 다음으로는 ViewModel 파일을 작성해야 합니다. 앞서 보여드린 안드로이드 권장 아키텍처 그림에서 Activity/Fragment 구성요소의 바로 아래 단계에 ViewModel 구성요소가 있었음을 생각해보면 ViewModel 파일을 작성해야 함을 이해할 수 있을 것입니다.

ViewModel 파일을 작성하기 전에 ViewModel의 역할에 대해 간단히 알아봅시다.

"ViewModel은 UI 구성요소에 데이터를 제공하고 Model과 커뮤니케이션하기 위한 데이터 처리 비즈니스 로직" 이라고 할 수 있습니다.

즉, UI 구성요소에 필요한 데이터를 Model에서 가져온 후, 가져온 데이터를 UI 구성요소에 전달해주는 중간 매개체라고 이해해봅시다!

이 때, ViewModel이 반드시 지켜야 하는 원칙은 ViewModel은 UI 구성요소에 대해 알지 못해야 하며 이를 통해 ViewModeldms Activity/Fragment의 수명주기 변화에 영향을 받지 않는다 입니다.

조금 더 쉽게 풀어 설명해보면 ViewModel은 자신이 Model에서 가져온 데이터를 어떤 UI 구성요소에 줘야 하는지는 모른다는 뜻입니다. 단지 'Model에서 가져온 데이터를 UI 단에 넘겨주기'의 작업만 하는 것이 ViewModel 입니다.

UserViewModel.kt 파일을 작성한 후, Repository 파일을 작성해야 합니다. 이 때도 마찬가지로 위에서 보여준 안드로이드 권장 아키텍처 그림을 참고하면 ViewModel의 바로 아래 단계에 Repository가 자리 잡고 있음을 확인할 수 있습니다.

Repository 파일은 실제로 데이터를 가져오는 작업을 담당하는 곳 입니다.

우리가 사용자 프로필에 사용되는 데이터를 server에서 가져온다고 가정한다면 Retrofit 라이브러리(안드로이드 http 통신을 도와주는 고마운 녀석^^)를 사용하여 Repository 파일 안에서 실제 server 통신을 호출하고 데이터를 응답받는 로직을 작성하면 됩니다.

server로부터 데이터를 응답받은 후 이 데이터를 다시 Repository의 한 단계 위 구성요소인 ViewModel에게 전달합니다.
(필자는 Repository 안에서 서버 호출 시 비동기 처리 위해 coroutine 이라는 비동기 처리를 도와주는 라이브러리를 사용합니다.)

Repository에게 사용자 프로필에 사용되는 데이터를 받은 ViewModel은 자신을 호출한 UI 단에 데이터를 넘겨줍니다.
(이 때, LiveData 라는 Observable한 데이터 Holder 클래스를 사용합니다. LiveData에 대한 자세한 설명은 다른 포스팅을 통해 소개하겠습니다ㅎㅎㅎ)

ViewModel에게 데이터를 넘겨 받는 UI 구성요소는 필요한 위치에 데이터를 세팅함으로써 사용자 프로필 UI를 완성하게 됩니다.

위에서 설명한 사용자 프로필 기능이 구현되는 과정을 다시 정리해보면 UI 구성요소 --> ViewModel --> Repository --> ViewModel --> UI 구성요소 로 이어지는 흐름임을 알 수 있을 것입니다.

이러한 구조로 안드로이드 앱을 빌드하는 것을 권장하고 있으며 앱이 이러한 구조일 때 여러 사용자 환경의 흐름에 적절히 대응할 수 있을 것입니다~!

그럼 여기까지의 설명으로 안드로이드 권장 아키텍처에 대한 소개를 마치겠습니다~

위 글을 읽으며 안드로이드 권장 아키텍처에 대한 전반적인 이해에 도움이 되었다면 필자는 정말 기쁠 것 같습니다😁

또한 위 내용 중 잘못된 설명이나 부족한 설명이 있을 경우 즉시 피드백 해주시길 기대합니다><