Hama Develop

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

January 13, 2020

조삼모사

(출처, 만화가 고셩규씨 개인 홈페이지)

SSR과 CSR의 차이는 얼핏 들으면 조삼모사 같은 이야기지만 유저는 상당히 다른 경험을 하게 된다. 대부분의 유저는 당장 도토리 4개 먹는 것을 선호한다. 저녁까지 웹사이트에 머물러 있고 싶은 생각이 없기 때문이다.

CSR은 페이지관련 문서를 서버로 부터 먼저 다 받아와서 보여주는 방식이고 SSR은 클라이언트 요청이 있을 때 마다 나누어 받아와서 보여주는 방식이다. 결국 화면을 보다는 점에서는 유저에게 같은 것을 주지만 주는 방법이 조금 다르다.

결국 같은 개수의 도토리를 받게 되는 원숭이들 처럼, 우리의 유저들도 같은 화면을 보게 된다. 하지만 화면을 보는 속도가 달라진다. 유저는 화면을 항상 빨리 보고 싶어한다. 유저의 시간은 소중하다.

TLDR:

  • 페이지 렌더링 과정에서 클라이언트가 서버에서 지속적으로 문서를 받아와야 하면 서버 사이드 렌더링
  • 처음 한번만 받아오고 이후 클라이언트에 저장된 문서들을 가지고 클라이언트에서 렌더링을 하면 클라이언트 사이드 렌더링,
  • 유저와 인터렉션이 많으면 CSR을 빨리 첫 화면을 띄워 주어야 하면 SSR을 하는 것이 좋다.

웹에서 페이지는 HTML, CSS, Java Script로 이루어져 있다. 브라우져는 위의 세가지 언어로 작성된 파일들을 읽어서 우리가 바라보는 화면을 만들어 내는 역할을 한다.

이러한 과정을 렌더링 이라고 한다.

유저가 처음 특정 웹에 접속을 했을 때, 접속후 웹 상에서 다양한 상호작용을 할 때마다 브라우져는 새로운 페이지를 렌더링 하게 된다.

이러한 렌더링이 클라이언트에서 이루어 지는지, 서버에서 이루어 지는지에 따라 클라이언트 사이드 렌더링(CSR), 서버 사이드 렌더링(SSR)로 구분 될 수 있다.

클라이언트와 서버가 무엇인지 익숙하지 않으실 수 있는 분들을 위해 간단히 정리하자면, 클라이언트는 서비스를 요청하는 기기를 이야기 하며, 서버는 요청에 대한 응답으로 데이터를 제공해 주는 컴퓨터를 이야기 한다.

즉 CSR은 클라이언트의 기기, 즉 유저의 컴퓨터에서 렌더링 작업이 이루어 지는 것이고, SSR은 회사의 컴퓨터에서 렌더링 작업이 이루어 지는 것이라고 이해하면 된다.

동일한 유저의 활동에 따라 어떤식으로 반응을 하는지 구체적 예를 들어 알아보자

유저가 특정 웹 사이트 내에서 다양한 활동을 한다고 생각해 보자. 일반적으로 맨 처음에는 홈 화면을 보고 홈화면에 있는 특정 컨텐츠를 클릭해서 해당 컨텐츠를 구체적으로 다루는 페이지로 들어가서 해당 컨텐츠를 확인 할 것이다. 일반적인 웹사이트 구성 이라면, 홈 화면에서 보이는 url은 도메인 이름(ex. Hamadevelop.me) 그대로 일 것이고 특정 콘텐츠의 url은 해당 콘텐츠까지의 경로를 포함하고 있을 것이다. (ex. Hamadevelop.me/content).

SSR의 경우에는 서버가 유저가 홈 화면에 접근 했을때 홈화면에 해당하는 HTML, CSS, JS를 브라우저에 전달한다. 브라우저는 이를 받아 유저가 볼수 있도록 랜더링을 한다. 유저가 특정 컨텐츠로 접근을 하게 되면 특정 콘텐츠에 해당하는 HTML, CSS, JS 를 브라우저에 전달하고 브라우저는 이를 유저가 볼수 있도록 랜더링을 한다.

반면 CSR의 경우에는 유저가 처음 도메인에 접근 했을 때, 앞으로 그 서비스를 이용하기 위해 필요한 문서들을 한번에 다운로드 받는다. 그리고 그 뒤에 발생하는 페이지 전환은 클라이언트에서 이미 받아놓은 문서들을 가지고 다시 랜더링을 하여 유저가 볼 수 있도록 한다.

SSR에서는 서버에 한번 요청을 하고 그 결과를 유저에게 보여주는 것이기 때문에, 화면 이동시 유저는 한번의 깜빡임을 경험하게 된다. 반면 CSR에서는 깜빡임이 없다. 이미 처음 접속할때 모든걸 받아 놓았기 때문에, 다시 서버에 요청이 들어가지 않고 그냥 화면만을 전환해 주면 된다. 대신 맨 처음 접속을 했을 때 화면 렌더링이 더 느리다. 받아와야 하는 데이터의 양이 더 많기 때문이다.

유저가 브라우저와 상호작용을 할 때 매번 서버와 소통을 하는 SSR에 비해 즉각적으로 반응이 이루어지는 CSR의 유저 경험이 좋을 수 밖에 없다. 또한 서버에서도 응답을 해주어야 하는 빈도와 응답의 크기가 획기적으로 줄어들어 부담이 적다.

과거에는 SSR방식을 사용하는 것이 지배적 이었다. 하지만, 네트워크의 발달과 브라우저 성능의 발달로 인해 CSR의 적용이 점점 늘고 있다. 요즘 웹사이트 개발에서 큰 인기를 끌고 있는 Single Page Application(SPA)도 CSR을 이용한다.

SSR은 검색엔진 최적화(SEO)에 더 좋다는 말이 있는데 , CSR상에서도 검색엔진 최적화를 할 수 있는 방법이 등장했으며, 구글검색 시에는 구글 검색 봇이 알아서 CSR 페이지를 잘 읽고 검색 결과에 노출을 잘 시켜 준다고 하니, SSR이 딱히 SEO에 우월하다고 말하기는 어렵지 않을까 생각한다.

CSR은 앞서 말했듯 초기에 받아와햐 하는 데이터의 양이 크다. 유저에게 바로 컨텐츠를 보여주는 것이 중요한 경우(뉴스, 블로그 등)은 SSR을 사용하는 것이, 유저와 인터렉션이 많은 웹의 경우는 CSR을 사용하는 것이 더 바람직 할 것으로 생각한다.