Next.js vs CRA: 설정부터 생산성까지 핵심 비교 가이드

React 개발을 시작하려는 순간, 우리는 중요한 선택지 앞에 서게 됩니다. 바로 Next.js와 CRA(Create React App) 중 무엇을 사용할 것인가입니다. 두 도구 모두 React 기반의 웹 애플리케이션을 만들기 위한 훌륭한 출발점이지만, 목적과 방향성에서 뚜렷한 차이를 지니고 있습니다.

📑 목차

• 서론: 같은 React, 다른 시작
• 1. Next.js와 CRA는 무엇인가?
  • 1.1 CRA(Create React App)의 정체
  • 1.2 Next.js의 철학과 등장 배경
• 2. 초기 설정 비교: 단순함 vs 유연함
  • 2.1 CRA의 설정 방식과 자동화
  • 2.2 Next.js의 기본 구성과 커스터마이징
• 3. 개발 생산성 비교: 효율적인 개발 경험은?
  • 3.1 라우팅 방식의 차이
  • 3.2 폴더 구조와 코드 관리
  • 3.3 타입스크립트 및 ESLint, Prettier 통합
• 4. 확장성과 기능 비교: SSR, SSG, API까지
  • 4.1 SSR(Server-Side Rendering)의 지원
  • 4.2 정적 사이트 생성(SSG)
  • 4.3 API Routes로 백엔드 통합
• 5. 어떤 프로젝트에 어떤 도구를 선택해야 할까?
  • 5.1 CRA가 유리한 프로젝트
  • 5.2 Next.js가 빛을 발하는 경우
  • 5.3 팀 규모와 기술 성숙도에 따른 선택 가이드
• 결론: 당신의 React 프로젝트, 어디서 시작할 것인가

서론: 같은 React, 다른 시작

React는 전 세계적으로 가장 인기 있는 프론트엔드 라이브러리 중 하나입니다. 하지만 React 자체는 사용자 인터페이스 구축에 집중된 라이브러리이기 때문에, 실제로 프로젝트를 시작하기 위해서는 이를 감싸는 ‘환경’이 필요합니다. 이때 주로 선택되는 두 가지 접근 방식이 바로 Create React App(CRA)과 Next.js입니다.

이 둘은 모두 React를 중심으로 한 개발을 지향하지만, 철학과 구조, 그리고 기능적인 범위에서 뚜렷한 차이를 보입니다. CRA는 빠르게 프론트엔드 개발을 시작할 수 있도록 미리 구성된 환경을 제공하고, Next.js는 페이지 기반의 라우팅, 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), API 핸들링까지 가능한 풀스택 프레임워크로 진화해왔습니다.

결과적으로, 프로젝트의 목표와 규모, 개발팀의 경험 수준에 따라 적합한 선택지가 달라질 수밖에 없습니다. 본 포스팅에서는 이 두 가지 도구를 비교하며 각각의 장단점을 세세하게 살펴보고, 어떤 상황에서 어떤 선택이 적합한지에 대해 구체적인 가이드를 제공합니다.

React로 무언가를 시작하고자 하는 순간, ‘무엇으로 시작할 것인가’는 단순한 기술 선택을 넘어 전체 프로젝트의 방향을 결정짓는 중요한 질문이 됩니다. 이 글을 통해 여러분의 선택이 더욱 명확해지기를 바랍니다.

1. Next.js와 CRA는 무엇인가?

React 기반의 프로젝트를 시작하려 할 때, 가장 먼저 맞닥뜨리게 되는 선택지는 환경 설정 도구입니다. 그중에서도 가장 널리 사용되는 두 가지가 Create React App(CRA)과 Next.js입니다. 이 두 도구는 모두 React를 기반으로 하지만, 프로젝트를 구성하는 철학과 제공하는 기능 면에서 분명한 차이를 보입니다.

1.1 CRA(Create React App)의 정체

