프론트엔드 프레임워크 비교(React, Vue, Angular), SPA란?

 

 

목차

• 프론트엔드 트렌드 변천사
• SSR, CSR, SSG
• 프론트엔드 프레임워크 비교

 

 

 

 

🎠 프론트엔드 트렌드 변천사

웹 프론트엔드 트렌드 변천사

전통적인 웹 동작 방식은 웹 서버가 HTML 전체 페이지를 브라우저에게 전송하는 구조로 동작했다. 과거 웹 사이트는 지금에 비해 문서 하나에 전달되는 파일 용량이 매우 적었다. User Interaction이 거의 없는 단순한 HTML, CSS 자체의 정적인 페이지를 개발하는데 그쳤다. 그래서 어떤 요소를 한 번 클릭하면 완전히 새로운 페이지를 서버에서 전송해주곤 했다. 

 

이후 동적인 웹 서비스가 등장하면서 웹 서버가 HTML 페이지와 더불어 Javascript를 통해 필요한 데이터만을 주고받으며, User Interaction을 구현하게 되었다. 

Javascript를 이용해 비동기로 화면을 동적으로 구성하는 Ajax의 탄생으로 서버에서 HTML을 만들지 않고 데이터만 교환이 가능하게 되었다. 그래서 JS를 이용해 데이터로 DOM 조작하는 작업이 중요해졌고 이로 인해 Ajax와 DOM을 쉽게 다룰 수 있는 jQuery가 각광받게 되었다. 

 

웹 산업이 발전하면서 백엔드와 프론트엔드의 영역을 분리하여 각자 전문성을 고도화시키는 것에 초점을 맞추게 되었다. 

백엔드는 거대 데이터를 처리하기 위한 도구와 자동 배포와 스케일링 등의 새로운 도전과제를 맞이하게 되었고,

프론트엔드는 화면을 동적으로 다루는 역할이 중요해지면서 Javascript를 이용한 클라이언트 개발 분야가 급속도로 성장하게 되었다.  (백엔드 - Data 중점, 프론트엔드 - UI/UX 중점)

그러다 보니 HTML과 JS를 함께 다루는 편이 더 나았고, 앱을 만들던 MVC 아키텍처를 표방하면서 데이터를 조작하고 DOM을 조작하는 로직을 하나로 관리하려는 움직임이 생겼다. 그렇게 자연스럽게 화면 단위가 아닌 컴포넌트 단위로 발전하게 된 것이다. 

매번 데이터 변경 시 템플릿 방식으로 HTML을 작성하는 방안이 연구되었고, 자동화하는 과정에서 Angular, React, Vue 등의 프레임워크가 만들어지게 되었다. 

 

이렇게 과거와 달리 최근 웹 프론트엔드 개발에서 주축이 되는 자바스크립트 진영에서도 라이브러리와 프레임워크를 이용한 개발이 필수로 여겨지고 있다. 

 

Javascript가 주축이 되면서 SPA 개념이 등장하게 되었다. 

 

 

⭐ SPA(Single Page Application)란? 

하나의 페이지로 구성된 웹 어플리케이션으로, 브라우저에 최초에 한 번만 페이지 전체를 로드하고, 이후부터는 특정 부분만 Ajax를 통해 데이터를 바인딩하는 방식이다. 

SPA는 웹 앱에 필요한 모든 정적 리소스를 처음에 한번 다운로드한다. 페이지 간 이동이나 페이지 갱신에 필요한 데이터만 갱신하기 때문에 전체적인 트래픽을 감소할 수 있고, 전체 페이지를 다시 렌더링 하지 않고 변경되는 부분만 갱신하여 새로고침이 발생하지 않는다. 

즉, 서버가 하던 대부분의 작업을 브라우저에서 처리하며, HTML 생성, navigation 처리, 인증에 따른 분기, 검색 등을 모두 Javscript로 처리할 수 있다. 따라서 속도, 사용성, 반응성의 향상으로 더 나은 사용자 경험을 기대할 수 있다.  

그러나, SPA가 모든 환경에 적합한 것은 아니다. 필요한 모든 정적 리소스를 최초에 한번 다운로드하기 때문에 초기 구동 속도가 느린 편이다. 또한, SEO(검색 엔진 최적화) 문제가 존재한다. 서버 사이드 렌더링 방식이 아닌 자바스크립트 기반 클라이언트 렌더링 방식이기 때문에, 처음 받은 웹페이지의 소스코드가 거의 비어있어 검색이 잘 안 될 수 있다. 

SPA는 웹보다는 앱에 적합한 기술이고, React와 같은 프레임워크는 SSR을 지원하는 기술이 존재한다. 

 

