MVC 패턴 이해

MVC 패턴

---

MVC 패턴은 소프트웨어 디자인 패턴 중 하나로 웹 애플리케이션의 구조를 구성하는 방법론입니다. MVC는 Model-View-Controller의 약자로 3가지 주요 구성 요소를 분리하여 유지보수성을 향상하고 애플리케이션의 확장성을 높이는 것을 목표로 합니다.

MVC 패턴의 동작 구조는 다음과 같이 정리할 수 있습니다.

1. 사용자가 요청을 보내면, 특정 URL 및 HTTP 메서드에 따라 Controller에게 라우팅 됩니다.
2. Controller를 통해 비즈니스 로직을 처리한 후, 결과를 Model에 담습니다.
3. Model에 담긴 결과를 바탕으로 Controller는 적절한 View를 선택하여 사용자에게 전달합니다.

 

이를 바탕으로 사용자 관점에서 쉽게 풀어쓰면 다음과 같습니다.

1. 사용자는 웹 사이트에 접속합니다.
2. 웹 사이트는 사용자에게 보여 줄 데이터를 가져옵니다.
3. 가져온 데이터를 사용자에게 웹 페이지를 출력하여 보여줍니다.

이와 같이 MVC 패턴의 흐름을 보면 각각의 관심사가 분리되어 동작하고 있음을 알 수 있습니다. 이제 각 구성 요소들이 어떤 역할을 수행하는지 구체적으로 알아봅시다.

---

Model

Model은 애플리케이션의 핵심 부분으로, 데이터와 비즈니스 로직을 다루며 주로 데이터베이스와 상호 작용을 담당하며, 데이터의 처리, 가공, 저장 등의 역할을 수행합니다. 예를 들어 클라이언트가 주문을 요청하면 처리한 결과를 응답해줘야 합니다. 이때 주문 요청을 받아들이고 처리하는 로직을 수행하며, 그에 따른 결과를 가공하여 응답 데이터를 생성하는 것이 Model의 주요 역할입니다.

 

View

View는 클라이언트에게 Model의 데이터를 시각적으로 표현하고 사용자 인터페이스(UI)를 생성하는 역할을 합니다. 주로 HTML, JSP, Thymeleaf와 같은 템플릿 엔진을 사용하여 동적인 웹 페이지를 생성합니다. 예를 들어 주문 내역을 표로 나타내거나, 클라이언트가 주문을 할 수 있는 입력 양식을 제공합니다.

 

Controller

Controller는 클라이언트의 요청을 받아들이는 엔드포인트(Endpoint)로 비즈니스 로직을 호출하여 처리를 위임하고 그 결과를 Model에 바인딩하고 적절한 View를 선택하여 클라이언트에게 응답을 생성하고 전송하는 역할을 합니다. 즉, Controller는 Model과 View 사이에서 상호 작용하여 전체적인 웹 애플리케이션의 동작을 조정합니다.

 

---

 

MVC 패턴은 왜 쓰는 것일까?

---

MVC 패턴은 웹 애플리케이션 개발에서 가장 널리 사용되는 아키텍처 패턴 중 하나입니다. 많은 웹 프레임워크 및 라이브러리들이 채택하고 있으며, 이를 이해하고 사용하는 것이 웹 개발자에게 필수적인 기술이 되었습니다.

 

MVC 유래

1970년대에 제록스 팔로알토 연구소에서 트라이브 린스케이지라는 개발자 분께서 Smalltalk 언어를 사용하여 소프트웨어 개발을 위해 처음으로 MVC의 시초입니다. MVC의 초기 구조는 MVC XEROX PARC 1978-79 자료에서 찾아볼 수 있었습니다.

MVC 패턴의 본질적인 목적은 사용자와 디지털 시스템 사이의 상호 작용에서 발생하는 간극을 해소하는 것입니다. 과거 데이터의 규모와 복잡성이 증가함에 따라 데이터를 효율적으로 제어하는 것이 중요한 과제였습니다. 이를 해결하기 위해 Controller를 통해 사용자의 요청을 받고, 이를 기반으로 하위 View를 생성하고 관리하여 각 구성 요소를 분리하는 방식이 고안되었습니다.

 

초기에는 해당 아키텍처 구성 요소를 Model-View-Editor로 지어지려고 하였으나, 더 나은 이름을 찾기 위해 여러 논의가 진행되었습니다. 이러한 논의 끝에 우리가 현재 익숙한 MVC(Model-View-Controller)라는 용어로 결정되었습니다. 이후 MVC 패턴은 과거의 여러 선배들의 고민과 노력을 거쳐 계속 발전하며, 현재의 웹 애플리케이션 개발에서 널리 사용되는 중요한 아키텍처 패턴으로 자리 잡게 되었습니다.

 

MVC 패턴의 이점

