웹 프론트엔드 아키텍쳐(MVC/MVVM/FLUX)

처음 개발 할 때에는 규칙없이 그냥 코드를 만들다 보면,
덩치가 커지는 순간 불편함이 생기고 정리가 안 되는 시점이 생깁니다.
그러니 처음부터 특정한 규칙을 만들어서 개발을 하는게 좋다는 것을 알게 되고,
규칙을 하나씩 만들어가며 개발을 하다보면 이것이 반복이 되어 하나의 특정 패턴이 만들어집니다.
이러한 패턴들을 모두가 이해하고 따를 수 있도록 하는 구조를 아키텍쳐라고 부릅니다.

 

그러므로 아키텍처란 좋은 구조를 만드는 것을 뜻하는데 좋은 구조의 첫번째 조건은 좋은 분류입니다.

 

MVC 아키텍처

Model, View, Controller라는 영역으로 나누는 고전적인 방식입니다.

 

View(화면): 최종적으로 HTML과 CSS로 만들어지는 결과물

Model(데이터): 데이터를 주관하는 영역

Controller(컨트롤러): Model의 데이터를 받아서 화면에, 화면으로부터 사용자의 동작을 받아서 Model을 변경하는 Model과 View 사이의 중간 역할

 

 

MVC가 이렇게 나누어진 이유

 

1. 화면을 다루는 문제와 데이터를 다루는 문제의 성격이 다르기 때문입니다.

2. Model과 View간의 의존관계를 최소화 해서 화면의 수정이 데이터의 수정에 영향을 미치지 않고 데이터 수정이 화면의 수정에 영향을 미치지 않고자 함입니다.

 

 

웹 프론트엔드라는 개념도 없던 웹 서비스 초창기 시절의 MVC는

• 데이터 베이스를 Model,
• HTML, css, javascript까지 포함한 클라이언트 영역을 View,
• 가운데서 라우터를 통해 데이터를 처리하고 새로운 HTML을 만들어서 보여주는 백엔드 영역을 Controller라고 취급했습니다.

 

jQuery, ajax라는 기술이 만들어지면서 HTML을 서버에서 직접 만들 필요가 없게 되었습니다.

이때부터는 웹 프론트엔드의 MVC 개념이 조금씩 바뀌게 됩니다.

• ajax로 부터 받는 데이터를 Model,
• HTML과 CSS로 만들어지는 화면을 View,
• javascript가 중간에서 서버의 데이터를 받아서 화면을 바꾸고 이벤트를 처리해서 데이터를 전달하는 Controller의 역할을 수행하게 됩니다.

 

MVVM 아키텍쳐 - angular, react, vue

 

등장 배경

 

jQuery로 작업을 하다보니 상당히 불편한 점을 발견하게 됩니다.

데이터를 찾아서 데이터를 바꾸고 데이터를 수정하고 이벤트를 연결하고 이벤트를 수정하는 부분들에서 피곤한 반복적인 패턴이 나타난다는 것을 알게 되었습니다.

 

서버에서 개발을 할 때에는 html이 전체적으로 렌더링으로 되다보니 {{ }}, <?= ?>, <%= %> 와 같은 치환자로 통해 선언적으로 편하게 개발을 하는 반면,

jQuery의 경우 전체 html를 갱신했다가는 번쩍거리는 화면을 맛볼 수 있으니 수정해야 할 부분을 일일히 찾아서 수정을 해줘야 했습니다.

 

클라이언트 개발도 서버처럼 템플릿과 같은 선언적인 방식으로 개발을 할 수 없을까? 라는 개념을 바탕으로 템플릿 바인딩 기반의 라이브러리 등이 만들어집니다.

 

013년에 구글에서 앵귤러가 발표가 됩니다. 앵귤러에서 템플릿과 바인딩이라는 중요한 개념들이 등장을 하였고 이후로 웹 개발하는 방식의 패러다임이 완전히 바뀌게 됩니다.

 

