개요

---

인터넷 역사가 이어지며 발전을 거듭할수록, 인터넷의 대명사인 웹 또한 거대해지고 있다. 초기 시절, 정적 데이터 기반의 단순 페이지만 보여주는데 그쳤던 웹은 이젠 대규모 비즈니스 로직을 무리없이 수행한다. 이러한 흐름에 따라, 웹의 기본 단위인 페이지의 비중도 따라 점점 커지고 있다.

우리는 하루에도 수십 개의 페이지를 향유한다. 사용자는 단순히 "페이지를 본다"는 활동을 하지만, 모든 일이 그렇듯이 그 이면에는 보이지 않는 여러 동작이 존재한다.

그 중 사용자에게 페이지를 보여주기 위해, 이 페이지를 렌더링. 즉, 그리는 로직에 대한 많은 고민이 이루어지게 된다. 페이지를 좀 더 빠르고, 효율적으로 보여줌은 우수한 페이지 UX로 이어지기 때문이다.

이러한 고민의 결과로, 현재 페이지의 렌더링 기법은 CSR, SSR, SSG 세 가지가 존재한다.

이 문서에서는 각 페이지 렌더링 기법에 대해 다뤄본다.

초기 렌더링 기법

---

옛날 얘기를 하다보면 수강신청을 위해 직접 말 그대로 진짜 학교에서 줄을 서서 대기를 했다는 얘기를 들어본 적이 있는가? 내가 태어나지도 않았던 시절. 컴퓨터는 지금처럼 흔하지 않았다고 한다.

때문에 인터넷 기술 또한 초기 단계에 머무를 수 밖에 없었고, 지금은 인지조차 하지 않는 당연한 기법조차 그 당시엔 상당히 과감하고 난해한 기술 취급을 받았을 것이다. 당연히 페이지의 개념 또한 지금과 매우 달라서, 웹 사이트에 단순히 "정보"를 표현하는 것조차 대단한 시절이였다.

때문에 그 옛날 웹 페이지의 렌더링 방식은 매우 단순했다. 그냥 호출한 URL의 파일을 전달하는 것 뿐이다.

물론, 현대에도 사이트의 용도에 따라 정적 렌더링을 사용하기도 한다. Nginx, Apache, IIS 등의 Web Server가 전형적인 정적 렌더링을 제공한다.

서비스할 폴더를 제공하면, 해당 폴더의 하위 파일을 URL 형태에 맞게 접근하는 방식이다. 하지만 이런 단순 라우팅은 페이지의 컨텐츠를 변경하기 매우 어렵다는 단점이 있었다.

AJAX(Asynchronous JavaScript And XML) 기술이 대두되기 이전까지, 모든 웹 페이지는 한 번 표시한 컨텐츠를 유동적으로 변경하지 못하고 같은 내용만을 주구장창 보여줄 뿐이다.

AJAX와 같은 비동기 기술이 나온 이래로, 이러한 문제를 해결하기 위한 다양한 렌더링 방법이 나오게 된다.

CSR(Client Side Rendering)

---

그 중 첫 번째로, 브라우저와 같은 클라이언트에서 페이지 렌더링을 수행하는 방식이 CSR이다.

CSR은 웹 서비스에서 사용하는 모든 JS, CSS를 index.js, index.css와 같이 하나의 파일로 번들링한다. 모든 페이지에서 이 번들링된 파일을 사용하여 페이지를 렌더링한다.

서버에 페이지를 요청하면, 서버는 아무것도 없는 빈 HTML과 번들링된 index.js, index.css를 제공한다. 브라우저가 응답을 받은 순간, 페이지에는 어떠한 내용도 표시되지 않는다. 이후 브라우저에서 JS와 CSS를 분석하여 사용자가 요청한 페이지를 렌더링한다.

모든 페이지가 동일한 파일을 요구하므로, JS나 CSS의 요청을 한 번만 수행하면 된다. 이미 모든 정보가 번들링된 파일에 선언되어 있으므로, 페이지를 렌더링할 때 필요한 모든 정보를 이미 가지고 있는 셈이다. 이러한 구조는 SPA(Single Page Application)을 구현하는데 매우 용이하다.

페이지의 원하는 부분만 새로운 정보로 즉시 렌더링할 수 있으며, 페이지 이동에 발생하는 깜빡임 현상(FOUC)을 효과적으로 제거할 수 있다. 또한 캐시 정책을 잘만 활용한다면, 페이지 로드 후엔 오프라인 환경에서도 서비스를 사용할 수 있다.

하지만, 번들링된 파일은 사이트의 모든 코드를 합친 통파일로, 용량이 매우 크다는 단점이 있다. 이러한 용량은 페이지 초기 호출의 지연으로 이어진다. 그 뿐만 아니라, SEO에도 매우 취약하다. CSR은 브라우저가 렌더링하기 이전엔 어떤 URL이든 렌더링 이전의 빈 HTML을 표시하기 때문이다. 즉, SEO 엔진은 CSR 페이지를 해석하기 매우 어렵다.