수많은 아키텍처들이 MVC 패턴과 유사한 관심사 분리 구조를 채택하여 사용하고 있습니다. 네트워크에서는 IP/TCP와 같은 프로토콜 스택을 통해 데이터 전송과 통신을 분리하고, 서버와 클라이언트 간에도 관심사를 분리하여 각각의 역할을 수행합니다.

 

웹 애플리케이션 개발에서도 MVC 패턴 이외에도 많은 아키텍처들이 존재합니다. 그러나 MVC 패턴이 가장 대중적인 이유는 MVC가 웹 애플리케이션의 관심사를 분리하는 데 가장 기본적인 구조를 가지고 있기 때문입니다.

 

MVC 패턴은 각 구성 요소의 역할이 명확하게 정의되어 있어 개발자들이 코드를 이해하고 유지보수하기 쉽다는 이점이 있습니다. 이러한 이점으로 인해 다른 아키텍처 패턴들도 MVC를 기반으로 파생되거나 영향을 받는 경우가 많습니다.

 

 

MVC 패턴의 다양한 이점을 정리하면 다음과 같습니다.

 

1. 컴포넌트 간의 책임을 분리하여 서로 간의 결합도 낮춘다.

MVC패턴은 각각의 관심사를 3가지 요소로 분할하여 서로에게 영향을 미치지 않고 독립적으로 변경할 수 있습니다. 이로 인해 코드의 가독성을 향상하고 유지보수를 용이하게 만듭니다.

 

2. 코드의 재사용성 및 확장성을 높일 수 있다.

각 부분이 독립적으로 작동하므로, Model, View, Controller를 다른 애플리케이션에서 쉽게 재사용할 수 있습니다. 또한 각 부분을 필요에 따라 확장할 수 있기 때문에 새로운 기능을 추가하거나 기존 기능을 변경하는 데 용이합니다.

 

3. 여러 View를 동일한 Model과 결합하여 유연하게 사용할 수 있다.

MVC 패턴은 동일한 데이터 기반으로 서로 다른 형식의 사용자 인터페이스를 제공하는데 유용합니다. 예를 들어 모바일 앱과 웹 애플리케이션은 동일한 Model을 사용하여 다른 View 가질 수 있습니다.

 

4. 테스트가 용이하다.

각 부분이 독립적으로 분리되어 있어 단위 테스트와 통합 테스트를 쉽게 수행할 수 있습니다. 각 Model, View, Controller를 개별적으로 테스트할 수 있어, 코드의 품질을 향상하고 버그를 줄이는데 도움이 됩니다.

 

5. 개발자 간의 커뮤니케이션 지원이 된다.

MVC 패턴은 널리 사용되는 디자인 패턴 중 하나이며, 다양한 프레임워크와 라이브러리가 지원되고 있습니다. 이는 개발자들이 도움을 받을 수 있는 다양한 자료와 문서를 활용할 수 있다는 이점을 가집니다.

 

---

 

MVC 패턴, 단점은 없을까?

---

MVC 패턴의 이점만 본다면 관심사를 분리하여 좋은 코드와 개발 효율성을 높이기 위해 쓰지 않을 이유가 없습니다. 그러나 MVC 패턴도 몇 가지 단점을 가지고 있습니다. 이러한 단점은 다음과 같습니다.

 

1. Model과 View의 완전 분리는 어렵다.

일반적으로 View는 Controller와 연결되어 화면을 구성하게 되는데, 이로 인해 Controller는 여러 개의 View를 다룰 수 있게 되며, Model은 Controller를 통해 여러 View와 연결될 수 있습니다. 이러한 상황에서 복잡한 애플리케이션일 경우 하나의 Controller가 다수의 View와 Model을 관리하면서 의존성이 커지는 경향이 있습니다.

 

2. 코드 중복과 성능 저하가 발생할 수 있다.

MVC 패턴은 각 구성 요소가 독립적으로 동작하므로 비슷한 코드가 각 구성 요소에 중복되어 나타날 수 있습니다. 또한 과도한 분리는 성능에 악영향을 미칠 수 있습니다. 예를 들어 Model과 View사이의 데이터 통신이 많아지는 경우입니다.

 

3. 컨트롤러가 과도한 역할을 수행하면 Massive-View-Controller 현상이 발생할 수 있다.

이는 Controller가 너무 많은 책임을 지니고, 비즈니스 로직이나 데이터 처리, View 구성 등을 모두 처리하려는 경향이 있을 때 발생합니다. 이로 인해 코드가 복잡해지고 유지보수가 어려워지는 문제가 생길 수 있습니다.

 

Massive-View-Controller 현상에 관한 내용은 Limitations of MVC Pattern 문서에서 자세히 볼 수 있습니다.

위 그림처럼 애플리케이션의 규모가 복잡하고 큰 서비스를 운영할 경우 하나의 Controller에 수많은 View와 Model이 연결되어 있기 때문에 자연스럽게 Controller에 부하가 커지게 됩니다. 

 

