[모던 리액트 Deep Dive] 4장 서버 사이드 렌더링

4.1 서버 사이드 렌더링이란?

4.1.1 싱글 페이지 애플리케이션의 세상

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

렌더링과 라우팅에 필요한 대부분의 기능을 서버가 아닌 브라우저의 자바스크립트에 의존하는 방식을 의미한다.

최초에 첫 페이지에서 데이터를 모두 불러온 이후에는 페이지 전환을 위한 모든 작업이 자바스크립트와 브라우저의 history.pushState와 history.replaceState로 이뤄지기 때문에 페이지를 불러온 이후에는 서버에서 HTML을 내려받지 않고 하나의 페이지에서 모든 작업을 처리하므로 싱글 페이지 애플리케이션이라고한다.

실제로 소스 보기로 HTML 코드를 봤을 때는 <body/> 내부에 아무런 내용이 없다. 이는 사이트 렌더링에 필요한 <body/> 내부의 내용을 모두 자바스크립트 코드로 삽입한 이후에 렌더링하기 때문이다. 또 페이지 전환 시에도 새로운 HTML 페이지를 요청하는 게 아닌 자바스크립트에서 다음 페이지의 렌더링에 필요한 정보만 HTTP 요청 중으로 가져온 다음, 그 결과를 바탕으로 <body/> 내부에 DOM을 추가, 수정, 삭제하는 방법으로 페이지가 전환된다. 즉, 최초에 서버에서 최소한의 데이터를 불러온 이후부터는 이미 가지고 있는 자바스크립트 리소스와 브라우저 API를 기반으로 모든 작동이 이뤄진다. 이러한 작동 방식은 최초에 로딩해야 할 자바스크립트 리소스가 커지는 단점이 있지만 한번 로딩된 이후에는 서버를 거쳐 필요한 리소스를 받아올 일이 적어지기 때문에 사용자에게 훌륭한 UI/UX를 제공한다는 장점이 있다.

전통적인 방식(ex. 네이버)의 애플리케이션과 싱글 페이지 애플리케이션(ex.Gmail)의 작동 비교

전통적인 방식의 페이지 전환은 발생할 때마다 새롭게 페이지를 요청하고, HTML 페이지를 다운로드해 파싱하는 작업을 거친다. 그래서 페이지 전환 시 처음부터 다시 다운로드 받고 렌더링을 거치기 때문에 브라우저 환경이 빠르지 않으면 흰 화면이 노출될 수 있다.

하지만 이를 모두 자바스크립트로 한다면 최초에 한번 모든 리소스를 다운로드하고 이후 페이지 전환 시 추가로 리소스를 다운로드할 필요가 없다. 경우에 따라 페이지 전체를 새로 렌더링하는 것이 아닌 페이지 전환에 필요한 일부 영약만 다시 그려서 매끄러운 UI를 보여줄 수 있다.

싱글 페이지 애플리케이션은 최초에 한 번 다소간의 로딩이 끝난 이후에는 페이지 전환이 모두 자바스크립트로 일어난다. Gmail로 볼 때, 이메일 목록에서 이메일 메시지를 클릭하면 주소는 변경되지만 목록만 특정 메일로 매끄럽게 전환된다.

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

과거 PHP나 JSP(JavaServer Pages)를 기반으로 대부분의 웹 애플리케이션이 만들어졌을 때는 거의 대부분의 렌더링이 서버 사이드에서 이뤄졌다. 페이지를 요청하면 서버에서 완성된 HTML을 내려받고， 또 페이지 이동이 있으면 새로운 페이지를 서버에서 내려받는 방식이었다. 여기서 자바스크립트는 어디까지나 사용자에게 추가적인 경힘을주기 위한 보조적인 수단으로 사용됐다.

그러나 자바스크립트가 서서히 다양한 작업을 수행하게 되면서 자바스크립트를 모듈화하는 방안이 점차 논의되기 시작됐고 그에 따라 등장한 것이 CommonJS와 AMD(Asynchronous Module Definition)다.

이후 자바스크립트에서도 어느 정도 서버에서만 할 수 있는 복잡한 작업을 할 수 있게 됐으며 점점 자바스크립트의 역할과 규모가 커져갔다.

기존의 웹 개발은 LAMP 스택, 즉 Linux(운영체제), Apache(서버), MySQL(데이터베이스), PHP.Python 등(웹 프레임워크)으로 구성돼 있다. 과거에는 자바스크립트에서 할 수 있는 일이 제한적이었기 때문에 대부분 서버에서 처리해야 했다.

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

이러한 JAM 스택의 인기와 Node .js 의 고도화에 힘입어 MEAN(MongoDB, Express.js, AngulalJS, Node.js)이나 MERN(MongoDB, Express.js, React, Node.js) 스택처럼 아예 API 서버 자체도 자바스크립트로 구현하는 구조가 인기를 끌기 시작했다.

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

과거의 웹과 현재의 웹의 기능을 비교하면 정말 천지차이다. 그럼에도 중요한 사실 중 하나는 사용자의 기기와 인터넷 속도 등 웹 전반을 이루는 환경이 크게 개선됐음에도 실제 사용자들이 느끼는 웹 애플리케이션의 로딩 속도는 5년 전이나 지금이나 크게 차이가 없거나 오히려 더 느리다는 것이다.

개발자들은 제품의 웹 서비스 환경에 대해 한번 더 고민할 때이다.

4.1.2 서버 사이드 렌더링이란?

싱글 페이지 애플리케이션이 자바스크립트를 활용해 하나의 페이지에서만 렌더링을 수행한다면, 서버 사이드 렌더링은 최초에 사용자에게 보여줄 페이지를 서버에서 렌더링해 빠르게 사용자에게 화면을 제공하는 방식을 의미한다.

즉, 싱글 페이지 애플리케이션은 사용자에게 제공되는 자바스크립트 번들에서 렌더링을 담당하지만, 서버 사이드 방식은 렌더링에 필요한 작업을 모두 서버에서 수행한다.

서버 사이드 렌더링의 장점

최초 페이지 진입이 비교적 빠르다

사용자가 최초 페이지에 진입했을 때 페이지에 유의미한 정보가 그려지는 시간(First Contentful Paint)이 더 빨라질 수 있다.

SPA는 사용자가 해당 페이지에 진입하고 자바스크립트 리소스를 다운로드하고 HTTP요청을 수행한 이후에 응답 결과를 가지고 렌더링해야 한다. 이러한 작업을 서버에서 이뤄지면 빠르게 렌더링될 수 있다. 서버에서 HTTP 요청을 수행하는 것이 더 빠르고, HTML을 그리는 작업도 서버에서 해당 HTML을 문자열로 미리 그려서 내려주는 것이 클라이언트에서 기존 HTML에 삽입하는 것보다 더 빠르기 때문이다.

이것은 화면 렌더링이 HTTP 요청에 의존적이거나 렌더링해야 할 HTML의 크기가 커진다면 상대적으로 서버 사이드 렌더링이 더 빠를 수 있다. 또 서버가 사용자를 감당할 수 있고 리소스 확보를 충분히 할 수 있는 상태여야 한다.

