SSR/CSR, SPA/MPA, PWA 정리

SSR (Server Side Rendering)

SSR 방식은 서버에서 렌더링을 마치고,
완전하게 만들어진 HTML 파일을 브라우저로 전달한 후 렌더링 하는 방식이다.

장점

• 이미 DOM이 다 구성된 파일을 브라우저가 받아서
  초기 로딩 속도가 빠르기 때문에 사용자가 빨리 컨텐츠를 볼수 있다.

• 이미 DOM에 내용이 다 차있기 때문에 SEO(검색엔진 최적화)에 좋다.

단점

• 매번 페이지를 요청할 때마다 새로고침 되기 때문에 UX가 다소 떨어진다.

• 페이지를 이동할 때마다 서버에 요청을 하기 때문에 서버의 부하가 커진다.

CSR (Client Side Rendering)

전통적인 방식으로는 SPA(싱글 페이지 어플리케이션) 가 사용하는 방식이다.

최초 로딩 시 브라우저가 서버에 HTML을 비롯한 CSS, JAVASCRIPT등
각종 리소스들을 받아오는 방식이 클라이언트 사이드 렌더링 방식이다.

각종 리소스들을 받아오면 사용자의 상호 작용에 따라 Javascript를 통해 동적으로 렌더링한다.

이후 필요에 따라 데이터를 서버에 요청해서 받아오게 된다.

장점

• 초기 요청을 제외하고는 SSR에 비해 빠른 페이지 전환 속도로 더 나은 UX를 제공한다.

• 서버에 요청하는 횟수가 적기 때문에 서버 부담이 SSR에 비해 적다.

단점

• 최초 로딩 시 모든 리소스 들을 받아와야 하기 때문에 초기 로딩 속도가 느리다.
• 처음에는 HTML이 비어있어 검색엔진의 봇들의 크롤링(crawling)할때 아무 내용이 없어서 SEO(검색엔진최적화)에 취약하다.
• 쿠키나 localStorage에서 사용자에 대한 정보를 저장해야 하기 때문에 XSS공격에 취약하다.

React 환경에서는 CSR의 단점을 극복하기 위해 React SSR 라이브러리인
Next.js를 사용한다고 한다.

SSR과 CSR의 차이점

차이점으로는 크게 초기 렌더링 속도,SEO, 보안으로 볼 수 있다.
CSR 의 경우 사용자의 행동에 따라 필요한 부분만 다시 읽어 들이기 때문에 서버 측에서 렌더링 하여
전체 페이지를 다시 읽어 들이는 것보다 빠른 반응속도를 기대할 수 있다.
SSR 을 한다 하더라도 ajax 기능을 위해 클라이언트 렌더링 요소가 포함될 수 밖에 없다.
클라이언트 측에서 렌더링을 하게 되면 SSR이 따로 필요하지 않기 때문에
일관성 있는 코드를 작성할 수 있다.
CSR은 페이지를 읽는 시간, 자바스크립트를 읽는 시간, 자바스크립트가 화면을 그리는 시간까지 모두 마쳐야 콘텐츠가 사용자에게 보여지는 반면 SSR의 경우 서버에서 view를 렌더링하여 가져오기 때문에 view를 보기까지 초기 구동속도가 빠르다,

하지만

CSR은 SEO에 취약한 것은 사실이나 그전에 내 서비스 전체가 SEO가 필요한가를 고민해 봐야한다.
공개되야 하는 퍼블릭 데이터만 SEO가 필요할 뿐이지 모든데이터가 SEO가 필요하지는 않다.

비용문제

CSR로 구성 할 경우 S3같은 단순 스토리지에 올리고 전면에 Cloud Front로 구성하여 캐싱과 레이턴시를 줄이고
트래픽 비용만 지불하게 된다.
SSR의 경우 매번 서버에서 로직을 실행하는 비용을 추가하게 된다.
그리고 동적 컨텐츠가 많은 경우 캐싱도 무효화 된다. 인스턴스를 Auto Scale 하거나 Serverless 기반의 Function을 사용하더라도 CSR과 비교해서 비용이 수백~수천배까지 차이가 날 수 있다.
CSR과 SSR을 선택하는 기분은 내 프로젝트나 서비스 구성에 맞는 방법을 사용해야 한다.
고객의 데이터를 보호해야 하는 경우나 비용이 민감할 경우 CSR을 택할 수 있고,
정적 콘텐츠와 퍼블릭 데이터가 많은 경우에는 SSR을 선택하는 것이 좋다.
필요에 따라 두가지를 섞어서 서비스를 구성해야 할 수도 있다.

