[Web] CSR vs SSR vs SSG vs ISR 각 렌더링 방식 쉽게 알아보기

[Web] CSR vs SSR vs SSG vs ISR 각 렌더링 방식 살펴보기

📖 들어가며

먼저, 웹 렌더링(Web Rendering)이란 웹 페이지를 사용자에게 보여주는 과정을 의미합니다.

이 렌더링 방식에 따라서 로딩 속도, 검색 엔진 최적화(SEO), 사용자 경험 등이 달라집니다.

 

이 과정을 간단히 비유하자면, 레스토랑에서 요리를 주문한다고 가정해 보겠습니다.

 

레스토랑에서 손님(사용자)이 메뉴(웹 페이지)를 주문하고, 요리사(서버)가 요리(웹페이지)를 준비하고, 웨이터(브라우저)가 요리를 손님에게 가져다주는 과정과 비슷합니다.

 

여기서 요리사가 요리를 준비하는 과정이 바로 렌더링(Rendering)입니다.

 

이렇게 중요한 웹 렌더링에는 여러 가지 방식이 있습니다.

 

오늘 알아볼 렌더링 방식들은 아래와 같습니다.

• 클라이언트 사이드 렌더링(Client Side Rendering, CSR)
• 서버 사이드 렌더링(Server Side Rendering, SSR)
• 정적 사이트 생성(Static Site Generation, SSG)
• 증분 정적 재생성(Incremental Static Regeneration, ISR)

 

각 렌더링 방식은 각각의 장단점이 있으며, 웹사이트의 목적과 사용자의 요구에 따라 적합한 방식을 선택하게 됩니다.

이 방식들을 다양한 식사 방식(홈 쿠킹, 레스토랑, 패스트푸드) 중 상황에 맞는 방식을 선택한 것과 같다고 보면 됩니다.

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

CSR 동작 과정

CSR(Client Side Rendering)은 웹 브라우저에서 JavaScript를 사용하여 웹페이지를 렌더링 하는 방식입니다.

즉, 사용자의 브라우저가 서버로부터 데이터를 받아와서 웹 페이지를 직접 생성합니다.

동작과정

1. 사용자가 웹사이트에 접속하면 서버는 빈 HTML과 JavaScript 파일을 보냅니다.
2. 브라우저가 JavaScript를 로드하고 실행합니다.
3. JavaScript가 동적으로 HTML을 생성하고, 이를 브라우저에 표시합니다.
4. 추가 페이지 요청 시, 전체 페이지를 다시 로드하는 대신 필요한 데이터만 서버에서 받아와서 해당 부분만 업데이트합니다.

비유하자면, CSR은 서버로부터 빈 접시(빈 HTML)와 요리 재료(JS)를 받고, 요리(렌더링)를 직접 하는 방식입니다.

 

마치 가정에서 직접 요리를 하는 홈 쿠킹과 비슷합니다.

자유롭게 요리를 할 수 있지만, 요리 실력(브라우저 성능)에 따라 결과가 달라질 수 있습니다.

 

즉, 브라우저 성능이 좋으면 웹 페이지의 렌더링 속도도 빠르고 사용자 경험도 좋아집니다.

하지만 브라우저 성능이 낮거나, JavaScript를 지원하지 않는 경우에는 웹 페이지의 렌더링 속도가 느려지거나, 웹 페이지가 제대로 표시되지 않을 수 있습니다.

요리 실력이 낮으면 음식의 맛이 떨어지는 것과 비슷한 맥락입니다.

장점

• 빠른 인터랙션 제공: 초기 로딩 후, 필요한 데이터만 서버에서 가져와 동적으로 페이지를 업데이트하기 때문에 추가 페이지 로딩이 없습니다. 이로 인해 사용자와의 인터랙션이 빠르게 이루어집니다.
• 서버 부하 감소: 전체 페이지를 매번 새로 렌더링 하지 않고, 변화가 있는 부분만 업데이트하므로 서버에 부담을 덜어줍니다.

단점

