
## 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는 객체 비교에 민감할까


![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)



React

2025

React Server Component

React Compiler 톺아보기

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

2024

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