Create React App(CRA)은 Facebook이 공식적으로 제공하는 React 프로젝트 부트스트래핑 도구입니다. 복잡한 웹팩(Webpack) 설정이나 바벨(Babel) 설정 없이도, 명령 한 줄로 React 프로젝트를 즉시 시작할 수 있게 해주는 “제로 설정(Zero Configuration)” 환경이 특징입니다.

예를 들어, 아래의 명령 한 줄이면 곧바로 React 프로젝트가 생성됩니다.

npx create-react-app my-app

CRA의 장점은 명확합니다. 초보자에게 매우 친화적인 설정과 표준화된 구조, 그리고 이미 많은 레거시 프로젝트에서 사용되고 있다는 점입니다. 또한 React만으로 프론트엔드 기능 구현에 집중하고자 하는 소규모 혹은 단순한 프로젝트에 적합합니다.

하지만 CRA는 그만큼 확장성과 유연성에 제한이 있습니다. 기본적으로 클라이언트 사이드 렌더링(CSR)만 지원하고, 서버 사이드 렌더링(SSR)이나 정적 사이트 생성(SSG) 기능은 별도의 설정 없이는 불가능합니다. 프로젝트가 커질수록 한계에 부딪히게 되는 구조입니다.

1.2 Next.js의 철학과 등장 배경

Next.js는 Vercel(구 ZEIT)에서 개발한 React 기반의 풀스택 프레임워크입니다. 기본적으로 React의 장점을 살리되, 실제 서비스에서 필요한 렌더링 전략(SSR, SSG 등), 라우팅, API 통합, 이미지 최적화 등의 기능을 통합적으로 제공합니다.

Next.js의 초기 철학은 단순했습니다. “React 애플리케이션을 배포 가능한 웹 애플리케이션으로 만들자.” 이 철학은 지금까지도 유효하며, 점차 서버리스 환경과 정적 사이트 최적화까지 포괄하는 방향으로 진화해왔습니다.

Next.js 프로젝트는 다음과 같은 명령어로 쉽게 시작할 수 있습니다.

npx create-next-app my-app

Next.js는 페이지 기반 라우팅 시스템을 기본 탑재하고 있어, 파일을 생성하는것 만으로도 라우팅이 자동으로 적용됩니다.

또한, getServerSideProps, getStaticProps와 같은 메서드를 통해 데이터 페칭과 렌더링 방식을 세밀하게 제어할 수 있습니다.

이러한 유연성 덕분에 Next.js는 단순한 프론트엔드 프로젝트뿐만 아니라, 마케팅 페이지, 블로그, 커머스 플랫폼, 그리고 기업형 서비스에 이르기까지 다양한 스펙트럼을 아우르는 선택지가 되고 있습니다.

요약하자면 CRA는 빠르고 간단한 시작을 위한 도구이고, Next.js는 확장성과 기능 중심의 설계 철학을 가진 프레임워크입니다. 이 차이는 이후의 초기 설정, 개발 생산성, 기능 확장성 등에서도 계속해서 영향을 미치게 됩니다.

2. 초기 설정 비교: 단순함 vs 유연함

React 개발의 출발선은 언제나 프로젝트의 초기 설정입니다. 개발자는 빠르게 코드를 작성하고 싶지만, 실제로는 ESLint 설정, Babel 플러그인, 웹팩 구성, 폴더 구조 설계 등 다양한 설정 작업이 필요합니다. 이런 점에서 CRA와 Next.js는 서로 다른 방향의 철학을 제시합니다. CRA는 ‘자동화된 단순함’을, Next.js는 ‘유연한 구성 가능성’을 강조합니다.

2.1 CRA의 설정 방식과 자동화

CRA의 가장 큰 장점은 ‘복잡한 설정을 몰라도 React 개발을 시작할 수 있다’는 점입니다. create-react-app 명령어 하나로 곧바로 프로젝트가 구성되며, 다음과 같은 기본 디렉토리 구조가 자동으로 생성됩니다.

