개발

[TIL] 렌더링 방식 정리

2024년 01월 23일 발행읽는 시간 15분

#들어가며

프론트엔드를 공부하다보면 나오는 여러가지 렌더링 방식이 나오는데 비슷하기도 하고 헷갈리기도 합니다. 이번 포스팅에서는 CSR, SSR, SSG, ISR 에 대해 알아보겠습니다. 각각의 동작을 이해하는 것은 효과적인 웹앱을 설계하고 개발하는 데 도움이 되겠죠? 각 렌더링 방식을 명확하게 정리하고, 주요 차이점이 뭔지 비교하면서 함께 이해해보도록 합시다!

#CSR(Client Side Rendering)

리액트는 기본적으로 CSR 전략을 사용합니다. 우리가 리액트를 배울 때 처음 배웠던 그 방식입니다.

html

<!DOCTYPE html>
<html>
  <body>
    <div id="root"></div>
    <script src="/static/js/bundle.js"></script>
  </body>
</html>

html

<!DOCTYPE html>
<html>
  <body>
    <div id="root"></div>
    <script src="/static/js/bundle.js"></script>
  </body>
</html>

CSR의 핵심은 클라이언트 측, 즉 사용자의 브라우저에서 자바스크립트 코드를 통해 동적으로 생성된다는 것입니다. HTML 코드에는 별 다른 내용이 없고, 대신 js 스크립트안에 모든 리액트, 기타 라이브러리, 개발 코드 등 웹을 구성하고 실행하는 모든 것이 들어있습니다.

예시로 든 HTML 코드에서 <div id="root"></div><div id="root"></div>는 웹이 렌더링될 컨테이너입니다. 사용자가 웹 페이지에 접속하면, 브라우저는 /static/js/bundle.js를 로드하고 실행합니다. 이 스크립트는 리액트 컴포넌트들을 root div에 렌더링하고, 이 과정에서 페이지의 전체적인 구조와 내용이 결정됩니다.

#CSR의 장단점

CSR의 장점

한 번 로딩되면, 빠른 UX 제공, 초기 로딩 후에는, 페이지 전환 및 상호작용이 빠르고 부드럽습니다.

CSR의 단점

긴 초기 로딩 시간(TTV, Time to View): 처음 페이지를 로드할 때 모든 JavaScript가 로드되고 실행될 때까지 사용자는 콘텐츠를 볼 수 없음, 이로 인해 FCP(First Contentful Paint)가 오래 걸릴 수 있음
자바스크립트 의존성: 브라우저의 옵션에서 JavaScript를 비활성화하면, 웹 페이지가 제대로 표시되지 않을 수 있음
SEO 문제: 검색 엔진은 JavaScript로 로드되는 콘텐츠를 인덱싱하는데 어려움을 겪을 수 있음 (SEO에 불리)
CDN 캐싱의 제한: 정적 콘텐츠에 비해 동적으로 생성되는 콘텐츠는 CDN을 통한 캐싱이 어려워, 성능 최적화에 한계가 있을 수 있음

#SSR(Server Side Rendering)

CSR을 이용한 싱글 페이지 어플리케이션이 자바스크립트를 이용해서 하나의 페이지에서 렌더링을 수행한다면, SSR은 텅빈 HTML이 아닌, 최초에 사용자에게 보여줄 페이지를 서버에서 렌더링해 빠르게 화면을 제공하는 방식을 말합니다. 클라이언트(브라우저)가 서버에 매번 데이터를 요청할 때 마다, 서버에서 새로운 화면(View)를 만들어 주는 방식입니다. 이 방식은 프리렌더링과 하이드레이션 과정을 포함하여, 초기 페이지 로딩 속도를 개선하고, 검색 엔진 최적화를 향상시키는 데 중점을 둡니다.

프리렌더링과 하이드레이션

