2025년 2월 14일, 리액트팀은 공식 블로그에 CRA를 deprecating 했다는 블로그를 포스팅했었는데요. 이전부터 CRA가 deprecated 될 거라는 소문(?)이 많이 들었지만 2월 14일을 기점으로 공식적으로 업데이트 된 것으로 보입니다.
이번 블로그에서는 CRA가 더 이상 유지되지 않는 이유와 리액트 팀이 프로젝트를 시작할 때 권장하는 방법을 정리해 보면서, 리액트의 방향성이 어떻게 변화하고 있는지 살펴보겠습니다.
CRA는 왜 사라지나? (CRA의 한계점)
Although Create React App makes it easy to get started, there are several limitations that make it difficult to build high performant production apps. In principle, we could solve these problems by essentially evolving it into a framework.
리액트 팀에 따르면, CRA는 프로젝트를 빠르게 시작할 수 있도록 도와주지만, 프로덕션 환경에서 성능을 최적화하는 데 한계가 있다고 합니다. 그리고 이러한 문제들은 이제 Next.js, React Router와 같은 프레임워크들이 더 효과적으로 해결하고 있기 때문에 CRA가 더 이상 필요하지 않다고 판단했습니다.
특히, 요즘의 프레임워크들은 라우팅, 데이터 페칭, 코드 분할 등의 기능을 기본적으로 제공하며, CRA가 이를 따라가기 어려운 상황입니다.
CRA의 주요 한계점
1. 빠르게 변화하는 웹 개발 환경을 따라가지 못함
최근 몇 년 사이 Next.js, Vite, Remix 등의 프레임워크가 등장하면서 프론트엔드 개발 환경이 급격히 발전했습니다. 하지만 CRA는 이러한 변화에 적절히 대응하지 못했고, 유지보수가 점점 느려졌습니다.
2. 느린 빌드 속도 & 개발 환경
CRA는 Webpack 기반으로 동작하는데, Webpack 설정이 무겁기 때문에 빌드 속도가 느립니다. 반면, 최신 번들러인 Vite는 ESBuild를 활용하여 훨씬 빠른 개발 환경을 제공합니다.
3. 서버 사이드 렌더링(SSR) & 정적 사이트 생성(SSG) 미지원
CRA는 기본적으로 클라이언트 사이드 렌더링(CSR)만 지원하기 때문에 SEO 성능이 낮고 초기 로딩 속도가 느립니다. 반면, Next.js, Remix와 같은 프레임워크들은 SSR, SSG, ISR 등의 기능을 제공하여 성능과 SEO 최적화를 지원합니다.
4. 코드 스플리팅 & 데이터 페칭 최적화 부족
CRA는 기본적으로 코드 스플리팅을 자동으로 지원하지 않으며, 데이터 페칭 관련 최적화 기능도 부족합니다. 최신 프레임워크들은 자동 코드 스플리팅과 더 효율적인 데이터 페칭 방법을 제공하여 성능을 더욱 향상시킵니다.
Framework를 추천한다는 것
CRA의 Deprecation을 단순히 "잘 사용되지 않기 때문에 폐기된 것"이라고 볼 수도 있지만, 사실상 웹 개발 환경의 변화에 맞춘 자연스러운 흐름이라고 볼 수 있습니다.
리액트 팀은 블로그에서 "Why we Recommend Frameworks" 섹션을 통해, 프레임워크를 사용하는 것이 웹 개발에 더욱 적합한 이유를 설명했습니다.
"Frameworks impose some opinions about structuring your app in order to provide a much better user experience, in the same way build tools impose some opinions to make tooling easier."
즉, 프레임워크는 앱을 구조화하는 방법에 대해 일정한 규칙을 강제(opinionated structure)하고, 이러한 규칙이 결국 더 나은 사용자 경험으로 이어진다는 것입니다.
위 문장을 차례차례 해석해보면 아래와 같습니다.
Frameworks impose some opinions about structuring your app
프레임워크는 앱 구조를 정하는 데 있어 일정한 의견을 강제한다
→ 즉, 프레임워크는 개발자가 앱을 구조화하는 방식에 대해 일정한 "규칙"을 제공합니다.
→ 예를 들어, Next.js는 파일 기반 라우팅을 강제하고, Angular는 모듈(Module) 구조를 따르게 합니다.
이러한 강제적인 구조(opinionated structure)가 있으면, 개발자들이 을 만들 수 있고, 유지보수도 쉬워집니다. 또한, 초보 개발자들도 빠르게 적응할 수 있습니다.
프레임워크를 사용하면:
✅ 일관된 구조 제공 → 개발자가 더 쉽게 프로젝트를 유지보수 가능
✅ 성능 최적화 → 자동 코드 스플리팅, 빠른 빌드 속도, 서버 사이드 렌더링 지원
✅ 최신 개발 환경 반영 → 최신 번들러 및 트렌드를 쉽게 적용 가능
원래 우리가 기본적으로 풀어야할 문제들을 프레임워크에서 이미 제공해주고 있기때문에 그리고 구조를 강조하면 유지보수에 좋고, 일관된 방식으로 앱을 만들 수 있기 때문에 프레임워크를 추천한다는 결론이 흥미로웠습니다. 실제로 현업에서 Nextjs가 주된 프레임워크로 많이 쓰이고 있으며 또 라이브러리였던 React Router가 v7로 넘어오면서 프레임워크 버젼을 제공해주는 것도 같은 맥락일지도 모르겠다는 생각이 들었습니다.
Webpack 에서 Vite 로
과거에는 CRA가 Webpack을 기반으로 동작했기 때문에, 많은 플러그인과 예제들이 Webpack 환경을 중심으로 구성되어 있었습니다. 하지만 최근에는 Vite가 새로운 기본 번들러로 자리 잡고 있습니다.
예를 들어:
- React Router v7에서는 Vite를 기본 번들러로 지원하며, 이를 기반으로 라우팅을 제공
- 리액트 공식 문서에서도 Vite를 사용한 프로젝트 설정을 추천
이처럼 CRA에서 Vite로의 전환은 단순한 도구의 변화가 아니라, 빠르고 효율적인 개발 환경으로의 진화라고 볼 수 있습니다.
마무리: CRA의 끝과 새로운 시작
제가 처음 리액트를 공부할 때 가장 먼저 콘솔 창에 입력했던 명령어가 npx create-react-app my-app이었다는 사실을 떠올리니 감회가 새롭고, 새삼 시간이 많이 지났다는 것을 실감하게 됩니다. 또한, 웹 개발 환경이 크게 변화했다는 것도 체감됩니다.
블로그 글 마지막 부분에서 CRA를 만들어 준 댄 아브라모브(Dan Abramov)와 유지보수에 힘쓴 분들, 그리고 글을 검수한 분들에게 감사를 표하는 "Thanks for" 문구를 보니 괜히 가슴이 뭉클해졌습니다. 역시 감성적인 F 유형 개발자인 것 같습니다. 😊