my-app/
├── node_modules/
├── public/
│   └── index.html
├── src/
│   ├── App.js
│   ├── index.js
│   └── ...
├── package.json
└── README.md

웹팩, Babel, ESLint 설정은 모두 CRA 내부에 숨겨져 있으며, 개발자는 직접 설정을 손대지 않고도 개발을 진행할 수 있습니다. 만약 내부 설정을 수정하고 싶다면 eject 명령어를 사용해야 합니다. 하지만 이는 CRA의 보호막을 해제하고 모든 설정을 직접 관리해야 하므로, 이후 유지보수가 까다로워집니다.

즉, CRA는 간단한 프로젝트나 프로토타입을 빠르게 시작하는 데 적합하지만, 특화된 설정이 필요한 중·대형 프로젝트에는 유연성이 부족할 수 있습니다.

2.2 Next.js의 기본 구성과 커스터마이징

Next.js는 초기 설정 단계에서부터 커스터마이징을 고려한 구조를 갖추고 있습니다. 기본적으로 필요한 라우팅, 페이지 구성, 환경 설정 등의 틀을 제공하면서도, 개발자가 이를 쉽게 확장하거나 수정할 수 있도록 설계되어 있습니다.

Next.js 프로젝트를 생성하면 아래와 같은 구조가 나타납니다.

my-app/
├── node_modules/
├── public/
├── pages/
│   ├── index.js
│   └── api/
│       └── hello.js
├── styles/
├── package.json
└── next.config.js

여기서 눈여겨볼 점은 pages/ 디렉토리입니다. 이 폴더 구조는 곧 라우팅 구조를 의미하며, 파일 하나를 추가하는 것만으로도 페이지가 생성됩니다. 또한 next.config.js 파일을 통해 웹팩이나 Babel 설정을 덮어쓸 수 있어, CRA와 달리 “설정에 자유도가 높다”는 특징이 있습니다.

Next.js는 다음과 같은 기능을 기본 제공하거나 간단한 설정으로 활성화할 수 있습니다.

• ESLint 통합
• TypeScript 자동 감지 및 설정
• 커스텀 Document 및 App 구조 정의
• 환경 변수 설정 (.env)

이처럼 Next.js는 개발자에게 더 많은 제어권을 주며, 실제 운영 서비스에 최적화된 환경 구성이 가능하게 합니다. 단, 그만큼 학습 곡선이 존재하고, 구조적 설계에 대한 고민도 함께 따라오기 때문에 초보자에게는 다소 부담이 될 수 있습니다.

결론적으로, CRA는 ‘설정 없이 바로 시작하고 싶은 개발자’를 위한 환경이며, Next.js는 ‘구조와 성능 최적화를 고려한 확장 가능한 개발 환경’을 지향합니다.

3. 개발 생산성 비교: 효율적인 개발 경험은?

현대 프론트엔드 개발에서 생산성은 단순한 코드 작성 속도 이상의 의미를 가집니다. 개발자가 더 적은 노력으로, 더 명확하게, 더 빠르게 결과를 낼 수 있도록 지원하는 구조와 툴의 통합이 핵심입니다. CRA와 Next.js는 이 부분에서도 각기 다른 경험을 제공합니다.

3.1 라우팅 방식의 차이

CRA는 라우팅이 기본 포함되어 있지 않으며, React Router와 같은 외부 라이브러리를 직접 설치하고 설정해야 합니다. 이는 개발자에게 라우팅에 대한 높은 유연성을 제공하는 한편, 초기 설정 부담을 늘리는 요소이기도 합니다.

npm install react-router-dom

라우트를 구성할 때도 아래와 같이 명시적으로 코드를 작성해야 합니다.

<BrowserRouter>
  <Routes>
    <Route path="/" element={<Home />} />
    <Route path="/about" element={<About />} />
  </Routes>
</BrowserRouter>