프리렌더링(Pre-rendering): 서버에서 사용자에게 보여줄 페이지를 미리 렌더링하는 과정을 말함, 이로 인해 사용자는 서버에서 완성된 HTML 페이지를 받게 되며, 콘텐츠에 빠르게 접근할 수 있음
하이드레이션(Hydration): 서버에서 렌더링된 페이지가 클라이언트에 로드된 후, 클라이언트 측 JavaScript가 실행되어 페이지를 완전하게 만드는 과정, SSR의 정적인 페이지에 동적인 기능을 부여함

댄 아브라모브는 하이드레이션을 “하이드레이션은 '건조한' HTML에 상호작용과 이벤트 핸들러라는 '물'을 공급하는 것과 같습니다.” 라고 설명함

#SSR의 장단점

SSR의 장점

빠른 TTV(Time to View): 사용자가 서버에서 이미 렌더링된 페이지를 받기 때문에 초기 콘텐츠에 빠르게 접근 가능
JavaScript 의존성 감소: SSR은 JavaScript가 비활성화된 환경에서도 페이지 콘텐츠를 볼 수 있음
SEO 최적화: 검색 엔진은 서버에서 렌더링된 콘텐츠를 더 쉽게 크롤링하고 인덱싱할 수 있어, SEO에 유리
보안 강화: 서버에서 렌더링되므로 클라이언트 측보다 보안이 강화됨
실시간 데이터 사용: 최신 데이터를 서버에서 바로 렌더링할 수 있어, 실시간 데이터 표시가 가능
사용자별 맞춤 데이터 제공: 서버에서 사용자의 요청에 따라 개인화된 데이터를 제공할 수 있음

SSR의 단점

비교적 느린 페이지 상호작용: 초기 로딩은 빠르지만, 클라이언트 측 JavaScript가 로드되고 실행될 때까지 페이지의 전체 기능이 활성화되지 않을 수 있습니다.
서버 부하 증가: 모든 사용자 요청에 대해 서버에서 페이지를 새로 렌더링해야 하므로, 트래픽이 많은 경우 서버에 과부하가 걸릴 수 있습니다.
CDN 캐싱 제한: 동적으로 생성된 콘텐츠는 정적 콘텐츠에 비해 CDN을 통한 캐싱이 어려울 수 있습니다.

#SSG(Static Site Generation)

SSG는 빌드 시 페이지를 미리 정적 파일로 생성하는 방식을 의미합니다. 이 과정에서 서버는 HTML, CSS, JavaScript 파일을 생성하여 저장합니다. 사용자가 특정 페이지에 접속할 때, 이미 생성된 정적 파일이 빠르게 제공됩니다. 이 방식은 웹사이트의 로딩 시간을 단축하고, 서버 부하를 줄이는 데 효과적입니다.

#SSG의 장단점

SSG의 장점

빠른 로딩 속도: 미리 생성된 정적 파일을 제공하므로, 사용자는 페이지를 즉시 볼 수 있음
서버 부하 감소: 서버에서 페이지를 실시간으로(요청마다) 렌더링할 필요가 없으므로, 서버 부하가 감소
보안 강화: 정적 파일을 제공하기 때문에 보안 취약점이 적음
SEO 최적화: 정적 파일은 검색 엔진에 의해 쉽게 인덱싱될 수 있음
효율적인 캐싱: CDN을 통한 캐싱이 용이

SSG의 단점

실시간 업데이트 제한: 콘텐츠 업데이트를 위해서는 전체 사이트를 다시 빌드하고 배포해야함
동적 기능 제한: 정적 파일만 제공되므로, 동적인 사용자 상호작용에는 제한적일 수 있음
빌드 시간 증가: 페이지 수가 증가함에 따라 빌드 시간도 증가함

SSG는 이런 특성들 때문에 콘텐츠가 자주 변경되지 않는 곳에 많이 사용합니다. 예) 블로그, 개발 Docs, 소개 페이지 등

#ISR(Incremental Static Regeneration)

