프론트엔드와 디자인 패턴

디자인 패턴이란?

 

소프트웨어에서 디자인 패턴은 반복적으로 발생하는 문제 상황에 대한 해결책을 제시하는 일반적인 설계 템플릿입니다. 디자인 패턴은 소프트웨어 공학에서의 최선의 실천 방법을 정리하고, 재사용 가능한 코드를 작성하기 위한 지침을 제공합니다.

디자인 패턴은 다음과 같은 주요 목적을 가지고 있습니다:

• 재사용성: 디자인 패턴은 특정 문제에 대한 해결책을 제공하므로, 해당 문제가 발생할 때마다 동일한 패턴을 재사용할 수 있습니다. 이를 통해 코드의 재사용성이 증가하고, 개발 시간과 비용을 절감할 수 있습니다.
• 유지보수성: 디자인 패턴은 코드의 구조화를 도와주며, 코드의 의도를 명확하게 전달합니다. 이는 코드를 이해하고 유지보수하는 과정을 단순화하고 오류를 방지할 수 있도록 돕습니다.
• 확장성: 디자인 패턴은 변경 가능성이 높은 부분을 식별하고, 해당 부분을 분리하여 추상화함으로써 시스템의 확장성을 향상합니다. 새로운 요구사항이나 기능 추가 시에도 시스템을 유연하게 확장할 수 있습니다.
• 커뮤니케이션: 디자인 패턴은 개발자들 간의 의사소통을 촉진합니다. 공통된 용어와 개념을 사용함으로써 팀 내에서 더 효율적으로 협업할 수 있습니다.

일반적으로 디자인 패턴은 생성(Creational), 구조(Structural), 행위(Behavioral) 세 가지 범주로 나누어집니다. 이러한 패턴들은 특정 문제 해결을 위해 공식화된 해결책을 제시하며, 이를 통해 소프트웨어의 품질을 향상시키고 개발 과정을 단순화합니다.

---

프런트엔드의 디자인패턴

 

수많은 애플리케이션, 소프트웨어가 있지만 FE의 관점에서 어떻게 발전해 왔고, 어떤 문제가 있었는지 작성했습니다.

 

 

 

 

MVC 디자인패턴

 

View

- 화면에 보이는 UI

 

Model

- 데이터 영역

- javascript 메모리, 백엔드를 통해 받는 데이터, DB 등등의 소프트웨어의 데이터

 

 

Controller

- Model과 View 사이의 중간 역할

- Model의 데이터를 받아서 화면을 만듦, 사용자의 동작을 받아 Model을 변경

- 사용자와의 상호작용을 담당

 

 

 

 

 

초창기의 웹 서비스의 MVC

 

사실 프런트엔드라는 직종의 역사는 그리 깊지 않다.

클라이언트단의 사양이 복잡해지고 SPA 등의 프론트엔드 프레임워크가 본격적으로 등장하면서 생기게 되었다.

이전에는 프런트와 백엔드의 구분이 명확하지 않고, 웹사이트가 그 자체로 View의 역할을 수행하는 것으로 개발되었다.

 

 

Model - DB

View - HTML & CSS & JS
Controller - 라우터를 통해 데이터를 처리하고 새로운 HTML을 만들어서 보여주는 영역

 

 

JQuery 등장 후 MVC

 

Model - ajax를 이용해 받아온 백엔드 데이터

View - HTML & CSS & JS
Controller - 사용자 입력을 처리하고 모델과 뷰 사이의 상호작용을 조정하여 UI 로직을 제어

 

 

MVC를 최대한 분리해야 한다는 원칙에 맞게, HTML과 jQuery를 따로 관리하는 것이 이 패턴의 주요 포인트

단점

- View를 업데이트하기 위해서 결국 Model과 View 사이의 의존성이 강해질 수 있고, 이는 규모가 커질수록 복잡성이 증가하게 됨

- 데이터를 연동하고 받아오는 과정에서 반복적인 패턴이 자주 발생

- Controller에 책임이 많아져 Controller에 부하가 생길 수 있음

 

 

---

MVP 디자인패턴

 

MVC 구조에서 View와 Model 간의 의존성을 해결하기 위해 제시된 모델이다. Controller 대신 Presenter가 생긴 구조로, 한때 Android 개발에서 가장 인기 있었던 구조라고 한다.

 

Model

- 데이터를 관리

 

View

- 데이터를 보여주는 방식을 정의

- 사용자의 action이 들어오면 presenter에게 전달

 

Presenter

- Model과 VIew 사이의 중계자 역할

- 서로의 요청과 응답을 전달해 줌

 

 

장점

• View - Model 사이의 의존성 문제를 해결한다.

단점

• View - Presenter가 1:1로 연결되면서 View와 Presenter 사이의 의존성이 발생하게 된다.

 

---

MVVM 디자인패턴

 

구글에서 발표한 앵귤러 프레임워크의 출시와 함께 웹 프런트엔드의 개발 방식에 패러다임이 바뀌기 시작한다.

jQuery를 이용해 DOM을 직접 조장하는 방식에서, 템플릿과 바인딩을 통한 선언적 반식으로 변화하게 된다.

