[디자인 패턴] MVC / MVP / MVVM 패턴

아키텍처 패턴이 왜 중요할까?

소프트웨어를 개발하면서 가장 흔히 마주치는 문제 중 하나가 기능이 많아질수록 코드가 복잡해지고 유지보수가 어려워진다는 점입니다.

특히 UI 로직과 비즈니스 로직이 섞여 있는 경우, 단순한 수정 하나가 연쇄적으로 많은 부분을 건드려야 하는 문제도 생기고, 테스트를 진행하기도 어려워질 수 있습니다.

 

이때 바로 이 아키텍처 패턴이 유용하게 사용됩니다.

아키텍처 패턴은 역할을 명확하게 나누어 코드의 책임을 분리하고, 유지보수와 확장성을 높이는 방법으로 활용됩니다.

대표적 아키텍처 패턴에는 MVC, MVVM 외에도 MVP.. 등이 있고, 특히 안드로이드나 프론트 개발의 경우에는 MVP와 MVVM이 많이 사용됩니다.

 

처음 아키텍처에 대해 공부할 때는 왜 이렇게 어렵게 구조를 나누고, 아키텍처는 또 왜 이렇게 많은거야! 하며 불평했던 것 같은데 프로젝트 규모가 커질수록 이 패턴을 알맞게 선택하는 게 코드 생산성과 테스트에 큰 영향을 준다는 것을 체감했습니다.

 

이번 글에서는 MVC, MVP와 MVVM이 어떤 구조로 동작하고 어떤 차이를 가지는지, 어떤 경우에 각각의 아키텍처를 사용하는 게 좋을지 작성해보려고 합니다.

 

---

 

MVC 패턴

MVC는 구성요소인 Model / View / Controller의 앞글자를 따서 붙여진 이름입니다.

 

 

사용자 인터페이스, 데이터 및 논리 제어를 구현하는 데 널리 사용되는 소프트웨어 디자인 패턴입니다.

 

구조

MVC는 가장 오래된 소프트웨어 디자인 패턴 중 하나로, 애플리케이션을 세 가지 책임으로 나누어 관리합니다.

• Model : 데이터와 비즈니스 로직 담당
  [ DB처리, API 통신, 내부 계산 등이 여기에 해당 ]
• View : 사용자 인터페이스(UI) 담당. Model의 데이터를 화면에 출력
• Controller : 사용자 입력 (클릭, 입력 등)을 받아 처리. 필요한 경우 Model을 변경하거나 View 업데이트

 

데이터 흐름

1. 사용자의 액션이 Controller에 들어옵니다
2. Controller는 사용자의 액션을 확인하고, Model을 업데이트합니다
3. Controller는 Model을 나타내줄 View를 선택합니다.
4. View는 Model을 이용하여 화면을 나타냅니다.

 

그림에서 볼 수 있듯이 Controller는 여러 개의 View를 선택할 수 있는 1:n 구조라는 특징을 가지고 있습니다.

가장 단순한 형태이다 보니 보편적으로 많이 사용되는 디자인 패턴입니다.

 

다만 단순한 만큼 단점도 있는데, View와 Model 사이 의존성이 높다는 것이 MVC 패턴의 단점이라고 볼 수 있습니다.

Model과 View의 의존성이 높을 경우, 어플리케이션이 커질수록 복잡해지고, 유지보수가 어려워집니다.

 

 

---

 

 

MVP 패턴

MVP는 Model / View / Presenter의 앞글자를 따서 만들어진 이름입니다.

기존 MVC 패턴에서 View와 Controller 간 결합도를 낮추기 위해 발전된 구조입니다.

MVC와 비슷하지만 Controller대신 Presenter를 넣은 패턴이라고 볼 수 있습니다.

 

구조

MVP는 안드로이드 앱 개발 초창기에 많이 사용되는 구조입니다.

MVC보다 비즈니스 로직의 분리를 더 명확히 하기 위해 등장했으며, 테스트 가능성과 모듈화 측면에서 개선된 구조입니다.

• Model : 데이터 처리와 비즈니스 로직 담당
  [ DB처리, API 통신, 내부 계산 등이 여기에 해당 ]
• View : 사용자 인터페이스(UI) 담당. Presenter에게 사용자 입력 이벤트를 전달합니다
• Presenter : View와 Model 사이의 중재자 역할을 합니다. View와 1:1로 연결되며, 인터페이스를 통해 View에 의존합니다.

 

데이터 흐름

1. 사용자의 액션이 View를 통해 들어옵니다
2. View는 데이터를 Presenter에 요청합니다.
3. Presenter는 Model에게 데이터를 요청합니다
4. Model은 Presenter에서 요청받은 데이터를 응답합니다.
5. Presenter는 View에게 데이터를 응답합니다.
6. View는 Presenter가 응답한 데이터를 이용하여 화면을 나타냅니다.

 

Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 접착제 역할을 합니다.

MVP는 MVC의 단점이었던 View와 Model의 의존성을 해결하기 위해 등장한 만큼 View와 Model의 의존성이 없다는 것을 장점으로 꼽을 수 있습니다.

 

 

---

 

 

 

MVVM 패턴

MVVM는 Model / View / View Model의 앞글자를 따서 만들어진 이름입니다.

UI와 로직을 더 명확하게 분리하고, 양방향 데이터 바인딩을 통해 View의 상태를 자동으로 업데이트할 수 있도록 설계된 구조입니다.

 

Microsoft에서 WPF(Windows Presentation Foundation)을 위해 제안한 이후 안드로이드나 웹에서 널리 사용되고 있습니다.

 

구조

• Model : 데이터 처리와 비즈니스 로직 담당
  [ DB처리, API 통신, 내부 계산 등이 여기에 해당 ]
• View : 사용자 인터페이스(UI) 담당. 
• View Model : View를 표현하기 위해 만든 View를 위한 Model. View를 나타내기 위한 데이터 처리

 

데이터 흐름

1. 사용자의 액션이 View를 통해 들어옵니다
2. View에 액션이 들어오면 Command 패턴으로 View Model에 액션을 전달합니다
3. View Model은 Model에게 데이터를 요청합니다
4. Model은 View Model에게 요청받은 데이터를 응답합니다
5. View Model은 응답받은 데이터를 가공하여 저장합니다
6. View는 View Model과 데이터 바인딩하여 화면을 나타냅니다

 

바인딩을 통한 UI 자동 갱신으로 View코드를 최소화할 수 있습니다.

또한 View Model은 View에 직접 의존하지 않아 테스트가 용이하고, 구조가 명확하며 확장성이 뛰어나다는 장점이 있습니다.

 

다만 바인딩 로직이 복잡해질 수 있고, 작은 프로젝트일 경우 오히려 오버엔지니어링이 될 수 있다는 단점이 있습니다.

 

 

---

 

출처

• https://velog.io/@eugenieseo16/CS4
• https://beomy.tistory.com/43