2024년 12월 13일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/2a3741f8-626e-4237-b985-d52de10bb444_thumbnail_1.png)

## Frontend — React 19 정식 출시

React가 **24년 12월 5일 React 19**를 Stable로 정식 출시했습니다.

React 19에서는 **Actions, `use`, `useOptimistic`, Form Actions, Server Components 관련 기능, Suspense와 SSR 개선** 등이 포함되면서 React의 역할이 단순한 Client UI Rendering을 넘어 더욱 넓어졌습니다.

특히 비동기 작업과 Form Mutation을 React의 상태 관리 흐름 안에서 처리할 수 있는 기능들이 추가되면서, 기존에 개발자가 직접 작성하던 Loading, Error, Optimistic UI 관련 Boilerplate를 줄이는 방향이 본격화됐습니다.

[React - React v19](https://react.dev/blog/2024/12/05/react-19)

---

### 기존 React의 역할

React는 처음부터 기본적으로 **Client UI를 구성하기 위한 Library**였습니다.

```text
State
  ↓
React Component
  ↓
Virtual DOM
  ↓
Browser UI
```

Backend에서 데이터를 가져오는 방법이나 Form을 서버에 제출하는 방식은 React 자체보다 외부 Library나 Framework가 담당하는 경우가 많았습니다.

```text
React

UI Rendering
State Management
Event Handling
```

그리고 Application에서는 별도의 도구를 함께 사용했습니다.

```text
React
  +
React Query
  +
Form Library
  +
Router
  +
Backend API
```

---

### React 19의 방향

React 19에서는 React가 직접 다루는 영역이 더욱 넓어졌습니다.

```text
React

Client UI
   +
Server
   +
Async Rendering
   +
Data Mutation
```

특히 비동기 상태와 Server Interaction을 Component Programming Model 안에서 자연스럽게 처리하려는 방향이 강해졌습니다.

---

### Actions

React 19에서 가장 중요한 개념 중 하나가 **Actions**입니다.

기존에는 Form을 제출하거나 데이터를 수정할 때 Loading과 Error 상태를 직접 관리하는 경우가 많았습니다.

```jsx
const [isPending, setIsPending] = useState(false);
const [error, setError] = useState(null);

async function handleSubmit() {
  setIsPending(true);

  try {
    await updateUser();
  } catch (error) {
    setError(error);
  } finally {
    setIsPending(false);
  }
}
```

비동기 작업 하나에도 여러 상태를 관리해야 합니다.

```text
Mutation

├─ Pending
├─ Success
└─ Error
```

React 19의 Actions는 이러한 비동기 Mutation을 React의 상태 관리 흐름과 연결합니다.

```text
User Action
    ↓
React Action
    ↓
Async Mutation
    ↓
Pending / Result
    ↓
UI Update
```

Form 제출과 서버 데이터 변경 같은 작업을 보다 선언적으로 처리할 수 있는 기반이 만들어진 것입니다.

---

### Form Actions

React 19에서는 `<form>`의 `action`에 Function을 사용할 수 있습니다.

```jsx
function Form() {
  async function submitAction(formData) {
    const name = formData.get('name');

    await saveUser(name);
  }

  return (
    <form action={submitAction}>
      <input name="name" />
      <button type="submit">
        Save
      </button>
    </form>
  );
}
```

기존에는 Form Event를 직접 처리하는 코드가 흔했습니다.

```text
onSubmit
   ↓
preventDefault()
   ↓
FormData 생성
   ↓
API 호출
   ↓
Loading 관리
   ↓
Error 관리
```

React 19에서는 이를 다음과 같은 방향으로 단순화할 수 있습니다.

```text
Form
 ↓
Action
 ↓
Async Mutation
 ↓
React State Update
```

Form과 Data Mutation이 React의 Programming Model 안으로 더 깊게 들어온 것입니다.

---

### `useOptimistic`

Optimistic UI는 서버의 응답을 기다리지 않고 성공할 것이라고 예상해 먼저 UI를 변경하는 방식입니다.

예를 들어 좋아요 버튼을 클릭했다고 가정해보겠습니다.

기존 방식은 다음과 같습니다.

```text
Click
 ↓
Server Request
 ↓
Response
 ↓
UI Update
```

Network Latency만큼 사용자가 기다려야 합니다.

Optimistic UI에서는 순서가 바뀝니다.

```text
Click
 ↓
UI 먼저 Update
 ↓
Server Request
 ↓
성공 → 유지
실패 → 복구
```

React 19에서는 `useOptimistic` Hook을 통해 이런 패턴을 React 수준에서 지원합니다.

```jsx
const [optimisticLikes, addOptimisticLike] =
  useOptimistic(likes, (current) => current + 1);
```

Social Feed, Comment, Like, Shopping Cart처럼 즉각적인 반응이 중요한 UI에서 활용할 수 있습니다.

---

### `use`

React 19에서는 새로운 `use` API도 추가됐습니다.

`use`를 사용하면 Render 과정에서 Promise나 Context 같은 Resource를 읽을 수 있습니다.

```jsx
const comments = use(commentsPromise);
```

Promise가 아직 완료되지 않았다면 Suspense와 연결됩니다.

```text
Component
   ↓
use(Promise)
   ↓
Promise Pending
   ↓
Suspense
   ↓
Loading UI
   ↓
Promise Resolve
   ↓
Component Rendering
```

비동기 데이터를 Component Rendering 과정과 더욱 직접적으로 연결하는 방식입니다.

---

### Suspense와 Async Rendering

React의 Suspense는 원래 Code Splitting과 Loading UI를 처리하기 위한 기능으로 많이 알려졌습니다.

```jsx
<Suspense fallback={<Loading />}>
  <Component />
</Suspense>
```

React 19에서는 `use`, Server Component 등의 기능과 결합하면서 **비동기 Rendering을 구성하는 핵심 Primitive**로 역할이 더욱 커졌습니다.

```text
Async Resource
     ↓
Suspense Boundary
     ↓
Loading
     ↓
Resource Ready
     ↓
Render
```

개발자가 모든 비동기 작업마다 별도의 `isLoading` 상태를 직접 만드는 방식에서 점점 벗어나는 방향입니다.

---

### 기존 Loading State

기존 React Application에서는 다음과 같은 코드가 매우 흔했습니다.

```jsx
if (isLoading) {
  return <Loading />;
}

if (error) {
  return <Error />;
}

return <Content />;
```

Application이 커지면 이런 상태 관리 코드도 반복됩니다.

```text
Request A
├─ isLoading
├─ error
└─ data

Request B
├─ isLoading
├─ error
└─ data
```

React는 Suspense와 Actions 같은 기능을 통해 이런 **Async State Handling의 일부를 Framework와 Runtime 수준에서 처리하는 방향**으로 발전하고 있습니다.

---

### Server Components

React 19에서는 Server Components와 관련된 기능도 React 생태계의 중요한 축으로 자리 잡았습니다.

기존 React는 기본적으로 Browser에서 Component를 실행했습니다.

```text
Browser
   ↓
React Component
   ↓
UI
```

Server Components에서는 일부 Component가 Server에서 실행될 수 있습니다.

```text
Server
  ↓
Server Component
  ↓
Rendered Result
  ↓
Client
```

이를 통해 Server에서만 필요한 작업을 Component 내부에서 처리할 수 있습니다.

예를 들어 다음과 같은 작업입니다.

```text
Database Access

File System Access

Server-side Data Fetching

Backend Service 호출
```

React의 Component Model이 Client와 Server 양쪽으로 확장되고 있는 것입니다.

---

### Client Component와 Server Component

React Application은 점점 다음과 같이 나뉠 수 있습니다.

```text
React Application

├─ Server Component
│   ├─ Data Fetching
│   ├─ Server Logic
│   └─ Static Rendering
│
└─ Client Component
    ├─ State
    ├─ Event
    └─ Browser Interaction
```

모든 Component를 Browser에 보내는 대신 필요한 부분만 Client Component로 만드는 구조입니다.

이 방식은 Next.js App Router 같은 Framework에서 이미 적극적으로 활용되고 있습니다.

---

### React와 Framework의 관계 변화

과거 React Application에서는 React가 UI Layer를 담당하고 나머지는 외부 Library를 조합하는 경우가 많았습니다.

```text
React
  +
Router
  +
Data Fetching
  +
Form Library
  +
State Library
```

최근 React는 Framework와 긴밀하게 결합되는 방향으로 발전하고 있습니다.

```text
React
   ↓
Framework

├─ Next.js
├─ Remix 계열
└─ 기타 React Framework
```

Server Components나 Server Actions 계열 기능은 특히 Framework Integration이 중요한 영역입니다.

---

### 왜 중요한가

React의 역할 자체가 바뀌고 있기 때문입니다.

초기 React를 단순화하면 다음과 같았습니다.

```text
React

Client UI Library
```

하지만 React 19에서 보이는 방향은 훨씬 넓습니다.

```text
React

Client
+
Server
+
Data Mutation
+
Async Rendering
+
Optimistic UI
```

Component가 단순히 HTML을 그리는 단위를 넘어 **데이터를 읽고 변경하며 비동기 상태까지 표현하는 Application Programming Model**로 확장되고 있습니다.

---

### Frontend Architecture의 변화

기존 Frontend Architecture에서는 Backend와 Frontend의 역할이 비교적 명확했습니다.

```text
React
  ↓
REST API
  ↓
Backend
  ↓
Database
```

최근에는 Framework와 Server Component가 들어오면서 구조가 달라질 수 있습니다.

```text
React Application

Client Component
       ↕
Server Component
       ↓
Server Action
       ↓
Database / API
```

Frontend Framework 내부에 Server-side Logic까지 포함되면서 Frontend와 Backend 사이의 경계가 더욱 흐려지고 있습니다.

---

### Data Mutation까지 React 영역으로

특히 React 19에서 중요한 변화는 **Rendering뿐 아니라 Mutation까지 React의 Programming Model에 들어오고 있다는 점**입니다.

기존에는 다음 구조가 일반적이었습니다.

```text
React UI
   ↓
Event Handler
   ↓
API Client
   ↓
Backend
```

React 19에서는 Framework와 결합해 다음과 같은 흐름을 만들 수 있습니다.

```text
React UI
   ↓
Action
   ↓
Server
   ↓
Mutation
   ↓
React Update
```

Rendering과 Data Mutation 사이의 연결이 더욱 직접적이 된 것입니다.

---

### 상태 관리 코드 감소

React Application에서 반복적으로 등장하는 코드 중 하나가 비동기 상태 관리입니다.

```text
Loading
Error
Success
Pending
Optimistic State
```

React 19는 이런 상태 중 일부를 React Runtime이 관리할 수 있는 Primitive를 제공합니다.

```text
Actions
      ↓
Pending State

useOptimistic
      ↓
Optimistic State

Suspense
      ↓
Loading State
```

개발자는 상태 자체를 직접 관리하기보다 **UI가 어떤 상태에서 어떻게 보여야 하는지 선언하는 방향**으로 이동할 수 있습니다.

---

### React Compiler와도 연결되는 큰 흐름

React 생태계에서는 개발자가 직접 Performance Optimization 코드를 작성해야 하는 부담도 줄이려는 움직임이 이어지고 있습니다.

기존에는 Render Optimization을 위해 다음과 같은 API를 직접 사용하는 경우가 많았습니다.

```text
useMemo

useCallback

memo
```

React Compiler 같은 별도의 기술도 등장하면서 장기적으로는 이러한 Optimization 중 일부를 Toolchain이 자동으로 처리하는 방향이 추진되고 있습니다.

다만 **React Compiler 자체가 React 19의 기본 기능이라는 의미는 아닙니다.**

React 19의 Actions, Suspense, Async Rendering과 함께 보면 React 생태계 전체가

```text
개발자가 직접 제어

        ↓

Framework
Compiler
Runtime

이 더 많은 부분을 처리
```

하는 방향으로 발전하고 있다고 볼 수 있습니다.

---

### 개발 방식의 변화

React Application 개발은 점점 Imperative한 상태 관리에서 Declarative한 구조로 이동하고 있습니다.

기존에는 개발자가 직접 다음 과정을 처리했다면,

```text
Request 시작

setLoading(true)

API 호출

Error 확인

State Update

setLoading(false)
```

점점 다음과 같은 구조로 이동합니다.

```text
Action 선언

Suspense Boundary 정의

Optimistic UI 정의

React가 상태 전환 관리
```

Framework와 Runtime이 반복적인 상태 관리 작업을 더 많이 담당하는 것입니다.

---

### 실무 영향

React 19로 Migration한다고 기존 React Application의 모든 코드를 바로 바꿔야 하는 것은 아닙니다.

기존 방식 역시 계속 사용할 수 있습니다.

하지만 새로운 Application에서는 다음 기능을 적극적으로 검토할 수 있습니다.

```text
React 19

├─ Actions
├─ Form Actions
├─ use
├─ useOptimistic
├─ Suspense
└─ Server Components
```

특히 Form과 비동기 Mutation이 많은 Application에서는 직접 작성해야 하는 상태 관리 코드의 양을 줄일 수 있습니다.

```text
기존

Form Library
+
Loading State
+
Error State
+
Optimistic State


새로운 방향

React Actions
+
Suspense
+
useOptimistic
```

물론 React Query나 Form Library가 필요 없어졌다는 의미는 아닙니다.

복잡한 Server State Cache, Validation, Retry, Pagination 같은 기능에서는 여전히 전문 Library가 유용합니다.

---

### React의 역할이 바뀐다

React 19에서 가장 중요한 변화는 개별 API보다 **React가 어디까지 담당하려 하는가**에 있습니다.

```text
과거

React
  ↓
UI Rendering


현재

React
  ↓
UI
+
Async State
+
Data Mutation
+
Server Integration
```

React가 단순한 View Library에서 **Full Stack Framework가 활용할 수 있는 Application Runtime과 Programming Model에 가까운 방향**으로 발전하고 있는 것입니다.

결국 React 19는,

> **React가 Client UI Library를 넘어 Server, Data Mutation, Async Rendering까지 포괄하는 새로운 Application Model로 확장되고 있음을 보여주는 Release**

라고 볼 수 있습니다.

2024년 12월 6일(금) 주간 개발트렌드

독자의 메모