이번에는 Next.js 프로젝트를 진행하기 전에, Next.js와 React의 차이점을 공부하면서 *SSR(서버 사이드 렌더링)*과 *CSR(클라이언트 사이드 렌더링)*이 주요 키워드로 많이 언급되는 것을 알게 되었습니다.
이에 대해 학습한 내용을 정리하여 포스팅해보려고 합니다.
🏗️ SSR(Server-Side Rendering) – 서버 사이드 렌더링
SSR은 서버에서 HTML을 미리 렌더링 하여 클라이언트에 전달하는 방식입니다.
즉, 사용자가 요청을 보내면 서버에서 HTML을 생성한 후 브라우저로 전송하며, 이후 JavaScript가 실행되면서 인터랙티브 기능이 활성화됩니다.
위 그림 대로 정리를 하자면,
1. 사용자가 웹사이트에 요청을 보냅니다.
2. 서버는 렌더링이 가능한 HTML 파일을 만듭니다.
3. 브라우저는 빠르게 HTML을 읽을 수 있어 화면은 렌더링 되었지만, 조작은 불가능한 상태
4. 브라우저가 JS파일을 읽습니다.
5. 이제 유저는 콘텐츠를 볼수도 있고, 사용자의 조작도 기록이 됩니다.
6. 브라우저가 JS 프레임워크를 실행합니다.
7. 기록된 사용자 조작도 실행되고 페이지 상호작용도 가능해집니다.
✅ SSR 동작 과정 (요약)
1. 사용자가 웹사이트에 요청을 보냄
2. 서버가 해당 요청을 처리하고 HTML을 생성하여 클라이언트에 응답
3. 브라우저가 HTML을 렌더링 하고 JS 파일을 다운로드
4. JS가 실행되면 페이지의 인터랙티브 요소가 활성화됨
전체적으로 정리를 하자면, 서버사이드렌더링은 클라이언트가 서버에 매번 데이터를 요청하고 서버에서 처리하는 방식이라, 요청이 들어올 때마다 서버에서 새로운 화면을 만들어서 제공합니다. 이 뜻은 화면을 렌더링 하는 주체가 서버라는 뜻입니다.
이렇게 요청함으로써 많은 정보를 가진 웹이라면 성능적 문제가 생기게 되었습니다. 왜냐하면 서버에 정보를 요청할 때마다 새로고침을 하고, 페이지를 로딩할 때마다 서버로부터 리소스를 전달받아 화면에 렌더링 하는 방식이기 때문입니다.
🔹 SSR 장점
✅ 검색엔진 최적화(SEO)에 유리 – 완전한 HTML을 서버에서 제공하기 때문에 검색 엔진 크롤러가 쉽게 분석 가능
✅ 초기 페이지 로딩 속도 빠름 – 첫 번째 화면을 서버에서 렌더링 후 제공하기 때문에 사용자 경험이 향상됨
🔻 SSR 단점
❌ 페이지 이동 시 로딩 속도가 CSR보다 느림 – 새로운 페이지를 요청할 때마다 서버 렌더링을 다시 수행해야 함
❌ 서버 부하 증가 – 요청이 많을수록 서버의 부담이 커지고, 확장성이 떨어질 수 있음
❌ 클라이언트에서 JS가 실행되기 전까지 페이지 조작 불가능
⚡ CSR(Client-Side Rendering) – 클라이언트 사이드 렌더링
CSR은 초기에는 빈 HTML을 전달하고, 브라우저에서 JavaScript를 실행하여 화면을 렌더링하는 방식입니다.
즉, 클라이언트(브라우저)가 데이터를 받아 화면을 구성하며, React, Vue 등 SPA(Single Page Application) 프레임워크에서 주로 사용됩니다.
✅ CSR 동작 과정
1. 사용자가 웹사이트에 요청을 보냄
2. CDN이 빠르게 HTML과 JS 파일을 제공
3. 브라우저가 HTML 및 JS를 다운로드 (이 시점에서는 화면이 안 보일 수 있음)
4. JS가 실행되면서 API 요청을 보내고 데이터를 받아와 UI를 렌더링
5. 페이지가 완성되면 사용자 인터랙션 가능
정리하면, 클라이언트 사이드 렌더링은 클라이언트인 브라우저가 렌더링을 처리하는 방식입니다.
서버에서 필요한 데이터를 한 번에 받고 받은 데이터를 브라우저가 렌더링 하는 겁니다.
이는 화면 렌더링 방식인 SPA(Single Page Application) 이랑도 밀접한 연관이 있다고 합니다.
SPA는 CSR 방식이고, 처음 한번 페이지 전체를 로딩하고, 필요시 데이터만 바꿔서 화면을 그려줍니다.
최근 개발할 때 많이 사용되는 프레임워크인 React도 SPA입니다.
CSR은 CPU 성능 상승 + JS 표준화(리액트, 뷰, 앵귤러 프레임워크의 발전)와 함께 본격적으로 시작되었습니다.
CSR은 서버에서 데이터를 받아 모두 읽고 다시 화면에 페이지를 바꿔서 보여주는 것보다 훨씬 빠르게 화면을 그릴 수 있습니다.
이는 성능적으로도, 페이지를 새로 렌더링을 하지 않아, 서버자원을 덜 사용하며, 새로고침이 발생하지 않기 때문에, 화면이 바뀔 때도 화면 깜빡임이 없어 사용자 경험을 높일 수 있습니다.
장단점을 정리하자면
🔹 CSR 장점
✅ 사용자 경험(UX)이 향상됨 – 페이지 새로고침 없이 빠르게 화면을 변경할 수 있음
✅ 트래픽 감소 효과 – 변경된 데이터만 받아오기 때문에 네트워크 비용 절감
✅ 페이지 간 이동 속도 빠름 – 서버 요청 없이 프런트엔드에서 화면을 조작 가능
🔻 CSR 단점
❌ 초기 로딩 속도 느림 – JS가 실행되기 전까지 빈 HTML이 로드됨
❌ SEO에 불리 – 초기 HTML이 비어있어 검색 엔진이 콘텐츠를 제대로 읽지 못할 가능성 있음
그럼 SSR과 CSR은 언제 사용해야 할까요?
SSR은 네트워크가 느리거나, 검색엔진 최적화가 필요할 때, 페이지 상호작용이 별로 없을 때 사용을 합니다.
(블로그, 뉴스, 실시간 데이터)
CSR은 네트워크가 빠르고, 검색엔진 최적화가 필요 없고, 페이지 상호작용이 많이 필요할 때 사용합니다.
(대시보드, 웹앱, 로그인 필요 페이지)
결론
SSR과 CSR은 각각 장단점이 있으며, 서비스 특성에 따라 적절한 렌더링 방식을 선택하는 것이 중요합니다.
✅ SEO가 중요한 블로그, 뉴스 사이트 → SSR을 활용
✅ 대시보드, 웹앱처럼 빠른 화면 전환이 필요한 경우 → CSR을 활용
✅ SEO와 사용자 경험을 모두 고려해야 하는 경우 → Next.js의 Hybrid Rendering(SSR + CSR 조합) 사용
Next.js는 SSR, CSR뿐만 아니라 SSG(Static Site Generation), ISR(Incremental Static Regeneration)까지 지원하여 다양한 렌더링 방식의 장점을 활용할 수 있습니다.
👉 다음 포스팅에서는 Next.js의 다양한 렌더링 방식과 활용 사례를 다뤄보겠습니다!