[React] 모던 리액트 딥다이브 4. 서버 사이드 렌더링 주요 정리

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

싱글 페이지 애플리케이션의 약자인 SPA는 렌더링과 라우팅에 필요한 대부분의 기능을 서버가 아닌 브라우저의 자바스크립트에 의존하는 방식을 의미한다. SPA는 말 그대로 하나의 페이지로 구현되며 새로운 페이지를 받아오지 않는다. 최초에 첫 페이지에서 데이터를 모두 불러온 이후에 페이지 전환 단계에서는 자바스크립트와 브러우저의 history.pushState와 history.replaceState로 이뤄지기 때문에 서버에서 HTML을 내려받지 않고 하나의 페이지에서 모든 작업을 처리한다.

 

SPA는 최초 첫 페이지를 받을 때는 SSR을 사용할 수 있으며 이후에는 CSR을 이용하여 렌더링을 진행해야 한다. 

1.1 SPA에서 페이지 전환이 일어나는 과정을 설명하시오

페이지 전환 시 새로운 HTML 페이지를 요청하는 것이 아니라 자바스크립트에서 다음 페이지의 렌더링에 필요한 정보만 HTTP 요청 등으로 가져온 다음, 그 결과를 바탕으로 <body/> 내부에 DOM을 추가, 수정, 삭제하는 방법으로 페이지가 전환된다.

1.2 SPA의 장점을 설명하시오

• 페이지 전환에 필요한 일부 영역만 다시 그릴 수 있기 때문에 훨씬 더 매끄러운 UI를 보여줄 수 있다.
• SPA에서는 단지 브라우저 내부에서 작동하는 자바스크립트만 잘 작성하면 웹 애플리케이션을 쉽게 만들 수 있다.
• 이에 프런트엔드 개발자들에게 좀 더 간편한 개발 경험을 제공했다.

1.3 JAM 스택이 무엇인지 설명하시오.

JAM스택이란 JavaScript, API, Markup 스택을 줄여 말하는 스택이다. React, Vue, Angular 등 프레임워크(React는 라이브러리이다)들의 등장으로 대부분의 작업을 자바스크립트에서 수행할 수 있게 되어, 프런트엔드는 자바스크립트와 마크업(HTML, CSS)을 미리 빌드해 두고 정적으로 사용자에게 제공하면 이후 작동은 모두 사용자의 클라이언트에서 실행되므로 서버 확장성 문제에 좀 더 자유로워질 수 있게 되었다.

 

+ 이전에는 서버 확장성 문제에 어려움이 있었나?

그렇다. 이전에는 LAMP 스택, (Linux, Apache, MySQL, PHP/Python)으로 웹 개발이 구성되어 있었는데, 이때만해도 자바스크립트에서 할 수 있는 일이 제한적이었기 때문에 대부분의 처리를 서버에서 해야만 했다. 따라서 웹 애플리케이션의 기능이 다양해지거나 사용자가 늘어나면 이와 동시에 서버도 확장해야 했기 때문에 클라우드의 개념이 부족했던 이때는 서버 확장성에 어려움을 겪었다.

 

+ JAM 스택과 Node.js의 고도화로 인기를 얻고 있는 스택은 무엇인가?

1. MEAN(MongoDB, Express.js, AngularJS, Node.js)
2. MERN(MongoDB, Express.js, React, Node.js)

2. 서버 사이드 렌더링이란?

서버 사이드 렌더링의 약어인 SSR은 서버에서 모든 렌더링 작업을 하고 사용자에게 화면을 제공하는 방식이다. 클라이언트 렌더링은 사용자 기기의 성능에 영향을 받지만 SSR은 서버에서 제공하기 때문에 비교적 안정적인 렌더링이 가능하다.

2.1 SSR의 장단점을 설명하시오

[장점]

• 최초 페이지 진입이 비교적 빠르다.
  • 일반적으로 서버에서 HTTP 요청을 수행하는 것이 더 빠르고, HTML을 그리는 작업도 서버에서 해당 HTML을 문자열로 미리 그려서 내려주는 것이 클라이언트에서 기존 HTML에 삽입하는 것보다 더 빠르다.