검색 엔진과 SNS 공유 등 메타데이터 제공이 쉽다

서버 사이드 렌더링은 검색 엔진 최적화에 유용하다. 먼저 검색 엔진이 사이트에서 필요한 정보를 가져가는 과정을 알아보면,

검색 엔진 로봇이 페이지에 진입한다.
페이지가 HTML 정보를 제공해 로봇이 이 HTML을 다운로드한다. 단, 자바스크립트 코드는 실행하지 않는다.
다운로드한 HTML 페이지 내부의 오픈 그래프나 메타 태그 정보를 기반으로 페이지의 검색(공유)정보를 가져오고 이를 바탕으로 검색 엔진에 저장한다.

이처럼 SPA에서는 대부분의 작동이 자바스크립트에 의존하는데, 검색 엔진이 최초 방문했을 때 이러한 메타 정보를 제공할 수 있도록 조치를 취하지 않는다면 검색엔진이나 SNS 공유 시 불이익이 있을 수 있다. 반면 서버 사이드 렌더링은 최초의 렌더링 작업이 서버에서 일어난다. 즉, 검색 엔진에 제공할 정보를 서버에서 가공해서 HTML 응답으로 제공할 수 있으므로 검색 엔진 최적화에 대응하기 용이하다.

누적 레이아웃 이동이 적다

누적 레이아웃 이동이란 사용자에게 페이지를 보여준 이후에 뒤늦게 어떤 HTML 정보가 추가되거나 삭제되어 마치 화면이 덜컥거리는 것과 같은 부정적인 사용자 경험을 말한다. 예를 들어 기사글의 로딩이 빨리 이뤄져 화면에 먼저 노출되었다가 뒤늦게 중간에 배너가 로딩되어 배너의 크기만큼 글 영역이 밀리는 불편함이 있다. SPA는 페이지 콘텐츠가 API 요청에 의존하고 API 요청의 응답 속도가 제각각이여서 적절한 처리를 하지 않으면 이러한 문제가 발생할 수 있다. 반면 서버 사이드 렌더링의 경우 이러한 요청이 완전히 완료된 이후에 완성된 페이지를 제공하므로 보완할 수 있다.

하지만 이러한 문제는 여전히 완벽하게 해결이 어려운데 useEffect 경우 컴포넌트가 마운트된 후에 실행되므로 SPA나 SSR 모두 문제의 소지가 있다. 또 SSR은 모든 요청이 완료되기 까지는 렌더링이 되지 않을 것이므로 최초 렌더링이 굉장이 느려질 수 있다. 그러나 이는 리액트 18에서 등장한 스트림으로 인해 해결될 수 있다.

사용자의 디바이스 성능에 비교적 자유롭다

비교적 사용자 디바이스의 성능으로부터 자유롭다. 자바스크립트 리소스 실행은 사용자의 디바이스에서만 실행되므로 절대적으로 사용자 디바이스 성능에 의존적이다. 그러나 SSR을 수행하면 이러한 부담을 서버에서 나눌 수 있어 조금 더 자유로워질 수 있다.

보안에 좀 더 안전한다

JAM 스택을 채택한 프로젝트의 공통된 문제점은 애플리케이션의 모든 활동이 브라우저에 노출된다는 것이다. SSR의 경우 인증 혹인 민감한 작업을 서버에서 수행하고 그 결과만 브라우저에 제공해 이러한 보안 위협을 피할 수 있다.

단점

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

서버에서도 실행될 가능성이 있는 코드라면 window에 대한 접근을 최소화해야 하고, window 사용이 불가피하다면 해당 코드가 서버 사이드에서 실행되지 않도록 처리해야 한다. 라이브러리 또한 서버에 대한 고려가 돼 있지 않다면 다른 대안을 찾거나 클라이언트에서만 실행될 수 있도록 처리해야 한다.

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

서버는 정적인 데이터인 자바스크립트와 HTML을 제공하면 모든 역할이 끝난다. 그러나 SSR은 말 그대로 사용자의 요청을 받아 렌더링을 수행할 서버가 필요하다. 이는 쉽지 않은 일인데 사용자의 요청에 따라 적절하게 대응할 수 있는 물리적인 가용량을 확보해야 하고, 때로는 예기치 않은 장애 상황에 대응할 수 있도록 복구 전략도 필요하다. 또한 요청을 분산시키고, 프로세스가 예기치 못하게 다운될 때를 대비해 PM2와 같은 프로세스 매니저의 도움도 필요하다.

서비스 지연에 따른 문제

SPA는 지연이 될때 '로딩중'과 같이 작업이 진행 중임을 안내하여 사용자에게 기다릴 여지를 줄 수 있다.

반면 SSR에서는 렌더링 작업이 끝나기까지 렌더링이 되지 않는다. 이로 인해 사용자 경험을 저해할 수 있다.

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

서버 사이드 렌더링 역시 만능이 아니다

제대로 설계하지 않으면 성능 개선도 얻지 못하고 서버와 클라이언트 두 군데로 관리 포인트만 늘어나는 역효과를 낳을 수 있다. 웹페이지의 설계와 목적, 그리고 우선순위에 따라 SPA이 더 효율적일 수도 있다.

싱글 페이지 애플리케이션과 서버 사이드 렌더링 애플리케이션

싱글 페이지 애플리케이션과 LAMP 스택과 같이 서버에서 모든 페이지를 각각 빌드하는 서버 사이드 렌더링 방식인 멀티 페이지 애플리케이션에 대해서는 다음과 같이 설명할 수 있다.

가장 뛰어난 SPA는 가장 뛰어난 멀티 페이지 애플리케이션 보다 낫다. 위 예시의 Gmail처럼 최초 페이지 진입 시에 보여줘야할 정보만 최적화해 렌더링하고, 중요성이 떨어지는 리소스는 게으른 로딩으로 렌더링에 방해되지 않도록 처리했으며, 코드분할(코드 스플리팅, 필요한 코드만 나눠서 번들링하는 기법) 또한 지켜 불필요한 자바스크립트 리소스의 다운로드 및 실행을 방지했다. 라우팅이 발생하면 변경할 HTML 영역만 교체한다.
평균적인 싱글 페이지 애플리케이션은 평균적인 멀티 페이지 애플리케이션보다 느리다. 멀티 페이지 애플리케이션은 매번 서버에 렌더링을 요청을 하고, 서버는 안정적인 리소스를 기반으로 매 요청마다 비슷한 성능의 렌더링을 수행한다. 그러나 싱글 페이지 애플리케이션은 렌더링과 라우팅에 최적화가 돼 있지 않다면 사용자 기기에 따라 성능이 들쑥 날쑥하고 성능 최적화도 돼 있지 않을 가능성이 높다. 심지어 멀티 페이지 애플리케이션에서 발생하는 라우팅으로 인한 문제를 해결하기 위한 다양한 API가 브라우저에 추가되고 있다.