SSG는 빌드 시 한 번 렌더링이 됐다면, ISR은 SSG의 발전된 형태로, 페이지가 처음 요청될 때 생성되고, 설정된 주기마다 데이터의 최신 여부를 체크하여 필요에 따라 페이지를 새롭게 렌더링합니다. 사용자의 요청에 따라 페이지를 생성하고, 이후의 요청에는 캐시된 버전을 제공합니다. 이는 빌드 시 모든 페이지를 생성하지 않아도 된다는 의미입니다. 설정된 시간 간격(예: 60초)이 지나면, 다음 요청 시 페이지가 재생성되어 최신 상태를 유지합니다.

빠른 빌드: 예를 들어, 100,000개의 제품을 가진 전자상거래 스토어에서 각 제품 페이지를 생성하는 데 50ms가 걸린다고 가정합니다. ISR을 사용하지 않으면, 모든 페이지를 생성하는 데 거의 2시간이 소요됩니다. ISR을 사용하면, 가장 인기 있는 1,000개 제품만 빌드 시 생성합니다. 나머지 제품 페이지는 요청 시 생성되므로 빌드 시간이 대폭 줄어들어, 예를 들어 1분 빌드가 가능해집니다.
높은 캐시 적중률: 또 다른 방법으로, 사용자의 요청에 대비해 10,000개 제품을 빌드 시 생성할 수도 있습니다. 이렇게 하면 빌드 시간은 더 길어지지만(예: 8분 빌드), 사용자 요청에 대한 응답이 빨라집니다.

#ISR의 장단점

ISR의 장점

성능 최적화: 첫 요청 후 생성된 페이지를 캐시하므로, 빠른 로딩 시간과 개선된 사용자 경험을 제공합니다.
최신 데이터 반영: 주기적인 페이지 갱신으로 항상 최신 콘텐츠를 제공할 수 있습니다.
서버 부하 감소: 모든 요청에 대해 페이지를 새로 생성하지 않기 때문에 서버 부하가 줄어듭니다.
빌드 시간 단축: 초기 빌드 시 필요한 페이지만 생성하고 나머지는 요청 시 생성하기 때문에 빌드 시간이 크게 줄어듭니다.
확장성 및 유연성: 대규모 웹사이트에서도 효율적으로 관리할 수 있으며, 변화하는 요구사항에 쉽게 대응할 수 있습니다.

ISR의 단점

초기 요청 지연: 캐시되지 않은 페이지에 대한 첫 요청은 생성 시간이 필요하므로 약간의 지연이 발생할 수 있습니다.
데이터 일관성 문제: 설정된 갱신 주기에 따라 최신 데이터가 반영되기까지 지연될 수 있습니다.

#각 렌더링 방식 특성표

기술	렌더링 위치	초기 로딩 성능	SEO	실시간 데이터	보안
CSR	브라우저	느림 (모든 자바스크립트 로딩)	비교적 불리	가능	클라이언트 측 렌더링으로 인한 취약성
SSR	서버	빠름 (미리 렌더링된 페이지)	유리	가능	서버 측 렌더링으로 인한 강화
SSG	서버(빌드 시간)	매우 빠름 (미리 생성된 정적 파일)	매우 유리	불가능	..
ISR	요청 시 + 빌드 시간	빠름 (인기 있는 페이지 미리 생성 후 요청에 따라 생성)	유리 (설정에 따라 최적화 가능)	가능 (재생성 시 최신 데이터 반영)	..

#마치며

이번 포스팅에서는 다양한 웹 렌더링 기술들 - CSR, SSR, SSG, ISR에 대해 알아봤습니다. 각각의 기술이 가진 고유의 특성과 장단점을 비교하면서, 어떤 상황에 어떤 렌더링 방식을 선택해야 하는가에 대한 이해를 돕고자 했습니다. 글을 쭉 읽으면서 느끼셨겠지만 ***"완벽한 렌더링 솔루션은 없다."***고 할 수 있겠습니다. 프로젝트의 특성과 요구사항에 맞게 최적의 렌더링 방식을 선택하는 것이 중요할 것 같습니다.

#참고자료

A Complete Guide To Incremental Static Regeneration (ISR) With Next.Js

Understanding CSR, SSR, SSG, and ISR: A Next.js Perspective