서버 사이드 렌더링에 대해 대략적으로 알고는 있었지만 자세히는 알지 못해 모던 리액트 딥다이브 책을 통해 해당 내용을 정리하고자 한다.

싱글 페이지 애플리케이션이란?

• 렌더링과 라우팅에 필요한 기능을 서버가 아닌 브라우저의 자바스크립트에 의존한다.
• 첫 페이지를 불러올 때 최초에 서버에서 최소한의 데이터를 불러온 이후부터는 이미 가지고 있는 자바스크립트 리소스와 브라우저 API를 기반으로 모든 작동이 이뤄진다.
• 따라서 첫 페이지를 불러온 후에는 서버에서 내려받을 필요없이 하나의 페이지에서 모든 작업을 처리하므로 싱글 페이지 애플리케이션이라고 한다.
• 최초에 로딩해야할 자바스크립트 리소스가 커지는 단점이 있다.
• 한번 로딩된 이후에는 서버를 거칠 일이 적어지기 때문에 사용자에게 훌륭한 UX/UI를 제공한다.

전통적인 방식의 애플리케이션과 싱글 페이지 애플리케이션의 작동 비교

• 과거 서버 사이드에서 작동하는 애플리케이션은 페이지 전환이 일어날 때마다 새롭게 페이지를 요청하고, HTML 페이지를 다운로드 해 파싱한다.
• 페이지를 처음부터 새로 그려야 해 페이지 전환 시 부자연스럽다. ex) 네이버 스포츠 뉴스
• 하지만 이런 페이지 전환을 자바스크립트로 한다면 최초에 모든 리소스를 다운로드 하고 페이지 전환에 필요한 일부 영역만 다시 그린다.
• 따라서 과거 서버 사이드 보다 훨씬 매끄럽게 화면 전환이 가능하다. ex) 지메일

싱글 페이지 렌더링 방식의 유행과 JAM 스택의 등장

