배경지식
- 미국 유튜버이자 CEO인 Theo는 React Docs에서 최근 별다른 발전이 없는 CRA를 권장하고 있는 문구를 제거하고 큰 인기를 얻고 있는 Vite를 추천하는 문서를 작성하는 것이 어떤지 트윗을 올립니다. 이 조사는 본인의 유튜브 커뮤니티를 통해서도 진행됩니다.
- 꽤 많은 구독자와 팬층을 가진 유튜버였을 뿐만 아니라 같은 생각을 하는 많은 개발자가 있었기 때문에 많은 지지를 받습니다.
- 이 지지를 기반으로 React Docs에 실제로 PR을 만들고 해당 내용에 대해 리액트 측에 의견을 묻습니다.
Theo의 PR 설명
PR 설명부 링크: https://github.com/reactjs/reactjs.org/pull/5487#issue-1551949585
Create React App은 특히 신규 개발자들에게 권장할 만한 기술은 아닙니다.
교육자로서 저는 CRA의 지속적인 권장으로 인해 새로운 리액트 개발자들이 불필요한 문제에 부딪히는 수많은 문제에 직면합니다. 저는 이 문제에 대해 트윗했고 많은 개발자의 수많은 동의를 보며 놀랐습니다.
저는 여기에 만든 이 PR 변경에 대한 것은 크게 중요하지 않으며, 새로 만드는 베타 문서에서 권장하는 기술에 대한 토론을 희망해 이 PR을 엽니다.
Dan Abramov의 답변
댓글 링크: https://github.com/reactjs/reactjs.org/pull/5487#issuecomment-1409720741
안녕하세요!
저희는 이 내용이 골칫거리라는 것을 이미 알고 있으며, 이를 해결하기 위한 제안을 준비하고 있습니다. 이 PR은 토론을 시작하기 위한 것이므로 Create React App의 미래에 대한 우리의 생각과 배경지식을 설명하기에 좋은 시기인 것 같습니다. 이 글에서 우리의 추론과 고려하고 있는 장단점에 대해 명확하게 하고 싶기 때문에 여러 섹션으로 구성된 긴 댓글이 될 것입니다. 참을성이 없으시다면 우리가 제안하는 앞으로의 방법에 관해 설명하는 마지막 섹션으로 스크롤 하세요.
Create React App이 존재하는 이유
이 토론에서 역사적인 맥락을 제공하기 위해 Create React App의 이야기를 다시 살펴보고 진화를 되짚어보고 싶습니다.
2016년 Create React App을 출시했을 당시 프런트엔드 도구 환경은 조각나 있었고 통합되어 있지 않았습니다. 기존 앱에 리액트를 추가하는 경우 <script>태그 또는 npm에서 import를 한 다음 기존 빌드 도구 구성을 수정했습니다. 하지만, 처음부터 리액트로만 빌드된 새 앱을 만드는 경우 이를 처리할 명확한 방법이 없었습니다.
Create React App을 만들기 전에는 여러 도구를 설치하고, JSX를 사용하기 위한 올바를 사전 설정을 하고, 개발 및 프로덕션 환경을 다르게 구성하고, 에셋 캐싱을 위한 올바른 설정을 한 뒤 린트을 구성하는 등의 설정이 필요했습니다. 이런 구성은 올바르게 수행하기는 매우 까다로웠습니다. 사람들은 복제할 수 있는 “보일러 플레이트” 저장소를 만들고 공유함으로써 이에 대처했습니다. 그러나 이런 방법은 다른 문제를 야기했습니다. 보일러 플레이트를 복제하고 프로젝트에 맞게 구성을 변경하면, pull을 통한 업데이트가 힘들었습니다. 프로젝트 설정이 오래되면 업데이트를 포기하거나 모든 도구가 다시 함께 작동하도록 하기 위해 큰 노력을 들여야 했습니다. 빠르게 움직이는 생태계에서 이는 매우 어려웠습니다.
Create React App은 여러 도구를 하나의 패키지로 결합하고 합리적인 기본 구성을 선택한 다음 도구 간의 작은 비호환성을 덮어써 이 문제를 해결했습니다. 이제 리액트로 새 프로젝트를 시작하고 싶다면, 명확하게 이 도구를 선택해서 활용하면 되었습니다! Create React App은 때때로 패키지를 업데이트했고, Create React App 아래에 있는 모든 도구는 “무료”로 받을 수 있었습니다. 이 모델은 매우 유명해져서 오늘날 이런 형태로 유지되는 전체 범주의 도구가 생깁니다. Vite는 이와 유사한 비전을 공유하며, 어떤 면에서는 이를 더 발전시키는 최고의 도구 중 하나입니다.
Create React App의 목표는 대부분의 리액트 사용자에게 새로운 리액트 웹앱을 시작하는 가장 좋은 방법을 제공하는 것이었습니다. 함께 작동하는 선별된 기능 모음을 제공했습니다. 시간이 지나면서 기본적으로 제공되는 “기준선”은 우리가 올바른 절충안을 파악함에 따라 확장될 것입니다. 예를 들어 런타임 오류에 대한 오버레이를 추가했습니다. 또한, 다양한 스타일 지정 옵션에 대한 지원도 추가했습니다. Fast Refresh를 기본 기능으로 추가해 컴포넌트 코드를 저장한 뒤 상태를 잃지 않고 변경 사항을 볼 수 있도록 기능도 추가했습니다. 이런 변화는 리액트 개발자 경험에 있어 큰 이정표였습니다. 또한, Create React App에서 컴파일 파이프라인을 완전히 제거했기 때문에 누구나 쉽게 컴파일 관련 기능을 추가할 수 있었습니다.
이처럼 선별된 설정을 갖는 것은 생태계에 여전히 가치가 있습니다. 리액트 훅이 나왔을 때 리액트 훅 린트 규칙을 기본 설정에 추가한 것처럼요. Create React App은 프로젝트를 시작하는 쉬운 방법일 뿐만 아니라 리액트 팀이 사소하지 않은 도구 변경 사항(Fast Refresh 지원, 리액트 훅 린트 규칙)을 가능한 가장 광범위한 청중에게 배포할 수 있도록 했습니다. 리액트 팀이 선별한 인기 있는 템플릿이 없다면 이런 도구 변경 사항을 광범위하게 적용하는 것은 어려웠을 것입니다.
Create React App의 문제
세월이 흐르면서 Create React App은 정체되었습니다. 많은 사람은 이 스레드에서 대안으로 제시된 방법보다 느리고 오늘날 사람들이 사용하기를 원하는 인기 있는 도구를 지원하지 않는다고 지적했습니다. 이런 문제를 원칙적으로 해결할 수 있습니다. 예를 들어 더 빠른 번들러를 사용하거나 Vite를 내부적으로 사용하기 위한 Create React App 내부 업데이트를 할 수 있습니다. 또는, 사람들에게 Create React App에서 Vite로 마이그레이션 하도록 제안할 수 있습니다. 하지만 우리가 다루고자 하는 훨씬 더 깊은 문제가 있습니다.
기본적으로 Create React App은 온전히 클라이언트 사이드 앱을 생성합니다. 즉, 생성된 모든 앱에는 빈 HTML 파일과 리액트 앱 번들과 함께 <script>태그가 포함되어 있습니다. 빈 HTML 파일이 로드되면 브라우저는 리액트 코드와 전체 앱 번들이 다운로드될 때까지 기다립니다. 낮은 대역폭 연결에서는 다소 시간이 걸릴 수 있으며, 이 작업이 진행되는 동안 사용자의 화면에는 아무것도 표시되지 않습니다. 그런 다음 앱 코드가 로드됩니다. 이때 브라우저는 모든 것을 실행해야 하며, 성능이 낮은 장치에서는 속도가 느려질 수 있습니다. 사용자는 마침내 화면에서 무언가를 보게 되지만 종종 일부 데이터를 더 로드해야 할 수도 있습니다. 즉, 코드에서 일부 데이터를 로드하라는 요청을 보내고 사용자는 데이터가 다시 오기를 기다립니다. 마지막으로 데이터가 로드되면 컴포넌트가 데이터와 함께 리렌더링 되며 사용자는 최종 결과를 보게 됩니다.
이는 매우 비효율적인 방법이지만 클라이언트에서만 리액트를 실행하는 경우 더 잘하기는 어렵습니다. 이를 레일즈와 같은 서버 프레임워크와 비교해보세요. 서버는 즉시 데이터 페칭을 시작한 다음 모든 데이터가 포함된 페이지를 생성합니다. 또는, 지킬과 같은 정적 빌드 타임 프레임워크를 사용해 빌드 중에 HTML+JS+CSS 번들을 생성해 정적 호스팅에 배포할 수 있습니다. 두 방법 모두 사용자는 스크립트가 로드되기를 기다리는 빈 파일 대신 모든 정보가 포함된 HTML 파일을 보게 됩니다. HTML은 웹의 근본입니다. 그러면 왜 “리액트 앱”을 만들면 빈 HTML이 생성될까요? 웹의 가장 기본적인 기능을 활용해 모든 대화형 코드가 로드되기 전에 콘텐츠를 빠르게 볼 수 있도록 하지 않은 이유는 뭘까요? 모든 클라이언트 사이드 코드가 로드를 완료할 때까지 데이터 로드 시작을 기다리는 이유는 뭘까요?
Create React App은 문제의 한 측면만 해결했습니다. 당시에는 좋은 개발 경험을 제공했지만, 좋은 사용자 경험을 위해 웹의 강력한 측면을 활용하는 데 도움이 되는 충분한 구조를 제공하지 않았습니다. 이런 문제를 스스로 해결하려고 시도할 수 있지만 “eject”한 뒤 설정을 상당히 수정해야 하므로 Create React App의 장점을 무효로 했습니다. 진정으로 효율적인 리액트 설정은 상황에 따라 다르며 Create React App에서는 이를 달성할 수 없었습니다.
이런 사용자 경험 문제는 Create React App에만 국한되지 않습니다. 또한, 리액트에만 국한되지도 않습니다. 예를 들어 Vite 홈페이지에 올라와 있는 Preact, Vue, Lit, Svelte 용 템플릿을 통해 생성된 앱 또한 동일한 문제를 겪고 있습니다. 이런 문제는 SSG(Static Site Generation) 또는 SSR(Server Side Rendering)이 없는 순수한 클라이언트 사이드 앱에 내재하여 있기 때문입니다.
Hack/XHP 렌더링에서 리액트로 재작성된 Facebook.com은 (결국 성능에 치명적이었기 때문에) SSR 없이는 출시될 수 없었지만, 위에서 설명한 문제는 페이스북과 같은 대형 앱에만 영향을 미치지 않았습니다. 오히려 정반대였죠! 리액트로 완전히 개발된 많은 앱을 보면 SSG 또는 SSR의 이점을 얻을 수 있는 많은 종류의 콘텐츠 지향 앱을 볼 수 있습니다. 포트폴리오, 블로그, 신문, 이커머스 샵처럼요. 이런 사이트에 빈 HTML 파일을 제공하는 것은 이치에 맞지 않습니다. 이런 이유로 우리는 항상 콘텐츠 지향 사이트에 SSG 지원 리액트 프레임워크를 사용하도록 제안했습니다.
리액트 프레임워크의 부상
일부 사람들은 리액트로 완전히 빌드하지 않는 것을 선호할 수 있으며 이는 유효한 옵션입니다. 예를 들어 지킬 또는 Astro 같은 다른 도구를 사용해 빌드하는 동안 서버에서는 HTML을 생성할 수 있습니다. 이런 방식은 빈 HTML 파일 문제를 해결하지만 두 가지 렌더링 기술(예: 페이지의 “외부” 부분에 대한 지킬 템플릿과 “내부” 부분에 대한 리액트 컴포넌트)을 혼합해야 합니다. 시간이 지남에 따라 추가하려는 상호 작용이 많을수록 이런 기술 분할이 두드러집니다.
이런 분할은 개발자 경험을 해칠 뿐만 아니라 사용자 경험에도 영향을 미칩니다. HTML 중심으로 리액트를 최대한 활용하지 않는 도구를 사용하면 모든 페이지 navigation은 전부 다시 로딩되며 클라이언트 측 상태는 모두 날아갑니다. 오늘날 많은 사용자는 90년대 스타일로 전체 페이지가 다시 로드되는 것이 아닌 원활한 인 앱 탐색(정확하고 접근할 수 있는 방식으로 수행된다고 가정)을 기대합니다. 마찬가지로 많은 개발자는 서로 다른 두 모델을 혼합하는 대신 단일 렌더링 모델을 사용해 앱을 빌드하는것을 선호합니다. 즉, 사람들은 리액트로 전체 앱을 구축하기를 원하고 우리는 그것을 가능하게 하고 싶습니다.
리액트로 전체 앱을 빌드하는 경우 SSG/SSR 지원 여부가 중요합니다. 하지만 Create React App은 이런 지원이 부족합니다. 하지만 이런 부분이 유일하게 Create React App이 뒤쳐진 영역은 아닙니다. 생태계에서 수년간 혁신한 끝에 많은 문제를 해결하는 리액트 솔루션을 갖게 되었습니다. 예를 들어 네트워크 워터폴와 번들 크기를 이야기해보겠습니다.
앱이 콘텐츠 지향 사이트만큼 SSG 또는 SSR의 이점을 얻지 못하더라도 네트워크 워터폴로 인해 어려움을 겪을 수 있습니다. “마운트 시” 페칭하는 경우 첫 번째 데이터 가져오기는 모든 코드가 로드되고 컴포넌트가 렌더링 될 때까지 시작하지 않습니다. 이는 워터폴 문제입니다. 코드가 아직 로드되는 동안 앱이 가져오기를 시작하는 방법을 “알고” 있다면 병렬로 수행할 수 있습니다. 페이지 전환 시 부모 컴포넌트와 자식 컴포넌트 모두 무언가를 페칭해야 한다면 더 나쁜 워터폴이 만들어집니다. 리액트 성능에 대해 이야기할 때 많은 앱에서 워터폴이 성능 병목을 불러일으킨다는 사실은 불가피합니다. 이런 워터폴을 해결하려면 Create React App이 수행하지 않는 라우팅과 데이터 페칭의 통합이 필요합니다.
번들 크기가 고정된 리액트와 달리 앱 코드는 모든 새로운 기능과 의존에 따라 계속 커집니다. 자주 배포하는 경우 사용자는 항상 모든 코드를 다시 로드해야 하므로 속도가 매우 느려질 수 있습니다. 이런 문제를 해결하는 몇 가지 방법이 있습니다. 모든 경우에 동작하는 것은 아닙니다. (도구에서 허용하는 경우) 서버에서 또는 빌드 중에 실행되도록 일부 코드를 이동할 수 있습니다. 이상적으로는 경로별로 코드를 분할할 수도 있습니다. 대시보드 페이지에서 차트를 렌더링해야 하는 경우 계정 청구 페이지에서 해당 차트의 전체 구현을 로드할 필요가 없습니다. 그러나 수동으로 코드를 분할하면 성능이 저하되는 경우가 많습니다. 예를 들어 차트를 느리게 로드하지만, 차트가 “마운트 시” 데이터를 로드하는 경우 또 다른 네트워크 워터폴이 만들어진 것입니다. 이 문제를 잘 해결하려면 Create React App이 수행하지 않는 라우팅 및 번들링과 데이터 페칭을 통합해야 합니다.
리액트는 라이브러리일 뿐입니다. 라우팅 또는 데이터 페칭을 수행하는 방법을 지시하지 않습니다. Create React App 또한 마찬가지입니다. 불행하게도 이는 원래 설계된 대로 리액트 또는 Create React App을 통해 이런 문제를 해결할 수 없음을 의미합니다. 보시다시피 이런 문제는 단순히 기능 하나의 누락을 이야기하지 않습니다. 서버 사이드 렌더링과 정적 생성, 데이터 페칭, 번들링과 라우팅과 같은 기능은 서로 연결되어 있습니다. Create React App이 나왔을 때 리액트는 매우 새로운 것이었고, 기능을 잘 결합하는 방법을 알아내는 것은 고사하고 개별적으로 작동하는 각 기능에 대해 파악해야 하는 것이 더 중요했습니다.
시대가 바뀌었습니다. 이제 이런 기능이 없는 솔루션을 권장하는 것이 점점 더 어려워지고 있습니다. 모든 항목이 바로 필요하지 않더라도 필요할 때 사용할 수 있도록 제공되어야 합니다. 다른 템플릿으로 마이그레이션 하고 이를 활용하기 위해 모든 코드를 재구성할 필요가 없어야합니다. 마찬가지로 데이터 페칭 또는 코드 분할이 경로 기반일 필요도 없습니다. 하지만 이런 내용은 대부분의 리액트 앱에서 사용할 법한 좋은 기본값입니다.
이 모든 부분을 직접 통합할 수는 있지만 잘하기는 어렵습니다. Create React App 자체가 컴파일과 관련된 몇 가지 문제를 통합했을 때와 마찬가지로 Next.js, Gatsby 및 Remix와 같은 도구는 더 나아가 렌더링, 라우팅 및 데이터 페칭과 통합 컴파일을 수행합니다. 컴파일, 렌더링, 라우팅 및 데이터 페칭을 통합하는 범주의 도구를 “프레임워크”라고 합니다. (리액트 자체를 프레임워크라고 부르는 것을 선호하는 경우 “메타 프레임워크”라고 부를 수도 있습니다.) 이런 프레임워크는 훨씬 더 나은 사용자 경험을 제공하기 위해 앱 구조화에 대한 몇 가지 의견을 제시합니다. 또한, 많은 개발자는 라우팅 및 데이터 페칭을 위한 확장 가능한 빌트인 솔루션을 권장하는 것이 인체 공학적(ergonomic)이라 생각합니다.
아키텍처로서의 리액트
우리는 리액트의 유연성을 좋아합니다. 리액트를 사용해 단일 버튼을 만드는 것부터 전체 앱을 만드는 데 사용할 수 있습니다. 이를 사용해 20년 된 Perl 웹 사이트 안에 내부 대시보드를 구축하거나 전체에 리액트를 사용해 하이브리드 SSG/SSR 이커머스 웹사이트를 만들 수 있습니다. 이런 유연성은 필수적이며 많은 사용자가 이를 좋아한다는 것을 알고 있습니다. 또한, 이는 사라지지 않을 것입니다.
그러나 리액트로 완전히 구축된 새 앱에 대해서는 저희도 가능한 최상의 기본 설정을 제공하고 싶습니다. 기본적으로 제안된 리액트 앱 생성 방법이 SSG 및 SSR, 자동 코드 분할, 클라이언트-서버 워터폴이 없으며, 경로 프리페칭, 클라이언트 UI 상태 보존을 지원하는 페이지 전환 및 기타 훌륭한 사용자 경험을 가능하게 하는 기능을 지원한다면 너무 좋을 것입니다. 하지만 동시에 리액트 아키텍쳐는 본질적으로 이 모든 기능을 가능하게 하기 위한 통합을 지원하지 않는 클라이언트 전용 아키텍쳐입니다. 적어도 리액트 앱을 생성하기 위해 제안된 기본 방법은 이런 기능에 제한되어서는 안됩니다.
이는 기회입니다. 프레임워크는 이런 문제를 뛰어난 성능과 인체 공학을 통합하는 것이 과제입니다. 그러나 여기에는 리액트의 도전도 있었습니다. 우리는 리액트 프레임워크가 훌륭한 사용자 경험을 제공할 수 있도록 도울 수 있는 가장 좋은 방법이 리액트 자체의 기본 본질에 집중하는 것임을 깨달았습니다. 리액트 자체가 할 수 있는 고유한 작업 중 렌더링 레이어에서 프레임워크가 다른 모든 레이어에서 작업을 강화하는 작업이 있습니다. 예를 들어 <Suspense>와 마찬가지로 단일 리액트 API는 배후에서 프레임워크에 대한 전체 범위의 최적화를 일으킬 수 있습니다.
이것이 우리가 리액트를 두 가지로 생각하는 것이 도움이 되는 이유입니다.
리액트는 라이브러리입니다. 이 라이브러리는 컴포넌트를 함께 정의하고 합성할 수 있는 몇 가지 API를 제공합니다. 또한, 리액트는 아키텍처입니다. 프레임워크 작성자가 렌더링 모델을 최대한 활용할 수 있도록 빌딩 블록을 제공합니다. 프레임워크 없이 리액트를 사용할 수 있습니다. 그러나, 프레임워크와 함께 사용할 때 프레임워크가 리액트 자체를 최대한 활용할 수 있는지를 확인하고 싶습니다. 지난 몇 년간 구축한 많은 기능(<Suspense>, useTransition, renderToPipeableStream과 같은 스트리밍 API 및 실험적으로 제공하고 있는 서버 컴포넌트)는 프레임워크 지향적입니다. 프레임워크는 번들링, 라우팅 및 데이터 페칭을 통합해 리액트를 최대한 활용할 수 있습니다.
이런 기능 중 일부는 Next 13, Gatsby 5 및 Remix 1.11에서 이미 채택된 것을 볼 수 있습니다. 하지만, 아직 할 일이 많고 이 작업 중 일부는 실험 단계를 졸업하는 과정에 있습니다.(하지만 문서는 여전히 부족합니다) 그런데도 우리는 다년간의 노력이 성과를 거두고 리액트 프레임워크 및 사용자가 기본적으로 더 빠른 앱을 제공할 수 있는 것을 보게 되어 기쁩니다.
이는 곧 다음 내용으로 연결됩니다.
하나의 라이브러리, 여러 개의 프레임워크
생태계에는 하나 이상의 리액트 프레임워크가 있습니다. 그리고 이런 점은 좋습니다.
이탈에 대한 우려에도 불구하고 리액트 생태계에는 많은 선수를 보유하는 것이 더 좋습니다. 생태계에는 경쟁하고 있는 여러 데이터 페칭 솔루션 및 라우팅 솔루션이 있습니다. 옵션은 매년 더 좋아지고 있습니다. 라우팅, 데이터 페칭, 렌더링 및 컴파일을 통합하는 여러 솔루션(예: 여러 리액트 프레임워크)가 있는 것은 놀라운 일이 아닙니다.
우리는 이대로 유지하고 싶습니다. 그러나, 리액트 생태계에 이점이 있고 가능한 경우 융합을 장려하고 싶습니다. 예를 들어, 서로 다른 프레임워크는 서로 다른 메커니즘을 사용하여 데이터를 로드할 수 있습니다. 하지만 모두 <Suspense>를 로딩 지표로 채택한다면 <Suspense>위에 있는 우리의 상위 레벨 기능은 모든 프레임워크에서 작동할 것입니다. 우리는 여전히 프레임워크용 API를 마무리하고 문서화하기 위해 노력하고 있지만, 그들이 리액트를 최대한 활용할 수 있도록 힘을 실어주고 싶습니다.
일부 프로젝트는 인기 있는 프레임워크의 틀에 절대 맞지 않겠지만 괜찮습니다. PHP 사이트와 통합해야 하는 내부 대시보드를 개발중일 수 있으며 어떤 프레임워크도 그런 작업을 쉽게 할 수 없습니다. 이는 Parcel 또는 온전한 클라이언트 사이드 Vite 템플릿 같은 하위 레벨 도구의 훌륭한 사용 사례입니다. 앱이 그림 편집기이고 라우팅이 없으며 SSG에서도 제외시키고 싶을 수 있습니다. 우리는 항상 지원했었으며, 앞으로도 지원할 것입니다. 리액트를 프레임워크 아키텍처가 아닌 라이브러리로 계속 사용하는 것은 유효합니다. 우리는 이것이 대부분의 새로운 웹앱에 대한 올바른 기본 값이 아니라고 주장할 뿐입니다.
대부분의 리액트 앱에서 프레임워크로 시작하는 것이 가장 좋은 방법이라면 어떤 프레임워크를 권장해야 할까요? 하나를 골라야 할까요? 어느 것을 선택할지 어떻게 결정하나요? 시간이 지나면서 정체된다면요? 더 민감한 인센티브에 대한 질문도 있습니다. 인기 있고 잘 관리되는 프레임워크에는 직간접적으로 이와 관련된 일종의 상업적 제품이 있는 경우가 많습니다. 이런 제안은 해당 프레임워크의 개발에 자금을 지원할 수 있습니다. 하지만, 예를 들어 특정 호스팅 플랫폼에서만 작동하는 제품으로 사람들을 밀어붙이는 것을 피하고 싶습니다.
이 내용은 이 스레드의 질문으로 이어집니다.
Create React App으로 무엇을 해야 할까요?
Create React App의 원래 목표는 다음과 같습니다.
- 구성없이 새 리액트 프로젝트를 시작하는 쉬운 방법을 제공합니다.
- 쉽게 업그레이드할 수 있도록 컴파일 관련 의존을 통합합니다.
- 리액트 팀의 도구 업데이트를 가능한 한 광범위하게 배포할 수 있도록 합니다. (예: Fast Refresh 지원, 훅 린트 규칙)
그러나 더 이상 리액트 앱을 만드는 가장 좋은 방법이라는 원래 목표를 충족시키지 못합니다. 기준을 높이고 컴파일을 렌더링, 라우팅 및 데이터 페칭과 통합함으로써 프레임워크는 사용자가 다음과 같은 리액트 앱을 만들 수 있도록 합니다.
- 웹 API를 최대한 활용해 작든 크든 기본으로 빠른 앱과 사이트를 제공합니다.
- 리액트 자체와 프레임워크 레벨 기능을 최대한 활용하도록 합니다.
- 개발자가 “성공의 구덩이(pit of success)”에 빠질 수 있도록 라우팅 및 데이터 페칭을 제공합니다.
리액트 생태계는 웹과 리액트 자체를 최대한 활용할 수 있는 기본 권장 접근 방식이 필요합니다. 이것은 반드시 Node.js 서버에 의존한다는 의미는 아닙니다. 널리 사용되는 많은 프레임워크는 서버가 필요하지 않고 SSG 모드에서 작동할 수 있으므로 “완전히 정적”인 사용 사례도 처리할 수 있습니다. 프레임워크의 장점은 나중에 SSR이 필요한 경우 마이그레이션 할 필요가 없다는 것입니다. Remix가 기본적으로 제공하는 mutation API처럼 다른 것과 마찬가지로 사용할 수 있습니다.
이 비전을 어떻게 달성할 수 있을까요? 몇 가지 옵션이 있습니다.
옵션 1. 처음부터 새 프레임워크 만들기
Create React App을 데이터 페칭, 라우팅, 번들링 및 SSG/SSR을 통합하는 프레임워크로 재설계할 수 있습니다. 하지만, 고품질의 새 프레임워크를 구축하는 것은 엄청난 작업이며 전문적인 생태계 전문 지식이 많이 필요합니다. 또한, 이를 해결하기 위해 다른 프로젝트를 중단하더라도 시간이 지남에 따라 다시 정체될 상당한 위험이 있어 우려스럽습니다. Create React App 자체가 그러했습니다. 실제 사용자가 없음에도 불구하고 공식적으로 권장되는 또 다른 프레임워크로 생태계를 더욱 세분화할 것입니다. 현재는 이 옵션이 실용적이지 않다고 생각합니다.
옵션 2. Create React App deprecate 화. Vite template 메인테이닝
Create React App을 더 이상 사용하지 않고 자체 Vite 템플릿을 메인테이닝 할 수 있습니다. 명시된 목표를 달성하려면 이 템플릿은 매우 정교해야 합니다. 리액트 프레임워크만큼 정교해야 하고 라우팅, 데이터 페칭 등에 대한 의견을 제시해야 합니다. 이는 동일한 문제로 이어집니다. 사실상 다른 프레임워크를 만드는 것입니다.
옵션 3. Create React App 사용 중단. 리액트 프레임워크 제안
Create React App을 도구로 덜 강조하거나 deprecate화 시켜 리액트 프레임워크를 더 사용하도록 강조할 수 있습니다. 이는 리액트와 함께 프레임워크를 사용해야 한다는 의미를 전하는 것이 아니라, 우리는 대부분의 앱에 리액트 프레임워크 중 하나를 사용하는 것을 제안한다는 것입니다. 단점은 리액트 앱을 만들기 위한 중립 브랜드 CLI “게이트웨이”가 더 이상 없다는 것입니다. 해당 프레임워크의 문서에서 올바른 정보를 찾아야 합니다. 노골적인 deprecate화도 파괴적입니다. 오랫동안 명령이 작동하도록 유지해야 하기 때문에 브랜딩 관점에서도 혼란스럽습니다.(Create React App이라는 이름 때문에 “리액트 앱을 만드는 것이 더 이상 사용되지 않는 이유가 뭔가요?”라는 질문이 유발되는 것처럼요)
옵션 4. Create React App이 단일 프레임워크를 사용하도록 만들기
지정된 단일 프레임워크를 선택하고 Create React App을 변경해 기본적으로 해당 프레임워크를 사용하도록 할 수 있습니다. 이 접근방식의 주요 문제는 다른 솔루션이 경쟁하기 매우 어렵게 만든다는 점입니다. 특히 서로 절충점은 약간 다르지만 대중성, 기능 집합 및 품질 면에서 거의 동일한 경우에는 더욱 그렇습니다. 이런 동작의 변경은 이전에 작성된 모든 튜토리얼이 명확하지 않은 방식으로 중단되기 때문에 상당히 파괴적입니다.
옵션 5. Create React App을 런처로 전환
Create React App을 명령으로 유지할 수 있지만, 런처로도 전환할 수 있습니다. 권장 프레임워크 목록을 제시하고 프레임워크가 없는 “전통적인” 접근 방식이 마지막 옵션이 됩니다. 마지막 “전통적인” 접근 방식은 CRA와 같은 클라이언트 전용 앱을 생성하지만(튜토리얼 중단을 방지하기 위해) 결국 내부적으로는 Vite로 이동할 수 있습니다.
선별된 프레임워크 목록에 오르려면 리액트 프레임워크가 특정 기준을 충족해야 합니다. 이 문서에서 발생한 것과 사실상 유사합니다. 우리는 커뮤니티에서의 인기와 채택(목록을 짧게 유지하기 위해), 기능 집합, 성능 특징, 웹 플랫폼과 리액트 자체를 최대한 활용할 수 있는 능력, 적극적으로 유지 관리 되는지 여부 및 명확한 기준을 고려해야 합니다. (공급 업체 종속을 방지하기 위해) 다양한 호스팅 서비스 및 환경에서 호스팅할 수 있어야 합니다 각 프레임워크의 스타터 템플릿은 일관된 디자인과 브랜딩을 유지하고 상용 서비스에 연결하지 않으며 유사한 구조를 갖도록 리액트 팀에서 유지 관리 합니다. 우리는 우리가 선택한 방법에 대해 커뮤니티와 명확하게 소통해야 하며 주기적으로 이를 재평가할 것입니다.
우리의 제안
우리는 현재 옵션 5(“Create React App을 런처로 전환”) 쪽으로 기울고 있습니다. Create React App의 원래 목표는 대부분의 리액트 사용자에게 새로운 리액트 웹 앱을 시작하는 가장 좋은 방법을 제공하는 것이었습니다. 우리는 이를 런처로 용도 변경하는 것이 대부분의 새로운 웹 앱에 가장 적합하다고 생각하며 변화를 명시적으로 전달한다고 생각합니다. 동시에 이전 작업 워크플로우를 위한 탈출구를 남겨둡니다. 옵션 3과 달리 “리액트 앱 만들기”가 더 이상 사용되지 않는다는 인식 또한 피할 수 있습니다. 약간의 선택이 필요하다는 현실을 인정하지만, 이제 선택할 수 있는 훌륭한 옵션을 제공합니다.
여기서 이야기 나눈 점을 구체화하는 더 자세한 RFC 제안을 작업할 것입니다. 그동안 이런 사항에 대한 당신의 의견을 듣고 싶습니다. 이 글이 긴 설명이라는 것을 알고 있지만 전체 사고 과정을 보여주고 싶었고 이 기회를 사용해 리액트와 프레임워크 간의 관계를 명확히 하고 싶었습니다. 여기에서 후속 질문에 답변하기 위해 최선을 다하겠습니다.
읽어주셔서 고맙습니다!
🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article(https://kofearticle.substack.com/)을 구독해주세요.