MPA(Multi Page Application)란?

여러 페이지로 구성된 웹 어플리케이션으로 사용자 클릭과 같은 인터렉션 발생 시마다 서버로부터 새로운 페이지를 받아와 페이지 전체를 새로 렌더링 하는 전통적인 웹 방식이다.

새로운 페이지 요청 시마다 정적 리소스가 다운되고 전체 페이지를 다시 렌더링 하므로 새로고침이 발생된다. 페이지에서 필요 없는 부분을 포함하여 전체를 갱신하기 때문에 비효율적이다.

하지만, 가장 큰 장점은 SPA와 달리 SEO에 친화적이라는 점이다. 검색 사이트에 노출되는 것이 중요한 웹사이트라면 MPA 구조로 개발하는 것이 좋다. 또한 서버에서 이미 렌더링 한 결과를 가져오기 때문에 SPA와 달리 첫 로딩이 짧은 편이다. 

 

 

🔍 SPA vs MPA 정리

기준	SPA	MPA
페이지 수	한 개	여러 개
초기 구동 속도	느림	빠름
트래픽 용량	작음	큼
SEO 최적화	약함	강함
사용자 경험	자연스러움	새로고침으로 깜빡거림
새로운 페이지 요청	필요한 부분만 리렌더링	전체 페이지 리렌더링
렌더링 방식	클라이언트 사이드 렌더링(CSR)	서버 사이드 렌더링 (SSR)

 

 

 

 

SSR, CSR, SSG

SSR (Server Side Rendering)이란?

서버 사이드 렌더링이란, 서버로부터 완전하게 만들어진 HTML 파일을 받아와 페이지 전체를 렌더링 하는 방식이다.  MPA는 SSR 방식을 채택한다. 모든 데이터가 맵핑된 페이지를 브라우저에 전달하기 때문에 화면을 구성하는 각각의 페이지가 있어 SEO구성이 쉽다. (* SEO - 검색엔진이 웹을 크롤링하면서 페이지에 컨텐츠 색인을 생성하는 과정)

서버로부터 화면을 렌더링 하기 위한 필수적인 요소를 먼저 가져오기 때문에 CSR보다 초기 로딩 속도가 빠르다. MPA 특징처럼 매번 페이지 요청 시 새로고침 되어 사용자 경험이 다소 떨어지며, 페이지 요청 시마다 서버에서 페이지를 구성하는 모든 리소스를 준비해서 응답하므로 서버 측 부하가 증가한다. 

 

CSR(Client Side Rendering)이란?

클라이언트 사이드 렌더링이란, 사용자 요청에 따라 필요한 부분만 응답받아 렌더링 하는 방식이다. SPA가 CSR 방식을 채택한다. 

클라이언트 사이드 렌더링 방식은 변경된 부분 관련 데이터만 가져오므로 SSR에 비해 빠른 속도와 서버 부하를 감소시킬 수 있다. 

새로고침 발생하지 않기 때문에 사용자 친화적이다. 

하지만 SPA 방식으로, 자바스크립트를 사용하여 사용자와 상호 작용 후 페이지에 내용을 로드하기 때문에 웹 크롤러가 페이지를 색인화하려 하면 내용의 빈 페이지처럼 보이게 되어 SEO에 불리하다. 

 

SSG (Static Site Generation)이란?

SSG는 Next.js에서 사용되는 개념이다. (React: CSR, Next.js: SSR, SSG)

Next.js는 브라우저에 렌더링 할 때 기본적으로 pre-rendering(사전 렌더링)을 한다. 

사전 렌더링은 서버단에서 DOM 요소들을 Build 하여 HTML 문서를 렌더링하는 것을 말한다. 

서버에서 pre-rendering 하는 것까지가 Next.js의 특징이고, pre-rendering을 동적으로 해서 페이지를 생성하느냐, 정적으로 페이지를 생성하느냐의 차이가 SSR과 SSG의 차이다. 

SSG: HTML을 빌드 타임에 각 페이지별로 생성하고 해당 페이지로 요청이 올 경우 이미 생성된 HTML 문서를 반환한다. 
SSR: 요청이 올 때 마다 해당하는 HTML 문서를 그때 그때 생성하여 반환한다. 

SSG의 경우 빌드 시 정적 사이트를 미리 만들어두기에 사용자에 따라 변화하지 않는 개인 블로그나 문서와 같은 서비스에 적합하다고 볼 수 있다. 이때, 빌드 시 미리 만들어 놓는다는 점을 통해 유추할 수 있겠지만 초기 페이지는 빌드할 때 기준으로 컨텐츠가 추가/변경된다면 다시 빌드해야 한다.

