아키텍처 패턴이란

이번 글에서는 아키텍처 패턴이란 무엇인지, 어떤 아키텍처 패턴이 있는지에 대해 공부한다.

아키텍처 패턴이란

주어진 상황에서, 소프트웨어 아키텍처에 공통적으로 일어나는 문제에 대한 일반적이고 재사용 가능한 해결 방법

디자인 패턴의 정의와 상당히 유사하다. 둘 다 문제에 대한 해결이 패턴화된 것이라 그런듯하다.

다만 조금 다른 점은 아키텍처 패턴의 관심사가 좀 더 넓다는 것이다.

소프트웨어의 전체 아키텍처를 설계할때 발생하는 문제를 해결할때 아키텍처 패턴 사용을 고려하게 되고,
이후 좀 더 자세히 들어가서 각 모듈을 설계할때 발생하는 문제를 해결할때 디자인 패턴 사용을 고려하는 식이다.

소프트웨어 아키텍처의 각 패턴들을 공부해두면,
이전 개발자들은 어떤 문제를 만나서 어떻게 해결하려고 했는지를 배울 수 있다.

따라서 새로운 패턴의 이름을 외우고 무턱대고 사용해보려고 하는것보단,
직접 소프트웨어를 개발하며 문제점을 체감하고, 그 문제점을 해소해줄 수 있는 패턴을 찾아보는 방식이 가장 좋다고 본다.
학습 시간이 충분하다면 말이다.

 

그럼 어떤 아키텍처 패턴이 있는지 알아보자.

레이어 패턴

시스템을 레이어 Layer별로 나눠서 레이어별로 관심사를 나누는 식으로 설계하는 패턴.

대표적인 예시는 OSI 7계층이 있다.

네트워크 통신이라는 굉장히 복잡한 시스템을 계층별로 나눠서 문제가 발생했을때,

어느 계층에서 문제가 발생했는지 빠르게 확인하고 대응할 수 있다.

 

레이어 패턴은 독립적인 패턴으로 사용된다기보단 다른 패턴에서 기본적으로 활용되고 있는 것 같다.

예를 들어 iOS에서 많이 사용하는 아키텍처 패턴중에 Clean Architecture가 있는데,

여기선 전체 앱의 구조를 Presentation Layer, Domain Layer, Data Layer로 나눠서 관심사를 분리한다.

한 계층에 대한 변화가 계층간 인터페이스에 대한 변화가 아니라면, 다른 계층에 거의 영향을 주지 않는다는 장점이 있다.

이렇게 앞으로 살펴볼 모든 아키텍처 패턴이 앱을 계층별로 나눠서 관심사를 분리한다.

 

MVC 패턴, MVP 패턴, MVVM 패턴

가장 유명하고 또 많이 사용되는 패턴들이다.

워낙 좋은 자료가 많은데 이 글을 참고하길 권장한다.

처음 MVC 패턴을 공부할때 헷갈리게 만들었던 요소가 왜 Model과 View간에 결합이 생긴다는거지?!

였는데 위 글에서 그 의문을 해결할 수 있었다. 과거의 MVC는 모델과 뷰간에 결합이 있는 구조였기 때문이다.

 

그리고 애플의 MVC <-> MVP/MVVM이 어떻게 다른지도 잘 나와있다.

MVP와 MVVM에선 ViewController를 View로 취급하고 UIKit에 독립적인 Presenter와 ViewModel을 만드는데,

이는 테스트 가능성을 위해서라는걸 잘 알 수 있다.

다만 MVC에서 MVP/MVVM으로 가는 이유로 추가하고 싶은 것은 뷰 컨트롤러가 지나치게 비대해지기 때문이라는 것이다.

즉, 기능이 추가될때마다 뷰 컨트롤러가 비대해져서 힘든데, 뷰 컨트롤러는 테스트도 불가능하니

MVP, MVVM 같은 새로운 패턴을 고안해낸 것이다.

 

그리고 Presenter와 ViewModel의 차이에서 조금 빠진 부분이 있어보인다.

MVP에서 Presenter는 View를 너무 잘 알고 있다. 둘 사이에 강한 의존성이 존재하기 때문에 어떤 Presenter를 재사용하기가 어렵다.

따라서 Presenter와 View 사이에 1:1 관계가 성립한다.

물론 '완벽히' 똑같은 뷰가 여러군데 재사용된다면 Presenter도 재사용할수 있겠지만,

'완벽히' 동일하지 않다면 Presenter를 재사용하기 힘들 것이다.

반면 MVVM에서 ViewModel은 View를 모른다. View만이 ViewModel을 알고 ViewModel의 변화를 관찰하는 방식이다.

