[iOS] SwiftUI 프로젝트에서 MVVM-C를 선택한 이유와 고민들

 

프로젝트를 새롭게 시작하면서 디자인 패턴에 대한 고민이 많았다.

특히 이번 프로젝트는 내가 처음으로 리드 역할을 맡은 프로젝트였고, SwiftUI에 익숙하지 않은 팀원도 있는 상황이었다.

따라서 팀 전체의 러닝 커브를 낮추면서도 유지보수가 쉬운 구조를 선택하고자 했다.

 

왜 MVVM-C를 선택했는가?

 

사실 가장 먼저 고려한 것은 TCA + Tuist 였다.

하지만 여러 고뇌 끝에 결과적으로는 택하지 않았고, 관련 글을 하단에 첨부하겠다.

https://dawning-record.tistory.com/106

리드를 맡으며 한 고민들과 지금의 생각들

 

 

선택된 구조는 MVVM(Model-View-ViewModel) 패턴이었다.

가장 대중적인 구조라고 생각했고, 비교적 러닝 커브가 낮으며 팀원들이 이해하기 쉬운 구조라고 생각했기 때문이다.

 

이전 프로젝트에서는 Route와 path, navigationDestination을 이용해 화면전환을 관리하고 있었고, 루트뷰에 해당하는 탭뷰 하나에서 모든 화면전환 로직을 관리하고 있었다.

프로젝트 초기에는 별 문제가 없는 듯 보였으나, 프로젝트가 장기화되고 여러 뷰와 기능들이 추가되며

화면 전환이 복잡해지면서 뷰의 책임이 무거워지는 문제를 경험했기에 이를 개선하기 위해 Coordinator 패턴을 함께 도입해보기로 했다.

 

결과적으로 우리는 SwiftUI + MVVM + Coordinator 구조, 즉 MVVM-C 형태로 프로젝트를 진행하게 되었다.

 

 

Coordinator 패턴이란?

 

Coordinator 패턴은 화면 전환의 책임을 전담하는 요소를 따로 두는 방식이다.

이를 통해 뷰나 뷰모델은 화면 전환에 대한 책임에서 벗어나, 본연의 역할에 집중할 수 있도록 도와준다.

 

• View: 사용자에게 UI를 보여주고 ViewModel과 바인딩
• ViewModel: 비즈니스 로직 처리 및 상태 관리
• Coordinator: 화면 전환 처리

 

즉, View나 ViewModel에서 화면 전환을 직접 하지 않고, Coordinator에게 “요청”만 하는 구조이다.

 

 

현실적인 고민들

 

패턴을 도입한 취지는 좋았지만, 프로젝트를 진행하면서 몇 가지 현실적인 고민이 생겼다.

 

 

1. Coordinator는 어디서 생성하고, 어디서 관리할 것인가?

 

Coordinator는 앱 전체 흐름을 제어하는 중요한 객체이기 때문에, 이를 어디서 생성하고 유지할지에 대한 명확한 기준이 필요했다. 보통 AppCoordinator 혹은 RootCoordinator를 만들고, 이 안에서 하위 Coordinator를 관리하는 방식이 일반적이다.

 

 

2. ViewModel이 Coordinator를 알아야 하나?

 

Coordinator를 ViewModel에서 호출하려면 ViewModel이 Coordinator에 대한 참조를 가져야 한다.

그렇다면 ViewModel을 생성할 때 Coordinator를 주입해야 하고, 이 과정에서 생성자 체인이 깊어질 수 있다.

 

예를 들어:

 

• AppCoordinator → FeatureCoordinator → ViewModel 생성
• 이 경우, ViewModel을 생성하는 모든 계층이 Coordinator를 전달해야 한다.

 

이 과정에서 의존성의 깊이가 깊어지고, 각 계층이 모두 Coordinator를 알아야 한다는 문제가 발생할 수 있다.

 

 

3. View에서 Coordinator를 다뤄도 괜찮은가?

 

우리는 일정상 2주라는 짧은 시간 안에 결과물을 만들어야 했기 때문에, 현실적인 타협이 필요했다.

그 결과 View에서 Coordinator를 직접 호출하는 구조를 일부 도입했다.

엄밀히 말하면 View는 ViewModel만 알고 있어야 한다고 생각하지만, 일정상 이 구조가 가장 빠르고 효율적이었다.

 

이런 구조는 엄격한 아키텍처 기준에는 어긋날 수 있지만, 러닝 커브가 낮고 빠르게 구현할 수 있다는 점에서 현실적인 선택이었다.

 

 

아직 남은 고민들

 

아직까지도 명확한 해답을 내리지 못한 고민이 있다.

 

• Coordinator를 ViewModel에 주입하면, 결국 어디까지 이 객체를 알고 있어야 할까?
• 모든 ViewModel이 Coordinator를 갖고 있어야 하는가, 아니면 일부만?
• 이 구조는 재사용성과 테스트에 어떤 영향을 줄까?

 

이런 고민들은 프로젝트를 진행하면서 계속 부딪히게 되었고, 구조 리팩토링을 하기로 한 지금 팀원들과 상의를 해보며 해결해 나갈 생각이다.

 

---

 

마무리하며

 

아키텍처를 선택하고 적용하는 일은 항상 정답이 없는 고민의 연속인 것 같다.

특히 SwiftUI와 같은 비교적 새로운 프레임워크에서는 실험과 타협이 동반되기 마련이다.

이번 프로젝트를 통해 MVVM-C 구조에 대해 실질적으로 고민하고 적용해볼 수 있었던 점은 정말 큰 배움이었다.

 

향후 더 나은 구조를 고민하고 개선해나가며, 팀원들과 함께 성장해 나가고 싶다.