create-react-app 은 더이상 권장되지 않는 방식인가?

권장사항에서 빠진 create-react-app와 최근의 프론트엔드 개발 트렌트

 

제 블로그에 관심이 많으신 분들은 이미 알고 계시겠지만, 사실 전 React보단 React-Native 개발자에 가깝습니다.(아, 웹 하고 싶다!) 그래서 한동안 React 웹서비스를 처음부터 만들 일이 많지 않았죠. 조그마한 토이프로젝트로 React에 대한 열정을 되살리고자 npx create-react-app 을 사용했습니다.

 

The Library

그러던 중 꽤나 충격적인 사실을 알게 되었습니다. 바로 React 공식문서에서 더 이상 create-react-app을 권하고 있지 않다는 사실을 말이죠.

 

React에 관심있으신 분들은 아시겠지만 최근 React 공식 웹사이트가 새로 오픈했습니다.

React

여기서 Start a New React Project 라는 메뉴에 들어가면 React 프로젝트를 처음 만드는 공식적인 방법이 나옵니다.

 

프로덕트 수준의 React 프레임워크를 쓰자.
  1. Next.js
  2. Remix
  3. Gatsby
  4. Expo(for native apps)

끝입니다.

이와중에 App 개발에서도 React-native가 아닌 expo를 추천하고 있는 게 함정🤣

 

여기서 충격적인건 create-react-app의 사용이 나오지 않는다는 것이죠.  검색 등 아무리 사이트를 뒤져도 create-react-app은 눈을 씻고 찾아도 나오지 않습니다. 이것은 입문자에게 맨 첫 꼭지로 Create React App을 추천했던 과거 공식문서와 비교하면 명확합니다.

create-react-app을 가장 먼저 추천하던 과거의 공식문서

 

왜 그런걸까요? 공식문서의 해당 내용 바로 아래에 Deep Dive라는 꼭지에서 힌트를 찾을 수 있었습니다. (영어 원문보기)

 

DEEP DIVE
프레임워크 없이 React를 사용할 순 없나요?

프레임워크 없이도 React를 사용할 수 있습니다. 페이지의 일부에 React를 사용하는 방식입니다. 그러나 React로 완전히 새로운 앱이나 사이트를 구축하는 경우 프레임워크를 사용하는 것이 좋습니다. 이유는 다음과 같습니다. 처음에는 라우팅이나 데이터 가져오기가 필요하지 않더라도 일부 라이브러리를 추가하고 싶을 것입니다. JavaScript 번들이 모든 새로운 기능과 함께 커짐에 따라 모든 경로에 대한 코드를 개별적으로 분할하는 방법을 파악해야 할 수 있습니다. 데이터 fetch가 더 복잡해지면 앱이 매우 느리게 느껴지도록 만드는 서버-클라이언트 네트워크 워터폴이 발생할 수 있습니다. 사용자들의 네트워크 상태가 좋지 않고 저가형 장치를 사용하는 사용자가 더 많기 때문에 서버에서 또는 빌드 시간 중에 콘텐츠를 일찍 표시하려면 구성 요소에서 HTML을 생성해야 할 수 있습니다. 서버 또는 빌드 중에 일부 코드를 실행하도록 설정을 변경하는 것은 매우 까다로울 수 있습니다.

이러한 문제는 React에만 국한되지 않습니다. 이것이 Svelte에 SvelteKit이 있고 Vue에 Nuxt가 있는 이유입니다. 이러한 문제를 직접 해결하려면 번들러를 라우터 및 데이터 가져오기 라이브러리와 통합해야 합니다. 초기 설정을 작동시키는 것은 어렵지 않지만 시간이 지남에 따라 앱이 커져도 빠르게 로드되는 앱을 만드는 데는 많은 미묘함이 있습니다. 최소한의 앱 코드를 전송하고 싶지만 페이지에 필요한 모든 데이터와 병렬로 단일 클라이언트-서버 왕복으로 전송해야 합니다. 점진적 향상을 지원하기 위해 JavaScript 코드가 실행되기 전에 페이지가 상호 작용하기를 원할 것입니다. 어디에서나 호스팅 할 수 있고 JavaScript가 비활성화된 상태에서도 계속 작동할 수 있는 마케팅 페이지에 대한 완전히 정적 HTML 파일의 폴더를 생성할 수 있습니다. 이러한 기능을 직접 구축하려면 실질적인 작업이 필요합니다.

