CSR - Client Side Rendering

CSR은 Client Side Rendering의 약자로 이름에서 알 수 있듯 클라이언트 단에서 페이지를 렌더한다.
클라이언트에서 렌더를 한다는게 무슨 의미냐, 말 그대로 HTML은 골격만 날라와서 그 위에 표기할 컨텐츠 정보가 담겨있는 스크립트 파일로 서버에서 통채로 받아와 클라이언트가 그 js파일을 읽고 페이지를 렌더하게 되는 것이다.

그렇기에 페이지에서 DB에 접근해 정보가 필요하다면 클라이언트 레벨에서 서버로 요청을 보내고, 응답을 받아 페이지 전체가 변할 필요없이 변하는 부분에 대해서만 렌더할 수 있게 된다.

대표적으로 React.js나 Vue.js같은 라이브러리가 이러한 CSR 방식을 사용하는데 (Next.js 같은 라이브러리를 사용하지 않을때) 이러한 방식의 특징으로는 SPA(Single Page Application) 구현이 용이하다는 점이 있다.

장점 1. 페이지 내에 상호작용이 많을 경우 더 나은 경험을 제공한다.

해당 페이지에서 상호작용하는 모든 정보가 처음부터 스크립트 파일에 담겨져 서버로 부터 전송되기에 더 나은 유저 경험을 제공할 수 있다.

이렇게 보면, 서비스는 사용하는 유저 중심으로 제공되어야 하는데 그럼 CSR이 짱 아님 ? 이라고 생각할 수 있지만, 여기에 치명적인 단점이 존재한다.

단점 1. 바로 페이지 최초 로딩이 오래 걸린다는 점이다.

유저가 기다리는 시간이 있다는 것 자체가 UX를 크게 해치는 요인중 하나 이기에 CSR이 만능은 아니고, 이를 해결하는 것이 CSR의 최고 과제 중 하나라고 할 수 있다.

여기서 끝나면 좋겠지만 다른 단점이 한가지 더 있다.

단점 2. 검색 엔진 최적화(Search Engine Optimazing, 이하 SEO)에 약하다는 점이다.

이를 알아보기 전에 검색 엔진 최적화라는 것이 먼저 알아보자.

우리가 사랑하는 구글, 네이버, 다음과 같은 웹 사이트는 검색 결과를 제공하기 위해 사전에 각 사이트가 가지고 있는 정보를 모아서(크롤링) 저장한다.

그런데 정적 페이지라면 각 사이트가 가지고 있는 정보가 HTML 구조 적혀져 있어 해당 페이지가 어떤 정보를 가지고 있는지 엔진이 파악하기 유리하지만, CSR으로 구성된 웹 페이지의 경우는 HTML은 골격만 있고, 페이지 안의 컨텐츠는 스크립트 파일에 있기때문에 검색 엔진이 결과를 확인하는 것에 불리하다.

요즈음은 네이버, 구글등의 멋진 선배 개발자님들의 피땀어린 노력으로 이와 같은 점이 많이 개선되었다지만, 그래도 여전히 CSR의 단점이라고 꼽을 수 있다.

SSR - Server Side Rendering

CSR을 알아봤으니 이와 자주 비교되는 SSR에 대해서도 알아보자면, 이 역시 이름에서 직관적으로 알아볼 수 있듯, 서버에서 렌더링한 후 결과물을 제공하는 방식이다.
렌더된 결과물을 클라이언트로 보내주기에 HTML에 골격만 있는 것이 아니라 피와 살이 다 덮어져 하나의 페이지로 제공이 된다.

그럼 이 SSR의 장점이 무엇일까 ?

장점 1. 바로 최초 페이지 로딩이 빠르다는 점이다.

CSR 같은 경우는 골격 던져주고 스크립트 파일 던져준 후 네가 요리해서 먹어라지만,
SSR 같은 경우는 바로 완성된 요리를 하나 딱 제공하는 것과 비슷하다고 볼 수 있을 것 같다.

다만 후술하겠지만 최초 로딩이 빠르다고 다 좋은 것은 아니다.

장점 2. SEO에 유리하다.

SEO가 CSR의 단점이었다면 SSR에겐 장점이다.
SSR은 렌더된 하나의 페이지를 클라이언트에 전달하기에 검색엔진이 읽을때도, 이 페이지엔 무슨 정보가 있고, 무슨 키워드로 검색하면 이 페이지를 띄워주면 되겠다는게 바로 보인다는 것이다.