Model이 변하면 View를 수정하고 View에서 이벤트를 받아서 Model를 변경한다는 Controller의 역할은 그대로 인데,

이를 구현하는 방식이 jQuery와 같은 DOM 조작에서 템플릿과 바인딩을 통한 선언적인 방법으로 변하게 됩니다.

 

이제는 코드에서 DOM을 조작하는 코드가 사라지고 이 기능들은 프레임워크가 담당하게 됩니다.

이제 개발자는 화면에 그려져야할 데이터만 만들어서 프레임워크에 전달해주면 프레임워크가 알아서 그려줍니다.

 

이를 View를 그리는 Model만 다루게 되었다는 의미로 ViewModel이라고 부르며
이 방식을 MVVM이라고 부르게 됩니다.

 

 

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

 

 

MVC에서 MVVM으로 오면서 달라진 부분

• 컨트롤러의 반복적인 기능이 선언적인 방식으로 개선이 되었다.
• Model과 View의 관점을 분리하려 하지 않고 하나의 템플릿으로 관리하려는 방식으로 발전했다. (기존에는 class나 id등으로 간접적으로 HTML에 접근하려고 했다면 이제는 직접적으로 HTML에 접근하는 방법으로 확장이 되었다.)

 

 

컴포넌트 그리고 Container-Presenter 패턴

웹 서비스가 발전하게 되면서 이제는 하나의 Page단위가 아니라 Page안에 여러가지 모듈이 있고 Modal이나 여러 화면들이 하나의 화면에서 구성이 될 수 있도록 발전을 하게 됩니다.

 

그래서 MVVM이 이제 화면단위가 아니라 조금 더 작게 재사용 할 수 있는 단위로 만들어서 조립을 하는 방식으로 발전을 하게 됩니다.

 

이것이 우리는 이미 이제 익숙한 Component 패턴입니다.

 

컴포넌트는 재사용이 가능해야 한다는 원칙에 따라 가급적 비지니스 로직을 포함시키지 않으려고 개발을 했습니다.

비지니스 로직이 들어가게 되면 컴포넌트의 재활용성은 상당히 떨어지게 됩니다.

 

그래서 비즈니스 로직을 관장하고 있는 컴포넌트를 Container 컴포넌트라 그러고

혹은 이제 비지니스 로직을 가지고 있지 않은 데이터만 뿌려주는 형태의 컴포넌트를 Presenter 컴포넌트로 분리하여

최상단 혹은 1depth에 Container를 두고 비지니스 로직을 관리하는 Container-Presenter 아키텍쳐가 만들어집니다.

 

비즈니스 로직이란?

사용자가 원하는 자료의 가공 부분
e.g) 자료를 저장할때는 부가세가 포함되지않고 자료가 저장이 되어있는데, 최종적으로 사용자에게는 부가세가 포함된 자료를 디스플레이해야 하는 업무를 처리해야 한다고 할 때 이를 처리하는 과정을 의미한다.

 

 

 

이렇게 만들게 됐을 때 알게된 문제는 컴포넌트 구조가 복잡해짐에 따라 하위에 특정 값을 전달하기 위해서는 중간 레벨에 있는 컴포넌트들은 전부 그 props를 가지고 있어야 하는 문제가 발생합니다.

 

 

이렇게 상단에 있는 데이터를 하단에 있는 props로 보내기 위해서 중간 계층에 있는 props를 하나씩 추가하는 문제를 Props Drilling Problem이라고 부릅니다.

 

그래서 이러한 문제를 해결하기 위한 새로운 아키텍쳐를 생각합니다.

 

 

FLUX 패턴과 Redux

 

 

FLUX패턴은 이제 MVC의 개념에서 벗어나서 단방향 아키텍쳐 (uni-directional architecture) 를 만들자는 이야기로 시작합니다. MVC는 문제점이 있다고 말하죠.

 

