이전에 사이드프로젝트를 준비하던 도중 팀원과 논쟁을 벌인 경험이 있습니다.
SSR과 CSR 중 어떤 것을 택해야할까? 에 대한 논쟁이었는데요.

오늘은 SSR과 CSR에 대해 알아보고, 둘 사이의 차이점 및 각 장점과 단점을 분석하는 시간을 갖도록 하겠습니다. 또한 그 외 GATSBY JS, SSG, TTI, TTV 에 대해서도 추가적으로 알아보도록 하겠습니다 :)

웹의 역사

Static Sites (~1995 mid)

1990년대 중반까지는 웹은 전부 다 Static Sites로 동작하였습니다.
이는 그림으로 살펴보면 이러한 형태가 되는데요.

사용자가 url을 입력하여 브라우저에서 서버 측에 어떤 html페이지가 필요한지를 요청 보내면 서버에서는 이미 등록되어있는 html 파일 중에 사용자가 요청한 html파일을 보내서 렌더링 시켜주는 식의 작동방식이었습니다.
이렇게 Static Sites로 작동하는 웹을 지금 시대 사람들이 보게된다면.. 음 일단 눈이 굉장이 아프고, UI 상으로 굉장히 보기 좋지 않습니다. Blinking Issue도 존재한답니다..
그렇지만 이 방식을 잘 기억해두세요..⭐️

<iframe> 도입 (1996~)

iframe 태그가 도입되었고, 페이지 내에서 부분적으로 문서를 받아와서 업데이트하는 방식이 가능해졌습니다.

XMLHttpRequest (1998~)

현재 우리가 사용하는 fetch api의 원조격이라고 볼 수 있는 XMLHttpRequest가 등장하면서 html 문서 전체가 아니라 Json 형식으로 서버에서 필요한 데이터만 받아와서 JavaScript를 통해 페이지에 렌더링할 수 있게끔 발전하였습니다.

AJAX (2005~)

위에 언급했던 방식이 본격적으로 AJAX라는 이름을 가지게 됩니다. AJAX는 요즘도 많이 접하는 단어죠?
구글은 이 AJAX를 이용하여 GMAIL과 Google Maps 등의 서비스를 만들게 됩니다. 사용자가 한 페이지에 머무르면서 필요한 데이터를 서버에서 받아와서 부분적으로 업데이트하는 방식, 즉 SPA의 시초가 이렇게 탄생하게 되었습니다. 웹사이트의 사용성이 많이 발전하게 된 시점입니다.

CSR과 SSR

사용자들의 pc 성능도 향상되고 JavaScript의 표준화가 잘 이뤄짐에 따라 Angular js, Vue js, react js 등의 프레임워크가 등장하며 오늘 우리가 주로 다룰 CSR 시대로 접어들게 됩니다.

CSR이란?

CSR (Client Side Rendering)은 말 그대로 클라이언트 사이드의 비중을 굉장히 높게 가져가는 방식을 말합니다. 실제로 이 경우에는 서버에서 받아오는 index.js 파일에는 script 태그의 script src="app.js" 라는 한 줄만 의미가 있을 뿐 html파일이 빈 껍데기나 다름없는 형태가 되는 걸 많이들 보셨을 겁니다.
html이 텅텅 비어져 있기때문에 링크된 app.js파일을 서버에 요청하고 다운로드 받아와 app.js+추가적인 데이터 json 을 받아 동적으로 화면을 rendering하게 됩니다.

그림으로 표현하면 다음과 같습니다.

CSR이 가진 문제점 🤦

1, Initial Loading may take too long

bundling 된 app.js파일은 어플리케이션의 로직과 소스코드가 담겨져 있어 사이즈가 크고 무겁기 때문에 이를 렌더링하는데 지연시간이 발생하고, 사용자들은 그 사이에 빈화면 혹은 로딩화면을 보게됩니다. 성격이 급한 사람들 입장에서는 이러한 방식이 정말 답답하게 느껴지겠죠??

2, Low Search Engine Optimization

Search Engine Optimization란 웹 페이지 검색엔진이 자료를 수집하고 순위를 매기는 방식에 맞게 웹 페이지를 구성해서 검색 결과의 상위에 나올 수 있도록 하는 작업을 말합니다. 이러한 작업을 할 때 검색 엔진은 페이지의 요소들을 살펴보고 취합하여 최적화를 시키는데, CSR의 경우에는 html의 body가 텅텅 비어있기 때문에 해당 요소들을 살피고 최적화를 시키는데 굉장히 까다로워지게 됩니다. Google의 SEO가 좋지 않은 것도 이러한 것이 원인으로 보여집니다.

자, 이러한 문제점을 해결하기 위해서 이제 사람들은 다른 방식을 생각하게 됩니다.
제가 아까 기억해두라고 했던 방식 생각나시나요? static sites 의 방식으로부터 영감을 받아 탄생한 SSR을 소개하도록 하겠습니다.

SSR이란?

SSR (Server Side Rendering)에서는 사용자가 웹사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 html파일을 만들고 이러한 html파일을 동적으로 제어할 수 있는 일부 JavaScript 소스코드만을 함께 클라이언트로 보내주는 방식으로 클라이언트에서는 이렇게 잘 만들어진 html파일을 CSR에 비해 더 빠르게 보여줄 수 있게 됩니다.