반면, Next.js는 라우팅 시스템이 프레임워크에 내장되어 있으며 파일 기반으로 동작합니다. pages 폴더에 파일을 생성하는 것만으로 해당 경로의 라우팅이 자동으로 이루어집니다. 이는 명확하고 직관적인 개발 경험을 제공합니다.

pages/
├── index.js        → "/"
├── about.js        → "/about"
├── blog/
│   └── [slug].js   → "/blog/:slug"

3.2 폴더 구조와 코드 관리

CRA는 src 디렉토리 내에서 어떤 구조든 자유롭게 구성할 수 있지만, 디렉토리 기반 라우팅이나 페이지 기반 설계가 없기 때문에 폴더 구조를 자체적으로 정의해야 합니다. 이는 장기적인 유지보수 관점에서 통일성 부족의 원인이 될 수 있습니다.

Next.js는 pages, public, styles, components 등의 구조를 권장하며, 자연스럽게 계층화된 개발 환경을 제공합니다. 페이지와 API가 폴더 기반으로 구분되기 때문에, 규모가 커질수록 구조적 관리가 용이해지는 장점이 있습니다.

3.3 타입스크립트 및 ESLint, Prettier 통합

개발자의 생산성을 높이는 데 있어 코드 정적 분석 도구나 포매터, 그리고 타입 시스템은 매우 중요한 역할을 합니다. CRA와 Next.js 모두 TypeScript를 지원하지만, 통합 방식에서 차이를 보입니다.

CRA에서는 TypeScript를 사용하려면 프로젝트 생성 시점부터 명시적으로 설정해야 하며, ESLint, Prettier는 별도로 설정하고 확장해야 합니다.

npx create-react-app my-app --template typescript

Next.js는 더 진화된 방식으로, 기존 JavaScript 프로젝트에서 .ts 또는 .tsx 파일을 추가하는 것만으로도 자동 설정을 감지합니다. 또한 프로젝트 생성 시 ESLint와 Prettier 설정을 함께 포함할 수 있는 선택지도 제공합니다. Vercel이 공식적으로 권장하는 구성으로, 일관된 품질 유지에 유리합니다.

이처럼 Next.js는 개발 초기부터 다양한 툴이 자동으로 통합될 수 있는 구조를 제공하며, 이는 특히 협업 프로젝트에서 큰 장점을 발휘합니다.

요약: 라우팅의 직관성, 구조화된 디렉토리 설계, 생산성 도구의 통합 측면에서 Next.js는 더욱 체계적이며 효율적인 환경을 제공합니다. 반면, CRA는 자유도가 높은 대신 모든 구성을 개발자가 수동으로 제어해야 하므로 소규모 프로젝트나 단기간 개발에 더 적합합니다.

4. 확장성과 기능 비교: SSR, SSG, API까지

현대 웹 개발에서 프론트엔드의 역할은 단순히 UI를 렌더링하는 것을 넘어, 백엔드와의 통신, SEO 최적화, 퍼포먼스 향상 등 다양한 요구사항을 수용하는 방향으로 확장되고 있습니다. 이런 변화 속에서 Next.js는 React 기반 프로젝트의 스펙트럼을 넓혀주는 프레임워크로 자리 잡았으며, CRA는 이러한 고급 기능에서는 상대적으로 제한적입니다.

4.1 SSR(Server-Side Rendering)의 지원

Next.js는 기본적으로 SSR을 지원합니다. 페이지 요청 시 서버에서 React 컴포넌트를 렌더링하고, 완성된 HTML을 클라이언트로 전달합니다. 이는 검색 엔진 최적화(SEO)와 첫 페이지 로딩 속도 개선에 매우 효과적입니다.

아래는 SSR을 위한 함수 예시입니다.

export async function getServerSideProps(context) {
  const res = await fetch(`https://api.example.com/data`);
  const data = await res.json();

  return {
    props: { data },
  };
}

이렇게 작성된 페이지는 요청 시마다 서버에서 데이터를 가져와 HTML을 동적으로 생성합니다. 실제 뉴스, 마켓, 관리자 페이지 등 콘텐츠가 자주 변경되는 서비스에 적합한 방식입니다.