• 과거 PHP나 JSP를 사용할 때는 대부분의 렌더링을 서버 사이드에서 이루어져 자바스크립트는 추가적인 경험을 위한 보조 수단에 불과했다.
• 자바스크립트가 점점 다양한 작업을 하면서 CommonJS와 AMD(Asynchronous Module Definition)가 등장하고 이에 힘입어 Backbone.js와 AngularJS, Knockout.js 등이 등장하며 MVx 프레임 워크를 구현하기 시작했다.
• 프레임 워크의 인기는 React, Vue, Angular의 시대를 맞이하게 하였고 자바스크립트의 역할이 크게 증가해 페이지의 렌더링에서부터 사용자의 인터렉션까지 모든 것을 자바스크립트 개발자가 담당하며 이를 모두 아우르는 싱글 페이지 렌더링이 인기를 입게 되었다.
• 기존의 웹 개발은 LAMP(Linux(운영체제), Apache(서버), MySQL(데이터베이스), PHP/Python(프레임워크) 등 으로 구성되어있었지만 자바스크립트의 프레임워크 등장으로 JAM(Javasciprt, API, Markup) 스택이 등장했다.
• 프론트엔드는 자바스크립트와 마크업(HTML, CSS)를 미리 빌드해두고 정적으로 사용자에게 제공하면 이후 작동은 사용자 클라이언트에서 실행되므로 서버 확장성에 좀 더 자유로워질 수 있다.
• JAM 스택의 인기와 Node.js의 고도화에 MEAN(MongoDB, Express.js, AngularJS, Node.js)나 MERN(MongoDB, Express.js, React, Node.js) 처럼 아예 API 서버 자체도 자바스크립트로 구현하는 구조가 인기를 끌었다.

새로운 패러다임의 웹서비스를 향한 요구

• 많은 양의 리소스가 자바스크립트로 넘어 오면서 자바스크립트의 코드의 크기도 방대해졌다.
• 이에 우려의 목소리가 나왔지만 사용자의 기기나 인터넷 속도가 크게 개선되어 괜찮을 것이라는 기대감이 존재했다.
• 하지만 이러한 발전과 달리 웹 서비스의 로딩 속도는 5년전과 큰 차이가 없거나 오히려 더 느렸다.
• 이에 개발자는 웹 서비스 환경에 한번 더 고민한다.

서버 사이드 렌더링이란?

• 싱글 페이지 애플리케이션은 사용자에게 제공되는 자바스크립트 번들에서 렌더링을 담당한다.
• 서버 사이드 렌더링은 렌더링에 필요한 작업을 모두 서버에서 수행한다.
• 클라이언트의 렌더링은 사용자 기기에 영향을 받지만 서버 사이드 렌더링은 서버에서 담당하기 때문에 비교적 안정적이다.

서버 사이드 렌더링의 장점

• 최초 페이지 진입이 비교적 빠르다.
  • 만약 보여줄 외부 API가 많다면 서버에서 HTTP 요청하는 것이 더 빠르고 HTML도 서버에서 문자열로 미리 그려 내주는 것이 SPA보다 빠르다.
• 검색 엔진과 SNS 공유 등 메타데이터 제공이 쉽다.
  • 검색 엔진이 사이트에서 필요한 정보를 가져가는 과정
    1. 검색 엔진 로봇이 페이지에 진입한다.
    2. 페이지가 HTML 정보를 제공해 로봇이 이 HTML을 다운로드 한다. 단, 다운로드만 하고 자바스크립트 코드는 실행하지 않는다.
    3. 다운로드한 HTML 페이지 내부의 오픈 그래프(Open Graph)나 메타(meta)태그 정보를 기반으로 페이지의 검색 정보를 가져오고 이를 바탕으로 검색 엔진에 저장한다.
  • 검색 엔진은 자바스크립트 코드를 실행하지 않기 때문에 SPA에서는 메타 정보를 제공하도록 조치를 취해야하지만 SSR에서는 검색 엔진에서 제공할 정보를 서버에서 가공해 HTML응답으로 제공하므로 검색 엔진 최적화에 대응하기 용이하다.
• 누적 레이아웃 이동이 적다.
  • SPA는 페이지 콘텐츠가 API 요청에 의존해 각각 응답이 제각각이므로 누적 레이아웃 이동 문제가 발생한다
  • SSR는 API 요청이 완료된 후에 완성된 페이지를 제공해 이러한 문제에 비교적 자유롭다.
• 사용자의 디바이스 성능에 비교적 자유롭다.
  • 자바스크립트 리소스는 사용자의 디바이스에서만 실행되므로 디바이스에 의존적이다.
  • SSR는 이런 부담을 서버에 나누어 비교적 자유롭다.
• 보안에 좀더 안전하다.
  • JAM 스택은 모든 활동이 브라우저에 노출된다.
  • API 호출, 인증 및 중요한 정보는 서버에서 수행하고 결과만 브라우저에 제공할 수 있어 좀더 안전하다.

서버 사이드 렌더링의 단점

• 소스코드를 작성할 때 항상 서버를 고려해야한다.

  • 만약 소스코드가 window를 사용하고 있고 서버에서 실행된다면 window is not defined라는 에러를 마주한다.

• 적절한 서버가 구축돼 있어야 한다.

  • SPA는 정적인 데이터인 자바스크립트와 HTML만 제공하면 되지만 SSR는 사용자의 요청을 받아 렌더링을 수행할 서버가 필요하다.

• 서비스 지연에 따른 문제

  • SPA는 무언가 느린 작업이 있다면 최초에 어떤 화면이라도 보여준 후 작업이 진행중임을 적절히 나타낼 수 있지만 SSR은 렌더링 작업이 끝나야 사용자에게 페이지를 보여주기 때문에 정보를 제공할 수 없다.

SPA와 SSR을 모두 알아야하는 이유

• 서버 사이드 렌더링 역시 만능이 아니다.
  • 작업을 서버에 미룬다 해서 성능문제가 해결되는 것은 아니다.
  • 잘못된 웹페이지 설계로 인해 서버와 클라이언트 두개로 관리 포인트가 늘어나는 역효과가 있을 수 있다.
  • 웹페이지 설계와 목적 우선순위에 따라 싱글 페이지 애플리케이션이 더 효율적일 수 있다.
• 싱글 페이지 애플리케이션과 서버 사이드 렌더링 애플리케이션
  • 가장 뛰어난 싱글 페이지 애플리케이션은 가장 뛰어난 멀티 페이지 애플리케이션(서버에서 모든 페이지를 각각 빌드하는 서버 사이드 렌더링 방식)보다 낫다.
    • gmail의 code splitting, 중요한 정보 먼저 로딩, 이미지는 게이른 로딩, 라우팅 발생 시 필요한 HTML 영역만 교체
• 평균적인 싱글 페이지 애플리케이션은 평균적인 멀티 페이지 애플리케이션보다 느리다.
  • 라우팅에 최적화되지 않은 SPA는 사용자 기기에 따라 성능이 다르고 적절한 성능 최적화를 수행하는 것은 매우 어렵다.
  • 멀티 페이지 애플리케이션에서 발생하는 라우팅 문제를 해결하기 위한 API가 브라우저에 추가되고 있어 동일한 노력을 한다면 SSR이 SPA보다 더 우위에 있을 수 있다.
• 결국 두 방법론이 완벽하지 않으므로 모두 상황에 따라 유효한 방법이라는 것을 이해해야한다.

현대의 서버사이드 렌더링

• 현대의 SSR은 LAMP의 방식과는 차이가 있다.
• LAMP 스택은 모든 페이지 빌드를 서버에서 렌더링해 초기 페이지 진입이 빠르지만 라우팅이 발생할 때도 서버에 의존해야하기 때문에 속도가 느리다.
• 요즘의 SSR은 최초 웹사이트 진입 시 SSR 방식으로 서버에서 HTML을 제공 받고 이후 라우팅에서는 서버에서 내려받은 자바스크립트를 바탕으로 SPA 처럼 작동한다. ex) Next.js, Remix

마치며

• 리액트 개발자라면 두가지 방법을 모두 숙지할 필요가 있으며 두가지 방법 모두 완벽하지 않으며 적절하게 하나를 선택해야한다고 생각한다. 이어서 다음 주제로는 직접 코드를 작성해 실습해보며 이해해볼 생각이다.

Reference

모던 리액트 Deep Dive - 04장 서버 사이드 렌더링