
sub system, component, module과 같은 관계 구성 요소 사이의 관계 구조를 설계하기 위해 기술적으로 축적된 해결 방법 또는 기본 system 틀Architecture pattern과 비슷하지만 보다 좁은 의미의 특정한 상황에서 구조적인 문제를 해결한 설계 방법 또는 해결하는 방식위 두 pattern을 간단하게 비교한 이유는 단순히 MVC pattern을 공부하기 위해 찾아보다가 MVC를 Architecture pattern으로 기술한 자료도 있고 Design pattern으로 기술한 자료도 있어 좀 더 정확하게 공부해야겠다 싶어 찾아보고 일단 간단하게 개념만 정리했다.
MVC자료를 찾아보니 MVP와 MVVM 같은 pattern이 MVC에서 파생되었다고 하는데 위키백과에 따르면 MVC는 Design pattern이라 기재되어 있고 MVP,MVVM은 Architecture pattern에서 파생되었다고 기재되어 있다.
찝찝한 마음으로 일단은 유추를 한다면 MVC pattern도 Architecture pattern에서 파생되었다고 일단 정리하고 후에 더 많은 자료와 관련 서적도 찾아보고 정확하고 확실한 개념 정리가 필요하다.

MVC는 Model, View, Controller의 합성, 축약어로 Web 구조를 설계할 때 위 세 역할로 나누어 설계하는 Design pattern이다.
상태 변경과 같은 Event가 발생하는 것을 Action이라 하고 Controller에서 발생한 Action받아 Model 또는 View로 알려준다.
Model : 저장되어 있는 상태의 변화가 생기면 Controller와 View에 전달 한다.
View : Model에서 받아 온 상태 정보를 보여주는 역할
Controller : 사용자 Action에 따라 Model의 상태와 같은 정보를 어떻게 관리할 지, View에서 Model의 정보를 어떻게 출력할 지 관리한다.
최근에 side-project로 Back-end 개발을 하면서 Django의 기본을 공부하면서 사용했던 경험이 있는데(아직 ing..), 딱 Django가 MVC를 명확하게 보여주는 framework라는 생각이 들었다.
Controller, View, Model 모두 의존 관계를 가지고 있어 규모가 클수록 로직이 복잡해지고 유지보수가 어렵다. Model은 하나의 View를 위한 정보를 가지고 있어 Model을 다시 사용하기 어렵다.

MVP pattern은 MVC에서 파생되어 구조는 비슷하지만 Controller가 아닌 Presenter가 존재한다. MVC에서는 Model과 View사이의 관계도 있었지만 MVP에서는 Presenter가 철저하게 View, Model을 관리한다. 또한 사용자의 Action을View를 통해 받는다.
Presenter : View에서 받아 온 Action에 따라 Model을 update하거나 Action에 따른 출력 정보를 View에게 다시 전달한다. View와 Presenter는 1:1 관계이고 View는 Presenter를 통해서만 Update가 가능하기 때문에 하나의 View를 알고 있는 Presenter를 다른 View에서 다시 사용하기 어렵다.

MVVM pattern은 모든 Action에 관한 처리를 모두 View에서 한다. MVC와 MVP의 Controller, Presenter가 필요 없고 정보 처리가 MVC, MVP보다 직렬적인 관계를 가진다. 대신 View의 Model 정보를 처리하기 위한 ViewModel이 존재한다.
MVVM의 특징은 View가 ViewModel에서 변경 사항을 가져올 때 ViewModel 내 변수와 같은 정보 처리에 binding되어 ViewModel의 변경된 정보가 View에서도 바로 반영이 된다. 이를 Data binding이라고 한다.
View에 대한 처리가 복잡해질수록 ViewModel에 대한 설계도 더 복잡해진다.
Reference
https://boxfoxs.tistory.com/394#recentComments
https://academy.realm.io/kr/posts/eric-maxwell-mvc-mvp-and-mvvm-on-android/