MVC 패턴 (Architectural Pattern)

Model-View-Controller (MVC) is a software design pattern commonly used for developing user interfaces that divides the related program logic into three interconnected elements.

— Trygve Reenskaug의 MVC 최초 설계 문헌

모두가 '관심사 분리'를 부르짖으며 찬양하지만, 정작 실무에 투입된 개발자들은 바쁘다는 핑계로 컨트롤러 파일 하나에 DB 조회, 데이터 가공, HTML 렌더링 코드까지 전부 쑤셔 박아 'MVC (Many-functions in Very-fat Controller)' 패턴을 완성시키곤 한다. 아키텍처 토론방에서는 세상 지성인인 척 완벽한 결합도 감소를 외쳤지만, 당장 오늘 밤 배포 마감 전에는 컨트롤러에 하드코딩 if-else를 박는 자신을 발견한다.(...)

1. 개요

소프트웨어 공학에서 사용자 인터페이스(UI)를 설계할 때 가장 널리 쓰이는 고전적인 아키텍처 패턴. 전체 애플리케이션의 관심사를 Model(데이터와 비즈니스 논리), View(사용자 화면 표현), Controller(사용자 입력 처리 및 흐름 제어)의 3가지 역할로 명확히 분리한다. 이 삼권 분립을 통해 각 구성 요소가 서로의 영역을 침범하지 않고 독립적으로 교체 및 테스트될 수 있는 강력한 유지보수성을 보장한다.

2. MVC 삼권 분립의 핵심 역할과 상호작용

MVC 패턴의 각 요소는 철저하게 독립된 규칙 하에 움직인다. Model은 데이터베이스와 통신하고 비즈니스 규칙을 실행하며, 화면(View)이나 컨트롤러의 존재를 몰라야 하는 고고한 존재다. View는 오직 화면을 그리는 역할에만 집중하며, 어떤 비즈니스 로직도 내장하지 않는 순수한 껍데기다. Controller는 뷰를 통해 유저의 요청(클릭, 타이핑)을 수신하고, 모델을 시켜 데이터를 가공한 뒤, 그 결과를 어떤 뷰에 뿌려줄지 전체적인 가교를 조율하는 총괄 지휘관이다.1 유저의 요청이 Controller -> Model -> Controller -> View -> User 형태로 순환하며 시스템의 평화가 유지된다.

3. 웹 프레임워크의 대세 장악과 변종 패턴들

MVC 패턴은 웹 생태계의 폭발적인 성장과 함께 황금기를 맞이했다. 자바 진영의 Spring MVC, 루비의 Ruby on Rails, 파이썬의 Django, PHP의 Laravel 등 시대를 풍미한 거의 모든 서버 사이드 렌더링(SSR) 프레임워크들이 철저하게 이 MVC 구조를 모태로 설계되었다. 최근 프론트엔드 싱글 페이지 애플리케이션(SPA) 생태계로 넘어오면서, 데이터의 양방향 흐름 통제가 까다로워진 MVC 대신 MVP, MVVM(Model-View-ViewModel), 그리고 메타가 고안한 Flux(단방향 데이터 흐름) 아키텍처 등 다양한 현대적 변종들이 등장하여 생태계를 한층 풍요롭게 만들고 있다.

4. 관련 밈 및 드립

4.1. 뚱뚱한 컨트롤러 (Fat Controller)

MVC 패턴을 사용하는 실무 프로젝트에서 백엔드 개발자들이 가장 흔하게 저지르는 악습. 비즈니스 로직은 서비스 레이어(Model)로 빼고 컨트롤러는 가볍게 길잡이 역할만 해야 하지만, 귀찮은 마음에 컨트롤러 메소드 안에 백 줄짜리 SQL 조회 코드와 복잡한 데이터 변환 if-else 조건문, 예외 처리 로직까지 꽉꽉 담으며 비대해지는 현상을 말한다. 기차 토마스 캐릭터에 나오는 '뚱뚱한 사장님(The Fat Controller)' 캐릭터 짤방이 이 끔찍한 코드 상태를 놀릴 때 약방의 감초처럼 투입된다.

4.2. 가장 복잡한 뷰와 모델의 유혹

뷰에 데이터를 보여줄 때, 모델의 원시 데이터 구조를 가공하지 않고 그대로 통째로 넘기는 바람에 HTML 템플릿(View) 파일 안에서 자바스크립트나 루프문을 돌려 복잡한 수식을 계산하게 만드는 막장 아키텍처. 뷰가 모델을 강하게 참조하며 결합도가 상승해, 데이터베이스 스키마 하나를 바꾸면 사용자 화면 소스 코드까지 전부 다 깨져버리는 '동반 폭사'의 비극을 낳는다.(...)

5. 여담

  • Trygve Reenskaug의 선구안: MVC 패턴을 처음 제안한 노르웨이의 컴퓨터 과학자 트뤼그베 레인스카우는 1979년 제록스 팔로알토 연구소에서 최초의 GUI 운영체제와 스몰토크 언어를 연구하던 도중 이 패턴을 고안했다. 웹 통신이 존재하기도 전에 PC 응용 프로그램의 사용자 인터페이스 분리를 위해 탄생한 아키텍처가 40년이 흐른 현대 웹 서버의 핵심 뼈대로 쓰이고 있는 셈이다.
  • Web MVC와 오리지널 MVC의 괴리: 오리지널 데스크톱 MVC 패턴에서는 모델의 데이터가 바뀌면 모델이 직접 뷰에 '나 바뀌었으니 화면 갱신해라'라고 알리는 양방향 이벤트 리스너 방식이 작동했다. 반면 HTTP의 단방향 통신에 맞게 변형된 웹 MVC 패턴은 무조건 클라이언트의 요청이 와야만 컨트롤러가 모델을 거쳐 새로운 뷰를 내려주는 일방통행 흐름(Request-Response)을 취한다.
  • Spring MVC의 DispatcherServlet: 스프링 프레임워크에서 Web MVC를 구현하기 위해 사용하는 핵심 기술은 '프론트 컨트롤러' 패턴인 DispatcherServlet이다. 모든 HTTP 요청을 최전방에서 이 서블릿이 단독 수신한 뒤, 매핑 테이블을 분석해 각각의 세부 컨트롤러에 일을 깔끔하게 분배해 주는 대기업형 분업 체계를 가동한다.

6. 관련 문서

각주

  1. 역할 분담이 확실하기 때문에, 퍼블리셔나 프론트엔드 개발자가 HTML/CSS를 수정하여 View 파일을 교체하는 도중에 백엔드 개발자가 Model 코드를 만져도 서로 아무런 훼손이나 간섭 없이 평화롭게 동시 개발을 진행할 수 있다. ↩