• 검색 엔진과 SNS 공유 등 메타데이터 제공이 쉽다.
  
  • SSR은 검색 엔진 최적화에 유용하다.
  • SPA에서는 검색엔진에게 HTML이나 각종 정보를 제공하기 위해 자바스크립트를 실행해야 하지만 로봇은 페이지를 보는 것이 아닌 페이지의 정적인 정보를 가져오는 것이 목적이라 자바스크립트를 다운로드하거나 실행할 필요가 없다. 
  • SSR에서는 검색 엔진에 제공할 정보를 서버에서 가공해 HTML응답으로 제공할 수 있기 때문에 검색 엔진 최적화에 매우 용이하다.
• 누적 레이아웃 이동이 적다.
  • 누적 레이아웃 이동이란 사용자에게 페이지를 보여준 이후에 뒤늦게 어떤 HTML 정보가 추가되거나 삭제되어 마치 화면이 덜컥거리는 것과 같은 부정적인 사용자 경험을 의미한다.
  • SPA에서는 페이지 콘텐츠가 API 요청에 의존하고, API 요청의 응답 속도가 제각각이며, 이를 적절히 처리해두지 않는다면 누적 레이아웃 이동 문제가 발생할 수 있다.
  • 하지만 SSR에서는 이러한 API 요청이 완전히 완료된 이후에 완성된 페이지를 사용자에게 제공하므로 이러한 문제에서 비교적 자유롭다.
• 사용자의 디바이스 성능에 비교적 자유롭다
  • 자바스크립트 리소스 실행의 부담을 서버에서 나눌 수 있으므로 사용자의 디바이스 성능으로부터 조금 더 자유로워질 수 있다.
  • 하지만 인터넷 속도가 느리다면 어떠한 방법론을 쓰든 느릴 것이고, 사용자 방문이 폭증해 서버에 부담이 증가하고 이를 위한 적절한 처리가 마련되어 있지 않다면 SSR도 충분히 느릴 수 있다.
• 보안에 좀 더 안전하다.
  • SSR은 인증 혹은 민감한 작업을 서버에서 수행하고 그 결과만 브라우저에 제공해 보안 위협을 피할 수 있다.

[단점]

• 소스코드를 작성할 때 항상 서버를 고려해야 한다.
  • 서버에서 실행될 가능성이 있는 코드는 window에 대한 접근을 최소화해야 하고, window 사용이 불가피하면 해당 코드가 서버 사이드에서 실행되지 않도록 처리해야 한다.
• 적절한 서버가 구축돼 있어야 한다.
  • SSR은 사용자의 요청을 받아 렌더링을 수행할 서버가 필요하지만 서버를 구축하는 것은 절대 쉬운 것이 아니다. 
  • 사용자의 요청에 따라 적절하게 대응할 수 있는 물리적인 가용량을 확보해야 하고, 때로는 예기치 않은 장애 상황에 대응할 수 있도록 복구 전략도 필요하다. 또한 요청을 분산시키고, 프로세스가 예기치 못하게 다운될 때를 대비해 PM2와 같은 프로세스 매니저의 도움도 필요하다.
• 서비스 지연에 따른 문제
  • SPA에서는 느린 작업을 수행중에 '로딩 중'과 같은 안내를 할 수 있지만 SSR에서 지연이 일어나면 사용자는 렌더링 작업이 끝날때까지 어떤 정보도 제공받을 수 없다. 그래서 규모가 커지고 작업이 복잡해지는 등 병목 현상이 심해지면 SSR은 더 안 좋은 사용자 경험을 제공할 수도 있다.

2.2 가장 뛰어난 SPA과 가장 뛰어난 MPA 중 어떤 것을 사용할 것인가?

가장 뛰어난 SPA를 사용할 것이다. MPA가 엄청난 최적화를 가미했다하더라도 가장 뛰어난 SPA라면 SPA가 가진 브라우저 API와 자바스크립트를 활용한 라우팅을 기반으로 한 매끄러운 라우팅보다 뛰어난 성능을 보여줄 수는 없을 것이다.

 

