MVC 패턴, 지금까지 가장 많이 쓰인 “기본기”부터 다지자

요즘 아키텍처 얘기만 나오면 MV*가 줄줄이 소환되죠. 그중 MVC(Model–View–Controller) 는 여전히 시작점이자 기준점입니다. 이번 글에서는 개념부터 현업에서 자주 겪는 오해, 프레임워크별 쓰임새까지 빠르게 정리해둘게요.

 

1) MVC, 한 문장 정의

UI(화면)와 도메인 로직을 분리하기 위해 앱을 Model / View / Controller 3축으로 나누는 아키텍처 패턴. 모델은 데이터와 규칙, 뷰는 표현, 컨트롤러는 입력 흐름과 조합을 맡습니다. 이 분리가 유지보수와 테스트에 유리한 이유는, 화면이 바뀌어도 비즈니스 규칙을 안 건드릴 수 있고 반대도 가능해지기 때문이죠.

2) 프레임워크마다 ‘MVC 다이어트’가 다르다

• Spring MVC: HTTP 요청을 Controller가 받고, 보통 비즈니스 로직은 Service 레이어로 빼서 “MVC + 레이어드”로 쓰는 게 관례입니다. DispatcherServlet, 핸들러 매핑, 뷰 리졸버 흐름을 타죠.
• iOS UIKit: UIViewController가 이름부터 ‘Controller’지만, 실제론 뷰 관리에 더 가깝습니다. 그래서 Massive View Controller 문제가 악명 높죠—역할 분리를 못하면 컨트롤러가 비대해집니다.
• Django: MVC와 거의 동일하지만 용어가 MTV(Model–Template–View) 로 바뀝니다. 이름만 달라졌지 큰 그림은 같습니다.

3) MVC를 잘 썼을 때 체감되는 이득

• 화면 교체가 쉬움: 뷰 템플릿을 갈아끼워도 모델/로직은 그대로.
• 테스트 범위가 또렷함: 모델 규칙은 단위테스트, 컨트롤러는 요청/응답 테스트로 분리. Spring 진영은 오래전부터 Spring-Test-MVC(MockMvc) 로 서블릿 컨테이너 없이 컨트롤러를 테스트하는 루틴이 자리잡았습니다.
• 협업 분업이 명확: 백엔드(모델/서비스)와 프론트(뷰)가 인터페이스만 맞추면 병렬 작업 가능.

4) 현업에서 자주 터지는 오해 & 함정

• “Controller에 로직 좀만 더…”
  그 “좀만”이 쌓여 Massive Controller 가 됩니다. 데이터 로딩, 포맷팅, 이벤트 처리, 네트워킹을 한곳에 몰아넣지 말고 서비스/유스케이스 로 분리하세요. iOS든 Web이든 원인은 “역할 분리 실패”지, MVC 탓이 아닙니다.
• 모델 누수
  뷰가 도메인 객체를 직접 들고 가공하기 시작하면, 나중에 모델 변경이 화면 전반을 깨뜨립니다. ViewModel/DTO 로 뷰 전용 데이터 형태를 만들어 주는 게 안전합니다.
• MVC만으로는 부족한 규모
  팀/서비스가 커지면 도메인 모듈화(레이어드, 헥사고날, 클린)와 함께 써야 유지보수가 됩니다. MVC는 “화면 중심 분리”이고, 클린/헥사고날은 “의존성 방향과 도메인 경계”를 다룹니다.

5) 써보기: MVC 도입 체크리스트 (간단 버전)

• Controller는 얇게: 파라미터 검증 → 유스케이스 호출 → 결과를 뷰 모델로 변환만.
• View는 ‘그리기’에만 집중: 계산/규칙/상태 전이 금지.
• Model은 UI 몰라야 함: 화면 프레임워크 import 금지.
• 테스트 계획을 먼저: 모델/유스케이스 단위테스트, 컨트롤러는 요청/응답 단위로 MockMvc(or 유사 도구) 테스트.

6) 언제 MVC가 특히 잘 맞나

• 서버 렌더링 웹: 템플릿 기반 화면이 많고, 요청-응답 사이클이 뚜렷할 때.
• 작은~중간 규모 앱의 출발점: 처음 구조를 잡고, 커지면 도메인 경계를 더한다.
• 학습/온보딩: 팀 공통 언어로 쓰기 좋고, 다른 MV*로 전환할 때 기준선이 됩니다.