프론트엔드/Next.JS

React 와 Next.js 비교

학습하는 청년 2023. 8. 9. 20:30

최종 수정 : 2025-06-12

React 와 Next.js 비교

■ 라이브러리(Library) / 프레임워크(Framework)

  • 리액트(React): 자바스크립트의 라이브러리
  • Next.JS: 자바스크립트의 프레임워크

라이브러리(Library)

  • 어플리케이션을 만들 때 필요한 자원(기능: 함수)의 모임
  • 응용 프로그램이 라이브러리를 사용한다.

프레임워크(Framework)

  • 코드를 작성하는 기본적인 틀을 제공해서 보다 효율적으로 어플리케이션을 만들 수 있도록 하는 소프트웨어 환경
  • 프레임워크에 의해 응용 프로그램이 사용된다.

■ CSR / SSR

둘의 차이는 유저가 브라우저에서 보는 화면(UI)를 어디에서 만들어 주는지에 따라 다르다.

  • React: CSR(Client-Side-Rendering)
  • Next.js: SSR(Server-Side-Rendering)

React 동작 방식 (CSR)

  1. 유저가 앱에 브라우저에 접속하면,
  2. 앱은 javascript 정보가 들어 있는 빈 html 문서를 브라우저에게 전달한다. 즉, javascript파일을 브라우저에게 전달하는 것이라 할 수 있다.
  3. 브라우저가 javascript 파일을 다운로드 하는 순간, 유저는 빈 화면을 보게 된다(접속에 대한 응답).
  4. 브라우저에서 javascript파일 다운로드가 끝나면, 리액트 코드가 있는 js파일을 실행한다.
  5. 브라우저에 있는 리액트 코드가 UI를 동적으로 렌더링한다.
  6. 유저는 앱 화면을 보게 된다.

브라우저가 javascript 코드를 가지고 있지 않거나, 요청 중인 상태일 경우 UI를 구성할 수 없다. 유저는 빈 화면을 마주하게 된다. 리액트 코드가 실행되기 전까지 그렇다. 이렇게 클라이언트 측에서 UI를 빌드하는 것을 CSR 방식이라 한다.

 

React는 SPA로 하나의 페이지 안에서 모든 데이터를 주고 받는다. react-router-dom 같은 라우팅 라이브러리를 사용해서 페이지 이동처럼 보이게 만들어 준다. 하지만 실제로는 페이지가 이동하는 것이 아니다. URL이 변경될 때, 보여지는 컴포넌트가 달라지는 것 뿐이다. 그러므로 실제로 페이지가 이동된 후, 다시 HTML과 JavaScript를 받아오는 것이 아니다.

 

React에서는 맨 처음 유저가 웹에 방문하면 HTML을 받아오고 CSS와 JavaScript를 불러와 웹을 동작시키면, React안에 작성해놓은 코드들이 동작한다.

 

장점

  • 초기 로드만 완료되면 이후 렌더링이 빠르다.
  • 서버에 요청할 것이 거의 없어 서버 부담이 적다.(data 필요시에만 요청)
  • Web Applications에 좋다.

단점

  • SEO에 좋지 않다.
    - 초기 HTML에는 동적으로 생성되는 콘텐츠가 포함되어 있지 않다. 검색 엔진 크롤러가 페이지를 수집할 때 동적으로 생성된 콘텐츠를 인식하지 못하기 때문에, 검색 결과에서 노출되는 확률도 떨어진다.
    - 또한, 페이지 로딩이 JavaScript 파일의 다운로드와 실행에 따라 지연됨에 따라 초기 로딩 속도가 느릴 수 있는데, 검색 엔진이 페이지의 초기 로딩 속도를 평가하는 중요한 요소 중 하나이므로 검색 엔진이 페이지를 빠르게 로딩할 수 없을 경우 페이지 노출이 낮아지는 원인이 될 수 있다.
  • 초기 로드가 오래 걸린다.
  • 외부 라이브러리가 필요한 경우가 많다.

 

Next 동작 방식 (SSR)

  1. 유저가 앱에 접속하면,
  2. 서버에서 리액트를 실행한다.
  3. 리액트는 UI를 렌더링한다.
  4. 렌더링된 결과를 통해 HTML을 브라우저에게 제공한다. 이때 유저는 앱의 초기화면을 보게 된다(접속에 대한 응답).
  5. 이후 브라우저는 리액트 코드가 있는 JavaScript 파일을 다운받고 실행시킨다. 이때부터 리액트와 같이 CSR의 동작(동적 렌더링)을 하게 된다. 이런 과정을 hydration이라고 한다.