장점은 대략 훑어본 것 같으니 단점으로 넘어가자면,

단점 1. 대표적인 단점이 페이지의 컨텐츠가 바뀌면 전체 페이지가 다시 렌더된다는 점이다.

이 SSR 방식은 페이지의 컨텐츠를 날 것 그대로 제공하고 최소한의 상호작용을 위한 스크립트만 함께 서버로부터 전달 받기에 페이지의 한 부분이 바뀌면 전체 페이지를 다시 서버가 재렌더해서 클라이언트로 전달하게 된다.

CSR의 경우는 바뀐 부분만 다시 렌더하면 된다지만 SSR의 경우는 전체 페이지를 다시 렌더해서 서버로 부터 전달받기에 페이지가 깜빡이는데 이를 Blinking이라고 한다.

페이지의 아주 작은 부분만 바뀌면 되는데 유저 입장에선 페이지 전체가 깜빡이니 유저 경험이 저해될 수 밖에 없다.

단점 2. 그 다음 단점이 서버 과부하가 걸리기가 쉽다는 점이다.

내가 만든 귀여운 프로젝트처럼 사용자가 적은 프로젝트면 모를까, 큰 프로젝트의 경우는 모든 유저가 클릭해서 페이지의 컨텐츠가 바뀌어야 할때마다 서버가 다시 렌더해서 결과물을 클라이언트에 전달 해줘야하니, 서버 입장에선 그저 괴로운 것이다.

단점 3. 그리고 이것 역시 치명적인 단점인데, 상호작용이 하기까지 시간이 걸린다.

SSR은 페이지에서 필요한 날 것의 컨텐츠와 이를 동작하기 위한 최소한의 스크립트만 함께 주어진다.
그리고 나서 상호작용에 필요한 스크립트를 서버로 부터 받아오기 시작하는데, 여기 기다리는 시간에서 유저가 상호작용이 필요한 동작을 하게된다면 ?
그냥 작동하지 않는 것이다.
왜 ? 그 동작을 실행할 스크립트가 오고 있으니까 !
그래서 유저 입장에선 눌렀는데 왜 안돼 ? 라는 반응이 생길 수 있는 것이고 이 역시 치명적인 UX저하로 이어지게 된다.

여기서 나오는 키워드가 TTV와 TTI인데,

앞서 설명한 CSR의 경우는 페이지를 조회하면 그 해당 페이지에서 상호작용하는 스크립트를 포함해 전부 전송하게 되고, 컨텐츠가 보이는 시간 (Time To View, TTV) 와 상호작용 하기 까지의 시간 (Time To Interaction)이 일치한다.

그런데 SSR의 경우는 ?
컨텐츠가 보여지고 나서 상호작용에 필요한 스크립트를 서버로 부터 전달받기에 이 사이에 틈이 생기게 되는 것이다.

그래서 CSR 방식의 숙제는 어떻게 해야 효율적으로 빠르게 사용자가 페이지를 볼 수 있게 스크립트를 쪼개서 보내느냐. 이고, SSR 방식의 숙제는 어떻게 TTV와 TTI의 간격을 줄이느냐가 되는 것이다.

결론

결론은 사실 별건 없다.
코딩에 정답이 어디있겠는가. 적어도 난 모른다.
그냥 해당 웹페이지의 성질에 따라서 선택하면 되는 것이다.
해당 페이지에 상호작용할 것도 없고 그냥 빠르게 글만 보여주는 신문이나, 블로그 글이 담긴 페이지라면? SSR이 유리할 것이다.

그런데 무슨 선택하는 버튼이 엄청 많은 페이지에 SSR을 적용하게 되면 버튼 하나 하나 누를때마다 페이지가 깜빡깜빡하게 되는 불편함을 야기하게 될 것이고, 이는 UX저하로 이어진다.
이럴때는 한번 딱 받아오고 나서 필요한 정보가 있다면 AJAX 요청을 보내는 CSR 방식이 유리할 것이다.

개발자 본인이 개발하는 웹 페이지가 어떤 방식이 더 유리할 것인가, 판별하고 단점을 최소화된 페이지를 만들어 내는게 결국 고수 개발자가 아닐까하는 생각을 하게된다.

결론의 결론,
열심히 공부하자.