최신 웹 프레임워크는 서버에서 클라이언트로 사이트 또는 앱을 전송하는 방법에 대한 다양한 옵션을 제공합니다. 양쪽에서 HTML을 생성하거나 콘텐츠 전송 네트워크를 통해 고속으로 배포하기 위해 미리 렌더링할 수 있습니다.
사이트 또는 앱의 구조를 결정하는 방법은 몇 가지 다른 요소에 따라 달라집니다. 방문자가 사이트 또는 앱에 액세스하는 방법을 알고 있어야 합니다. 초기 로딩과 후속 탐색 중 어느 쪽의 로딩 속도가 더 중요한지 이해해야 합니다. 또한 사이트를 얼마나 자주 업데이트할지도 고려해야 합니다.
이러한 모든 요소를 염두에 두고 각 렌더링 패러다임의 장단점을 비교해야 합니다.
여러 가지 방법으로 웹사이트 렌더링하기
웹사이트 렌더링은 웹 사이트가 웹 브라우저에 표시되는 과정을 말합니다. 원시 데이터를 사용자 화면에서 형식이 지정된 HTML로 변환하는 프로세스에 접근하는 방법에는 여러 가지가 있습니다.
각 방법에는 장단점이 있으며, 각 방법의 장단점을 알면 사이트에 적합한 방법을 선택하는 데 도움이 될 수 있습니다.
CSR: 브라우저가 책임짐
CSR은 클라이언트 측 렌더링의 약자입니다. 앱이나 사이트를 클라이언트 측에서 렌더링할 때 서버는 작은 상용구 코드를 제외하고는 HTML을 거의 또는 전혀 전달하지 않습니다. 그런 다음 페이지 로드 이벤트 후 페이지에서 필요한 모든 데이터를 서버에 AJAX 요청을 통해 요청합니다.
앱이나 페이지가 클라이언트 측에서 렌더링될 때 서버는 클라이언트 브라우저에서 HTML을 생성하는 스크립트를 클라이언트에 전달합니다. 이를 통해 사용자가 상호 작용할 때 브라우저를 새로 고치지 않는 단일 페이지 애플리케이션을 사용할 수 있습니다.
CSR 앱은 탐색에서 빠르게 로드되는 경우가 많지만 초기에는 로드 속도가 느릴 수 있습니다. 속도는 렌더링을 위해 선택한 프레임워크와 사용하는 추가 라이브러리 및 애드온의 수에 따라 크게 달라집니다. 가장 널리 사용되는 최신 자바스크립트 프레임워크에는 CSR 옵션이 포함되어 있습니다.
완전 클라이언트 측 렌더링 페이지 및 앱은 URL을 사용하여 지정된 페이지로 직접 이동할 수 없는 문제가 있습니다. 클라이언트 측 렌더링 앱이 처음 시작될 때 입력한 URL에 관계없이 동일한 시작 지점으로 이동합니다.
SSR: 중앙 서버에서 렌더링
SSR은 서버 측 렌더링을 의미합니다. 이는 사이트가 템플릿을 기반으로 HTML을 생성하고 HTML, 스타일시트 및 스크립트를 혼합하여 클라이언트에 전송하는 훨씬 더 전통적인 형태의 웹 페이지 렌더링입니다. 가장 널리 사용되는 대부분의 백엔드 웹 프레임워크가 이 범주에 속합니다.
서버 사이드 렌더링 앱과 사이트는 초기 로딩이 더 빠른 경향이 있지만 탐색을 계속할 때마다 전체 새로 고침이 필요합니다. 즉, 시간이 더 오래 걸릴 뿐만 아니라 SSR을 사용하는 개발자는 세션 관리도 고려해야 합니다.
SSR로 생성된 사이트와 앱의 가장 큰 장점은 경로 탐색의 일관성입니다. 사용자가 지정된 경로를 입력하면 요청된 페이지로 바로 이동합니다. 일부 프레임워크는 앱 내에서 페이지 간 사용자 리디렉션을 관리하지만, 사용자가 처음에 원하는 페이지에 액세스하지 못할 수 있습니다.
많은 최신 프레임워크는 서버에서 렌더링한 페이지를 클라이언트에 제공하는 것으로 시작하는 혼합 솔루션을 제공합니다. 페이지가 로드되면 클라이언트 측 스크립트 이벤트가 페이지의 컨트롤에 첨부되는 하이드레이션이라는 이벤트가 발생합니다. 이때부터 클라이언트가 모든 탐색을 처리합니다.
혼합 다이내믹은 사용자가 단일 페이지 애플리케이션의 속도와 부드러움을 그대로 유지하면서 앱의 모든 페이지로 바로 이동할 수 있는 기능을 제공합니다. Next.js는 Nuxt.js 및 Sveltekit과 마찬가지로 여러 렌더링 패러다임을 제공합니다.
SSG: 최소화된 렌더링
SSG(정적 사이트 생성)는 클라이언트 또는 서버 측에서 HTML을 생성할 필요성을 우회합니다. 대신 SSG 스타일의 사이트와 앱은 필요한 모든 페이지를 미리 컴파일하고 그 결과를 CDN에 푸시하여 빠르게 전송합니다.
웹 페이지를 매우 빠르게 전송하는 매우 효과적인 방법입니다. 결과는 일반적으로 개별 페이지에 필요한 모든 HTML과 스타일시트가 포함된 간단한 번들로 컴파일됩니다. 이러한 번들은 사용자가 가능한 한 빨리 받을 수 있도록 최대한 압축된 상태로 유지됩니다.
SSG 사이트는 탐색할 때마다 새로고침이 필요하지만 로드 속도가 매우 빠른 경향이 있습니다. 하지만 정적 사이트의 가장 큰 단점은 유연성이 부족하다는 점입니다. 소셜 미디어 앱이나 복잡한 이커머스 플랫폼과 같이 매우 동적인 시스템에서는 SSG가 쉽게 처리할 수 있는 것보다 훨씬 더 많은 변경이 필요합니다.
또한 많은 정적 사이트는 변경할 때마다 독립적으로 컴파일해야 하므로 변경에 더 많은 오버헤드가 필요합니다. 따라서 재고가 빠르게 변동하는 디지털 상점이나 소셜 미디어 앱과 같이 빠르게 변화하는 사이트에는 SSG 스타일 렌더링이 적합하지 않습니다.
ISR: 모든 것을 담다
가장 복잡한 렌더링 유형이지만 가장 유익한 렌더링 유형인 ISR은 점진적 정적 재생(Incremental Static Regeneration)의 약자입니다. ISR은 정적으로 생성된 사이트의 속도와 확장성에 SSR 및 CSR 스타일 앱의 반응성을 결합한 기술입니다.
ISR 스타일 페이지 또는 앱에서 페이지가 요청되면 서버는 먼저 만료되지 않은 캐시된 페이지 버전이 있는지 확인합니다. 있는 경우 서버는 즉시 캐시된 페이지를 제공합니다.
페이지의 캐시된 버전이 존재하지 않거나 페이지 생성 후 충분한 시간이 경과한 경우 서버는 새 버전을 생성합니다. 이 새 버전은 클라이언트에 전달되어 나중에 사용할 수 있도록 캐시됩니다.
이 유형의 렌더링은 설정하기가 더 복잡하지만 SSG 사이트에서 일반적으로 발생하는 대부분의 문제를 자동화합니다. 이를 통해 앱은 추가 오버헤드를 자동화하면서 정적으로 생성된 앱의 속도와 안정성을 모두 제공할 수 있습니다.
몇몇 최신 프레임워크는 이미 ISR 스타일 렌더링 옵션을 제공합니다. 더 많은 프레임워크가 개발 과정에서 점진적 생성을 지원합니다. 대부분의 주요 프레임워크는 아직 지원하지 않는 경우 곧 ISR 렌더링을 지원할 예정입니다.
어떤 렌더링 유형이 가장 적합할까요?
웹사이트나 앱을 렌더링하는 방법에는 여러 가지가 있습니다. 이 네 가지 렌더링 유형에는 각각 여러 가지 변형이 있습니다. 모든 프로젝트에 이상적인 렌더링 유형은 없으며, 어떤 유형을 선택할지는 사이트 또는 앱에서 가장 중요한 것이 무엇인지에 따라 달라집니다.
프로젝트의 렌더링 패러다임을 선택할 때는 속도, 잠재 고객의 프로젝트 사용 방식, 사이트 변경 빈도 등을 고려하는 것이 중요합니다. 이러한 원칙은 사이트 또는 앱을 구성하는 가장 좋은 방법을 결정하는 데 도움이 되는 기본 원칙입니다.