클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SCR)의 차이

먼저 클라이언트-서버 간 통신에서 HTML을 반환하는 웹 서버의 대략적인 흐름은 다음과 같다.

 

정적 페이지(HTML/CSS/JS로 이루어진 웹 문서) 반환 👉🏻 DB 연동 및 API 요청 필요성 대두 👉🏻 동적 페이지(정적 페이지 + 서버에서의 비지니스 로직이 가미된 문서) 반환

 

정적 웹페이지(static web page) : 정적페이지란 항상 같은 내용을 보여주는 웹페이지(클라이언트가 URL을 통해 서버에 웹 페이지를 요청하였을 때, 서버 안에 이미 만들어져 있는 HTML 문서를 사용자에게 보여주는 경우)
동적 웹페이지(dynamic web page) : 동적페이지란 요청에 대해서 각각 다른 내용을 보여주는 웹페이지(클라이언트가 URL을 통해 서버에 웹 페이지를 요청했을 때, 서버는 사용자에 맞는 HTML 문서를 생성하여 사용자에게 응답하는 것)

여기서 동적 페이지는 CSS와 JS로 Interactive한 HTML문서로, AJAX 요청 및 실시간 처리까지 모두 반영하는 문서로 이해할 수 있다.

 

MPA(Multiple Page Application) 는 정적 페이지를 반환하는 웹 사이트의 경우 요청 시 마다 '이미 만들어진 새로운 페이지'를 반환하며, 이때 화면의 깜빡임이 발생한다.

반면에 React나 Vue로 만든 웹 페이지가 사용하는 SPA(Single Page Application) 는 MPA 방식과 다르게 하나의 페이지에서 모든 페이지로 이동하고 보여주는 방식이다.

 

1) MPA vs SPA

위에서 언급했듯, MPA는 다수의 페이지로 구성되어 요청마다 정해진 페이지를 반환하는 반면, SPA는 단일 페이지로 구성되어 해당 페이지 자체에서 요청에 따라 화면을 재구성한다.

 

MPA 방식에서는 이미 하드코딩된 정적 페이지들을 개별적으로 서버가 가지고 있고, 요청마다 서버는 해당 요청에 상응하는 정적 페이지를 반환해주게 된다. 이는 결국 렌더링이 서버에서 완료되어 최종 문서를 반환하고 있는 형태이다.

 

반면 SPA 방식에서는 최초 요청 시에 서버로부터 비어있는 HTML문서를 전달받고, 렌더링에 필요한 기타 다른 파일들(JS 등)을 Load하여 클라이언트(브라우저)단에서 렌더링을 실시해 화면을 구성한다. 즉, 렌더링이 클라이언트에서 이루어지는 형태이다.

(SPA는 MPA 이후에 탄생하였는데, 가장 큰 이유는 모바일 시대가 도래하면서 상대적으로 성능이 PC보다 좋지않은 모바일 디바이스에서 최적화를 보장하기 위해서와, 사용자 친화적인 UX를 제공해주기 위해서이다.)

 

MPA === SSR 또는 SPA === CSR은 엄연히 틀린 개념이다.
MPA/SPA는 웹 어플리케이션을 구성하는 형태를 말하고, SSR/CSR은 렌더링 방식을 말한다. 다만 MPA는 SSR 방식만, SPA는 CSR 방식만 가능한 것은 맞다. (전통적인 개념이라는 가정 하에)

 

2) CSR vs SSR

그렇다면 여기서 CSR과 SSR은 무엇일까 ? 각 용어를 해석하자면 클라이언트에서 HTML 문서를 렌더링할 것이냐, 아니면 서버에서 HTML문서를 렌더링할 것이냐로 구분할 수 있다.

 

SSR(Server Side Rendering)

• 요청 시마다 새로고침이 일어나며 서버에 새로운 요청을 전달
• 첫 페이지 로딩이 빠름, 이후 새 요청마다 새로고침 되어 UI/UX면에서 좋지 않음
• 사용자에 대한 정보를 서버측 세션에 저장(보안성 Good)

 

위 사진은 SSR의 기본적인 사이클인데, 서버에서 요청한 HTML 파일을 렌더링이 마친 상태로 응답하기에 로딩시간이 상대적으로 짧다는 것을 알 수 있다. 따라서 SSR 방식의 장점은 다음과 같이 정리할 수 있다.

 

SSR의 장점

1. 첫 페이지 로딩 시간이 CSR 방식과 비교해 매우 짧다. (하지만 그림에서 보듯이 별도의 JS 파일 등을 다운받아 적용하기까지는 시간이 좀 더 소요되어 사용자의 인터랙션에 정상적인 반응을 보일때까지 기다리는 시간이 어느정도 발생할 수 있다)
2. 이미 렌더링 된 HTML 문서가 전달되므로 SEO(Search Engine Optimazation)이 CSR 방식에 비해 적용하기 더 우수하다.
3. 사용자 정보를 서버측 세션으로 관리하기 용이하므로 CSR 방식에 비해 보안이 우수하다.