- 페인트 홀딩(Paint Holding) : 같은 출처(origin)에서 라우팅이 일어날 경우 화면을 잠깐 하얗게 띄우는 대신 이전 페이지의 모습을 잠깐 보여주는 기법
- back forward cache(bfcache) : 브라우저 앞으로 가기, 뒤로가기 실행 시 캐시된 페이지를 보여주는 기법
- Shared Element Transitions : 페이지 라우팅이 일어났을 때 두 페이지에 동일 요소가 있다면 해당 콘텍스트를 유지해 부드럽게 전환되기 하는 기법

현대의 서버 사이드 렌더링

먼저 기존 LAMP 스택은 모든 페이지 빌드를 서버에서 렌더링해 초기 페이지 진입이 빠르다는 장점이 있지만 이후 라우팅이 발생할 때도 마찬가지로 서버에 의존해야 하기 때문에 싱글 페이지 렌더링 방식에 비해 라우팅이 느리다는 단점이 있다. 그래서 요즘은 최초 웹사이트 진입 시에는 서버 사이드 렌더링 방식으로 서버에서 완성된 HTML을 제공받고, 이후 라우팅에서는 서버에서 내려받은 자바스크립트를 바탕으로 마치 싱글 페이지 애플리케이션처럼 작동한다. Next.js, Remix 등이 이러한 방식으로 작동한다.

4.2 서버 사이드 렌더링을 위한 리액트 API 살펴보기

리액트에서 서버 사이드 렌더링을 실행할 때 사용되는 API를 확인해 보려면 리액트 저장소의 react-dom/server.js를 확인하면 된다. 이번에는 기존에 있던 기본적인 4개의 함수에 대해 설명한다.

4.2.1 renderToString

인수로 넘겨받은 리액트 컴포넌트를 렌더링해 HTML 문자열로 반환하는 함수다. SSR을 구현하는 데 가장 기초적인 API로, 최초의 페이지를 HTML로 먼저 렌더링한다고 언급했는데 바로 그 역할을 하는 함수가 renderToString이다.

import ReactDOMServer from 'react-dom/server'

function ChildrenComponent({fruits}: {fruits: Array<string>}) {
 useEffect(()=>{
  console.log(fruits)
 },[fruits])

 function handleClick() {
  console.log('hello')
 }
 
 return (
  <ul>
   {fruits.map((fruit)=>(
    <li key={fruit} onClick={handleClick}>
     {fruit}
    <li/>
   ))}
  <ul/>
 )
}

function SampleComponent() {
 return (
  <>
   <div>hello<div/>
   <ChildrenComponent fruits={['apple', 'banana', 'peach']} />
  </>
 )
}

const result = ReactDOMServer.renderToString(
 React.createElement('div', { id: 'root' }, < SampleComponent/>),
)

// result는 다음과 같은 문자열을 반환한다.
<div id="root" data-reactroot="">
 <div>hello</div>
 <ul>
  <li>apple</li>
  <li>banana</li>
  <li>peach</li>
 </ul>

위 예제를 보면 ChildrentComponent에 있는 useEffect와 같은 훅과 handleClick과 같은 이벤트 핸들러는 결과물에 포함되지 않는 것을 확인할 수 있다. 이는 의도된 것으로 renderToString은 인수로 주어진 리액트 컴포넌트를 기준으로 빠르게 브라우저가 렌더링할 수 있는 HTML을 제공하는 데 목적이 있는 함수일 뿐이기 때문이다. 즉, 클라이언트에서 실행되는 자바스크립트 코드를 포함시키거나 렌더링하는 역할까지는 해주지 않는다. 그래서 renderToString을 사용하면 서버 사이드의 이점인 먼저 완성된 HTML을 서버에서 제공할 수 있어 초기 렌더링에서 뛰어난 성능을 기대할 수 있다. 또한 검색 엔진이나 SNS 공유를 위한 메타 정보도 손쉽게 완성할 수 있다.

하지만 사용자와 인터랙션할 준비가 되기 위해 별도의 자바스크립트 코드를 모두 다운로다, 파싱, 실행하는 과정을 거쳐야 한다.

또 주목할 것은 div#root에 존재하는 속성인 data-reactroot이다. 이 속성은 리액트 컴포넌트의 루트 엘리먼트가 무엇인지 식별하는 역할을 한다. 자바스크립트를 실행하기 위한 hydrate 함수에서 루트를 식별하는 기준점이 된다.

4.2.2 renderToStaticMarkup

renderToString과 매우 유사한 함수인데, 모두 리액트 컴포넌트를 기준으로 HTML 문자열을 만든다는 점에서 동일하다. 차이점은 data-reactroot와 같은 추가적인 DOM 속성을 만들지 않는다는 점이다. 이렇게 하면 HTML의 크기를 아주 약간이라도 줄일 수 있다.

// ...이하 생략
const result = ReactDOMServer.renderToStaticMarkup(
 React.createElement('div', { id: 'root' }, <SampleComponent />),
)
<div id="root">
 <div>hello</div>
 <ul>
  <li>apple</li>
  <li>banana</li>
  <li>peach</li>
 </ul>
</div>

앞선 예제에서 renderToStaticMarkup만 바꿔 실행한 결과, data-reactroot가 사라진 완전히 순수한 HTML 문자열이 반환되는 것을 확인 할 수 있다.

이 함수를 사용하면 클라이언트에서는 리액트에서 제공하는 useEffect와 같은 브라우저 API를 절대 실행할 수 없다. 만약 이 함수의 결과물을 기반으로 리액트의 자바스크립트 이벤트 리스너를 등록하는 hydrate를 수행하면 서버와 클라이언트의 내용이 맞지 않다는 에러가 발생한다. 즉, renderToStaticMarkup은 리액트의 이벤트 리스너가 필요 없는 완전히 순수한 HTML을(정적인 내용) 만들 때만 사용된다.

4.2.3 renderToNodeStream

renderToNodeStream은 renderToString과 결과물이 완전히 동일하지만 두 가지 차이점이 있다.

앞에서 살펴본 두 API 인 renderToString 과 renderToStaticMarkup 은 브라우저에서도 실행할 수는 있지만 renderToNodeStream은 브라우저에서 사용하는 것이 완전히 불가능하다는 점이다. renderToNodeStream은 완전히 Node.js 환경에 의존하기 때문이다.

두 번째 차이점은 결과물의 타입이다. renderToString 은 이름에서도 얄 수 있듯 결과물이 string 인 문자열이지만, renderToNodeStream 의 결과물은 Node.js 의 ReadableStream이다. ReadableStreamdms utf-8로 인코딩된 바이트 스트림으로, Node.js나 Deno, Bun 같은 서버 환경에서만 사용할 수 있다. 즉 string을 얻기 위해서는 추가적인 처리가 필요하다.

ReadableStream 자체는 브라우저에서도 사용할 수 있는 객체다. 그러나 ReadableStream을 만드는 과정이 브라우저에서 불가능하게 구현돼 있다.