많은 컨텐츠가 미리 렌더링 되고 정적인 컨텐츠라는 특징 덕분에 페이지 로드 시간이 빠르며, SEO에 이점이 있다.

 

 

 

 

 

프론트엔드 프레임워크 비교

웹 프론트엔드 영역에서 주요 라이브러리와 프레임워크로 자리 잡은 React, Vue.js, Angular에 대해 비교해보고자 한다.

 

Angular

프레임워크로서 대부분의 기능을 지원하지만, 타입스크립트를 학습해야 하며, 뷰에 비해 더 많은 기능을 제공하고 있어 러닝커브가 높은 편이다. 

 

React

프레임워크가 아닌 라이브러리이다. 리액트는 전적으로 UI를 렌더링하는데만 관여하기 때문이다. 

SPA Framework가 아닌 View 렌더링에만 집중하고 Angular와 달리 개발에 필요한 나머지 router, ajax 등은 서드파티 라이브러리에 의존하여 사용해야 한다. 따라서 단독으로 사용하기보다 state 관리 모듈(Redux..)와 같이 쓰여 그 부분에 대한 이해도가 필요하다. 

React는 XML 포맷의 템플릿을 직접 자바스크립트에 내장시키는 형태로 JSX 기술을 주력으로 사용하는 것을 권장한다. 다른 프레임워크에 비해 더 자바스크립트에 집중된 형태의 컴포넌트가 나타나게 된다. 

또한 가상 DOM을 이용하여 실제 DOM을 조작하는 방식에 비해 렌더링 성능이 뛰어나다. 

 

Vue

프레임워크로서 대부분의 기능을 지원하고, 라이브러리가 아니므로 부분적으로 사용이 불가능하다.

또한 정해진 문법과 틀이 있어, 문법만 익히면 사용하기 쉬워 빠른 개발에 용이하다. 

React와 동일하게 가상 DOM을 사용하고, 컴포넌트 기반 개발을 중심으로 한다. 하지만 React와 구별되는 특징으로, 컴포넌트의 자바스크립트 집중도가 낮다는 점이다. JSX를 사용하는 React와 달리, 컴포넌트와 구성요소를 작성할 때 Angular처럼 HTML 마크업 기반 템플릿 문법을 사용한다. 

HTML 마크업 기반 템플릿 부분과 자바스크립트 부분, CSS를 작성하는 스타일 시트 부분을 나눔으로써, React에 비해 기존 HTML, CSS에 익숙한 웹 퍼블리셔가 Vue.js를 접했을 때 컴포넌트 구성요소 및 구조를 쉽게 이해할 수 있어, React에 비해 디자이너와의 협업이 더 쉬워질 수 있다. 

 

 

🌟 프레임워크와 라이브러리 차이
프레임워크 
: 앱을 만들기 위해 필요한 대부분의 것을 갖고 있는 것으로, 프레임워크는 앱을 만드는데 필요한 대부분의 라이브러리를 포함하고 있다. 
라이브러리 
: 특정 기능을 모듈화 해 놓은 것

 

 

🤔 그렇다면 언제, 어떤 프레임워크를 선택해야 할까? 

Angular

• 기능이 풍부하고 규모가 큰 애플리케이션 개발할 때
• 믿을 수 있고 확장 가능한 프레임워크가 필요할 때
• 타입스크립트로 코딩해야 할 때
• 장기 프로젝트이며, 투자규모가 상당한 네이티브 앱이나 하이브리드 앱, 또는 웹앱을 개발할 때

React

• 기존의 앱에서 기능성을 확장할 때
• 프로젝트의 규모가 크고 더 확장될 가능성이 있을 때
• javascript 문법에 능숙하며 typescript를 사용하는 경우
• Component를 작은 단위로 나누어 비슷한 UI 재사용을 많이 할 때
• 커스터마이징 및 자유도 높은 환경을 선호할 때
• 크로스 플랫폼 앱 개발이 필요할 때

Vue

• 규모가 작고 가벼운 프로젝트를 빠르게 만들 때
• 퍼블리셔, 마크업 개발자가 따로 존재할 때
• 기존 HTML, CSS, JS 구조로 작성된 코드를 SPA로 옮기고 싶을 때
• 개발자 간 코드 통일성을 위한 커뮤니케이션 비용을 줄이고 싶을 때
• 백엔드 개발도 함께하고 있을 때 

 

 

 

 

 

 

 

 

 

참고

https://yozm.wishket.com/magazine/detail/1289/