WebArchitecture

Frontend MVC 패턴

, ,

프론트엔드에서 MVC 패턴을 사용 안하는 이유

프론트엔드에서 MVC 패턴을 대체하는 패턴들과 등장 배경 이유를 알아보자.

백엔드에서의 수행 절차

  1. client 의 request 를 받는다. (브라우저 or 앱)
  2. request 를 분석한다. (라우팅)
  3. 필요한 데이터를 수집 / 가공 한다. (데이터 베이스 조회)
  4. 뷰를 생성하고 response 한다.

플로우

컨트롤러 → 모델 → 뷰 → 컨트롤러가 이렇게 흐름상 하나의 흐름으로 이어진다고 볼 수 있다.
이 결과 문제는 각각의 레이어들 사이에 강한 의존성이 생기는 문제가 존재 한다.

그래서 이부분에 대해 실제 MVC 에서는 동작은 아래와 같이 진행된다.

이런식으로 Controller 가 Model 을 통해서 데이터를 수집하고, 가공하는걸 부탁해서 받아온 다음에 그 Model 정보를 다시 View 에 전달을 해준다. 물론 View 에 전달을 할 때 Model 객체를 넣어주는 경우도 있다.

들여다 보면 model 과 View 간에 어느 정도 의존성을 완전히 없애지는 못하지만 중간계층에 컨트롤러가 많은 역할을 해서 Model 과 View 컨트롤을 많이 하는 경우가 있다.

Controller 예)

1
2
3
model = new Model();
view = new View(model);
view.makeHTML();

이렇게 백엔드에서는 MVC 패턴이 굉장히 유용한데, 프론트엔드 에서도 소프트웨어 개발 관점에서 이걸 그대로 쓸 수 있지 않을까? 란 생각을 하게 된다.

프론트엔드 SPA 개발 관점으로 보면 아래와 같을 것이다.

SPA 에서는 URL 이 여러 개가 존재할 수가 있다. URL 이 존재하는데 페이지는 전환이 되지 않고 컨텐츠 내용만 업데이트 되는 형식이다.

서버에서 리퀘스트 정보를 받아서 처리하는 컨트롤러를 생각해보면 그거와 굉장히 유사한 일을 클라이언트에서도 한다고 볼 수 있다.

그래서 URL 을 분석하는 일들을 좀 할 수가 있다. 사용자가 입력한 URL 분석을 해서 그거에 따라서 어느 부분을 렌더링 해주는 역할을 할 수가 있다.
이것만 봐서는 백엔드의 처리와 거의 비슷한 역할을 프론트엔드 에서도 한다는 걸을 알 수가 있고그러다 보면 MVC 를 쉽게 적용해서 그래로 활용할 수 있을 것이라고 생각을 할 수가 있다.

하지만 현실을 그렇지 않은 경우가 더 많다. View 단은 복잡하게 구성되어지게 되기 때문인데..

10 년 훨씬 전부터 프론트엔드는 복잡한 View 가 많아졌다.

  • 카카오 맵
  • 구글 시트
  • 포털 사이트
  • 쇼핑 사이트
  • 기타 등등

페이지 전환 없이 여러가지 렌더링 일을 하는 싱글 페이지 어플리케이션이 많아지고 있고, 이 부분은 당연히 기술이 발달함에 있어 브라우저에서 CSS, JS 로 이전 보다 표현 및 기능 들이 처리 가능해졌기 때문..

다시 본론으로 와서 보면… 사실 프론트엔드는 그 자체가 View 이다.

그래서 사실은 MVC 같은 패턴이 필요한게 아니고, 그냥 View 대한 처리가 필요한 걸 수도 있다.

보통 백엔드 관점에서의 View 를 어떤식으로 얘기하는가를 보면

보통 MVC 에서는 View 는 만들어지는 결정체 일뿐…

컨트롤러가 입력을 받고 그 다음 모델에서 데이터를 조회/가공하고 클라이언트에 줄 Response 할 View 를 만드는 것.

거기에 반해 프론트엔드의 View 는 아무래도 다르다. 다시 말하자면 프론트엔드에서의 View 는 온갖 이벤트가 발생한다.

즉, 백엔드 관점의 View 개념 처럼 가만히 있는 View 가 아니라, View 가 바로 메인이자 컨트롤러와 같은 일을 할 수 밖에 없는 상황이 생기게
되는 것이다. 그러다보니 문제의 진입점이 굉장히 다양하게 되어 버린다.

실제로 View 에서 일어나는 일들을 살펴보면

이처럼 View 안에서 여러가지 일들이 있다.

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

