[iOS 5주차] 아티클 스터디: 왜 모바일 앱 개발에서도 아키텍처가 중요한가? - MVC, MVP, MVVM, Clean Architecture
2
내일배움캠프-iOS-5기-본캠프
목록 보기
32/35
💭
사전캠프에서 읽었지만 글로 작성하지 않았던 내용
앱을 직접 만들어보면서 중요성이 상기됨
[Medium] 왜 모바일 앱 개발에서도 아키텍처가 중요한가?
2018.05.20. 작성 / 읽기 5분 소요
왜 모바일 앱 개발에서도 아키텍처가 중요한가?
1. 백엔드 프리젠테이션 로직이 단순해지고 있다 -> 프론트는 더 복잡해지고 있다
- 모바일 성능이 좋아지면서, 서버에서 따로 로직을 처리할 필요가 없어졌다.
- 서버는 간단한 데이터 저장 및 가공을 하는데에 그치는 경우가 많다.
- 간단한 서버만을 구현하거나 (Node.Js 등), 서버리스(Serverless) 형태로 구성하는 경우가 많아짐 (Firebase 등)
2. 백엔드 환경에서 잘 들어맞던 MVC 구조가 모바일에는 별로 큰 도움이 안 된다
- 모바일 환경은 Model, View, Controller를 명확하게 구분해주지 않는다.
- 뷰: 안드로이드는 XML, iOS는 스토리보드 및 XIB 가 전부.
UI 로직이 들어갈 여지가 적음. - 컨트롤러: 뷰 레벨의 기능 제약으로 인해 컨트롤러가 모두 떠안는 구조.
iOS에서는 컨트롤러를 아예 뷰컨트롤러라고 부름.
안드로이드의 경우 액티비티(Activity)에서 작은 단위의 앱 역할까지 해야됨. - 모델: 안드로이드는 SQLite와 룸(Room) 제공
iOS는 SQLite와 코어데이터(Coredata) 제공 / 써드파티로 렘(Realm) 채용 가능
그러나 모델 레이어에 대한 별도 구조는 제공하지 않고 개발자의 재량에 맡겨짐.
모델 계층의 일이 컨트롤러의 부담이 되거나, 부적절한 계층 분리로 모델 계층이 프레젠테이셔노과 도메인 로직을 갖는 이상한 상황도 생김.
- 뷰: 안드로이드는 XML, iOS는 스토리보드 및 XIB 가 전부.
3. 모바일 환경만의 독특한 특성들
- 뷰 상태가 매우 복잡하고 비동기 처리가 많다.
- 일련의 순차적 흐름으로 뷰 로직을 처리하는 게 불가능한 경우가 많음
- 이에 따라 구조화되지 않은 형태로 코드를 짜기 쉽상임
- 결과적으로 하나의 컨트롤러 파일이 비대해지고 로직 흐름이 비단선적이게 됨
- MVP, MVMM, 클린 아키텍쳐(Clean Architecture) 중심 앱 개발의 이점
- 개발 속도: 몇 배는 빨라짐 (주의: 개인차 있음)
- 유지보수성: 1년 뒤에 다시 코드를 봐도 즉시 어디를 고쳐야하는지 알아차릴 수 있다. 앱 전체에 영향을 줄 수 있는 기능을 수정할 경우라도 클래스 두어 개 정도의 수정으로 쉽게 대응이 가능하다.
- 확장성: 기능 확장에 대한 두려움이 (거의) 없어진다. 기획자가 급격한 사양 변경을 요청해도 웃으면서 대처할 수 있다.
- 코드 품질: 다른 엔지니어에게 코드를 보여줘도 부끄럽지 않다.
- 가독성: 별 문서 없이도 금방 프로젝트 구조의 이해가 가능하다. 일이 많아지면 언제라도 다른 엔지니어에게 일을 인계할 수 있다.
ChatGPT 요약
- 백엔드와 프론트엔드의 차이: 요즘은 서버(백엔드) 쪽에서는 간단한 데이터 저장이나 처리만 하고, 실제로 화면을 구성하는 일(프론트엔드)이 더 복잡해지고 있음. 그래서 모바일 앱이나 웹 프론트엔드 개발이 점점 중요해지고 복잡해짐.
- 기존 방식의 한계: 전통적인 MVC(모델-뷰-컨트롤러)라는 구조는 서버 개발에는 잘 맞았지만, 모바일 앱에는 맞지 않음. 모바일에서는 화면 처리나 이벤트 관리가 복잡해서 기존 방식으로는 한계가 있음.
- 모바일만의 특성: 모바일 앱은 다양한 화면 상태를 처리하고 비동기(여러 작업을 동시에 처리하는 것) 처리도 많아서 코드가 매우 복잡해짐. 그래서 관리하기 힘든 상황이 생기고, 코드가 점점 더 길어지기도 함.
- 새로운 아키텍처의 필요성: 이런 문제들을 해결하기 위해 MVP, MVVM, 클린 아키텍처 등 새로운 방법론들이 나왔음. 이 방법론들을 쓰면 개발 속도가 빨라지고, 유지보수가 쉬워지며, 코드가 더 깔끔해져서 나중에 다른 사람과 협업할 때도 편리해짐.
결국, 이런 새로운 아키텍처를 쓰면 코드를 더 이해하기 쉽고 개발 효율이 높아진다는 게 이 글의 핵심.
MVC, MVP, MVVM, Clean Architecture
1. MVC (Model-View-Controller)
MVC는 가장 기본적이고 널리 사용되는 아키텍처 패턴 중 하나로, 애플리케이션을 세 가지 주요 컴포넌트로 나눈다.
- Model: 데이터와 관련된 모든 비즈니스 로직을 처리함. 데이터베이스에서 데이터를 가져오거나 가공하여 제공.
- View: 사용자에게 보여지는 화면을 담당함. Model의 데이터를 받아와 렌더링.
- Controller: View와 Model 사이에서 중재자 역할을 함. 사용자의 입력을 받고 Model을 업데이트하거나 View에 반영.
장점
- 간단하고 이해하기 쉬움.
- 역할 분리가 명확하여 유지보수 용이.
단점
- View와 Controller 간의 결합도가 높아, 복잡한 애플리케이션에서는 테스트가 어렵고 확장성이 떨어질 수 있음.
2. MVP (Model-View-Presenter)
MVP는 MVC에서 Controller 대신 Presenter를 도입하여 View와 Model의 결합도를 낮추는 방식이다.
- Model: 데이터와 비즈니스 로직을 처리.
- View: UI와 사용자 입력을 담당. Presenter와 상호작용.
- Presenter: View에서 사용자 입력을 받아 Model을 갱신하고, 갱신된 데이터를 다시 View에 전달.
특징
- View는 Presenter와만 통신하며, Model에 직접 접근하지 않음.
- View는 인터페이스를 통해 Presenter와 연결되어 있어, Mock View를 사용한 단위 테스트가 쉬움.
장점
- View와 Model의 완전한 분리로 테스트 용이.
- View를 변경해도 Presenter에 영향을 주지 않음.
단점
- Presenter 코드가 복잡해질 수 있음.
3. MVVM (Model-View-ViewModel)
MVVM은 MVP에서 더 발전된 형태로, ViewModel이 추가된다. ViewModel은 View와 Model 사이의 중간자 역할을 하며, 데이터 바인딩을 통해 View와 연결된다.
- Model: 비즈니스 로직 및 데이터.
- View: 사용자에게 보여지는 UI.
- ViewModel: View의 상태 및 데이터를 관리하며, View와 데이터 바인딩.
특징
- 데이터 바인딩을 통해 ViewModel의 변화가 자동으로 View에 반영.
- ViewModel은 View의 이벤트를 처리하고, View는 ViewModel의 상태를 반영.
장점
- View와 Model의 결합도를 크게 낮출 수 있음.
- 테스트 및 유지보수 용이.
- 데이터 바인딩을 통해 코드 간소화 가능.
단점
- 데이터 바인딩 설정이 복잡할 수 있음.
- 너무 많은 로직이 ViewModel에 집중될 수 있음.
4. Clean Architecture
클린 아키텍처는 소프트웨어의 유연성, 확장성, 유지보수성을 극대화하기 위해 설계된 아키텍처이다. 모든 계층이 의존성 규칙(Dependency Rule)을 따른다.
주요 계층
- Entities (도메인 모델): 애플리케이션의 핵심 비즈니스 로직.
- Use Cases: 특정 비즈니스 동작을 수행하는 애플리케이션의 서비스.
- Interface Adapters: Use Cases와 외부 세계 (UI, DB 등) 간의 데이터 변환.
- Frameworks & Drivers: 외부 시스템과의 통신 (UI 프레임워크, 데이터베이스 등).
특징
- 의존성 규칙: 안쪽 계층은 바깥쪽 계층에 의존하지 않음.
- 예를 들어, Use Case는 Entity에만 의존하고, Interface Adapters나 Framework에 의존하지 않음.
장점
- 각 계층의 독립성 보장으로 테스트 용이.
- 특정 프레임워크에 종속되지 않음.
- 변경이 일어날 때, 다른 계층에 미치는 영향을 최소화.
단점
- 구현 복잡도가 높고, 초기 개발 속도가 느림.
- 구조를 잘못 설계하면 오히려 유지보수성이 떨어질 수 있음.
요약 비교
| 특징 | MVC | MVP | MVVM | 클린 아키텍처 |
|---|---|---|---|---|
| 주요 개념 | View-Controller-Model 분리 | View-Presenter-Model 분리 | View-ViewModel-Model 분리 | 여러 레이어를 통한 의존성 분리 |
| 데이터 바인딩 | View가 직접 Controller 호출 | 수동으로 View 업데이트 | 데이터 바인딩 사용 | 명시적 레이어 통신 |
| 테스트 용이성 | 상대적으로 낮음 | Presenter 테스트 용이 | ViewModel 테스트 용이 | 각 레이어 독립적 테스트 가능 |
| 적합한 프로젝트 | 단순한 앱, 빠른 프로토타이핑 | 비교적 단순한 앱 | 중규모 앱 | 대규모, 복잡한 비즈니스 로직의 앱 |
| 아키텍처 | View와 Model의 결합도 | 테스트 용이성 | 사용 난이도 |
|---|---|---|---|
| MVC | 높음 | 낮음 | 쉬움 |
| MVP | 낮음 | 높음 | 보통 |
| MVVM | 낮음 (데이터 바인딩) | 높음 | 보통~어려움 |
| Clean | 매우 낮음 | 매우 높음 | 어려움 |
- MVC는 단순한 구조로 인해 빠른 개발이 필요하거나 비교적 간단한 애플리케이션에 적합하다.
- MVP는 간단한 UI 중심 앱에서 적합하다.
- MVVM은 데이터 바인딩을 활용하여 View-ViewModel 동기화를 원할 때 유리하다.
- 클린 아키텍처는 확장성과 유지보수성이 중요한 대규모 프로젝트에 적합하다.
iOS 개발에 특화된 아키텍처?
iOS 앱 개발에서는 기본적으로 MVC를 비롯한 다양한 아키텍처 패턴을 사용할 수 있지만, iOS에 특화된 아키텍처 패턴이나 변형도 존재한다. 주요한 iOS 특화 아키텍처는 다음과 같다:
1. MVC (Model-View-Controller)
애플이 iOS 개발을 위해 권장하는 기본 아키텍처. UIKit 프레임워크가 MVC에 기반을 두고 설계되어, 간단한 앱에서 빠르게 사용할 수 있다. 하지만 ViewController가 과도한 책임을 가지는 Massive View Controller 문제로 확장성에 한계가 있다.
2. MVVM-C (Model-View-ViewModel-Coordinator)
MVVM 패턴에 Coordinator를 추가하여 ViewController의 책임을 분산시킨 아키텍처.
- Coordinator: 화면 전환과 관련된 모든 내비게이션 로직을 담당하여, ViewController가 View와 관련된 역할만 수행할 수 있도록 한다.
특징
- ViewController의 역할이 줄어들어 코드 복잡도를 낮출 수 있음.
- 화면 전환 로직이 Coordinator에 집중되므로, 테스트 및 재사용성 향상.
3. VIPER (View-Interactor-Presenter-Entity-Router)
iOS 앱 개발에서 클린 아키텍처의 원칙을 기반으로 한 패턴. 엄격한 책임 분리와 테스트 용이성이 목표.
- View: UI 및 사용자 입력 관리.
- Interactor: 비즈니스 로직을 처리.
- Presenter: Interactor에서 받은 데이터를 View에 표시하기 적합한 형태로 변환.
- Entity: 데이터 모델.
- Router: 화면 전환 로직을 관리.
특징
- 각 역할이 명확히 분리되어, 유지보수와 테스트가 매우 용이.
- 구조가 복잡하여, 초기 개발 비용이 높음.
4. Redux 아키텍처
단방향 데이터 흐름을 기반으로 하는 상태 관리 방식. iOS에서는 ReSwift 라이브러리를 활용하여 구현할 수 있음.
- State: 애플리케이션의 모든 상태를 단일 객체로 관리.
- Action: 상태 변경을 일으키는 이벤트.
- Reducer: 현재 상태와 Action을 기반으로 새로운 상태를 반환.
- Store: 상태를 보관하며, View와 연결하여 상태 변경을 반영.
특징
- 상태 관리가 명확하여 디버깅과 테스트가 용이.
- 단방향 데이터 흐름으로 인해 버그 발생 가능성 감소.
5. Compositional Architecture
Swift와 Combine, SwiftUI를 활용한 함수형 프로그래밍(FP) 기반 아키텍처.
- Composable Architecture (TCA): 상태와 동작을 컴포넌트로 나누어 관리함.
- State: 애플리케이션 상태를 표현.
- Action: 상태 변화와 관련된 이벤트.
- Reducer: 상태 변화 로직.
- Environment: 외부 종속성 관리.
특징
- 모듈화된 설계로 테스트 및 재사용성이 뛰어남.
- Combine/SwiftUI의 리액티브 패러다임과 잘 맞아 iOS 개발에 적합.
요약: iOS에서의 아키텍처 선택 가이드
| 아키텍처 | 특징 | 적합한 프로젝트 |
|---|---|---|
| MVC | 단순한 구조, UIKit 기반 | 소규모 앱, 빠른 프로토타이핑 |
| MVVM-C | 데이터 바인딩과 화면 전환 책임 분리 | 중규모 앱, 화면 전환이 많은 앱 |
| VIPER | 역할 분리, 높은 유지보수성 | 대규모 앱, 복잡한 비즈니스 로직의 앱 |
| Redux | 단방향 데이터 흐름, 명확한 상태 관리 | 상태 관리가 중요한 앱 |
| Compositional | SwiftUI/Combine 기반, 함수형 프로그래밍 요소 | 최신 기술 사용, SwiftUI 중심의 프로젝트 |
Reciprocity lies in knowing enough