면접 준비를 하면서 좀 더 상세하게 공부를 하고 싶어서 블로그로 정리를 해봤습니다.
MDN Web Docs에서 정의한 내용을 살펴보도록 하겠습니다.
Model-View-Controller(모델-뷰-컨트롤러) 는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴입니다. 소프트웨어 비즈니스 로직과 화면을 구분하는데 중점을 두고 있으며, 이러한 "관심사 분리" 더나은 업무의 분리와 향상된 관리를 제공한다.

쇼핑몰을 예로 들어서 설명 해보겠습니다. 사야할 물품 이름, 개수, 가격 목록을 원합니다.
이것을 MVC를 사용해서 구현 방법을 설명하도록 하겠습니다.
모델은 애플리케이션에서의 정보 및 데이터 부분을 정의합니다.
데이터의 상태가 변경되면, 모델을 뷰에게 알리고 가끔 컨트롤러에게도 알립니다.
(이 부분은 밑에서 상세하게 설명을 하겠습니다.)
쇼핑몰에서의 모델 부분은 데이터 물품, 가격등 및 이미 존재하는 리스트 항목을 지정합니다.
뷰는 앱의 데이터를 보여주는 방식을 정의합니다.
쇼핑몰에서 뷰는 사용자에게 보여지는 부분과 표시할 데이터를 모델에게 받아옵니다.
컨트롤러는 앱의 사용자로부터 입력에 대한 응답으로 모델 및 뷰를 업데이트를 해줍니다.
컨트롤러는 모델과 뷰 사이에서 데이터 흐름을 제어한다.
쇼핑몰에서 항목을 추가하거나 제거해줄때 입력이 컨트롤러에 들어가고 컨트롤러가 모델에서 전달해주고 모델이 업데이트 시킨 내용을 뷰로 전달해줍니다.
관심사 분리외에 MVC만의 장점을 알아봅시다.
- 컴포넌트를 분리해서 사용하기 때문에 가독성과 코드 재사용성이 증가되고 유지보수에 좋습니다.
- 역할을 분리해서 사용하기 때문에 협업시에 개발 효율성이 높아지고 커뮤니케이션 효율이 높아진다.
살아가다 보면 뭐든 100프로는 없다. 조금이라도 부족한 부분이 있을수 밖에 없다.
MVC패턴도 부족한 부분이 있는데 그 부분을 정리해보겠습니다.
- 양방향 데이터 흐름을 가지고있다.
- Model과 View의 의존성을 완전히 분리시킬 수 없습니다. Massive-View-Controller 현상 발생

양방향 데이터 흐름은 프로젝트가 커질수록 복잡도가 높아지게 됩니다.
Model이 업데이트가 되면 View는 화면에 반영을 할 수 있고, View도 Model을 업데이트 시킬 수 있습니다. 어떤 Model이 업데이트가 되면 View도 업데이트 되고, 업데이트 된 View가 다른 Model을 업데이트를 하고 이렇게 복잡한 데이터 흐름을 가지게 됩니다. 프로젝트가 커질수록
이러한 현상을 Massive-View-Controller이라고 합니다.
예를 들어 페이스북이나 당근에 알림이 떠있지만 실제로 알림을 누르면 아무것도 없을때가 있습니다. 이러한 버그를 해결하기 위해 단방향 데이터 흐름을 가진 패턴 다른 패턴 등을 대안으로 내놓았습니다.
다음 편에는 단방향 데이터 흐름을 가진 Flux 패턴에 대해서 내용을 정리해서 가져오도록 하겠습니다.