MVC,MVVM 아키텍쳐

프롤로그

앞서서 아키텍쳐란 무엇인가를 공부해봤습니다. 좋은 아키텍쳐란 코드 가독성을 좋게 하며, 유지 보수가 쉽도록 하는 도와준다는 것은 어렴풋이 알겠는데, 그렇다면 종류가 어떤 것이 있을지? 이 글에서는 MVC, MVVM 이 무엇인지 이해하고자 노력하는 비전공자의 노력이라고 봐주시면 감사하겠습니다.

공부하며 참고한 자료는 하단에 출처를 남기겠습니다. 문제시 댓글 남겨주세요!

전통적인 MVC 아키텍쳐

MVC는 아주 오래된 패턴으로, 1970년대에 만들어져서 1980년대 보편화되었다고 한다.

MVC, 즉 Model, View, Controller 영역으로 구조를 나눈 것

Model(데이터)

모델은 어플리케이션에서 사용되는 데이터와 그 데이터를 변경시키는 비즈니스 로직이다.
모델의 범주는 아키텍쳐에 따라 달라질 수 잇다.

ex) Javascript의 Object, 서버의 API 로 받는 데이터, 서버에 있는 DB

화면이 아닌 소프트웨어가 다뤄야할 중요한 데이터의 영역이다.

View(화면)

사용자가 눈으로 볼 수 있는 화면, 웹 프론트에선 HTML, CSS로 만들어진 결과물

Controller(컨트롤러)

Model의 데이터를 받아서 화면에 그리고, 화면에서 이루어진 사용자의 동작을 받아서 Model을 변경한다. Model과 View 사이의 중간 역할을 하는 것을 Controller 라고 한다.

MVC가 많이 적용된 백엔드 어플리케이션을 만들 때의 수행절차를 보면

1. 클라이언트가 request를 보낸다
2. request 분석 (Controller 담당)
3. 필요한 데이터를 수집/가공 (Model 담당)
4. 뷰를 생성 (view)
5. 결과 응답(Controller)

출처) 프롱트_프론트엔드에서 MVC보다 더 많이 쓰이는 패턴은? 영상 캡쳐 이미지

하지만 프론트엔드에서 MVC 아키텍쳐를 사용하면 어떻게 될까?

프론트엔드의 MVC

출처:https://developer.mozilla.org/ko/docs/Glossary/MVC

10년 전부터 프론트엔드는 복잡한 형태의 view가 많아졌다.(kakaoMap, google Sheets...)

또한 우리가 경험하는 포털 사이트, 쇼핑한 사이트 등등 페이지 전환없이 하나의 페이지에서 여러가지 랜더링 일을 하는 싱글페이지 어플리케이션이 증가했다.

따라서 프론트엔드는 그 자체가 다 view이기 때문에, MVC 아키텍쳐가 아니라, View 에 대한 아키텍쳐가 필요하다.

왜냐면 보통의 MVC 에선 View는 클라이언트의 request에 의해 만들어지는 결정체라는 것이다.

But FE에서 View 는 View 에서 다양한 이벤트 들이 이러나기 때문에, View 가 메인이자 controller와 같은 일을 하게 된다

이런 프론트엔드 특성을 Model 과 View관계로 정리를 해보자면

1. view의 변경으로 Model 을 바꿔야 하는 경우
   Ex) 사용자 입력값

2. Model의 변경으로 view를 바꿔야한다.
   Ex) 서버로 받은 데이터

이렇게 되면 view와 model의 강한 의존성, 양방향 의존성이 문제가 되고,
이들의 가장 결합은 결과적으로 어플리케이션의 복잡도를 올리게 된다.

이렇게 되면 MVC 모델 관점에서, 슈퍼 울트라 컨트롤러가 필요해지게 된다.

또한 View는 계층적인 구조가 필요하다.
View는 사실 DOM(html문서를 브라우저가 이해할 수 있도록 만든 Tree 자료 구조)을 표현하는 것이다.

랜더링이란 DOM을 바꾸는 것, 자주 DOM을 바꾼다는 것 = 자주 자료구조를 바꾸는 것,

View는 자주 자료 구조를 바꿔서 표현하는 것이 빈번하기 때문에, DOM이 가진 트리 구조 즉 계층적인 구조를 활용하고, DOM변경를 최소화 시켜줘야 한다.

화면 그냥 자주 바뀌면 안되나?
그렇게 되면, CPU 과부하에 따른 성능 저하, 사용자 인터페이스가 지연됨으로 사용자 경험 저하 등이 일어나게 된다.

따라서 프론트엔드는 애플리케이션의 성능과 사용자 경험을 최적화하기 위해서는 리랜더링을 최소화한다.
그렇기 때문에 View 간의 계층처리가 필요하게 된다.

