제이제이랩

현재 회사에서 제가 적용하는 아키텍쳐는 MVP와 MVVM을 섞어서 쓰고 있습니다. 소위 네이밍을 MVVM+P라고 지었는데요.

그림을 그리면 아래와 같이 되는데요.

이 그림 한장이 사람들에게 직관적으로 다가오는지 확인하기 위해 우선 reddit에 글을 올려본 후 어떤 설명을 추가할 지 알아본 후 세번째 글을 써야할 것 같습니다.

잘안보이시면 클릭 하셔서 확대해 보세요.

주말이 되어 오랜만에 어떤 글을 써볼까 하다가 이제 새로운 회사에 입사한지 한달이 살짝 넘은 터라 안드로이드 기능 개발 프로세스에 대해서 고민하는 시간을 갖도록 하겠습니다. (사실 저는 개발 방법론이나 개발 프로세스 자체는 관심이 없긴 한데, 아키텍쳐와 밀접하게 연관이 되어 있기 때문에 살펴봤네요ㅎㅎ;;;) 티몬에 재직할 때에는 사실 개발 프로세스에 대해서는 제가 신경쓰지 않아도 기획자 및 PM유닛에서 관리하기 때문에 고민할 필요가 없었지만, 지금 재직하는 회사는 벤처 회사이기도 하고 좀 더 기민하게 개발할 필요가 있다는 느낌적인 느낌이 들어 필히 개발 과정 동안 발생할 수 있는 상황에 대해 유연하게 대응할 수 있는 개발 방식에 대한 고민이 필요해 보였습니다.

기획서가 성숙단계에 접어들어 안드로이드 개발팀이 개발을 시작한다고 합시다. 기획서만 있고 디자인, 서버 API가 아직 나오지 않는 상태에서 모바일팀에서는 업무를 어떻게 진행해야 할지가 문제입니다. 디자인 시안이 안나와서 기획서대로 xml를 짜놓은 후 액티비티, 프래그먼트 구현을 했는데, 디자인이 기획서와 상당하게 차이가 나도록 변경되는 경우가 생긴다면 액티비티와 프래그먼트의 UI로직도 변경이 필요합니다. 서버에서 mock-up 데이터를 안내려 주거나 힘든 경우 모바일 클라이언트에서는 mock-up만 오기를 기다려야만 하는가? 이런 문제가 있는데요.

사실 서버에서 데이터를 내려주지 않고 디자인 시안이 나오지 않는 상황에서도 할 수 있는게 있습니다. MVVM 아키텍쳐를 채택해서 ViewModel을 미리 만들어서 기획서에 나온 UI를 가지고 xml을 만들어 바인딩하는 정도의 작업을 할 수 있습니다. ViewModel에 대한 테스트까지 해주면 땡큐죠. View에서 사용할 Presenter도 이 단계에서 정의해 줄 수 있습니다. 만약 디자인 시안이나 최종 디자인이 나왔다면 해당 디자인에 따라 xml을 개발하고 기존 ViewModel과 바인딩만 해주면 되고 서버 API 개발이 어느정도 진행되어 mock-up 데이터를 내려줄 수 있게되었다라고 한다면 json2pojo 서비스를 사용해서 5분만에 POJO클래스를 만들고 POJO를 Adapter 패턴을 사용하여 ViewModel에 사용될 수 있도록 적용해 주기만 하면 됩니다. 그리고 Presenter가 model를 사용하도록 하여 서버 연동을 해주면 작업이 완료가 되겠네요.

좀 더 정리해보면, 

1. 기획서를 바탕으로 ViewModel을 만들고, 테스트할 수 있는 기본 UI를 기획서에서 있는대로 최대한 단순한 xml을 구현한다.

2. ViewModel에 대한 테스트를 수행 및 테스트 코드를 작성한다.

3. Activity, Fragment, RecyclerView등의 View는 ViewModel만을 사용하도록 구현 한다. 절대 Model의 data(POJO)와는 디커플링 시킨다.

4. View layer에 대한 테스트 수행 및 테스트 코드를 작성한다.

윗 단계까지 작업하면 디자인, 서버 API의 mock-up이 준비되지 않아도 기획서에서 요구한 요구사항을 만족시키고 실행 가능한 앱이 됩니다. 

그럼 만약에,

- 기획서가 변경되었다면 어떻게 해야 할까요?

기획서가 변경되면... 사실 답없네요ㅎㅎㅎ 그냥 기존 코드 베이스를 싹다 수정해야 한다면 수정 해야겠죠. 허탈하게 웃을 뿐입니다.

- 디자인 작업이 완료 되었다면 어떻게 해야할까요?

