👋 굿바이 CRA (Sunsetting Create React App)

TLDR;

리액트 앱을 설치하기 위해 CRA를 사용하고 계셨나요? 이제는 CRA가 deprecate 됩니다.
해당 이유는 크게 CRA는 라우팅, 데이터 fetching, 코드 스플릿을 자체적으로 지원하지 않아 
추가적으로 라이브러리에 의존해야했다는 점, 최근 많은 프레임워크들이 해당 문제들을 해결했고 해당 기능들을 위해 CRA관리가 불필요해졌기 때문입니다.

프레임워크나 빌드 툴로 리액트 프로젝트를 마이그레이션하기를 권장합니다. 비록 CRA+빌드 툴도 선택 가능한 옵션이지만 라우팅, 데이터 fetching, 코드 스플릿 기능을 “잘” 통합해놓은 Next.js, React Router, Expo와 같은 프레임워크를 사용하는 것을 추천합니다.

위의 프레임위크들은 SSR과 CSR 옵션 모두 제공합니다.
SSR이 SEO뿐만 아니라 다운로드해야할 자바스크립트 양을 줄여 성능 최적화에 도움이 된다는 점을 고려하면 SSR와 CSR이 필요한 페이지를 적절하게 사용하는 것이 중요해보입니다.

 

해당 글은 February 14, 2025 by Matt Carroll and Ricky Hanlon이 작성한 Sunsetting create react app을 번역/의역 했습니다.

 

Create React App를 deprecate하기로 했습니다.

CRA로 만들어진 앱들은 프레임워크로 마이그레이션을 하거나 vite, parcel 이나 RSBuild 와 같은  build tool로 마이그레이션 하기를 권장합니다.

해당 포스트는 추가적으로 프로젝트에 적절한 프레임워크가 없는 경우를 위해 프레임워크 만드는 법,  React app 처음부터 만드는 법에 대해 다루고자 합니다.

 

2016년에 Create React app을 출시했을 당시, React app을 ‘어떻게 만들어야한다’는 규칙이 없었습니다.

React 앱을 만들기 위해서는 JSX, lint, hot reloading와 같은 기본 기능들을 지원하기 위해 여러 툴들을 추가적으로 설치해야했죠. 이 까다로운 일을  커뮤니티가 만든 boilerplates가 핸들링했었지만, boilerplate은 업데이트하기도 어렵고 fragmentation은 리액트가 새로운 기능들을 추가하기 어렵게 만들었습니다.

 

CRA는 이 문제를 하나의 통일된 권장 설정방식으로 여러 툴들을 합쳐서 해당 문제를 해결했었죠. 

이 방식으로 앱들이 간단하게 새로운 툴과 기능을 지닌 버젼으로 업그레이드를 하거나, 리액트 팀이 작지 않은 툴 변화(Fast Refresh support, React Hooks lint rules)를 가능한 많은 사용자들에게 제공할 수 있도록 했죠. 이 모델의 인기에 힘입어 오늘날에는 해당 방식으로 작업하는 툴들만의 카테고리가 아예 있을 정도가 되었습니다.

 

Deprecating Create React App

 

비록 CRA로 프로젝트 시작하기는 쉽지만, 프로덕션 앱으로써 최상의 기능들을 하기에는  여러 제약들 이 있었습니다. 

원칙대로라면 프레임워크로 발전시켜서 해결할 문제이지만, CRA는 현재 유지보수 관리자들이 없고, 

이미 이 문제들을 해결한 프레임워크들이 수둑해서 CRA를 deprecate하기로 했습니다. 

 

오늘부터 새로운 app을 CRA로 설치할 경우 deprecation 경고를 보시게 될 것입니다.

 

 

프레임워크로 마이그레이션하기

 

이제는 프레임워크로 새로운 리액트앱 생성하기를 권장합니다.

권장하고 있는 모든 프레임워크는 클라이언트 사이드 랜더링(CSR)과  싱글 페이지 앱(SPA)을 지원하고, CDN이나 서버없이 정적 호스팅 서비스로 배포가 가능하도록 지원합니다.

 