서버에서 UI를 모두 구성한 후 유저에게 응답 화면을 보여주는 방식이다. 화면이 pre-rendering되어 유저는 인터넷 속도에 상관없이 화면에 뭔가 나오는 것을 볼 수 있다. 이렇게 서버 측에서 UI를 렌더링하는 것을 SSR 방식이라 한다.

hydration
리액트 코드가 브라우저에 이미 존재하는 HTML과 동기화하여 앱이 동적으로 상호작용할 수 있도록 하는 과정

 

장점

  • SEO에 좋다.
    - HTML 파일에 모든 정보가 포함되어 있기 때문에 봇이 데이터를 수집할 수 있다. 덕분에 페이지의 콘텐츠가 검색 엔진에 잘 색인되고 순위가 올라갈 수 있게끔 만든다.
  • 향상된 성능
    - SSR과 SSG를 통해 웹사이트의 성능을 향상시킨다.
  • 프리 렌더링(Pre-Rendering)을 통해 페이지 로딩 속도가 향상된다.
  • 덕분에 사용자 경험(UX)도 개선된다.
  • Static Sites(정적 앱)에 좋다.
  • Next.js는 확장성이 용이한 덕분에 고트래픽(high-traffic) 웹사이트를 다룰 수 있다. 트래픽이 증가함에 따라 웹사이트를 확장할 수 있다.
  • 클라우드 기반 호스팅 서비스를 통해 쉽게 배포할 수 있다.
  • CSR과 SSR을 통해 다이나믹한 콘텐츠를 제공하며, 사용자에게 원활하고 흥미로운 경험을 제공한다.

단점

  • 전체 앱을 서버에서 앞서 렌더링하기 때문에 컴포넌트 로딩이 오래 걸릴 수 있다. 이때, 유저는 빈 화면을 볼 수도 있다.
  • 서버에 매번 요청하기 때문에 서버 부하가 크다(view 변경 시 요청).
  • 페이지를 요청할 때마다 새로고침되어 UX가 떨어진다.
  • Next.js는 복잡한 웹 사이트에 적합한 프레임워크이다. 그렇기에 단순한 웹사이트를 만들 때는 너무 많은 복잡성이 추가될 수 있다.

■ Next.js가 제공하는 이점

1. 프리렌더링

기본적으로 모든 페이지 컴포넌트를 프리렌더링한다. 데이터의 성격에 따라 getStaticProps를 활용해 빌드 단계에서 데이터를 받아 정적 생성 또는 SSR할 수 있다. 이를 통해 이미 렌더링된 html 문서를 가져올 수 있어서 첫 로딩이 빨라져 유저 경험에 좋고, SEO에도 강점이 있다.

 

Next.js 15에서는 getStaticProps / getServerSideProps를 더 이상 사용하지 않는다. 렌더링 방식은 fetch 위치와 옵션으로 자동 결정되며 서버 컴포넌트는 기본적으로 SSR이다. 설정에 따라 SSG나 ISR로 바뀐다.

fetch 위치
서버 컴포넌트: SSR, SSG, ISR 가능하며, 데이터를 서버에서 미리 불러오고 HTML을 생성한다.
클라이언트 컴포넌트: CSR이며, 브라우저에서 데이터 fetch 후 클라이언트에서 렌더링된다.

fetch 옵션
옵션 없음: SSR이며, 빌드시 HTML 생성
{ cache: 'no-store' }: SSR이며, 요청마다 HTML을 새로 생성
{ next: { revalidate: N } }: ISR이며, N초 후 요청 시 백그라운드 재생성

 

2. 이미지 최적화

Image 컴포넌트를 통해 필요한 크기에 맞는 이미지를 제공하고, lay-loading 속성이 기본적으로 활성화되어 있어 화면에 보여질 시점에 이미지를 로딩하여 초기 페이지 로딩 속도를 개선한다.

Q. 크기에 맞는 이미지를 제공한다면, 크기를 지정하지 않아도 되는가?

