[SwiftUI] MVVM 아키텍처 패턴(2탄 - SwiftUI에서 나타나는 딜레마)
지난 포스팅에서 MVVM 패턴을 이해하기 위한 내용들을 정리했고, 이번 편에서는 SwiftUI에서의 MVVM 패턴에 대한 딜레마에 대해 다뤄볼까 한다.
아마도 한번이라도 SwiftUI에 MVVM 패턴을 적용하기 위해 구글링을 해봤다면 아주 침이 고이는 포스팅 제목이 보인다. 그건 바로 “Stop using MVVM for SwiftUI”. 해석하자면 SwiftUI에서 MVVM 패턴을 멈추라는 얘기이다. 다들 이게 무슨 소리인가 하며 들어가서 보게 되면 SwiftUI에 대한 구조적 특성을 매우 근본적으로 파악하며 작성된 글들이라는 것을 알 수 있고, 본인 또한 이러한 궁금증에 대해 고민해 봤던 적이 있어서 이번 포스팅을 통해 추가로 정리하기로 했다.
SwiftUI는 MVVM과 잘 맞는가?
SwiftUI는 선언적 UI 프레임워크로, MVVM 패턴과 잘 어울리긴 하지만 몇가지 측면으로 인하여 SwiftUI가 MVVM 패턴을 사용하기에 적합하지 않다는 의견이 나온다. 이러한 의견은 아마도 SwiftUI의 선언적 특성과 내장된 상태 관리 기능들에 대한 많은 고려를 하면서 나오게 된 의문일 것이다.
SwiftUI에서 MVVM 패턴이 적합하지 않을 수 있는 이유
1. 선언적 UI와의 중복
SwiftUI는 기본적으로 @State, @Binding, @StateObject, @ObservedObject등의 속성을 통해 상태 관리와 데이터 바인딩을 지원한다. 이러한 기능이 이미 MVVM 패턴의 ViewModel이 하는 역할을 내장하고 있기에 MVVM 패턴을 적용하면서 불필요한 중복이 생길 수 있다.
2. SwiftUI의 구조적 특성
SwiftUI에서는 View가 상태를 직접 추적할 수 있기에 ViewModel의 역할이 제한될 수 있는 것이다. 예를 들어, @State를 통해서 View에서 스스로의 상태를 직접적으로 관리할 수 있다. 이렇게 되면 ViewModel의 필요성이 줄어들고 MVVM의 중개자인 ViewModel의 역할이 축소될 수 있다.
3. 반응형 프로그래밍과의 중복
SwiftUI에서는 이미 Combine 프레임워크를 통해 반응형 프로그래밍을 지원하기에, 이를 통해서 @Published, @ObservedObject 같은 퍼블리셔와 구독 패턴을 사용하여 데이터 변경을 구독하고 처리할 수 있는데, 이도 마찬가지로 ViewModel의 역할과 중복된다.
언제 SwiftUI에서 MVVM을 사용할까?
복잡한 비즈니스 로직이 존재할 때
어플리케이션이 복잡한 비즈니스 로직을 포함하고 있거나, View와 분리된 상태 관리가 필요하다면 MVVM 패턴을 사용하는 것이 유리하다. SwiftUI의 선언적 프레임워크를 최대로 이끌어 내고자 굳이 이러한 로직은 View에서 사용하게 된다면 코드가 비대해지기 때문에 오히려 역효과를 낼 수 있기 때문이다.
유지보수성
팀 내에서 코드의 일관성을 유지하고, View와 비즈니스 로직을 명확히 분리하고자 할 때 MVVM 패턴을 분명 적용하지 않은것보다 팀의 협업에 도움을 줄 것이다.
테스트 용이성
비즈니스 로직을 ViewModel에 집중시킬 수 있기에, 그때 얻게되는 단위 테스트가 용이해진다는 점은 MVVM 패턴을 적용하기에 충분한 요건이라 본다.
결론
SwiftUI는 MVVM 패턴과 잘 어울리지만, 프레임워크 자체적인 성질을 고려한다면 적합하지 않을 수 있다. 특히 규모가 작은 토이프로젝트에서는 오히려 MVVM 패턴을 적용하는 것보다 SwiftUI의 프레임워크 특성을 살려 구성하는 것이 효율적일 수 있다. 하지만 규모가 커진다면 복잡한 비즈니스 로직이 생기고, 유지보수성은 필연적이기에 SwiftUI의 특성을 살리기 위해 굳이 MVVM 패턴을 적용하지 않는 것은 배보다 배꼽이 더 커지는 꼴이다.
그렇기에 프로젝트의 상황에 따라 MVVM 패턴을 적용하지에 대한 고민은 필요하다. 본인이 이번에 진행중인 프로젝트에서도 이러한 고민을 거쳤고, TCA 패턴과 고민을 하던 중 아직은 TCA의 이점을 제대로 알고 쓰기엔 다른 아키텍처 패턴에 대한 경험과 이해도가 충분하지 않았고, 프레임워크에 대한 이해도 또한 아직은 부족하다 생각했기에 좀 더 근본적으로 아키텍처를 분리하고 다룰 수 있는 MVVM을 사용하자 결심했다.