들어가며..
- MVC, MVVM, Flux 등 코드의 아키텍처 종류에 대해 대략적인 특징만 알고 있었다.
- 이번 기회에 여러 아키텍처의 특징을 정리해보면서, 아키텍처의 변천사를 알아보고자 한다.
FE에서의 디자인 패턴
- 흔히들 알고 있는 디자인 패턴은
생성구조행동패턴으로 분류된 개념을 떠올리곤 한다.
그래서 나 또한 위 디자인패턴을 가장 먼저 읽고 정리하게 되었고, 문득아니 이건 객체에 대한 설명같은데, 프론트 보다는 백엔드 쪽에 가깝지 않나?!라는 생각이 들어 FE에서의 디자인 패턴을 조금 더 살펴보기로 했다. - FE의 디자인 패턴은 결국
웹 디자인 패턴과 동일하게 풀이된다. - 옛날의 웹은 백엔드를 중심으로 한
읽기전용웹이 전부였고, 단순한 패턴이 웹 디자인패턴의 시작이었다.
1. MVC 패턴
- 제일 유명한 패턴일 것이다. Model-View-Controller
FE라는 개념이 없던 시절에는 웹사이트 자체가 View였기에, Model을 통한 View를 그려주는 매우 단순한 방식을 택했다.- 그렇기에
View > Controller -> Model -> View방식으로 흘러간다. - 이에 대한 단점은 아주 명확한데,
Model과 View이 끈끈하다는 것이다.- 대부분 운영환경의 경우, Model보다는 View쪽에서의 변경사항이 많이 발생한다.
MVC의 같은 경우, View의 수정이 필요할 때마다, Model의 변경또한 불가피해진다.
- 그렇기에
★ 초기에는 FE의 역할이 없어, Model을 통한 View를 그리는 매우 단순한 방식을 택했다.
⚠️ 매우 단순하지만, MVC간의 결합도가 높아
1. 코드 복잡성이 높고
2. 유지보수/테스트가 어려우며
3. 비즈니스 로직의 (관심사)분리가 애매한 상황이 존재할 수 있다.
2. MVP 패턴
- MVC패턴의 의존성을 낮추고자 나온 패턴으로,
Model-View-Presenter이다. - Presenter가 Controller의 역할을 대신하지만, 흐름의 순서에 차이가 생긴다.
View > Presenter > Model > Presenter > View와 같이 Presenter가 완벽한 중개자가 된다.
★ MVC패턴에서의 뷰-모델간의 결합도를 낮춘다.
⚠️ Presenter의 역할이 중요해지면서, 결합도 또한 증가되었다.
3. MVVM 패턴
- 이제서야 초기 현대적인 디자인 패턴이 시작되었다.
Model-View-ViewModel로, 이전의 MVP패턴과 달리데이터바인딩이라는 개념으로 결합도를 조금 더 낮추게 한다.
✅ 데이터바인딩이란
View의 속성과 ViewModel의 속성을 연결하여, 유기적인 관계로 만드는 것이다.
ex. 뷰모델의userName속성과 뷰의Input의 value속성을 바인딩하면, userName이 변경될 때마다 TextInput의 값도 자동으로 변경되는 것이다.
- 이러한 데이터바인딩을 통해, View와 ViewModel의 연결을 확립하기에 MVP패턴보다는 결합도가 낮다고 말할 수 있다.
(MVP에서 View와 Presenter가 태어날 때부터 짝꿍이었다)
★ MVVM은
데이터바인딩을 통해 UI와 비즈니스로직을 분리하여, 재사용성과 유지보수성을 높인다.
또한, 이러한 패턴은 현재의 FE 3대장인 React, Vue, Angular에서 초기개념으로 사용되었다.
⚠️ ViewModel의 설계가 어렵고, 학습곡선이 높다.
4. Component 패턴
- 인간의 욕심은 끝이 없듯이, 완벽에 가까운 MVVM패턴에서 더욱 재사용성이 높은 패턴을 찾게 되었다.
- 웹서비스가 발전하면서, 하나의 Page안에서 여러 모듈을 조립하는 방식인
Component패턴이 등장하게 되었다.
★ 재사용성, 모듈화, 독립성 등 컴포넌트를 기반으로 한 개발방식 (지금의 FE에 가깝다)
비즈니스 로직이 컴포넌트에 포함되면, 재사용성이 떨어지기에 UI와 비즈니스 로직을 분리하는Container-Presenter방식을 초기에는 활용하곤 했다.
⚠️ 컴포넌트 단위로 쪼개다 보니, 컴포넌트간의 유기적인 데이터관리가 어렵게 되었다.
Props Drilling
5. Flux 패턴
- Component패턴은 props를 통해서만 데이터를 관리하다보니, 데이터의 파편화가 있었
다. - 이를 해결하기 위해 store라는 전역저장소를 두어, 단방향적인 데이터흐름인
Flux패턴이 탄생하게 되었다.
Action객체를 Dispatcher함수를 통해 Store에 반영하면, Store를 구독하는 View에 반영되는 흐름이다.
★ Props Drilling해소
전역상태관리 시대의 시작
⚠️ 높은 러닝커브
상태관리만을 위한 코드 (보일러 플레이트, Redux)
6. Observer-Observable 패턴
- 1:다 관계의 종속성을 정의하는 패턴이다.
- Flux와 비슷하나, Action과 Dispatch를 배제하여, 변경된 값을 모두에게 전달하는 방식이다.
- 초창기의 Mobx, RxJS
7. Atomic 패턴
- 지금의 Recoil이 따르고 있는 패턴
- Redux의 Flux패턴이 너무 장황하다고 여기게 되자, Model에 쉽게 접근하는 방법을 목표로 한다.
- Atom이라는 단위로 DataModel을 설계한다.
정리하며...
- MVC패턴부터 지금의 Component패턴까지 알아보면서 느낀점은
디자인 패턴은불편한 것을 해결하거나, 더욱 나은 개선을 위해진화해왔다는 점이다. - MVC패턴의 불편함을 MVP로, MVP의 불편함을 MVVM으로 ...
- 하지만, Component패턴부터는 불편함보다는 더욱 나은 개선을 위해서인 것 같다.
(물론, 보일러 플레이트나 높은 러닝커브 또한 불편함이라고 볼 수 있겠다..)
- 현재 많이 사용되고 있는 Redux, Recoil, React등이 이러한 디자인 패턴에 기인한 라이브러리인 것을 볼 수 있기에 디자인패턴에서 탄생될 라이브러리를 잘 활용하기 위해서는 디자인패턴에 대해 계속해서 알아보는 노력을 하는 것이 중요하다고 생각이 되었다.