반면 CRA는 클라이언트 사이드 렌더링(CSR)만 기본 지원하며, SSR을 사용하려면 Next.js나 자체 Node.js 서버를 추가로 구축해야 합니다. 이는 기술적 허들이며 복잡성을 증가시킵니다.

4.2 정적 사이트 생성(SSG)

Next.js는 정적 페이지 생성 또한 기본 지원합니다. 빌드 시점에 페이지를 생성해 정적인 HTML 파일로 저장하고, 클라이언트가 요청할 때 해당 파일을 빠르게 서빙합니다. 이 접근은 블로그, 문서 페이지, 랜딩 페이지 등에 이상적입니다.

export async function getStaticProps() {
  const res = await fetch('https://api.example.com/static-data');
  const data = await res.json();

  return {
    props: { data },
    revalidate: 60 // ISR: 60초마다 페이지 갱신
  };
}

이와 함께 Next.js는 Incremental Static Regeneration(ISR) 기능을 제공하여, 빌드 이후에도 특정 주기로 정적 페이지를 재생성할 수 있습니다. 이는 SSG의 속도와 SSR의 유연성을 모두 취할 수 있는 혁신적인 전략입니다.

CRA는 SSG 기능을 기본적으로 제공하지 않으며, Netlify나 Gatsby 같은 도구와 연동해야만 정적 페이지 생성을 구현할 수 있습니다.

4.3 API Routes로 백엔드 통합

Next.js는 pages/api 디렉토리를 통해 간단한 서버리스 API 엔드포인트를 정의할 수 있습니다. 이는 별도의 Express 서버나 백엔드 플랫폼 없이도 백엔드 기능을 프로젝트 내에서 직접 구현할 수 있게 해 줍니다.

// pages/api/hello.js
export default function handler(req, res) {
  res.status(200).json({ message: 'Hello from Next.js API!' });
}

이를 통해 인증, 데이터 핸들링, 외부 API 중계 등 다양한 기능을 Next.js 애플리케이션 내부에서 처리할 수 있습니다. 클라이언트와 백엔드를 단일 리포지토리에서 관리할 수 있다는 점은 소규모 프로젝트, 스타트업, MVP 개발에 있어 막대한 생산성 이점을 제공합니다.

CRA에서는 이러한 API 라우팅 기능이 없으며, 백엔드 서버를 별도로 구축하고, CORS 설정을 포함한 다양한 통신 구조를 별도로 구성해야 합니다.

정리하자면, Next.js는 SSR, SSG, ISR, API 라우트 등 강력한 백엔드 통합 기능과 다양한 렌더링 전략을 통해 확장 가능한 구조를 갖추고 있으며, 현대 웹 서비스의 복합적인 요구를 수용할 수 있는 강력한 도구입니다. 반면, CRA는 단일 페이지 애플리케이션(SPA)에 특화된 경량화된 도구로, 고급 기능을 필요로 하지 않는 프로젝트에 적합합니다.

5. 어떤 프로젝트에 어떤 도구를 선택해야 할까?

이제까지의 비교를 통해 CRA와 Next.js가 기술적으로 어떤 차이를 가지는지 파악했습니다. 그렇다면 실무에서 프로젝트를 시작할 때, 어떤 기준으로 두 도구 중 하나를 선택해야 할까요? 기술의 선택은 단순히 트렌드나 성능 수치가 아니라, 프로젝트의 성격과 팀의 역량, 운영 전략에 따라 달라져야 합니다.

5.1 CRA가 유리한 프로젝트

CRA는 다음과 같은 경우에 유리한 선택이 될 수 있습니다.

• 작고 단순한 SPA(Single Page Application)을 개발할 때
• 서버 사이드 렌더링이나 정적 생성이 불필요한 경우 (예: 내부 대시보드, 툴 UI)
• 학습 목적이나 프로토타이핑 단계로 빠르게 화면을 구성해야 할 때
• 개발자가 React에 익숙하지만 웹팩, Babel 등 하위 도구에는 익숙하지 않을 때

