```jsx
// some Component
const [count, setCount] = useState(0);

const tripleIncrement = () => {
	setCount(count + 1);
	console.log(count);  // 0
	setCount(count + 1);
	console.log(count);  // 0
	setCount(count + 1);
	console.log(count);  // 0
}

return (
	<div>
		<span>{count}</span>
		<button onClick={tripleIncrement}>+3</button>
	</div>
)
```

React에서 setState를 통한 상태의 변경이 즉각 반영되지 않음을 설명하는 예시 코드는 정말 익숙하다. 

그래서인지 조금만 구글링을 해보면, 지금도 수많은 블로그들이 ‘setState는 비동기적이다’라고 단언하고 있다. 나 역시 그동안 막연하게 그렇다고만 생각했었다.

그런데 setState는 정말 비동기 함수일까?

[React 공식문서](https://react.dev/learn/adding-interactivity)를 차근차근 읽으며 고민해본 결과, **“setState 함수는 비동기적이 아니다”**라고 말 할 수 있겠다는 결론을 내렸다.

그 이유를 설명해보려고 한다.

## React의 UI 업데이트 프로세스

리액트는 UI를 구축하기 위한 라이브러리이다. 그리고  ‘상태’라는 개념을 사용하여, 상태의 변화가 곧 UI에 반영되는 메커니즘을 가지고 있다.

상태는 주로 사용자의 인터랙션에 의한 ‘이벤트’에 의해 변경된다. 이벤트가 발생하면 내부적으로 작성된 event handler 함수의 로직에 의해 상태의 변화가 발생하고, 리액트는 변화된 상태를 바탕으로 변경되어야할 UI를 계산한다. 그리고 모든 계산이 완료되면 변경 사항을 브라우저가 실제 사용자가 보고있는 화면에 반영한다.

공식 문서에서는 이 과정을 `trigger` `render` `commit` 이라는 용어를 사용하여 구분한다. 

### trigger

먼저 trigger는 사용자의 인터랙션 등으로 인해 이벤트가 발생하여 상태 업데이트 로직이 호출되는 단계다. 

사용자가 버튼을 클릭하면, click event가 발생한다. event handler 내부에는 클릭에 따라 변화해야 하는 동작들(ex. 배경 색상의 변경, 텍스트 내용의 변경, 모달 팝업 등등)과 관련된 로직이 포함되어 있고, 대부분 setState를 호출하여 해당 상태들을 변경하는 방식일 것이다.

공식 문서에서는 state의 setter를 설명하며 다음과 같은 표현을 사용한다.

> … you can trigger further renders by updating its state with the [set function.](https://react.dev/reference/react/useState#setstate) Updating your component’s state automatically queues a render.
> 

‘queues a render’ 즉, setState의 역할은 렌더링이라는 특정한 동작에 대한 예약 혹은 요청 행위라고 볼 수 있다.

다시 위의 예시 코드를 살펴보자.

```jsx
// some Component
const [count, setCount] = useState(0);

const tripleIncrement = () => {
	setCount(count + 1);
	console.log(count);  // 0
	setCount(count + 1);
	console.log(count);  // 0
	setCount(count + 1);
	console.log(count);  // 0
}

return (
	<div>
		<span>{count}</span>
		<button onClick={tripleIncrement}>+3</button>
	</div>
)
```

사용자가 버튼을 클릭하면 이벤트 핸들러인 `tripleIncrement` 함수가 호출된다. 이제 공식 문서의 설명에 따라 함수 내부의 `setCount(count + 1)` 의 의미를 좀 더 자세히 생각해볼 수 있다.

`setCount(count + 1)` 는 ‘다음 렌더링을 요청한다. 그리고 다음 렌더링에 수행할 동작 목록(queue)에 `count 상태를 count + 1로 변경해라` 라는 명령을 추가한다’로 해석할 수 있다.

그리고 `tripleIncrement` 함수는 이러한 명령을 세 번 반복하고 있는 것에 불과하다.

이처럼 setState 함수의 역할은 리렌더링을 요청하고, 그때 수행할 동작을 큐에 추가하는 것이 전부다. 또한 실행이 완료되기를 기다렸다가, 그 결과 값을 가지고 추가적인 계산이나 기타 동작을 수행하지도 않는다.

이 일련의 과정 자체에는 어떠한 비동기적인 로직도 개입되어 있지 않다. 

따라서 **setState는 비동기 함수가 아니다** 라고 생각했다.

질문에 대한 답은 구했다. 그러나 몇 가지 의문점이 남는다.

- 왜 사람들은(나는) setState를 비동기 함수라고 생각했을까?
- 그리고 count + 1을 세 번이나 계산 했는데 왜 count의 최종값은 여전히 1인가?

이를 해소하기 위해 렌더링 과정에 대해 조금 더 자세히 알아야할 필요가 있다.

### State Snapshot

`setCount` 의 의미를 확인했으니, `tripleIncrement` 이벤트 핸들러에는 렌더링 요청이 세 번이나 있었음을 알 수 있다. 그리고 그때마다 count 상태를 1씩 증가시켰다.

따라서 클릭 이벤트가 발생하면 총 세 번의 리렌더링을 수행하고, 각 렌더링마다 count 상태는 1씩 증가하여 최종적으로 화면에 보여지는 count는 3이 되는 것이 자연스러운 결과다. 

만약 ‘렌더링 → 상태 업데이트’ 의 과정이 동기적으로 수행 됐다면 그랬을 것이다.

하지만 리액트는 그렇게 동작하지 않았다.

먼저 `count + 1` 이라는 계산식이 실제로는 어떤 값으로 계산되는지 알기 위해, 공식 문서의 [state as snapshot](https://react.dev/learn/render-and-commit#re-renders-when-state-updates)이라는 표현을 살펴보자.

> [“Rendering”](https://react.dev/learn/render-and-commit#step-2-react-renders-your-components) means that React is calling your component, which is a function. The JSX you return from that function is like a **snapshot** of the UI in time. Its props, event handlers, and local variables were all calculated **using its state at the time of the render.**
> 

즉, ‘한 번의 렌더링 과정’에서는 변화를 계산하는 데에 사용할 상태를 snapshot처럼 기억하고 있다는 것이다. **(자바스크립트 클로저!)**

새로운 snapshot은 다음 ‘회차’의 렌더링이 완료되고 그 결과를 반영하여 새롭게 업데이트 될 것이다.

이는 렌더링 과정 중에는 언제나 동일한 snapshot을 참조하기 때문에 계산에 참조하는 상태 값 또한 언제나 동일하다는 것을 의미한다.

다시 코드를 살펴보자.

```jsx
const [count, setCount] = useState(0);

const tripleIncrement = () => {
	setCount(count + 1);
	setCount(count + 1);
	setCount(count + 1);
}

...
```

클릭 이벤트 발생으로 인해 `tripleIncrement` 함수 내부의 코드가 실행되는 시점의 snapshot에 기록된 count 상태의 값은 초기값인 **0**이다.

따라서 `tripleIncrement` 함수 내부에서 참조하는 실제 값은 다음과 같다.

```jsx
const tripleIncrement = () => {
	setCount(0 + 1);
	setCount(0 + 1);
	setCount(0 + 1); // 모든 리렌더링이 끝나고 사용자에게 보여지는 count를 계산하는 로직
}
```

다시 코드를 해석하면, ‘다음 렌더링을 요청한다. count 상태의 값을 1로 업데이트 해라’라는 지시를 세 번 반복하고 있다.

따라서 세 번의 렌더링이 발생하지만, 세 번 모두 count를 1로 업데이트 하기 때문에 count의 값이 3이 되지 않는 것이다.

이 사실을 알고나면 당연히 이 과정이 어딘가 비효율적이라는 생각이 든다.

사용자의 화면에 최종적으로 보이게 되는 count의 값은 마지막으로 계산된 세 번째 렌더링의 결과값이다.

물론 위의 예시에서는 세 번의 계산에서는 count 상태의 값이 모두 동일하기 때문에 앞선 두 번의 `setCount(1)` 가 중복이라고 명확하게 인식되지만,

설령 중간 과정에서 계산되는 상태의 값이 동일하지 않다고 하더라도 결국 마지막에 화면에 남아있는 값이 아닌 나머지 값들을 계산하는 과정(렌더링)은 굳이 필요가 없어 보인다.

이처럼 비효율적인 렌더링을 최소화하기 위해 리액트는 또다른 방법을 사용하고 있다.

### Batching

그 방법이란 다음 렌더링에 수행할 동작을 queue에 추가하는 과정에서의 배치 처리이다.

> React waits until *all* code in the event handlers has run before processing your state updates.
> 

리액트는 불필요한 렌더링 과정을 최소화 하기 위해, 이벤트 핸들러 내의 모든 상태 변화 로직이 실행(setState의 호출)될 때까지 기다린다. 그리고 배치(batch) 처리를 통해 동일한 상태에 대한 중복되는 업데이트 로직을 제거하고 해당 상태의 최종적인 결과를 계산하기 위한 로직만 다음 렌더링 과정에 포함시킨다. 

setState가 호출된 횟수만큼 매번 리렌더링을 수행하는 것이 아니라, 한 번에 처리해도 무방한 setState들을 모았다가 ‘한 회차의 렌더링 과정’에서 결과적으로 필요한 동작만 처리해버리는 것이다.

배치 처리를 고려하여 다시 이벤트 핸들러 함수를 해석해보자.

```jsx
const tripleIncrement = () => {
	setCount(0 + 1);
	setCount(0 + 1);
	setCount(0 + 1); // 렌더링에 최종적으로 포함되는 로직
}
```

결국 위 코드가 배치 처리까지 완료된 이후 최종적으로 의미하는 바는 **단 한 번**의 ‘다음 렌더링에 count 상태의 값을 1로 업데이트 해라’ 가 된다.

## 정리

처음으로 돌아가 ‘setState는 비동기적으로 동작하는가?’ 라는 질문을 다시 떠올려보자.

만약 `tripleIncrement` 이벤트 핸들러 내부에서 `setCount(count + 1)`의 호출마다 리액트가 즉각 (리)렌더링을 수행하여 그때마다 count의 값이 count + 1로 업데이트 되었다면 ‘setState는 동기적으로 동작한다’라는 명제에 이견이 생기지 않았을 것이다. 

그러나 살펴본 것과 같이 setState의 역할은 새로운 렌더링 요청하고 상태 변화 로직을 enqueue 하는 것에 그치고 있다. 

또한 나머지 상태 변화 로직들이 모두 실행되고 배치 처리까지 ‘기다렸다가’ 비로소 렌더링 단계로 넘어가 실질적인 상태 변화가 이뤄지기에 마치 setState가 비동기적으로 동작하는 것으로 착각한 것이다.

보다 정확하게 표현하자면,

> **“setState 함수 자체는 동기적으로 동작하지만, 리액트가 setState 함수를 사용하여 상태를 업데이트 하는 리렌더링 프로세스는 비동기적이다”**
> 

정도로 말 할 수 있지 않을까?

이번 포스팅의 주요 내용은 여기까지다.

## 번외 1. Updator function

우리는 다음과 같이 setState의 인자로 함수를 할당하여 상태를 업데이트 하는 경우, 같은 회차의 렌더링에서도 값이 증가한다는 것을 알고 있다.

```jsx
const tripleIncrement = () => {
	setCount(n => n + 1);  // 1
	setCount(n => n + 1);  // 2
	setCount(n => n + 1);  // 3
}
```

어째서 이런 결과가 나오는 걸까?

> 1. React queues this function to be processed after all the other code in the event handler has run.
2. During the next render, React goes through the queue and gives you the final updated state.
> 

배치 처리되는 일반적인 setState 동작과는 다르게 setter의 인자에 함수를 전달한 경우, 해당 함수 자체가 다음 렌더링을 위한 queue에 추가된다.

따라서 위 예시의 경우, queue에 3개의 `n => n + 1` 함수가 추가된다.

그리고 렌더링 과정에서 각 함수의 계산 결과가 다시 다음 함수의 인자(n)로 전달되어 계산되기 때문에, 동일한 회차의 렌더링임에도 불구하고 updator function을 사용하면 렌더링의 결과가 달라진다.

`tripleIncrement` 라는 이벤트 핸들러의 이름에 맞는 동작을 위해서는 이처럼 updator function을 사용하는 것이 옳은 해결책인 것이다.

## 번외 2. 동일한 값의 업데이트

setState가 언제나 리렌더링을 요청하는 것은 아니다.

새로운 값이 기존의 값과 동일하다면, setState는 리렌더링을 요청하지 않는다.

이때 값의 비교에 [Object.is](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Object/is) 메서드를 사용한다.

따라서 기존의 상태와 새로운 상태의 값이 동일한 원시값이거나, 참조값이 같은 객체라면 setState가 호출되더라도 리렌더링이 이루어지지 않는다.

## 번외 3. Commit 단계

리액트의 UI 업데이트 3단계 중 마지막 단계인 commit에 대해서는 별도의 설명을 하지 않았다.

setState 논의와 직접적인 관계가 없었기 때문이다. 정말 간략하게만 짚고 넘어가자면,

상태 변화에 따라 변경되어야 할 UI를 계산하는 과정(렌더링)이 끝나면 그 결과를 DOM에 반영함으로써 사용자의 화면도 비로소 업데이트 된다.

이 과정에서도 -virtual DOM을 이용한 재조정 과정을 거치며-  굳이 변경이 필요없는 부분은 건너뛰고, 실질적인 변경 사항이 발생한 DOM 노드에 대해서만 그 내역이 업데이트 된다. 그리고 브라우저에 의해 repaint 된다.

이밖에도 UI 업데이트 프로세스와 관련하여 기억하고 있으면 좋을 두 가지 사실은 useEffect와 useRef의 동작 시점이다.

먼저 useEffect에 대한 설명이다.

> Every time your component renders, React will update the screen *and then* run the code inside `useEffect`. In other words, **`useEffect` “delays” a piece of code from running until that render is reflected on the screen**
> 

즉, useEffect 내부에 정의된 코드는 commit 단계까지 완료된 이후 비로소 실행됨을 알 수 있다. 불가피한 경우가 아니라면, 렌더링 단계에서 상태 변화와 관련된 코드를 처리하는 것이 불필요한 리액트 렌더링, 나아가 브라우저의 repaint까지 줄일 수 있을 것이다.

또한 useRef를 사용하는 DOM 조작도 commit 단계와 관련이 있다.

> React sets `ref.current` during the commit. Before updating the DOM, React sets the affected `ref.current` values to `null`. After updating the DOM, React immediately sets them to the corresponding DOM nodes.
> 

render 단계에서 useRef를 사용한 DOM의 참조는 불가능하다. 정확하게는 최초 render에서는 불가능하고, 이후의 리렌더링 과정에서는 최신 DOM 데이터를 참조할 수 없다. render 단계에서 계산된 결과가 DOM에 반영되는 시점은 render가 종료된 이후인 commit 단계이기 때문이다.

React의 setState 메서드는 정말 비동기일까? React 공식문서를 읽어보며 setState가 정확히 어떻게 동작하는지 자세하게 알아보았다.

setState는 비동기일까? (feat. React 공식 문서)

블로그의 SEO를 위해 서치엔진 크롤러에게 사이트 정보를 제공하기 위한 robots.txt와 sitemap.xml의 추가가 필요했다. 

페이지 수가 적은 블로그이기 때문에 하드코딩으로 작성해도 금방이지만, 이를 자동화 해주고 동적인 페이지들의 사이트맵 생성도 쉽게 처리해주는 [next-sitemap](https://www.npmjs.com/package/next-sitemap#generating-dynamicserver-side-sitemaps)라이브러리를 프로젝트에 추가했다.

기본적으로 `next-sitemap.config.js` 파일을 생성하여 간단하게 설정을 추가하고, package.json에 `"postbuild": "next-sitemap"` 스크립트를 추가해주면 된다.

간단하다. 하지만..

정적으로 생성되는 페이지와 반 정적(?)으로 생성되는 페이지들이 섞여있는 이 블로그에서는 어떻게 사이트맵을 생성할 것인지 조금 더 고민해봐야 했다.

## SSG + On-Demand ISR이 혼합된 포스팅 페이지들

현재 블로그의 페이지들은 기본적으로 SSG가 되고 있기 때문에, 앱 빌드 시점에 모든 페이지가 생성된다. 따라서  next-sitemap은 빌드 이후, 빌드 시점에 생성된 모든 페이지들이 포함된 sitemap.xml을 자동 생성할 수 있다. 정적으로 사이트맵 생성이 가능한 것이다.

그러나,

이 블로그는 on-demand ISR을 활용하여 재빌드 없이 새로운 포스팅을 생성할 수 있도록 구성되어 있다. 👉[관련 포스팅: ****블로그에 ISR, On-Demand ISR 적용하기****](https://42blog.vercel.app/posts/6460a75d9ba0b46e99ea988d)

이 때문에 해결해야 할 문제가 발생한다.

이미 생성되어 데이터베이스에 저장되어 있는 포스팅들은 앱 빌드 후 정적 생성되는 sitemap.xml 파일에 포함이 된다. 하지만 나중에 ISR 방식으로 추가 작성한 포스팅은 당연히 빌드 시점에 생성된 sitemap.xml에 포함되지 않게 된다.

새로 포스팅을 작성한 이후에 다시 앱을 빌드하면 next-sitemap이 해당 포스팅 페이지가 추가된 sitemap을 생성해주겠지만, 애초에 포스팅을 작성할 때마다 앱을 재빌드 하지 않기 위해 채택한 ISR 아니었던가.

## 잠시 dynamic sitemaps에 대해..

크롤러는 `도메인/sitemap.xml` 경로에 접근하여 해당 사이트의 정보를 확인한다. 따라서 페이지를 요청하는 시점에 최신 페이지 정보를 담은 sitemap을 생성하여 응답해줄 수 있다면, 동적으로 sitemap을 생성하여 크롤러에게 제공할 수 있다.

‘요청 시 최신 데이터를 렌더링 한 페이지를 생성하여 응답’ 한다? SSR을 활용하면 되겠다.

기본적인 순서는 다음과 같다.

1. sitemap.xml 페이지 생성
2. getServerSideProps 함수 내부에서 DB로부터 포스팅 페이지 주소 목록(post id)을 fetch
3. fetch 해온 데이터로 sitemap.xml 템플릿을 생성하여 응답

물론 next-sitemap이 조금 더 간편하게 해당 작업을 수행하도록 도와주지만, 원리를 파악해보고자 원론적인 방법으로 코드를 작성해보면 다음과 같을 것이다. ([사이트맵 프로토콜](https://www.sitemaps.org/protocol.html#otherformats) 참고)

```tsx
// pages/sitemaps.xml/index.tsx
const createUrl = (route) => `
	<url>
		<loc>https://42blog.vercel.app/posts/${route}</loc>
		// lastmod, priority etc..
	</url>
`;

export const getServerSideProps: GetServerSideProps = async ({req, res}) => {
	const pageIds = await fetchPageIdsFromDB();

	const sitemap = `
		<?xml version="1.0" encoding="UTF-8"?>
			<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
				${pageIds.map((id) => createUrl(id)).join("")}
			</urlset>
	`;

	res.setHeader("Content-Type", "text/xml");
	res.write(sitemap);
	res.end();
	
	return {
		props: {},
	};
}

export default function SiteMap() {}
```

이제 /sitemaps.xml 페이지 접속 시, 포스팅 상세 페이지 주소 목록을 모두 포함하여 동적으로 생성되는 sitemap을 확인할 수 있다.

## 중복 생성되는 Url 줄이기

이제 동적으로도 사이트맵을 생성할 수 있음을 알았다.

그렇다면 Home이나 About 처럼 정적 생성되는 페이지들에 대해서는 정적 사이트맵 생성이 필요할 것이고, 동적(on-demand ISR)으로 생성되는 포스팅 페이지들을 고려하여 SSR을 이용하여 동적 사이트맵 생성을 시키면 될 것이다.

이를 위한 next-sitemap 설정은 다음과 같다.

1. 먼저 동적 사이트맵 생성을 위한 페이지를 만들어준다. 
    
    위에서 구현한 것과 거의 동일하지만, next-sitemap 제공 메서드를 사용하여 조금 더 간편하게 구현 가능하다. 정적 사이트맵 파일과 구분하기 위해 페이지 이름을 `dynamic-sitemap.xml` 로 정했다.
    

```tsx
// pages/dynamic-sitemap.xml/index.tsx
import { getServerSideSitemapLegacy } from 'next-sitemap';
import type { GetServerSideProps } from 'next';

const siteUrl = process.env.PRODUCTION_URL || 'https://42blog.vercel.app';

export const getServerSideProps: GetServerSideProps = async (ctx) => {
  const postIds = await fetchPageIdsFromDB();

  const fields = postIds.map(({ id }) => ({
    loc: `${siteUrl}/posts/${id}`,
    lastmod: new Date().toISOString(),
    priority: 0.7, // 자동 생성 시 부여되는 default priority 값
  }));

  return getServerSideSitemapLegacy(ctx, fields);
};

export default function SiteMap() {}
```

1. 정적 페이지들을 위한 정적 사이트맵 자동 생성 설정을 위해 `next-sitemap.config.js` 파일 추가
    
    `additionalSitemaps` 에 위에서 추가한 동적 사이트맵 생성 페이지의 주소를 추가하여, 크롤러에게 해당 주소에 사이트맵이 추가적으로 존재함을 알려준다.
    

```tsx
// next-sitemap.config.js
const siteUrl = process.env.PRODUCTION_URL || 'https://42blog.vercel.app';

/** @type {import('next-sitemap').IConfig} */
module.exports = {
  siteUrl,
  changefreq: false,
  generateIndexSitemap: false,
  generateRobotsTxt: true,
  robotsTxtOptions: {
    policies: [
      {
        userAgent: '*',
        disallow: [], // 크롤링 되지 않아야 할 경로 배열
      }
    ],
    additionalSitemaps: [ `${siteUrl}/dynamic-sitemap.xml` ]
  },
};
```

단 2개의 파일을 추가하여 쉽게 완료된 것 같으나, 문제가 하나 있다.

1. 앱 빌드 시 Home, About 페이지 외에도 포스팅 페이지들이 정적 생성(SSG) 되기 때문에, 해당 시점에 데이터베이스에 존재하는 포스팅들의 주소도 정적 사이트맵 목록에 추가된다.
2. 이후 크롤러가 `/dynamic-sitemap.xml` 페이지에 접근하면, 사전에 작성해 둔 SSR 로직에 따라 데이터베이스로부터 모든 포스팅 목록을 가져와 동적 생성되는 사이트맵의 목록에 추가한다.

즉, 빌드 이후에 새롭게 추가되는 포스팅 페이지들을 위해 동적 사이트맵 생성을 가능하도록 했지만 이것 때문에 기존에 존재하던 포스팅 페이지들이 사이트맵에 중복으로 포함되게 된다.

해결 방법은 간단하다.

1. 정적 사이트맵 생성 시 포스팅 페이지들을 생성 대상에서 제외한다.
2. 포스팅 페이지들은 동적 사이트맵으로만 생성한다.

이를 위한 약간의 next-sitemap.config 설정 추가가 필요하다.

postbuild 시에 생성될 정적 사이트맵에 포스팅 페이지 경로(/posts/*)와 동적 사이트맵 생성 페이지 경로를 제외하도록 `exclude` 경로 목록을 더해준다.

```tsx
// next-sitemap.config.js
const siteUrl = process.env.PRODUCTION_URL || 'https://42blog.vercel.app';

/** @type {import('next-sitemap').IConfig} */
module.exports = {
  siteUrl,
  changefreq: false,
  generateIndexSitemap: false,
  exclude: [
	  '/dynamic-sitemap.xml',
	  '/posts/*',
	],  // 정적 사이트맵 생성 시 제외할 경로 배열
  generateRobotsTxt: true,
  robotsTxtOptions: {
    policies: [
      {
        userAgent: '*',
        disallow: [],
      }
    ],
    additionalSitemaps: [ `${siteUrl}/dynamic-sitemap.xml` ]
  },
};
```

## 결과물 확인

이제 성공적으로 사이트맵이 생성 됐는지 확인해보자.

먼저, 성공적으로 앱 build 및 next-sitemap의 postbuild가 이뤄졌다면 Next.js의 정적 파일 생성 경로인 `/public` 에 robots.txt 파일과 sitemap.xml 파일이 추가된다.

배포가 완료 됐다면 각각의 경로에 접속하여 의도한대로 해당 파일들이 작성 됐는지 확인해볼 수 있다.

(`/posts/create`, `/posts/edit` 페이지는 admin 기능이기 때문에 크롤링이 불가능하도록 disallow 경로로 추가해뒀다.)

- robots.txt 👉 https://42blog.vercel.app/robots.txt
- sitemap.xml 👉 https://42blog.vercel.app/sitemap.xml
- dynamic-sitemap.xml 👉  https://42blog.vercel.app/dynamic-sitemap.xml
    - 페이지 접근 시 SSR 시간, 약간의 딜레이가 발생하는 것을 알 수 있다.

on-demand ISR 방식을 사용하는 블로그에서는 어떻게 sitemap과 robots.txt을 구성해야 성공적으로 크롤링 될 수 있을지 그 방법을 고민해보고 작성한 포스팅

On-Demand ISR을 사용하는 블로그의 sitemap 생성하기

블로그를 만들기 시작하며 가장 먼저 들었던 생각이 ‘포스팅을 작성하거나 수정할 때마다 빌드를 다시 하고싶지 않다’ 였다. 그렇다고 블로그에서 SEO를 포기하고 client-side rendering 페이지를 만들 수는 없었다. 한편 server-side rendering (getServerSideProps를 활용한) 페이지는 매번 최신의 데이터를 보여줄 수야 있겠지만, ‘거의’ 바뀌지 않을 페이지를 모든 요청 마다 새로 렌더링 하는 건 서버 자원의 낭비다.

다행히 Nextjs에는 ISR 방식이 있었고, **`v12.2.0`**부터는 ‘On-Demand ISR’을 제공하고 있었다. 결론적으로는 On-Demand ISR을 활용해서 내가 원하는 방식으로 블로그를 구현할 수 있었다.

## ISR, Incremental Static Regeneration

‘점진적 정적 재생성’ 정도로 해석할 수 있을 것 같다. 의미 그대로 최초 빌드 시에 생성된 정적 페이지(SSG)를 시간이 흐르고 나서 다시 생성 하는 방식이다. ISR 방식으로는 일부분의 수정을 위해 전체 앱을 재빌드 할 필요없이 ‘페이지 단위’의 정적 페이지 재생성이 가능한 것이다.

근본적으로는 SSG이기 때문에 동일하게 getStaticProps를 사용하면 된다. 거기에 revalidate라는 prop만 추가하면 되는데 ‘트리거 발생 후 얼마 뒤에 재생성을 진행할지’ 시간을 설정하면 된다.

이때 재생성의 트리거는 해당 페이지에 대한 요청, 즉 해당 페이지에 트래픽이 발생한 시점이다. 따라서 아래의 예시는 ‘방문자가 해당 페이지에 접근하고 나서 60초 뒤에 해당 페이지를 재생성 한다’를 의미한다.

```jsx
export async function getStaticProps() {
  const res = await fetch('https://.../posts');
  const posts = await res.json();
 
  return {
    props: {
      posts,
    },
    revalidate: 60,
  };
}
```

실제 동작 과정은 다음과 같을 것이다.

1. 페이지에 방문자가 발생하면 최초 빌드 시에 생성되어 캐싱 된 정적 페이지가 서빙 된다.
    - 60초 이내로 또다른 방문자가 발생해도 여전히 같은 페이지가 서빙 된다.
2. 60초가 지나면 nextjs가 백그라운드에서 해당 페이지를 재생성 한다.
3. 새로운 페이지가 생성되면 기존 캐시를 무효화하고, 재생성된 페이지가 서빙 된다.
4. (새로운 방문자 발생하면 위의 과정을 반복)

트래픽이 발생한 시점에만 재성성이 트리거 되니 서버 리소스 사용이 줄어 합리적인 방식이라고 할 수 있다. 그러나 여전히 탐탁치 않은 지점들이 있었다.

1. 트리거를 유발한 최초 방문자는 revalidate 시간이 지나고 새로고침을 하지 않으면 재생성 된 페이지를 볼 수 없다.
2. 페이지에 업데이트 된 내용이 전혀 없는 경우에도 트래픽이 발생하여 조건을 충족하면 계속해서 동일한 페이지를 재생성 해야 한다. 서버 자원의 낭비다.

사실 1번의 경우 글을 수정한 다음 내가 해당 페이지를 한 번 방문하면 다음 방문자들에게 업데이트는 반영 되겠지만, 여전히 2번 문제는 피할 수가 없다.

내가 원하는 블로그를 만들기에는 반쪽 짜리 해결책인 것 같다.

## On-Demand ISR

ISR인데 on-demand라면, 요청이 있을 때만 정적 페이지를 재생성할 수 있을 것 같았고, 실제로도 그랬다.

그럼 그 재생성 ‘요청’을 어떻게 서버에 전달할까? 당연하게도 api를 통해서 가능하다.

```jsx
// pages/api/revalidate.js
export default async function handler(req, res) {
  try {
    await res.revalidate('/path-to-revalidate');
    return res.json({ revalidated: true });
  } catch (err) {
    return res.status(500).send('Error revalidating');
  }
}
```

이처럼 api를 작성해주면 이제 /api/revalidate 를 호출하는 것만으로 해당 페이지를 재생성 할 수 있게 된다. (현재는 필요 시 클라이언트에서 직접 revalidate api를 호출하도록 해놨지만, 웹훅을 사용하여 DB에 업데이트가 발생하면 api를 호출하는 방식으로 변경해도 좋을 것 같다)

동작 순서는 다음과 같다.

1. 포스트 수정 후, revalidate api 호출
2. nextjs가 백그라운드에서 해당 페이지를 재생성
3. 페이지 생성이 완료되면 기존 캐시를 무효화하고 새로운 페이지 서빙

on-demand ISR을 활용하면 직접 api를 호출하는 경우 외에는 페이지를 재생성 할 일이 없으니 서버 자원도 필요한 때에만 사용할 수 있다.

이제 정적 페이지 생성을 통해 빠른 서빙과 SEO를 챙길 수도 있고, 새로운 데이터를 추가하거나 부분적인 수정 사항이 생겨도 전체 앱을 재빌드 할 필요도 없어졌고, 서버 자원의 낭비 없이 필요한 페이지만 업데이트 할 수도 있다.

## getStaticPaths Fallback

ISR을 적용할 때 고려해야할 부분이 하나 더 있다.

기존에 존재하던 포스트를 수정하는 경우 해당 페이지의 경로가 getStaticPaths에 의해 최초 빌드 시 정적 생성되어 있으니 문제가 없지만, 새롭게 포스트를 추가하는 경우 해당 포스트의 경로는 빌드 시점에 getStaticPaths에 의해 생성된 경로 목록에 존재하지 않는다.

따라서 getStaticPaths의 fallback 설정을 통해 ISR로 새롭게 추가된 경로에 접근 했을 때 화면 처리를 어떻게 할 것인지에 대한 적절한 설정이 필요하다.

1. fallback: **`false`** 최초 빌드 시 getStaticPaths에 포함되지 않은 모든 경로에 대한 요청에 404 페이지를 응답한다. 새로운 포스트 작성 후 재빌드 없이 해당 경로에 접근할 수 있어야 하는 현재 목적과 맞지 않다.
2. fallback: **`blocking`** getStaticProps에 포함되지 않은 경로인 경우, 백그라운드에서 해당 페이지의 렌더링(SSR) 진행 후 완료되어 브라우저에 html이 응답될 까지 그 상태로 대기하다가 완성된 페이지를 보여 준다.
3. fallback: **`true`** 페이지 컴포넌트에서는 next router의 isFallback 프로퍼티를 활용하여 fallback 버전의 화면을 구성할 수 있다. getStaticProps에 포함되지 않은 경로인 경우, 이 fallback 버전의 페이지를 보여주다가 브라우저가 해당 페이지의 JSON을 응답받으면 해당 데이터로 페이지를 다시 그린다.

**`blocking`**, **`true`** 둘 다 최초 동작 하여 경로를 추가한 이후로는 정적 경로 목록에 포함되기 때문에 이후부터는 기존에 정적 생성된 페이지들과 동일하게 동작한다.

이 블로그의 경우 처음에는 아무것도 화면에 표시되지 않은 채 기다려야하는 사용자 경험을 고려해서 fallback을 true로 설정하고 로딩 문구를 보여주도록 했다. 그런데 다시 생각해보니 이미 revalidate가 완료된 시점에 해당 페이지는 재생성이 되었을 터였다. 따라서 없는 경로에 대한 요청이 발생하더라도 해당 페이지가 완성될 때까지 기다리는 시간이 거의 필요없기 때문에 오히려 blocking 모드로 어떤 화면 전환도 발생하지 않도록 하는 것이 더 좋겠다는 판단이 들었다.

블로그에 새로운 포스팅을 작성할 때마다 앱 빌드를 다시 하지 않기 위해, Next.js의 ISR 방식을 사용하여 생성과 동시에 게시물을 업데이트 할 수 있는 방법을 알아보자