이미 CRA로 만들어진 앱은 다음의 가이드를 통해 순수 클라이언트(client-only) 기반의 SPA로 마이그레이션하는데 도움이 될 것입니다.

• Next.js’ Create React App migration guide
• React Router’s framework adoption guide.
• Expo webpack to Expo Router migration guide

 

빌드 툴로 마이그레이션하기

 

앱이 독특한 제약이 있거나, 직접 프레임워크를 만들어 문제를 해결하기를 원하거나, 리액트가 어떻게 동작하는 지 뼈대부터 살펴보고 싶다면 Vite, Parcel 나 Rsbuild를 통해 리액트 세팅을 커스텀마이징할 수 있습니다.

 

아래의 링크들은 CRA로 만들어진 앱을 빌드툴로 마이그레이션하는데 도움이 될 것입니다: 

• Vite Create React App migration guide
• Parcel Create React App migration guide
• Rsbuild Create React App migration guide

 

Vite, Parcel 나 Rsbuild로 시작하기 위해 도움이 필요하시면 Building a React App from Scratch문서를 참고해주세요.

🤔 프레임워크가 필요할까요?

대부분의 앱들은 프레임워크의 덕을 보겠지만, 특정 경우에는 리액트를 처음부터 새팅하는 것이 더 적절할 수 있습니다. 먼저 살펴볼 것은 앱이 라우팅이 필요한 경우라면 프레임워크를 사용하는 것을 권장합니다.
Svelte가 Sveltekit이 있고, Vue는 Nuxt가 있고, Solid가 SolidStart가 있듯이, 리액트는 data-fetching 와 code-splitting과 같은 기능들이 라우팅에 처음부터 완전히 통합되어 있는  프레임워크를 사용하는 것을 권장합니다. 복잡한 설정을 직접해야하는 수고스러움을 이미 만들어진 프레임워크들이 해결하죠. 하지만 Vite, Parcel 또는 Rsbuild와 같은 빌드 툴로 리액트 앱 처음부터 만드는 것 또한 언제나 선택가능한 옵션입니다.

 

그럼에도 불구하고 리액트가  프레임워크 사용을 권장하는 이유와  빌드 툴의 한계에 대해 살펴보겠습니다.

 

빌드 툴의 한계

 

CRA와 빌드 툴을 통해 리액트 앱을 시작하는 것이 쉬워졌습니다.

npx create-react-app my-app를 실행하면 dev 서버, linting, production 빌드를 포함해 충분히 설정이 된 리액트 앱가 만들어지죠.

 

예를 들면 내부 어드민 툴을 만들고자 한다면 다음과 같은 랜딩 페이지로 시작할 수 있습니다: 

 

export default function App() {

  return (

    <div>

      <h1>Welcome to the Admin Tool!</h1>

    </div>

  )

}

 

 

JSX와 같은 리액트 기능들을 바로 사용하여 코딩을 할 수 있고, 디폴트 린트 규칙, dev 와 prod 각각에서 실행가능하도록 하는 번들러가 있지만, 실제 프로덕션 앱을 만들기에는 필수적인 툴들이 부재하죠.

대부분의 프로덕션 앱들은 routing, data fetching 그리고 코드 스프릿하기 등의 기능들이 필요합니다.

 

라우팅

 

CRA는 라우팅 규칙을 특정하고 있지는 않습니다. 막 리액트를 시작했다면 useState을 통해 라우트를 변경하는 방식 사용할 수도 있습니다. 하지만 해당 방식은 앱에 링크를 공유할 수 없도록 합니다. 모든 링크들은 같은 페이지를 가리키고, 앱의 구조를 관리하기 어려워지죠.

 

import {useState} from 'react';



import Home from './Home';

import Dashboard from './Dashboard';



export default function App() {

  // ❌ Routing in state does not create URLs

  const [route, setRoute] = useState('home');

  return (

    <div>

      {route === 'home' && <Home />}

      {route === 'dashboard' && <Dashboard />}

    </div>

  )

}

 