예를 들어, 관리형 SaaS 대시보드나 내부용 백오피스는 대부분 로그인 후 사용자 기반으로 동작하며, SEO가 필요하지 않기 때문에 CSR 중심인 CRA가 효율적인 선택이 됩니다.

5.2 Next.js가 빛을 발하는 경우

반면, 다음과 같은 경우에는 Next.js의 활용 가치가 더욱 높아집니다.

• SEO가 중요한 콘텐츠 기반 사이트 (예: 블로그, 마케팅 페이지, 이커머스)
• SSR 또는 SSG 전략을 통해 페이지 로딩 속도 개선이 필요한 경우
• API 엔드포인트와 프론트엔드를 통합 관리하고 싶은 경우
• 지속적인 페이지 생성 및 갱신이 필요한 서비스 (ISR 활용)
• 향후 확장성과 유지보수성까지 고려해야 하는 프로젝트

특히 대규모 서비스에서 SEO 성능은 트래픽의 핵심 요소이기 때문에, SSR 및 SSG를 지원하는 Next.js는 필수 선택지로 여겨집니다. 또한 서버리스 아키텍처에 익숙한 팀에게는 API Routes의 유연성이 매우 유리합니다.

5.3 팀 규모와 기술 성숙도에 따른 선택 가이드

선택 기준	CRA	Next.js
개발 시작 속도	매우 빠름	빠름 (설정 다양)
기능 확장성	낮음	매우 높음
SEO 최적화	지원 불가	기본 지원
학습 난이도	낮음 (초보자 친화)	중간~높음 (개념 다양)
팀 규모	1~3인 소규모 팀	3인 이상 중대형 팀

위의 정리를 통해, 기술적 비교를 넘어서 실무 적용 관점에서 어떤 프레임워크가 더 적합한지를 판단할 수 있습니다. 선택은 결국 개발팀의 역량, 프로젝트의 목적, 서비스의 구조적 방향에 따라 달라져야 합니다.

결론: 당신의 React 프로젝트, 어디서 시작할 것인가

React 프로젝트를 시작하는 데 있어 Create React App(CRA)과 Next.js는 서로 다른 철학과 가능성을 가진 두 가지 도구입니다. CRA는 단순하고 직관적인 환경을 제공함으로써 빠른 시작을 가능하게 하지만, 구조적 한계와 기능적 제약이 존재합니다. 반면, Next.js는 SSR, SSG, API 라우트 등 현대 웹 개발에 필요한 다양한 기능을 포괄하면서도, 초기 진입장벽이 다소 높은 편입니다.

여기서 중요한 포인트는 ‘어떤 것이 더 낫다’가 아니라, ‘당신의 프로젝트에 어떤 것이 더 적합한가’입니다. 프로젝트가 작고, 빠르게 UI만 구현해야 하는 상황이라면 CRA는 충분히 훌륭한 선택입니다. 반대로, SEO가 중요하고 콘텐츠가 풍부하며 확장 가능한 구조를 원한다면, Next.js가 압도적으로 우위에 있습니다.

기술 선택은 항상 전략적인 고민에서 출발해야 합니다. 그리고 그 전략은 기술의 복잡성뿐 아니라 팀의 역량, 프로젝트의 생애 주기, 유지보수 계획, 그리고 사용자의 요구까지 모두 고려한 결정이어야 합니다.

React의 유연함은 도구 선택에서도 그대로 이어집니다. 오늘의 선택이 곧 프로젝트의 품질로 이어지는 만큼, 이 포스팅이 여러분의 개발 여정에 명확한 이정표가 되었기를 바랍니다.

React는 동일하지만, 시작점은 다를 수 있습니다. 그리고 그 시작이 곧, 프로젝트의 미래를 정의할 수 있습니다.