2025년 2월 21일(금) 주간 개발트렌드

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

## Frontend — Create React App 공식 지원 종료

React 팀이 **오늘 25년 2월 14일 Create React App(CRA)을 신규 애플리케이션에서 Deprecated 처리**한다고 공식 발표했습니다.

Create React App은 오랫동안 React 프로젝트를 시작하는 가장 대표적인 방법이었습니다.

```bash
npx create-react-app my-app
```

복잡한 Webpack이나 Babel 설정 없이 React 프로젝트를 바로 생성할 수 있었기 때문에 React 입문자부터 실제 SPA 프로젝트까지 널리 사용됐습니다.

하지만 React 생태계가 Server Rendering, Server Components, Modern Build Tool 중심으로 변화하면서 CRA의 구조는 점점 최신 React 개발 방식과 맞지 않게 됐습니다.

React 팀은 신규 프로젝트에서 **React Framework를 사용하거나 Vite, Parcel, Rsbuild 같은 Build Tool을 사용하는 방향**을 권장했습니다.

[React - Sunsetting Create React App](https://ko.react.dev/blog/2025/02/14/sunsetting-create-react-app)

---

### Create React App의 역할

과거 React 프로젝트를 직접 구성하려면 여러 Tool을 설정해야 했습니다.

```text
React Project

├─ Webpack
├─ Babel
├─ ESLint
├─ Development Server
├─ Build Script
└─ Configuration
```

React를 처음 배우는 개발자에게는 상당한 진입 장벽이었습니다.

Create React App은 이를 하나의 Command로 해결했습니다.

```text
create-react-app
       ↓
React Project 생성
       ↓
npm start
```

내부 Configuration을 직접 다루지 않아도 React Application을 바로 개발할 수 있다는 것이 CRA의 핵심 장점이었습니다.

---

### Zero Configuration

CRA가 인기를 얻은 가장 큰 이유 중 하나는 **Zero Configuration**이었습니다.

```bash
npx create-react-app my-app
cd my-app
npm start
```

개발자는 Build Tool의 세부 설정을 몰라도 다음 기능을 바로 사용할 수 있었습니다.

```text
CRA

├─ JSX
├─ Babel
├─ Webpack
├─ Hot Reload
├─ ESLint
├─ Development Server
└─ Production Build
```

React 입문 과정에서 Build Environment보다 Component와 State 같은 React 자체를 먼저 배울 수 있도록 만들어줬습니다.

---

### 하지만 Frontend 환경이 바뀌었다

CRA가 등장했던 시기와 현재의 Frontend 환경은 상당히 다릅니다.

기존 React Application은 대부분 Client-side SPA였습니다.

```text
Browser
   ↓
React SPA
   ↓
REST API
   ↓
Backend
```

따라서 React Project의 핵심 문제는 Browser에서 실행할 JavaScript Bundle을 만드는 것이었습니다.

```text
React
  ↓
Bundle
  ↓
Browser
```

하지만 현대 React Application은 훨씬 다양한 Rendering Model을 사용합니다.

```text
React Application

├─ CSR
├─ SSR
├─ SSG
├─ Streaming
├─ Server Components
└─ Server Actions
```

단순 SPA Build Tool만으로 React 생태계 전체를 설명하기 어려워진 것입니다.

---

### React 자체도 변했다

React 18과 React 19를 거치면서 React의 역할도 크게 변했습니다.

과거 React는 주로 다음 영역을 담당했습니다.

```text
React

Client UI
+
Component
+
State
```

최근 React는 Framework와 결합해 다음 영역까지 다루기 시작했습니다.

```text
React

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

따라서 React 팀도 신규 Application에서는 단순한 Client Build Setup보다 **Framework 중심 접근을 적극적으로 권장하는 방향**으로 이동했습니다.

---

### CRA의 구조적 한계

Create React App은 내부 Configuration을 숨겨 개발 경험을 단순하게 만드는 구조였습니다.

```text
Developer
    ↓
react-scripts
    ↓
Webpack / Babel / ESLint
```

처음에는 편리했지만 Project가 복잡해질수록 Configuration을 수정하기 어려운 문제가 있었습니다.

CRA에서는 내부 설정을 크게 변경하려면 과거에는 `eject` 같은 방법을 사용하기도 했습니다.

```bash
npm run eject
```

하지만 한번 Eject하면 숨겨져 있던 설정이 Project로 전부 노출됩니다.

```text
Before

react-scripts


After eject

Webpack Config
Babel Config
ESLint Config
etc.
```

CRA의 간단함이 동시에 Customization의 제약이 되는 구조였습니다.

---

### Build Tool도 크게 발전했다

CRA가 만들어질 당시 Frontend Build 환경에서는 Webpack이 사실상 표준에 가까웠습니다.

```text
React
  ↓
Webpack
  ↓
Bundle
```

하지만 이후 새로운 Build Tool들이 등장했습니다.

```text
Frontend Build Tools

├─ Vite
├─ Parcel
├─ Rsbuild
├─ esbuild
└─ Turbopack
```

특히 Vite는 빠른 Development Server와 단순한 Configuration을 기반으로 빠르게 확산됐습니다.

```text
Source Code
    ↓
Vite
    ↓
Fast Dev Server
```

CRA가 제공했던 간단한 개발 경험을 더 현대적인 Toolchain으로 제공할 수 있게 된 것입니다.

---

### 일반 SPA라면 Vite

Server Rendering이나 Full Stack 기능이 필요하지 않은 일반적인 React SPA에서는 Vite가 대표적인 선택지가 됐습니다.

```bash
npm create vite@latest
```

Architecture 역시 단순합니다.

```text
React
  ↓
Vite
  ↓
SPA
  ↓
Backend API
```

예를 들어 Backend가 Spring Boot나 NestJS로 별도로 존재한다면 다음과 같은 구조가 자연스럽습니다.

```text
Frontend

React + Vite
      ↓
REST API


Backend

Spring Boot / NestJS
      ↓
Database
```

Frontend와 Backend를 명확히 분리하는 프로젝트에서는 여전히 매우 일반적인 Architecture입니다.

---

### Full Stack / SSR이라면 Framework

SSR이나 Server Component 같은 기능이 필요하다면 Build Tool만으로는 부족합니다.

이 경우 React Framework를 사용하는 방향이 권장됩니다.

```text
React
  ↓
Framework
```

대표적으로 다음과 같은 선택지가 있습니다.

```text
React Framework

├─ Next.js
└─ React Router Framework Mode 등
```

Framework는 Build뿐 아니라 다음 기능까지 제공합니다.

```text
Framework

├─ Routing
├─ Data Loading
├─ SSR
├─ SSG
├─ Server Rendering
├─ Streaming
├─ Server Functions
└─ Deployment Integration
```

즉 CRA를 대체하는 하나의 Tool이 등장했다기보다 **Application 요구사항에 따라 Build Tool과 Framework를 선택하는 구조로 바뀐 것**입니다.

---

### 과거의 React 프로젝트 시작 방식

예전에는 React Project를 만든다고 하면 선택지가 단순했습니다.

```text
React Project
      ↓
Create React App
```

Tutorial이나 강의에서도 CRA가 사실상 기본이었습니다.

```bash
npx create-react-app my-app
```

React를 배우는 과정 자체가 CRA와 함께 시작되는 경우가 많았습니다.

---

### 현재의 React 프로젝트 시작 방식

이제는 먼저 Application의 성격을 판단해야 합니다.

```text
React Project
     ↓
어떤 Application인가?
```

일반 SPA라면,

```text
React
  ↓
Vite
```

Server Rendering이나 Full Stack Application이라면,

```text
React
  ↓
Framework
  ↓
Next.js 등
```

Library를 만들거나 독자적인 Build 환경이 필요하다면 다른 Build Tool을 선택할 수도 있습니다.

```text
React
  ↓
Vite / Parcel / Rsbuild
```

즉 React 프로젝트 생성 방식이 **하나의 공식 Starter에서 여러 Architecture 선택지로 분화된 것**입니다.

---

### 왜 중요한가

Create React App은 단순한 Tool 하나가 아니었습니다.

오랫동안 React 입문과 SPA 개발의 사실상 기본 출발점 역할을 했습니다.

```text
React 시작
   =
Create React App
```

이 공식이 깨졌다는 것은 React 생태계의 구조 자체가 바뀌었다는 의미입니다.

```text
과거

React
  ↓
SPA
  ↓
CRA


현재

React
  ↓
Application Architecture
  │
  ├─ SPA → Vite
  │
  └─ Full Stack / SSR → Framework
```

React 개발자가 Project를 시작할 때부터 **Rendering 방식과 Application Architecture를 선택해야 하는 시대**가 된 것입니다.

---

### React가 Framework 중심으로 이동하는 이유

React의 새로운 기능 중 일부는 Framework와 함께 사용할 때 의미가 커집니다.

예를 들어 다음과 같은 기능입니다.

```text
Server Components

Server Rendering

Streaming

Actions

Data Loading
```

React 자체는 UI Library이기 때문에 Routing, Server Runtime, Build System까지 모두 제공하지 않습니다.

따라서 Framework가 React의 기능을 실제 Application Architecture와 연결합니다.

```text
React Primitive
      ↓
Framework
      ↓
Application
```

React 팀이 Framework 사용을 권장하는 이유도 이 구조와 연결됩니다.

---

### Frontend와 Backend의 경계 변화

CRA 시대의 대표적인 구조는 명확했습니다.

```text
React SPA
   ↓
REST API
   ↓
Backend
```

Frontend와 Backend가 별도의 Application으로 존재했습니다.

최근 React Framework에서는 구조가 달라질 수 있습니다.

```text
React Framework

├─ Client Component
├─ Server Component
├─ Route
├─ Data Fetching
└─ Server Logic
```

Frontend Project 내부에 일부 Backend 역할까지 포함될 수 있습니다.

```text
Browser
   ↓
React Framework
   ↓
Backend / Database
```

CRA의 종료는 이런 **Frontend Architecture 변화와도 연결되는 사건**입니다.

---

### 그렇다고 SPA가 사라진 것은 아니다

Framework가 강조된다고 해서 모든 React Application을 Next.js로 만들어야 하는 것은 아닙니다.

예를 들어 다음과 같은 Application이라면 Vite 기반 SPA가 훨씬 단순할 수 있습니다.

```text
Admin

Internal Tool

Dashboard

Backend가 별도로 존재하는 서비스

SEO가 필요하지 않은 Application
```

Architecture는 다음처럼 유지할 수 있습니다.

```text
React + Vite
      ↓
Backend API
      ↓
Database
```

중요한 것은 Framework가 무조건 정답이라는 것이 아니라 **Application 요구사항에 따라 Tool을 선택하는 것**입니다.

---

### 신규 프로젝트에서는 CRA를 선택할 이유가 거의 없다

CRA가 Deprecated 되면서 신규 프로젝트에서는 굳이 CRA를 선택할 이유가 거의 사라졌습니다.

```text
New React Project

CRA
 ↓
Deprecated
```

대신 다음처럼 판단하는 것이 자연스럽습니다.

```text
일반 SPA

React + Vite


SSR / SEO / Full Stack

React Framework


Custom Build Environment

Vite / Parcel / Rsbuild
```

Project Architecture에 맞는 Tool을 처음부터 선택하는 방식입니다.

---

### 기존 CRA 프로젝트는 어떻게 해야 하나

기존 CRA Application이 있다고 해서 당장 동작하지 않는 것은 아닙니다.

```text
Existing CRA Project
      ↓
계속 실행 가능
```

하지만 장기적으로 React와 Build Tool 생태계가 발전하면서 Migration을 검토할 필요가 생깁니다.

일반 SPA라면 다음과 같은 Migration이 가능합니다.

```text
Create React App
      ↓
Vite
```

Framework 기능이 필요한 경우에는 단순 Build Tool Migration보다 Architecture 자체를 검토해야 합니다.

```text
CRA SPA
   ↓
Architecture Review
   ↓
Next.js 등 Framework
```

---

### CRA → Vite Migration에서 확인할 것

기존 CRA Project를 Vite로 이동할 때는 단순히 Package만 변경하는 것으로 끝나지 않을 수 있습니다.

다음 항목을 확인할 필요가 있습니다.

```text
Migration

├─ Environment Variable
├─ Build Script
├─ Asset Path
├─ Alias
├─ Proxy 설정
├─ Test Environment
└─ Browser Compatibility
```

예를 들어 CRA에서는 Environment Variable에 다음 Prefix를 사용했습니다.

```text
REACT_APP_API_URL
```

Vite에서는 일반적으로 다음과 같은 형태를 사용합니다.

```text
VITE_API_URL
```

그리고 접근 방식도 달라집니다.

```javascript
import.meta.env.VITE_API_URL
```

Build Tool이 달라지면 주변 Configuration도 함께 점검해야 합니다.

---

### 개발자 경험의 변화

CRA의 핵심 목적은 React 개발자가 Build Tool을 몰라도 프로젝트를 시작할 수 있도록 만드는 것이었습니다.

```text
Build Complexity
      ↓
CRA가 숨김
      ↓
Developer는 React에 집중
```

현재는 Build Tool 자체가 훨씬 단순해졌습니다.

```text
Vite

Fast
+
Simple
+
Extensible
```

따라서 별도의 거대한 Abstraction Layer 없이도 비교적 간단한 Developer Experience를 제공할 수 있게 됐습니다.

---

### React 생태계의 기준 변화

React 개발의 기본 구조 역시 다음처럼 변화했습니다.

```text
2010s

React
+
Create React App
+
Client SPA
```

이후에는

```text
2020s

React
+
Modern Build Tool / Framework
+
Client + Server
```

방향으로 이동하고 있습니다.

Create React App의 Deprecated는 이러한 변화가 공식적으로 확인된 사건이라고 볼 수 있습니다.

---

### 실무 영향

신규 React 프로젝트에서는 먼저 Application 요구사항을 기준으로 Tool을 결정하는 것이 중요합니다.

```text
새 React Project
      ↓
Requirement
      ↓
┌─────────────────────┐
│                     │
SPA                 Full Stack / SSR
 │                     │
 ↓                     ↓
Vite                Framework
                    Next.js 등
```

기존 CRA Project에서는 당장 Migration이 필수인 것은 아니지만 장기적인 유지보수를 고려하면 Modern Toolchain으로의 이전을 검토할 필요가 있습니다.

특히 새로운 React 기능과 최신 Library들이 점점 Modern Build Tool과 Framework를 중심으로 개발되는 만큼 시간이 지날수록 CRA를 유지하는 장점은 줄어들 가능성이 큽니다.

결국 Create React App의 공식 Deprecated는,

> **React 프로젝트를 시작하면 먼저 CRA를 설치하던 시대가 끝나고 Application 특성에 따라 Build Tool과 Framework를 선택하는 시대로 완전히 전환됐다는 사건**

이라고 볼 수 있습니다.

CRA가 사라졌다는 것보다 더 중요한 변화는 **React 생태계의 기본 Architecture가 Client SPA 하나에서 SPA, SSR, Server Components, Full Stack Framework 등 여러 형태로 확장됐다는 점**입니다.

2025년 2월 14일(금) 주간 개발트렌드

독자의 메모