Image 컴포넌트에서 크기(width, height)를 지정해주는 것이 최적화에 필수에 가깝다.
이미지의 사이즈를 명시해줄 경우, 이를 기반으로 여러 해상도에 맞는 최적화된 이미지를 생성한다.
지정한 사이즈를 기준으로 브라우저에 가장 적합 해상도의 이미지를 제공하여 불필요하게 큰 이미지를 받는 문제를 방지한다.

 

3. Client side navigation

Link 컴포넌트를 통해 페이지를 이동할 때 페이지 전체를 불러오는 것이 아니라 필요한 데이터만 가져오기 때문에 이동 속도도 빨라지고 부드럽게 넘어간다.

 

4. 코드 스플리팅

Webpack과 같은 번들러 설정과 import 문법, lazy, Suspense 사용없이도 빌드 과정에서 페이지 단위로 자동으로 코드 스플리팅을 지원한다.

 

Next.js는 페이지 단위 코드 스플리팅을 기본으로 지원한다. 각 페이지는 별도의 JS 번들로 분리되어, 사용자가 해당 페이지에 접근할 때 필요한 코드가 로드된다. 그래서 대부분의 경우, 별도로 코드 스플리팅을 신경쓰지 않아도 된다. 다만, 컴포넌트 단위로 지연 로딩이 필요할 때는 dynamic() 함수를 사용하는 것이 좋다.

Q. 그렇다면 Suspense를 사용 안 해도 되는가?

일반적인 페이지 전환 수준에서는 사용하지 않아도 충분하다. 하지만, 특정 컴포넌트 단위로 코드 분할하고 싶다면
1) React: React.lazy와 Suspense를 사용할 수 있다. 
2) Next.js: dynamic() 함수를 사용하는 것이 좋다.

 

React.lazt + Suspense VS next/dynamic

1) React.lazt + Suspense
간단한 문법으로, 순수 React 프로젝트에서 매우 유용하다.
하지만, SSR이 불가능하므로, Next.js에서는 클라이언트 전용에서만 사용 가능하다.

2) next/dynamic
SSR 지원 여부를 직접 제어 가능 -> 'use client'가 선언된 컴포넌트에서도 ssr: false 설정을 통해 사용할 수 있다.
SEO 고려 가능
Suspense 없이도 로딩 UI 제공 가능
공식 문서에서도 React.lazy 대신 이를 권장

 

5. 개발자 경험

파일 시스템 라우팅, 리다이렉트, 스타일링을 위한 환경 설정(Sass, CSS Modules, Tailwind 등)을 제공해 좋은 개발 경험을 제공한다.

Q. CSR과 SSR 무엇이 더 좋은가?

SSR이 CSR 이후 각광 받으면서, CSR보다 SSR이 더 최신 기술, 혹은 더 '좋은' 기술'이라고 생각하는 사람들이 있다. 하지만 생각해보면, SSR은 SPA가 아닌 MPA에서 정적 페이지를 렌더링할 때부터 쓰이던 기술로, 예전 기술을 SPA 환경에서 채택한 것이라고 볼 수 있다. 그러므로, 어떤 기술이 좋다, 나쁘다 혹은 최신이나 아니다를 논하는 것은 무의미하다. 이보다는, 만들고 있는 웹 사이트에 맞게 CSR과 SSR 중 채택하여 정할 수 있는 능력이 있어야 한다.

■ 참고 영상 및 글

[NextJS] NextJS 시작하기 - 2. React.js와 Next.js의 차이점 (framework vs. library, CSR vs. SSR)

https://gyyeom.tistory.com/56

 

CSR과 SSR의 장단점 Next.js 선택 이유와 고려사항

https://seo0yoon.tistory.com/221

 

Next.js 웹 개발 프레임워크: 장점과 단점, SEO를 고려한 선택 방법

https://liahoneyblog.co.kr/next-js-%ec%9b%b9-%ea%b0%9c%eb%b0%9c-%ed%94%84%eb%a0%88%ec%9e%84%ec%9b%8c%ed%81%ac-%ec%9e%a5%ec%a0%90%ea%b3%bc-%eb%8b%a8%ec%a0%90-seo%eb%a5%bc-%ea%b3%a0%eb%a0%a4%ed%95%9c-%ec%84%a0%ed%83%9d/

 

Next.js를 사용하면서 리액트랑 별반 다르지 않다고 느꼈던 이유

https://www.reason-to-code.com/blog/why-we-couldn't-feel-the-difference-of-nextjs/

 

 

 

 

저작자표시 비영리 변경금지 (새창열림)