왜 우리는 “MVC”라고 말하는 것을 멈추고 대신 “RCMV”라고 말해야 할까

Source: Dev.to

MVC의 문제점

MVC(모델, 뷰, 컨트롤러)는 웹 개발에서 가장 많이 쓰이는 아키텍처 용어 중 하나이지만, 실제 현대 웹 애플리케이션이 어떻게 동작하는지를 완전히 설명하지는 못합니다.
관심사의 분리를 설명해 주지만, 요청 처리를 이해하는 데 중요한 실행 흐름을 누락하고 있습니다.

실제 요청 흐름

요청은 먼저 라우트와 매핑되어야 합니다. 일반적인 흐름은 다음과 같습니다:

Request → Router → Controller → Model → View

이는 고전적인 “MVC” 순서와 다릅니다. 올바른 구성 요소 순서는 다음과 같습니다:

1. Router – 들어오는 요청을 라우트와 매핑합니다.
2. Controller – 의도를 검증하고, 요청을 조정하며, 책임을 위임합니다.
3. Model – 데이터를 구조화하고 관리합니다(규칙, 영속성, 비즈니스 제약).
4. View – 최종 출력을 렌더링합니다.

RCMV 소개

RCMV(Router, Controller, Model, View)는 MVC를 대체하는 것이 아니라, 현대 애플리케이션이 실제로 요청에 응답하는 방식을 반영하도록 확장한 것입니다.

Router

• 애플리케이션의 진정한 진입점 역할을 합니다.
• 어떤 코드가 요청을 처리할지, 요청이 허용되는지를 결정합니다.
• 라우팅이 없으면 페이지가 로드되지 않고, API가 응답하지 않으며, CRUD 작업도 일어나지 않습니다.

Controller

• 라우터가 요청을 허용한 뒤에만 활성화됩니다.
• 요청을 조정하고, 의도를 검증하며, 작업을 모델에 위임합니다.
• 데이터를 소유하지 않으며, 데이터를 조율합니다.

Model

• 데이터를 구조화하고 관리하는 역할을 담당합니다.
• 규칙, 영속성, 비즈니스 제약을 강제합니다.
• 사용자에게 직접 응답하지 않으며, 컨트롤러가 응답합니다.

View

• 클라이언트에게 최종 응답이 렌더링되는 최종 목적지입니다.

RCMV가 중요한 이유

• Laravel, Django, Rails, Express와 같은 프레임워크가 동작하는 방식과 일치합니다.
• 실제 진입점을 드러내어 개발자가 현실적인 문제를 디버깅하는 데 도움을 줍니다.
• 라우팅과 요청 처리를 명시적으로 만들어 스파게티 코드를 방지할 수 있습니다.
• 도메인‑주도 설계(DDD)와 자연스럽게 어우러져 더 깔끔한 시스템 설계를 촉진합니다.

중요한 정리

RCMV는 MVC의 확장이며, 대체가 아닙니다. 요청 라이프사이클의 첫 단계에 라우터를 추가하는 것뿐입니다.

최종 생각

MVC만으로 충분한가, 아니면 현대 개발에 더 나은 사고 모델이 필요한가? 실제 현대 웹 애플리케이션의 흐름을 반영하기 위해 RCMV 도입을 고려해 보세요.