그렇다면 renderToNodeStream 은 왜 필요할까? 먼저 스트립의 개념을 이해해보자. 유튜브와 같은 웹에서 동영상을 볼 때, 전체 영상을 다 다운로드할 때까지 기다리지 않고 몇 초라도 먼저 다운로드하여 그 부분을 먼저 보여주고 이후에 계속 영상을 다운로드한다. 스트림은 큰 데이터를 다룰 때 데이터를 청크(Chunk, 작은 단위)로 분할해 조금씩 가져오는 방식을 의미한다.

그래서 renderToString으로 생성해야 하는 HTML의 크기가 매우 크면 Node.js가 실행되는 서버에 큰 부담이 된다. 이때 스트림을 활용하면 청크 단위로 분리해서 순차적으로 처리할 수 있는 장점이 있다.

export default function App({ todos }: {todos: Array<TodoResponse>}) {
 return (
  <>
   <h1>나의 할 일!<h1/>
   <ul>
    {todos.map((todo, index) => (
     <Todo key={index} todo={todo} />
    ))}
   </ul>
  </>
 )
}

위 App은 todos를 순회하며 렌더링하는데, 이 todos가 엄청나게 많다고 가정한다면 renderToString은 이를 모두 한 번에 렌더링하려고 하기 때문에 시간이 많이 소요될 것이다. 그러나 이를 renderToNodeStream으로 렌더링하면 다음과 같은 차이가 있다.

// Node.js 코드
;(async () => {
 const response = await fetch('http://localhost:3000')
 
 try {
  for await (const chunk of response.body) {
   console.log('------chunk------')
   console.log(Buffer.from(chunk).toString())
  }
 } catch(err) {
   console.error(err.stack)
 }
})()

위와 같이 응답으로 오는 HTML이 여러 청크로 분리돼 내려오는 것을 볼 수 있다.

4.2.4 renderToStaticNodeStream

renderToString 에 renderToStaticMarkup 이 있다면 renderToNodeStream 에는 renderToStaticNodeStream이 있다.

renderToNodeStream과 제공하는 결과물은 동일하지만, renderToStaticMarkup과 마찬가지로 리액트 자바스크립트에 필요한 리액트 속성이 제공되지 않는다. 마찬가지로 hydrate 를 할 필요가 없는 순수 HTML 결과물이 필요할 때 사용하는 메서드다.

4.2.5 hydrate

hydrate 함수는 renderToString과 renderToNodeStream으로 생성된 HTML 콘텐츠에 자바스크립트 핸들러나 이벤트를 붙이는 역할을 한다. 정적으로 생성된 HTML에 이벤트 핸들러를 붙여 완전한 웹페이지 결과물을 만든다.

먼저 render 메서드를 살펴보면 (CRA로 생성된 프로젝트의 index.jsx에서 있음)

render 함수는 컴포넌트와 HTML의 요소를 인수로 받는다. 이를 바탕으로 HTML의 요소에 해당 컴포넌트를 렌더링하며, 여기에 이벤트 핸들러를 붙이는 작업까지 모두 한 번에 수행한다. 즉, render는 클라이언트에서만 실행되는, 렌더링과 이벤트 핸들러 추가 등 리액트를 기반으로 한 온전한 웹페이지를 만드는 데 필요한 모든 작업을 수행한다.

hydrate도 인수를 넘기는 것은 render와 유사하다.

hydrate는 기본적으로 이미 렌더링된 HTML이 있다는 가정 하에 작업이 수행되는 것이 차이점이고, 이 렌더링된 HTML을 기준으로 이벤트를 붙이는 작업만 실행한다. 중요한 것은 hydrate로 넘겨준 두 번째 인수에는 이미 renderToString 등으로 렌더링된 정적인 HTML 정보가 반드시 담겨 있어야 한다는 것이다.

만약 서버와 클라이언트의 HTML 결과물이 다를 수 밖에 없는 경우(ex. 초 단위로 기록해야 하는 경우)에는 suppressHydrationWarning을 추가해 경고를 끌 수 있지만 꼭 필요한 상황에서만 사용해야 한다. 차라리 서버에서 실행되는 것보다 useEffect를 통해 노출하는 편이 나을 수도 있다.

4.2.6 서버 사이드 렌더링 예제 프로젝트

(리액트 팀에서도 리액트 서버 사이드 렌더링을 직접 구현하기 보다 Next.js 같은 프레임워크를 사용하는 것을 권장하고 있음)

예시 프로젝트는 Todo List 이다.

index.tsx

애플리케이션의 시작점으로, hydrate가 포함돼 있다. 이 파일의 목적은 서버로부터 받은 HTML을 hydrate를 통해 완성된 웹 애플리케이션으로 만드는 것이다. 주목할 것은 fetchTodo를 호출해 필요한 데이터를 주입한다는 점이다. hydrate는 서버에서 완성한 HTML과 하이드레이션 대상이 되는 HTML의 결과물이 동일한지 비교하는 작업을 거치므로, 이 비교 작업을 무사히 수행하기 위해 한번 더 데이터를 조회한다.

App.tsx

일반적으롤 사용자가 만드는 리액트 애플리케이션의 시작점이다. 한 가지 다른 점은 todos를 props로 받는데, 이 props는 서버에서 요청하는 todos를 받는다. 이 props.todo를 기반으로 렌더링한다.

Todo.tsx

index.html

이 HTML 파일은 서버 사이드 렌더링을 수행할 때 기본이 되는 HTML 템플릿이다. 이 HTML을 기반으로 리액트 애플리케이션이 완성된다.

다만 여기서 몇가지 주목할 포인트가 있다.

server.ts

사용자의 요청 주소에 따라 어떠한 리소스를 내려줄지 결정하는 역할을 한다. 특히 서버 사이드 렌더링을 위해 이 파일에서 리액트 트리를 만드는 역할도 담당한다.

파일을 나눠서 살펴보면,

createServer

http 모듈을 이용해 간단한 서버를 만들 수 있는 Node.js 기본 라이브러리다. 3000번 포트를 이용하는 HTTP 서버를 만들었다고 이해하면 된다.

serverHandler

createServer로 넘겨주는 인수로, HTTP 서버가 라우트(주소)별로 어떻게 작동할지를 정의하는 함수다.

req.url을 통해 사용자가 접근한 주소를 알 수 있는데, 각 주소별로 어떻게 작동할지 정의할 수 있다. 자세한 라우터는 뒤이어서...

server.ts의 루트 라우터 /

다음 코드는 사용자가 /로 접근했을 때 실행되는 코드다.

이 라우팅에서는 renderToString을 활용해 리액트 컴포넌트를 HTML로 만들었고, 이를 앞서 언급한 __placeholder__ 대상으로 replace를 실행해 서버 응답으로 제공했다. 그 결과 브라우저에서 다음과 같이 확인할 수 있다.

이 페이지가 서버에서 만들어졌는지 확인하려면 소스 보기를 통해 확인하면 된다.

소스 보기는 자바스크립트를 실행하지 않고 온전히 HTML만 보여준다.

