CSR과 SSR 언제 어떤것을 써야할까?
CSR, SSR 그리고 SPA. (Feat, SEO)
CSR의 탄생 배경?
전통적인 웹개발에서 사용자에게 화면을 보여주기 위해서는
웹서버에서 필요한 데이터를 DB에서 가져와 가공해 HTML에 결합해 응답을하고 브라우져에서 바로 그려주는 방식이였고
이를 SSR(Server-Side rendering)이라고 한다.
하지만 사용자가 웹에서 페이지 이동(URL)을 할 경우 서버에서 새롭게 페이지를 응답해 브라우져에서 새로 그려주어야 했으므로
이미 렌더링 되었고 변경이 불필요한 부분까지 새로 렌더링되며 화면의 깜빡임까지 발생하니 사용자 입장에서 부드럽지 않았다.
이러한 문제를 개선하고자 JS(자바스크립트)로 HTML을 동적으로 생성하고 조작해 필요한 부분만 렌더링 해주도록 만들어진 것이 CSR(Client-Side rendering)이다.
JS로 CSR 방식으로 만들고자 직접 HTML을 동적으로 조작하기 위해 모든 것을 프로그래밍 한다면 난이도도 높고 시간도 오래 걸릴 것이다.
이를 위해 React, Angular, Vue, Svelt와 같은 프레임워크들이 탄생했으며 쉽게 CSR 기반으로 개발 할 수 있도록 가능해졌고, 모던한 웹개발 트렌드로 자리잡게 되었다.
CSR의 연장선으로 하나 알고가면 좋을 개념이 SPA(Single Page Application) 이다.
하나의 페이지에서 필요한 부분만 동적으로 렌더링해 마치 요즘 스마트폰에서 앱을 사용하는것과 같이 부드러운 사용감을 제공하기 위해 CSR을 이용해 개발된 앱을 일컫는다.
Gmail, 페이스북과 같은 사이트들이 대표적인 SPA이다.
CSR이 무조건 좋은것 인가?
결론부터 말하자면 그렇지 않다.
웹 애플리케이션에 이미 접속한 경우에 사용자가 체감되는 사용성은 좋지만 한가지 문제가 있다.
그것은 바로 SEO(Search Engine Optimization) 에 대응이 안된다는 것이다.
SEO는 단어 의미 그대로 구글, 네이버, 빙과 같은 검색엔진에서 검색이 잘 되기 위한 기술과 개념으로 이해하면 된다.
검색 엔진의 웹 크롤러 봇(Bot)이 검색 대상 웹사이트들에 접근하여 HTML 내용을 수집하여 검색 엔진 DB에 저장하여 색인 후 검색결과로 제공하게 되는 것이다.
하지만 CSR로 개발된 웹사이트의 경우 검색 봇이 수집한 시점에는 JS를 이용해 동적으로 생성된 HTML이 없는 상태이기 때문에 제대로된 컨텐츠가 수집되지 않는다.
만약 이해가 잘 안된다면 React, Vue와 같은 앱으로 만든 사이트들을 접속해 페이지 소스 보기를 실행해보면 단번에 이해가 될것이다.
그렇기에 만들고자 하는 웹 서비스가 검색 엔진에서 많이 노출되어야 한다면 SEO을 꼭 신경써야하기에 무턱대고 사용성을 생각해 CSR로 만든다면 낭패를 볼 수 있다.
앱 사용성과 SEO 둘 다 잡는 방법
다행히도 SEO를 대응하고자 CSR을 무조건 포기하란 법은 없다.
CSR과 SSR을 둘 다 지원해주는 React 진영의 Next JS, Vue 진영의 Nuxt와 같은 프레임워크들도 탄생했고 많은 인기를 얻고 있다.
사용성도 높이고 검색 노출도 잘되고 얼마나 좋은가?
하지만 이 모든 이점을 누리기 위해서 CSR과 SSR 개념을 정확히 이해하고,
하이브리드 렌더링을 위한 프레임워크 사용법을 잘 익히고 개발해야하기에 난이도가 다소 있는 편이다.
결론
검색 노출이 잘 되어야한다면 기본적으로 SSR 방식을 고려하자.
만약 프론트엔드 전문 개발팀이 있거나 새로 학습해서 적용해볼 시간적 여유가 있다면 Next나 Nuxt에 도전해보자.
사이드 프로젝트나 회사 내부에서 사용 할 백오피스와 같은 웹서비스라면 CSR로만 제작해도 충분하다.