입력 값을 통해 Model 이 변경 된다.

이와 반대의 케이스의 경우도 있다.

모델의 변경, 즉 서버로 받은 데이터 또는 어떤 주기적으로 데이터를 생성하는 일이 생긴다거나 그럴 때 View 를 바꿔야 되는 경우도 있다.

그러면 결국 View 와 Model 이 양쪽으로 복잡한 관계가 될 거라는 예상을 할 수 있을 것이다.

이런걸 양방향 이라고 볼 수 있는데, 결국 이런 양방향의 문제가 프론트엔드에서는 상당히 복잡도를 올린다고 볼 수 있다.
그리고 한가지 더 프론트엔드 상황을 보면 View 는 아주 많다는 것이다.

View 를 하나만 만들 수도 있지만, 그렇게 되면 View 가 너무 커지게 되어 버린다.
그래서 View 를 컴포넌트로 단위로 쪼개서 나누게 된다.

그러다 보면 View 와 Model 이 양방향으로 데이터를 교환하는 것이데… View 도 엄청 많고 또 흔한 경우는 아니지만 그에 따른 모델도 굉장히 다수의 모델이 존재할 수가 있게 되어 버린다.

그럼 어떻게 되는 것인가?

결국 서로 간에 의존성이 많아지게 되고 View 와 Model 간의 복잡도가 훨씬 더 올라가게 되어 버린다. View 하고 Model 중 어디서 어디로 호출 하는지 굉장히 혼란스럽게 된다. 더구나 Model, View 가 서로 엄청 호출한다. 그래서 강한 의존성도 생기게 되고…

이 문제를 해결하기 위해 당연히 MVC 에 Controller 역할을 하나 만들어 주면 되지 않을까 생각해 볼 수 있다.

하지만 Controller 는 복잡한 View 와 model 을 끌어 안고 있기 때문에 슈퍼 울트라 컨트롤러 같은 역할의 Controller 가 될 수 밖에 없는 것이다.
컨트롤러가 굉장히 비대해지는…

여기서 또 하나의 프론트엔드의 View 특징을 알아본다면

View 는 계층적인 구조를 가지는게 필요하다.

컴포넌트로 잘게 쪼개서 나누었을때 View 는 어떻게 보면 결국 DOM 이란걸 브라우저에 렌더링 해서 표현하는 것이다.

DOM 은 트리 구조로 되어 있다. 따라서 View 영역도 DOM 만큼 잘게 나누지는 않지만 어느 정도 트리 구조를 가지면서 이를 제어 해야 된다.
왜냐하면 View 는 잦은 리렌더링으로 다시 렌더링 되는 경우가 많이 있기 때문이며, 이를 제어하기 위해서는 이 계층적인 것을 원래의 (DOM) 구조를 활용하면서 리렌더링을 최소화 해주는 그런 방법들을 찾아야 한다.

프론트엔드에서 가장 비싼 비용에 속한 부분 중 하나가 DOM 변경이 해당 되며 가장 느린 작업 이기 때문이다. 그렇기 때문에 하나의 큰 덩어리 구조가 아닌 어느정도 계층적인 구조를 만들어서 렌더링 효율성을 얻어야 되는 것이다.

정리

  • View 가 아주 많다
  • 양방향 처리가 필요하다.
  • 슈퍼 울트라 컨트롤러가 생긴다
  • View 간의 계층처리가 필요하다.

그래서 , 필요한 것은?

  • 복잡한 View, Model 관계 단순화.
  • View 계층 처리로 쉽고 효율적인 DOM 처리.

백엔드의 MVC 패턴으로 프론트엔드 적용해서 이와 같은 문제를 해결 할 수 있는가….
결론적으로 적합 하지 않다고 볼 수 있다.

그렇기에 현재 프론트엔드에서 사용되는 주요 기술들은

  • 데이터 바인딩 (렌더 자동화)
  • MVVM 패턴 (Vue.js)
  • Flux 아키텍처 (React.js)

등을 등장 되어 사용되며 앞서 설명했던 문제들을 잘 해결해 주고 있다.

MVVM 패턴 Flux 패턴

이처럼 프론트엔드에서의 View 는 많은 특성이 있다.

View 자체가 엄청 많고 그에 따른 인터렉션을 제어하는 이벤트들도 많다. 따라서 백엔드에서 사용하는 MVC 패턴보다 더 나은 선택이 필요하
기 때문에 MVVM, Flux 등의 과 같은 패턴들을 채택하게 되어서 사용 되어지고 인기를 얻고 있는 이유 일 것 이다.

참조

공유하기