위 결과를 보면 useEffect로 넣은 코드도 잘 실행됐고, hydrate가 되기 이전부터 이미 서버사이드에서 완벽하게 렌더링돼서 하나의 HTML을 만들 제공했음을 알 수 있다. 서버 사이드에서 HTML을 만들어 제공하는 SSR의 목적을 이 라우트로 달성한 것이다.

server.ts의 /stream 라우터

다음 라우터는 /stream이다. 이 코드도 rootElement를 만드는 과정까지는 동일하다.

indexFront와 indexEnd는 앞서 소개한 index.html의 __placeholder__ 부분을 반으로 나눈 코드다. 절반을 우선 응답으로 기록하고, 이후에 renderToNodeStream을 활용해 나머지 부분을 스트림 형태로 생성했다.

스트림은 청크 단위로 생성하기 때문에 이를 pipe와 res에 걸어두고 청크가 생성될 때마다 res에 기록했다. 마지막으로 이 스트림이 종료되면 index.html의 나머지 반쪽을 붙이고 최종 결과물을 브라우저에 제공한다.

결과물을 보면 /stream으로 접속해도 renderToString을 활용한 /와 완벽하게 동일한 결과물을 브라우저가 내려받는 것을 확인할 수 있다.

/ 방식과 동일하지만 페이지를 만드는 순서대로 제공하기 때문에 더욱 효율적이다.

그 밖의 라우터

하나는 browser.js인데, 애플리케이션에서 작성한 리액트 및 관련 코드를 제공하는 파일로, 웹팩이 생성한다. browser.js.map은 browser.js와 관련된 소스맵 파일로, 디버깅 용도로 쓰인다. 하지만 이 예제에서는 사용하지 않는다.

webpack.config.js

configs 배열에 각각 브라우저 코드와 서버 코드를 번들링하는 방식으로 선언했다.

먼저 브라우저의 경우 entry가 ./src/index.tsx이며, 그중 resolve.extensions로 번들링에 포함해야 하는 파일을 선언해 뒀고, 이 결과물을 __dirname, './dist'에 만들도록 선언했다. 그리고 react 와 react-dom은 외부 CDN 서비스를 사용하기 위해 번들링에서 제외했으며， 타입스크립트 파일을 읽어 들이기 위한 ts-loader를 추가했다.

서버의 경우 entry 가 ./src/server.ts 이며 그 외의 설정은 비슷하다. 몇 가지 차이점은 HTML 을 불러오기 위한 raw-loader, 그리고 target 을 node로 하고 node 의 API는 모두 Node.js 에서 제공하므로 nodeExternal()로 번들러에서 제외했다.

요약하자면 entry를 선언해 시작점을 선언하고， 필요한 파일과 그에 맞는 loader를 제공하고， 마지막으로 번들링에서 제외할 내용을 선언한 뒤 output 으로 내보낸다. 이것이 webpack.config.js 설정의 전부다.

* fetchTodo가 클라이언트와 서버 두 군데에서 일어나는데, API 결과에 따라 두 결과물에 차이가 발생하지 않는지?

해당 예제는 fetch 결과물이 변경되지 않아 크게 문제가 없지만 대부분의 API 호출 시에는 적절한 처리가 필요하다. Next.js의 경우 fetchTodo를 getServerSideProp라는 예약 함수에서 딱 한번만 호출하고 그 결과를 HTML에 포함시켜 HTML 파싱이 끝나면 자연스럽게 window 객체에 접근할 수 있도록 해둔다. 이 정보를 바탕으로 hydrate를 수행하여 중복 호출을 방지한다. 자세한 내용은 4.3절에서...

4.3 Next.js 톺아보기

4.3.1 Next.js란?

Vercel이라는 미국 스타트업에서 만든 풀스택 웹 애플리케이션을 구축하기 위한 리액트 기반 프레임워크다. 현재 가장 많이 사용되고 있다.

4.3.2 Next.js 시작하기

Next.js는 create-next-app을 제공해 개발자가 빠르게 프로젝트를 생성할 수 있게 한다.

타입스크립트를 기반으로 Next.js 프로젝트를 만들어보자.

npx create-next-app@latest --ts

package.json

npm 프로젝트를 살펴볼 때는 package.json을 먼저 봐야 한다. 프로젝트 구동에 필요한 모든 명령어 및 의존성이 포함돼 있어 대략적인 프로젝트의 모습을 확인하는 데에 매우 유용하다.

next.config.js

이 파일은 Next.js 프로젝트의 환경 설정을 담당하며, Next.js를 자유자재로 다루려면 반드시 알아야 하는 파일이다.

첫 줄의 @type으로 시작하는 주석은 자바스크립트 파일에 타입스크립트의 타입 도움을 받기 위해 추가된 코드다. Vs code 기준 해당 주석이 있으면 next의 NextConfig를 기준으로 타입의 도움을 받을 수 있다. 그리고 추가된 옵션을 더 살펴보면,

SWC가 바벨에 비해 더 빠른 속도를 보여주기 때문에 사용을 권장한다.

pages/_app.tsx

pages 폴더가 경우 따라 src 하단에 존재할 수 있는데 src에 있거나 프로젝트 루트에 있어도 동일하게 작동한다.

_app.tsx, 그리고 내부에 있는 default export로 내보낸 함수는 애플리케이션의 전체 페이지의 시작점이다. 웹 애플리케이션에서 공통으로 설정해야 하는 것들을 여기에서 실행할 수 있다. 다음은 _app.tsx에서 할 수 있는 내용들이다.

또한 서버 사이드 프레임워크로서 최초에는 서버 사이드 렌더링을, 이후에는 클라이언트에서 _app.tsx의 렌더링이 실행된다는 것을 알 수 있다.

pages/_document.tsx

create-next-app으로 생성하면 해당 파일은 존재하지 않지만 프로젝트 실행은 된다. 그럼에도 해당 파일은 유용한 도움을 준다.

_app.tsx가 애플리케이션 페이지를 전체 초기화하는 곳이라면, _document.tsx는 애플리케이션의 HTML을 초기화하는 곳이다.

아래는 _app.tsx와의 차이점이다.

참고로 _document.tsx에서만 할 수 있는 또 한가지 작업은 CSS-in-JS의 스타일을 서버에서 모아 HTML로 제공하는 것이다.

pages/_error.tsx

이 파일도 기본 생성되는 것이 아니며, 없어도 실행은 된다.

Next.js 프로젝트 전역에서 발생하는 에러를 적절하게 처리하고 싶다면 이 페이지를 활용하면 된다. 이 페이지의 작동을 확인하려면 프로덕션으로 빌드해서 확인해 봐야 한다.

pages/404.tsx

404 페이지를 정의할 수 있는 파일이다.

pages/500.tsx

서버에서 발생하는 에러를 핸들링하는 페이지다. _error.tsx랑 같이 있다면 500.tsx가 우선적으로 실행된다.

pages/index.tsx

