React VS NextJS (SSG,CSR/SPA,MPA)

서이·2023년 9월 3일

개념정리

목록 보기

3/9

SPA vs MPA

SPA(Single Page Application)는 한 개(Single)의 Page로 구성된 Application이다.

MPA는 새로운 페이지를 요청할 때마다 정적 리소스가 다운로드된다. 매번 전체 페이지가 다시 렌더링 된다.

MPA(Multiple Page Application)는 여러 개(Single)의 Page로 구성된 Application이다.

SPA는 웹 에플리케이션에 필요한 모든 정적 리소스를 최초 한 번에 다운로드한다.
그 이후 새로운 페이지 요청이 있을 때, 페이지 갱신에 필요한 데이터만 전달 받아서 페이지를 갱신한다.

👉 SPA를 CSR(Client Side Rendering) 방식으로 렌더링한다고 말한다.
👉 MPA를 SSR(Server Side Rendering) 방식으로 렌더링한다고 말한다.

CSR

CSR은 Client Side Rendering의 약자이며, CSR은 body가 비어있는 HTML을 최초 다운받는다. 이후 화면에 그려주기 위해 필요한 JS 파일을 내려받는 과정이 필요하다. JS 파일까지 내려받으면 실행한 후 화면에 그려줄 HTML을 만들어주는 과정을 거친다.페이지가 변경되더라도 최초의 JS를 다운받아 렌더링할 때 모든 페이지를 다 가지고 있으므로 서버에게 요청하지 않는다.(대표적으로 React, Vue, Angular, Svelte가 있다)

SSR

SSR은 Server Side Rendering의 약자이며, 웹 브라우저가 서버에서 렌더일을 진행하고 연산, 분석이 완료된 HTML 파일을 화면에 뿌려주는 것을 의미합니다.

👍 MPA 장점

SEO 관점에서 유리하다.
MPA는 완성된 형태의 HTML 파일을 서버로부터 전달받는다.
따라서 검색엔진이 페이지를 크롤링하기에 적합하다.
첫 로딩 매우 짧다.(요청하는 화면의 내용을 그 때 그 때 다운 받기 때문에 초기 로딩 속도가 상대적으로 빠름)
서버에서 이미 렌더링해 가져오기 때문이다.
그러나 클라이언트가 JS 파일을 모두 다운로드하고 적용하기전 까지는 각각의 기능은 동작하지않는다.

👎 MPA 단점

새로운 페이지를 이동하면 ‘깜빡’인다. (UX)
매 페이지 요청마다 리로딩(새로고침) 발생.
새로운 페이지를 요청할 때마다 전체 페이지를 다시 렌더링하기 때문이다.
페이지 이동시 불필요한 템플릿도 중복해서 로딩 (성능)
서버 렌더링에 따른 부하
모바일 앱 개발시 추가적인 백엔드 작업 필요 (생산성)개발이 복잡해질 수 있다.
SSR은 만들어진 html을 먼저 받아오지만, interactive하게 만드는 JS를 나중에 갖고 오기 때문에, TTV(Time To View)와 TTI(Time To Interact)의 시간차가 CSR보다 길다.

그런데 CSR 방식으로 만든 SPA 앱은 검색엔진최적화(SEO)가 어렵다.
일반적인 SPA 앱을 검색로봇 입장에서 보면 모든 페이지의 소스가 아래와 같이 보인다. 해당 페이지 접속 후 페이지 소스보기 시 HTML이 비어있는 모습을 확인할 수 있다.

👍 SPA 장점

자연스러운 사용자 경험 (UX)
전체 페이지를 업데이트 할 필요가 없기 때문에 빠른 페이지 전환과 ‘깜빡’ 거림이 없다.
필요한 리소스만 부분적으로 로딩, 서버 요청 횟수가 적어 서버에 부담이 적다.(성능)
SPA의 Application은 서버에게 정적리소스를 한 번만 요청한다.그리고 받은 데이터는 전부 저장해놓는다. (캐시=Cache)
서버의 템플릿 연산을 클라이언트로 분산 (성능)
컴포넌트별 개발 용이 (생산성)
모바일 앱 개발을 염두에 둔다면 동일한 API를 사용하도록 설계 가능 (생산성)

👎 SPA 단점