SPA (Single Page Application)

글자 그대로 하나의 페이지로 구성된앱이다.

기술적으로는 SPA는 어떤 페이지를 접속하더라도 HTML,CSS,JS 동일한 파일 하나만 접속한
페이지에 맞게 화면을 구성한다.

최근 들어 JS프레임워크들은 SPA를 기본으로 하고 있다.

SPA의 트릭은 하나의 페이지에서 JS를 통하여 보고있는 DOM의 내용을 모두 제거하고 다른 컨텐츠로 DOM을 채운 다음에 브라우저상에 URL을 강제로 변경하여, 실제로 방문한적도 없는 URL을 방문하여 해당 페이지를 보고 있는 느낌을 주는것이다.

MPA (Multi Page Application)

여러개의 페이지로 구성된 웹이다.

페이지를 별로 해당 페이지에 맞는 HTML,CSS,JS를 가지고 화면을 구성하는 고전적인 방식이다.

MPA는 일반적으로 하이퍼 링크를 클릭했을 떄 해당 페이지로 가고 화면이 깜빡이면서 새로운 페이지가 로드되고

그때 해당 페이지에 맞는 HTML,CSS,JS를 받아 화면을 그리는 방식이다.

SPA,MPA 언제 무엇을 선택해야 할까?

둘중 무엇을 먼저 선택하기 보다는 사용하는 프레임워크나 아키텍처에 따라서 SPA,MAP가 정해진다는 표현이 맞을것 같고, 개념상으로 이것이 어떻게 다른지를 이해하는게 더 중요한거 같다.

일반적으로 CSR=SPA, SSR=MAP 라고 공식처럼 얘기가 되는데 React,Vue,Anguler같은 JS기반 프레임 워크를 쓰면 기본적으로 HTML,CSS,JS파일이 각 하나씩 나오기 때문에 자연스레 SPA가 되면서 CSR이 되는 것이고 이를 SSR로 구현하면 페이지 별로 렌더링을 따로 하기 때문에 MPA가 되는 것이다.

MPA이면서 같은 JS 파일을 받고 클라이언트에서 렌더링을 하게 되면 MPA + CSR이 되는 것이고 SPA면서 SSR을 택하면 SSR+SPA가 되는 것인데 원리를 이해하면 이런 식으로는 궁합이 잘 맞지 않기 때문에 처음 언급한 공식처럼 사용이 되는 것이다. 되고 안되고 보다는 무엇이 무엇인지를 이해하는 것이 중요하다.

SPA,MPA의 차이를 이야기 하면 기술적인 부분을 다 떠나서 그냥 화면이 한번 깜빡인다에 중점을 둔다.

MPA는 페이지를 새로 로드하기 때문에 화면 깜빡임 현상을 막을 수가 없다.

하지만 SPA는 이미 로드한 페이지에서 DOM의 내용만 교체하기 때문에 이 깜빡임이 보이지 않는다.

이 한번의 깜빡임 이라는 아주 작은 디테일 때문에 커다란 결과를 가져 올 수 있다.

모바일의 경우 적은 트래픽과 빠른 인터렉션이 중요한데 이는 SPA와 잘 맞는다. 초기 로딩은 살짝 느릴 수 있으나 모바일 브라우져도 결국은 자체적으로 캐싱을 하기 때문에 이후에 네트워크 트래픽의 소모가 적고 이후 설명할 PWA를 활용하면 오프라인 상태에서도 인터렉션이 가능하다.

PWA(Progressive Wep App)

PWA 란 프로그래시브 웹 앱 이라고 하며 웹과 네이티브 앱의 기능을 모두 갖춘 형태이다.
간단하게는 웹처럼 URL로 접근하여 애플 스토어나 구글스토어를 거치지 않고 모바일 디바이스 홈 화면에 바로 설치하여 사용이 가능하다는 것이다. 설치하여 구동 시 상단에 URL 컨트롤을 감추어 일반적인 모바일 앱처럼 작동하게 만들 수도 있다. 굳이 설치를 하지 않더라도 모든 데이터를 기본적으로 캐싱하여 오프라인 상태에서도 데이터를 볼 수 있다.

피드백은 댓글로 부탁드립니다. 감사합니다.