파일 이름이 곧 라우팅이 되는 것과 [] 사용해 라우팅을 정의하는 부분이 어색할 수 있는데 [] 안의 내용을 변수로 처리된다고 생각하면 쉽게 이해할 수 있다. []의 변수로 지정된 값을 어떻게 사용하는지는 다음 예제를 보자.

위 페이지를 다음과 같은 주소로 접근하면 props에 다음과 같은 값이 담긴다.

서버 라우팅과 클라이언트 라우팅의 차이

Next.js는 서버 사이드 렌더링을 비롯한 사전 렌더링을 지원하기 때문에 최초 페이지 렌더링이 서버에서 수행된다.

위 예제에 next/link는 Next.js에서 제공하는 라우팅 컴포넌트이며, <a/> 태그와 비슷한 동작을 한다. 두 개 차이점은

<a> 태그로 페이지 이동을 하면 모든 리소스를 처음부터 다시 받는다는 것이고, <Link> 태그로 이동하면 페이지 이동에 필요한 내용만 받는다는 것이다. 그래서 전자는 잠시 깜빡임이 있다.

Next.js는 SSR의 장점과 SPA의 장점을 모두 살리기 위해 이러한 방식으로 작동하는 것이기 때문에 다음과 같은 규칙을 지켜야 한다.

페이지에서 getServerSideProps를 제거하면 어떻게 될까?

getServerSideProps가 아무것도 하지 않고 있음에도 추가가 되어있을텐데 만약 이를 제거하게 되면 어떠한 방식으로 접근해도 서버에 로그가 남지 않는 것을 확인할 수 있다.

그 이유는 빌드 결과물에서 확인할 수 있다.

getServerSideProps가 있는 빌드

getServerSideProps가 있는 채로 빌드하면 서버 사이드 런타임 체크가 되어 있는 것을 볼 수 있다.

getServerSideProps가 없는 빌드

getServerSideProps가 없는 채로 빌드하면 빌드 크기가 약간 줄어든 것과 동시에 서버 사이드 렌더링이 필요없는 정적인 페이지로 분류된 것을 알 수 있다.

getServerSideProps가 없으면 서버에서 실행하지 않아도 되는 페이지로 처리하고 typeof window의 처리를 모두 object로 바꾼 뒤 빌드 시점에 미리 트리쉐이킹을 해버리기 때문이다. 이는 Next.js가 모든 작업을 서버에서 하는 것이 아님을 알게 해준다.

/pages/api/hello.ts

이는 서버의 API를 정의하는 폴더다. 이 주소는 다른 pages 파일과 다르게 HTML 요청을 하는 것이 아닌 서버 요청을 주고 받는다.

페이지와 마찬가지로 default export로 내보낸 함수가 실행된다. 여기에 있는 코드는 당연히 서버에서만 실행된다.

서버에서 내려주는 데이터를 조합해 BFF(backend-for-frontend) 형태로 활용하거나, 풀스택 애플리케이션을 구축하고 싶을 때, 혹은 CORS(cross-origin resource sharing) 문제를 우회하기 위해 사용될 수 있다.

4.3.3 Data Fetching

서버 사이드 렌더링 지원을 위한 몇가지 데이터 불러오기 전략이다. 이 함수는 pages/의 폴더에 있는 라우팅이 되는 파일에만 사용할 수 있으며, 예약어로 지정되어 반드시 정해진 함수명으로 export를 사용해 함수를 외부 파일롤 내보내야 한다.

이를 활용하면 서버에서 미리 필요한 페이지를 만들어서 제공하거나 해당 페이지에 요청이 있을 때마다 서버에서 데이터를 조회해서 미리 페이지를 만들어 제공할 수 있다. 여기에 활용할 수 있는 함수들은 다음과 같다.

getStaticPaths와 getStaticProps

어떠한 페이지를 CMS(Contents Management System)나 블로그， 게시판과 같이 사용자와 관계없이 정적으로 결정된 페이지를 보여주고자 할 때 사용되는 힘수다. 두 개의 함수는 반드시 함께 있어야 사용할 수 잇다.

/pages/post/[id]와 같은 페이지가 있고, 해당 페이지에 두 함수를 사용했다고 가정을 해보자.

getStaticPaths는 /pages/post/[id]가 접근 가능한 주소를 정의하는 함수다. 예제에서는 /post/3이나 /post/foo 등은 404를 반환한다.

getStaticProps는 앞에서 정의한 페이지를 기준으로 해당 페이지로 요청이 왔을 때 제공할 props를 반환하는 함수다. 예제에서는 fetchPost(1), fetchPost(2)를 기준으로 각 함수의 응답 결과를 변수로 가져와 { post }로 반환한다.

Post는 getStaticProps가 반환한 post를 렌더링하는 역할을 한다. getStaticPaths에서 해당 페이지는 id를 각각 1, 2만 허용하며, getStaticProps는 1과 2에 대한 데이터 요청을 수행해 props로 반환한 다음, 마지막으로 Post는 이 결과를 바탕으로 페이지를 렌더링한다. 즉 이 두 함수로 빌드 시점에서 미리 데이터를 불러온 다음 정적인 HTML 페이지를 만들 수 있다.

getStaticPaths 함수의 반환값 중 하나인 fallback 옵션은 미리 빌드해야 할 페이지가 너무 많은 경우에 사용 가능하다.

paths 에 미리 빌드해 둘 몇 개의 페이지만 리스트로 반환하고， true 나 "blocking" 으로 값을 선언할 수 있다. 이렇게 하면 next build 를 실행할 때 미리 반환해 둔 paths 에 기재돼 있는 페이지만 앞서와 마찬가지로 미리 빌드하고 나머지 페이지의 경우에는 다음과 같이 작동한다.

getServerSideProps

서버에서 실행되는 함수로 해당 함수가 있으면 무조건 페이지 진입 전에 이 함수를 실행한다. 응답값에 따라 페이지의 루트 컴포넌트에 props를 반환할 수도， 혹은 다른 페이지로 리다이렉트시킬 수도 있다. 이 함수가 있다면 Next.js는 꼭 서버에서 실행해야 하는 페이지로 분류해 빌드 시에도 서버용 자바스크립트 파일을 별도로 만든다.

/pages/post/ [id]. tsx 파일에 다음과 같은 getServerSideProps 가 있다고 가정해 보자.

context.query.id를 사용하면 /post/[id]와 같은 경로에 있는 id 값에 접근할 수 있다. 이 값을 이용해 props를 제공하면 페이지의 Post 컴포넌트에 해당 값을 제공해 이 값을 기준으로 렌더링을 수행할 수 있다. 결과물은 다음과 같다.

Next.js의 서버 사이드 렌더링은 getServerSideProps 의 실행과 함께 이뤄지며， 이 정보를 기반으로 페이지를 렌더링하는 과정이 바로 서버 사이드 렌더링을 나타내는 것임을 알 수 있다. 여기서 한 가지 더 눈여겨봐야 할 것은 __NEXT_DATA __ 라는 id 가 지정된 script다. 이 스크립트는 getServerSideProps 의 정보인 props뿐만 아니라 현재 페이지 정보， query 등 Next.js 구동에 필요한 다양한 정보가 담겨 있다. 그렇다면 이 정보는 왜 script 형태로 삽입돼 있을까?

