.png%3Ftable%3Dblock%26id%3Db06785f0-5ea3-4b47-9323-3ae8cf4b0e26%26cache%3Dv2&w=3840&q=75)
MVC Pattern이란?
MVC Pattern은 디자인 패턴 중 하나입니다. 소프트웨어 개발에서 특정한 문제에 대한 해결책을 제시하는 일종의 템플릿이며, 코드를 구조화하고 재사용성을 높이기 위한 가이드라인을 제공합니다.
이러한 패턴은 개발자들이 공통적으로 마주치는 문제를 해결하는데 도움이 되며, 코드의 가독성과 유지 보수성을 향상 시키는데 기여합니다.
MVC
MVC(Mode-View-Controller) 패턴은 소프트웨어를 세 가지 주요 부분으로 나누어 개발하는 디자인 패턴 중 하나입니다. 이 패턴은 모델, 뷰, 컨트롤러 간의 역할을 명확히 정의하여 각 부분이 독립적으로 작동하면서도 효율적으로 협력할 수 있도록 합니다.
사용자가 controller를 조작하면 controller는 model을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달하게 됩니다.
Model
애플리케이션의 정보와 데이터를 나타냅니다. 데이터베이스, 초기 상수, 변수 등을 포함하며 이러한 데이터와 정보의 가공을 책임지는 컴포넌트입니다. 모델은 다음과 같은 규칙을 가지고 있습니다.
- 모든 편집 가능한 데이터 보유
사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 합니다. 예를 들어, 화면 안의 네모 박스에 표현된 글자의 위치, 크기, 내용, 포맷 등의 정보를 포함합니다.
- 뷰나 컨트롤러에 대한 무지
데이터 변경이 발생하면 모델은 직접적으로 화면 UI를 수정하지 않고, 내부 속성 값을 통해 뷰를 참조하는 것을 피해야 합니다.
- 변경 통지에 대한 처리 방법 구현
모델의 속성 중 텍스트 정보 등이 변경v되면, 해당 변경을 감지하고 이벤트를 발생시켜 다른 컴포넌트에 전달해야 합니다. 또한, 누군가 모델을 변경하도록 요청하는 이벤트를 수신할 수 있는 처리 방법을 구현해야 합니다. 모델은 재사용 가능하며 다른 인터페이스에서도 변하지 않아야 합니다.
VIEW
사용자 인터페이스 요소를 나타냅니다. 데이터 및 객체의 입력과 출력을 담당하며, 데이터를 기반으로 사용자가 볼 수 있는 화면을 생성합니다. 뷰 에서는 다음과 같은 규칙들이 있습니다.
- 모델이 가진 정보를 따로 저장하지 않음
면에 데이터를 표시하기 위해 모델이 가진 정보를 전달 받더라도, 해당 정보를 저장해서는 안 됩니다. 명령을 받으면 화면에 표시하기만 하고, 필요한 정보는 저장하지 않아야 합니다.
- 모델이나 컨트롤러와 독립적
모델과 같은 다른 구성 요소를 참조하거나 이에 대해 알아서는 안 됩니다. 뷰는 데이터를 받아 화면에 표시하는 역할에만 집중합니다.
- 변경 통지에 대한 처리방법 구현
화면에서 사용자가 표시된 내용을 변경하면 이를 모델에게 전달해 모델을 변경해야 합니다. 이를 위해 변경 통지를 구현합니다. 재사용 가능한 설계를 고려하고, 다른 정보를 표현할 때 쉽게 설계되어야 합니다.
Controller
데이터와 사용자 인터페이스 요소들을 연결하는 역할을 합니다. 사용자가 데이터를 클릭하고 수정하는 등의 이벤트를 처리합니다. 컨트롤러에서는 다음과 같은 규칙을 이해해야 합니다.
- 모델이나 뷰에 대한 알림
모델과 뷰에 대한 정보를 알고 있어야 합니다. 모델과 관련된 뷰에 대한 정보를 알고 있어야 모델과 뷰 간의 상호 작용을 중재할 수 있습니다.
- 모델이나 뷰의 변경을 모니터링
모델이나 뷰에서 변경이 일어났을 때 이를 모니터링하고, 해당 변경을 해석하여 다른 구성 요소에게 통지합니다. 애플리케이션의 메인 로직을 담당합니다.
이러한 설계 원칙을 준수하여 모델, 뷰, 컨트롤러 간의 강한 결합을 피하고, 재사용 가능하고 유지 보수가 용이한 애플리케이션을 개발할 수 있습니다.
MVC Pattern을 사용해야 하는 이유
MVC 패턴을 사용하면 사용자 인터페이스(View), 데이터 처리(Model), 중간 제어(Controller)로 구성된 애플리케이션을 만들어 각 부분이 독립적으로 역할에 집중할 수 있습니다.
이를 통해 개발자들은 각자의 역할에만 집중하여 애플리케이션을 구축할 수 있으며, 결과적으로 유지 보수성과 애플리케이션의 확장성, 그리고 유연성이 향상됩니다.
중복 코딩이 최소화되어 코드 일관성을 유지하면서 UI 디자인 변경이 쉬워지고, 또한 새로운 요구 사항에 대응할 수 있어 유연성이 증가하는데 이는 클라이언트의 새로운 요구 사항에 대응하는 데 최소한의 비용이 소요된다는 장점을 지닙니다.
MVC Pattern의 한계
MVC 패턴은 코드를 어떻게 나눌 것 인가에 대한 해답 중 하나 이지만, 완벽하지 않습니다. 잘못된 사용 시에는 오히려 문제를 야기할 수 있습니다.
- Model과 View의 의존성 분리 어려움
일반적으로 View는 Controller와 연결되어 화면을 형성하고, Model은 Controller를 통해 View와 연결됩니다. 이로 인해 복잡한 애플리케이션에서는 하나의 Controller에 여러 개의 View와 Model이 복잡하게 연결되어 의존성이 커질 수 있습니다. 특히, Controller에 따라 여러 개의 View와 Model이 연결되면서 의존성이 증가할 수 있습니다.
- Massive-View-Controller(MVC) 현상
대규모 애플리케이션에서는 Controller의 부하가 증가하면서 Massive-View-Controller(MVC) 현상이 발생할 수 있습니다.
Massive-View-Controller(MVC) 현상이란?
Massive-View-Controller(MVC) 현상은 MVC 패턴에서 컨트롤러의 역할이 지나치게 커져서 발생하는 상황을 나타냅니다. 특히 대규모 애플리케이션에서 주로 발생하며, 이로 인해 여러 문제가 발생할 수 있습니다.
- 코드의 비대화
컨트롤러의 역할이 매우 복잡해지면서 코드가 비대해지는 현상이 발생합니다. 이는 코드의 가독성을 낮추고 유지 보수를 어렵게 만듭니다.
- 재사용성 및 확장성 저하
Massive-View-Controller 상황에서는 컨트롤러가 여러 역할을 수행하므로 특정 역할에 맞게 모듈화 되지 않아 재사용성이 감소하고, 새로운 기능을 추가하기가 어려워집니다.
- 유지 보수성 하락
복잡한 컨트롤러 구조는 유지 보수를 어렵게 만듭니다. 코드 변경이나 오류 수정이 예측하기 어려워집니다.
- 테스트 용이성 저하
단일 컨트롤러에 다수의 역할이 집중되면 테스트 작성이 어려워지고, 테스트의 범위를 파악하기 어려워집니다.
Massive-View-Controller docs: https://www.infoq.com/news/2014/05/facebook-mvc-flux/
이는 하나의 Controller에 많은 View와 Model이 연결되어 있어 Controller의 부담이 크게 커지는 상황을 지칭합니다. 이로 인해 코드의 복잡성, 재사용성 및 확장성이 저하되고, 유지 보수성이 하락하며 테스트 용이성이 저하 등 다양한 Side-Effect 를 불러오게 될 수 있습니다.
이러한 한계는 MVC 패턴의 사용 시 주의할 필요가 있음을 시사합니다. 따라서 특히 대규모 애플리케이션에서는 MVC 패턴을 적절히 활용하고 이러한 한계를 최소화하는 방법을 찾는 것이 중요합니다.
MVC Pattern의 대안
- MVVM (Model-View-View Model)
Model은 데이터와 비즈니스 로직을, View는 사용자 인터페이스를 나타냅니다. ViewModel은 뷰와 모델 사이의 중간 매개체로 동작하여 뷰에 특화된 로직을 처리하고 모델을 관리합니다. 데이터 바인딩을 통한 양방향 통신이 주요 특징입니다.
- MVP (Model-View-Presenter)
Model이 데이터와 비즈니스 로직을, View가 사용자 인터페이스를 담당하는 패턴입니다. Presenter는 뷰와 모델 간의 중간 매개체로 동작하며, 사용자 입력 처리, 모델 업데이트, 뷰에 업데이트 알림 등을 담당합니다.
- MVW (Model-View-Whatever)
일반적으로 MVC, MVP, MVVM 등을 통칭하여 어떤 패턴이든 사용 가능함을 나타냅니다. 아키텍처를 구성하는 방법에 중점을 둡니다.
- Flux
페이스북에서 개발한 애플리케이션 아키텍처로, 단방향 데이터 흐름을 중심으로 합니다. 액션, 디스패처, 스토어 등의 개념을 활용합니다.
- Redux
React 애플리케이션에서 상태 관리를 위한 라이브러리로, Flux 아키텍처를 기반으로 합니다. 단일 스토어, 순수 함수, 불변성 등을 강조합니다.
- RxMVVM
리액티브 프로그래밍 라이브러리와 MVVM 패턴을 결합한 것으로, 리액티브 확장성을 활용하여 비동기 이벤트 및 데이터 흐름을 처리하고 뷰모델에 반응적으로 업데이트합니다.
MVC Pattern이 적용된 프레임워크 혹은 라이브러리
- Django (웹 프레임워크)
Django는 Python으로 작성된 웹 프레임워크로, MTV(Model-Template-View)라는 변형된 MVC 패턴을 사용합니다. 여기서는 Controller 대신에 View와 URLconf가 존재합니다.
- Ruby on Rails (웹 프레임워크)
Ruby on Rails는 Ruby 언어를 기반으로 하는 웹 프레임워크로, 전통적인 MVC 패턴을 사용합니다. 모델, 뷰, 컨트롤러로 구성되어 있습니다.
- Spring (Java 프레임워크)
Spring은 Java 기반의 프레임워크로, Spring MVC는 전통적인 MVC 패턴을 구현하고 있습니다. 모델, 뷰, 컨트롤러로 구성되어 있으며, Java 언어로 웹 애플리케이션을 개발하는 데 사용됩니다.
- Angular (웹 프레임워크)
Angular는 TypeScript 기반의 프론트엔드 웹 프레임워크로, 클라이언트 측에서 MVC 패턴을 지원합니다. 컴포넌트 기반 아키텍처를 사용하며, 컴포넌트가 컨트롤러와 뷰의 역할을 겸합니다.
- React (라이브러리)
React는 JavaScript 라이브러리로, 주로 프론트엔드 개발에 사용됩니다. React는 컴포넌트 기반 아키텍처를 사용하며, 컴포넌트가 뷰의 역할을 합니다. 상태 관리 라이브러리인 Redux와 함께 사용되면 MVC 패턴과 유사한 아키텍처를 구성할 수 있습니다.
글을 마치며
MVC 패턴을 공부하면서 느낀 점은, 기본에 충실하면서도 조금씩 발전하고 단점을 보완해 나가는 것이 이 패턴의 핵심인 것 같습니다. 마치 축구에서의 팀의 기본 포메이션처럼, MVC 역시 기본적인 원칙을 중시하면서도 프로젝트의 성격에 맞게 유연하게 적용될 수 있습니다.
패턴이 시간이 지남에 따라 여러 문제점을 드러내기도 하지만, 그럴 때마다 그 문제점을 개선하고 발전시켜 나가는 것이 패턴이 지속적으로 유용하게 사용되는 비결인 것 같습니다. 여러 변형된 패턴이 등장하긴 했지만, Model과 View의 분리는 여전히 핵심적인 원칙으로 자리 잡고 있습니다.
소프트웨어 개발에서도 기본이 중요하다는 생각이 계속해서 들었습니다. 축구 팀이 기본 포메이션에서 출발하여 다양한 전략을 통해 발전해 나가듯이, MVC 역시 기본적인 역할과 책임을 잘 수행하면서도 다양한 요구 사항에 유연하게 대응할 수 있어야 합니다. 개발에서도 각 구성 요소가 정해진 역할에 충실하고, 의도한 대로 협력하면서 좋은 소프트웨어를 만들어 나가는 것이 중요하다고 생각합니다.
마지막으로, 패턴을 이해하고 적용하는 것 뿐만 아니라, 계속해서 발전시켜 나가며 새로운 도전에 적응하는 자세가 중요하다는 것을 느꼈습니다. 기본에 충실하되 지속적인 성장과 개선을 통해 더 나은 소프트웨어를 만들어내는 것이 제일 중요한 과제이자 목표라고 생각합니다.