CRA를 사용하는 대부분의 앱들은 React Router 나Tanstack Router와 같은 라우팅 라이브러리를 추가하여 라우팅 문제를 해결합니다. 라우팅 라이브러리를 통해 앱에 추가적인 라우트를 구성할 수 있고, 앱의 구조에 대한 opinion을 제공하며 라우트에 해당되는 링크를 공유할 수 있도록 합니다.

 

 React Router의 경우 다음과 같이 라우트를 정의할 수 있죠: 

 

import {RouterProvider, createBrowserRouter} from 'react-router';



import Home from './Home';

import Dashboard from './Dashboard';



// ✅ Each route has it's own URL

const router = createBrowserRouter([

  {path: '/', element: <Home />},

  {path: '/dashboard', element: <Dashboard />}

]);



export default function App() {

  return (

    <RouterProvider value={router} />

  )

}

 

 

이제 /dashboard링크를 공유할 수 있고, 앱이 대쉬보드 페이지로 이동할 수 있게 되었죠. 

라우팅 라이브러리를 추가하면 중첩 라우트(nested routes), 라우트 가드(route guard), 라우트 트랜지션(route transition)와 같이 라우팅 라이브러리 없이 구현하기 어려운 기능들을 누릴 수 있도록 합니다.

 

비록 라우팅 라이브러리를 추가하는 것이 앱의 복잡도를 높이지만 없으면 구현하기 어려운 추가 기능들을 제공하기도 하죠.

 

데이터 fetching

 

CRA의 큰 문제점 중 하나는 data fetching이 었습니다. CRA는 데이터를 가져오는 방식이 특정되어 있지 않고, 이제 막 시작하고 있는 입장이라면 useEffect안에 데이터를 fetch해서 로드하는 옵션을 고려했을 수도 있습니다.

하지만 이 방식은 컴포넌트가 랜더된 이후에 데이터가 fetch되기 때문에 네트워크 waterfall를 일으킬 수있는 문제가 있습니다. 네트워크 waterfall은 코드를 다운로드 하고 있을 때 병렬적으로 데이터를 fetch하는 것이 아니라, 앱이 랜더될 때 수행하여 발생합니다.

 

다음과 같이 useEffect 안에서 데이터를 fetch하면 실제로는 더 일찍 데이터를 fetch할 수 있었음에도 불구하고, 유저는 실제 콘텐츠를 보기까지 더 오래 기다려야한다는 문제가 생깁니다.

 

export default function Dashboard() {

  const [data, setData] = useState(null);



  // ❌ Fetching data in a component causes network waterfalls

  useEffect(() => {

    fetch('/api/data')

      .then(response => response.json())

      .then(data => setData(data));

  }, []);



  return (

    <div>

      {data.map(item => <div key={item.id}>{item.name}</div>)}

    </div>

  )

}

 

 

React Query, SWR, Apollo, or Relay 와 같은 fetch 라이브러리를 사용해서 데이터를 prefetch하여 컴포넌트가 랜더하기 전에 요청을 시작할 수 있도록 문제를 해결할 수 있죠. 

 

다음 예시와 같이 라우팅 loader 패턴와 함께 라우트 레벨의 데이터 의존성을 부여하면 라우터가 데이터 fetch를 특정화하여 최적화하도록 할 수 있습니다: 

export async function loader() {

  const response = await fetch(`/api/data`);

  const data = await response.json();

  return data;

}



// ✅ Fetching data in parallel while the code is downloading

export default function Dashboard({loaderData}) {

  return (

    <div>

      {loaderData.map(item => <div key={item.id}>{item.name}</div>)}

    </div>

  )

}

 

첫 로드 시  라우터는 라우트를 랜더하기 전에 데이터를 바로 fetch할 수 있게 됩니다. 

유저가 앱 내에서 이동 시 데이터와 라우트를 병렬적으로 가져올 수 있게 되어 화면에 콘텐츠를 보기까지의 시간을 단축하고 유저 경험을 개선할 수 있죠. 

 

하지만 해당 방식은 로더를 적절히 configure해야하고, 성능과 복잡성 간의 트레이드오프를 요구합니다.

 

코드 스플릿하기

 

CRA의 큰 문제 중 하나는 코드 스플릿하기입니다.