앞서 리액트의 서버 사이드 렌더링을 하는 작동을 잠시 떠올려보자.

1 번과 6 번 작업 사이에 fetch 시점에 따라 결괴물의 불일치가 발생할 수 있으므로 1 번에서 가져온 정보를 결과물인 HTML에 script 형태로 내려주는 것이다. 이 작업을 거치면 1 번의 작업을 6 번에서 반복하지 않아도 되어 불필요한 요청을 막을 수 있을뿐더러 시점 차이로 인한 결괴물의 차이도 막을 수 있다. 6 번에서 재요청하는 대신， <script/> 를 읽어도 1 번의 데이터를 동일하게 가져올 수 있다. Next.js 에서는 이 정보를 window 객체에도 저장해 둔다.

일반적인 리액트의 JSX와는 다르게 getServerSideProps 의 props로 내려 줄 수 있는 값은 JSON으로 제공할 수 있는 값으로 제한된다는 것이다. props의 결과를 HTML에 정적으로 작성해서 내려주기 때문에 JSON으로 직렬화할 수 없는 값， 즉 class 나 Date 등은 props로 제공할 수 없다. getServerSideProps 에서는 반드시 JSON.stringify 로 직렬화할 수 있는 값만 제공해야 하고， 값에 대

해 가공이 필요하다면 실제 페이지나 컴포넌트에서 히는 것이 옳다. 만약 JSON으로 변환할 수 없는 값이 props 로 제공된다면

“ Reason: object ("[object Date]") cannot be serialized as JSON. Please only

return JSON serializable data types. " 라는 에러가 발생한다.

그리고 getServerSideProps 는 무조건 클라이언트가 아닌 서버에서만 실행된다는 사실 또한 염두에 두어야 한다. 서버에서 실행되기 때문에 다음과 같은 제약이 있다.

getServerSideProps 내부에서 실행하는 내용은 최대한 간결하게 작성하기 위해 꼭 최초에 보여줘야 하는 데이터가 아니라면 getServerSideProps 보다는 클라이언트에서 호출하는 것이 더 유리하다. getServerSideProps 에는 반드시 해당 페이지를 렌더링하는 데 있어 중요한 역할을 하는 데이터만 가져오는 것이 좋다.

getServerSideProps에서 어떤 조건에 따라 다른 페이지로 보내고 싶다면 redirect를 사용할 수 있다.

위 예제에서 post를 조회하는 데 실패하면 /404 페이지로 바로 이동한다. 이 경우 클라이언트에서 리다이렉트하는 것보다 더 자연스럽다.클라이언트에서는 아무리 리다이렉트를 초기화해도 자바스크립트가 어느 정도 로딩된 이후에 실행할 수 밖에 없지만 getServerSideProps를 사용하면 조건에 따라 사용자에게 미처 해당 페이지를 보여주기도 이전에 원하는 페이지로 보내버릴 수 있기 때문이다.

getlnitialProps

getStaticProps 나 getServerSideProps 가 나오기 전에 사용할 수 있었던 유일한 페이지 데이터 불러오기 수단이었다. 대부분의 경우에는 getStaticProps 나 getServerSideProps 를 사용하는 것을 권장하며, getInitalProps는 과거에 작성된 Next.js 코드에서 필수로 존재하기에 반드시 알고 있어야 한다.

/pages/todo/[id].tsx 에 다음과 같이 getInitialProps 를 작성해 보자.

가장 큰 차이점은 페이지의 루트 함수에 정적 메서드로 추가한다는 점과 props 객체를 반환하는 것이 아닌 바로 객체를 반환한다는 점이다.

클래스 컴포넌트로 작성하면 다음과 같다.

getInitialProps는 라우팅에 따라서 서버와 클라이언트 모두 다 실행 가능한 메서드이다. 따라서 getInitialProps에 코드를 작성할 때는 이러한 특징을 감안해서 작성해야 한다. 해당 메서드가 서버 혹은 클라이언트 중 어디서 실행되지 알고 싶다면 다음과 같이 작성한다.

contenxt 객체에는 다양한 값이 존재하며 getServerSideProps도 포함된다.

4.3.4 스타일 적용하기

전역 스타일

CSS Reset 이라 불리는， 이른바 브라우저에 기본으로 제공되고 있는 스타일을 초기화하는 등 애플리케이션 전체에 공통으로 적용하고 싶은 스타일이 있다면 _app.tsx를 활용하면 된다. _app. tsx 에 필요한 스타일을 직접 import 로 불러오면 애플리케이션 전체에 영향을 미칠 수 있어 반드시 _app.tsx에서만 제한적으로 작성해야 한다.

컴포넌트 레벨 CSS

Next.js 에서는 컴포넌트 레벨의 css 를 추가할수 있다. [name].module.css 와 같은 명명 규칙만 준수하면 되며 ， 이 컴포넌트 레벨 cs s는 다른 컴포넌트의 클래스명과 겹쳐서 스타일에 충돌이 일어나지 않도록 고유한 클래스명을 제공한다. 페이지와 다르게 컴포넌트 레벨 css는 어느 파일에서건 추가할 수 있다. 다음 예제를 보자.

button에 alert 클래스를 선언해 스타일을 입혔지만 실제 클래스는 Button_alert_62TGU와 같이 조금 다른 것을 볼 수 있는데, 이는 컴포넌트별 스타일 충돌을 방지하기 위해서 Next.js의 최적화가 잘 작동하고 있음을 알 수 있다.

SCSS와 SASS

css를 사용했을 때와 동일한 방식으로 사용하면 된다. scss에서 제공하는 variable을 컴포넌트에서 사용하고 싶다면 export 문법을 사용하면 된다. 이 외에는 컴포넌트 레벨 CSS와 동일하다.

CSS-in-JS

CSS 구문이 자바스크립트 내부에 있다는 것은 확실히 프런트엔드 개발자에게 직관적이고 편리하게 느껴질 것이다. 현재 대표적으로 시용되고 있는 CSS-in-JS 라이브러리인 styled-components를 예로 적용하면 (_document.tsx가 없는 경우)

요약한다면 리액트 트리 내부에서 사용하고 있는 styled-components 의 스타일을 모두 모은 다음， 이 각각의 스타일에 유니크한 클래스명을 부여해 스타일이 충돌하지 않게 클래스명과 스타일을 정리해 이를 _document.tsx 가 서버에서 렌더링할 때 React.Context 형태로 제공하는 것이다. 이렇게 CSS-in-JS 의 스타일을 서버에서 미리 모은 다음 서버 사이드 렌더링에서 한꺼번에 제공해야 올바른 스타일을 적