React를 통해 CSR을 제공할 수 있다.

• 👍 장점

  • 매우 적은 서버의 부담
  • 빠르고 자연스러운 페이지 렌더링

• 👎 단점

  • 비교적 큰 번들링 파일로 인한 초기 렌더링 지연
  • 취약한 SEO
  • 사용자 디바이스의 퍼포먼스에 영향을 받기 쉬움

• 🔎 용도

  • 소규모 프로젝트

SSR(Server Side Rendering)

---

SSR은 서버에서 페이지 렌더링을 수행하는 방식이다.

SSR은 각 URL마다 서버가 요청을 받아, 정의된 로직에 따라 페이지를 렌더링하여 응답하는 방식이다. 서버가 널널했던 CSR과 달리, SSR은 브라우저의 역할이 매우 널널하다. 브라우저는 서버에서 제공한 파일을 그대로 표시하고 스크립트를 수행하는 역할 정도가 끝이다.

각 페이지별로 꼭 필요한 최소한의 자원만을 활용할 수 있어, 초기 로딩이 CSR에 비해 상대적으로 빠르다. 브라우저가 응답을 받는 시점에 이미 기본적인 렌더링이 완료된 상태이므로, SEO에도 유리하다. CSR에서는 빈 껍데기밖에 볼 수 없었던 SEO 엔진이, SSR에선 렌더링된 온전한 페이지에 접근할 수 있기 때문이다.

하지만 SSR은 페이지 요청 시, 서버에 유의미한 부담을 요구한다. 그 뿐만 아니라, 단순 라우팅 서버만으로 구현이 가능한 CSR과 달리, SSR은 자신이 직접 컨트롤 가능한 서버를 요구한다. 즉, AWS든 본인 컴퓨터든 어떤 식으로든 자신이 직접 코딩 가능한 서버가 있어야만 한다. 소요시간 같은 수사적인 표현의 비용이 아니라, 사람이나 상황에 따라 진짜 비용이 든다.

Tomcat의 Servlet이나 Node.js의 Express을 통해 SSR을 제공할 수 있다.

• 👍 장점

  • 비교적 작은 번들링 파일로 인한 빠른 초기 렌더링 시간
  • SEO 친화적
  • 사용자 디바이스에 상관없이 비교적 일정한 퍼포먼스를 제공

• 👎 단점

  • Serverless 서비스 불가능
  • 경제적 비용 야기
  • 페이지 이동 시 지속적으로 서버의 부담 발생

• 🔎 용도

  • 대규모 비즈니스 서비스

SSG(Static Site Generator)

---

CSR과 SSR 모두 각자의 장단점이 있다. 하지만 컨텐츠가 변경될 일이 거의 없거나 예측 가능할 경우, 굳이 서버나 클라이언트에서 복잡하게 렌더링할 필요가 없을 것이다.

SSG는 이러한 발상에서 착안한 것으로, 각 페이지의 HTML, JS, CSS를 빌드함으로써 URL별 파일을 생성한다. 파일이 이미 정의되어 있으므로, 기능이 제한적이지만 매우 빠른 정적 렌더링을 사용할 수 있다.

SSG는 빌드 시 이미 렌더링된 페이지 자체를 아예 빌드해버린다. 이러한 특성으로 CSR, SSR 모두 SSG로 빌드하여 운용이 가능하다.

페이지가 얼마나 복잡하던 간에, 이미 적절히 빌드된 파일로 변환하기 때문에, 정적 렌더링이라는 단순한 기법을 사용해도 전혀 무리가 없다. 또한, 이미 생성된 파일을 전달하는 방식이기 때문에, SEO 엔진이 이를 분석하는데에 전혀 무리가 없다.

또한 SSG는 일부 케이스의 경우 CSR과 SSR의 장점 모두를 포함하는 완벽한 상위호환을 갖기도 한다.

그러나 컨텐츠가 변경될 때마다 빌드 작업을 계속 수행해줘야한다.

React의 경우 Next.js, Gatsby.js에서 SSG를 제공해준다. 지금 당신이 보고있는 이 블로그 또한 SSG로 빌드된 사이트다.

• 👍 장점

  • CSR, SSR의 장점 소화 가능
  • SEO 친화적

• 👎 단점

  • 빌드 작업의 높은 중요도

• 🔎 용도

  • 컨텐츠가 비교적 정적인 서비스 (블로그 등)

정리

---

사용자의 시각에서는 다 똑같은 사이트지만, 이면에는 여러 렌더링 방식이 있으며, 각 방식은 저마다의 장단점을 가진다.

이 세 렌더링 방식 중, 어느 것도 완벽한 상위 호환이 되지 않는다. 각 렌더링의 장단점을 이해하고, 본인이 만드려는 서비스에 적합한 렌더링 기법을 선택하자.