[서버사이드 렌더링의 이해]

● 서버 사이드 렌더링의 이해

CSR SSR 에 대해서 자꾸 많은 것을 보고,, 그게 먼지 개념은 항상 들었지만 이해하기가 너무 힘들었습니다. 이번기회에 실습으로 아예 SSR을 접하면서 그 차이를 직접 느껴보고 개념을 이해하려고 합니다.

 

❍ 웹의 역사(SPA 시대까지)

1990년대 중반 - 정적 웹 사이트들

1990년대 중반까지는 모두 정적 웹 사이트들(Static Sites)이었다. 이미 잘 만들어진 HTML 문서들이 만들어져 있고, 사용자가 브라우저에서 해당 사이트에 접속하면 서버에 이미 배포되어져 있는 HTML 문서를 받아와서 보여주는 방식입니다. 예를 들어 페이지 내에서 다른 링크를 클릭하면, 다시 서버에서 해당 페이지의 HTML 문서를 받아온 후 페이지 전체가 업데이트 되어야 한다. 사용성이 떨어지고 페이지마다 전체가 업데이트 되어야하는 단점이 있습니다.

 

1996년 - iframe 태그 도입

문서 내에서 또 다른 문서를 담을 수 있는 iframe 태그가 도입이 되었고 이후 페이지 내에서 부분적으로 문서를 받아와서 업데이트 할 수가 있게 됩니다. 지금도 간혹 쓰이고 있는 태그입니다. (대체로 유튜브 같은 영상을 담아 보여줍니다.) 예컨대 블로그 내 영상이나 지도를 불러올 때 쓰이기도 합니다.

 

1998년 ~ing - XMLHttpRequest

프론트엔드 개발 시 자주 쓰이는 Fetch API의 원조 XHR Web API가 개발이 되어 이제는 HTML 문서 전체가 아니라 JSON과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아올 수 있게 됩니다. 해당 데이터를 자바스크립트를 이용해서 동적으로 HTML 요소를 생성한 후 페이지에 업데이트 하는 방식입니다.

 

2005년 - AJAX

2005년 XHR과 같은 방식이 공식적인 AJAX라는 이름을 가지게 되고 AJAX를 이용해서 카카오맵, Gmail과 같은 웹 앱들이 만들어지기 시작합니다. 이것이 현재 널리 쓰이고 있는 SPA(Single Page Application)입니다. 사용자가 한 페이지 내에 머무르면서 필요한 데이터만 서버에서 받아와 부분적으로 업데이트 됩니다. 이런 방식으로 하나의 어플리케이션을 사용하듯 웹 사이트에서도 앱과 같은 사용자 경험을 느끼게 되어 사용성이 굉장히 좋아지게 됩니다.

 

CSR(Client Side Rendering)

SPA가 트렌드가 되고 사용자의 PC 성능이 점차 좋아지면서 많은 것들을 무리 없이 처리할 수 있게 되었습니다. 또한 자바스크립트도 표준화가 잘 되어짐에 따라 강력한 커뮤니티를 바탕으로 Angular, React, Vue.js와 같은 프레임워크, 라이브러리가 생겨 CSR의 시대가 오게 됩니다. CSR은 쉽게 말해 모든 렌더링을 클라이언트 측(브라우저)에 위임하는 것을 의미합니다.

즉, CSR이 탄생하기 이전에는 서버쪽에 매번 HTML 파일을 요구해야했습니다. 그럼 브라우저는 늘 서버쪽에서 모두 다 그려진(즉, 렌더링이 완성된) HTML 파일만 가져와 브라우저는 보여주기만 한 것입니다. 따라서 버튼을 눌러서 토글이 열린다던지 그런 이벤트가 HTML에 만들어졌었다면, 그 HTML파일을 브라우저는 다시 서버에 요구하고, 서버는 렌더링을 다 해서 브라우저에게 다시 돌려준 것이죠. 즉, 클라이언트 쪽은 정말 요구만 하는 경향이 있었습니다.

SSR은 서버가 그림을 대신 그려서 클라이언트에게 주고 클라이언트는 보여주기만 해준다.
CSR은 재료만 서버에서 가져오고 그림은 클라언트가 그려서 보여준다.

아주 쉽게말하면 위와 같습니다. 

[SSR과 CSR의 차이]

 

따라서 예전에는 브라우저가 서버에게 직접적으로 데이터를 요구할 수 없었으며, 데이터를 요구하기 위해서는 새로운 html파일을 가져와 다시 보여줘야했습니다. 하지만 ajax가 생기면서 모두 해결이 되면서~ CSR이 탄생하게 된 것이죠.

 

❍ CSR은 그럼 왜생겻나?

서버는 클라이언트쪽의 요청도 들어야하고, 혼자 렌더링까지 해주어서 브라우저에게 보내주어야합니다. 서버 혼자 너무 빡센일을 합니다.. 하지만 클라이언트 쪽에 있는 렌더링 엔진은 탱자탱자 놀고만있죠? 따라서 클라이언트쪽에도 적당히 일을 넘겨주면서, 서버도 조금 더 적은일을 하자는 취지에서 시작된 것 같습니다. (개인적인 의견.. 또 자원 낭비는 아까워하는 이 개발의 세상이니까..)

또한 SSR은 너무 입아프게 말하다시피 깜빡임의 현상과 서버쪽의 과부하가 생길수 있으니까 CSR이 탄생한 것 같습니다.

물론 SSR과 CSR의 장단점이 각각 있기 때문에 또 알아서 필요할때는 선택해서 활용하라는 것 같네요.

 

❍ 서버 사이드 렌더링의 장점

서버 사이드 렌더링에는 어떤 장점이 있을까요? 리액트로 만든 SPA는 검색 엔진 크롤러 봇처럼 자바스크립트가 실행되지 않는 환경에서는 페이지가 제대로 나타나지 않습니다. 따라서 서버가 클라이언트 대신 렌더링을 해주면 검색 엔진이 페이지 내용을 제대로 수집해갈 수 있습니다. 따라서 웹 서비스의 검색 엔진 최적화를 위해서 서버 사이드 렌더링을 구현해주는 것이 좋다고 합니다.

또한 서버 사이드 렌더링을 통해 초기 렌더링 성능을 개선할 수 있습니다. CSR같은 경우 렌더링을 클라이언트쪽에서 하게 되므로 렌더링이 모두 이루어지기 전까지 사용자는 빈 화면을 볼 수도 있습니다. 이런건 UX가 좋지 않아지니까 서버사이드렌더링을 이용하면 좋습니다. 렌더링이 서버쪽에서 이뤄지니까 사용자는 빠르게 콘텐츠를 확인할 수 있습니다.

 

❍ 서버 사이드 렌더링의 단점

서버 사이드 렌더링은 결국 원래 브라우저가 해야할 일을 서버가 대신 처리하는 것이므로 서버 리소스 사용된다는 단점이 있습니다. 갑자기 수많은 사용자가 웹 페이지에 동시에 접속한다면 서버에 과부하가 발생할 수 있습니다. 따라서 사용자가 많은 서비스라면 캐싱과 로드 밸런싱을 통해 성능을 최적화해 주어야 합니다. 또한 서버 사이드 렌더링을 하면 프로젝트의 구조가 좀 더 복잡해 질 수 있고, 데이터 미리 불러오기, 코드 스플리팅과의 호환 등 고려해야할 사항이 더 많아져 개발이 어려워질 수도 있습니다.