용할 수 있다. 만약 이런 과정을 거치지 않는다면 스타일이 브라우저에서 뒤늦게 추가되어 FOUC(flash of unstyled content) 라는， 스타일이 입혀지지 않은 날것의 HTML을 잠시간 사용자에게 노출하게 된다. 이는 다른 CSS-in-JS도 마찬가지로， 코드는 약간씩 다르지만 모두 서버에서 스타일을 모아 서버 사이드 렌더링 시에 일괄 적용하는 과정은 동일하게 거치게 된다. 따라서 CSS-in-JS 를 Next.js와같은서버 사이드 렌더링 프레임워크에서 사용할 때는 반드시 이런 초기화 과정을 서버에서 거쳐야한다.

만약 바벨 대신 SWC를 사용한다면 next.config.js 에 다음과 같이 compiler.styledComponents 를 추가하면 된다.

* 프로덕션 모드로 빌드했더니 <style/> 태그 내부가 비어 있지만 스타일은 정상적으로 적용된다 이유는?

styled-components가 프로덕션 모드에서는 SPEEDY_MODE라고 하는 설정을 사용하기 때문이다. 이는 HTML에 스타일을 적용하는 대신 자바스크립트를 활용해 CSSOM 트리에 직접 스타일을 넣는다.

4.3.5 _app.tsx 응용하기

위 예제는 _app.tsx를 함수 컴포넌트로 변환한 것이다. 먼저 _app.tsx에 getInitialProps를 추가하려면 반드시 const appProps = await App.getInitialProps(context)를 실행한 뒤 해당 값을 반환해야 한다. 이 코드는 다른 페이지에 있는

실행해서 반환하는 역할을 하는데, 이게 없다면 다른 페이지의 getInitialProps가 정상적으로 실행되지 않는다.

다음 내용을 _app의 getInitialProps를 추가해 두고 Next.js에서 라우팅을 반복해보자.

실행 절차는 다음과 같다.

페이지 방문 최초 시점인 1 번은 서버 사이드 렌더링이 전체적으로 작동해야 해서 페이지 전체를 요청했다. 그러나 이후에는 클라이언트 라우팅을 수행하기 위해 해당 페이지 가 비록 getServerSideProps 와 같은 서버 관련 로직이 있다 하더라도 전체 페이지를 가져오는 것이 아닌 ， 해당 페이지의 getServerSideProps 결과를 json 파일만을 요청해서 가져오는 것을 확인할수 있다.

이러한 특성을 잘 활용하면 다음과 같이 웹서비스를 최초에 접근했을 때만 실행하고 싶은 내용을 app.getInitialProps 내부에 담아 둘 수 있다.

다음 if 문 조건을 하나씩 살펴보자.

1. req 가 있다면 서버로 오는 요청이다.

2. req.url 이 /_next로 시ξf하지 않는다면 이는 클라이언트 렌더링으로 인해 발생한 getServerSideProps 요청이 아님을 알 수 있다.

3. pathname, 즉 접근 요청하는 경로가 에러 페이지가 아니라면 정상적인 페이지 접근일 것이다.

1 ， 2 ， 3 번 조건을 모두 만족한다면 사용자가 웹페이지에 최초로 접근해서 최초 서버 사이드 랜더링을 수행했다는 사실을 어느 정도 보장할 수 있을 것이다. 여기에는 userAgent 확인이나 사용자 정보와 같은 애플리케이션 전역에서 걸쳐 사용해야 하는 정보 등을 호출하는 작업을 수행할 수 있을 것이다. 이러한 조건을 응용한 실제 활용은 이후에 본격적으로 다룬다.

4.3.6 next.config.js 살펴보기

먼저 Next.js 설정 파일은 자바스크립트이지만 @type 구문을 활용해 미리 선언돼 있는 설정 타입(NextConfig ) 의 도움을 받을 수 있다.

실무에서 자주 사용되는 설정은 다음과 같다.

- basePath: 기본적으로 애플리케이션을 실행하면 호스트 아래 /에 애플리케이선이 제공될 것이다. 개발 환경으로 치면 localhost:3000/이 접근 가능한 주소가 되는데， 여기에 basePath: "docs" 와 같이 문자열을 추가하면 localhost:3000/docs에 서비스가 시작된다. 환경변수명에서도 알 수 있듯， 일종의 URL을 위한 접두시(prefix) 라 볼 수 있다. 만약 여기에 값을 추가했다 하더라도 <Link>나 router. push() 등에 이 basePath 를 추가할 필요는 없다.

basePath 가 있다면 클라이언트 렌더링을 트리거하는 모든 주소에 알아서 basePath 가 붙은 채로 렌더링 및 작동할 것이다. 다음과 같은 컴포넌트는

<Link href="/about">
 <a>about</a>
</Link>

렌더링 시 다음과 같이 렌더링된다.

단, 이것 또한 어디까지나 Next.js 에서 제공하는 기능이므로 <a> 태그를 직접 사용하거나 window. location.push 등으로 라우팅을 수행할 경우에는 반드시 basePath 가 붙어 있어야 한다.

- swcMinify: swc를 이용해 코드를 압축할지를 나타낸다. 기본값은 true 이지만 실험적인 기능이라 걱정이 된다면 false를 설정해서 꺼도된다. Next.js13 버전부터 기본값이 true로 변경됐다. 즉, 별도 설정이 없다면 swc 를 활용해 코드를 압축한다.

- poweredByHeader: Next.js는 응답 헤더에 X-Power-by: Next.js 정보를 제공하는데 . false 를 선언하면 이 정보가 사라진다. 기본적으로 보안 관련 솔루션에서는 powered-by 헤더를 취약점으로 분류하므로 false로 설정하는 것이 좋다.

- redirects: 특정 주소를 다른 주소로 보내고 싶을 때 사용된다. 정규식도 사용 가능하므로 다양한 방식으로 응용할 수 있다.

'React-study > dil' 카테고리의 다른 글

[모던 리액트 Deep Dive] 마지막 15장 (4)	2024.12.26
[모던 리액트 Deep Dive] 14장 웹사이트 보안을 위한 리액트와 웹페이지 보안 이슈 (0)	2024.12.24
[모던 리액트 Deep Dive] 13장 웹페이지 성능을 측정하는 다양한 방법 (1)	2024.12.21
[모던리액트 Deep Dive] 12장 모든 웹 개발자가 관심을 가져야 할 핵심 웹 지표 (3)	2024.12.20
[모던리액트 Deep Dive] 11장 Next.js 13과 리액트 18 (1)	2024.12.10

자바스끄립또

[모던 리액트 Deep Dive] 4장 서버 사이드 렌더링

4.1 서버 사이드 렌더링이란?

4.2 서버 사이드 렌더링을 위한 리액트 API 살펴보기

4.3 Next.js 톺아보기

'React-study > dil' 카테고리의 다른 글

티스토리툴바

[모던 리액트 Deep Dive] 4장 서버 사이드 렌더링

4.1 서버 사이드 렌더링이란?

4.2 서버 사이드 렌더링을 위한 리액트 API 살펴보기

4.3 Next.js 톺아보기

'React-study > dil' 카테고리의 다른 글

관련글

티스토리툴바