[네트워크] 서버사이드 렌더링(SSR)과 클라이언트 사이드 렌더링(CSR)

 

1.  서버사이드 렌더링 (SSR)

 

웹 페이지의 HTML을 서버에서 생성하여 클라이언트(웹 브라우저)에 전송하는 방식.

사용자가 웹 페이지에 접근할 때 서버는 요청된 페이지를 렌더링하고 클라이언트로 전송한다. 서버의 웹 페이지가 브라우저에 도착했을 때는 이미 완전히 렌더링이 된 상태이다.

 

만약 웹 페이지에 데이터베이스의 데이터가 필요한 경우, 서버에서 데이터를 처리하고 불러와서 동적인 웹 페이지로 변환하여 브라우저로 보낸다.

 

서버가 모든 요청마다 HTML을 생성해야 하므로 서버에 부하가 올 수 있다.

 

2.  클라이언트사이드 렌더링 (CSR)

 

SSR과 반대로 CSR은 클라이언트에서 JavaScript를 실행하여 페이지를 렌더링한다. (React나 Angular, Vue.js 같은 프레임워크들이 CSR 방식을 사용한다.) 

 

만약 데이터베이스의 데이터가 필요한 경우 이를 위해 API가 사용된다. 웹 페이지를 렌더링 하기 위해 필요한 데이터를 API 요청으로 해결하는 것이다. (백엔드와 프론트 단에서 작성하는 RESTful 형식의 API 명세 등)

 

3. 차이점

가장 큰 차이점은 웹 페이지가 렌더링 되는 위치, 시점이다. SSR은 서버에서, CSR은 클라이언트에서 페이지를 렌더링한다. 이런 방식의 차이에서 오는 장단점도 존재한다.

 

SEO가 우선순위인 경우 SSR 방식이 좋을 것이다. SEO란 Search Engine Optimization 의 줄임말로 웹 사이트나 웹 페이지의 검색 결과에서 높은 순위를 얻기위한 전략, 기법을 말한다.

예를 들어 블로그 같은 경우 검색 엔진이 사용자에게 많이 노출되는 것이 유리하기 때문에 SSR 방식을 적용하여 사용자가 클릭할 때마다 페이지가 렌더링하여 사용자에게 정보를 제공하는것이 좋다. 뉴스 속보를 제공하는 홈페이지도 SSR 방식을 사용하는 것이 유리 할 것이다. 물론 단점으로는 유지비용이 높아지게 된다.

 

 CSR은 SPA(Single Page Application) 및 동적인 사용자 인터페이스가 필요한 애플리케이션에서 사용된다. 예를 들어 많은 예약 사이트들은 CSR 방식을 사용한다. SSR은 서버에서 렌더링하기 때문에 서버에 부담이 많이 가지만, CSR은 서버에서 클라이언트로 필요한 데이터를 넘겨주기 때문에 부담이 적다. 또한 서버로부터 받은 데이터를 이용하여 화면의 일부만 변경하기 때문에 빠른 렌더링으로 사용자에게 이점을 줄 수 있다.

 

 

SSR, CSR을 적절히 혼합한 아키텍처 도입의 장점

 

명확한 역할 분담: SSR에서는 백엔드가 HTML을 렌더링하고, 프론트엔드는 그 HTML을 사용자와 상호작용하는 데 집중한다. 이로 인해 역할이 명확히 나뉘어 협업이 원활해진다.

API와 페이지 구조의 명확화: 백엔드는 데이터와 페이지 구조를 정의하고, 프론트엔드는 이를 기반으로 사용자 인터페이스를 설계한다. 이로 인해 API와 페이지 구조에 대한 명확한 기준을 세울 수 있어 협업이 용이하다.