iOS 아키텍처(MVC, MVVM, ReactorKit, VIPER)

안녕하세요! 오늘은 개발하면서 좀 더 효율적으로 개발하는 생각들이 담긴 여러 아키텍처들에 대해 알아볼꺼에요.

크게 MVC, MVVM, ReactorKit, Viper 순으로 알아볼려 해요.

이중에서 Viper는 추가 포스팅을.. ㅋㅋ;; 그럼 시작해보겠습니당

우선 아키텍처란 뭘까용?

아키텍처는 건축학이라는 뜻이래요. 즉 개발에서의 아키텍처는 개발 설계같은거죠..? 방법은 여러가지가 있겠지만.. 지금까지 사람들이 개발해오면서 요런게 좋다! 하는게 유명해졌을 것이고.. 그런게 바로 MVC, MVP, MVVM 등등.. 의 아키텍처인 거죠. 아키텍처도 결국 좀 더 효율적이고, 불편했던 것을 수정하면서 만들어진 것이기 때문에 여러 아키텍처들과 비교를 하면서 설명을 하면 이해가 잘 되더라구용 그래서 iOS에서의 가장 기본적인 아키텍처인 MVC 패턴을 먼저 소개해볼까 합니당

MVC 디자인 패턴

MVC 디자인 패턴은 애플에서 권장하는 가장 기본적인 아키텍처라고 알고 있어요. View와 Model, Controller로 이루어진 아키텍처이죠.

• View: UI요소.. 버튼이라던지.. 이미지라던지..
• Controller: UI요소들을 컨트롤(상호작용)하는 코드를 작성하는 부분이에요. 버튼이 클릭했을때의 액션이라던가.. 그런부분들은 컨트롤러에서 담당해용
• Model: 로직, 데이터 등등.. 네트워크 통신을 한다던가..

그림으로 보면 요런 흐름인데, 사실상 코드로 구현하다보면 요렇게 구연하게 되죠 ㅠㅠ..

View를 따로 파일을 만들어서 Controller에서 불러와서 사용을 해도 되지만, 뷰랑 컨트롤러는 밀접한 관계..? 가 있기 때문에 요렇게 작성하게 되는 것 같아요

사실상 Controller와 Model 이죠 😅

이렇게 MVC패턴을 사용하면 장점이 뭘까요?

MVC 패턴은 가장 기본적인 디자인 패턴이라 그런지 구조가 심플해요.

• 그래서 개발속도가 빨라요.
• 구조가 심플해서 배우기도 쉽구요.

하지만 MVC의 단점은

구조가 비교적 단순하다 보니 코드가 뭉쳐있는 경향이 있어요. 특히 뷰컨트롤러에요.

• ViewController에 코드가 몰빵되어 있는 단점이 있어요.(사실 Model이 없는 경우도 있으니..)
• 그러다보니 유지보수 면에서도 문제가 생길 수 있구요.

그래서 MVC로 개발을 하다가 뭔가 아쉬운거에요.. 그래서 이것저것 새로운 시도를 하다가 MVVM 같은 패턴이 나왔다고 생각해요.

MVVM 디자인 패턴이란..?

MVC 패턴에선 ViewController에 코드가 몰빵되어 있다는 아쉬움이 있었어요. 그래서 이를 해결하기 위해 기능을 좀 더 나누어서 코딩하기로 시도를 한 것중 하나가 MVVM 패턴인거죠. MVVM 패턴은 MVC패턴에서 View에 대한 Model인 ViewModel을 하나 더 추가된 패턴이라고 생각하시면 되요.

• Model: 로직, 데이터 등등.. 네트워크 통신을 한다던가..
• View: View + Controller..
• ViewModel: View에 대한 Model 이에요. View에 들어갈 데이터들 + 해당 뷰의 로직 등등..

ViewModel과 Model.. 똑같아 보이죠..? 저도 애매하다곤 생각하는데, Model은 전체적인 큼지막한 로직들을 작성해주면 되고(네트워킹 같은..) ViewModel은 View에서 사용되는 데이터라던가..(예를들어서 설정창에 들어갈 기본적인 text Array 라던가..) 필요 로직들을 작성해주면 되는데, View에만 있는 로직들은 ViewModel에서 작성해주시면 되구요, 큼지막한 로직들은 Model에 작성되어 있을테니, ViewModel이 Model기능을 가져와서 사용해주는식으로 하면 될 것 같아요. 정리하면 ViewModel이 View에 대한 로직 + 필요시 Model로직부분을 가져오고 + View에 대한 데이터를 가지고 있는게 ViewModel이고, 이런 ViewModel을 ViewController(+View)가 가져와서 사용하는 형식인거죠

