프론트엔드 아키텍처란?

* 회사 기술블로그에 직접 작성한 내용을 발췌.

 

만약 개발을 할 때 어떤 규칙을 세우지 않고 코드를 짜게 되면 후에 그 코드의 양이 늘어나게 될 경우 불편함이 생기고 정리가 안되는 시점이 생기게 됩니다.​

이러한 점을 방지하기 위해 처음부터 특정한 규칙을 만들어 개발을 하게 된다면 이것이 반복이 되어 특정한 패턴이 만들어지고 이러한 패턴을 모두가 이해하고 따를 수 있도록 하는 구조를 아키텍처라고 합니다.​

소프트웨어 관점에서 지속적으로 관리가 잘 되는 코드를 위해선 좋은 아키텍처가 필요하며 웹에서도 좋은 아키텍처의 모습이 지속적으로 진화하고 있습니다.​

모든 패턴과 아키텍처에 대해서 설명드릴 순 없고 어떤 아키텍처가 있는지에 대해서와 이 아키텍처의 개념에 대해서만 간단하게 설명드릴 예정이지만 각각의 아키텍처가 어떻게 발전했고 어떤 식으로 진화하고 있는지에 대해 알게 된다면 앞으로 어떤 식으로 개발하는 것이 좋은지 판별할 수 있는 좋은 기회라고 생각합니다.​

1. MVC 아키텍처

MVC는 Model, View, Controller의 약자입니다.

순차적으로 설명드리기 위해 View부터 설명하자면 View는 화면입니다.
HTML과 CSS로 만들어지는 결과들입니다.​

Model은 데이터입니다. 정적인 웹도 존재하겠지만 사용자 입장에서 정적인 웹에서 할 수 있는 것은 아무것도 없으며 기본적인 CRUD를 위해서는 데이터가 움직이는게 보이는 동적인 웹이 필요합니다. 이러한 데이터를 주관하는 영역을 Model이라고 합니다. Model의 번주는 아키텍처에 따라 달라집니다. Javascript의 Object 일 수도 있고 서버의 API로 받는 데이터 일 수도 있고 서버에 있는 DB 일 수도 있습니다.​

Controller는 중간다리 역할이라고 볼 수 있습니다. Model의 데이터를 받아 화면에 그리고 화면으로부터 사용자의 동작을 받아 Model을 변경합니다. 이 중간 역할을 하는 것을 Controller라고 합니다.​

그렇다면 이렇게 MVC로 나뉘어진 이유는 무엇일까요?

화면을 다루는 문제와 데이터를 다루는 문제의 성격을 분명히 다릅니다. 따라서 그 두 가지를 분리하고 싶고 Model과 View 간의 의존관계를 최소화해서 화면의 수정이 데이터의 수정에 영향을 미치지 않고 데이터의 수정이 화면의 수정에 영향을 미치지 않고자 함입니다.​

하지만 지금에서야 MVC의 개념이 확실해졌지만 초창기의 프론트엔드라는 개념이 없었던 시절엔 MVC라는 것은 언어마다 그 개념이 상이했습니다. 그러다가 프론트엔드의 역할이 추가되고 ajax라는 기술이 만들어지면서 HTML을 서버에서 직접 만들 필요가 없게 되었습니다.​

이전에는 데이터베이스를 Model 취급하고 HTML과 CSS 그리고 Javascript까지 포함한 클라이언트 영역을 View, 라우터를 통해 데이터를 처리하고 새로운 HTML을 만들어서 보여주는 백엔드 영역을 Controller라고 취급했다면 ajax가 등장함으로써 ajax로 받는 데이터를 Model, HTML과 CSS로 만들어지는 화면을 View, Javascript가 중간에서 서버의 데이터를 받아서 화면을 바꾸고 이벤트를 처리해서 서버에 데이터를 전달하는 Controller의 역할을 수행하게 됩니다. 이런 Controller의 가장 주요한 역할을 했던 것이 JQuery라고 불리는 자바스크립트 프레임워크입니다.

2. MVVM 아키텍처

그다음 나온 아키텍처가 바로 MVVM 아키텍처입니다.​

JQuery로 작업을 하다 보니 상당히 불편한 점을 발견하게 되는데 데이터를 찾아서 데이터를 바꾸고 데이터를 수정하고 이벤트를 연결하고 이 이벤트를 수정하는 부분에서 반복적인 패턴이 나타나는 것을 알게 되었습니다.​

이전에 서버에서 개발을 할 때는 HTML이 전체적으로 렌더링 되다 보니 {{}} , <?= ?>와 같은 치환자로 선언적으로 편하게 개발을 했지만 JQurey는 전체 HTML을 갱신했으며 수정해야 할 부분을 일일이 찾아서 수정을 해줘야 했습니다.​

이러한 점을 어떻게 편하게 할 수 있을까라는 생각을 나온 개념이 템플릿 바인딩입니다. Model이 변하면 View를 수정하고 View에서 이벤트를 받아서 Model을 변경한다는 Controller의 역할은 그대로인데 이를 구현하는 방식이 JQuery와 같은 DOM 조작에서 탬플릿과 바인딩을 통한 선언적인 방법으로 변하게 됩니다.​

코드에서 DOM을 조작하는 코드가 사라지고 이 기능들은 프레임워크가 담당하게 되며 개발자는 화면에 표시될 데이터만 만들어 프레임워크에 전달해 주면 됩니다.

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

3. Container-Presenter

<이미지 출처 : https://generic-ui.com/blog/angular-container-presenter>

레이어 분리를 보여주는 컨테이너 프리젠터 차트

웹 서비스가 발전하게 되면서 이제는 하나의 page 단위가 아닌 page 안에 여러 가지 모듈이 있고 모달이나 여러 화면들이 하나의 화면에서 구성이 될 수 있도록 발전을 하게 됐습니다. 그래서 MVVM이 이젠 화면 단위가 아닌 조금 더 작게 재사용 할 수 있는 단위로 만들어서 조립을 하는 방식으로 발전을 하게 되며 이것이 현재 우리에게 익숙한 Component 패턴입니다.​

하지만 이런 패턴에서 또 다른 문제점이 생기게 되는데 props를 컴포넌트 간에 전달을 해주기 위해서 하위에서 상위로 그 상위에서 하위로 이동하며 모든 컴포넌트에서 그 props를 가지게 되는 문제가 생기게 됩니다.​

이러한 문제점을 Props Drilling Problem이라고 부릅니다.​​

<이미지 출처 : https://blogs.perficient.com/2021/12/03/understanding-react-context-and-property-prop-drilling/>

이러한 문제점을 해결하기 위해 단방향 패턴인 FLUX 패턴이 등장하게 되며 그 이후에도 아토믹 패턴, React-Query 등 여러 패턴이 나오게 됩니다.

<이미지 출처 : https://velog.io/@userhwseo/Atomic-Design>

<이미지 출처 : https://velog.io/@userhwseo/Atomic-Design>

아키텍처에 관한 책을 읽고 자료를 찾아보면서 프론트엔드의 역사와 현재 그리고 미래를 알게 되어 좋은 시간이 되었습니다.​

감사합니다.

​

​​

참고사이트

https://blogs.perficient.com/2021/12/03/understanding-react-context-and-property-prop-drilling/

https://generic-ui.com/blog/angular-container-presenter

https://cocoon1787.tistory.com/733

https://velog.io/@userhwseo/Atomic-Design

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