미뤄두었던 SSR, CSR 개념 정리를 해보자!
그래도 개발자를 할건데, 중요한 개념들은 머릿속에 넣어두는 것도 좋지만,
입 밖으로 설명할 수 있어야 하지 않을까?
아래 사진은 이번 글의 결론이자 핵심이다.
먼저 보고 글을 이해하는 것이 도움이 될것이다.
그 전에 SPA, CSR, MPA, SSR은 알아야 겟져?
1. 랜더링부터 알아보자
우리는 원하는 정보를 얻기 위해 거의 매일매일 웹페이지에 접속을 하는데,
우리가 인식하지는 못하지만, 그때마다 웹 페이지는 미리 만들어진 것을 가져오는 것이 아니라,
실시간으로 그려지는 것이라고 볼 수 있는데,
실시간으로 웹페이지가 그려지는 과정을 웹 브라우저의 렌더링 이라고 말한다.
2. SPA vs MPA
1) MPA (Multi Page Application)
spa와는 반대되는 전통적인 웹 어플리케이션 개념이다
mpa는 페이지를 이동하면 서버에서 새로운 페이지를 새로 렌더링해서 전송해주는 방식이다
페이지 안에 내용이 많이 없으면 상관없지만, 웹이 발전하고 그에 따라 사용자 경험이 중요해지면서
페이지에 담기는 정보가 많아지고, mpa방식은 서버에게 비효율적이고 속도도 느려지면서 외면을 받게 되었다.
이런 어려움 때문에 SPA가 탄생했다고 봐도 된다.
2) SPA (Single Page Application)
SPA는 단일 페이지 모던 웹 어플리케이션이라고 한다.
하나의 웹사이트에는 다양한 페이지가 존재하는데,
spa에서는 다양한 페이지를 하나의 페이지로 담는 것이다.
사용자가 처음 웹사이트에 접속하면 핵심 정적 리소스(HTML, CSS, JavaScript)를 다운로드한다.
그리고 사용자가 다른 페이지로 이동하면, 페이지에서 변경이 필요한 부분만 로딩하고 전체 페이지를 다시 로딩하지 않는다.
'필요한 데이터를 서버에서 비동기로 가져와서 현재 페이지에 업데이트 한다'
그래서 웹 사이트에서 보내야 하는 네트워크 요청을 최소화 하기 때문에
빠른 응답과 부드러운 사용자 경험이 가능한 것이다.
3) 결국에는,
결국, 어떤 웹사이트를 만들지에 따라 선택하는 방식이 다르다.
페이지 수가 많고 빠르고 부드러운 UI/UX를 구축하려면 SPA,
간단한 페이지를 구현하고 필요한 정보가 적으면 MPA 방식도 좋은 방법이다.
SPA의 특징은 다음과 같습니다.
- 동적 콘텐츠 로딩: SPA는 필요한 콘텐츠를 서버에서 비동기적으로 가져와서 페이지를 업데이트합니다. 사용자가 페이지를 이동해도 전체 페이지를 다시 로드하지 않고 필요한 부분만 갱신하기 때문에 빠른 웹 경험을 제공할 수 있어요.
- 클라이언트 사이드 라우팅: SPA는 클라이언트 측에서 JavaScript로 라우팅을 처리합니다. MPA와 다르게 서버로부터 새로운 페이지를 요청하지 않고도 다른 화면으로 전환할 수 있는 것이죠.
- 상태 관리: SPA는 클라이언트 측에서 애플리케이션 상태를 관리해요. 사용자 인터페이스(UI)의 현재 상태에 따라 서버와 데이터를 주고받아 동기화할 수도 있고요. 덕분에 사용자에게 빠른 인터렉션을 제공할 수 있어요.
- 재사용 가능한 컴포넌트: SPA는 일반적으로 재사용 가능한 컴포넌트 기반 구조를 가지고 있어, 유지보수성과 확장성이 뛰어나요. 컴포넌트를 독립적으로 개발 및 테스트할 수 있어서 생산성도 향상되고요.
출처 : https://docs.tosspayments.com/resources/glossary/spa#spa의-특징
SPA의 특징
3. SSR vs CSR
1) SSR(Sever-Side-Rendering)
말 그대로 서버 사이드 랜더링, 서버에서 랜더링을 통해 화면을 보여주는 것이다.
서버에서 페이지를 완전하게 만들어 클라이언트에게 전달해주기 때문에 초기에 화면을 보여주는 속도가 빠르다.
그렇다면 SSR 이니깐, 서버 사이드 스크립트 언어를 사용하는 프레임워크들이 이 방식을 사용하겠죠?
PHP, ASP, JSP, Node.js 등등..
아래와 같은 프로세스로 동작한다고 볼 수 있다.
1. 사용자가 웹사이트에 접근한다.
2. 서버는 랜더링 준비된 페이지를 보내준다.
3. 브라우저는 빠르게 HTML파일을 읽을 수 있어 화면은 렌더링 된 상태이지만,
아직 JS 파일을 읽지 않았기 때문에 사용자가 조작은 불가능하다.
4. 브라우저가 JS를 다운받고, 연결하고, 읽는다
5. 유저는 콘텐츠를 볼 수 있게되고 사용자와의 상호작용도 브라우저에 기록된다.
6. 브라우저가 JS 프레임워크를 실행한다
7. 기록된 상호작용도 실행되고 사용자가 조작도 할 수 있다.
이러한 프로세스를 갖고 있다보니, 아래와 같은 장단점을 가질 수 있다.
| 장점 | 단점 | |
| 초기 로딩 속도 | 서버에서 미리 렌더링하여 전송하므로, 첫 페이지 로딩이 빠름 | 페이지 전환 시마다 새로 요청해야 해서 UX가 끊길 수 있음 |
| SEO | 완성된 HTML을 제공하므로, 검색 엔진이 쉽게 크롤링 가능 | X |
| UI/UX | 초기 화면이 빠르게 표시되어 사용자 만족도 높음 | 페이지 이동 시 화면이 깜빡이며, 속도가 느려짐 |
| 서버 부하 | 클라이언트가 부담을 덜고, 서버에서 최적화된 HTML을 제공 | 요청마다 서버에서 렌더링을 수행해야 하므로, 트래픽이 많으면 서버 부하 증가 |
2) CSR(Client-Side-Rendering)
이것도 말 그대로 클라이언트에서 화면을 랜더링해서 보여주는 것이라고 보면 된다.
이건 SSR 과 다르게 HTML 파싱부터 JS 읽기까지 브라우저에서 하기 때문에 처음에 화면을 띄우는 데 시간이 좀 걸린다.
클라이언트 사이드 스크립트 언어이니,
React, Angular, Vue 와 같은 곳에서 사용합니다.
CSR은 아래와 같은 프로세스를 가진다고 보면 된다.
1. 클라이언트가 웹사이트에 접근
2. 서버에서는 빈 HTML 문서를 클라이언트에 전달
3. 클라이언트가 HTML 문서에 포함된 정적 리소스(CSS, 이미지 등), 자바스크립트 번들 파일을 다운로드한다.
4. 클라이언트에서 번들 자바스크립트 파일을 실행한다. 자바스크립트에 의해 페이지가 렌더링되며,
이 때 사용자는 렌더링된 페이지를 볼 수 있다.(아직 데이터를 안받아와서 placeholder만 표시)
5. 페이지 렌더링이 완료된 후, 서버에 API 날림
6. API에서 받아온 데이터로 상태 업데이트 하고 페이지를 리렌더링한다.
7. 페이지 인터렉션이 가능해진다.
이러한 프로세스를 갖고 있다보니, 아래와 같은 장단점을 가질 수 있다.
| 장점 | 단점 | |
| 초기 로딩 속도 | 서버에서 최소한의 HTML과 JS만 전송하므로 가벼움 | 초기 로딩 시 JS 번들이 커지면 속도가 느려질 수 있음 |
| SEO(검색 엔진 최적화) | SPA 프레임워크(React, Vue 등)에서 클라이언트에서 동작하는 JS로 페이지를 렌더링하므로, 검색 엔진이 바로 크롤링하기 어려움 | 별도로 SSR 또는 프리렌더링이 필요함 |
| UI/UX | 페이지 이동 시 추가 요청 없이 빠르게 렌더링 가능 (부드러운 네비게이션) | 초기 로딩 후, JS 실행이 끝나기 전까지 빈 화면이 보일 수 있음 |
| 서버 부하 |
API 응답을 클라이언트에서 캐싱하여 성능 최적화 가능 | 클라이언트가 모든 렌더링을 담당해야 하므로, 저사양 기기에서는 성능 저하 가능 |
4. 그래서 둘이 뭐가 다른건데?
간단히 비유하자면, 아래와 같이 볼 수 있지 않을까?
SPA(CSR) = 뷔페
• 처음에 접시(HTML)만 받고, 이후 음식(JavaScript & API)을 필요할 때마다 떠오면서 먹는다.
• 처음에는 가벼운데, 점점 많은 음식이 쌓여(초기 로딩 빠름, 이후 점점 무거워짐) 부담될 수도 있다.
MPA(SSR) = 코스요리
• 셰프(서버)가 음식을 한 접시씩(페이지) 준비해서 서빙한다.
• 매번 새로운 요리(페이지)가 제공되므로, 기다리는 시간이 있지만(새 페이지 로딩),
미리 정성껏 만들어 제공되기 때문에 처음부터 완성된 상태다.
서로를 비교도 해보자!
| CSR (Client-Side Rendering) | SSR (Server-Side Rendering) | |
| 렌더링 방식 | 브라우저에서 JS가 실행되어 화면을 렌더링 | 서버에서 HTML을 완성한 후 클라이언트에 전달 |
| 초기 로딩 속도 | JS가 다운로드 및 실행되어야 하므로 상대적으로 느림 | 서버에서 미리 렌더링해 주므로 초기 로딩이 빠름 |
| 페이지 전환 속도 |
JS가 미리 로드되므로 빠르고 부드러움 (싱글 페이지 네비게이션) | 새로운 페이지 요청마다 새 HTML을 받아야 해서 상대적으로 느림 |
| SEO (검색 최적화) |
기본적으로 크롤러가 JS를 실행하지 못해 SEO가 어려움 (프리렌더링 필요) | 완성된 HTML이 제공되므로 SEO 최적화에 유리 |
| 서버 부하 |
서버는 API 요청만 처리하고, 렌더링은 클라이언트에서 수행하여 서버 부하 적음 | 서버가 모든 요청마다 HTML을 렌더링하므로, 트래픽이 많으면 부하 증가 가능 |
| UI/UX | 첫 로딩이 오래 걸리지만, 이후 페이지 전환은 매우 빠름 | 첫 페이지 로딩이 빠르지만, 페이지 전환 시 깜빡임이 발생 |
5. SSR/CSR 과 MPA/SPA는 서로 같은 것인가?
결론은 아니다
개념을 공부하다 보면, 자연스럽게
SSR == MPA, CSR==SPA 같은 생각이 들 수 있지만
SSR과 CSR은 MPA와 SPA가 어플리케이션을 구성하기 위해 선택한 랜더링 방법이라고 이해해야 한다.
혹시라도 오해를 불러올까봐 포스팅 처음부터, 아래 사진을 먼저 보고 공부하자고 한것이다.
쉽게 말하자면 SPA는 처음에만 페이지를 받아오고 이후에는 받아오지 않는데
그럼에도 데이터가 수정되고 조회되게 하고 싶어서 CSR이란 “방식”을 채택한 것이고
반대로 MPA는 동적이지 않은 페이지를 상황에 맞게 클라이언트에 뿌려주기 때문에 SSR 방식을 채택한 것이다.
6. 그럼 SPA에는 SSR을 하지 못하고 MPA에는 CSR을 못 할까?
이런 의문점이 생길 수 있는데,
일단 그렇다고 말할 수 있다.
SPA와 MPA에서는 각각 SSR과 CSR을 하지 못하는데, 정확히 말하자면
SSR만으로는 SPA의 구현이 불가능하고 CSR만으론 MPA의 구현이 불가능 하다. (구현하려는 페이지가 여러 개라고 가정)
왜냐하면, SPA에서 데이터 부분을 전부 SSR을 해버린다면
사실상 그건 더는 SPA가 아니라 MPA가 되어버리는 것이다.
반대의 경우도 마찬가지겠죠?
다만, SPA에서 처음 로드하는 페이지만 SSR을 하고
그 이후는 CSR을 하면 SPA가 여전히 유지가 된다.
이 경우에는 “SPA에서 SSR이 가능하다” 라고 할 수 있겟지
SPA에서 SSR을 할 경우 장점 - SEO 단점을 보완가능하다.
그런데 이게 되게 별거 아닌거 같아 보이지만, 엄청 중요하다.
우리는 개발을 왜 하나? 고객이 존재하기 때문이다.
그런데 SEO가 나가리되면, 구글에 검색했는데 한 4페이지 정도에 가서야
우리 서비스를 확인할 수 있다고 생각해봐라 그게 의미가 있나?
이렇듯 "어떤 방식을 사용하는것이 정답이다." 라고 할 수 있는것은 아니고,
자신이 개발하려는 사이트의 특성에 맞게 알맞은 방법을 채택하여 사용하는 것이
가장 베스트이다. (근데 이건 뭐 모든 개발에 적용되는거 아닌가?)
레퍼런스
'CS > 네트워크' 카테고리의 다른 글
| 프록시에 대해서 알아보자 (Forward Proxy, Reverse Proxy) (0) | 2025.02.20 |
|---|