• 초기 로딩 속도 느림: 브라우저가 JavaScript를 로드하고 실행하는 과정이 필요하므로, 이 과정으로 인해 초기 로딩 속도가 느릴 수 있습니다.
• SEO 취약: 브라우저가 JavaScript를 실행하여 동적으로 만드는데, 이 과정이 실행되기 전에는 빈 HTML이 먼저 화면에 보이게 됩니다. 이 때문에 웹 크롤러가 페이지의 내용을 제대로 인식하지 못하여, 검색 엔진 최적화(SEO)에 취약할 수 있습니다.

적합한 상황

• 사용자와의 상호작용이 많은 웹사이트에 적합합니다.
• 예를 들어, 대시보드, 어드민 페이지와 같은 곳에서 사용자의 입력에 따라 화면이 동적으로 변하는 경우와 SEO가 크게 중요하지 않은 경우에 활용할 수 있습니다.

서버 사이드 렌더링 (SSR)

SSR 동작 과정

SSR(Server Side Rendering)은 이름에서도 알 수 있듯이 서버에서 HTML을 완성하여 브라우저로 보내는 방식입니다.

동작 과정

1. 사용자가 웹사이트에 접속하면 서버에서 해당 페이지에 필요한 HTML을 생성합니다.
2. 서버는 생성된 HTML을 브라우저로 보냅니다.
3. 브라우저는 받은 HTML을 표시합니다.
4. 추가 페이지 요청 시, 해당 페이지에 대한 HTML을 다시 서버에서 생성하여 보냅니다.

비유하자면, SSR은 서버에서 요리(웹페이지 렌더링)를 완성시킨 후 접시에 담아서(완성된 HTML) 손님(사용자)에게 제공하는 방식입니다.

레스토랑에서 요리사가 완성된 요리를 손님에게 제공하는 것과 비슷합니다.

장점

• 빠른 초기 페이지 로딩: 서버에서 완성된 HTML을 브라우저로 보내주기 때문에, 사용자는 빠르게 완성된 페이지를 볼 수 있습니다.
• 검색 엔진 최적화(SEO)에 유리: 완성된 HTML을 제공하므로, 검색 엔진이 콘텐츠를 쉽게 인식하고 인덱싱할 수 있습니다.

단점

• 서버 부하 증가: 사용자의 각 요청에 대해 서버에서 렌더링을 해야 하므로, 서버 부하가 커질 수 있습니다.

적합한 상황

• 동적 콘텐츠가 많은 웹사이트에 적합합니다.
• 사용자의 요청에 따라 콘텐츠가 실시간으로 변경되어야 하는 경우, 서버에서 렌더링을 통해 항상 최신 상태의 웹 페이지를 제공할 수 있습니다.
• 예를 들어, 사용자 맞춤형 콘텐츠를 제공하는 웹사이트, 주식 정보와 같이 실시간으로 변경되는 데이터를 다루는 웹사이트 등에서 사용할 수 있습니다.

정적 사이트 생성 (SSG)

SSG 동작 과정

SSG(Static Site Generation)는 빌드 시에 모든 페이지를 HTML로 미리 생성하는 방식입니다.

동작 과정

• 빌드 시에 서버는 모든 가능한 요청에 대한 HTML을 미리 생성합니다.
• 사용자가 웹사이트에 접속하면, 서버는 미리 생성해 둔 HTML을 보냅니다.
• 브라우저는 받은 HTML을 표시합니다.
• 추가 페이지 요청 시, 미리 생성해 둔 해당 페이지의 HTML을 보냅니다.

비유하자면, 미리 요리(웹페이지 렌더링)를 완성시켜 놓고, 동일한 요리를 계속 제공하는 방식입니다.

이는 패스트푸드 체인점에서 미리 만들어진 햄버거를 판매하는 것과 비슷합니다.

빠르게 요리를 제공할 수 있지만, 개인화된 요리 제공이 어렵다는 단점이 있습니다.

장점

• 빠른 로딩 속도: 모든 페이지가 빌드 시에 미리 생성되므로, 사용자가 요청 시에는 빠른 로딩 속도를 제공합니다.
• 서버 부하 감소: 미리 생성된 HTML만 제공하므로, 서버 부하가 적습니다.

단점

• 데이터 변경에 불편: 사이트의 데이터가 변경될 때마다 전체 사이트를 다시 빌드해야 합니다.

적합한 상황

