xxo' TIL/WIL

IOS/UIKit

[UIKit] UIKit app 코드구조 / MVC 디자인 패턴

xxoxec 2025. 7. 3. 01:38
UIKit은 시스템과 상호 작용하고, 앱의 메인 이벤트 루프를 실행하고, 콘텐츠를 화면에 표시하는 등 앱의 핵심 객체를 다양하게 제공합니다. 이러한 객체는 대부분 그대로 사용하거나 약간만 수정하여 사용할 수 있습니다. 어떤 객체를 언제 수정해야 하는지 아는 것은 앱 구현에 매우 중요합니다.
UIKit 앱의 구조는 모델-뷰-컨트롤러(MVC) 디자인 패턴을 기반으로 하며, 객체는 용도에 따라 구분됩니다. 모델 객체는 앱의 데이터와 비즈니스 로직을 관리합니다. 뷰 객체는 데이터의 시각적 표현을 제공합니다. 컨트롤러 객체는 모델 객체와 뷰 객체를 연결하는 다리 역할을 하며, 적절한 시점에 데이터를 서로 이동합니다.

 

https://developer.apple.com/documentation/uikit/about-app-development-with-uikit

 

About App Development with UIKit | Apple Developer Documentation

Learn about the basic support that UIKit and Xcode provide for your iOS and tvOS apps.

developer.apple.com

 

UIKit 앱의 코드 구조

UIKit 앱의 일반적인 구조

UIKit 앱의 일반적인 구조를 보여주는 이미지. 앱의 데이터 구조를 나타내는 모델 객체를 제공하면 된다. UIKit은 대부분의  객체를 제공하지만, 필요에 따라 데이터에 대한 사용자 지정 뷰를 정의할  있다. 데이터 객체와 UIKit  간의 데이터 교환을 조정하는 것은  컨트롤러와  델리게이트 객체다.

 

Model View 사이의 관계

  • Model : 데이터
  • View : 데이터 표현 객체

이 사이의 관계가 중요한데 직접 소통하지 않고 중간 매체들을 통해서 소통하려고 한다.

 

 

iOS 앱에서 모델-뷰(Model-View) 패턴은 주로 MVC(Model-View-Controller), MVVM(Model-View-ViewModel), MVP(Model-View-Presenter)와 같은 아키텍처 패턴으로 구현됩니다. 각 패턴은 앱의 구조를 어떻게 나누고, 각 컴포넌트 간의 역할을 어떻게 분리할지를 정의합니다.

 

 

 

MVC (Model-View-Controller)

  • Model : 데이터나 비즈니스 로직을 담당. 앱의 상태나 데이터가 여기에 해당하며, 네트워크 요청이나 데이터베이스와의 상호작용도 포함된다.
  • View : 사용자에게 보이는 인터페이스 UI를 담당. 사용자와의 상호작용을 위한 화면 요소들. 즉 화면에 표시되는 요소들이며, 모델의 데이터를 표시하는 역할을 한다.
  • Controller : 모델과 뷰 간의 상호작용을 중재. 뷰에서 발생한 이벤트를 처리하여 모델을 업데이트하고, 모델의 변화를 뷰에 반영한다. 즉, 모델과 뷰를 연결하는 역할이며 사용자의 입력을 받아서 해당 입력에 맞는 모델 데이터를 변경하거나 뷰를 업데이트하는 로직을 수행한다.

MVC 디자인 패턴

 

iOS에서 MVC 아키텍처의 예

Model : User 클래스와 같은 데이터 객체가 될 수 있다.

View : UIView, UILabel, UIButton 등의 UI 요소들이 해당된다.

Controller : UIViewController가 이를 담당하며, 이 클래스 내에서 모델과 뷰의 상호작용을 관리한다.

 

MVC의 장단점

장점

  • 직관적이고 이해하기 쉬운 구조이다.
  • 코드 분리가 잘 되어 유지보수가 용이하다.
  • OS에서 UIViewController가 기본적으로 컨트롤러 역할을 하므로, 매우 자연스럽게 구현할 수 있다.

단점

  • 복잡한 애플리케이션에서는 뷰와 컨트롤러가 과도하게 결합되어 "Massive View Controller" 문제에 직면할 수 있다.
  • 데이터가 많고 복잡한 경우, 뷰와 컨트롤러가 지나치게 커져서 관리하기 어려운 코드가 될 수 있다.

배경 설명

애플에서는 기본적으로 MVC(Model-View-Controller) 패턴을 가이드 하고 있다.

하지만, 개발자들이 실무 진행간에 MVC를 가이드대로 안씀 -> 개발 부재가 쌓인다.

더 좋은 구조가 무엇이고, 반복가능하면서 지속가능한 방법이 무엇인지 꾸준히 고민해서 나온 디자인 패턴들 MVVM, MVP, VIPER, Ribs.

아키텍처에 대한 고민들, 특히 클린 아키텍처

대규모의 서비스를 제공하는 슈퍼앱을 제공하고 있는 회사들이 도입하고 있는 멀티 모듈 아키텍처가 있다.

 

 


 

참고 :

https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html

 

Model-View-Controller

Retired Document Important: This document may not represent best practices for current development. Links to downloads and other resources may no longer be valid. Model-View-Controller The Model-View-Controller (MVC) design pattern assigns objects in an ap

developer.apple.com

https://medium.com/airbnb-engineering/designing-for-productivity-in-a-large-scale-ios-application-9376a430a0bf

 

Designing for Productivity in a Large-Scale iOS Application

How innovation in technology and people processes have enabled iOS developers to remain productive in a large codebase.

medium.com

 

 

 


 

 

MVVM (Model-View-ViewModel) : 데이터 바인딩을 통해 뷰와 모델을 분리하는 방식으로, 코드 재사용성과 테스트 용이성을 높이는 패턴이다.

  • Model : 데이터와 비즈니스 로직을 담당.
  • View : UI를 담당하며, 사용자와의 상호작용을 담당한다.
  • ViewModel : 뷰와 모델을 연결하는 역할. 뷰의 상태를 관리하고, 뷰에 필요한 데이터를 모델에서 가져와 가공하여 제공한다. 뷰의 로직을 뷰모델에서 처리하여 뷰의 복잡성을 줄일 수 있다.

MVP (Model-View-Presenter) : 컨트롤러 대신 프레젠터가 뷰와 모델을 연결하는 방식으로, 뷰가 프레젠터에 의존하게 된다.

  • Model : 데이터나 비즈니스 로직을 담당.
  • View : 사용자와 상호작용하는 UI를 담당. 단, 뷰는 가능한 한 로직을 포함하지 않고, 단지 프리젠터에게 작업을 요청한다.
  • Presenter : 뷰에서 발생한 이벤트를 처리하고, 모델을 업데이트하거나 데이터를 가져옵니다. 뷰는 프리젠터에게 데이터를 요청하고, 프리젠터는 뷰를 업데이트한다.

 

 패턴은 상황에 따라 적합하게 선택할  있으며, MVVM 특히 SwiftUI  맞는 아키텍처로 많이 사용된다. 모델과 뷰의 분리를 통해 유지 보수성이나 테스트 용이성을 높이는  유리하다. MVVM 패턴과 MVP 패턴은 SwiftUI 학습 시 다시 정리.