v19.2Latest

React 앱을 처음부터 만들기

기존 프레임워크가 잘 지원하지 않는 제약 조건이 있는 앱을 개발하거나, 자신만의 프레임워크를 구축하는 것을 선호하거나, React 앱의 기본을 배우고 싶다면, React 앱을 처음부터 구축할 수 있습니다.

Deep Dive
프레임워크 사용 고려하기

1단계: 빌드 도구 설치하기

첫 번째 단계는 vite,parcel또는rsbuild와 같은 빌드 도구를 설치하는 것입니다. 이러한 빌드 도구들은 소스 코드를 패키징하고 실행하는 기능, 로컬 개발을 위한 개발 서버, 앱을 프로덕션 서버에 배포하기 위한 빌드 명령을 제공합니다.

Vite

Vite는 현대 웹 프로젝트를 위한 더 빠르고 간결한 개발 경험을 제공하는 것을 목표로 하는 빌드 도구입니다.

npm create vite@latest my-app -- --template react-ts

Vite는 의견이 명확하며, 기본적으로 합리적인 기본값을 제공합니다. Vite는 빠른 새로고침, JSX, Babel/SWC 및 기타 일반적인 기능을 지원하는 풍부한 플러그인 생태계를 가지고 있습니다. 시작하려면 Vite의React 플러그인또는React SWC 플러그인 및 React SSR 예제 프로젝트를 참조하세요.

Vite는 이미 권장 프레임워크중 하나인React Router에서 빌드 도구로 사용되고 있습니다.

Parcel

Parcel는 훌륭한 기본 제공 개발 경험과 확장 가능한 아키텍처를 결합하여 프로젝트를 시작 단계에서 대규모 프로덕션 애플리케이션까지 이끌어 갈 수 있습니다.

npm install --save-dev parcel

Parcel은 패스트 리프레시, JSX, TypeScript, Flow 및 스타일링을 기본적으로 지원합니다. 시작하려면Parcel의 React 레시피를 참조하세요.

Rsbuild

Rsbuild는 Rspack 기반 빌드 도구로, React 애플리케이션을 위한 원활한 개발 경험을 제공합니다. 신중하게 조정된 기본값과 성능 최적화가 준비되어 있습니다.

npx create-rsbuild --template react

Rsbuild는 패스트 리프레시, JSX, TypeScript, 스타일링과 같은 React 기능에 대한 내장 지원을 포함합니다. 시작하려면Rsbuild의 React 가이드를 참조하세요.

참고

React Native용 Metro

React Native로 처음 시작하는 경우 React Native용 JavaScript 번들러인Metro를 사용해야 합니다. Metro는 iOS 및 Android와 같은 플랫폼에 대한 번들링을 지원하지만, 여기에 나열된 도구들과 비교했을 때 많은 기능이 부족합니다. 프로젝트에 React Native 지원이 필요한 경우가 아니라면 Vite, Parcel 또는 Rsbuild로 시작하는 것을 권장합니다.

2단계: 일반적인 애플리케이션 패턴 구축

위에 나열된 빌드 도구들은 클라이언트 전용 싱글 페이지 애플리케이션(SPA)으로 시작하지만, 라우팅, 데이터 가져오기 또는 스타일링과 같은 일반적인 기능에 대한 추가 솔루션은 포함하지 않습니다.

React 생태계에는 이러한 문제를 해결하기 위한 많은 도구들이 포함되어 있습니다. 시작점으로 널리 사용되는 몇 가지를 나열했지만, 다른 도구가 더 잘 맞는다면 자유롭게 선택하세요.

라우팅

라우팅은 사용자가 특정 URL을 방문할 때 표시할 콘텐츠나 페이지를 결정합니다. URL을 앱의 다른 부분에 매핑하기 위해 라우터를 설정해야 합니다. 또한 중첩된 라우트, 라우트 매개변수 및 쿼리 매개변수를 처리해야 합니다. 라우터는 코드 내에서 구성하거나, 컴포넌트 폴더 및 파일 구조를 기반으로 정의할 수 있습니다.

라우터는 현대 애플리케이션의 핵심 부분이며, 일반적으로 데이터 가져오기(더 빠른 로딩을 위해 전체 페이지의 데이터를 미리 가져오는 것 포함), 코드 분할(클라이언트 번들 크기를 최소화하기 위해), 페이지 렌더링 방식(각 페이지가 어떻게 생성되는지 결정)과 통합됩니다.

다음 도구 사용을 권장합니다:

데이터 페칭

서버나 다른 데이터 소스로부터 데이터를 가져오는 것은 대부분의 애플리케이션에서 핵심적인 부분입니다. 이를 올바르게 수행하려면 로딩 상태, 오류 상태 처리 및 페칭된 데이터 캐싱이 필요하며, 이는 복잡할 수 있습니다.

목적에 맞게 구축된 데이터 페칭 라이브러리는 데이터를 가져오고 캐싱하는 어려운 작업을 대신 처리하여, 앱이 필요로 하는 데이터와 이를 표시하는 방법에 집중할 수 있게 해줍니다. 이러한 라이브러리는 일반적으로 컴포넌트 내에서 직접 사용되지만, 더 빠른 사전 페칭과 더 나은 성능을 위해 라우팅 로더에 통합되거나 서버 렌더링에서도 사용될 수 있습니다.

컴포넌트에서 직접 데이터를 페칭하면 네트워크 요청 폭포 현상으로 인해 로딩 시간이 느려질 수 있으므로, 가능한 한 라우터 로더나 서버에서 데이터를 사전에 페칭하는 것을 권장합니다! 이렇게 하면 페이지가 표시되는 동안 페이지의 데이터를 한 번에 모두 가져올 수 있습니다.