• 내용이 자주 변경되지 않은 웹사이트에 적합합니다.
• 예를 들어, 회사 소개, 제품 소개, FAQ 등과 같은 정보를 제공하는 사이트나, 개인 블로그와 같이 콘텐츠가 일정 시간 동안 고정되는 경우 SSG를 사용할 수 있습니다.

증분 정적 재생성 (ISR)

ISR 동작 과정

SSG와 SSR의 단점을 보완하고 장점을 결합한 Next.js 프레임워크에서 도입한 렌더링 방식입니다.

빌드 시점에 페이지를 미리 생성하면서도 특정 시간 간격으로 페이지를 재생성하여 업데이트된 데이터를 반영할 수 있게 합니다.

동작 과정

1. 빌드 시점: 빌드 시점에 웹 페이지를 정적으로 생성합니다. 이때, Next.js에서는 getStaticProps와 revalidate 옵션을 이용하여 페이지를 어떻게 생성하고, 언제 생성할지를 설정할 수 있습니다.
2. 사용자 접속 시: 웹 사이트에 접속하면 미리 생성된 HTML을 보냅니다.
3. 페이지 표시: 브라우저는 받은 HTML을 표시합니다.
4. 새로운 요청 및 페이지 재생성: 새로운 사용자의 요청이 들어왔을 때, revalidate 옵션에 설정된 시간이 경과하면, 해당 페이지를 서버에서 재생성합니다. 이때, 새로운 사용자는 이전 페이지를 보게 됩니다. 이유는 설정된 시간이 경과되어도 새로운 요청이 없으면 재생성하지 않기 때문입니다. 새로운 요청이 있을 때에만 페이지가 재생성되며, 재생성 중에는 이전의 페이지가 계속해서 보이게 됩니다.

비유하자면, ISR은 필요에 따라 요리(웹페이지 렌더링)를 새로 만들 거나, 미리 만들어둔 요리를 제공하는 방식입니다.

이는 레스토랑과 패스트푸드 체인점의 중간 형태로, 대부분의 손님에게는 미리 만들어진 요리를 제공하되, 특별한 요구가 있을 경우 새로운 요리를 만들어 제공합니다.

장점

• 빠른 로딩 속도: 페이지가 미리 생성되어 있으므로, 즉시 응답할 수 있습니다.
• 데이터 실시간 반영: 정해진 시간 간격으로 새로운 요청이 들어오면 페이지를 재생성하므로, 데이터의 변경을 반영할 수 있습니다.
• 서버 부하 감소: 모든 요청에 대해 실시간으로 페이지를 생성하지 않으므로, 서버 부하를 줄일 수 있습니다.

단점

• 구현 복잡성: 각 페이지의 상태를 관리해야 하므로, 구현이 복잡할 수 있습니다.
• 재생성 시간: 페이지의 재생성에는 시간이 소요됩니다. 따라서 매우 빈번하게 변경되는 데이터는 반영하기 어려울 수 있습니다.

적합한 상황

• 일부 페이지는 자주 업데이트되고, 다른 일부 페이지는 그렇지 않은 경우에 사용할 수 있습니다.
• 예를 들어, 쇼핑 사이트에서는 일부 상품 정보는 자주 업데이트 되지만, 회사 소개나 이용 약관 등의 페이지 등 그렇지 않은 경우를 뜻합니다.

각 렌더링 방식 비교 정리 표

렌더링 방식	SEO	초기 로딩 시간	서버 부하	데이터 가져오기	적합한 사례
SSR	높음	보통	보통	서버	SEO 최적화, 콘텐츠 중심
CSR	낮음	초기에는 느림, 이후에는 빠름	낮음	클라이언트	동적 콘텐츠가 많음
ISR	높음	보통	낮음	하이브리드	자주 업데이트 되는 데이터
SSG	높음	매우 빠름	매우 낮음	빌드 시점	포트폴리오, 개인 블로그

 

📕 마무리

웹 렌더링 방식 선택은 웹사이트의 성능과 사용자 경험에 중요한 영향을 미칩니다.

즉, 서비스의 요구 사항에 맞게 각 특징을 잘 분석해서 적용하는 것이 중요하다고 생각합니다.

 

참고 문헌:

https://www.educative.io/answers/ssr-vs-csr-vs-isr-vs-ssg

https://youtu.be/khcRPut9DMA?si=fTleSSR4S8fOse8u

https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regeneration