이로 인해 Controller의 부담이 커져 엮여있는 Model과 View를 변경하는 데도 많은 비용이 들며, 변경 시 다양한 부작용이 발생할 가능성이 높습니다.

 

---

 

MVC 패턴의 문제를 해결하기 위한 다른 패턴들

---

MVC 패턴의 단점을 해결하기 위한 새로운 대안으로 다음과 같은 아키텍처나 디자인 패턴을 고려해 볼 수 있습니다.

• MVVM(Model-View-ViewModel)
• MVP(Model-View-Presenter)
• MVW(Model-View-Whatever)
• Flux 아키텍처
• Redux
• RxMVVM

만약 MVC 패턴을 완전히 대체할 수 있는 패턴이었다면, 현재 MVC 패턴은 사용되지 않고 과거의 기술로 남아 있었을 것입니다. 그러나 언제나 그렇듯이 각기 다른 방법들은 서로 장단점이 나뉘며, 개발자가 상황에 따라 어떠한 패턴이 좋을지 선택해야 합니다. 이 중 자주 사용되는 MVVM 패턴과 MVP 패턴을 간단히 살펴보려고 합니다.

 

MVVM(Model-View-ViewModel) 패턴

MVVM 패턴은 MVC 패턴의 한계를 극복하기 위해 개발된 패턴 중 하나로 Model, View, View Model 요소로 이루어진 소프트웨어 아키텍처 패턴입니다.

여기서 Model과 View는 MVC 패턴에서의 Model과 View와 동일한 개념을 가지고 있습니다. 중요한 것은 바로 View Model입니다. View Model은 View와 Model 사이에서 중개자 역할을 수행하며, View를 보여주기 위한 데이터 처리를 담당하는 요소입니다. 즉, View를 표현하기 위해 만들어진 Model이라고 볼 수 있습니다.

 

MVVM 패턴의 동작 순서는 다음과 같습니다.

1. 사용자의 요청은 View를 통해 받게 됩니다. 
2. View에서 요청을 받으면, Command 패턴을 통해 View Model로 요청을 전달합니다. 
3. View Model은 Model에게 요청 처리에 필요한 데이터를 요청합니다. 
4. Model은 내부적으로 비즈니스 로직을 수행하여 View Model에 필요한 데이터를 전달합니다. 
5. View Model은 전달받은 데이터를 가공하여 저장합니다. 
6. View는 View Model과 Data Binding을 통해 사용자에게 요청에 적절한 화면을 출력합니다.

MVVM 패턴은 Command 패턴과 Data Binding 패턴 두 가지를 활용하여 구현되었습니다. 이 패턴들을 통해 View와 Model 사이의 의존성을 줄이고, View Model을 통해 중간 계층을 통해 상호작용할 수 있습니다. 하지만 MVVM 패턴의 단점으로는 ViewModel을 설계하는 과정이 복잡하고 어렵다는 점이 있습니다.

 

MVP(Model-View-Presenter) 패턴

MVP(Mode-View-Presenter) 패턴은 MVC 패턴의 한계를 극복하기 위해 등장한 패턴 중 하나로, Model, View, Presenter로 구성되는 소프트웨어 아키텍처 패턴입니다.

여기서 Model과 View는 MVC 패턴과 동일한 역할을 수행하며, Controller의 역할은 Presenter가 담당합니다.

 

Presenter는 Model과 View 사이에서 중개자 역할을 하며, MVC 패턴에서의 Controller와 유사하지만, View에 직접 연결되지 않고 사용자 인터페이스를 통해 상호작용합니다. 따라서 View에서 요청한 정보를 통해 Model을 가공하여 View로 전달해 주는 방식을 취합니다.

 

MVP 패턴의 동작 순서는 다음과 같습니다.

1. 사용자의 요청은 View를 통해 받게 됩니다. 
2. View는 데이터를 Presenter에 요청합니다. 
3. Presenter는 Model에게 데이터를 요청합니다. 
4. Model은 요청을 통해 비즈니스 로직을 수행하여 Presenter에게 요청받은 데이터를 전달합니다. 
5. Presenter는 View에게 전달받은 데이터를 응답합니다. 
6. View는 Presenter가 응답한 데이터를 이용하여 화면을 출력합니다.

MVP 패턴은 MVVM 패턴과 유사하게 Presenter를 통해서만 데이터를 전달받기 때문에 MVC 패턴의 약점 중 하나인 View와 Model의 의존성을 줄일 수 있습니다. 하지만 MVP 패턴은 View와 Presenter 사이의 의존성이 높아지게 되는 단점이 있습니다.

 

---

MVC(Model, View, Controller) Pattern

Facebook: MVC Does Not Scale, Use Flux Instead [Updated]

Trygve/MVC

[디자인 패턴] MVVM 패턴이란?