대부분의 백엔드나 REST 스타일 API에서 데이터를 가져오는 경우 다음을 사용하는 것을 제안합니다:

GraphQL API에서 데이터를 가져오는 경우 다음을 사용하는 것을 제안합니다:

코드 분할

코드 분할은 앱을 필요할 때 로드할 수 있는 더 작은 번들로 나누는 과정입니다. 앱의 코드 크기는 새로운 기능과 추가적인 의존성이 생길 때마다 증가합니다. 전체 앱의 모든 코드가 사용되기 전에 전송되어야 하기 때문에 앱의 로딩 속도가 느려질 수 있습니다. 캐싱, 기능/의존성 축소, 일부 코드를 서버에서 실행하도록 옮기는 것은 느린 로딩을 완화하는 데 도움이 될 수 있지만, 과도하게 사용하면 기능을 희생할 수 있는 불완전한 해결책입니다.

마찬가지로, 프레임워크를 사용하는 앱이 코드를 분할하는 데 의존하는 경우, 코드 분할이 전혀 이루어지지 않는 경우보다 로딩이 더 느려지는 상황을 마주할 수 있습니다. 예를 들어,지연 로딩으로 차트를 로드하면 차트를 렌더링하는 데 필요한 코드 전송이 지연되어 차트 코드가 앱의 나머지 부분과 분리됩니다.Parcel은 React.lazy를 통한 코드 분할을 지원합니다. 그러나 차트가 초기 렌더링후에데이터를 로드한다면 이제 두 번 기다려야 합니다. 이것은 폭포 현상입니다: 차트의 데이터를 가져오고 이를 렌더링하는 코드를 동시에 전송하는 대신, 각 단계가 차례로 완료되기를 기다려야 합니다.

라우트별로 코드를 분할하면 번들링 및 데이터 페칭과 통합될 때 앱의 초기 로드 시간과 앱의 가장 큰 가시적 콘텐츠가 렌더링되는 데 걸리는 시간(Largest Contentful Paint)을 줄일 수 있습니다.

코드 분할에 대한 지침은 빌드 도구 문서를 참조하세요:

애플리케이션 성능 향상

선택한 빌드 도구가 단일 페이지 애플리케이션(SPA)만 지원하므로 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG) 및/또는 React 서버 컴포넌트(RSC)와 같은 다른렌더링 패턴을 구현해야 합니다. 처음에는 이러한 기능이 필요하지 않더라도, 나중에 SSR, SSG 또는 RSC의 이점을 얻을 수 있는 일부 라우트가 있을 수 있습니다.

  • 싱글 페이지 애플리케이션(SPA)는 단일 HTML 페이지를 로드하고 사용자가 앱과 상호작용할 때 페이지를 동적으로 업데이트합니다. SPA는 시작하기 쉽지만 초기 로딩 시간이 더 느릴 수 있습니다. SPA는 대부분의 빌드 도구의 기본 아키텍처입니다.
  • 스트리밍 서버 사이드 렌더링(SSR)은 서버에서 페이지를 렌더링하고 완전히 렌더링된 페이지를 클라이언트로 전송합니다. SSR은 성능을 향상시킬 수 있지만 싱글 페이지 애플리케이션보다 설정 및 유지 관리가 더 복잡할 수 있습니다. 스트리밍이 추가되면 SSR의 설정 및 유지 관리가 매우 복잡해질 수 있습니다.Vite의 SSR 가이드를 참조하세요.
  • 정적 사이트 생성(SSG)는 빌드 시점에 앱의 정적 HTML 파일을 생성합니다. SSG는 성능을 향상시킬 수 있지만 서버 사이드 렌더링보다 설정 및 유지 관리가 더 복잡할 수 있습니다.Vite의 SSG 가이드를 참조하세요.
  • React 서버 컴포넌트(RSC)는 빌드 타임, 서버 전용, 상호작용 컴포넌트를 단일 React 트리에서 혼합할 수 있게 합니다. RSC는 성능을 향상시킬 수 있지만 현재 설정 및 유지 관리에 깊은 전문 지식이 필요합니다.Parcel의 RSC 예제를 참조하세요.

렌더링 전략은 라우터와 통합되어야 하므로 프레임워크로 구축된 앱이 경로별로 렌더링 전략을 선택할 수 있습니다. 이렇게 하면 전체 앱을 다시 작성하지 않고도 다양한 렌더링 전략을 사용할 수 있습니다. 예를 들어, 앱의 랜딩 페이지는 정적 생성(SSG)을 사용하는 것이 유리할 수 있는 반면, 콘텐츠 피드가 있는 페이지는 서버 사이드 렌더링을 사용할 때 가장 좋은 성능을 발휘할 수 있습니다.

적절한 경로에 적절한 렌더링 전략을 사용하면 콘텐츠의 첫 번째 바이트가 로드되는 시간(첫 번째 바이트까지의 시간), 첫 번째 콘텐츠가 렌더링되는 시간(첫 번째 콘텐츠풀 페인트), 그리고 앱에서 가장 큰 가시적 콘텐츠가 렌더링되는 시간(가장 큰 콘텐츠풀 페인트)을 단축할 수 있습니다.

그 외에도…

이는 새로운 앱을 처음부터 구축할 때 고려해야 할 기능의 몇 가지 예시일 뿐입니다. 마주하게 될 많은 제약 사항들은 각 문제가 서로 연결되어 있고 익숙하지 않은 문제 영역에 대한 깊은 전문 지식을 필요로 할 수 있기 때문에 해결하기 어려울 수 있습니다.

이러한 문제를 직접 해결하고 싶지 않다면, 이러한 기능을 기본 제공하는 프레임워크로시작할 수 있습니다.

上一篇React 앱 만들기下一篇기존 프로젝트에 React 추가하기