즉, 프론트엔드 아키텍쳐에서 핵심 가치로 봐야할 것은,

• View가 아주 많다.
• View와 Model의 양방향 처리가 필요하다.
• 많은 양의 View와 Model에 데이터와 request를 처리하기 위해 슈퍼 울트라 컨트롤러가 필요하다.
• View간의 계층처리가 필요하다.

그래서 프론트엔드 아키텍쳐에서 필요한 것은

• 복잡한 view, model 단계 단순화
• view 계층처리로 쉽고 효율적인 DOM 처리가 필요하다.

따라서
1. 클라이언트의 Request을 Controller에서 받고
2. Model을 갔다가
3. View를 생성하고 다시 Controller로 전달

의 구조를 가진 MVC 아키텍쳐로는 복잡한 view와 model의 양방향을 해결하기엔 적합하지 않다.

이런 문제를 해결하기 위해서 프론트엔드에서는 데이터 바인딩, MVVM, Flux 와 같은 새로운 형태의 기술이 도입되었다.

물론 MVVM 아키텍쳐가 나오기 전에, MVC 모델을 보완한 MVP 모델을 간단히 짚고 넘어가보자

MVP (Model, View, Presenter)

출처: https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html

Model

애플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분

View

사용자가 눈으로 볼 수 있는 화면, 웹 프론트에선 HTML, CSS로 만들어진 결과물

여기까진 앞서 본 MVC 와 같다면 다른 점은 Presenter
의 등장이다.

Presenter

View에서 요청한 정보로 Model을 가공하여 View에 전달해 주는 부분

동작 방식

1. 사용자 입력(Action)들은 View를 통해 들어오게 돼요.
2. View는 데이터를 Presenter에 요청해요.
3. Presenter는 Model에게 데이터를 요청해요.
4. Model은 Presenter에서 요청받은 데이터를 응답해요.
5. Presenter는 View에게 데이터를 응답해요.
6. View는 Presenter가 응답한 데이터를 이용하여 화면을 나타내요.

MVC의 단점이였던 Model 과 View의 의존성을 없애, 유지 보수와 유닛 테스트가 쉬워졌으나,
결국 Presenter와 View는 1:1 관계이기 때문에 어플리케이션이 복잡해지면 둘 사이의 의존성이 강해진다는 것이다.

MVC 는 Model 과 View 의 의존성
MVP 는 View 와 Presenter 의 의존성 문제을 가지고 있다.

여기서 중요한 것은
데이터 바인딩이라는 기술이 등장하면서 소프트웨어 아키텍쳐의 패러다임이 바뀌었다고 생각한다.

데이터 바인딩

데이터 바인딩은 모델과 뷰 간의 동기화를 자동화함으로써 MVC와 MVP의 단점을 해결하는 데 큰 도움을 줬다고 생각한다. 데이터 바인딩을 통해 모델의 데이터가 변경되면 뷰가 자동으로 업데이트되고, 사용자 입력이 모델에 자동으로 반영됩니다. 이는 컨트롤러나 프레젠터의 복잡성을 줄이고, 코드의 유지보수성을 향상시키는데, 큰 역할을 했다.

MVVM 아키텍쳐 - Angular, React, Vue

MVVM(Mode-View-ViewModel) 아키텍처는 데이터 바인딩을 효과적으로 활용하는 프론트엔드 아키텍쳐이다.

이 방식이 유명해진 계기는 Google이 개발한 AngularJS의 등장이다.
AngularJS는 양방향 데이터 바인딩을 도입하여 모델과 뷰 간의 동기화를 자동화했다. 이는 MVVM 패턴을 웹 애플리케이션에 적용하는 중요한 계기가 되었다.

이후 나오는 프레임워크인 React, Vue, Angular2, Svelte등 어떤 방식의 템플릿과 데이터 바인딩 문법을 쓰느냐 방식만 다를 뿐 MVVM이라는 아키텍쳐는 그대로 유지되게 됩니다.

그렇다면 MVVM 의 구조는 어떻게 될까?

출처 : https://velog.io/@summerdewyes/%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90-%ED%8C%A8%ED%84%B4-MVC-MVP-MVVM

구조

Model: 데이터와 비즈니스 로직을 관리
View: 사용자 인터페이스를 정의
ViewModel: 뷰의 상태와 동작을 관리하고, 모델과 뷰 간의 데이터 바인딩을 처리

동작 방식

1. 사용자 입력(Action)들은 View를 통해 입력
2. Command 패턴으로 ViewModel에 사용자 입력(Action)을 전달
3. View Model은 Model에게 데이터를 요청
4. Model은 View Model에게 요청받은 데이터를 응답해서 전달
5. View Model은 응답받은 데이터를 가공하여 저장
6. View는 View Model과 Data Binding 하여 화면을 나타냄