CRA는 코드 스플릿을 하기 위해 특정된 해결책을 제시하지 않죠. 리액트를 막 시작한 입장이라면 코드 스플릿하는 것 자체를 아예 고려하지 않았을 수도 있습니다.

 

해당 경우, 앱이 싱글 번들의 경우  bundle.js : 75kb로 제공된다는 점입니다.

 

하지만 유저가 필요할 경우에만 번들을 다운로드할 수 있도록 분리하는 것이 성능을 고려하면  이상적이죠.

유저가 현재 있는 페이지에 대한 코드만 다운로드해도 되기 때문에 앱을 로드하기까지 대기시간을 줄일 수 있습니다.

• core.js      25kb
• home.js      25kb
• dashboard.js 25kb

 

코드 스플릿을 하는 방법 중 하나는 React.lazy를 사용하는 것입니다.

하지만 이는 컴포넌트가 랜더되기 전까지 코드 fetch되지 않는다는 것을 의미하고, 이는 네트워크 waterfall로 이어질 수 있습니다. 더 적절한 해결책은 코드가 다운로드하고 있을 때 병렬적으로 코드를 fetch할 수 있게 라우터 feature를 사용하는 것입니다. 

 

예를 들어 React Router는 lazy 옵션을 추가하여 특정 라우트에서는 코드 스플릿을 하여 로드될 때 최적화를 해줍니다:  

 

import Home from './Home';

import Dashboard from './Dashboard';



// ✅ Routes are downloaded before rendering

const router = createBrowserRouter([

  {path: '/', lazy: () => import('./Home')},

  {path: '/dashboard', lazy: () => import('Dashboard')}

]);

 

최적화된 코드 스플릿하기는 쉽지 않고, 유저들이 필요 이상으로 많은 코드를 다운로드하게끔 하는 실수로 이어질 수도 있습니다. 캐싱 최대화하기, 병렬 fetch, "상호작용 시에 임포트하기 (import on interaction)" 패턴과 함께 사용되어야 라우터와 데이터 로딩 해결책을 잘 사용할 수 있죠.

 

+ CRA를 보내주는 추가적인 이유들…

 

라우팅, 데이터 fetching, 코드 스플릿하기 등의 기능 부재는 CRA를 보내줘야하는 여러 이유들 중 몇가지에 불과합니다. 위의 기능들을 추가하고도 pending state 고려하기, 네비게이션 인터럽션, 사용자들을 위한 에러 메세지, 그리고 데이터 revalidate하기 등 실제 앱을 만들기 위해서 해결할 문제들이 존재하죠.

 

실제 유저들을 위해서 해결해야할 문제 카테고리들을 나열하자면: 

 

• Accessibility
• Asset loading
• Authentication
• Caching
• Error handling
• Mutating data
• Navigations
• Optimistic updates
• Progressive enhancement
• Server-side rendering
• Static site generation
• Streaming

 

이 모두 최적의  로딩 시퀀스(loading sequence)를 만들기 위해 함께 고려해야할 사항이죠.

CRA로 각각의 문제를 해결하기에는 각 요소들이 서로 복잡하게 얽혀있고 사용자들이 익숙하지 않은 깊이의 전문성이 필요한 경우도 있습니다. 해당 문제를 해결하기 위해 유저들은 CRA가 해결하고자 했던 문제들을 직접 해결하기에 나서서 말들게 되었죠.

 

프레임워크를 권장하는 이유

 

어찌저찌 CRA와 빌드 툴(e.g. Vite, Parcel)을 통해 앞서 언급한 문제들을 해결할 수 있었겠지만, “잘”하기는 쉽지 않다는게 사실입니다. CRA가 여러 빌드 툴과 통합되었듯이, 유저에게 최적의 경험을 제공하기 위해 해당 기능들을 지닌 툴들을 통합하기 위한 노력이 필요하죠.

해당 카테고리(빌드 툴, 랜더링, 라우팅, 데이터 fetching, 코드 스플릿하기)의 툴들을 통합한 것이 바로 “프레임 워크”입니다. 리액트 자체를 프레임워크라고 부르신다면, 툴들을 통합해놓은 해당 카테고리를 “메타 프레임워크”라고도 부를 수 있겠죠.

 

