시지프의 돌을 굴리며

2025년 하반기(7~12월) 회고


## React Server Component란


React Server Component(RSC)는 서버에서 렌더링되는 React 컴포넌트다. Next.js App Router는 기본적으로 모든 컴포넌트를 Server Component로 취급한다.


기존 React 앱은 모든 컴포넌트가 브라우저에서 실행되었다. Server Component는 서버에서 렌더링을 완료한 뒤 결과만 클라이언트로 보낸다. 이를 통해 JavaScript 번들 크기를 줄이고 초기 로딩 속도를 개선할 수 있다.


## 왜 필요한가


기존 React 앱에서는 데이터를 가져오기 위해 다음과 같은 과정을 거친다.

1. 브라우저가 빈 HTML을 받는다
2. JavaScript 번들을 다운로드하고 실행한다
3. 컴포넌트가 마운트되면 `useEffect`로 API를 호출한다
4. 데이터를 받아서 화면을 업데이트한다

이 과정에서 사용자는 로딩 상태를 보게 되고, JavaScript 번들 크기가 커질수록 초기 로딩이 느려진다.


Server Component는 이 문제를 해결한다. 서버에서 데이터를 가져오고 렌더링까지 완료한 뒤 결과만 보내므로, 브라우저는 즉시 컨텐츠를 표시할 수 있다.


## Server Component의 장점


Server Component는 다음과 같은 장점을 제공한다.

- 데이터 소스에 가까운 위치에서 데이터를 가져온다. 서버는 데이터베이스나 내부 API와 같은 네트워크에 있으므로 데이터 조회가 빠르다.
- **클라이언트로 전송하는 JavaScript 크기를 줄인다.** 서버에서만 실행되는 코드는 브라우저로 보내지 않는다.
- 초기 페이지 로딩이 빠르다. HTML이 서버에서 생성되어 오므로 First Contentful Paint가 개선된다.
- 보안이 강화된다. API 키나 토큰 같은 민감한 정보를 서버에만 두고 사용할 수 있다.

## Server Component의 특징


Server Component에서는 다음과 같은 작업을 할 수 있다.


```typescript
import { db } from '@/lib/database'

export default async function ProductList() {
  // 데이터베이스 직접 조회
  const products = await db.query('SELECT * FROM products')

  return (
    <ul>
      {products.map(product => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  )
}
```


위 코드에서 컴포넌트를 `async` 함수로 선언하고 데이터베이스를 직접 조회한다. 이 코드는 서버에서만 실행되므로 데이터베이스 연결 정보가 클라이언트에 노출되지 않는다.


Server Component는 컴포넌트 함수 자체를 `async`로 만들 수 있다. 별도의 데이터 페칭 함수 없이 컴포넌트 내부에서 바로 비동기 작업을 수행할 수 있다.


## Server Component의 제약사항


Server Component는 서버에서만 실행되기 때문에 클라이언트 전용 기능을 사용할 수 없다. 다음과 같은 것들은 Server Component에서 사용할 수 없다.

- 상태 관리 훅: `useState`, `useReducer`
- 생명주기 훅: `useEffect`, `useLayoutEffect`
- 이벤트 핸들러: `onClick`, `onChange`
- 브라우저 전용 API: `window`, `localStorage`, `document`
- 사용자 정의 훅: 위 기능들을 사용하는 커스텀 훅
- React Context: `useContext`

예를 들어 Server Component에서 `useEffect`를 사용하려고 하면 다음과 같은 에러가 발생한다.


```plain text
Error: useEffect only works in Client Components. Add the "use client" directive at the top of the file to use it.
```


이런 기능이 필요하다면 해당 컴포넌트를 Client Component로 만들어야 한다. 파일 최상단에 `'use client'`를 추가하면 된다.


```typescript
// 에러 발생
export default function ProductList() {
  useEffect(() => {
    console.log('마운트됨')
  }, [])

  return <div>상품 목록</div>
}
```


```typescript
// ✓ 정상 작동
'use client'

export default function ProductList() {
  useEffect(() => {
    console.log('마운트됨')
  }, [])

  return <div>상품 목록</div>
}
```


Server Component는 HTML을 생성하는 데 집중하고, 인터랙션이 필요한 부분은 Client Component로 분리하는 것이 권장된다.


## Client Component란


하지만 모든 것을 Server Component로 만들 수는 없다. 사용자와의 상호작용, 상태 관리, 브라우저 API 사용 등은 클라이언트에서만 가능하다.


Client Component는 브라우저에서 실행되는 React 컴포넌트다. 다음과 같은 기능을 사용할 때는 Client Component가 필요하다.

- `useState`, `useReducer` 같은 상태 관리
- `useEffect`, `useLayoutEffect` 같은 생명주기 훅
- `onClick`, `onChange` 같은 이벤트 핸들러
- `window`, `localStorage` 같은 브라우저 전용 API
- 사용자 정의 훅

## 'use client' 디렉티브


Client Component를 만들려면 파일 최상단에 `'use client'` 디렉티브를 추가한다.


```typescript
'use client'

import { useState } from 'react'

export default function LikeButton() {
  const [likes, setLikes] = useState(0)

  return (
    <button onClick={() => setLikes(likes + 1)}>
      좋아요 {likes}
    </button>
  )
}
```


`'use client'`는 서버와 클라이언트 코드 사이의 경계를 선언한다. 이 디렉티브가 있는 파일과 그 파일이 import하는 모든 모듈은 클라이언트 번들에 포함된다.


`'use client'`를 추가하지 않으면 기본적으로 Server Component로 동작한다. Next.js App Router는 Server Component를 기본값으로 사용한다.


## 언제 무엇을 사용할지


다음 표는 어떤 상황에 어떤 컴포넌트를 사용해야 하는지 정리한 것이다.


| 작업                               | Server Component | Client Component |
| -------------------------------- | ---------------- | ---------------- |
| 데이터 가져오기                         | ✓                |                  |
| 백엔드 리소스 직접 접근                    | ✓                |                  |
| 민감한 정보를 서버에 보관                   | ✓                |                  |
| 큰 의존성을 서버에 유지                    | ✓                |                  |
| 상태 관리 (`useState`, `useReducer`) |                  | ✓                |
| 생명주기 훅 (`useEffect`)             |                  | ✓                |
| 이벤트 핸들러                          |                  | ✓                |
| 브라우저 전용 API                      |                  | ✓                |
| 사용자 정의 훅                         |                  | ✓                |


기본적으로 Server Component를 사용하고, 인터랙션이 필요한 부분만 Client Component로 분리하는 것이 권장된다.


