SPA? CSR? SSR?

알아보자!

SPA, MPA, CSR, SSR, SSG!

 

(사실은 Next.js 학습에 대한 강한 동기부여를 위한 포스팅...)

 

0. 용어 정리

 

SPA : 단일 페이지 어플리케이션, 사용자가 웹 애플리케이션을 이용할 때 페이지를 새로 로드하지 않고, 한 번 로드된 페이지 내에서 동적으로 콘텐츠를 업데이트하는 방식, 한번 로드된 웹 페이지 내에서 사용자 상호작용에 따라 동적으로 콘텐츠를 변경하는 방식

MPA : 전통적인 웹 애플리케이션 구조, 사용자가 페이지를 요청할 때마다 서버에서 새로운 HTML 페이지를 전송받는 방식

CSR : 브라우저에서 렌더링을 처리하는 방식

SSR : 서버에서 렌더링을 처리하는 방식

SSG : 빌드 시 HTML을 생성하여 제공하는 방식

 

+ SPA & CSR

SPA는 애플리케이션의 구조적 특성을 의미하고, CSR은 렌더링 방식에 관련된 기술적 특성을 의미한다.

CSR은 SPA를 구현하기 위해 사용되는 핵심 기술로 이해하면 된다.

 

+ SSR & SSG

SSR과 SSG는 모두 서버에서 페이지를 생성한다.

다만 SSR은 요청 시 페이지를 서버에서 렌더링 하는 방식이고,

SSG는 빌드 시 미리 페이지를 생성하여 서버에 저장했다가 요청 시 바로 제공하는 방식이다.

 

1. MPA의 한계

 

전통적인 웹 브라우저는 서버 호출마다 새로운 HTML을 응답받는 형태였다.

즉, 여러개의 페이지로 이루어진 웹앱(MPA)의 형태를 가지고 있었다.

 

이 방식은 간단한 형태의 머나먼 과거에는 적합한 형태였으나,

시간이 지나 지금 같은 시기에는 적절하지 않게 되었다.

 

점점 방대한 데이터를 가지게 된 페이지를 각각의 페이지로 가지고 있기에는 서버의 부하가 심하고,

매번 완전히 새롭게 페이지를 응답 받아야 하는 방식이 클라이언트 입장에서도 여간 부담스러운게 아니었기 때문이다.

사용자 입장에서도 새롭게 페이지를 받아 올 때마다 깜빡거림을 경험해야 했다.

게다가 브라우저보다 성능이 안 좋은 모바일 기기에게 MAP방식은 큰 부담이었다.

 

모쪼록 MPA 방식은 웹의 성장과 함께 한계에 부딪히게 되었다.

 

2. SPA의 등장

 

해결 방법은 간단했다. 하나의 페이지로 웹을 보여주는 것이다.

그렇게 탄생한 것이 SPA이다.

 

SPA는 다음과 같이 작동한다.

처음에만 단일 HTML 페이지를 로드하고,

이후 부터는 (사용자가 앱과 상호작용 할때마다) 페이지를 동적으로 업데이트하는 것이다. (페이지 새로고침X)

업데이트는 AJAX나 HTML5를 통해서 수행한다. (마크업을 받아오는 것이 아닌, JSON과 같은 데이터를 받는다.)

 

덕분에 웹은

자연스럽게 페이지를 전환할 수 있고,

그덕에 좋은 사용자 경험을 제공할 수 있게 되었다.

(성능개선, UX개선 두 토끼 캣치!)

 

3. SPA의 한계

 

장점만 가득해 보인 SPA도 한계와 마주하게 된다.

 

SPA의 작동 원리를 더 구체적으로 살펴보면 단점을 알게된다.

완성된 HTML을 서버로 부터 받아오기에 바로 사용자가 웹을 볼 수 있는 MPA와는 달리,

SPA는

a. 우선 모든 정적 리소스를 받아오고

b. 이후 JS엔진이 가동되고