프레임워크는 빌드 툴들이 툴 사용이 용이하도록 opinion을 강제하듯이, 더 좋은 유저 경험을 위해 앱을 특정 구조로 만들도록 opinion을 강제할 수 있습니다. 

앞서 말한 이유때문에 새 프로젝트를 시작할 경우  Next.js, React Router , Expo를  권장합니다. 프레임워크들은 CRA를 사용할 때와 같은 경험과 더불어 유저들이 실제 프로덕션 앱들을 만들기 위해 필요한 해결책들을 제시하죠.

 

🤔 서버사이드 랜더링이 필수인가요?

앞서 권장한 프레임워크들 모두 클라이언트 사이드 랜더 기반의 앱을 만들 수 있는 옵션을 제공합니다.
특정 경우 CSR가 페이지에 적절한 선택일 수 있지만, 대부분의 경우 그렇지 않을 겁니다. 앱 대부분이  클라이언트 사이드라고 해도  static-site generation (SSG) 나 server-side rendering (SSR)의 덕을 볼 페이지들이 종종 있습니다. 예를 들면 이용 약관 페이지(Terms of Service page), 도큐멘테이션 등이 해당되죠.  

서버 랜더링은 주로 클라이언트 쪽에 자바스크립트에 덜 보내고, 완성된 HTML 문서를 보내기 때문에 Total Blocking Time (TBD)를 줄여 First Contentful Paint (FCP)가 빠르게 이루어져  Interaction to Next Paint (INP)를 감소시켜 줍니다. 
이러한 성능 최적화를 위해 크롬 팀은 static 이나 server-side 랜더를 순수 클라이언트 사이드 랜더 보다 권장합니다. 서버를 사용하기에 트레이드오프들이 있고 모든 페이지를 위한 최선의 선택이 아닐 수 있습니다. 

페이지를 서버에서 생성하기 위한 추가 비용과 시간은 Time to First Byte (TTFB)를 증가시킬 수 있습니다. 각각의 트레이드오프를 고려하여 적합한 랜더링 방식을 필요에 따라 취사선택하여 최적화된 앱을 만들 수 있습니다.

프레임워크들은 페이지에 서버를 사용할 옵션만 줄뿐, 강제하지는 않습니다. 
해당 방식으로 앱의 각 페이지에 적절한 랜더링 전략을 선택할 수 있죠.

 

그럼 서버 컴포넌트는?

 

앞서 언급한 프레임워크 모두 리액트  서버 컴포넌트 사용을 지원합니다.

서버 컴포넌트들은 라우팅과 데이터 fetching 문제들을 서버에서 해결할 수 있도록 하고, 클라이언트 컴포넌트를 위한 코드 스플릿을  랜더해야하는 데이터에 따라 해주기 때문에 보내야하는 자바스크립트양을 줄이고  loading sequence를 최적화합니다.

 

서버 컴포넌트는 서버가 필요하지 않습니다.CI 서버에서 static-site generated app (SSG) 앱을 생성하기 위해 빌드 타임 시 실행될 수 있고, 웹 서버에서 SSR(서버 사이드 랜더)된 앱에서 런타임에 실행될 수 있습니다.

 

 리액트 서버 컴포넌트와 제로-번들 사이즈 소개 와 공식 문서에서 추가적인 내용을 살펴보실 수 있습니다.

 

 

🗒️ 서버 랜더링은 SEO만을 위한 것은 아닙니다.

 

서버 랜더링이 SEO만을 위한 것이라는 흔한 오해가 있다.

서버 랜더링이 SEO를 개선할 있다는 것은 맞지만, 유저가 화면에 콘텐츠를 보기 위해 다운로드하고 파싱해야할 자바스크립트의 양을 줄여서 성능을 개선할 수 있다.

이러한 성능 최적화를 이유로 크롬 팀은 개발자들에게 완전히 클라이언트 사이드보다  static이나 서버 사이드 랜더링을 장려 한다.

 

 

---

 

Reference

 

Sunsetting Create React App

Sunsetting Create React App – React