렌더링 방식(CSR, SSR, SSG)

프론트엔드 개발을 공부하다보면 마주칠 수 밖에 없는 개념인 CSR과 SSR등 여러 렌더링 방식이 존재한다. 이 여러 렌더링 방식에 대해서 자세하게 알아보는 포스팅을 준비했다. 그 이전에 SPA(Single Page Application)와 MPA(Multi Page Application)에 대해서도 다뤄보자. 이 포스팅은 나 포함 많은 주니어 개발자가 가지고 있던 잘못된 지식에 대해서도 바로잡을 수 있는 시간이 될 수 있을것 같다.

 

MPA

Multi Page Application

MPA(Multi Page Application)은 전통적인 웹 애플리케이션 방식으로 페이지 당 하나의 html 파일을 갖고, 새로운 페이지 요청 시마다 정적 리소스가 다운로드 되고 전체 페이지를 다시 렌더링하는 방식이다. 간단하게 말하면 HTML 파일이 여러개 있는 애플리케이션이라고 할 수 있다. 뒤에서 설명하겠지만 MPA는 SSR 렌더링 방식과 연관이 있다.

SPA

Single Page Application

전통적인 웹 애플리케이션과 달리 SPA는 단일 페이지로 구성된 애플리케이션으로 최초에 애플리케이션에 접속시 애플리케이션에 필요한 모든 정적 리소스를 다운로드하고, 페이지 이동이 일어나는 경우 해당 페이지에 필요한 비동기적 데이터 부분만을 서버에 요청하여 동적으로 렌더링을 한다. 간단하게 말하면 HTML이 한개인 애플리케이션이라고 할 수 있다. 마찬가지로 뒤에서 설명하겠지만 일반적으로 SPA는 CSR 렌더링 방식과 연관이 있다.

 

 

위에서 SPA와 MPA의 개념에 대해서 살펴보았다. 일반적으로 SPA는 CSR 방식과 연관이 있다고 설명했고, MPA는 SSR 방식과 연관이 있다고 설명했다.

그렇다면 SPA = CSR, MPA = SSR 인 것일까? 같다 라는 관점에서 보면 "그렇지 않다"가 답이다.

SPA와 MPA의 개념은 애플리케이션을 구성하는 페이지가 몇개냐의 관점에서, CSR과 SSR의 개념은 어디에서 렌더링을 준비하냐의 관점에서 해석해야한다.

그렇다면 어디에서 렌더링이 이루어지느냐에 따라 나뉘는 CSR과 SSR에 대해서 알아보자.

 

CSR

CSR 동작 원리

CSR은 Client Side Rendering으로 클라이언트 측에서 렌더링을 준비하는 렌더링 방식이다. 위에서 어디에서 렌더링을 준비하냐의 관점에서 렌더링 방식을 나눌 수 있다고 했는데, 그림을 통해서 확인할 수 있듯이 클라이언트는 서버로부터 빈 HTML과 자바스크립트를 받고 비어있는 HTML에 자바스크립트를 통해 동적으로 렌더링을 진행한다. 이 특징을 통해서 찾아볼 수 있는 CSR의 장단점은 다음과 같다.

 

장점

🔘 서버 부하의 분산: 렌더링을 클라이언트 측에서 담당하기 때문에 서버에서 일어날 수 있는 부하를 감소시킬 수 있다.

🔘 TTV와 TTI 사이의 간극이 작음: TTV(Time To View; 사용자가 웹사이트를 보는 것)와 TTI(Time To Interact; 사용자가 웹사이트와 상호작용을 하는 것)의 간극이 작아 사용자가 화면을 볼 때 상호작용할 수 있다.

 

단점

🔘 느린 초기 화면 로딩: 클라이언트 측에서 자바스크립트를 다운로드 받고 동적으로 렌더링하는 시간을 기다려야하기 때문에 초기 화면 로딩 속도가 느리다.

🔘 불리한 SEO: 여러 브라우저의 크롤러는 HTML을 통해 검색 가능한 색인을 만드는데 CSR 방식은 빈 HTML이기 때문에 SEO에 불리하다.

 

SSR

SSR 동작 원리

SSR은 Server Side Rendering으로 서버 측에서 렌더링을 준비하는 방식이다. 위의 그림과 같이 서버로부터 완성된 HTML을 받아 즉시 렌더링이 이루어지고 클라이언트가 자바스크립트를 다운받은 후 HTML에 자바스크립트가 연결된다. 이 특징을 통해 SSR의 장단점에 대해서도 살펴보자.

 

장점

🔘 용이한 SEO: 모든 데이터가 HTML에 담겨 브라우저에 전달되기 때문에 크롤러가 검색 가능한 색인을 만들 수 있어 SEO가 용이하다.

🔘 빠른 초기 화면 로딩: 자바스크립트 코드를 다운로드 받고 실행하기전에 사용자가 렌더링된 화면을 볼 수 있다.

 

단점

🔘 TTV와 TTI 사이의 간극이 비교적 큼: 사용자가 빠르게 렌더링된 화면을 볼 수 있지만 클라이언트 측에서 자바스크립트가 다운로드가 완료되어 HTML에 연결되지 않는다면 상호작용이 불가능하다.

🔘 서버의 부하: 초기 페이지의 렌더링을 서버에서 담당하기 때문에 서버에 부하를 줄 수 있다.

 

SSG

SSG(Static Site Generation)는 서버에서 완성된 HTML을 보내준다는 측면에서 SSR과 비슷하지만, 서버에서 요청시마다 완성된 새로운 HTML을 내려주는 SSR과 다르게 SSG는 빌드 시에 페이지를 미리 생성해놓고 클라이언트의 요청이 발생하면 만들어 둔 HTML을 응답하는 렌더링 방식이다.

 

렌더링 방식 결정

위에서 여러가지 렌더링 방식에 대해서 살펴보았지만, 언급한 세가지가 렌더링 방식의 전부는 아니다. ISR, 유니버셜 렌더링 등 여러가지가 더 존재하지만 추가적인 렌더링 방식은 이후에 다시 다뤄보도록하겠다.

 

지금까지 살펴본 내용을 바탕으로 완벽한 렌더링 방식은 존재하지 않는다라고 생각한다. 따라서 내가 만드는 애플리케이션이 어떤 특성과 목적을 가지고 있는지에 따라 렌더링 방식을 결정하면 좋을 것 같다. 그럼 같이 어떨 때 해당 렌더링 방식을 사용하면 좋을 지를 살펴보자.

 

CSR: 사용자 경험에 중점을 둔 애플리케이션, 유저와의 상호작용이 중요한 경우, 유저의 개인정보를 담고 있어 검색 엔진에 노출될 필요가 없는 경우

SSR: 검색 엔진 최적화가 중요한 경우, 페이지의 데이터가 자주바뀌지만 누구에게나 같은 내용을 보여주는 경우

SSG: 검색 엔진 최적화가 중요한 경우, 페이지의 데이터가 바뀌지 않고 누구에게나 같은 내용을 보여주는 경우

 

 

이 포스팅을 정리하면서 SPA = CSR, MPA = SSR 라고 생각했던 잘못된 지식을 깰 수 있었다.

구성하는 페이지가 몇개인지, 렌더링을 어디서 준비하는지의 관점에서 이해하고 사용할 수 있도록하자.

다음에는 실제로 여러 렌더링 방식을 실험해보고 정리해보는 포스팅을 준비해보도록하겠다