## Server Component와 Client Component 조합하기


Server Component와 Client Component는 함께 사용할 수 있다.


### Server Component에서 Client Component로 데이터 전달하기


Server Component는 Client Component에 props로 데이터를 전달할 수 있다. 단, props는 직렬화 가능한 값이어야 한다.


```typescript
// app/page.tsx (Server Component)
import LikeButton from './like-button'

export default async function PostPage({ params }) {
  const post = await getPost(params.id)

  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
      <LikeButton initialLikes={post.likes} />
    </article>
  )
}
```


```typescript
// app/like-button.tsx (Client Component)
'use client'

import { useState } from 'react'

export default function LikeButton({ initialLikes }) {
  const [likes, setLikes] = useState(initialLikes)

  return (
    <button onClick={() => setLikes(likes + 1)}>
      좋아요 {likes}
    </button>
  )
}
```


위 코드에서 Server Component인 `PostPage`는 서버에서 포스트 데이터를 가져온다. 그리고 초기 좋아요 수를 `LikeButton`에 전달한다. `LikeButton`은 Client Component이므로 브라우저에서 상태를 관리하며 사용자의 클릭에 반응한다.


### Client Component 안에 Server Component 넣기


Client Component는 직접적으로 Server Component를 import할 수 없다. 하지만 `children` prop을 통해 Server Component를 받을 수 있다.


```typescript
// app/modal.tsx (Client Component)
'use client'

export default function Modal({ children }) {
  return (
    <div className="modal">
      {children}
    </div>
  )
}
```


```typescript
// app/page.tsx (Server Component)
import Modal from './modal'
import ServerContent from './server-content'

export default function Page() {
  return (
    <Modal>
      <ServerContent />
    </Modal>
  )
}
```


위 패턴에서 `Modal`은 Client Component지만 `children`으로 무엇을 받을지는 모른다. `ServerContent`는 Server Component로서 서버에서 렌더링된다. `Modal`은 단지 렌더링된 결과를 받아서 표시할 뿐이다.


이 패턴을 사용하면 Client Component와 Server Component를 독립적으로 렌더링할 수 있다. Client Component가 재렌더링되어도 Server Component는 서버에서 이미 렌더링되었기 때문에 다시 렌더링되지 않는다.


## 주의사항


### Client Component는 양쪽에서 실행된다


Server Component는 서버에서만 실행되지만, Client Component는 서버와 클라이언트 양쪽에서 실행된다.

- 서버: 초기 HTML 생성(사전 렌더링)을 위해 1번 실행
- 클라이언트: 하이드레이션을 위해 1번 실행

따라서 Client Component에는 브라우저 전용 API(`window`, `localStorage` 등)를 바로 사용하면 안 된다. 서버에서 실행될 때 에러가 발생한다. `useEffect` 안에서 사용하거나 조건부로 체크해야 한다.


```typescript
'use client'

export default function MyComponent() {
  // 에러: 서버에서 실행 시 window가 없음
  const width = window.innerWidth

  // useEffect는 클라이언트에서만 실행됨
  useEffect(() => {
    const width = window.innerWidth
  }, [])
}
```


### Client Component에서 Server Component를 import할 수 없다


Client Component는 다른 Client Component만 직접 import할 수 있다. Server Component를 사용하려면 `children`이나 props로 받아야 한다.


```typescript
// 불가능
'use client'
import ServerComponent from './server-component'

export default function ClientComponent() {
  return <ServerComponent />
}
```


```typescript
// children으로 받기
'use client'

export default function ClientComponent({ children }) {
  return <div>{children}</div>
}
```


### 직렬화 가능한 값만 전달할 수 있다


Server Component에서 Client Component로 props를 전달할 때는 직렬화 가능한 값만 보낼 수 있다. 함수, 클래스 인스턴스, Symbol 같은 값은 전달할 수 없다.


```typescript
// 불가능
<ClientComponent
  onClick={() => {}}  // 함수 전달 불가
  date={new Date()}   // Date 객체 전달 불가
/>

// 가능
<ClientComponent
  count={42}              // 숫자
  name="hello"            // 문자열
  data={{ id: 1 }}        // 객체
  items={[1, 2, 3]}       // 배열
  timestamp="2024-01-01"  // ISO 문자열
/>
```


이는 서버에서 컴포넌트를 렌더링한 결과를 JSON 형태로 클라이언트에 전송하기 때문이다. JSON으로 변환할 수 없는 값은 전달할 수 없다.


### 컴포넌트 계층 구조 설계


Client Component를 최대한 말단에 배치하는 것이 좋다. 상위에 Client Component가 있으면 그 하위의 모든 컴포넌트가 JavaScript 번들에 포함되어 용량이 커진다.


```typescript
// 비효율적인 구조
'use client'

export default function Page() {
  const [open, setOpen] = useState(false)

  return (
    <div>
      <Header />        {/* JavaScript 번들에 포함 */}
      <Content />       {/* JavaScript 번들에 포함 */}
      <Footer />        {/* JavaScript 번들에 포함 */}
      <Modal open={open} setOpen={setOpen} />
    </div>
  )
}
```


위 코드는 `Modal`의 상태 관리 때문에 전체를 Client Component로 만들었다. 이렇게 하면 `Header`, `Content`, `Footer` 같은 정적 컴포넌트까지 모두 JavaScript 번들에 포함되어 파일 크기가 커진다.


```typescript
// 효율적인 구조
export default function Page() {
  return (
    <div>
      <Header />        {/* Server Component */}
      <Content />       {/* Server Component */}
      <Footer />        {/* Server Component */}
      <ModalButton />   {/* Client Component */}
    </div>
  )
}
```


```typescript
// modal-button.tsx
'use client'

export default function ModalButton() {
  const [open, setOpen] = useState(false)

  return (
    <>
      <button onClick={() => setOpen(true)}>열기</button>
      <Modal open={open} setOpen={setOpen} />
    </>
  )
}
```


위 코드는 상태가 필요한 부분만 Client Component로 분리했다. `Header`, `Content`, `Footer`는 Server Component로 남아있어 JavaScript 번들에 포함되지 않는다. 이렇게 하면 번들 크기가 줄어들고 Time to Interactive(TTI)가 개선된다.


**핵심은 인터랙션이 필요한 최소한의 부분만 Client Component로 만드는 것이다.** 페이지 전체를 Client Component로 만들지 말고, 버튼이나 입력 폼처럼 실제로 상호작용이 필요한 부분만 분리한다.


## 참고 자료

