2025년 1월 10일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

## Frontend — React 19이 새로운 React 기준선으로 이동

React 19 Stable이 **2024년 12월 5일** 공개된 이후, 2025년 초부터 Framework와 Library 생태계에서도 React 19 지원과 Migration이 본격적으로 진행되기 시작했습니다.

React 19에서는 **Actions, `use`, `useOptimistic`, Form Actions, Server Components 관련 기능, Suspense와 SSR 개선** 등이 정식 React의 방향으로 자리 잡았습니다.

중요한 변화는 단순히 Hook 몇 개가 추가된 것이 아니라, React가 전통적인 Client UI Library에서 **Server Rendering, Async State, Data Mutation까지 Framework와 함께 다루는 Application Model**로 이동하고 있다는 점이었습니다.

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

---

### React 18까지의 일반적인 구조

전통적인 React Application에서는 React가 주로 Client UI를 담당했습니다.

```text
React
  ↓
Client UI
  ↓
REST / GraphQL
  ↓
Backend
```

데이터 요청과 Mutation을 처리하려면 보통 여러 Library를 함께 사용했습니다.

```text
React

+
TanStack Query
+
React Hook Form
+
Router
+
Backend API
```

React 자체는 기본적으로 UI Rendering과 Component State 관리에 집중하고 있었습니다.

---

### React 19의 방향

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

```text
React 18

Client UI
+
State
+
Rendering


React 19

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

특히 Server Components나 Actions 같은 기능은 React가 Framework와 더욱 밀접하게 연결되는 방향을 보여줍니다.

---

### Actions

React 19의 대표적인 변화 중 하나가 **Actions**입니다.

기존에는 Data Mutation을 처리할 때 개발자가 여러 상태를 직접 관리하는 경우가 많았습니다.

```text
Submit
  ↓
setLoading(true)
  ↓
API Request
  ↓
Success / Error 처리
  ↓
State Update
  ↓
setLoading(false)
```

코드에서는 다음과 같은 상태들이 반복적으로 등장했습니다.

```text
isLoading
isPending
error
data
```

React 19에서는 Action을 통해 비동기 Mutation을 React의 상태 전환과 더욱 자연스럽게 연결할 수 있게 됐습니다.

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

---

### Form 처리도 React 안으로

React 19에서는 Form의 `action`에 Function을 전달하는 패턴도 사용할 수 있습니다.

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

  await updateUser(name);
}

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

기존 방식에서는 다음 과정이 익숙했습니다.

```text
onSubmit
   ↓
preventDefault()
   ↓
Form Data 추출
   ↓
API 호출
   ↓
Loading 관리
   ↓
Error 처리
```

React 19에서는 이런 Mutation Workflow 일부를 React 자체의 Programming Model 안에서 처리할 수 있게 됐습니다.

---

### Optimistic Update

React 19의 `useOptimistic`은 서버 응답을 기다리기 전에 UI를 먼저 업데이트하는 **Optimistic UI Pattern**을 지원합니다.

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

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

Optimistic Update에서는 순서가 달라집니다.

```text
Click
 ↓
UI 즉시 Update
 ↓
API Request
 ↓
성공 → 유지
실패 → Rollback
```

예를 들어 다음과 같은 UI에서 유용합니다.

```text
Like

Comment

Shopping Cart

Todo

Follow

Reaction
```

사용자 Interaction에 즉각적으로 반응할 수 있기 때문에 체감 UX를 개선할 수 있습니다.

---

### `use`

React 19에서는 새로운 `use` API도 등장했습니다.

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

```jsx
const data = use(dataPromise);
```

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

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

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

---

### Suspense의 역할 확대

기존에는 Loading State를 직접 작성하는 패턴이 매우 흔했습니다.

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

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

return <Content />;
```

React 19에서는 Suspense와 비동기 Resource가 더욱 긴밀하게 연결됩니다.

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

개발자가 모든 비동기 작업마다 별도의 Loading State를 직접 관리하는 구조에서 점차 벗어나는 방향입니다.

---

### Server Components

React 19 시대에서 중요한 변화 중 하나는 **Server Components가 React Architecture의 공식적인 방향으로 자리 잡았다는 점**입니다.

기존 React Component는 주로 Browser에서 실행됐습니다.

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