ViewModel을 좀더 자세히 설명해보자면, ViewModel은 View에 대한 데이터, 로직들을 가지고 있다고 했자나요? ViewModel은 View에 대한 로직들을 가지고 있기 때문에, 상태값을 가질 수 있어요. 이게 무슨얘기냐면.. 예를 들어서 로그인 과정에서 패스워드가 8자리 이상일 경우만 로그인 버튼이 활성화된다는 기능을 구현한다면, 비밀번호를 입력받은 TextFeild에서 텍스트가 입력받은 Action 부분은 Controller에서 담당을 할 거에요. 그리고 textField 안의 텍스트 길이가 8자리 이상인지 유무 로직부분은 ViewModel에 있을 거구요. 로직을 통과 했을 때 가능하거나, 불가능 하거나 하는 Bool값이 있죠? 이렇게 로직을 시행했을 때 성공했을때, 실패했을때와 같은 상태값이 존재하는데, 이를 ViewModel에서 관리해주게 되면, 해당 기능이 잘 작동되는지 테스트를 할 때 굳이 빌드를 해볼 필요가 없이 Unit Test를 통해 ViewModel값에 데이터를 넣었을 때 상태값이 잘 나오는지 유무만 확인하면 되기 때문에 좀 더 모듈화가 되서 MVVM을 사용하면 좀 더 테스트하기 좋아진다고 해요.(Testable 하다 라고 말하더라구요 ㅋㅋ;;) 로그인 인증같은 큼지막한 로직은 Model에서 작성을 하고, ViewModel에서 가져와서 사용하는거구용.

그럼 MVVM의 장점은 뭘까요..?

우선 MVC에 비해 View에 대한 ViewModel이 하나 더 생겼기 때문에, ViewController가 가벼워졌겠죠?

• MVC의 단점인 ViewController 몰빵현상이 사라졌어요.
• MVC보다 코드가 정리된 느낌입니다
• 코드가 분리되었기 때문에 재사용성 + 유지보수 면에서 좋아지겠죠..?
• ViewModel로 인해 Testable 해지구요

요런 장점들이 있다고 생각합니다.

반면에 MVVM의 단점은

• ViewModel이 딱 이거다! 라는 표준화된 틀이 없고 View에 대한 Model이라는 애매한 규칙만 있어서, 사람마다 ViewModel이 다르다고 해요.. 협업에서 이 부분이 좀 애매해지죠
• ViewModel이라는 파일이 하나 더생기기 때문에 파일수가 많아져요
• MVC에 비해 복잡해졌죠.. 코드를 나눴기 때문에 MVC에 비해 개발속도가 느려요.

ReactorKit

reactorKit은 전수열님이 만드신 프레임워크로, 단방향 데이터흐름을 가진 아키텍처 구조를 가지고 있어요.

ReactorKit이 생긴 이유는..?

MVVM과 마찬가지로 MVC에서 컨트롤러 부분이 무거워지고, MVVM과 함께 RxSwift를 같이 사용했을때 상태값관리가 어렵단 문제점을 발견하고 이를 해결하고자 만들었다고 해요. 그래서 MVVM과 마찬가지로 MVC에서 View에대한 Model을 가진 ViewModel 같은 Reactor라는걸 가지고 있는데, 데이터 흐름이 컨트롤러 -> 리액터 로 가서 핑퐁하듯 리액터 -> 컨트롤러로 메소드가 호출되는 단방향 흐름의 아키텍처인거죠.

그림으로 보면 요런 느낌입니다.

reactor가 ViewModel 느낌이구요. 역시 네트워킹같은 큼지막한 Model 부분을 Reactor에서 가져와서 컨트롤러로 전달해주고 있습니다. 단 컨트롤러에서 Action을 Reactor로 전달받으면, 로직 수행 후 상태값을 컨트롤러로 주는 단방향 형식이기 때문에, 상태관리가 간결해지는 장점이 있습니다.

ReactorKit의 장점은

• MVVM과 같이 뷰컨트롤러가 가벼워지고, 테스트하기 좋아졌어요.

• RxSwift 기반으로 만든 것이기 때문에, RxSwift의 모든 기능을 사용 가능하구요

• 데이터가 단방향 흐름이기 때문에, 상태값관리가 편해졌고, 중간상태를 reduce() 라는 메소드로 관하기 때문에 상태관리가 간결해졌습니다.

• 기본적으로 View나 Reactor 프로토콜이 적용되었기 때문에 코드가 깔끔해집니다.

