들어가며: 왜 디자인 패턴이 필요할까?
어떤 앱을 만든다고 생각해보세요.
처음엔 간단하게 시작했지만,
기능이 하나둘 추가되면서 코드가 점점 복잡해집니다.
그리고 나중에 유지보수를 하거나 다른 개발자들과 함께 작업해야 할 때가 오죠.
이때 우리는 "좀 더 쉽고 깔끔하게 만들 수 있는 방법"을 고민하게 됩니다.
만약 이런 방법들을 미리 정리해두지 않는다면?
매번 처음부터 클래스와 함수들을 일일이 다 만들어야 할 거예요.
디자인 패턴이란 바로 이런 "좀 더 쉽고 편리하게" 개발할 수 있도록 만들어진 검증된 해결책들입니다.
프로그램 개발 중에 반복적으로 발생하는 문제점들을 정리해서,
상황에 따라 간편하게 적용할 수 있는 특정한 "규약" 형태로 만든 것이죠.
예를 들어,
데이터를 만들고 → 이 데이터를 수정하는 로직을 짜고 → 그 데이터를 화면에 보여주는 부분을 만든다
만약 이 모든 것들이 로직 분리 없이 한꺼번에 뒤섞여 정의되어 있다면?
나중에 유지보수하기가 정말 힘들 거예요.
디자인 패턴은 바로 이런 문제를 "돕기" 위해 나온 것입니다.
스트래티지 패턴, 옵저버 패턴 등등 정말 여러 가지가 있고,
그 중 하나가 바로 오늘 알아볼 MVC 패턴입니다.
MVC란?
MVC는 Model, View, Controller의 약자입니다.
하나의 애플리케이션이나 프로젝트를 구성할 때, 그 구성요소를 세 가지 역할로 구분한 패턴입니다.
기본적인 동작 흐름은 이렇습니다: 사용자가 Controller를 조작하면,
Controller는 Model을 통해서 데이터를 가져오고,
그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달하게 됩니다.
실제 MVC 패턴의 구조를 보면,
Controller가 View에도 직접적인 영향을 미치는 부분이 있습니다.
전체적인 흐름을 보면
Model → Controller → View → User → Controller
로 순환하는 구조를 가지고 있어요.
각각의 역할을 자세히 알아보겠습니다.
Model (모델)
애플리케이션의 정보와 데이터를 나타냅니다.
데이터베이스, 상수, 초기화값, 변수 등을 뜻하며,
이러한 데이터들의 가공을 책임지는 컴포넌트입니다.
모델이 지켜야 할 규칙들:
- 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 합니다화면에 네모박스와 글자가 표현된다면,
네모박스의 화면 위치 정보, 크기 정보, 글자 내용, 글자의 위치, 포맷 정보 등을 모두 가지고 있어야 합니다. - View나 Controller에 대해서 어떤 정보도 알지 말아야 합니다
데이터 변경이 일어났을 때 모델에서 화면 UI를 직접 조정하려고 View를 참조하는 내부 속성값을 가지면 안 됩니다. (즉, 독립적) - 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 합니다
모델의 속성이 변경되면 이벤트를 발생시켜 누군가에게 전달해야 하며, 변경 요청 이벤트를 수신할 수 있는 처리 방법을 구현해야 합니다.
또한 재사용 가능해야 하며 다른 인터페이스에서도 변하지 않아야 합니다.
View (뷰)
사용자 인터페이스 요소들을 나타냅니다.
input 텍스트, 체크박스 항목 등과 같은 요소들이죠.
데이터 및 객체의 입력과 출력을 담당합니다.
한마디로 데이터를 기반으로 사용자들이 볼 수 있는 화면입니다.
뷰가 지켜야 할 규칙들:
- 모델이 가지고 있는 정보를 따로 저장해서는 안됩니다
화면에 글자를 표시하기 위해 모델로부터 정보를 전달받지만, 그 정보를 유지하기 위해 뷰 내부에 저장하면 안 됩니다. 단순히 "네모박스를 그리라"는 명령을 받으면 화면에 표시만 하고, 그릴 때 필요한 정보들은 저장하지 않아야 합니다. - 모델이나 컨트롤러와 같은 다른 구성요소들을 몰라야 합니다
자기 자신을 제외한 다른 요소를 참조하거나 어떻게 동작하는지 알아서는 안 됩니다.
뷰는 데이터를 받으면 화면에 표시해주는 역할만 가집니다. - 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야 합니다
화면에서 사용자가 내용을 변경하게 되면 이를 모델에게 전달해서 모델을 변경해야 합니다.
그 작업을 위해 변경 통지를 구현해야 하며, 재사용 가능하게끔 설계해야 합니다.
Controller (컨트롤러)
데이터와 사용자 인터페이스 요소들을 잇는 다리 역할을 합니다.
사용자가 데이터를 클릭하고 수정하는 것에 대한 "이벤트"들을 처리하는 부분입니다.
컨트롤러가 지켜야 할 규칙들:
- 모델이나 뷰에 대해서 알고 있어야 합니다
모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고 수신하는 방법만 가지고 있습니다.
이를 컨트롤러가 중재하기 위해 모델과 관련된 뷰에 대해서 알고 있어야 합니다. - 모델이나 뷰의 변경을 모니터링해야 합니다
모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지를 해야 합니다.
또한 애플리케이션의 메인 로직은 컨트롤러가 담당하게 됩니다.
왜 MVC 패턴을 사용해야 할까?
사용자가 보는 페이지, 데이터 처리, 그리고 이 2가지를 중간에서 제어하는 컨트롤러.
이 3가지로 구성되는 하나의 애플리케이션을 만들면 각각 맡은 바에만 집중할 수 있게 됩니다.
공장에서도 각자의 역할만 담당해서 처리하면 효율적이 되는 것처럼, 개발에서도 마찬가지입니다.
서로 분리되어 각자의 역할에 집중할 수 있게끔 하여 개발하고 애플리케이션을 만든다면:
- 유지보수성 증가: 특정 부분에 문제가 생겨도 해당 영역만 수정하면 됩니다
- 애플리케이션 확장성 향상: 새로운 기능을 추가할 때 기존 코드에 미치는 영향을 최소화할 수 있습니다
- 유연성 증가: 클라이언트의 새로운 요구사항에 대해 최소한의 비용으로 보다 유연하게 대처할 수 있습니다
- 중복 코딩 문제 해결: 각 역할이 명확히 분리되어 있어 코드 중복을 방지할 수 있습니다
그러기 위한 것이 바로 MVC 패턴입니다.
MVC 패턴을 사용하는 프레임워크와 라이브러리
그렇다면 MVC 패턴을 사용하는 프레임워크나 라이브러리는 뭐가 있을까요?
대표적인 예시들:
- 구글의 AngularJS
- PHP의 CodeIgniter
- Django (Python)
- Ruby on Rails
- Spring MVC (Java)
MVC 패턴의 한계와 주의점
하지만 MVC 패턴이 만능은 아닙니다:
언제 사용하지 않는 게 좋을까?
- 아주 간단한 프로젝트: 할일이 3-4개뿐인 간단한 스크립트라면 MVC로 나누는 게 오히려 복잡할 수 있어요
- 실시간 반응이 중요한 게임: 성능상 MVC의 계층 구조가 부담이 될 수 있습니다
- 팀이 MVC를 이해하지 못하는 경우: 패턴을 억지로 적용하면 오히려 코드가 더 복잡해질 수 있어요
흔한 실수들
- 너무 세세하게 나누기: 간단한 기능도 MVC로 억지로 나누려다 보면 오히려 복잡해집니다
- Controller에 모든 로직 몰아넣기: Controller가 너무 비대해지면 MVC의 의미가 없어져요
- Model과 View가 직접 소통하게 하기: 규칙을 어기면 나중에 유지보수가 힘들어집니다
현실에서는 어떻게 발전했을까?
MVC 패턴은 시간이 지나면서 여러 변형들이 나왔어요:
- MVP (Model-View-Presenter): Android 개발에서 많이 사용
- MVVM (Model-View-ViewModel): WPF, Angular에서 사용
- Flux/Redux: React 생태계에서 인기
각각은 MVC의 기본 아이디어를 유지하면서도, 특정 환경에 더 적합하도록 발전시킨 것들입니다.
마무리하며
MVC 패턴은 "복잡한 것을 단순하게 나누어 생각하자"는 기본 철학을 담고 있습니다.
처음에는 "굳이 이렇게까지 나누어야 하나?" 싶을 수도 있어요.
하지만 프로젝트가 커지고, 팀원이 늘어나고,
요구사항이 계속 바뀌는 상황을 겪다 보면 이런 패턴의 소중함을 깨닫게 될 거예요.
좋은 코드는 6개월 후의 자신도 쉽게 이해할 수 있는 코드라는 말이 있습니다.
MVC 패턴은 바로 그런 코드를 만들기 위한 하나의 방법일 뿐이에요.
패턴에 얽매이지 말고, 상황에 맞게 유연하게 적용하는 것이 현명한 개발자의 자세가 아닐까 싶습니다.