[iOS] 정녕 SwiftUI와 딱 어울리는 아키텍쳐는 없는건가요

0. 서론

회사에서 혼자, 처음으로, 첫 프로젝트를 맡게 되었다. 그리하여 iOS 최소버전, 기술스택, 아키텍쳐까지 내 마음대로 정할 수 있었다.

iOS에서 기술스택이라 하면 가장 큰건 UIKit, SwiftUI 일 것이다. 새싹을 진행하며 UIKit을 단련하긴 했지만, 우리 회사 화면을 보니 양이 많고 커스텀은 나쁘지 않은 수준이라 UIKit보다는 SwiftUI쪽이 훨씬 빠르게 만들 수 있을 것 같아 SwiftUI로 정했다.

그렇다면 이제는 아키텍쳐만 정하면 끝이다.

... 뭐로하지...??

1. 아키텍쳐는 하나의 프로젝트에 하나여야만 하는가?

내 대답은 '절대 그렇지 않다' 이다. 간단한 뷰는 간단하게, MVC로 빠르게 쳐내는 편이 더 빠르면서도 심지어 가독성마저 좋다.

SwiftUI의 TabView를 예로 들어보자면, SwiftUI에서 TabView는 사실 State 변수 하나만 있으면 구현하는데에 문제가 없다. 그런데, MVVM 지키겠다고 TabViewModel을 만들고, 파일을 하나 새로 파서 해야 하는가?

이는 시간낭비일 뿐더러 가독성마저 떨어지게 된다.

복잡하면 복잡할수록 관리하기 쉬워지는 패턴을, 간단하면 간단할수록 관리가 쉬워지는 패턴을 선택해서 사용하는편이 좋을 것이다.

그래서 나는 아키텍쳐들을 대충 조사해봤다.

2. iOS 아키텍쳐 라고 검색하면 나오는 아키텍쳐들과 그에 대한 개인적인 생각

1. MVC

SwiftUI에는 ViewController라는 개념은 없지만, 그냥 View파일에 모든 프로퍼티와 메서드를 때려 박는걸 MVC로 칭하도록 하겠다. 이는 앞서 설명했듯 TabView같은 뷰에서 활약하기 좋을 것이다.

2. MVVM

iOS를 하는 사람들은 익숙할만한 패턴이다. Model - View - ViewModel로 분리해서 관리하는 패턴이다. SwiftUI에선 단순하게 MVC에서 프로퍼티와 함수를 뷰모델로 빼면 끝이다. 그래서 프로퍼티와 함수가 어느정도 있지만 간단하면서, Service 레이어와 통신하는 뷰 이면 사용할만한 아키텍쳐가 아닐까 싶다.

3. MVI

사실 이 글을 쓰게 된 이유다. 결과적으로 나는 회사 프로젝트에서 가장 크게 주축으로 잡을 아키텍쳐를 MVI로 잡게 되었다. 후술 하겠지만, TCA는 아니다. MVI로 잡은 이유는 여러 Service 레이어와 통신해야 하고, 관리해야하는 부분이 많다고 생각해서 유지보수하기 유리한 단방향 아키텍쳐, MVI를 선택했다.

4. TCA

요즘은 좀 나아졌다곤 많이 듣긴 했지만, 회사의 프로젝트를 (비지니스 타임이 중요하고, 그 하나로 회사에 영향이 가는) 하나의 라이브러리에 의존시킨다는 것 그 자체가 너무 무책임 하다고 느껴졌다. 나중에 TCA가 지원이 끊기거나 문제가 생기면 어떻게 할것인지, 도저히 상상조차 가지 않는다. 하나의 프로젝트가 하나의 라이브러리에 의존시킨다는것, 그 자체가 너무나도 큰 리스크 아닌가?

5. REDUX

러닝커브도 너무 높고, 할려고 하는일에 비해 하는 일이 너무 많은것 같아 제외시켰다.

3. 그래서 고민 끝에 MVI를 선택하다.

TCA가 MVI를 기반으로 만들어졌고, ReactorKit도 MVI를 기반으로 하고 있기에 나중에 iOS 인력을 뽑거나 해도 큰 지장이 없을 거라는 판단에 MVI로 선택했다. 또한 하나의 라이브러리에 의존적이지도 않고, 단방향 아키텍쳐라는 장점에 유지보수도 용이하겠다 라는 판단이다.

다음 글은 아마 회사에서 적용시킨 MVI패턴에 대한 이야기를 해볼까 한다.