여기서 핵심은 Model과 View의 의존성을 없애고,
Command 패턴과 Data Binding을 사용하기 때문에 View와 View Model 사이의 의존성도 없다는 것이다.
이를 View를 그리는 Model만 다루게 되었다는 의미로 ViewModel이라고 부르며 이 방식을 MVVM 이라고 부르게 된다.

컴포넌트와 Container-Presenter 패턴

MVVM 아키텍쳐를 바탕으로 웹 프론트엔드 개발은 많은 변화를 맞이하게 된다. Page 안에 여러가지 모듈, Modal 등이 하나의 화면에서 구성될 수 있도록 발전을 하게 된다.

하나의 화면에서 여러가지를 보여주려면, View 가 많아지는 것보다, 재사용이 가능한 좀 더 작은 단위로 블럭조립을 하듯 그런 방식이 필요해지게 됐다고 생각한다.

따라서, MVVM 은 View단위보다 조금 더 작게 단위인 컴포넌트 단위로 세분화 되었고, 이게 Component 패턴이다. 컴포넌트는 재사용이 가능해야 된다는 원칙에 따라, 가급적 비지니스 로직을 포함시키지 않고 개발을 진행했다.

따라서, 비지니스 로직을 담당하는 컴포넌트는 Container 컴포넌트라 하고, 데이터만 뿌려주는 형태의 컴포넌트(U중심)를 Presenter 컴포넌트라고 한다. 따라서, Container-Presenter 아키텍쳐가 만들어진다.

이 아키텍쳐를 사용하면서 느낀 불편함은 Props Drilling 이였다.

Props Drilling Problem

상위 컨테이너 컴포넌트에서 하위 프리젠테이션 컴포넌트로 Props를 전달하고, 이벤트가 발생하여 데이터 변경이 필요하면 다시 상위 컴포넌트로 전달이라는 과정이 상당히 복잡해진다는 문제점이 있다. 그래서 이러한 문제를 해결하기 위해 새로운 아키텍쳐의 필요성이 증가했다.

FLUX 패턴과 Redux

Flux는 Facebook에서 개발한 애플리케이션 아키텍처로, 특히 데이터 흐름과 상태 관리를 단순화하고 예측 가능하게 만들기 위해 설계되었다. Flux는 단방향 데이터 흐름을 통해 전통적인 MVC 패턴의 복잡성을 해결하고, Container-Presenter 패턴의 문제점을 보완할 수 있는 구조를 제공한다.

여기서의 핵심은 기존에 양방향 데이터 바인딩과는 다른 단방향 데이터 바인딩을 이용한다는 것이다.

동작 방식

1. Action: 뷰나 다른 소스에서 액션이 발생.
2. Dispatcher: 디스패처가 액션을 받아서 모든 스토어에 전달.
3. Store: 스토어가 액션을 받아 상태를 변경하고, 상태 변경 이벤트를 발생.
4. View: 뷰가 스토어로부터 상태 변경 이벤트를 받고, 새로운 상태로 다시 렌더링.

장점

1. 단방향 데이터 흐름 덕분에 데이터의 흐름을 예측하고 디버깅하기가 쉬워진다.
2. 스토어가 비즈니스 로직을 캡슐화하므로, 코드의 모듈화가 편해진다.

이 FLUX 패턴을 이용한 Redux가 탄생한다. 기존의 Props Drilling Problem의 문제점을 짚어주었다. 기존 컴포넌트 단위의 MVC 개념에서 완전히 비지니스 로직과 View를 분리하면서 이것을 상태관리라고 부르게 된다.

그러나 이 FLUX 패턴의 한계는 높은 학습곡선과 쓰기 어려운 문법이라고 합니다.
이걸 개선하기 위해 다른 패턴들이 계속적으로 나오고 있습니다.

마치며

아키텍쳐가 어떤 식으로 발전하게 되었으며, MVC이라는 개념이 웹 프론트엔드 관점에서 계속적으로 발전하고 있는지 확인해보았습니다.

아키텍쳐를 사용하면서 느꼈던 불편함에서 시작되어 새로운 아키텍쳐로 만들어지는 패러다임으로 이어진다는 것이다. 모든 것은 불편함에서 시작해, 그것을 개선하는 과정에서 해결책이 나온다는 것이다.

내가 코드를 짤 때도, 이후에 유지보수를 위해, 불편함이 있다면 그것을 개선하려고 노력하고 더 나아가 나만의 해결책 찾는 노력을 해야겠다는 생각을 했다.

참고 출처:
https://velog.io/@teo/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C%EC%97%90%EC%84%9C-MV-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94
https://www.youtube.com/watch?v=Y5vOfv67h8A
https://whales.tistory.com/137
https://beomy.tistory.com/43
https://velog.io/@summerdewyes/%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90-%ED%8C%A8%ED%84%B4-MVC-MVP-MVVM