- [Next.js 공식 문서 - Server Components](https://nextjs.org/docs/app/building-your-application/rendering/server-components)
- [Next.js 공식 문서 - Client Components](https://nextjs.org/docs/app/building-your-application/rendering/client-components)
- [Next.js 공식 문서 - Composition Patterns](https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns)


서버에서 렌더링하고 JavaScript 번들 줄이기

React Server Component

useMemo, useCallback 없이 자동 최적화되는 React 19

React Compiler 톺아보기

참조 동등성이 리렌더링을 결정하는 방식

왜 React는 객체 비교에 민감할까

몰입과 실험, 기본기의 중요성을 깨달은 한 학기

2025년 3~6월 회고


![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/context-api-usereducer-flux/image-1762678308451-1.webp)


## 서론


React에서 여러 컴포넌트가 공유하는 상태를 관리할 때 prop-drilling 문제에 직면한다. 부모에서 자식으로, 또 그 자식으로 props를 계속 전달하다 보면 코드가 복잡해지고 유지보수가 어려워진다.


Flux 패턴은 이런 상태 관리를 체계적으로 수행하기 위한 아키텍처다. 데이터 흐름을 단방향으로 유지해서 상태 변경을 예측 가능하게 만든다. Redux가 Flux 패턴을 기반으로 만들어졌지만, 추가 라이브러리 없이 React의 Context API와 `useReducer`만으로도 같은 패턴을 구현할 수 있다.


본 글에서는 Context API와 `useReducer`를 활용해 Flux 패턴을 구현하는 방법을 다룬다.


## 왜 Flux 패턴인가


과거 Backbone 같은 프레임워크는 이벤트 기반으로 상태를 관리했다. Model이 변경되면 이벤트를 발생시키고, 여러 View가 이 이벤트를 구독해서 반응하는 구조다.


![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/context-api-usereducer-flux/image-1762678308451-1.webp)


문제는 이벤트가 연쇄적으로 발생할 때다. View A가 Model을 변경하면, 그게 View B를 업데이트하고, View B가 다시 다른 Model을 변경하고, 이게 또 View C를 업데이트한다. 상태 변경의 흐름을 추적하기 어렵고, 버그가 발생했을 때 원인을 찾기 힘들다.


Flux는 단방향 데이터 흐름으로 이 문제를 해결한다. 상태를 변경하는 방법이 하나로 제한되고, 그 과정을 추적할 수 있다.


## Flux 패턴의 이해


![https://www.youtube.com/watch?v=N9PT9iNTZAE&list=PLuHgQVnccGMB-iGMgONoRPArZfjRuRNVc&index=2&ab_channel=생활코딩](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/context-api-usereducer-flux/image-1762678312027-2.webp)


Flux 패턴은 4가지 요소로 구성된다.


### Action


애플리케이션에서 발생하는 이벤트나 사용자 상호작용을 표현한다. 보통 `type`과 `payload`를 포함한다. 그림에서 배달부로 표현되듯이, **액션은 정보를 담아서 Store로 전달하는 택배 상자** 같은 역할을 한다.


```javascript
// 카운터 증가
{ type: 'INCREMENT', payload: 1 }

// 사용자 로그인
{ type: 'USER_LOGIN', payload: { userId: 123, userName: 'john' } }

// 할일 추가
{ type: 'ADD_TODO', payload: { id: 1, text: '장보기', completed: false } }

// 데이터 로딩 시작
{ type: 'FETCH_DATA_START' }
```


`type`은 무슨 일이 일어났는지 알려주고, `payload`는 필요한 데이터를 전달한다. `payload`가 필요 없는 액션도 있다.


### Dispatcher


액션을 받아서 Store로 전달하는 중앙 허브다. 모든 액션이 Dispatcher를 거치기 때문에 상태 변경을 일관되게 처리할 수 있다. 그림에서 카운터 직원으로 표현되듯이, **배달부(액션)가 가져온 택배를 확인하고 처리 담당자(reducer)에게 넘겨주는 관문** 역할을 한다.


```javascript
// 컴포넌트에서 사용
const handleClick = () => {
  dispatch({ type: 'INCREMENT', payload: 1 });
};

// 여러 액션을 순차적으로 dispatch
const handleLogin = async (credentials) => {
  dispatch({ type: 'LOGIN_START' });

  try {
    const user = await loginAPI(credentials);
    dispatch({ type: 'LOGIN_SUCCESS', payload: user });
  } catch (error) {
    dispatch({ type: 'LOGIN_FAILURE', payload: error.message });
  }
};
```


`dispatch` 함수는 동기적으로 동작한다. 액션을 받으면 즉시 reducer를 호출해서 상태를 업데이트한다.


### Store


애플리케이션의 상태와 상태 변경 로직을 관리한다. Dispatcher로부터 액션을 받으면 상태를 업데이트하고, 구독자에게 변경을 알린다. **상태를 직접 수정하지 않고 항상 새로운 객체를 반환한다.**


그림에서 Store는 여러 요소를 포함하는 큰 상자로 표현된다.

- `state` (책): 현재 상태 데이터를 기록
- `reducer` (펜으로 쓰는 사람): 액션을 보고 새로운 상태를 작성
- `dispatch` (카운터): 액션을 받아서 reducer로 전달
- `getState` (카운터): 컴포넌트에게 현재 state를 제공
- `subscribe` (카운터): 상태 변경을 구독하는 컴포넌트 등록

```javascript
// 현재 상태
const currentState = {
  count: 5,
  user: null,
  todos: []
};

// INCREMENT 액션을 받으면
const action = { type: 'INCREMENT', payload: 1 };

// reducer가 새 상태를 반환
const newState = {
  count: 6,        // 변경됨
  user: null,      // 유지
  todos: []        // 유지
};

// currentState !== newState (다른 객체)
// currentState.user === newState.user (같은 참조)
```


변경되지 않은 부분은 같은 참조를 유지한다. 이를 통해 React는 어떤 부분이 바뀌었는지 확인할 수 있다.


### View


사용자 인터페이스를 구성하고 Store의 상태를 화면에 표시한다. 사용자 상호작용을 액션으로 변환해서 Dispatcher로 보낸다. React 컴포넌트가 View 역할을 한다. 그림에서 render(삽으로 땅 파는 사람)로 표현되듯이, **Store의 state를 받아서 실제 UI를 구축하는 작업자** 역할을 한다.


```javascript
const TodoList = () => {
  // Store에서 상태 읽기
  const { state, dispatch } = useContext(AppContext);

  // 사용자 상호작용을 액션으로 변환
  const handleAddTodo = (text) => {
    dispatch({
      type: 'ADD_TODO',
      payload: { id: Date.now(), text, completed: false }
    });
  };

  const handleToggleTodo = (id) => {
    dispatch({ type: 'TOGGLE_TODO', payload: id });
  };

  // Store의 상태를 화면에 표시
  return (
    <div>
      <h1>할 일: {state.todos.length}개</h1>
      <ul>
        {state.todos.map(todo => (
          <li key={todo.id} onClick={() => handleToggleTodo(todo.id)}>
            {todo.text}
          </li>
        ))}
      </ul>
    </div>
  );
};
```


View는 상태를 직접 변경하지 않는다. 항상 `dispatch`를 통해 액션을 보내고, Store가 상태를 업데이트하면 자동으로 리렌더링된다.


## Context API와 useReducer로 구현하기


Context API는 컴포넌트 트리 전체에 데이터를 전달하는 방법을 제공한다. `useReducer`는 복잡한 상태 로직을 관리하는 훅이다. 이 둘을 합치면 Flux 패턴을 구현할 수 있다.


### 프로젝트 구조


```plain text
project-root/
├── src/
│   ├── components/
│   │   ├── Counter.js
│   ├── context/
│   │   ├── AppContext.js
│   ├── reducers/
│   │   ├── appReducer.js
│   ├── actions/
│   │   ├── actionTypes.js
│   │   ├── actions.js
│   ├── App.js
│   ├── index.js
```


### 1. Reducer 작성 (Store)


`reducers/appReducer.js` 파일을 만든다. Reducer는 현재 상태와 액션을 받아서 새로운 상태를 반환하는 함수다.


```javascript
export const initialState = {
  count: 0,
};

export const appReducer = (state, action) => {
  switch (action.type) {
    case 'INCREMENT':
      return { ...state, count: state.count + 1 };
    case 'DECREMENT':
      return { ...state, count: state.count - 1 };
    default:
      return state;
  }
};
```


`action.type`을 확인해서 어떤 상태 변경을 수행할지 결정한다. `{ ...state }`로 기존 상태를 복사하고, 변경할 부분만 덮어쓴다. 원본 상태를 직접 수정하지 않는 것이 핵심이다.

> state.count += 1 같은 직접 수정은 React가 변경을 감지하지 못한다. 항상 새 객체를 반환해야 한다.
> Reducer는 순수 함수여야 한다. fetch 같은 비동기 로직은 컴포넌트에서 처리하고, reducer는 결과 데이터만 받아서 상태를 업데이트한다.

### 2. Action 정의


`actions/actionTypes.js`에 액션 타입을 상수로 정의한다.


```javascript
export const INCREMENT = 'INCREMENT';
export const DECREMENT = 'DECREMENT';
```


문자열을 직접 쓰지 않고 상수로 정의하는 이유는 두 가지다. 첫째, 오타를 방지한다. `'INCREMNET'` 같은 실수를 컴파일 단계에서 잡을 수 있다. 둘째, 나중에 액션 타입을 변경할 때 한 곳만 수정하면 된다.


`actions/actions.js`에 액션 생성자 함수를 만든다.


```javascript
import { INCREMENT, DECREMENT } from './actionTypes';

export const increment = () => ({
  type: INCREMENT,
});

export const decrement = () => ({
  type: DECREMENT,
});
```


컴포넌트에서 `dispatch({ type: 'INCREMENT' })` 대신 `dispatch(increment())`를 사용할 수 있다. 나중에 payload를 추가하기도 쉽다.


```javascript
export const increment = (amount = 1) => ({
  type: INCREMENT,
  payload: amount,
});
```


### 3. Context 생성 (Dispatcher + Store 연결)


`context/AppContext.js`에서 Context를 만들고 Provider를 정의한다.


```javascript
import { createContext, useReducer } from 'react';
import { appReducer, initialState } from '../reducers/appReducer';

const AppContext = createContext();

const AppProvider = ({ children }) => {
  const [state, dispatch] = useReducer(appReducer, initialState);

  return (
    <AppContext.Provider value={{ state, dispatch }}>
      {children}
    </AppContext.Provider>
  );
};

export { AppContext, AppProvider };
```


`useReducer`는 `[state, dispatch]`를 반환한다. `state`는 현재 상태고, `dispatch`는 액션을 보내는 함수다. 이 둘을 Context로 제공하면 하위 컴포넌트 어디서든 접근할 수 있다.


### 4. Component에서 사용 (View)


`components/Counter.js`에서 Context를 사용한다.


```javascript
import { useContext } from 'react';
import { AppContext } from '../context/AppContext';
import { increment, decrement } from '../actions/actions';

const Counter = () => {
  const { state, dispatch } = useContext(AppContext);

  return (
    <div>
      <p>Count: {state.count}</p>
      <button onClick={() => dispatch(increment())}>+</button>
      <button onClick={() => dispatch(decrement())}>-</button>
    </div>
  );
};

export default Counter;
```


`useContext(AppContext)`로 `state`와 `dispatch`를 가져온다. 버튼을 클릭하면 `dispatch`로 액션을 보낸다.

> dispatch는 액션 객체를 받는다. dispatch(INCREMENT) 같이 타입만 전달하면 reducer에서 action.type이 undefined가 된다. dispatch({ type: INCREMENT }) 또는 dispatch(increment())를 사용한다.

### 5. Provider 적용


`App.js`에서 `AppProvider`로 컴포넌트를 감싼다.


```javascript
import React from 'react';
import { AppProvider } from './context/AppContext';
import Counter from './components/Counter';

const App = () => (
  <AppProvider>
    <Counter />
  </AppProvider>
);

export default App;
```


`index.js`에서 앱을 렌더링한다.


```javascript
import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';

ReactDOM.render(<App />, document.getElementById('root'));
```


## 전체 동작 흐름


사용자가 `+` 버튼을 클릭하면 다음 과정이 실행된다.


```mermaid
graph TD
    A[View<br/>Counter 컴포넌트] -->|사용자 클릭| B[Action<br/>increment]
    B -->|type: INCREMENT| C[Dispatcher<br/>dispatch]
    C -->|액션 전달| D[Reducer<br/>appReducer]
    D -->|새 상태 반환| E[Store<br/>state]
    E -->|리렌더링| A
```


각 요소의 세부 동작을 보면 다음과 같다.

1. View에서 사용자가 버튼 클릭
2. Action에서 `increment()`가 `{ type: 'INCREMENT' }` 액션 객체 반환
3. Dispatcher에서 `dispatch`가 액션을 `appReducer`로 전달
4. Reducer에서 `action.type`을 확인하고 `{ ...state, count: state.count + 1 }` 반환
5. Store에서 `useReducer`가 새 상태로 업데이트하고 Context 값 변경
6. View에서 Counter 컴포넌트가 리렌더링되어 새 count 값 표시

이 흐름은 계속 반복된다. 사용자가 다시 버튼을 클릭하면 같은 순환이 다시 시작된다.


## 마무리


이 글은 "전역 상태 관리 라이브러리를 꼭 사용해야 할까?"라는 의문에서 시작했다. Redux, Zustand, Recoil 같은 라이브러리를 추가하기 전에, React 자체 기능만으로 충분한지 알고 싶었다.


검색 결과 Context API와 `useReducer`를 조합하면 Flux 패턴을 구현할 수 있었다. Action, Dispatcher, Store, View로 이어지는 단방향 데이터 흐름을 React 내장 기능만으로 만들 수 있다. Redux가 제공하는 핵심 패턴을 추가 라이브러리 없이 구현 가능하다는 점이 고무적이다.


물론 Redux를 완벽하게 대체할 수 있는지는 이 글에서 깊이 있게 검증하지 않았다. Redux DevTools, 미들웨어 생태계, 성능 최적화 같은 부분에서는 여전히 Redux가 우위에 있을 수 있다. 하지만 중소규모 프로젝트에서 단순히 상태 관리 패턴이 필요하다면, Context API와 `useReducer`로 충분히 해결할 수 있다는 걸 확인했다.


## references


[https://velog.io/@j7papa/Context-API-useReducer](https://velog.io/@j7papa/Context-API-useReducer)


[https://youtu.be/BCD2irXaVoE?si=bt6dFuSF67iceULb](https://youtu.be/BCD2irXaVoE?si=bt6dFuSF67iceULb)


[https://medium.com/@amodes/redux-redux-toolkit-context-api-flux-what-problems-they-solve-and-when-to-use-them-94131ad1398b](https://medium.com/@amodes/redux-redux-toolkit-context-api-flux-what-problems-they-solve-and-when-to-use-them-94131ad1398b)



Redux 없이 단방향 데이터 흐름 만들기

Context API + useReducer로 flux 패턴 구현하기


## 개요


TypeScript의 `enum`을 사용하면 번들 크기가 예상보다 커지는 현상이 발견되었다. 특히 미사용 enum이 최종 번들에 포함되어 tree shaking이 제대로 동작하지 않는 문제였다. 더 흥미로운 점은 이 현상이 번들러마다 다르게 나타난다는 것이다.


## 문제의 원인


### enum이 컴파일되는 방식


문제의 근본 원인은 TypeScript enum의 컴파일 방식에 있다. enum은 JavaScript의 네이티브 기능이 아니기 때문에, TypeScript 컴파일러가 이를 IIFE(즉시 실행 함수)로 변환한다.


```typescript
// TypeScript 코드
export enum MOBILE_OS {
  IOS = 'iOS',
  ANDROID = 'Android'
}
```


위 코드는 다음과 같이 컴파일된다.


```javascript
// 컴파일된 JavaScript
export var MOBILE_OS;
(function (MOBILE_OS) {
    MOBILE_OS["IOS"] = "iOS";
    MOBILE_OS["ANDROID"] = "Android";
})(MOBILE_OS || (MOBILE_OS = {}));
```


### 왜 IIFE가 문제인가


IIFE는 즉시 실행되는 함수이기 때문에 번들러가 이를 "부수 효과(side effect)가 있는 코드"로 판단한다.

> **부수 효과(Side Effect)란?**  
> 함수가 반환값 외에 외부에 영향을 미치는 모든 동작을 의미한다. 전역 변수를 수정하거나, DOM을 조작하거나, CSS 파일을 import하거나, 이벤트 리스너를 등록하는 것이 대표적이다. 번들러는 부수 효과가 있는 코드를 제거하면 프로그램 동작이 달라질 수 있으므로 함부로 제거할 수 없다.

enum의 IIFE 패턴에서 특히 문제가 되는 부분은 `(MOBILE_OS || (MOBILE_OS = {}))` 구문이다. 이 코드는 외부 변수 `MOBILE_OS`를 읽고, 값이 없으면 빈 객체로 초기화한다. 번들러 입장에서는 외부 상태를 변경하는 코드로 보인다. 실제로 `MOBILE_OS`를 사용하지 않더라도 번들러는 "이 코드를 제거하면 프로그램 동작이 달라질 수 있다"고 판단한다. 그래서 안전을 위해 코드를 그대로 남긴다.


이 문제는 TypeScript의 [Issue #27604](https://github.com/microsoft/TypeScript/issues/27604)에서 2018년부터 논의되고 있다. 해결 방법으로 **`/*#__PURE__*/`** 주석을 IIFE 앞에 추가하여 "이 함수는 순수 함수이며 부수 효과가 없다"고 명시하는 방안이 제안되었다. 이렇게 하면 번들러가 안전하게 제거할 수 있지만, 아직 TypeScript 컴파일러 자체에는 반영되지 않았다.


### 번들러별 동작 비교


세 가지 주요 번들러는 enum tree shaking을 서로 다르게 처리한다.


### Vite (Rollup 기반)


Vite의 경우, 미사용 enum과 함수가 완벽히 제거되었다. 최종 빌드에는 실제 사용되는 코드만 포함되어 가장 효율적인 번들 크기를 달성했다.


```javascript
// Vite 빌드 결과 - 미사용 ENUM_TEST는 제거됨
const ENUM_COUNT = { ONE: 1, TWO: 2 };
console.log(ENUM_COUNT.ONE);
```


### Webpack


Webpack의 경우, `/* unused harmony exports ENUM_TEST, result */` 주석으로 미사용 코드를 표시하지만 실제 코드는 제거하지 않았다. 모듈 캐시 형태로 전체 enum 파일을 require하는 방식을 사용했다.


```javascript
// Webpack 빌드 결과 - 미사용 코드도 포함됨
/* unused harmony exports ENUM_TEST, result */
const ENUM_TEST = { ... };  // 사용하지 않지만 남아있음
const ENUM_COUNT = { ... };
```


Webpack은 `usedExports` 최적화를 통해 미사용 export를 표시하지만, 실제 제거는 Terser 같은 minifier에게 위임한다. 문제는 Terser가 IIFE의 부수 효과를 확신할 수 없어서 보수적으로 코드를 유지한다는 점이다.


### 왜 이런 차이가 발생하는가


같은 TypeScript enum 코드를 빌드했는데 결과가 다른 이유를 이해하려면, 두 번들러가 실제로 어떤 코드를 생성했는지 비교해야 한다.


**원본 TypeScript 코드**


```typescript
// enums.ts
export enum USED_ENUM { VALUE_A = 'A', VALUE_B = 'B', VALUE_C = 'C' }
export enum UNUSED_ENUM { VALUE_X = 'X', VALUE_Y = 'Y', VALUE_Z = 'Z' }

// main.ts
import { USED_ENUM } from './enums';
console.log(USED_ENUM.VALUE_A);
```


**Vite가 생성한 코드**


```javascript
var o=(t=>(t.VALUE_A="A",t.VALUE_B="B",t.VALUE_C="C",t))(o||{});
console.log("USED_ENUM.VALUE_A:",o.VALUE_A);
// UNUSED_ENUM은 어디에도 없음
```


**Webpack이 생성한 코드**


```javascript
var A,o;
!function(A){A.VALUE_A="A",A.VALUE_B="B",A.VALUE_C="C"}(A||(A={})),
function(A){A.VALUE_X="X",A.VALUE_Y="Y",A.VALUE_Z="Z"}(o||(o={})),
console.log("USED_ENUM.VALUE_A:",A.VALUE_A);
// UNUSED_ENUM(o)도 포함됨
```


두 번들 모두 enum을 IIFE로 변환했다. 그런데 Vite는 미사용 IIFE를 제거했고, Webpack은 그대로 남겼다. 이 차이는 어디서 오는 걸까?


**Rollup/Vite의 전략**


Rollup은 "사람이 작성한 것처럼 보이는 최대한 효율적인 번들"을 목표로 한다. ES 모듈의 정적 구조를 분석하여 사용되지 않는 export를 추적하고, 해당 IIFE가 참조되지 않으면 제거한다. 실제로 `UNUSED_ENUM`은 import되지도, 사용되지도 않았으므로 Rollup은 이 IIFE를 안전하게 제거할 수 있다고 판단했다.


**Webpack의 전략**


Webpack은 `usedExports` 최적화로 미사용 export를 표시하지만, 실제 제거는 Terser에게 위임한다. Terser는 IIFE 패턴을 보고 "이 코드가 외부 상태를 변경할 수도 있다"고 보수적으로 판단한다. `sideEffects: false`를 명시적으로 선언하지 않는 한, 안전을 위해 IIFE를 보존한다.


흥미로운 점은 두 번들러 모두 `unusedFunction`은 제거했다는 것이다. 일반 함수는 명확히 부수 효과가 없다고 판단할 수 있지만, IIFE는 즉시 실행되므로 더 신중하게 처리한다. Rollup은 이런 경우에도 사용 여부를 추적해서 제거하지만, Webpack/Terser는 보수적으로 유지한다.


## bundler 테스트


레퍼런스들에서 설명한 내용이 실제로 그런지 직접 확인해보자. Vite와 Webpack 최신 버전으로 동일한 코드를 빌드하여 번들 결과를 비교한다.


### 테스트 환경 구성


간단한 테스트 케이스를 작성한다. 여러 개의 enum을 정의하되 일부만 실제로 사용하는 코드다.


![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/bundler-enum-tree-shaking/image-1762678327911-5.webp)


![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/bundler-enum-tree-shaking/image-1762678327911-5.webp)


이 코드를 Vite 최신 버전에서 빌드하면 `UNUSED_ENUM`과 `unusedFunction`이 제거되는지 확인할 수 있다.


### Vite 빌드 결과 뜯어보기


테스트 환경은 Vite v7.2.2이다. `npm run build`를 실행하면 다음과 같이 빌드된다.


```plain text
vite v7.2.2 building client environment for production...
✓ 5 modules transformed.
dist/assets/index-DXZEMrmh.js   1.04 kB │ gzip: 0.58 kB
✓ built in 42ms
```


![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/bundler-enum-tree-shaking/image-1762678327911-5.webp)


빌드된 JavaScript 파일을 열어보면 다음과 같다.


![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/bundler-enum-tree-shaking/image-1762678327911-5.webp)


번들 파일을 살펴보면 흥미로운 결과를 발견할 수 있다. 31번 라인에 `var o=(t=>(t.VALUE_A="A",t.VALUE_B="B",t.VALUE_C="C",t))(o||{})` 형태로 압축된 IIFE가 보이는데, 이것이 USED_ENUM이다. 반면 UNUSED_ENUM은 어디에도 존재하지 않는다. 함수도 마찬가지다. `function c(t){return...}` 형태로 usedFunction은 남아있지만, unusedFunction은 흔적도 없다.


번들 파일 전체에서 "UNUSED"나 "unused" 문자열을 검색해도 아무것도 나오지 않는다. Vite는 enum에 대한 tree shaking을 완벽하게 수행했다.


### Webpack 빌드 결과 뜯어보기


같은 코드를 Webpack v5.102.1에서 빌드해본다. `optimization.usedExports`와 `minimize`를 모두 활성화한 production 모드다. Vite와 동일한 테스트 환경을 위해 CSS import와 DOM 조작 코드도 포함했다.


```plain text
> webpack

asset bundle.js 4.47 KiB [emitted] [minimized] (name: main)
webpack 5.102.1 compiled successfully in 517 ms
```


![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/bundler-enum-tree-shaking/image-1762678327911-5.webp)


빌드된 파일을 열어보면, 대부분의 코드는 style-loader와 CSS 관련 모듈이다. 번들 말미에 실제 enum과 애플리케이션 코드가 위치한다.


![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/bundler-enum-tree-shaking/image-1762678327911-5.webp)


놀랍게도 `UNUSED_ENUM`이 그대로 남아있다. 번들 파일을 검색하면 `VALUE_X`, `VALUE_Y`, `VALUE_Z`가 모두 포함되어 있음을 확인할 수 있다. `unusedFunction`은 제거되었지만, **enum은 제거되지 않았다.**


Webpack은 enum의 IIFE를 제거하지 못했다.


### 테스트 결과 정리


Vite v7.2.2는 enum tree shaking에 완벽하게 성공했다. 번들 크기는 1.04 kB다. 반면 Webpack v5.102.1은 enum tree shaking에 실패했다. UNUSED_ENUM이 번들에 포함되어 308 bytes를 차지한다. 코드가 단순해서 번들 크기 자체는 작지만 불필요한 enum이 포함되어 있다.


흥미로운 점은 두 번들러 모두 `unusedFunction`은 제거했다는 것이다. 일반 함수는 tree shaking이 작동하지만, enum의 IIFE 패턴은 Webpack에서 여전히 처리하지 못한다.


### 왜 Vite는 성공하고 Webpack은 실패하는가


같은 TypeScript enum 코드인데 번들러에 따라 결과가 다른 이유는 무엇일까?


Rollup은 특정 패턴의 IIFE를 인식하고 분석할 수 있다. TypeScript enum이 생성하는 IIFE 패턴은 충분히 예측 가능하므로, Rollup은 이를 "순수한 코드"로 판단하여 미사용 시 제거한다. 반면 Webpack의 Terser는 더 보수적으로 접근하여 IIFE를 부수 효과가 있는 코드로 간주한다.


결론적으로 **Vite 환경에서는 enum을 사용해도 번들 크기 걱정을 덜 수 있다.** 하지만 Webpack을 사용하는 프로젝트에서는 여전히 Union Types나 const enum으로 전환하는 것이 안전하다.


## 해결 방법


enum의 tree shaking 문제를 해결하려면 다음 방법들을 고려할 수 있다.


### Union Types로 전환


모든 번들러에서 적용되는 방법은 enum 대신 객체와 Union Type을 사용하는 것이다.


```typescript
// enum 대신 as const 객체 사용
const MOBILE_OS = {
  IOS: 'iOS',
  ANDROID: 'Android'
} as const;

// 타입 정의
type MOBILE_OS = typeof MOBILE_OS[keyof typeof MOBILE_OS];  // 'iOS' | 'Android'

// 사용 예시
function getDevice(os: MOBILE_OS) {
  return `Your device is ${os}`;
}

getDevice(MOBILE_OS.IOS);  // 타입 체크 완벽하게 작동
```


이 방식은 컴파일 후 순수한 객체만 남기 때문에 IIFE가 생성되지 않는다.


```javascript
// 컴파일 결과
const MOBILE_OS = {
  IOS: 'iOS',
  ANDROID: 'Android'
};
```


객체는 번들러가 쉽게 분석할 수 있다. 미사용 시 완벽하게 tree shaking되며, Webpack과 Vite 모두에서 작동한다. 타입 안정성도 enum과 동일하게 유지되면서 런타임 overhead도 없다. 컴파일 결과가 간단하고 예측 가능하며, Babel과 TSC 모두 지원한다.


반면 enum보다 문법이 약간 복잡하다는 단점이 있다. 숫자 enum의 역방향 매핑도 불가능하지만, 문자열 enum에서는 어차피 역방향 매핑이 안 되므로 실질적인 제약은 아니다.


### const enum 사용


```typescript
const enum MOBILE_OS {
  IOS = 'iOS',
  ANDROID = 'Android'
}

console.log(MOBILE_OS.IOS);
```


`const enum`은 컴파일 시점에 인라인으로 대체되어 런타임 코드가 전혀 생성되지 않는다.


```javascript
// 컴파일 결과 - enum이 완전히 사라짐
console.log("iOS");
```


완벽한 tree shaking처럼 보이지만 제약이 있다. 런타임 코드가 전혀 생성되지 않고 enum 문법을 그대로 사용할 수 있다는 장점이 있다. 반면 Babel에서 지원하지 않아 TypeScript 전용이며, `--isolatedModules` 옵션과 호환 문제가 있다. 다른 모듈에서 import할 때 문제가 발생할 수 있고, 값이 인라인되어 있어서 디버깅이 어렵다.


### Vite로 번들러 전환


Webpack을 사용 중이라면 Vite로 전환하는 것도 방법이다. 실제 테스트에서 확인했듯이 Vite는 enum tree shaking을 완벽하게 지원한다. 기존 enum 코드를 수정하지 않고도 번들 크기를 최적화할 수 있고 빌드 속도도 향상된다. 다만 프로젝트 마이그레이션 비용이 들고 기존 Webpack 설정을 재구성해야 한다.


### 권장 전략


새 프로젝트라면 Vite를 사용하는 것이 좋다. Vite는 내부적으로 Rollup을 사용하므로 enum tree shaking이 잘 작동하고 빌드 속도도 빠르다. Vite 환경에서는 enum을 그대로 써도 되지만, Union Types를 쓰면 모든 빌드 툴에서 안전하고 더 명시적이다.


Webpack을 사용하는 기존 프로젝트는 점진적으로 Union Types로 마이그레이션한다. 레거시 프로젝트에서는 const enum을 고려할 수 있으나 제약 사항을 반드시 확인해야 한다.


## 정리

TypeScript enum은 IIFE로 컴파일되어 번들러가 부수 효과 있는 코드로 판단한다. 이로 인해 미사용 enum이 tree shaking되지 않는 문제가 발생한다.

번들러별로 처리 방식이 다르다:
- Vite(Rollup): enum tree shaking 완벽 지원
- Webpack: IIFE를 보수적으로 유지, tree shaking 실패

해결책으로는 Union Types(`as const` 객체)가 가장 범용적이다. Vite 환경이라면 enum을 그대로 써도 되지만, Webpack 프로젝트에서는 Union Types 전환을 권장한다.

## References


[Enum tree shaking](https://jicjjang.github.io/posts/enum-tree-shaking)


[TypeScript enum의 Tree-shaking - Line Engineering](https://engineering.linecorp.com/ko/blog/typescript-enum-tree-shaking)


[TypeScript Issue #27604 - Make generated codes from enum could be minified when not used](https://github.com/microsoft/TypeScript/issues/27604)


[Webpack Tree Shaking Guide](https://webpack.js.org/guides/tree-shaking/)


[Tree-shaking versus dead code elimination by Rich Harris](https://medium.com/@Rich_Harris/tree-shaking-versus-dead-code-elimination-d3765df85c80)



IIFE로 컴파일되는 enum이 번들 크기를 키우는 이유

Bundler에서의 Enum Tree Shaking 문제


## 왜 SSG인가

블로그를 만들 때 가장 먼저 결정해야 하는 건 렌더링 방식이다. Next.js는 SSR, SSG, ISR을 지원하는데, 블로그에는 SSG가 가장 적합했다.

블로그 글은 한 번 작성하면 자주 바뀌지 않는다. 매 요청마다 서버에서 렌더링할 필요가 없다. 빌드 타임에 모든 페이지를 미리 생성해두면 CDN에서 정적 파일로 서빙할 수 있다. 서버 비용이 거의 들지 않고, 응답 속도도 빠르다.

ISR은 "주기적으로 재생성"이라는 개념이 블로그와 맞지 않았다. 글을 수정하면 즉시 반영되어야 하는데, ISR의 revalidation 주기 동안 구버전이 보일 수 있다. 차라리 수정할 때마다 빌드를 새로 돌리는 게 명확하다.

## 핵심 구조

Next.js Page Router에서 SSG를 구현하는 핵심은 두 함수다.

### getStaticPaths

빌드 타임에 어떤 페이지들을 생성할지 알려준다.

```typescript
export const getStaticPaths: GetStaticPaths = async () => {
  const posts = getSortedPostsData();
  const paths = posts.map((post) => ({
    params: { id: post.id },
  }));

  return {
    paths,
    fallback: false,
  };
};
```

`fallback: false`는 정의되지 않은 경로로 접근하면 404를 반환한다는 의미다. 블로그는 빌드 시점에 모든 글이 확정되므로 이 설정이 적합하다. `fallback: true`나 `'blocking'`은 동적으로 새 페이지를 생성할 때 쓴다.

### getStaticProps

각 페이지에 필요한 데이터를 빌드 타임에 가져온다.

```typescript
export const getStaticProps: GetStaticProps = async ({ params }) => {
  const id = params?.id as string;
  const postData = await getPostData(id);
  const headings = extractHeadings(postData.content);
  const adjacentPosts = getAdjacentPosts(id);
  const relatedPosts = getRelatedPosts(id, postData.tags);
  const readingTime = calculateReadingTime(postData.content);

  return {
    props: {
      postData: { ...postData, headings },
      adjacentPosts,
      relatedPosts,
      readingTime,
    },
  };
};
```

여기서 반환하는 props가 페이지 컴포넌트의 props로 전달된다. 빌드 타임에 실행되므로 파일 시스템 접근, 데이터베이스 쿼리 등 서버 사이드 작업이 가능하다.

## 데이터 레이어 설계

마크다운 파일에서 데이터를 추출하는 로직은 `src/lib/posts.ts`에 모아뒀다.

### 파일 시스템 기반 CMS

```typescript
const postsDirectory = path.join(process.cwd(), "posts");

export function getPostsList(): PostListItem[] {
  const fileNames = fs.readdirSync(postsDirectory);
  const allPostsData = fileNames
    .filter((fileName) => fileName.endsWith(".md"))
    .flatMap((fileName) => {
      const id = fileName.replace(/\.md$/, "");
      const fullPath = path.join(postsDirectory, fileName);
      const fileContents = fs.readFileSync(fullPath, "utf8");
      const matterResult = matter(fileContents);
      const data = matterResult.data as PostFrontmatter;

      if (data.published !== true) return [];

      return [
        {
          id,
          title: data.title,
          created: toDateString(data.created),
          tags: data.tags || [],
          excerpt: generateExcerpt(matterResult.content),
        },
      ];
    });

  return allPostsData.sort((a, b) => (a.created < b.created ? 1 : -1));
}
```

`fs.readdirSync`로 posts 폴더의 파일 목록을 읽고, 각 파일을 파싱해서 데이터를 추출한다. `gray-matter` 라이브러리가 frontmatter와 본문을 분리해준다.

`published !== true`인 글은 `flatMap`에서 빈 배열을 반환해 필터링한다. `filter` + `map` 조합보다 한 번에 처리할 수 있어서 간결하다.

### Frontmatter 타입 정의

```typescript
export interface PostFrontmatter {
  title: string;
  created: string | Date;
  updated?: string | Date;
  published?: boolean;
  tags?: string[];
}
```

`gray-matter`는 날짜 문자열을 자동으로 Date 객체로 파싱한다. `"2025-01-15"` 형식을 Date로 변환해주는데, 문제는 UTC로 파싱한다는 것이다. 한국 시간대에서 작성한 날짜가 하루 전으로 표시될 수 있다.

```typescript
function toDateString(value: string | Date): string {
  if (value instanceof Date) {
    // gray-matter가 UTC로 파싱하므로 UTC 메서드 사용
    const year = value.getUTCFullYear();
    const month = String(value.getUTCMonth() + 1).padStart(2, "0");
    const day = String(value.getUTCDate()).padStart(2, "0");
    return `${year}-${month}-${day}`;
  }
  return value;
}
```

`getUTCFullYear()`, `getUTCDate()` 등 UTC 메서드를 사용해서 파싱된 그대로의 날짜를 문자열로 변환한다. 로컬 시간대 메서드(`getFullYear()`)를 쓰면 시간대 변환이 일어나서 날짜가 어긋날 수 있다.

## 빌드 타임 최적화

SSG에서 중요한 건 빌드 타임이다. 글이 많아질수록 빌드 시간이 길어지는데, 몇 가지 최적화를 적용했다.

### 코드 하이라이팅 캐싱

코드 블록 하이라이팅은 비용이 크다. 매 빌드마다 모든 코드 블록을 하이라이팅하면 시간이 오래 걸린다.

```typescript
export const getStaticProps: GetStaticProps = async ({ params }) => {
  // ...
  const codeBlockRegex = /```([^\n\r]*)\r?\n([\s\S]*?)```/g;
  const codeBlocks: { [key: string]: string } = {};
  let match;
  let blockIndex = 0;

  while ((match = codeBlockRegex.exec(postData.content)) !== null) {
    const language = match[1]?.trim() || "text";
    const code = match[2];
    const blockKey = `block-${blockIndex++}`;
    codeBlocks[blockKey] = await highlightCode(code, language);
  }
  // ...
};
```

`getStaticProps`에서 코드 블록을 미리 하이라이팅해서 props로 전달한다. 클라이언트에서 하이라이팅하지 않으므로 번들 크기도 줄고, 사용자가 보는 시점에는 이미 처리가 끝나 있다.

### 날짜순 정렬 한 번만

```typescript
return allPostsData.sort((a, b) => (a.created < b.created ? 1 : -1));
```

정렬은 `getPostsList` 함수 내에서 한 번만 수행한다. 호출하는 쪽에서 매번 정렬하지 않아도 된다. 최신 글이 먼저 오도록 내림차순 정렬한다.

## 실제 빌드 결과

현재 블로그는 빌드 시 약 120개 페이지를 생성한다. Vercel에서 빌드 시간은 1분 내외다.

```text
Route (pages)                              Size     First Load JS
├ ● /                                      5.2 kB        89.4 kB
├ ● /posts/[id]                            12.1 kB       96.3 kB
├ ● /notes/[...slug]                       8.7 kB        92.9 kB
└ ... (120 more routes)
```

SSG의 장점은 배포 후 비용이 거의 없다는 것이다. Vercel 무료 티어로 충분하다. 서버리스 함수 호출이 없으니 사용량 걱정도 없다.


2025