JavaScript 파일을 번들링해서 한 번에 받기 때문에 초기 구동 속도가 느리다. (Webpack의 code splitting으로 해결 가능)
처음에는 HTML이 비어 있어 검색엔진최적화(SEO)가 어려움,크롤러 봇들은 JS파일을 실행시키지 못하기 때문에 HTML에서만 콘텐츠들을 수집하게 되고 CSR페이지를 빈페이지로 인식하게 된다. (SSR로 해결 가능)
보안 이슈 (프론트엔드에 비즈니스 로직 최소화)
SSR에서는 사용자에 대한 정보를 서버측에서 세션으로 관리를 하지만 CSR 방식에서는 클라이언트측의 쿠키말고는 사용자에 대한 정보를 저장할 공간이 마땅치 않다, 쿠키나 localstorage에서 사용자에 대한 정보를 저장해야 하기 때문에 XSS 공격에 취약하다. React 환경에서는 CSR의 단점을 극복하기 위해 ReactSSR 라이브러리인 Next.js를 사용한다고 함.

⚠️ 주의점

CRS != SPA
전통적인 웹페이지 렌더링 방식 != SSR

SSR vs CSR

SSR과 CSR 두 가지 렌더링 방식에 대해 살펴보았는데 다시한번 정리하자면 이렇다.

차이점으로 초기렌더링속도, SEO, 보안이 있다.

SPA를 SSR 방식으로 렌더링 할 수도 있다?!

Nuxt.js 란?

React 애플리케이션을 위한 Next.js 프레임워크가 있다면, Vue를 위해 SSR을 지원하는 프레임워크가 Nuxt.js이다.
정의하자면 Nuxt.js는 Vue를 기반으로 하여 SSR 기반의 Web Application을 컴포넌트 단위로 개발 할 수 있게 해주는 프레임워크이다.
Angular, React, Vue SPA 삼대장들이 출시되고 나서 SPA의 단점을 극복하고자 많은 노력들이 있었지만, 정통 SSR(MPA) 방식의 장점을 완벽하게 커버하기란 불가능 하였다. 그래서 SSR(MPA) 방식에서 SPA의 장점 중 일부라도 누려보기 위해서 나온 프레임워크가 Next.js(React 기반), Nuxt.js(Vue 기반)들이 아닐까 추측된다.

Next.JS의 작동원리는 다음과 같다.

초기에 사용자가 Server에 페이지 접속을 요청하면, SSR방식으로 렌더링 될 HTML을 보냄.
브라우저에서 JavaScript를 다운로드하고 React를 실행함.
사용자, 페이지가 서로 상호작용하여 다른 페이지로 이동할 땐, Server가 아닌 CSR방식으로 브라우저에서 처리함.

React VS NextJS

create-react-app로 만든 React.js 앱은 CSR(Client-Side-Rendering)이고,
creat-next-app로 만든 Next.js 앱은 SSR(Server-Side-Rendering)이다.

1) React 동작 방식 (CSR)
유저와 서버, 브라우저 각각의 입장을 나눠서 생각하면 이해하기가 쉽다. (브라우저는 유저와 앱의 연결통로)

유저가 브라우저를 통해 앱에 접속하면,
앱은 브라우저에게 javascript 정보가 들어있는 빈 html 문서을 전달한다. 즉, 브라우저에게 javascript파일을 전달하는 것으로 볼 수 있다.
브라우저는 javascript파일을 다운로드하고 동시에 유저는 빈 화면을 보게 된다(접속에 대한 응답).
브라우저에서 js 파일의 다운로드가 끝나면, 리액트 코드가 있는 js파일을 실행한다.
브라우저에 있는 리액트 코드가 UI를 렌더링한다. (동적으로 렌더링)
유저는 드디어 앱이 보여주고자 했던 화면을 보게 된다.
즉, 브라우저가 javascript 코드를 가지고 있지 않거나, 요청 중인 상태라면 UI를 구성할 수 없고, 유저는 빈 화면을 보게 된다. 리액트 코드가 실행되기 전까지는 유저 화면에 아무것도 보이지 않는 것이다. 이렇게 클라이언트 측에서 UI를 빌드하는 것을 CSR 방식이라 한다.

2) Next 동작 방식 (SSR)
Next.js란 무엇인가?

Next.js는 리액트를 위해 만든 오픈소스 자바스크립트 웹 프레임워크로, 리액트에는 없는 서버 사이드 렌더링server-side rendering(SSR), 정적 사이트 생성static site generation(SSG), 증분 정적 재생성incremental static regeneration(ISR)과 같은 다양하고 풍부한 기능을 제공.