(가장 뛰어난 SPA는 Gmail을 예시로 들었음)

2.3 평균적인 SPA와 평균적인 MPA 중 어떤 것을 사용할 것인가?

평균적인 MPA를 사용할 것이다. 평균적인 SPA는 평균적인 MPA보다 느리다. 일반적인 SPA에서 렌더링과 라우팅에 최적화가 돼 있지 않다면 사용자 기기에 따라 성능이 들쑥날쑥하고, 적절한 성능 최적화도 돼 있지 않을 가능성이 높기 때문에 MPA 대비 성능이 아쉬울 가능성이 크다.

 

심지어 최근에는 MPA에서 발생하는 라우팅으로 인한 문제를 해결하기 위해 다양한 API가 브라우저에 추가되고 있다.

- 페인트 홀딩, back forwrad cache, Shared Element Transitions

2.4 현대의 SSR에 대해서 설명하시오.

최초 웹사이트 진입시 SSR로 서버에서 완성된 HTML을 제공하고 이후 라우팅에서는 서버에서 내려받은 자바스크립트를 바탕으로 SPA처럼 작동하는 방식을 많이 사용한다.

3. SSR을 위해 리액트 API

1. renderToString
   • 실제 브라우저가 그려야 할 HTML 결과를 만들어낸다.
   • 클라이언트에서 실행되지 않고 완성된 HTML을 서버에서 제공할 수 있기에 초기 렌더링에 뛰어난 성능을 보이며, 검색 엔진이나 SNS 공유를 위한 메타 정보도 renderToString에서 미리 준비한 채로 제공할 수 있다.
   • data-reactroot 속성이 있기 때문에 renderToStaticMarkup과 다르게 hydrate 함수에서 루트를 식별하는 기준점이 되어 useEffect와 같은 API를 실행할 수 있다.
2. renderToNodeStream
   • renderToString과 renderToStaticMarkup은 브라우저에서도 실행할 수 있지만 renderToNodeStream은 브라우저에서 사용하는 것이 완전히 불가능하다.
   • renderToNodeStream는 완전히 Node.js 환경에 의존하고 있다.
   • 결과물에서도 차이가 있는데 renderToNodeStream는 Node.js의 ReadableStream으로 반환한다.
   • 왜 사용할까? 
     • 스트림 : 큰 데이터를 다룰 때 데이터를 청크(chunk, 작은 단위)로 분할해 조금씩 가져오는 방식
     • 반환되는 결과물이 유뷰브 영상 등과 같이 클 때, 큰 크기의 데이터를 청크 단위로 분리해 순차적으로 처리할 수 있다. (유튜브도 사용자가 볼 수 있는 몇 초라도 먼저 다운로드되면 그 부분을 먼저 보여주고, 이후에 계속해서 영상을 다운로드한다.)
3. hydrate
   • hydrate는 생성된 HTML 콘텐츠에 자바스크립트 핸들러나 이벤트를 붙이는 역할을 한다.

4. Next.js에서 번들링과 컴파일을 빠르게 수행하기 위해 만들어진 옵션은 무엇인가?

swcMinify, SWC는 바벨에 비해 더 빠른 속도를 보여주기 때문에 특별한 이유가 없다면 쓰는 것을 권장한다.

4.1 Next.js의 라우팅 구조는 무엇인가?

/pages 디렉터리를 기초로 구성된다. 

각 페이지에 있는 default export로 내보낸 함수가 해당 페이지의 루트 컴포넌트가 된다. 

4.2 getServerSideProps의 유무의 차이를 설명하시오.

getServerSideProps가 없다면 서버에서 실행하지 않아도 되는 페이지로 처리한다. 따라서 getServerSideProps를 넣어주지 않는다면 빌드 시점에 미리 만들어도 되는 페이지로 간주해버려 window도 undefined가 아니다. 

4.3 Next.js에서 사용할 수 있는 CSS의 사용 방법에 대해 나열하시오.

1. 전역 스타일
2. 컴포넌트 레벨 CSS
3. SCSS와 SASS
4. CSS-in-JS
   • styled-jsx, styled-components, Emotion, Linaria 등