그렇다면 CSR에서 대두되었던 2가지 취약점을 SSR의 관점에서 살펴보겠습니다.

1, Initial Loading may take too long - 해결됨

CSR을 사용했을 때 무거운 app.js파일을 받아오는 것에 비해 서버에서 빠르게 틀이 잡힌 html을 제공해주기에 사용자들이 Rendering되는 첫 페이지를 보는 시간이 단축될 수 있습니다.

2, Low Search Engine Optimization - 해결됨

모든 컨텐츠가 html에 담겨져 있기에 효율적인 SEO가 가능합니다.

✋ 그렇다면 SSR은 만능이네요??

아닙니다. SSR에도 몇가지 이슈가 존재합니다. 그 부분을 살펴보도록 하겠습니다.

SSR이 가진 문제점 🤦‍♀️

1, Blinking Issue

이는 Static Sites에서 발생했던 문제죠? 사용자가 클릭을 하게되면 전체적은 웹사이트를 서버에서 받아오기 때문에 UX 측면에서 아주 치명적인 이슈가 생성됩니다.

2, Server side overhead

서버에 과부하가 걸리기 쉽습니다. 사용자가 많은 제품일수록 많은 사용자가 클릭할때마다 서버에서 데이터를 받아 html파일을 생성해야하므로 서버에 많은 무리를 줄 수 있습니다.

3, Need to wait before interacting

가장 치명적인 단점입니다. 사용자가 빠르게 웹사이트를 볼 수는 있지만, 아까 제가 SSR의 정의 부분에서 이야기 했죠? 첫 페이지가 렌더링 될 때 필요한 JavaScript 소스 코드는 받아왔지만 그 외의 동적으로 데이터를 처리하는 JavaScript 소스 코드는 아직 다운로드 받지 못했기에, 각종 이벤트 (클릭 등..) 에 대해 반응이 없는 상황이 벌어질 수 있습니다.

TTV과 TTI

위에서 우리는 CSR과 SSR의 장단점을 어느정도 살펴보았는데요. 이러한 이야기를 나눌때 꼭 등장하는 TTV와 TTI에 대해 알아보도록 하겠습니다. 정말 중요합니다!

TTV이란?

TTV는 'Time To View'의 줄임말입니다. 사용자가 페이지를 요청할 시에 해당 페이지가 보일 때까지 걸리는 시간을 의미합니다.

TTI이란?

TTV는 'Time To Interaction'의 줄임말입니다. 사용자가 페이지를 요청할 시에 해당 페이지에서 동적인 활동을 시작할 수 있을 때까지 걸리는 시간을 의미합니다.

CSR에서의 TTV와 TTI

위 그림과 같이 CSR은 TTI와 TTV가 같습니다.
CSR을 사용할 경우 최종적으로 bundling해서 보내주는 JavaScript파일을 어떻게 하면 효율적으로 많이 분할해서 첫번째로 사용자들에게 정말 필요한 부분만 보낼 수 있도록 을 해보아야합니다.

SSR에서의 TTV와 TTI

SSR에서는 위와 같이 TTV와 TTI의 시간적 차이가 있는 편입니다.이 시간의 단차를 줄이기 위해 노력을 해야하고, 보다 더 매끄러운 UI/UX를 제공할 수 있는 방안을 모색해야합니다.

Gatsby JS & Next JS

SSG와 Gatsby

SSG는 Static Site Generation의 줄임말으로 React JS의 경우에는 CSR에 최적화 되어있는 라이브러리이지만 Gatsby 라는 라이브러리를 사용하여 웹 어플리케이션을 정적으로 페이지를 미리 생성을 해놓고 서버에 배포를 해놓을 수 있습니다. 이는 완전 정적으로 보이지만, JavaScript 파일을 함께 가지고 있을 수 있기 때문에 동적으로 처리할 수 있다는 장점을 가지고 있습니다.
Gatsby와 React를 함께 사용하는 프로젝트는 향후 포스팅할 예정입니다.

Next Js

과거에는 강력한 SSR을 지원하는 라이브러리였지만 SSG도 지원을 하고, CSR과 SSR을 적당히 섞어서 보다 유연한 프로그래밍을 할 수 있도록 지원을 하고 있습니다.
이 역시 향후 사용방법을 포스팅할 예정입니다.

마무리

FrontEnd 생태계는 상당히 빠르게 더 나은 방향을 찾아 발전하고 있습니다. 그렇다고 해서 과거 이 생태계가 어떻게 발전해왔는지에 대해 잊어버려서는 안된다고 생각합니다.
Static Sites가 CSR의 단점을 어느정도 파훼할 수 있었다는 것, 정말 놀랍지 않나요?

필자는 그동안 개인적으로 UI/UX 부분에서 CSR이 보다 더 유저 친화적이라고 생각하여 CSR을 선호하였지만, 프론트 엔드 개발자로서 앞으로 SSR도 사용해봄과 동시에 더 나은 UX에 대해 고민해보는 시간이 분명 필요할 것이라고 생각하였습니다.

긴 포스팅 글 읽어주셔서 감사합니다 :)