Server Component에서는 일부 Component를 Server에서 실행할 수 있습니다.

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

이를 통해 다음과 같은 Server-side 작업과 Component를 연결할 수 있습니다.

```text
Database Access

Server Data Fetching

File Access

Backend API

Authentication
```

---

### Client와 Server의 경계 변화

React Application은 점점 다음과 같은 형태가 됩니다.

```text
React Application

├─ Server Component
│   ├─ Data Fetching
│   ├─ Server Logic
│   └─ Rendering
│
└─ Client Component
    ├─ Event
    ├─ Browser API
    └─ Interactive State
```

모든 Component를 Client JavaScript로 보내는 것이 아니라 **Server에서 처리할 부분과 Client에서 처리할 부분을 나누는 Architecture**입니다.

---

### Next.js와 React 19

이 변화는 Next.js 같은 React Framework와 함께 보면 더 명확합니다.

```text
React 19
   ↓
Server Components
Actions
Suspense
Async Rendering
   ↓
Next.js
   ↓
Full Stack Application
```

React 자체에서 Primitive를 제공하고 Framework가 Routing, Cache, Server Rendering, Deployment 등의 기능을 결합하는 구조입니다.

따라서 신규 React Project에서는 단순히

```text
React
+
Client SPA
```

만 생각하기보다

```text
React 19
+
Framework
+
Server / Client Architecture
```

를 함께 고려하는 것이 점점 자연스러워졌습니다.

---

### React가 Framework에 가까워진 것은 아니다

React 자체가 Next.js 같은 Full Stack Framework가 된 것은 아닙니다.

역할은 여전히 구분됩니다.

```text
React

Component
Rendering
Actions
Suspense
Server Component Primitive


Framework

Routing
Data Loading
Caching
Deployment
Server Runtime
Build
```

React는 Framework가 Full Stack Application을 구성할 수 있도록 **더 많은 Primitive를 제공하는 방향**으로 발전하고 있다고 보는 것이 정확합니다.

---

### `ref` 사용 방식의 변화

React 19에서는 Function Component에서도 `ref`를 Prop처럼 사용할 수 있게 됐습니다.

기존에는 `forwardRef`를 사용해야 하는 경우가 많았습니다.

```jsx
const Input = forwardRef((props, ref) => {
  return <input ref={ref} {...props} />;
});
```

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

```jsx
function Input({ ref, ...props }) {
  return <input ref={ref} {...props} />;
}
```

따라서 기존 Component Library나 Design System에서는 `forwardRef` 사용 패턴을 점검할 필요가 생겼습니다.

---

### 기존 프로젝트에서는 Migration이 필요하다

React 19가 출시됐다고 해서 React 18 Application을 바로 전부 다시 작성할 필요는 없습니다.

하지만 Version Upgrade 시에는 몇 가지 Compatibility를 확인해야 합니다.

```text
React 18
   ↓
React 19 Migration

├─ Dependency Compatibility
├─ forwardRef
├─ Form 처리
├─ Suspense
├─ SSR
├─ Hydration
└─ Framework Version
```

특히 React 생태계에는 수많은 Third-party Library가 있기 때문에 Library의 React 19 지원 여부도 확인해야 합니다.

---

### Framework Compatibility

React Application에서는 React Version만 독립적으로 Upgrade하는 경우보다 Framework와 함께 Upgrade하는 경우가 많습니다.

```text
Next.js
   ↓
React
   ↓
React DOM
```

따라서 실제 Migration에서는 다음 조합을 함께 확인해야 합니다.

```text
React Version

Next.js Version

UI Library

Form Library

State Library

Testing Library
```

React 19을 지원한다고 해도 주변 Dependency가 아직 대응되지 않았다면 Migration 과정에서 문제가 발생할 수 있습니다.

---

### SSR과 Hydration

React 19에서는 Server Rendering과 Hydration 관련 개선도 계속됐습니다.

Modern React Application에서는 Server에서 HTML을 먼저 생성하고 Client에서 Interactive UI로 연결하는 구조가 많이 사용됩니다.

```text
Server
  ↓
HTML 생성
  ↓
Browser
  ↓
Hydration
  ↓
Interactive React
```

이 과정에서 Server와 Client Output이 다르면 Hydration Error가 발생할 수 있습니다.

```text
Server Output
      ≠
Client Output
      ↓
Hydration Error
```