즉 View와 ViewModel이 느슨하게 결합되었다는 것이고 ViewModel을 재사용하기 좋다.

따라서 ViewModel과 View 사이에 1:N 관계가 성립한다. 그래서 완벽히 동일하지 않은 뷰라도 ViewModel을 재사용할 수 있다.

뷰는 뷰모델에서 필요한 Output만 bind하면 되기 때문이다.

뷰모델의 Output이 a, b, c, d, e라면 뷰 A에선 뷰모델의 a, b만 bind하고, 뷰 B에선 뷰모델의 b, c, d만 bind하고, 뷰 C에선 뷰모델의 a, e만 bind하는 방식이다.

물론 재사용성을 너무 고려하다가 뷰모델이 좀 비대해지는 경우도 발생할 수 있다. 다른 뷰 D, E, F...에서도 재활용하고 싶어서 뷰모델의 Output에 f, g, ...를 추가하면 당연히 비대해질 것이다.

 

아무튼 코드의 재사용성 측면에서는 MVP보다는 MVVM을 사용하는 것이 더 좋다고 볼 수 있다.

다만 데이터의 바인딩을 구현할때는 보통 RxSwift를 많이 사용하는데,

러닝 커브가 높은 기술이라서 처음 배울때 어려움이 있을 수도 있다.

 

사실 MVVM은 현재 앱스토어의 대부분의 앱에 적용되지 않았을까 싶을 정도로 iOS에서 많이 사용되는 패턴이다.

화면 전환 로직을 Coordinator로 분리한 MVVM-C, 비즈니스 로직을 Interactor로 분리한 MVVM-I같은 변형도 존재한다.

물론 패턴에는 정답이 없다. 화면 전환 로직을 분리하고 그 객체에 Navigator라는 이름을 붙여도 된다.

물론 좀 더 널리 알려진 패턴을 사용하면 다른 사람이 봤을때 이해가 빠르다는 장점이 있을 것이다.

 

ReactorKit

MVVM 같은 아키텍처 패턴들은 큰 그림에서 앱을 설계하는 것이라 코드상에서 구현할때는 개발자마다 다르게 구현될 수 있다.

MVVM을 적용할때 코딩 스타일을 통일하기 위해 사용하는 프레임워크 예시로 ReactorKit이 있다.

자세한 내용은 여기를 참고하자.

 

Clean Architecture

클린 아키텍처는 전체 앱을 구조적으로 분리하는 패턴이다.

크게 3가지 레이어로 분리하고, 레이어간의 의존 관계를 제한하여 핵심이 되는 레이어의 재사용성을 높였다.

화면이 보여지는 부분(UI)을 Presentation Layer로 나누는데,

이 부분은 보통 MVVM 패턴으로 구현하곤 한다. 그래서 보통 MVVM + Clean Architecture로 아키텍처를 구성한다.

 

개인적으로 특정 레이어들을 교체하기 용이하다는 점이 좋았다.

클린 아키텍처를 사용하면 Layer간 인터페이스를 추상화해서 특정 Layer 구현체만 교체하기 용이한 구조가 된다.

UI를 교체할땐 Presentation Layer만 교체하면 되고, 데이터를 읽고 쓰는 부분을 교체할땐 Data Layer만 교체하면 된다.

그래서 프로젝트를 할때 레이어를 교체하기 좋은 설계를 위해 클린 아키텍처를 채택해서 구현했던 경험이 있다.

 

클린 아키텍처 관련해선 이미 좋은 자료가 많아서 아래 링크를 남긴다.

 

Clean Architecture and MVVM on iOS

Clean Architecture는 모바일 개발을 어떻게 도와주는가? - (1) 경계선: 계층 나누기

 

참고로 클린 아키텍처도 다양한 구현 방식이 존재한다.

https://github.com/sergdort/CleanArchitectureRxSwift

GitHub - sergdort/CleanArchitectureRxSwift: Example of Clean Architecture of iOS app using RxSwift

https://github.com/kudoleh/iOS-Clean-Architecture-MVVM.git

GitHub - kudoleh/iOS-Clean-Architecture-MVVM: Template iOS app using Clean Architecture and MVVM. Includes DIContainer, FlowCoor

 

그 외의 패턴 (VIPER, RIBs, TCA, Clean Swift, ReSwift)

이 패턴들은 직접 사용해보지도 못했고, 이름만 들어본 수준이라 필요에 따라 하나씩 학습하고 내용을 추가할 예정이다.

RIBs와 TCA, VIPER 순으로 학습할 예정이다.