React 프로젝트 설정 및 확장성 이야기

React는 여러 방법으로 생성하고 프로젝트를 설정한다.

( ex : CRA, Next, gastby etc ) 

이에 대한 여러 글들은 많지만, 내가 프로젝트를 초기 단계부터 시작한다면 어떻게 시작하면 좋을지는 정리되어서는 나오지는 않았던 것 같다. 그래서 여러 자료들을 읽으면서 공부를 했고 어느정도 윤곽이 보여 글을 써보고 싶었다. 

만약에 React 프로젝트 새로 생성하는데 어떤 프레임워크로 시작할지, 설정을 어떻게 할지 고민 되는 사람들한테 도움이 될 것이다. 

React의 한계

먼저 이야기에 앞서 프로젝트를 생성할 때 어떤 이슈를 때문에 생성하고 설정하는데 고민이 필요한지 알아보겠다.

리액트는 UI라는 영역만 담당하기 때문에 여러 라이브러리 설치가 필수적으로 이에 대한 구성이 매우 중요하다.

• SSR(Server Side Rendering) / SSG(Static Site Generation)
• Type Checker
• Routing
• State management
• Styling
• Bundling
• Lazy loading
• Code splitting
• Static file serve
• Scroll restoration

이러한 다양한 기능들을 위한 라이브러리가 있는 만큼 Webpack 과 babel 등 프로젝트 관리가 쉽지 않기 때문에 개발자 들은 리액트 빌드 툴체인을 신경 쓰기 보다는 규격화 되어 있는 프레임워크를 쓰는 방향으로 가고 있다.

예로) 네이버의 쇼핑 검색 서비스의 경우 처음에는 CRA(Create React App)을 eject하여 라이브러리를 적용하여 SSR이나 Code Splitting 같은 기능을 직접 구축하여 사용하다가 유지보수 측면과 여러가지 이슈로 인해 기존 프로젝트를 Next.js로 마이그레이션 작업을 진행하였다고 한다.

1. CRA ( Create React App)

참고 사이트 :  https://create-react-app.dev/docs/getting-started/

Getting Started | Create React App

Create React App은 공식적으로 지원되는 단일 페이지 React 애플리케이션을 만드는 방법이다.

webpack이나 Babel과 같은 도구를 설치하거나 구성할 필요가 없고 또한, 코드에 집중할 수 있도록 미리 구성되어 숨겨져 있다. 이러한 것은 개발 초기에는 정말 간편히 생성되므로 편하게 느껴질 것이다.

하지만, 어플리케이션이 복잡해지고 고도화 되는 경우, 혹은 SSR 을 직접 구현해야 하는 경우 결국엔 이 설정파일을 까서 커스텀 해야하는 일이 생길때, 문제는 발생하게 되어있다.

CRA로 프로젝트를 생성했다면, 결국 이러한 상황에서 eject를 해야한다. 하지만 문제는 eject 이전엔 모든 의존성을 내가 알지 못한다는 점과 숨겨져있는 수많은 디펜던시들이 드러나게 되고 build 파일을 만드는데 필요한 의존성이 대다수 포함되어 있어 결국은 내가 프로젝트의 버전을 올리거나 어떤 작업을 할 때 문제가 생긴다면, 결국은 eject 를 해서 현재의 의존성을 알아야 한다. 이는 매우 비생산적이고 누구나 하기 싫은 일이다.

CRA로 프로젝트를 시작했을 때, eject 여부의 케이스와 craco를 소개하겠다.

CRA without eject

• CRA에서 eject를 하지 않고 사용하는 방법
• 가장 기본적인 프로젝트 생성 방법

장점

• webpack 설정을 신경쓰지 않을 수 있다.
• 신경써야 할 코드가 적다

단점

• react-scripts로 설정 flow 이해가 힘듬
• 라이브러리 사용을 위한 코어 부분을 수정시 결국 eject을 할 수 밖에 없음

CRA with eject

• CRA에서 eject를 해서 사용하는 방법
• 종속 된 많은 설정들을 보고 수정해나간다.
• eject시, 밑에 이미지 처럼 config와 scripts폴더가 생기고 package.json파일이 모든 dependency와 babel, jest 설정 코드가 드러난다.

  

장점

• webpack을 커스터마이징하여 설정할 수 있음

단점

• 건드릴 필요 없는 불필요한 코드 증가로 인한 복잡성 증가
• JavaScript로 짜여진 CRA의 모든 config 파일들(Webpack, Babel ...)을 직접 유지보수해야 함
• One Build Dependency의 장점을 잃게 됨, 작업 도중 하나의 패키지가 필요해서 설치한다거나, 삭제할 때, 항상 다른 패키지들과의 의존성을 신경써야 함

Craco

Create React App Configuration Override 는 CRA를 쉽게 설정하기 위해 만들어진 라이브러리

CRA에서 eject를 하지 않아도 root 폴더에 craco.config.js를 추가해서 eslint, babel, postcss 등을 쉽게 설정가능

@craco/craco

밑에 공식 레퍼런스에 여러 설정에 대한 내용(내 경우에는 alias를 자주 쓴다)이 있으므로 찾아서 할 수 있다.

@craco/craco

2. Next.js

Next는 React 기반의 프레임워크로 다양한 기능을 지원하여 많은 개발자 그리고 회사들이 사용하고 있다.

• 데이터 프리패칭 지원 - SSG(Static Site Generation), SSR(ServerSide Rendering) 사용가능 (CSR도 사용가능)
• 개발 모드를 위한 서버 뿐만 아니라, 프로덕션 서버(BFF)도 제공 및 다양한 서버 라이브러리(Express, Koa)로 수정 가능
• SSR 지원 및 Google Chrome 팀과 협업으로 SEO 및 로드 성능이 높음
• 코드베이스가 TypeScript이고, 자체적으로 TypeScript 지원
• 특별한 설정을 하지 않아도 지원해주는 개발 편의기능 (페이지에 사용되는 코드만 로드하는 code-splitting를 통한 번들 최적화, 파일 기반 라우팅, Webpack, Babel을 이용한 자동 컴필레이션 및 번들링, React Fast Refresh, SSG, SSR, static 파일 서빙시 ./public를 /에 매핑해줌)

next가 프로젝트 설정이 편한 이유

1. next.config.js  

  추가적으로세부설정을수정하고싶다면,next.config.js로간단하게수정가능 하면서 특징에 맞게 플랫폼 관리 시간이 적게 들고 컴포넌트 개발을 통한 서비스 개발에 집중할 수 있게 해준다.

  2. Webpack5 지원

  Webpack5는 이전 버전 호환성을 지니며 Webpack 4와 아무 비용없이 마이그레이션이 가능하다. 뿐만 아니라 향상된 tree-shaking과 지속 캐싱, Deterministic chunk and module ids을 제공한다.

 

---

결론

소개한 방법들 말고도 다양한 framework를 이용하여 react 프로젝트를 구성한다. 자기 프로젝트 성격 그리고 확장성을 잘 생각하여 프로젝트를 구성하는 것이 미래의 자신을 위한 일이다. 이 내용을 다루면서 webpack, babel에 대한 깊은 이해 그리고 package 관리에 대해서 공부를 해야겠다고 생각이 들어 공부하고 관련한 내용을 다룰 것이다.