유저와 서버, 브라우저 각각의 입장을 나눠서 생각하면 이해하기가 쉽다. (브라우저는 유저와 앱의 연결통로)

유저가 브라우저를 통해 앱에 접속하면,
서버에서 리액트를 실행한다.
리액트는 UI를 렌더링한다.
렌더링된 결과를 통해 브라우저에게 HTML을 제공한다. 이때 유저는 앱의 초기화면을 보게 된다(접속에 대한 응답).
이후 브라우저는 리액트 코드가 있는 Javascript 파일을 다운받고 실행시킨다. 이때부터 일반적인 리액트 앱과 같이 CSR의 동작(동적 렌더링)을 하게 되고 이 과정을 hydration이라고 한다.
즉, 서버에서 UI를 모두 구성한 후 유저에게 응답해 화면을 보여주는 방식으로, 화면이 pre-rendering되어 유저는 인터넷 속도에 상관없이 화면에 뭔가 나오는 것을 볼 수 있다. 이렇게 서버 측에서 UI를 렌더링하는 것을 SSR 방식이라 한다.

cf) hydration - 리액트 코드가 브라우저에 이미 존재하는 HTML과 동기화하여 앱이 동적으로 상호작용할 수 있도록하는 과정

라우팅?

사용자가 요청한 URL에 따라 알맞은 페이지를 보여주는 것
여러 페이지로 구성된 웹 애플리케이션을 만들 때 페이지 별로 컴포넌트들을 분리해가면서 프로젝트를 관리하기 위해 필요한 것

리액트에서 라우트 시스템을 구축하기 위해 사용할 수 있는 2가지 선택지

리액트 라우터(React Router): 가장 많이 사용되는 리액트의 라우팅 관련 라이브러리입니다. 컴포넌트 기반으로 라우팅 시스템을 설정할 수 있습니다.

Next.js: 리액트 프로젝트의 프레임워크이며 파일 경로 기반으로 작동합니다. 다양한 기능(리액트 프로젝트 설정을 하는 기능, 라우팅 시스템, 최적화, 다국어 시스템 지원, 서버사이드 렌더링 등)을 제공합니다.

Library vs Framework

React.js는 라이브러리이고, Next.js는 React.js의 프레임워크이다.
이 둘의 궁극적인 차이점은 "응용 프로그램의 흐름 주도권을 누가 가지고 있느냐"이다.

1) Framework
코드를 작성하는 기본적인 틀을 제공해서 보다 효율적으로 어플리케이션을 만들 수 있도록 하는 소프트웨어 환경

2) Library
어플리케이션을 만들 때 필요한 자원(기능: 함수)의 모임

즉, React에서는 우리가 모든 것을 직접 생성하고 설정해 주었던 것들이 Next에서는 이미 만들어져 있다.

React: CSR(Client-Side-Rendering)

Next.js: SSR(Sever-Side-Rendering), SSG(Static-Site-Generation)

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

사전 렌더링이란? Server단에서 DOM 요소들을 Build하여 HTML 문서를 렌더링하는 것을 말합니다.

위 사진처럼 HTML을 미리 렌더링하고, 그 뒤에 요청이 오면 Chunk 단위로 javascript를 보내주어 이벤트가 작동하게 되는 것이 Hydration이며, Next.js에서 사용되는 방법입니다.
https://narup.tistory.com/230
이러한 빌드 과정, 웹 페이지 요청 과정이 SSR인 것은 아니다!

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

SSG(Static Site Generator)

정적 사이트 생성기는 누가 접속하든 항상 동일한 내용을 보여주는 웹사이트롤 만들 때 적합한 방식이다. 즉 미리 서버에 화면을 저장해두었다가 꺼내쓰는 방식이다. 그래서 컨텐츠 변경이 잦지 않은 소규모 웹사이트를 제작할 때 유용하며 사이트도구는 Gastsby, Hugo등을 주로 사용한다.
만들어 놓은 웹페이지를 그대로 보여주기 때문에 빠르다는 장점이 있다. 컨텐츠를 자주 업데이트하는 사이트에는 빌드시간이 길어져 비효율적이다.

SSR은 요청 시 서버에서 즉시 HTML을 만들어 응답하기에 데이터가 달라지거나 자주 바뀌어서 미리 만들어 두기 어려운 페이지에 적합하고, SSG는 페이지들을 서버에 모두 만들어 둔 후에 요청 시 해당 페이지를 응답하는 것이므로 바뀔 일이 거의 없어 캐싱해두면 좋을 페이지에 사용하면 적합하다.