정확히는 MVC의 문제점이 아니라 기존의 MVC의 경계에 대한 이야기였습니다. 컴포넌트의 재사용과 독립성을 지나치게 강조하다보니 같은 데이터를 공유하는 과정에서 props을 통해서 데이터를 전달하는 문제들로 하여금 Model의 관리가 파편화 되는 문제가 발생했습니다.

 

 

그래서 FLUX 패턴이라고 하는 단일 흐름을 만들었으면 좋겠다라는 식으로 발표가 됩니다.

 

Redux

 

Redux는 기존의 Props Drilling Problem의 문제점을 정확히 짚어주었고,

Store, Dispatch, Reducer에 대한 개념을 정확하게 다시 정리해주었습니다.

 

FLUX 패턴은 View를 각각의 MVC 컴포넌트 관점으로 보는 것이 아니라 하나의 큰 View로 이해하고,

View에서는 Dispatch를 통해서 Action을 전달하면 Action은 Reducer를 통해서 Data가 Store에 보관이 되고 Store에 들어있는 데이터는 다시 View로 연결이 되는 방식을 지향합니다.

 

기존의 컴포넌트 단위의 MVC개념에서 완전히 비지니스 로직과 View를 분리하면서 이 분리된 개념을
상태관리(State Management)라고 부르게 됩니다.

 

 

MVC에서 FLUX으로 오면서 달라진 부분

• 공통적으로 사용되는 비지니스 로직의 Layer와 View의 Layer를 완전히 분리되어 상태관리라는 방식으로 관리한다.
• 각각의 독립된 컴포넌트가 아니라 하나의 거대한 View 영역으로 간주한다.
• 둘 사이의 관계는 Action과 Reduce라는 인터페이스로 분리하며 Controller는 이제 양방향이 아니라 단반향으로 Cycle을 이루도록 설계한다.

 

FLUX 패턴은 각 프레임워크 진영에게 많은 영감을 주었으며 프레임워크와 더불어 본격적인 상태관리 라이브러리들이 만들어지기 시작하게 되었습니다. Redux, Vuex 등이 대표적인 상태관리 라이브러리입니다.

 

FLUX 패턴의 한계

1. 높은 학습곡선
2. 장황한 문법

 

간단한 구조에서는 앞에서 언급한 Props Drilling Problem이 치명적이지 않았으나

상태를 관리하기 위해서 Action, Dispatch, Reducer를 만들고 관리하는데 들어가는 많은 부수적인 코드들로 인해 관리가 되려 어려워 진다는 문제가 있었습니다.

 

 

Atomic 패턴 - Recoil, Svelte Store, Vue Composition, jotai

거대한 View영역과 Store영역을 나누어 이분법으로 생각하자는 의견에는 동의하나

Action ~ Dispatch ~ Reducer와 같은 복잡한 구조를 가져야 하는가에 대한 방법에 대해서는 회의적인 시각으로 만들어진 방법입니다.

 

간단한 문법으로 컴포넌트 외부에서 공통의 데이터를 set, get을 할 수 있게 하면서 동시에 동기화를 할 수 있는 방향성입니다.

이와 더불어 computed, derived, select 와 같은 반응형 기능을 제공하여 관련된 데이터의 동시 업데이트를 제공하고 있습니다.

 

개선방향

• View와 Model은 분리한다.
• 중간의 과정은 자율에 맡기고 간단하게 Model에 접근하는 법만 제공하자.
• 동기화, 동시성 처리가 중요

 

 

최근 아키텍쳐의 방향성

• 단방향 아키텍쳐
• 선언적 프로그래밍을 통한 Controller
• 뷰와 비지니스 로직의 분리(상태관리)
• 반응형 프로그래밍
• 서버와의 연동을 Controller로 간주하는 움직임

 

 

 

 

참고자료

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

프론트엔드에서 MV* 아키텍쳐란 무엇인가요?

https://m.blog.naver.com/anjdieheocp/20117559228

비즈니스 로직(Business logic)이란?