위 React 프레임워크들은 추가 작업 없이 기본적으로 이와 같은 문제를 해결합니다. 이를 통해 매우 간결하게 시작한 다음 필요에 따라 앱을 확장할 수 있습니다. 각 React 프레임워크에는 커뮤니티가 있으므로 질문에 대한 답변을 찾고 툴을 업그레이드하는 것이 더 쉽습니다. 또한 프레임워크는 코드에 구조를 부여하여 당신과 다른 사람들이 서로 다른 프로젝트 간에 컨텍스트와 기술을 유지하도록 돕습니다. 만약 이런 프레임워크를 사용하지 않고 커스텀 셋업을 사용한다면 미지원 종속성에 걸리기 쉬워지며, 결국 업그레이드를 할 수 없고 커뮤니티의 지원도 받을 수 없는 "나만의 프레임워크"를 마주하게 될 것입니다.(그리고 이런 것들은 과거의 유사품들과 비슷하게 더욱 범용적으로 사용할 수 없게 될 것입니다)

여전히 확신이 서지 않거나 앱에 이러한 프레임워크에서 제대로 제공되지 않는 비정상적인 제약이 있고 고유한 사용자 지정 설정을 롤링하고 싶다면 우리는 당신을 막을 수 없습니다. npm에서 react 및 react-dom을 가져오고, Vite 또는 Parcel과 같은 번들러로 사용자 정의 빌드 프로세스를 설정하고, 라우팅, 정적 생성 또는 서버 측 렌더링 등에 필요한 다른 도구를 추가하십시오.

(의역이 섞여있습니다. 자세한 내용은 원문을 확인해주세요.)

 

3줄 요약하면

1. 요즘은 Server Side Rendering이 대세인데, SSR 어려우니 그냥 프레임워크를 따라라.

2. SSR을 위한 여러 문제들과 커뮤니티, 코드의 일관성을 프레임워크가 보장해 주는데, 만약 네 스스로 구축한다면 그런 장점은 다 사라지고, "나만의 프레임워크"가 될 것이다.

3. 그래도 네 스스로 구축하고 싶다면 말리진 않을게

 

아주 쉽게 말하면 스스로 할 생각 말고 그냥 프레임워크 써서 만드는 것을 추천하는 것입니다.

 

사실 create-react-app도 생각해 보면 방향성 없이 커스텀하고 자유분방하게 만들 React에 대해 일종의 가이드라인을 제시하여 초기 셋업을 해주는 역할이었을 텐데, 요즘은 이것 조차도 불필요한 과정으로 이해되는 모양입니다.

 

애초부터 프레임워크였던 Angular나 Vue.js에 비해, 라이브러리임을 강조했던 React는 점점 프레임워크로의 사용을 권하는 것을 보면 개발에 요즘의 트렌드를 보여주는 것 같습니다. (심지어는 Native App에서조차 자기네 라이브러리가 아닌 Expo 프레임워크 사용을 권하고 있죠ㅎㅎ.. 우리 팀 어떻게 하지...👀)

개발자의 자율성보다는 프레임워크의 규칙과 엄밀함을 권하는 것이 최근의 트렌드같습니다. 저도 수혜를 입고 있는 TypeScript의 유행과도 맥이 닿아 보입니다.(TypeScript 잘 쓰고 있습니다. 감사합니다.)

 

토이 프로젝트는 Next.js를 사용해봐야 하나 고민이 되네요. 이참에 Next.js를 공부해 보는 것도 좋을 것 같습니다.

---

번역 및 내용에 대해 이견이 있으시거나 의견이 있으신 분은 댓글을 남겨주세요. 틀린 부분은 수정하겠습니다.

도움이 되셨다면 좋아요 공감❤️과 우측 상단의 구독 부탁드립니다.