Front-End 개발자로 일하기 위해
여러 채용공고들을 살펴보다가,
JavaScript MV* 패턴 에 대한 이해와 활용한 개발 경험이
우대 사항도 아닌 지원 자격에 있는 것을 보고 궁금해서 시작된 글
JavaScript MV*패턴이란?
JavaScript MV* 패턴 이란
JavaScript를 이용하여 웹 개발을 하면서,
조금 더 '효율적'이고 '간편한' 개발을 위해 프레임워크를 사용했다.
여러 프레임워크들마다 '효율적'이고 '간편한' 개발이 무엇인지 생각했고
이것을 개념화 한 것이 '아키텍처 패턴'이다.
아키텍처 패턴에는 MVC, MVVM, FLUX, Atomic 패턴 등 여러 종류가 있다.
MV*는 Model과 View 구조를 따르는 아키텍처 패턴을 말한다.
아키텍처 패턴들은 모두에게 각자 나오게 된 사연이 있는데
각 아키텍처 패턴이 왜 나왔는지 한 번 살펴보도록 하자.
여기서 잠깐.
MV* 패턴에 대해 알아야하는 이유가 있을까?
Front-End 개발 분야는
다른 개발 분야들과 다르게 빠르게 대세 프레임워크가 바뀐다.
왜냐하면 각 프레임워크가 완벽하지 않기에,
그것들을 보완하고자 아키텍처 패턴들이 새로 생기고,
그것을 적용한 프레임워크가 생겨난다.
각 개개인마다 생각하는 바가 다르겠지만,
그저 빠르게 바뀌기만 하는 프레임워크를 공부만 하고,
정작 '왜' 바뀌는지에 대해 알지 못한다면
능동적으로 사고하는 개발자가 아니라 코드를 짜주는 GPT가 될 것만 같았다.
때문에, 조금 더 이해하기 위해 아래의 글까지 끄적여본다!
MVC 패턴
(with jQuery..)
먼저 초창기에 등장한 MVC패턴이다.
Model: 데이터를 처리 및 관리
View: 사용자에게 보여지는 UI
Controller: 클라이언트에게 Action을 입력받아 처리
액션 처리 과정
- 클라이언트에서 입력된 Action들이 Controller로 들어온다.
- Controller는 Action에 따라, Model을 업데이트한다.
- Controller는 Model의 업데이트 됨에 따라 바뀌는 View를 선택한다.
- 선택된 View는 Model로부터 데이터를 받아와서 업데이트한다.
MVC 아키텍처 패턴의 한계
- 대규모 프로젝트의 경우 Controller가 많은 Model과 View가 연결되어 Controller가 과도하게 커지는 현상이 생긴다. 때문에 유지보수에 많은 시간과 노력들이 소요된다.
- MVC 아키텍처 패턴을 주도적으로 사용하는 jQuery의 경우, 명령형 프로그래밍 방식으로 작동한다는 것이다. 때문에, 중복되는 코드들돠 더불어 비슷한 작업에 많은 시간을 소모한다는 것이다.
MVVM 패턴
(with Angular, Vue, React...)
그 다음으로 소개할 것은 MVVM 아키텍처 패턴이다.
Model: 데이터를 처리 및 관리
View: 사용자에게 보여지는 UI
ViewModel: View와 Model의 중간계층, 데이터 가공 처리
View와 ViewModel의 차이점
여기서 그렇다면 Model 과 ViewModel 의 차이가 무엇인지 궁금해 할 수 있다.
Model 은 데이터와 비즈니스 로직 관리에 중점을 두며 View 와 소통을 하지 않고, ViewModel 이 변화한 데이터를 바탕으로 View 와 소통을 한다.
액션 처리 과정
- 클라이언트에서 입력된 Action들이 View로 입력된다.
- View는 Action에 따라 자신이 사용한 ViewModel을 선택한다.
- ViewModel은 Model에게 데이터를 요청한다.
- ViewModel은 받은 데이터를 가공한 뒤, 데이터 바인딩을 통해 데이터를 전달한다.
개선된 점
- 데이터 바인딩을 통해 각 요소간의 의존성을 줄였다.
- MVVM 패턴을 이용한 라이브러리 및 프레임워크를 통해 명령형 프로그래밍에서 선언형 프로그래밍으로 전환되었다. 이를 통해 중복된 코드들을 대폭 개선할 수 있었다.
한계
- 양방향 데이터 바인딩으로 인해 데이터 흐름을 예측하기 어렵고, 복잡한 상태관리를 야기할 수 있다.
- MVVM 아키텍처 패턴을 이용한 언어들에서 컴포넌트 방식으로 중복된 코드들을 제거하기 시작했는데, 이에 props-drilling 문제가 발생했다.
Flux 패턴
(With Redux...)
그 다음으로 소개할 것은 FLUX 패턴이다.
View: 사용자에게 보여지는 UI
Action: 애플리케이션 내에 발생하는 사건 및 이벤트
Dispatcher: Action을 받아서 Store에 Action을 분배
Store: 상태를 저장하고 관리하는 곳
액션 처리 과정
- 클라이언트에서 View를 통해 입력된 Action이 발생한다.
- Action들이 생성되어 Dispatcher로 넘어간다.
- Dispatcher에서 각 Action이 등록된 Store에 배분한다.
- Store에서 액션 유형에 따라 액션을 처리하여, 상태를 변경한다.
- 상태가 변경된 스토어는 View에 변경사항을 통지한다.
개선된 점
- 컴포넌트 간의 결합도가 낮아지고, 재사용성이 향상되었다.
- 상태 변화가 중앙 집중화 되어, 관리에 용이하다.
한계
- 코드의 복잡성이 향상된다.
- 중앙 디스패처가 모든 액션을 처리해, 대규모 프로젝트의 경우 성능 이슈가 발생한다.
내 생각
여기서 소개되지 않았던 MVP 아키텍처 패턴들과, MVI 아키텍처 패턴들이 존재하고,
그나마 최근에 사용되는 Atomic 패턴과 React-Query패턴들도 있다.
아직 정답인 아키텍처 패턴이 없다.
하지만 내 개인적인 생각으로는 정답은 존재하지 않을 것 같다.
완벽해보이는 것에도, 사람들은 더 나은 것들을 발견하고
세상에 새로운 혁신을 제공한다.
개인도 마찬가지인 것 같다.
늘 현실에 안주하지 않고 성장하려는 사람이
더 나은 미래를 만들 것이다.
나는 그러한 사람이 되고 싶다:)
아직 많은 패턴들을 겪어보지 못했지만,
기회가 된다면 jQuery 같은 언어들도 접해보고 싶다.
과거에서 새로운 방법을 찾을 수도 있고,
나는 아직 많은 것을 경험해 보고 싶다.
참고문헌