• 부분적으로 아키텍처를 적용할 수 있다네요..

  
  

ReactorKit 단점은..

• 역시나 파일수가 많아지구요..
• MVC에 비해 개발속도가 느려지겠죠..
• 그리고 또 뭐가있을까요.. ㅋㅋ;;

다음은 Viper라는 아키텍처에 대해 알아보겠습니당

Viper 아키텍처란 뭘까요..?

View, Interactor, Presenter, Entity, Router로 구성된 아키텍처 입니다. Viper 아키텍처 역시 코드를 분리시켜서 재사용성과 테스트가 용이한 아키텍쳐라고 해요.

단일책임원칙(링크)를 기반으로 하는 아키텍처라고 하네요.

• Entity: 단순 데이터 모델 입니다.
• Interactor: 데이터 모델을 어떻게 사용할지를 조작하는 로직을 담당. 오로지 데이터 작업만..
• Prsenter: Interactor에서 가져온 데이터를 가지고 뷰를 "언제" 뿌릴지를 결정하는 로직.. 추가로 Router를 통해 어떻게 화면전환을 할지도 가져옴
• View: View + Controller, Present에서 이렇게 뿌려라! 라고 하는대로 뿌려줌.
• Router: 어떻게 화면전환을 할지에 대한 부분을 Presenter로 전달

대략적인 흐름을 그림으로 보자면..

기본적으로 화면기준으로 생각을 하게 되니깐..(프로세스 단위로 보는게 좋다곤 하더라구요ㅠㅠ..) View(ViewController)에서 시작을 해보면

ViewController에서 Presenter를 가져와서 이걸 통해서 뷰를 업데이트 하겠죠..? 약간 ViewModel 느낌으로.. ViewController에선 액션만 보내주면 Presenter가 알아서 해줄꺼에요.. 상태값같은걸로 뷰를 업데이트 하게 될 거구요.

Present는 데이터 모델들을 어떻게 처리할지를 가지고 있는 Interactor와 상호작용하면서 판단을 할거고.. 만약 화면전환이 이루어져야 한다면, Router에서 어떻게 전환할껀지 판단을 가져와서 ViewController로 전달하는식으로 진행이 되는 것 같아요.

Viper는 알아가는 아키텍처라.. 사용해보면서 경험한 장단점은 아직 없지만.. 알아본 결과..

Viper의 장점은..

• V,I,P,E,R 역할이 명확하게 구분된다는 점..분리가 되어 재사용성이 좋아지겠네요
• 역할이 잘 나눠졌기 때문에, 기능추가가 편하고요. 유지보수가 좋아지겠네요
• UI로직이 분리되어 있기 때문에, 역시 Testable합니다

단점은..

• 명확한 가이드가 없고, 정보가 별로 없다..
• 역할이 잘 분할되어 있기 때문에, 앱 기능 하나를 정해도 이를 VIPER로 나눠서 작업을 해줘야하 하기 때문 고민이 많이 필요하다..
• 또 뭐가 있을까요..

오늘은 여러 아키텍처들에 대해 알아봤습니당. Viper 아키텍처는 추가로 예제 프로젝트를 진행하면서 추가로 더 깊에 알아볼 예정이에요. 원래는 Viper만 할려했는데, 하다보니 요렇게됬네용 ㅋㅋ;;

코로나 조심하시구요! 건강이 최곱니다. 그리고 제가 추가로 제 블로그에 채팅 기능을 넣었어요! 바로 채널톡 에서 지원해주는 기능인데, 재밌는 기능인 것 같아요. 혹시 iOS 관련 궁금하신거나.. 심심하시면 톡해주시면 저한테 톡으로와서 바로 답변드릴 수 있어요. 아직 톡이 온적이 없는데.. 재밌을 것 같아용 ㅋㅋ

채널톡 링크: https://channel.io/ko

그럼 다음 포스팅은 VIPER 예제 프로젝트로 찾아뵙겠습니당.

참고

• turcan9389님 블로그
• 브랜디 블로그
• 안정민님 -slideShare

추가로 혹시 iOS 앱 개발이 아직 미숙하다고 느끼시고 이 강의를 안들어 보신 분은 edWith - 부스트코스 iOS 강의를 꼭 들어보시는걸 추천드려요. 카카오톡 오픈톡방에 iOS 부스트코스 오픈톡방도 있으니 한번쯤 들어오셔서 swift 질문도 하고 정보도 공유하면 좋을 것 같아요.

• Naver - Edwith - 부스트코스 iOS

• 부스트코스 iOS 카카오톡 오픈톡방