UI디자인에 맞게 xml을 수정하고 data binding을 활용해서 ViewModel과 연동하면 됩니다. 문제가 있네요. ViewModel의 수정이 필요하게되면 ViewModel에 대한 테스트 코드 또한 수정해야하고... 

- 그럼, 서버에서 mock-up 데이터를 내려줄 수 있고 통신 프로토콜 방식에 대한 방식이 확정되었으면 어떻게 해야할까요?

data layer가 부재되어 있다면 data layer를 구현해야 하고 앞서 구현한 Presenter에서 API 요청을 보낼 모델을 사용하도록 합니다. json이 응답으로 오는 경우 json2pojo로 POJO 클래스를 뚝딱 만들면 되겠고, POJO와 ViewModel간 Adapter pattern으로 적용하여 기존 UI 로직 수정이 없도록 하면 개발이 끝나겠습니다.

우선 이러한 방식으로 회사에 적용해 볼까?라는 생각이 듭니다. 아직 제가 검증한 방법은 아니고, 이렇게 하면 어떨까 수준에서 나온 아이디어 입니다. 써보니 순수한 mvvm이 아니군요. 사실 click event 처리를 ViewModel에서해야 하나 Presenter를 만들어서 해야하나 현재 아리까리한 상황입니다. 글 보다는 그림으로 설명하는게 좋을것 같아 다음 글에서는 위에 너무 성의없게 작성한 글을 한번 visualization 하고 코드도 작성해서 설명해야겠습니다.

드디어 개인적으로 안드로이드 앱 아키텍쳐 패턴에 대해 해부해야 할 시간이 돌아왔습니다.

스프링으로 웹 애플리케이션 개발할 때는 MVC 패턴을 쓰는것이 표준이 되었지만 안드로이드 진영에서는 MVC, Uncle bob의 clean architecture, MVP, MVVM 등의 소프트웨어 아키텍쳐 패턴을 앱에 적용하려는 많은 시도와 노력들이 보였습니다. 더이상 기본 Model-View 아키텍쳐로는 유지보수 용이하고 테스트 가능한 앱을 만들기가 거의 불가능에 가깝고 이제 어느정도 안드로이드 앱 아키텍쳐에 대한 큰 흐름이 잡혀지는 느낌같은 느낌이 들어 인터넷에 정리된 것들을 다 훑어보고 날로 주어먹은 후 내용을 정리하려 합니다.

우선 기본적인 사항은 정리가 되었습니다. MVC는  안드로이드에 쓰기에는 부적합 한것으로 여겨지고, MVP, MVVM 중에 갑론을박이 조금 있기는 합니다만, 저의 주관으로는 MVVM을 쓰는게 현명해 보입니다. 둘다 SoC(Separation of Concern)을 잘 지키지만 MVVM이 좀더 View의 코드수를 훨씬 더 줄일 수 있습니다. 그리고 MVP에서 각 뷰, 프리젠터는 인터페이스를 정의하고 구현해야 하는데, Google data-binding을 사용하는 MVVM에서는 인터페이스를 정의하고 구현해야하는 수고가 없어졌습니다. Mark-up(XML)에 if-statement, for-loop등의 복잡한 로직을 넣지않고 ViewModel에서 단지 getter나 boolean을 반환하는 메소드만 호출하는 수준이면 MVP처럼 fully testable한 앱을 구현할 수 있습니다. 마크업에 대한 사용 규정은 팀원끼리 협의해야하겠습니다. 기술적인 내용외에 MVP 라이브러리 중 Square에서 만든 mortar가 방치되어 있는거나 reddit 쪽 쓰레드, 구글링을 통한 아키텍쳐 패턴에 관한 블로그를 봤을 땐 MVVM을 더 사용하고자 하는 움직임이 좀더 많게 보입니다.(수치 정량화 하진 않았습니다;;;) 

MVVM을 사용할 때는 View<->ViewModel 사이는 data-binding으로 이어주고 ViewModel<->Model은 RxJava로 통신하는 방식이 거의 표준으로 쓰이고 있습니다. 별도의 3rd party 라이브러리가 필요하진 않습니다. Dependency Injection을 위해 Dagger 2를 사용하고 HTTP 통신을 위해 Retrofit2를 쓰는 수준이면 기본적인 서비스 앱 구조를 잡기에 충분합니다. 이미 여러 샘플이 나와 있지만 저도 샘플 코드를 만들어야 하겠습니다. 우선 Learning Curve가 좀 높은 ReactiveX를 좀 해부한 후에 샘플 코드를 작성해야겠습니다. ReactiveX만으로도 할일은 태산이니까요ㅎㅎㅎ.