MVC의 역할을 그대로이나 구현하는 방식이 바뀐 것에 가깝다고 할 수 있다.

 

FE 코드에서 DOM을 직접 조작하는 방식이 조금씩 지양되고,

대신 프레인워크가 조작하는 방향으로 바뀌고, 개발자는 화면에 그려져야 할 데이터만 만들면 프레임워크가 알아서 그려주었다.

 

이를 View를 그리는 Model만 신경 쓰게 되었다는 의미로 ViewModel이라고 부른다.

 

Model

- 데이터

 

View

- UI

 

ViewModel

- Model을 가지고 View를 그리는 역할이자, View가 Model과 상호작용할 수 있게 하는 역할,

- UI의 재사용 가능한 부분을 추상적으로 표현할 수 있음

 

앵귤러 이후 React, Vue, Svelte 등 템플릿, 바인딩 문법의 차이가 조금씩 있을 뿐, MVVM이라는 아키텍처는 대부분

그대로 유지되어 왔습니다.

 

 

장점

• 컨트롤러의 반복적인 기능을 선언적인 방식으로 개선하였다.
• Model과 View의 관점을 분리하지 않고, 하나의 템플릿을 통해 관리하려는 방식으로 발전하게 된다.
• 웹의 DOM api를 잘 몰라도 비지니스 로직만으로 서비스를 만들 수 있다.

---

Flux 패턴

기존의 MVC 아키텍처는 컴포넌트의 재사용과 독립성에 중점을 둔 구조였습니다.
그러나 프로젝트의 규모가 커지고 복잡성이 증가함에 따라, MVC에서는 모델의 관리가 어려워지고 데이터의 흐름이 복잡해지는 문제가 발생했습니다. 특히, 같은 데이터를 공유할 때에는 props를 통해서만 데이터를 전달할 수 있어서 모델의 관리가 파편화되는 경향이 있었습니다. 이러한 문제에 대한 해결책으로 Flux 패턴이 등장하게 되었습니다.

 

Flux는 단방향 데이터 흐름을 중심으로 한 아키텍처로, 데이터의 흐름을 명확히하여 애플리케이션의 상태 관리를 더욱 효율적으로 할 수 있게 해주었습니다.

 

또한 데이터 플로우를 단방향으로 유지하여 어플리케이션 상태의 복잡성을 줄이고 데이터 변화를 더욱 쉽게 예측가능한 방식으로 처리합니다.

 

 

props drilling

• 컴포넌트 구조가 복잡할 때에 발생하는 Props Drilling Problem
• 특정 sibling에서 같은 데이터를 공유하고 사용하려 할 때 구조가 번거로워질 수밖에 없다.

⇒ 단방향 아키텍처(uni-directional architecture)에 대한 제안이 등장한다.
⇒ 비지니스 로직과 View를 아예 분리하며, 이 개념을 상태 관리(State Management)라고 부른다.

MVC 컴포넌트 관점에서 벗어나, View를 그냥 하나의 큰 단위로 바라보는 관점이다.

 

 

 

 

View에서 Dispatch를 통해 Action을 전달 → 전달된 Action에서는 Reducer를 통해 Store에 데이터를 보관 → Store에 있는 데이터는 다시 View로 연결 (단방향 cycle)

• Action
• Dispatcher
• Store

 

 

 

장점

• Props drilling problem의 해소
• 다양한 상태 관리 라이브러리가 등장하는 등 많은 영감을 줌 (Redux, Vuex 등)

단점

• 장황한 문법으로 인한 높은 학습 비용
• Action, Dispatch, Reducer를 만들고 관리해야 하므로 관리가 어려워짐

 

---

이외의 방법들

 

Atomic Pattern

거대한 View 영역과 Store 영역을 나누는 것은 동일하나, Action-Dispatch-Reducer 구조는 너무 복잡하기 때문에 손쉽게 Model에 접근하는 방법만 제공하는 것을 목표로 하는 패턴이다.

간단한 문법으로 컴포넌트 외부에서 공통의 데이터를 set, get하고 동시에 동기화를 하는 방향성이다. 더불어 computed, derived, select 등의 반응형 기능을 제공하여 관련된 데이터의 동시 업데이트를 제공한다.

Recoil, Svelte Store, Vue Composition, iotai 등이 해당한다.

 

 

React-Query

상태 관리에 편향되어 있던 시각에서 벗어나 다시 MVC의 개념을 확대하는 방향으로, 고전적인 ajax의 데이터를 Model로 간주한다.

대부분의 프론트엔드 개발은 서버 데이터를 CRUD하고 UI를 그리는 것이 중점인데, Flux, Atomic은 비동기 데이터를 처리하기에는 너무 복잡한 방법이라는 관점이다.

• Model: 서버에서 데이터를 fetch 해오는 영역
• View: React
• Controller: query & mutation. 서버 데이터의 상태를 관리하고 캐싱, 동기화, refetch 등을 관리

 

GraphQL

미리 스키마를 정의하고 이를 기반으로 데이터를 교환한다. (Schema based 아키텍처)

이 역시 서버 데이터를 Model로 간주하고, 서버와의 통신을 통해 View에게 데이터를 전달하는 방식이다.