전체적인 흐름으로 이해해보는 웹 렌더링의 발전과정
# 웹 렌더링 방식의 발전에 대해 알아볼까요?
2023년 12월 27일
개요
웹이 처음 등장한 이후, 웹 렌더링 방법론은 사용자의 경험을 개선하기 위해 지속적으로 발전해왔다. 해당 글에서는 단순히 CSR과 SSR의 장단점을 비교하는 것이 아닌, 각 기술이 기존의 문제점을 어떻게 보완하면서 등장하게 되었는지 전체적인 흐름을 이해하면서 그에 따른 기술 발전을 중심으로 웹 렌더링 방법론을 소개하고자 한다.
사용자 요청
사용자는 웹 브라우저의 주소창에 www.google.com과 같은 도메인을 입력하고 Enter 키를 누르면, 브라우저는 도메인을 IP 주소로 변환하기 위해 DNS 서버에 조회 요청을 보낸다.
"브라우저"는 사용자가 웹 페이지에 접근하기 위해 사용하는 소프트웨어 애플리케이션을 의미한다. 브라우저는 웹 페이지를 요청하고, 서버로부터 받은 데이터를 사용하여 페이지를 렌더링하는 역할을 한다. ex) Chrome, Safari
DNS 서버는 도메인 네임 시스템(DNS)으로 인터넷의 전화번호부와 같은 기능을 하며, 도메인 이름을 IP 주소로 변환하여 웹 브라우저에 입력한 도메인 이름에 해당하는 사이트의 IP 주소를 찾아주는 역할을 한다.
DNS 서버에 조회 요청을 보내기 전, 브라우저는 먼저 자신의 캐시에서 도메인의 IP 주소가 저장되어 있는지 확인한다. 만약 이전에 같은 도메인에 접근한 적이 있다면, 해당 IP 주소가 캐시에 저장되어 있으므로 이 경우, 브라우저는 DNS 조회를 생략하고 캐시된 IP 주소를 사용한다.
브라우저에 IP 주소 정보가 없으면, 컴퓨터의 호스트 파일을 확인하고, 그래도 IP 주소정보가 없다면, 운영 체제의 DNS 캐시를 확인하고 그래도 없다면, 그제서야 로컬 DNS 서버에 도메인의 IP 주소를 조회한다. 만약 로컬 DNS 서버도 IP 주소를 모르면, 다른 DNS 서버에 요청을 전달하며 재귀적으로 요청받은 IP주소를 찾게된다. DNS 서버가 최종적으로 도메인의 IP 주소를 반환하면, 이 IP 주소는 로컬 DNS 서버를 거쳐 브라우저에 전달된다.
호스트 파일은 도메인과 IP 주소를 수동으로 연결해 놓은 목록이라고 생각하면 된다
💡 DNS 서버에 조회 요청을 보내기 전, 확인작업을 전부 진행하는게, 로컬 DNS 서버에 도메인의 IP 주소 요청하는거보다 코스트가 적나? 생각이 든다. 그만큼 DNS에 IP 주소를 요청하는 작업이 무거운 작업인가보다.
브라우저는 반환된 IP 주소를 사용하여 웹 서버와 TCP 연결을 시도한다. 이 과정은 TCP 3-way 핸드셰이크로 진행되는데, 브라우저가 서버에 연결 요청을 보내고, 이 패킷은 연결을 시작하고자 하는 서버에 알려진다. 이후 서버가 연결 요청을 수락하고, 클라이언트에게 응답을 보내는데, 이 패킷은 서버가 연결 요청을 수락했음을 나타낸다. 클라이언트는 서버의 응답을 확인하고, ACK 패킷을 보내 연결을 완료한다. 이로써 클라이언트와 서버 간의 TCP 연결이 완료된다.
웹 서버는 사용자가 웹 페이지를 요청하는 대상 서버를 의미한다. 예를 들어, 사용자가 브라우저 주소 창에 "www.google.com"을 입력하면, "google.com" 도메인을 호스팅하는 서버가 웹 서버가 된다.
💡 TCP 3-way 핸드셰이킹 과정은 아래의 예시로 이해하면 편하다.
클라이언트: 연결 요청 (SYN)
- 클라이언트(사용자 A)가 친구(서버 B)에게 전화한다.
- A: "여보세요! 나 A야. 나랑 대화할 수 있어?"
서버: 연결 수락 (SYN-ACK)
- 친구 B가 전화를 받습니다.
- B: "여보세요, 어 A야 나 B야. 대화할 준비 됐어. 너도 준비됐어?"
클라이언트: 응답 (ACK)
- A가 다시 응답합니다.
- A: "좋아, B! 나도 준비됐어. 이제 이야기하자."
TCP 연결이 성공적으로 이루어지면, 브라우저는 웹 서버에 HTTP 또는 HTTPS 요청을 보낸다. HTTPS인 경우, 이 과정에서 SSL/TLS 핸드셰이크가 추가로 이루어진다. SSL/TLS는 암호화된 통신을 위한 작업이라고 생각하면 된다.
웹 서버는 브라우저의 요청을 처리하고,HTML, CSS, JavaScript 파일들이 포함된 문서를 응답으로 브라우저에 반환한다.
렌더링
렌더링(Rendering)
브라우저에서 유저가 최종으로 볼 화면을 만드는 것
드디어 HTML, CSS, JavaScript 파일들이 포함된 문서를 응답으로 받은 브라우저는 위 코드처럼 HTML 구조와 스타일 정보 및 자바스크립트 파일을 통해 유저가 최종으로 볼 화면을 만들기 시작한다.
웹 브라우저는 먼저 HTML 문서를 받아서 DOM(Document Object Model) 트리를 생성한다. DOM 트리는 웹 페이지의 구조를 나타내는 자료 구조를 의미한다. 동시에 CSS 파일도 분석하여 CSSOM(CSS Object Model) 트리를 생성하는데, CSSOM 트리는 웹 페이지의 스타일 정보를 담고 있다. 해당 두 트리는 하나의 랜더 트리로 결합되고, 이렇게 생성된 렌더 트리를 기반으로 브라우저는 웹페이지를 출력하게 된다.
렌더 트리가 생성된 후, 브라우저는 각 요소의 정확한 위치와 크기를 계산하는 레이아웃 과정을 수행한다. 해당 과정을 통해 요소들이 화면에 어떻게 배치될지 결정한 후 마지막으로, 브라우저는 화면에 요소들을 그리는 페인팅 과정을 수행된다. 해당 과정에서는 텍스트, 색상, 이미지 등이 실제로 화면에 렌더링된다.
이 때 자바스크립트에 의해 요소의 스타일이나 내용이 변경되면, 브라우저는 리플로우(레이아웃 재계산)와 리페인트(화면 재그리기) 과정을 거치는데, 해당 과정은 성능에 큰 영향을 미치므로, 가능한 한 최소화하는 것이 중요하다.
전통적인 HTML 렌더링
정적 HTML 페이지는 웹의 초기 형태로, 모든 콘텐츠가 미리 작성되어 있는 HTML 파일 형태로 제공되는 웹 페이지다. 전통적인 HTML 렌더링 방식은 웹 서버가 브라우저의 요청을 받으면, 해당 HTML 파일을 클라이언트(브라우저)로 전달하는 방식으로 작동한다.
웹 서버는 사용자가 요청하는 사이트의 HTML, CSS, JavaScript 파일 등 웹 페이지를 구성하는 리소스들이 저장된 곳이라고 생각하면 된다.
장점
정적 HTML 페이지는 고정된 콘텐츠를 제공한다. 서버에 한 번 업로드된 이후에는 변경되지 않으며, 이는 페이지가 사용자 동작에 따라 동적으로 변화하거나 실시간으로 업데이트 되지 않는다. 이 말은 즉슨 미리 렌더링된 파일을 단순히 전송만 하면 되기 때문에 로드 속도가 매우 빠르다. 서버는 클라이언트의 요청을 받는 즉시, 사전에 준비된 HTML 파일을 그대로 전송하면 되는것이다.
index.html
about.html
blog-post1.html
blog-post2.html
예를 들어 지금 내 블로그를 정적 HTML 페이지로 제작한다면, 위 코드처럼 각 페이지마다 html 파일을 작성하여, 서버에 올린 후 배포하면 될것이다.
정적 HTML 페이지는 제작 및 배포 과정이 매우 단순하다. 그냥 HTML 파일을 작성하고 이를 웹 서버에 배포하면 끝이다. 이러한 간단성 덕분에 정적 HTML 페이지는 개발 초기 단계나 소규모 프로젝트에 적합하다.
또한 정적 HTML 페이지는 검색 엔진 최적화(SEO)에도 매우 유리하다. 모든 페이지가 고정된 HTML 파일 형태로 제공되기 때문에 검색 엔진 크롤러가 해당 HTML 파일을 읽어내서 데이터를 쉽게 수집하고 인덱싱할 수 있다.
단점
정적 HTML 페이지는 콘텐츠가 고정되어 있어 사용자 맞춤형 콘텐츠 제공이 불가능하고, 사용자와 상호작용을 하면서 페이지 내용이 바뀌는 기능을 제공하기 어렵다. 예를들어 쇼핑 웹사이트에서 사용자가 로그인하면 개인 추천 상품을 보여주고 싶지만, 정적 HTML 페이지에서는 모든 사용자가 동일한 상품 목록을 보게 된다. 또한 사용자가 게시물에 좋아요를 누르거나 댓글을 달아도 동적 업데이트를 처리하지 못하기 때문에 페이지 내용이 실시간으로 바뀌는 기능을 제공하기 어렵다.
💡 조금 더 설명해보자면 정적 HTML 페이지는 한 번 작성된 후 서버에 업로드되면 그 내용이 변하지 않는다고 했는데, 이는 HTML 파일이 서버에 저장된 그대로 클라이언트에게 전달된다는 의미이고, 서버는 단순히 이 고정된 파일을 클라이언트에게 제공하는 역할만 하게 된다.
때문에 서버와 클라이언트 사이의 동적인 데이터 교환(데이터베이스 연동, 비동기 API작업)을 처리할 수 있는 능력이 부족해진다는것이다.
정적 HTML 페이지는 많은 페이지를 개별적으로 수정해야 하며, 수정할 페이지가 많을수록 시간이 많이 소요된다. 예를 들어, 웹 사이트의 공통적인 레이아웃을 변경하려고 해도, 각 HTML 파일에서는 변경된 레이아웃 코드를 일일이 수정해야 한다. 이러한 어려움은 대규모 웹 사이트나 자주 업데이트가 필요한 경우에는 더욱 더 힘든 작업일것이다.
❗ 이후 SSR, CSR에 대해 다루겠지만, 참고로 해당 방식은 SSR 방식이다. 사실 이 때 시절에는 CSR이란 개념이 등장하기 전이라서 HTTP기반 SSR 방식만이 존재했다. HTTP 요청이라는 다소 정해져있고, 무겁다고 생각될 수 있는 요청과 응답만으로 페이지 변화가 이뤄지기 때문에 느릴 수 밖에 없었다.
SPA의 등장
스마트폰으로 웹에 접속하는 모바일 웹 사용자의 수가 급격히 증가하면서 정적 HTML 페이지의 단점은 더욱 부각되었다. 그 당시 모바일 환경에서는 네트워크 속도나 기기 성능이 데스크톱에 비해 상당히 제한적이었고, 이는 페이지가 바뀔 때마다 전체 페이지를 다시 로드 해야 하는 과정에서 느린 로드 시간과 과도한 데이터 사용으로 사용자 경험을 저하시켰다.
때문에 웹 애플리케이션이 진화하면서 사용자 경험을 향상시키기 위해 SPA라는 개념이 등장했다. SPA, Single Page Application은 웹 애플리케이션 또는 웹사이트의 한 형태로, 단 하나의 HTML 페이지로 구성되어 있으며, 필요한 모든 JS, CSS를 처음 한 번에 로드하거나 필요한 시점에 비동기적으로 로드한다. 한 번 로드된 이후에는 추가적인 전체 페이지 리로드 없이 사용자와의 상호작용에 따라 필요한 콘텐츠만 동적으로 업데이트된다.
SPA는 또한 AJAX를 활용하여 클라이언트-서버 간의 비동기 통신을 가능하게 해준다. AJAX를 사용하여 페이지가 새로고침되지 않고도 서버로부터 데이터를 받을 수 있게 되었다.
💡 사용자가 웹에서 페이지를 요청 할 때 새로운 페이지 요청 대신 기존의 HTML 뼈대를 유지한 채 JavaScript로 새로운 콘텐츠를 요청한다. AJAX 호출을 통해 필요한 데이터만 서버에서 받아와 클라이언트(브라우저) 측에서 페이지를 업데이트하는것이다.이를 통해 페이지의 일부분이 동적으로 업데이트되고, 페이지 전환이 빠르고 부드러워 사용자 경험이 향상된다. 이와 같은 동적 로딩 방식 덕분에 SPA는 빠른 사용자 인터페이스를 제공하고, 서버 요청을 최소화가 가능하다.
장점
페이지 전환 시 전체 페이지를 다시 로드할 필요가 없기 때문에, 매우 빠른 사용자 경험을 제공하는데, AJAX를 통해 필요한 데이터만 비동기적으로 요청하여 서버 통신량을 줄일 수 있고, 이는 곧 서버의 부하를 줄이고 네트워크 자원을 효율적으로 사용하게 되어 모바일 환경에서 유리하다는 장점이 있다.
정적 HTML의 단점이었던 공통적인 레이아웃을 변경하려고 해도, 각 HTML 파일에서는 변경된 레이아웃 코드를 일일이 수정해야 한다는 단점을 컴포넌트 기반의 아키텍처를 통해 코드의 재사용성과 유지보수성을 높일 수 있다. 즉 기존에 모든 HTML에 작성되어 있던, 공통 레이아웃 코드를 하나의 컴포넌트로 만들어서 사용하기 때문에 변경사항이 생겨도 해당 컴포넌트화된 공통 레이아웃 코드만 바꿔주면 된다.
단점
SPA의 최대 단점 중 하나는 초기 로드 시 필요한 JavaScript, CSS 파일들이 많아지면 초기 로드 시간이 길어질 수 있다는 점이다. 사용자가 첫 번째로 페이지에 접속할 때, SPA는 전체 애플리케이션의 필요한 모든 리소스를 한 번에 로드하기 때문이다. 한 번 SPA가 로드되고 나면, 추가적인 페이지 전환이나 사용자 상호작용이 일어날 때는 전체 페이지를 다시 로드하지 않고 필요한 데이터만 비동기적으로 서버에서 가져와 DOM을 업데이트하여 전환이 빠르긴 하지만, 그래도 첫 페이지에 진입 시 사용자는 모든 리소스가 로드될 때 까지 빈화면만 보게 될것이다.
또한 첫 페이지 로드 이후 콘텐츠를 동적으로 로드하기 때문에, 검색 엔진 크롤러가 모든 콘텐츠를 수집하는 데 어려움을 겪을 수 있다. 정적 HTML 페이지에서는 각 페이지가 고정된 HTML로 구성되어 있기 때문에, 검색 엔진 크롤러가 쉽게 페이지의 콘텐츠를 수집할 수 있었다. SPA의 첫 페이지 로드는 최소한의 HTML과 함께 JavaScript 코드를 포함하고 이 JavaScript가 실행되어야만 실제 콘텐츠가 로드되는데, 검색 엔진 크롤러는 JavaScript를 실행하지 않기 때문에, 첫 페이지 로드에서 콘텐츠를 수집하지 못하는것이다. 물론 페이지가 변경될 때도 실제 HTML 페이지가 변경되는것이 아닌 JavaScript가 작동되어 컨텐츠가 바뀌기 때문에 역시나 콘텐츠를 수집하지 못할 것이다.
클라이언트사이드 렌더링(CSR)
클라이언트사이드 렌더링(CSR)은 웹 애플리케이션에서 대부분의 렌더링 작업을 클라이언트(브라우저) 측에서 수행하는 방식을 의미한다. 서버는 초기 HTML 파일과 필요한 JavaScript, CSS 파일을 클라이언트에 전달하고, 이후의 콘텐츠는 클라이언트 측에서 동적으로 렌더링된다.
사용자가 웹 애플리케이션에 처음 접속하면, 웹 서버는 최소한의 HTML 파일과 함께 필요한 JavaScript와 CSS 파일을 클라이언트로 전송한다. 클라이언트 브라우저는 전달받은 JavaScript 파일을 실행하여 페이지의 동작과 상호작용을 처리하고 AJAX를 통해 서버로부터 필요한 데이터를 비동기적으로 요청하고, 받아온 데이터를 통해 DOM을 동적으로 업데이트하여 화면을 구성한다
???
❗ SPA의 설명을 다시 적은거 아닌가 싶을 정도로 SPA의 개념과 매우 유사하다. 그렇다면, SPA는 곧 CSR인 것인가? 아니면 CSR은 곧 SPA인 것인가? 어떤 개념이 상위개념이고 SPA와 CSR은 어떤 차이를 가지고 있을까?
SPA와 CSR의 관계
결론적으로 말하면 단일 페이지 애플리케이션 (SPA)과 클라이언트사이드 렌더링 (CSR)은 밀접한 관계가 있지만, 서로 다르게 이해해야 한다.
차이점
포커스 영역 (어떤 목적을 가지고 있나)
- SPA는 애플리케이션의 아키텍처와 설계 방법에 초점을 맞추고 있다. 단일 HTML 페이지 후 필요한 자원을 비동기적으로 로드하여 사용자 경험을 최적화하는 것이 주된 목적이다.
💡 네이버 지도를 예시로 들면 사용자가 지도를 둘러 볼 때, 전체 페이지를 다시 로드하지 않고 필요한 지도 데이터만 서버에서 비동기적으로 받아와 화면을 업데이트되어 사용자는 매우 부드럽고 빠르게 지도를 둘러 볼 수 있다. 즉 말 그대로 필요한 자원을 비동기적으로 로드하여 사용자 경험을 최적화하는 것이 주된 목적이라는것이다.
- CSR은 렌더링의 과정, 즉 사용자 인터페이스를 어떻게 그릴 것인가를 설명한다. CSR은 주로 클라이언트 측에서 UI를 렌더링하는 방식에 중점을 두는데, CSR의 목적은 클라이언트 측에서 렌더링 작업을 수행하여 서버의 부하를 줄이는게 중점인것이다.
SPA에서는 첫 페이지만 받아오고 이후에 데이터의 수정, 조회를 클라이언트 측에서 수행하기 때문에, CSR이란 방식을 채택한 것뿐이다. 즉, 사용자가 웹 애플리케이션에 처음 접속할 때는 단 한 번의 HTML 파일을 서버에서 받아오고, 이후의 모든 데이터 수정과 페이지 업데이트는 클라이언트 측에서 JavaScript를 통해 동적으로 이루어지기 위해 CSR을 도입했다.
결론적으로, SPA와 CSR은 같지 않다. SPA는 주로 CSR을 채택하지만, SPA와 CSR은 서로 다른 개념이다. CSR은 SPA 구현 방법 중 하나로, SPA의 핵심적인 부분을 담당하는것뿐이다. SPA는 아키텍처로서의 개념이고, CSR은 렌더링 방식으로서의 개념으로 이 둘은 애초에 비교 대상이 아니다. SPA는 반드시 CSR만을 사용하지 않으며, 필요에 따라 SSR 또는 SSG와 같은 다른 기술을 병행할 수 있다.
SPA + CSR 조합의 문제점과 리액트의 등장
클라이언트 사이드 렌더링을 통해 구현된 SPA + SCR 조합은 모든 렌더링 작업을 클라이언트, 즉 사용자 브라우저에서 수행하게 하여 서버의 부담을 줄이고 인터랙티브한 웹 애플리케이션을 만들기에 유리했다.
❗ 하지만 그 말은 곧 클라이언트가 더 무거워진다는것을 의미했다.
위 사진을 보면 Client 측에서 Model, View, Controller 등 클라이언트 측에서 너무 많은 책임을 지게 되는 상황을 초래한다. 전통적인 모델-뷰-컨트롤러(MVC) 아키텍처에서는 데이터 모델, 사용자 인터페이스, 애플리케이션 로직 간의 상호작용이 복잡해지면서 관리가 어려워졌다.
이러한 문제점을 해결하고자 등장한 것이 바로 리액트다. 리액트는 페이스북에서 개발한 라이브러리로, 단순히 '뷰(View)'만을 관리하는 철학을 바탕으로 만들어졌다.
리액트는 '뷰(View)'를 컴포넌트 단위로 나누어 더욱 모듈화된 구조를 제공한다. 이는 전통적인 MVC 패턴에서의 '뷰'와 유사하지만, 훨씬 더 강력하고 유연하다. 또한 리액트 컴포넌트는 독립적으로 개발, 테스트, 유지보수할 수 있어 코드 재사용성을 높이고 개발 효율성을 크게 향상시켰다.
또한 리액트는 실제 DOM과는 별개로 가상 DOM을 이용한다. 상태가 변화할 때마다 실제 DOM 전체를 리렌더링하는 대신, 가상 DOM에서 먼저 변경된 부분을 감지하고 이를 바탕으로 최소한의 실제 DOM 업데이트를 수행한다.
이처럼 리액트는 컴포넌트 기반 아키텍처, 가상 DOM, 그리고 명확한 패턴 분리를 통해 뷰(View)에 집중함으로써 MVC 패턴에서 '뷰'와 '모델/컨트롤러'를 더 명확하게 분리할 수 있었고, SPA + CSR 조합에서 생길 수 있는 클라이언트측의 과도한 부담을 보완하고, 복잡한 웹 애플리케이션을 효율적으로 개발 및 유지보수할 수 있는 강력한 도구로 자리 잡게 되었다.
진보된 서버사이드 렌더링(SSR)의 등장
CSR은 클라이언트 측에서 대부분의 렌더링 작업을 수행하기 때문에 여전히 초기 페이지 로딩 성능이 좋지 않으며, SEO가 취약하다는 문제점이 남아있었다. 이러한 문제를 해결하기 위해 렌더링 및 HTML 응답을 위한 뷰(View)와 컨트롤러(Controller)가 서버에서 처리되는 좀 더 진보된 형태의 SSR이 탄생하게 되었다.
서버사이드 렌더링(SSR)은 웹 애플리케이션에서 초기 HTML 페이지를 서버에서 렌더링하여 클라이언트에 전송하는 방식을 의미한다.
정적 HTML에서의 SSR은 기본적으로 서버에서 모든 콘텐츠(HTML, CSS, JavaScript 포함)를 미리 렌더링하여 클라이언트에게 완전한 페이지를 제공했다. 즉, 클라이언트는 사전에 렌더링된 페이지 전체를 다운로드 받게 되었다.
하지만 현대의 서버사이드 렌더링(SSR)의 동작 원리는 클라이언트의 초기 요청을 서버가 수신하여, 필요한 데이터를 수집하고 이를 HTML 템플릿과 결합하여 서버에서 HTML 페이지를 생성한다.
생성된 HTML 페이지는 클라이언트로 전송되며, 클라이언트는 이를 즉시 렌더링하여 사용자에게 표시한다. 이후 클라이언트에서 JavaScript가 실행되면서 "하이드레이션" 과정을 통해 서버에서 제공된 HTML과 연결되고, 클라이언트 측에서의 인터랙티브한 기능이 활성화된다.
이후 사용자의 추가 데이터 요청 시에는 클라이언트사이드 렌더링(CSR)을 사용하는 방식을 사용하는데 이렇게 SSR, CSR을 적절히 조합함으로써 초기 로딩 성능과 SEO를 최적화하는 동시에, 인터랙티브한 사용자 경험을 제공할 수 있게 된다.
SSR을 사용하면 초기 HTML이 서버에서 완전히 렌더링되어 클라이언트에 전달되기 때문에, 브라우저는 이를 즉시 표시할 수 있어 초기 로딩 시간을 크게 줄일 수 있다.
장점
서버에서 미리 렌더링된 HTML을 클라이언트에 전달하기 때문에, 초기 로딩 속도가 빠르다. 사용자는 빠르게 첫 화면을 볼 수 있어 사용자 경험이 향상됨과 동시에, 검색 엔진 크롤러는 미리 렌더링된 HTML을 쉽게 인덱싱할 수 있기 때문에, CSR에 비해 SEO 성능이 뛰어나다.
단점
각 클라이언트 요청마다 서버가 HTML을 렌더링해야 하기 때문에, 서버에 부하가 증가할 수 있다. 이는 서버에서 렌더링을 수행하면서 추가적인 서버 자원을 소모하게 되므로 호스팅 비용 증가로 이어질 수 있으며, 특히 트래픽이 많은 애플리케이션의 경우 비용 문제가 발생할 수 있다.
❗ 다수의 사용자 요청이 발생할 때마다 서버는 매번 HTML을 동적으로 생성해야 하므로 서버에 높은 부하가 걸리게 되는데, 이는 특히 대규모 트래픽이 발생하는 상황에서 서버의 부하를 극대화시킬 수 있을것이다. 또한 서버가 HTML을 생성하는 시간이 요청 처리 시간에 포함되기 때문에, 서버의 성능에 따라 응답 시간이 달라질 수 있다는 한계를 가지고 있다.
SSG의 등장
SSG(정적 사이트 생성)는 이러한 SSR의 한계를 극복하고자 등장한 기술이다. SSG의 기본적인 원리는 빌드 타임에 모든 페이지를 미리 렌더링하여 정적 HTML 파일로 변환하고, 이를 서버나 콘텐츠 배포 네트워크(CDN)에 배포하는 것이다.
즉, 개발 단계에서 데이터베이스나 API 등 필요한 모든 소스에서 데이터를 가져와 각 페이지를 완전히 작성된 HTML 파일로 변환하는 과정을 포함하여 모든 페이지를 미리 렌더링한 후 이러한 파일들은 서버나 CDN에 저장한다.
사용자가 웹 페이지를 요청하게 되면 서버는 동적으로 페이지를 생성하는 대신, 미리 생성된 정적 HTML 파일을 제공하게 된다. 정적 파일은 서버의 파일 시스템 또는 CDN에 저장되어 있기 때문에 매우 빠르게 제공될 수 있다.또한 SSG를 사용하면 각 요청 시마다 서버가 HTML을 생성할 필요가 없으므로, 서버 자원을 절약할 수 있다. 이는 서버의 안정성을 향상시키고 미리 생성된 정적 파일만 제공하면 되므로 서버의 과부하를 방지할 수 있다.