React 19에서는 이런 Server / Client Rendering 경험을 개선하는 작업도 중요한 흐름이었습니다.

---

### React 18 기준 설계에서 React 19 기준 설계로

React 18에서는 다음과 같은 Architecture가 익숙했습니다.

```text
Client React

├─ useState
├─ useEffect
├─ Data Fetching Library
├─ Form Library
└─ REST API
```

React 19과 Framework를 중심으로 보면 다음과 같은 Architecture도 자연스러워집니다.

```text
React 19

├─ Server Components
├─ Client Components
├─ Actions
├─ Suspense
├─ Optimistic UI
└─ Framework Integration
```

단순하게 Library Version이 하나 올라간 것이 아니라 **React Application을 설계하는 기본 관점 자체가 변화하고 있는 것**입니다.

---

### Frontend와 Backend 경계가 흐려진다

React 19과 Server Component 기반 Framework에서는 Frontend 개발자가 다루는 영역도 확장됩니다.

기존에는 다음 구조가 익숙했습니다.

```text
Frontend

React
  ↓
REST API


Backend

Spring / Node
  ↓
Database
```

최근에는 다음과 같은 구조도 흔해지고 있습니다.

```text
React Framework

├─ Client UI
├─ Server Rendering
├─ Data Fetching
├─ Mutation
└─ Server Function
        ↓
    Backend / Database
```

Frontend Engineer 역시 Server Rendering, Cache, Data Mutation 같은 Backend 개념을 이해해야 하는 영역이 넓어지고 있습니다.

---

### 그렇다고 기존 Library가 필요 없어지는 것은 아니다

React 19의 새로운 기능이 등장했다고 해서 TanStack Query나 React Hook Form 같은 Library가 바로 필요 없어지는 것은 아닙니다.

예를 들어 복잡한 Server State에서는 여전히 다음 기능들이 중요합니다.

```text
Cache

Retry

Pagination

Infinite Query

Background Refetch

Query Invalidation
```

복잡한 Form에서는 다음 기능도 필요합니다.

```text
Validation

Nested Form

Dynamic Field

Error Management

Schema Integration
```

따라서 React 19은 모든 Library를 대체한다기보다 **기본적인 Async Interaction을 React 자체에서 처리할 수 있는 범위를 넓힌 변화**에 가깝습니다.

---

### 신규 프로젝트의 기준 변화

React 19 Stable 이후 신규 프로젝트에서는 React 18의 제약을 기준으로 Architecture를 설계할 이유가 점점 줄어들었습니다.

```text
신규 Project

React 19
    +
Modern Framework
    +
Server / Client 분리
```

특히 Next.js 같은 Framework를 사용하는 경우 React 19의 기능을 기반으로 새로운 Application Architecture를 설계하는 것이 자연스러워졌습니다.

반면 기존 React 18 Project라면 Migration 비용과 Dependency Compatibility를 먼저 확인하는 것이 중요합니다.

```text
Existing Project

React 18
   ↓
Migration Cost 확인
   ↓
Dependency Compatibility
   ↓
React 19
```

---

### 실무 영향

React 19의 Stable 출시 이후 중요한 것은 새로운 API 하나하나보다 **React Ecosystem의 기준점이 이동하기 시작했다는 것**입니다.

기존 Frontend Architecture가

```text
Client SPA
+
REST API
```

중심이었다면,

새로운 React Architecture는

```text
Client
+
Server
+
Async Rendering
+
Mutation
+
Framework
```

을 함께 고려하는 방향으로 확장되고 있습니다.

신규 프로젝트에서는 React 19과 Framework 중심 Architecture를 검토하는 것이 자연스러워졌고,

기존 프로젝트에서는 다음 요소를 점검해야 합니다.

```text
React 19 Migration

├─ Framework 지원
├─ Library Compatibility
├─ ref / forwardRef
├─ Form Logic
├─ Suspense
├─ SSR
└─ Hydration
```

결국 React 19의 의미는,

> **React가 단순한 Client UI Library에서 Framework와 결합해 Server Rendering, Async State, Data Mutation까지 다루는 새로운 Application Model의 기준선으로 이동했다는 것**

이라고 볼 수 있습니다.

2025년 1월 3일(금) 주간 개발트렌드

독자의 메모