[ Swift ] View / Model / Controller 관계(MVC) 기본 개념

MVC는 화면 하나를 3역으로 나눠서 생각하는 패턴이다.

Model

• 앱의 데이터와 비즈니스 규칙을 담당한다.

• “무엇을 저장/계산/검증해야 하는가”가 들어간다.

• 예: User, Post, Order, 가격 계산 로직, 유효성 검사, 네트워크 응답 파싱 결과(도메인 모델로 변환된 것) 등

View

• 그리는 역할만 담당한다.

• 데이터를 보여주고, 터치/스크롤/버튼 클릭 같은 사용자 이벤트를 전달한다.

• 예: UIView, UILabel, UITableViewCell 등

• 원칙적으로 View는 “이 데이터가 왜 이렇게 됐는지”를 모르면 좋다(표현만).

Controller

• Model과 View 사이의 중간 관리자다.

• 사용자의 입력을 받아(Model을 변경하거나 요청) → 결과를 View에 반영한다.

• iOS에선 보통 UIViewController가 Controller 역할을 한다.

요약하면 흐름은 이렇게 이해하면 된다.

사용자 입력(View) → Controller가 받음 → Model 변경/요청 → 결과를 Controller가 받아서 → View 업데이트

3) MVC의 대표 문제점

포스팅에 많이 쓰는 “MVC의 단점”은 보통 아래 4개로 정리된다.

1) Controller가 비대해진다(= Massive VC)

• 기능이 늘수록 ViewController 파일이 커지고 복잡해진다.

• 읽기/수정/리팩토링이 어려워진다.

2) 결합도가 높아진다

• Controller가 View의 디테일과 Model의 디테일을 동시에 알게 된다.

• 화면 수정이 데이터/로직 수정으로 줄줄이 번지기 쉽다.

3) 테스트가 어렵다

• 비즈니스 로직이 Controller에 섞이면, UI 의존 코드와 섞여 단위테스트가 까다로워진다.

• “버튼 누르면 요청하고, 응답 오면 뷰 바꾸고…” 같은 흐름이 통째로 얽힌다.

4) 역할 경계가 흐려진다

• “이 로직이 Model인가? Controller인가?”가 애매해진다.

• 결국 팀마다 스타일이 달라지고 일관성이 깨질 수 있다.

요즘 추세

요즘은 “MVC를 버린다” 보다는,

MVC의 ‘컨트롤러 비대화’를 해결하려고 책임을 분리하는 방향

으로 많이 간다. 대표 흐름은 아래다.

A) MVVM (가장 대중적)

• Controller(또는 View)가 하던 “표현용 로직/상태”를 ViewModel로 분리한다.

• ViewModel이 “화면에 필요한 데이터 형태로 가공된 값”과 “상태(로딩/에러)”를 들고, View는 그걸 보여준다.

• 장점: 테스트/재사용이 좋아지고, VC가 얇아진다.

• 단점: 바인딩/상태 관리 규칙이 없으면 ViewModel이 또 비대해질 수 있다.

B) Coordinator(네비게이션 분리)

• 화면 이동/전환 로직을 ViewController에서 떼어내 Coordinator로 옮긴다.

• 장점: 화면 로직과 네비게이션이 분리되어 VC가 깔끔해진다.

• 실무에서 “MVC + Coordinator” 또는 “MVVM + Coordinator” 조합이 흔하다.

C) Clean Architecture / VIPER 등

• 레이어를 더 엄격히 나누고 의존성 방향을 통제한다(도메인/유스케이스/프레젠테이션 등).

• 장점: 대규모 앱에서 변경 영향도가 줄고 테스트가 쉬워진다.

• 단점: 보일러플레이트(구조 코드)가 늘고, 팀 합의/규율이 필요하다.

D) 단방향 데이터 흐름(UDF) 계열: Redux/TCA 스타일

• 상태를 한 곳에서 관리하고, “Action → Reducer → State → View” 흐름으로 움직인다.

• 장점: 상태 추적/디버깅/예측 가능성이 좋아진다.

• 단점: 초반 러닝커브가 있고, 작은 앱엔 과할 수 있다.

🌟요약

MVC는 View-Model-Controller로 역할을 나누어 UI를 관리하는 전통적인 패턴이다. 다만 iOS에서는 UIViewController가 화면 생명주기와 이벤트 처리, 데이터 로딩과 상태 관리까지 떠안기 쉬워 컨트롤러가 비대해지는 문제가 자주 발생한다(Massive VC). 그래서 최근에는 MVC를 완전히 버리기보다는 MVVM으로 표현 로직과 상태를 분리하거나, Coordinator로 네비게이션을 분리하고, 더 큰 규모에서는 Clean Architecture/VIPER/UDF 같은 구조로 책임을 더 엄격히 나누는 방향이 많이 사용된다.