c. 이후 JS엔진가 JS코드를 읽으며 HTML을 만들기 시작하고

d. HTML이 다 만들어진 후에야 사용자가 웹을 보는 형태이다.

 

이 많은 과정에서 당연히 SPA는 어쩔 수 없게도

느린 초기 페이지 로딩을 특징으로 가지게 된다.

 

게다가 검색 엔진 크롤러가

a. 초기 HTML의 초기화로 켄텐츠를 잘 읽지 못하고,

b. JS엔진으로 렌더링 된 컨텐츠를 잘 읽지 못하고,

c. URL변화를 잘 처리하지 않으면 페이지 별로 색인화도 못할 수 있다.

 

물론 구글 검색 엔진은 JS를 해석할 수 있어서 덜하지만,

네이버와 같은 국내 검색엔진은 JS를 해석하지 못해 SEO 최적화에 있어 SPA는 불리하다.

나의 웹이 네이버와 같은 플랫폼에서 잘 노출되지 않는다는 것이다.

애쓰게 만든 나의 웹이!! 이건 중대한 결함이다! (물론 노출을 원하는 경우에서 안될 때!)

 

SEO : 웹사이트나 웹페이지가 검색 엔진에서 더 잘 노출되도록 최적화하는 과정

 

 

4. SSR의 등장

 

그러면 다시 옛날처럼 빠른 초기 페이지 로딩과 SEO를 위해서,

서버에서 렌더링해서 응답해주자!

 

그래서 탄생한 것이 SSR이다.

 

SSR은 다음과 같이 작동한다.

사용자가 웹 접속하면 서버가 최소한의 JS코드를 담은 HTML을 브라우저에 전달한다.

(덕분에 바로 사용자는 화면 볼 수 있다. pre-rendering)

(이 상태에서는 모든 동적 요소 담긴 JS가 전달된 것은 아니기 때문에 사용자가 아직 화면과 인터랙션은 불가능하다.)

이후에 전달 받은 JS을 다운로드 및 실행하여 hydration을 진행한다. 이때부터는 인터랙션이 가능하다.

 

이를 통해 첫화면을 CSR과 비교하여 빠르게 사용자에게 보여줄 수 있고,

첫화면을 어느정도 서버에서 가지고 오는 만큼 SEO 최적화에도 큰 장점을 가진다.

 

 

5. SSR의 한계

 

각각의 렌더링 방식은 장단점이 명확하다.

극단적인 상황에서는 각각의 방식 중에 적절한 방식을 채택하여 개발하면 된다.

 

개인정보가 많아 SEO 최적화가 필요없고, 너무 잦은 업데이트가 이루어지는 경우 CSR

SEO가 중요하고, 누구에게나 동일한 내용이 보여지는 경우 SSR이나 SSG

가 채택될 것이다.

 

하지만

SSR의 한계는 다시금 MPA의 한계와 일치하게 된다.

그렇게 CSR을 선택한다면 결국 꼬리에 꼬리를 무는 것이다.

 

개발자들은 결국 둘을 함께 사용하는 방식을 도입하였다.

초기 페이지를 받아올 때는 SSR을

초기 페이지를 받아온 이후에는 CSR의 방식으로 렌더링한다.

 

이런 방식을 하이브리드렌더링 방식이라고 한다.

사용자에 따라 페이지 내용이 다르고, 빠른 인터랙션이 요구되며, 복잡한 동적 콘텐츠가 포함되어 있고,

검색엔진 최적화 역시 포기할 수 없는 경우에 적합하다.

(요즘 웹 다 이렇지 않나....?)

 

6. React와 Next.js

 

React는 CSR 방식을 채택한다.

Next.js는 SSR, 하이브리드렌더링 방식을 채택한다.

 

...그렇다... Next.js 배워야 한다...

 

 

 

참고❤️

https://velog.io/@dikum98/CSR-SSR-SSG%EC%97%90-%EB%8C%80%ED%95%B4

CSR & SSR & SSG에 대해