SSR의 단점

1. 각 페이지 별로 매번 로딩시간 및 새로고침 현상이 발생하기 때문에 UI/UX 면에서 좋지않다.
2. 서버에서 렌더링이 이루어지기 때문에 서버의 부담이 커지고, 부하에 걸릴 위험이 있다.

 

CSR(Client Side Rendering)

• 첫 페이지 로딩이 오래걸림(하지만 이후 유저와의 인터랙션이 빠름)
• 초기에 반환되는 HTML는 비어있기 때문에 SEO 문제가 발생
• 쿠키말고는 사용자 정보를 담을수 없음

이제 SPA 개념과 등장한 CSR 방식의 작동원리를 알아보자.

 

하나의 페이지에서 여러 페이지를 보여준다는 것은 결국 JS를 이용해서 페이지의 일부분이나 전체를 리렌더링한다고 생각해볼 수 있다.

 

React 라이브러리를 이용해 링크 이동과 같은 기능을 내부적으로 구현 시 Router를 설치하여 사용하지만, 결국 이러한 파일(jsx, js)들은 Webpack과 같은 번들링 도구를 거쳐 하나의 거대한 JS파일로 번들링된다.

SPA에서는 이처럼 번들링된 JS를 전달받아 Single Page Application을 구축하게 되는 것이다.

 

즉, CSR 방식에서는 번들링이 완료된 JS 파일을 모두 Load하기 전까지는 첫 페이지를 로드할 수가 없다 !

 

엄연히 말해 첫 페이지는 이미 Load 되었지만, 이 페이지는 빈 HTML 파일이다. 따라서 유저는 Loading이 완료되기까지 빈 화면을 볼 수 밖에 없고, 문서에 기입된 내용이 없기 때문에 SEO 최적화에도 많은 어려움이 따른다.(물론 Code Splitting 등의 기법으로 Loading 시간을 줄일 수 있는 기법들이 존재하기는 한다)

 

CSR의 장점

1. 초기 로딩 속도를 제외하면 이후 유저와의 인터랙션 속도가 빠르다.(이미 다운로드받은 번들링된 JS파일에 렌더링에 필요한 로직들이 들어가 있기 때문)
2. 따라서 새로고침이나 화면 깜빡임 등과 같은 현상이 발생하지 않기 때문에 UX에 엄청난 이점을 준다.
3. 서버가 클라이언트 뷰(View) 단에서 처리할 일을 신경쓰지 않아도 된다.

CSR의 단점

1. 유저는 번들링이 완료된 JS 파일을 모두 다운로드받기 전까지는 빈 화면만 볼 수 있다.
2. 초기에 반환되는 HTML 파일은 비어있기 때문에 SEO 최적화에 문제가 생긴다.

 

3) 2가지 장점을 모두 취할 순 없을까? 🤔

첫 로딩에 시간이 오래 걸리는 CSR의 단점과, 각 페이지마다 새로고침이 요구되는 SSR의 단점을 합친다면 이를 극복할 수 있지 않을까?

 

이러한 생각에서 탄생한 여러 프레임워크들이 존재한다. Vue의 경우엔 Nuxt.js가 대표격인 것 같고, React의 경우엔 Next.js / Gatsby.js 등이 있다. 물론 프레임워크를 사용하지 않고 순수 React에서 여러 설정들을 건드려 SSR을 지원하도록 할 수도 있다고 한다.

 

이렇게 SPA 형태에 SSR을 지원하도록 설정한다면, 첫 페이지 로딩은 SSR 방식으로 기존 CSR 방식보다 빠르게 문서를 받아옴과 동시에 해당 문서는 서버측에서 렌더링이 완료되었으므로 SEO 적용 또한 가능하다.

 

그 이후에 렌더링 될 페이지는 그 사이 번들링 된 js 파일을 받아서 CSR 방식으로 수행한다면 두 가지 렌더링 방식들이 가지고 있던 단점들을 어느정도 극복할 수 있다.

 

즉, SPA 형태에서 2가지 렌더링 방식을 적절히 혼합해 사용함으로써 기존 방식들이 가지고 있던 단점을 극복하는 것이다. ⭐️⭐️

 

다음 포스팅에서는 React에서 SSR 지원이 가능하도록 해주는 프레임워크인 Next.js를 사용하여 실제 CSR 방식과 SSR 방식의 차이점과 이 둘을 혼합하여 구동하는 방식의 실제 예시를 살펴볼 예정이다.