1) 개요
최근 웹 개발 채용시장을 보면 SSR(Server-Side-Rendering) 기반 프레임워크의 사용이 많아졌다.
또한, SSR과 CSR(Client-Side-Rendering)의 개념을 이해하는지를 채용 기준에 넣기도 한다.
따라서 NEXT.js를 배우기 전에 SSR과 CSR의 개념과 차이를 보고 가는것이 좋을듯하다.
2) SPA / MPA
SSR과 CSR의 개념을 알기 전, SPA(Single Page Application)와 MPA(Multi Page Application)을 알고 가야한다.
우리가 흔히 웹 개발이라 생각하며 배우려는 React나 Vue와 같은 JS기반 프레임워크는 SPA를 개발하기 위함이다.
또한 MPA는 전통적인 웹 페이지 구성방식, 즉 고전적 방법이기 때문에 현재 배우는 입장에서는 생소할 수 있다.
2.1) SPA
SPA는 Single Page Application의 약자로, 하나의 페이지로 구성된 웹 애플리케이션을 의미한다.
하나의 페이지로 구성되어 있기 때문에 이벤트 발생시 보통 헤더는 고정되어있고 메인화면이나 이벤트가 발생한 부분만 바뀌는 방식이다.
2.2) MPA
MPA는 Multi Page Application의 약자로, 탭 이동 시 서버로부터 새로운 HTML을 받아와 페이지 전체를 렌더링 하는 방식이다. 웹 페이지를 구성하는 전통적인 방식이다.
3) CSR / SSR
(일반적으로) SPA에서는 CSR로 렌더링하고, MPA 에서는 SSR로 렌더링 한다.
다만 SPA === CSR 이라던가 MPA === SSR 이라고 일반화 해서는 안된다. 이 두 개념은 페이지의 개수와 렌더링 방식에 따라 다른것이므로 혼용하지 말자.
3.1) CSR의 동작 과정
- 사용자가 웹사이트에 방문하면 브라우저가 서버에 컨텐츠 요청.
- 서버는 빈 뼈대 HTML을 응답으로 회신.
- 브라우저가 연결된 JS링크를 통해 서버로부터 JS파일 다운로드.
- JS를 통해 동적으로 페이지를 만든 후, 브라우저에 출력.
CSR의 장점
CSR은 JS파일을 다운로드하고 동적으로 DOM을 생성하는 시간동안 기다리기 때문에 초기 로딩속도가 느리지만, 초기 로딩 이후 페이지 일부를 변경할 때 서버에서 해당 데이터만 요청하기 때문에 초기 이후 구동 속도가 빠른게 장점이다.
또한, 서버는 빈 뼈대 HTML만을 넘기기 때문에 서버의 부하가 적다. 때문에 연산이나 라우팅 등을 클라이언트 측에서 처리하게되며 이는 반응속도의 향상에 도움이 된다.
추가로, 이벤트 발생시 필요부분만 바꾸기 때문에 사용자 경험(UX) 측면에서 이점이 있다.
CSR의 단점
CSR의 가장 큰 단점은 SEO(Search Engine Optimization / 검색엔진 최적화)에 불리하다는 것이다.
브라우저들이 갖는 웹 크롤러는 HTML을 읽어 검색 가능한 색인을 만든다. 하지만 CSR의 경우 첫 페이지 로딩시 빈 뼈대 HTML을 서버로부터 받기 때문에 파일이 비어있다.
이 경우 색인할만한 컨텐츠가 존재하지 않기 때문에 크롤링 봇 입장에서는 최적화가 어려운것이다.
물론 구글의 크롤링 봇은 JS를 실행할줄 알기에 CSR 크롤링도 가능하다고는 하지만, 완벽한 단계가 아닌, 즉 불안정한 상태이기 때문에 구글 측에서도 여전히 SSR을 권장하고있다.
또한, 보안 측면에서도 단점이 있다. 쿠키나 로컬스토리지에 저장되는 사용자 정보 도용에 취약하며, 핵심 기능이 클라이언트에서 수행되므로 로직이 노출 될 가능성이 있다.
3.2) SSR의 동작 과정
- 사용자가 웹사이트에 방문하면 브라우저가 서버에 컨텐츠 요청.
- 이에 서버는 페이지에 필요한 데이터를 얻고 삽입. CSS까지 적용하여 렌더링 준비를 마친 HTML과 JS코드를 브라우저에 회신.
- 브라우저에서는 JS코드를 다운로드하고 HTML에 JS로직을 연결.
SSR의 장점
SSR은 모든 데이터가 이미 HTML에 담긴 채로 브라우저에 회신되기 때문에 SEO에 유리하다. 즉 크롤링 봇이 HTML파일을 읽기 편하다는 것이다.
또한 JS코드를 다운받고 실행하기 전에 사용자가 이미 HTML이 렌더링된 화면을 볼 수 있다. 즉 뭔가 보이기 시작하는 시점이 CSR 보다 빠르다는 것이다.
보안 측면에서도 CSR보다 이점이 많다. 서버에서 렌더링을 할때 escaping과 같은 조치를 취할 수 있어 안정적이며, XSS(Cross-Site Scripting)공격에 대한 위험성이 낮으며, CSRF(Cross Site Request Forgery)공격의 노출 가능성도 적다.
SSR의 단점
하지만 뭔가 보이기 시작하는 시전, 즉 렌더링된 페이지가 보이는 시점에서 이벤트(ex. 클릭)를 발생 시키면 반응이 없을 수도 있다.
그 이유는 상호작용(Interaction)이 가능한 페이지 처럼 보일 뿐, 실제로는 클라이언트 측에서 JS가 실행되고 이벤트 핸들러가 있는 JS로직이 모두 연결될 때까지는 사용자 입력에 응답이 없다는 것이다.
즉, TTV(Time to View)와 TTI(Time to Interact)간의 시간 차이가 존재한다는 것이다. 반면 CSR은 JS가 동적으로 DOM을 생성하기 때문에 TTV시점과 TTI시점간 차이가 없거나 미묘하다.
3.3) CSR / SSR 장단점 정리
| CSR | SSR | |
| 장점 | ● 화면 깜빡임이 없음 ● 초기 로딩 이후 구동 속도 빠름 ● TTV / TTI 간 차이가 적거나 없음 ● 서버 부하 적음 |
● 초기 구동 속도가 빠름 ● SEO에 유리 |
| 단점 | ● 초기 로딩 속도가 느림 ● SEO에 불리 |
● 화면 깜빡임이 있음 ● TTV / TTI간 차이가 있음 ● CSR에 비해 서버의 부하가 발생함 |
3.4) 사용 권장 예시
| CSR | SSR |
| 네트워크가 빠를 때 | 네트워크가 느릴 때 |
| SEO가 불필요할 때 | SEO가 필요할 때 |
| 사용자에게 보여지는 데이터가 많을 때 | 최초 로딩이 빨라야할 때 |
| 경량 메인 스크립트를 사용할 때 | 메인 스크립트의 크기가 클 때 |
| 웹 사이트에서 상호작용이 많을 때 | 웹 사이트에서 상호작용이 적을 때 |
4) 결론
결국 CSR이니 SSR이니 렌더링을 어디서 하느냐에서 오는 차이이고, 그 차이로 인해 프로젝트의 수익성에 지대한 영향을 미칠 수 있다는 것이다. 이 때문에 NEXT.js와 같은 프레임워크들이 유행하는것 같다.(NEXT.js는 SSR을 쓰면서 필요부분에만 CSR을 적용할 수 있음.) NEXT.js에 관한 정리는 이후 따로 포스팅 하겠다.
