[RxSwift + MVVM] 1. iOS의 모바일 아키텍처 패턴

1. 아키텍처 패턴이란?

소프트웨어 공학은 건축 공학을 많이 모방하여 연구되었습니다.

기본적으로 계획 - 설계 - 시공이 건축이라면,

계획 - 설계 - 구현이 소프트웨어 개발이겠죠.

 

아키텍처 패턴은 설계항목에 들어가는 방법론입니다.

위키피디아에서는 이렇게 설명되어 있습니다.

아키텍처 패턴(architectural pattern)은 주어진 문맥 안에서 소프트웨어 아키텍처의 공통적인 발생 문제에 대한 일반적인, 재사용 가능한 해결책을 의미한다. 아키텍처 패턴은 소프트웨어 디자인 패턴과 비슷하지만 더 넓은 범위에 속한다. 아키텍처 패턴은 소프트웨어 공학의 다양한 문제를 해결하는데, 예를 들어 컴퓨터 하드웨어 성능 제한, 비즈니스 위험의 최소화와 고가용성을 들 수 있다. 일부 아키텍처 패턴은 소프트웨어 프레임워크 안에 구현되어 있다.

쉽게 생각해보면, 소프트웨어 공학 연구들을 통해서 만들어진 보편적인 설계 패턴이라고 생각하시면 됩니다.

 

2. 왜 알고 사용해야 할까?

조금만 생각해보면 간단한 부분입니다.

옛날의 개발문화로 생각해보면, 예전에는 일반적인 소프트웨어의 규모가 그다지 크지 않았기 때문에, 혼자서 진행하는경우가 많았죠. 그래서 본인이 직접 개발하며 시행착오를 겪으며 개발하는게 일반적이었다면..

현재의 개발은 그렇지 않습니다.

소프트웨어의 규모는 늘어나고있고, 데이터는 정말정말 방대해지고 있습니다.

그래서 아키텍처 패턴을 이용하면, 아키텍처 패턴이 아닌 개인이 직접 패턴을 만들며 설계하여 구현한것과 비교하여 이런 차이가 있지 않을까 생각해 봅니다.

 

* 협업, 인수인계 능률 증가

당연한얘기지만, 구조화되고 많이 알려져있는 패턴이기 때문에 서로에게 익숙하겠죠.

가장 중요한 포인트 같습니다.

* 효율적인 코드 작성

여러사람들의 시행착오를 거쳐 개발된 패턴인 만큼, 많은 문제점들이 해결되어있을 가능성이 큽니다.

* 개발 속도 증가

복잡하게 패턴부터 설계할 필요가 없습니다. 미리 공부해놓고 프로젝트에 적용하면 됩니다.

MVC를 예로 들어도, 일종의 규격화가 되어있기 때문에 Model을 만들고 View를 만들고, Controller로 연결해주면 됩니다. 아키텍처 패턴을 떠나 소프트웨어 개발 패턴들이 가져다주는 장점이죠.

 

3. iOS에서 사용하는 몇가지 아키텍처 패턴들

MVC 패턴

라이프사이클을 대략적으로 정리하면..

* View와 Controller는 1:1 관계입니다.

1. 사용자가 View에서 행동을 하면..

2. View에서 Controller로 데이터를 입력합니다.

3. Controller는 Model에 데이터 수정을 요청합니다.

4. Model은 View에 수정된 데이터를 간접적으로 반영시킵니다.

 

가장 보편적이며, 단순한 패턴입니다.

Model, View, Controller로 쉬운 설계가 가능하죠.

 

하지만 몇가지 문제점이 존재하는데요.

* 일단 Model과 View가 의존적이기때문에, 단위테스트가 쉽지 않습니다.

(이후 아래부터 나오는 단위테스트에 대한 어려움은, View와 그 외의 것들을 떨어트리지 못해서 진행하는 어려움에 대한 이야기입니다.)

* 프로젝트가 커질수록 Controller의 할일이 많아지기 때문에, 코드가 길어집니다.

 

Apple MVC 패턴

라이프사이클은 MVC와 비슷하고, ViewController의 Apple CocoaFramework의 라이프사이클을 따릅니다.

 

정말 쉽고 간편합니다.

CocoaFramework에서 Cocoa의 의미 자체가, 자바와 대비되는데요, 

자바가 커피에서 이름을 따왔다면, CocoaFramework의 Cocoa는 어린아이도 마실수있는 코코아처럼 누구나 쉽게 이용할수있는 프레임워크임을 뜻한다고 하네요.

코드도 당연히 짧습니다.

 

하지만 이또한 몇가지 문제점이 존재하는데요,

* 프로젝트 규모가 커질수록 ViewController가 복잡해집니다.

* 따라서 유지보수도 힘들어지고, 단위테스트도 절대 수월하지 않습니다.

 

MVP 패턴

라이프사이클은 이렇습니다.

* View와 Presenter는 1:1 관계입니다.

1. 사용자가 View에서 행동을 하면..

2. View에서 Presenter로 데이터를 입력합니다.

3. Prsenter는 Model에 수정을 요청하고

4. Model은 다시 Presenter로 반환을 해줍니다.

5. Presenter는 다시 View로 데이터를 반영시킵니다.

 

MVC와 비슷하지만, Model이 데이터를 View가 아닌, Presenter로 보내준다는데에서 차이점이 있습니다.

따라서 View와 Model간의 의존성이 적고, 유닛테스트는 비교적 수월해집니다.

기능 수정, 추가도 편하겠죠.

 

하지만 이또한 몇가지 문제가 있는데요..

* 프로젝트가 커질수록 Prsenter또한 MVC의 Controller처럼 커질수밖에 없습니다.

* View와 Presenter는 1:1관계이기도하고, View의 통신구가 Presenter밖에 없기 때문에 상당한 의존성이 따릅니다.

* 그리고 View의 코드도 App에서 UI구현이 간단하지가 않아서 코드가 길어질수밖에 없습니다.

 

MVVM 패턴

라이프사이클은 이렇습니다.

* View와 ViewModel은 N:1 관계입니다.

1. View는 적당한 ViewModel을 선택하여 구독합니다.

2. ViewModel은 Model에게 데이터 수정을 요청합니다.

3. Model은 ViewModel에게 수정된 데이터를 반영합니다.

4. ViewModel은 수정된 데이터를 받아 가공합니다.

5. View는 구독한 ViewModel에서 가공된 데이터를 받아 화면에 반영합니다.

 

View가 적당한 ViewModel을 선택하고, 데이터 수정을 기다리며 수정된 데이터를 받아서 화면에 보여주는 방식인데요.

구독에 관한건 다음장인 옵저버 패턴에서 다루겠습니다.

View와 Model은 철저하게 분리되어 있습니다.

View와 ViewModel사이에도 의존성이 줄어듭니다. ViewModel에서 받는 입력이 꼭 View에서 직접 전달할 필요가 없죠. 애초에 1:N을 염두에두고 설계하기때문입니다.

 

하지만 이 또한 몇가지 문제점이 발생합니다.

* 코드는 결국 크게 짧아지지 않습니다.

구체적으로 말하면, 제법 규모가 있는, ViewModel을 여러개의 뷰에서 쓸때나 조금 기대해볼만 합니다. 규모가 작은 프로젝트에서는 오히려 더 길어질수가 있죠.

* ViewModel의 설계가 쉽지 않습니다. 1:1의 관계가 아니기 때문에, 다양한 가능성을 생각해야합니다.

* 짧게는 옵저버 패턴, 길게는 리액티브 프로그래밍을 생각해야할 만큼 러닝커브도 제법 있는 편입니다.