[iOS] MVC에서 MVI로, AI를 쓰기 전에 개발자가 미리 적용하자 (MVI + Clean Architecture with. SwiftUI

 
최근 AI가 정말 많이 발전했다.
예전에는 카카오톡에서 '개발 도와주세요', '개발 고수님들 찾습니다'라는 오픈 채팅방을 쉽게 볼 수 있었는데,
요새는 정말 보기가 힘들더라.
 
AI를 쓰는건 정말 좋은것 같다. 귀찮은 코드를 대신 작성해주고, 새로운 코드나 기술을 적용할 때, 쉽게 설명해주니까.
그런데 너무 AI 자체에 의존해서 생기는 문제들도 보여지고 있다.
 
특히 아키텍쳐나 패턴에 대한 지식이 하나도 없는 상태로 AI에게 코드를 맡겼다가, 유지보수가 불가능한 수준의 프로젝트가 생성되거나.
반대로 AI가 특정 아키텍쳐나 패턴을 적용해주었는데, 개발자가 이해하지 못해서 평생을 AI에게만 맡겨야 하는 불상사가 생기고 있다.
 
물론 AI가 더, 더 발전해서 개발자가 아무런 설계를 하지 않아도 되는 세상이라면 상관 없겠지만,
적어도 글을 쓰는 이 순간까지 개발자라면 유지보수가 좋은 코드를 작성하는 것이 중요하고, 그를 위한 설계도인 아키텍쳐/패턴에 대한 이해가 하나라도 있어야 하지 않겠냐는 의견이다.
 
처음 만난 좋은 선임분들께 MVVM으로 시작해서, 지금은 MVI + Clean Architecture에 대한 이해가 조금이나마 되었다.
상당히 어려웠고, 지금도 여러 패턴들을 왔다갔다 하다보면 헷갈릴 때가 가끔 있다.
 
그래서. 템플릿을 만들고 공유하기로 했다.
내가 쉽게 가져다 쓰기 위한 이유도 있고, 혹시나 직접 구글을 통해 정보를 찾아 헤메는 개발자들이 내가 만든 구조를 보고 MVI + Clean Architecture를 이해하는데 조금이나마 도움이 됐으면 좋겠다.
 

---

 

*들어가기 전 주의*

1. iOS 앱을 기반으로 하고 Swift로 작성했습니다.
2. MVVM, 의존성 주입, protocol, 옵저버 패턴 등, 기본 지식이 없으면 이해가 어려울 수 있습니다.
3. 테스트 코드는 추가할 예정입니다.
4. 이런 상태 관리 패턴과 아키텍쳐는 대규모 프로젝트에서 유리합니다. 규모가 작거나 테스트 전용 앱에서는 오버엔지니어링을 유발할 수 있습니다. 클린 아키텍쳐와 MVI 패턴을 꼭 적용하는 것만이 정답은 아닙니다.
 
궁금한 점이 있는 분은 댓글 또는 메일로 연락주세요.
 
GitHub - BLEV-Woo/CleanMVI-iOS

GitHub - BLEV-Woo/CleanMVI-iOS: iOS Clean Architecture + MVI + DI modular app template in SwiftUI

 
자세한 내용은 REAMME.md에 작성했으니, 여기에는 간단하게만 작성해본다.

---

전체 구조: Clean Architecture + Multi-Module

이 프로젝트는 단순히 파일 몇 개로 이루어진 패턴 예제가 아니다.
실제 대규모 서비스에서도 적용할 수 있도록, 물리적인 모듈 분리를 전제로 설계했다.
(물론 나는 아직 그 정도까지의 규모를 서비스해보진 못한것 같지만... 항상 염두하고, 공부하고, 적용하는게 개발자의 역할 아닐까)
 
전체 레이어는 크게 5가지로 나눠진다.
 
1. App: 앱의 진입점. 모든 모듈을 조립하는 역할을 한다.
2. Feature: UI와 화면 로직(MVI Store)이 위치한다.
3. Domain: 비지니스 로직의 중심. 순수 Swift로만 작성되고 UseCase와 Entity가 포함된다.
4. Data: 외부 API 호출이나 로컬 DB 접근을 담당하며, Domain의 protocol(Interface)을 실제로 구현한다.
5. Core: 네트워크 클라이언트, 공통 아키텍쳐 베이스 등, 전역에서 사용하는 유틸리티 모듈
 

MVI: 예측 가능한 단방향 데이터 흐름

이 템플릿의 핵심 UI 패턴은 MVI (Model-View-Intent)이다. SwiftUI의 선언적 UI와 잘 어울리는 패턴이다.
이를 더 구조화하고 강제하는 것이 그 유명한 TCA (The Composable Architecture)이다.
 
왜 TCA를 사용하지 않았냐고 묻는다면, 내가 알고 있는 TCA는 외부 라이브러리에 종속된다.
TCA를 프로젝트에 import하고, 이미 정해진 규격에 따라야하기 때문에 유연한 대처가 불가능하다고 생각했다.
MVI를 알아만둬도 TCA에 적응하기 쉬울 것이라는 생각도 든다.
 
MVI에는 State, Intent, Effect, ViewEffect가 있다.
 
왜 ViewEffect가 필요한가?
일회성 이벤트를 일반적인 State에 넣으면, View가 다시 그려질 때 얼럿이 중복으로 뜨거나 상태를 매번 수동으로 초기화 해야 한다. 이를 해결하기 위해 ViewEffect를 활용한다.

---

 
부족하거나 완벽하지 않을 수 있지만, 누군가 내 코드를 보고 도움이 됐으면 좋겠다.