[React] Next.js란 무엇이고 왜 사용하는가

Overview

Next.js는 리액트를 위해 만든 오픈소스 자바스크립트 웹 프레임워크로, 리액트에는 없는 **서버 사이드 렌더링server-side rendering(SSR), 정적 사이트 생성static site generation(SSG), 증분 정적 재생성incremental static regeneration(ISR)**과 같은 다양하고 풍부한 기능을 제공합니다.

서버사이드 렌더링(SSR)을 함으로써 얻는 이득은?

1. 로딩- 클라이언트 사이드 렌더링(CSR)의 경우 모든 js 파일을 로드하고 사용자는 웹을 보게되는데 이때까지 사용자는 많은 시간을 대기해야 하는데, 서버사이드 렌더링은 서버에서 자바스크립트를 로딩함으로 클라이언트 측에서는 자바스크립트를 로딩하는 시간이 줄어들게 됨
2. SEO- 클라이언트 사이드 렌더링(CSR)의 경우 자바스크립트가 로드 되지 않은 경우 아무런 정보를 보이지 않음. 구글의 검색엔진의 경우 자바스크립트가 로드되지 않은 페이지를 검색엔진으로 스캔함으로 결론적으로 검색에 아무 페이지도 걸리지 않게 되는데, 서버 사이드 렌더링은 검색엔진이 자바스크립트를 읽는 것이 아닌 서버측에서 자바스크립트, html, css를 만들어 컨텐츠에 직접 업로드 함으로 검색엔진에 게시글이 걸리게 됨 또한 meta 태그를 자유롭게 추가함으로 SEO를 용이하게 할 수 있음

넥스트 제공 기능

코드 분할code splitting, 서버 사이드 렌더링, 파일 기반 라우팅, 경로 기반 프리페칭pre-fetching 등으로 말이죠. 이제 개발자는 Next.js로 클라이언트와 서버 모두에서 아주 복잡한 작업을 별다른 노력 없이 쉽게 구현할 수 있게 됨

이 외에도 현재 Next.js는 다음과 같은 기능을 제공

● 정적 사이트 생성
● 증분 정적 콘텐츠 생성
● 타입스크립트에 대한 기본 지원
● 자동 폴리필polyfill 적용
● 이미지 최적화
● 웹 애플리케이션의 국제화 지원
● 성능 분석

 

Next 사용의 단점

1. 프레임워크의 공개빌드된 파일들의 폴더가 .next라서 next.js 사용 프로젝트인게 정말 잘 드러난다.
2. 속도SSR의 단점으로 서버가 느리면 웹사이트가 기하급수적으로 느려진다.
3. 서버 부하가 CSR에 비해 많은 편이다.
4. 페이지 이동할때마다 새로운 html 파일을 불러올 때 화면이 깜박거림. (UX적으로 좋지못함)

---

NEXT.js 탄생배경

탄생배경

최근 몇 년 사이 웹 개발 분야에는 많은 변화가 있었습니다. 최신 자바스크립트 프레임워크들이 개발되기 전에는 동적 웹 애플리케이션을 만들기가 어렵고 복잡했습니다. 수없이 많은 라이브러리를 사용해야 했으며 원하는 대로 작동하도록 설정하는 것도 버거웠습니다.

앵귤러Angular, 리액트, 뷰Vue와 같은 프레임워크가 등장하면서 웹 개발 분야는 급속도로 변하기 시작했으며 프런트엔드 웹 개발 분야에서 여러 혁신적인 아이디어를 이끌어냈습니다.

리액트는 페이스북(현재 사명은 메타) 엔지니어 조던 발케Jordan Walke가 만들었으며 XHP Hack 라이브러리에 큰 영향을 주었습니다. 페이스북의 PHP와 Hack 개발자들은 XHP를 통해 자사 애플리케이션의 프런트엔드 부분에서 재사용할 수 있는 컴포넌트를 만들었습니다. 이 자바스크립트 라이브러리는 2013년에 오픈소스가 되었고, 변화를 거듭하며 웹 사이트, 웹 앱, 나중에 다룰 리액트 네이티브를 사용한 네이티브 앱 개발, 심지어는 React VR을 사용한 VR 구현까지 가능하게 했습니다. 그 결과 리액트는 가장 인기 있는 자바스크립트 라이브러리가 되었으며 수백만 개 이상의 웹 사이트에서 다양한 목적으로 사용되고 있습니다.

다만 리액트에는 한 가지 큰 문제점이 있습니다.

바로 리액트가 기본적으로 클라이언트 사이드에서만 작동한다는 점입니다.

사용자의 웹 브라우저에서만 실행되기 때문에 리액트를 사용한 웹 애플리케이션은 검색 엔진 최적화search engine optimization(SEO)의 효과를 거의 볼 수 없으며, 첫 화면에 웹 애플리케이션을 제대로 표시하기 위해 애플리케이션 실행 초기에 성능 부담이 생깁니다.

웹 앱을 완전히 표시하려면 브라우저가 전체 웹 애플리케이션 번들을 다운로드한 다음 그 내용을 분석하고 코드를 실행해서 결과를 얻어야 하기 때문입니다. 그래서 아주 큰 웹 애플리케이션에서는 첫 화면을 표시하기까지 수 초가 소요되기도 합니다.

이 문제를 해결하기 위해 많은 개발자들이 웹 애플리케이션을 서버에서 미리 렌더링해두는 방법을 연구하기 시작했습니다.

서버 사이드 렌더링을 사용할 수 있다면 리액트 앱을 순수한 HTML 페이지로 미리 렌더링해둔 다음 브라우저가 이를 다운로드하여 즉각 화면에 표시하고, 클라이언트에서 자바스크립트 번들을 다 받으면 사용자가 웹 앱과 상호 작용할 수 있게 됩니다.

이러한 연구의 결과로 Vercel이 Next.js를 만들었습니다.

 

넥스트 사용 기업

Next.js는 현재 넷플릭스, 트위치, 틱톡, 훌루, 나이키, 우버, 엘라스틱과 같은 유명 기업에서 사용되고 있습니다.

어떤 회사들이 Next.js를 사용하는지 궁금하다면 웹 사이트를 참고하기 바랍니다.

Next.js는 리액트가 규모에 상관없이 다양한 웹 애플리케이션을 만들 수 있는 훌륭한 도구라는 점을 널리 보여주고 있으며, 그 결과 아주 큰 회사든 스타트업이든 가릴 것 없이 Next.js를 사용하고 있습니다.

물론 서버 사이드 렌더링을 지원하는 프레임워크가 Next.js 하나뿐인 것은 아닙니다.

 

넥스트와 비슷한 프레임워크

Next.js 외에도 자바스크립트 영역에서 서버 사이드 렌더링을 지원하는 프레임워크들이 있습니다.

Next.js가 아닌 다른 프레임워크를 선택한다면 해당 프레임워크가 프로젝트 목적에 얼마나 부합하는지를 고려해야 합니다.

Gatsby

Gatsby는 Next.js 대신 사용할 수 있는 유명한 프레임워크입니다. 특히 정적 웹 사이트를 만들 수 있는 프레임워크를 찾는다면 더할 나위 없이 좋은 선택입니다. Next.js와 달리 Gatsby는 정적 사이트 생성만 지원하는데, 그 때문인지 정말 놀랍도록 잘 만들어냅니다.

모든 페이지를 빌드 시점에 미리 렌더링해서 정적 콘텐츠 형태로 만들기 때문에 어떤 콘텐츠 전송 네트워크content delivery network(CDN)로도 제공할 수 있습니다.

동적 서버 사이드 렌더링을 지원하는 다른 프레임워크와 비교해보면 놀라운 성능을 확인할 수 있습니다. Next.js와 비교했을 때 Gatsby의 가장 큰 단점은 역시 동적 서버 사이드 렌더링을 지원하지 않는다는 점입니다. 따라서 데이터에 따라 동적으로 변하는 복잡한 웹 사이트는 만들 수 없습니다.

Razzle

Razzle은 Next.js만큼 유명하진 않지만 서버 사이드 렌더링이 가능한 자바스크립트 애플리케이션을 만들 수 있습니다.

Razzle의 핵심은 create-react-app 도구를 쉽게 사용하면서도 서버와 클라이언트의 복잡한 애플리케이션 설정들을 추상화하고 단순하게 만들 수 있다는 점입니다.

Next.js나 다른 프레임워크 대신 Razzle을 썼을 때의 가장 큰 장점은 사용할 프레임워크에 관한 지식이 없어도 된다는 것입니다.

리액트, 뷰, 앵귤러, Elm, Reason-React 등 어떤 프레임워크든 원하는 것을 쓸 수 있습니다.

Nuxt.js

뷰를 사용한 웹 애플리케이션 개발에서 리액트의 Next.js에 해당하는 것은 Nuxt.js입니다.

서버 사이드 렌더링, 정적 사이트 생성, 프로그레시브 웹 앱 관리 등과 같은 기능을 제공하면서도 성능, SEO, 개발 속도 등에서 별다른 차이가 나지 않습니다. Nuxt.js나 Next.js 모두 같은 목표를 갖는 프레임워크지만 Nuxt.js는 좀 더 많은 설정을 필요로 합니다.

하지만 이런 부분은 그다지 큰 문제가 되지 않습니다. Nuxt.js 설정 파일에서는 레이아웃, 전역global 플러그인과 컴포넌트, 라우트 등을 지정할 수 있습니다.

반면 Next.js는 이런 설정을 리액트와 동일하게 처리합니다. 이 부분을 제외하면 Nuxt.js와 Next.js는 많은 기능이 동일합니다. 가장 큰 차이점은 바로 기저의 라이브러리가 무엇이냐는 것입니다. 만약 뷰를 사용한다면 서버 사이드 렌더링을 위해 Nuxt.js를 사용해보는 것도 좋습니다.

Angular Universal

앵귤러는 서버에서 자바스크립트 코드를 실행하고 렌더링하는 기능을 제공하고자 Angular Universal을 세상에 선보였습니다.

이 역시 정적 사이트 생성과 서버 사이드 렌더링을 지원하지만 Nuxt.js나 Next.js와 다른 점은 가장 큰 소프트웨어 회사인 구글에서 만들었다는 점입니다.

앵귤러로 웹 애플리케이션이나 컴포넌트를 만들었다면 자연스럽게 Nuxt.js나 Next.js가 아닌 Angular Universal을 사용하게 될 것입니다.

 

왜 Next?

바로 Next.js가 제공하는 믿기 힘들 정도로 뛰어난 기능들 때문

Next.js는 리액트에서 제공하지 않는 여러 기능을 지원하며 비단 컴포넌트뿐만 아니라 설정이나 개발 옵션 등 다양한 부분에서도 유용한 기능들을 제공합니다. 필자는 Next.js가 지금껏 보았던 프레임워크 중 가장 완벽한 것이 아닐까 생각합니다.

Next.js는 활동적인 커뮤니티를 가지고 있으며 커뮤니티에서 열렬한 지지도 받고 있습니다.

Next.js를 사용해서 애플리케이션을 만들 때 단계별로 많은 지원을 받을 수 있다는 뜻이죠.

이는 정말 큰 장점입니다.

개발하고 있는 웹 애플리케이션 코드에 문제가 생겼을 때 GitHub나 스택 오버플로와 같은 다양한 커뮤니티에서 도움을 받을 수 있기 때문입니다. Next.js를 만든 Vercel 팀에서도 이런 요청이나 토의에 적극 참여하고 있습니다.

지금까지 Next.js와 경쟁 프레임워크를 살펴보았습니다. 이제 기본적으로 클라이언트에서만 실행되는 리액트 앱의 자바스크립트 코드와, 서버 사이드 렌더링을 사용해서 웹 페이지를 빌드 시점에 정적으로 생성하고 사용자 요청을 동적으로 처리하는 자바스크립트 코드가 어떤 차이점을 갖는지 알아보겠습니다.

 

리액트에서 Next로

리액트를 사용해본 경험이 있다면 Next.js로 웹 사이트를 만드는 것은 어렵지 않습니다.

Next.js의 기본 철학은 리액트와 거의 같습니다.

‘설정보다 관습convention-over-configuration’이라는 취지로 만들어졌기 때문에 Next.js의 특정 기능을 사용하고자 한다면 복잡한 설정 없이도 해당 기능을 사용할 수 있는 쉬운 방법을 찾을 수 있습니다.

설정보다 관습(convention-over-configuration): 개발자가 해야 할 결정의 수를 줄여주면서도 유연성은 잃지 않도록 하는 소프트웨어 설계 패러다임입니다.

예를 들어 단일 Next.js 애플리케이션에서 별도의 설정 파일을 만들지 않고도 어떤 페이지에 서버 사이드 렌더링을 적용하고 어떤 페이지에 정적 페이지 생성을 적용할지 지정할 수 있는 것이죠.

각 페이지에서 특정 함수를 익스포트export하면 Next.js가 나머지 일을 알아서 처리합니다.

리액트와 Next.js의 가장 큰 차이점은 무엇일까요?

리액트는 자바스크립트 라이브러리이고 Next.js는 프레임워크라는 점입니다.

Next.js는 클라이언트와 서버에서 실행할 수 있는 코드에 풍부하고 다양한 기능을 제공하여 웹 애플리케이션을 만들 수 있게 해줍니다.

서버 사이드 렌더링 페이지나 정적으로 생성된 페이지 모두 Node.js에서 실행되기 때문에 fetch, window, document와 같이 웹 브라우저에서 제공하는 전역 객체나 canvas 같은 HTML 요소에는 접근할 수 없습니다.

Next.js 페이지를 만들 때는 이 점을 꼭 기억하기 바랍니다.

전역 변수나 HTML 요소를 반드시 사용해야 하는 컴포넌트를 다루는 방법도 Next.js에서 제공합니다.

반면 fs, child_process와 같이 Node.js에서만 사용할 수 있는 라이브러리나 API를 사용하려는 경우, Next.js는 각 요청별 데이터를 클라이언트로 보내기 전에 서버 사이드 코드를 실행하거나 페이지 생성 시점에 해당 코드를 처리하는 방식을 지원합니다.

어떤 방식으로 지원하는지는 각 페이지가 어떤 렌더링 방식을 사용하느냐에 따라 결정됩니다.

클라이언트 사이드 앱을 만들고자 할 경우에도 리액트의 create-react-app 대신 Next.js를 사용할 수 있습니다.

Next.js는 프로그레시브 웹 앱이나 오프라인 웹 앱 역시 쉽게 만들 수 있을 뿐만 아니라 많은 내장 컴포넌트와 최적화 기능을 사용할 수 있다는 장점도 있습니다.

---

Next.js가 제공하는 주요 기능

hot reloading

개발 중 저장되는 코드는 자동으로 새로고침됩니다.

automatic routing

pages 폴더에 있는 파일은 해당 파일 이름으로 라우팅됩니다. (pages/page1.tsx -> localhost:3000/page1)

public 폴더도 pages의 폴더와 동일하게 라우팅 할수있습니다. 그러나 모든 사람이 페이지에 접근할 수 있으므로 지양하도록합니다.

single file components

style jsx를 사용함으로 컴포넌트 내부에 해당 컴포넌트만 스코프를 가지는 css를 만들수 있습니다.

// styled-jsx

function Heading(props) {
  const variable = "red";
  return (
    <div className="title">
      <h1>{props.heading}</h1>
      <style jsx>
        {`
          h1 {
            color: ${variable};
          }
        `}
      </style>
    </div>);
}

export default function Home() {
  return (
    <div>
      // red
      <Heading heading="heading" />
      // block
      <h1>ttt</h1>
    </div>);
}

• <style jsx global>를 사용하면 글로벌로 스타일 정의 가능합니다.

글로벌 스타일 정의 가능

_app.tsx에만 정의 가능합니다. 다른 컴포넌트에 정의한 경우 다른 클래스와 겹쳐 오류를 발생할 수 있음으로 _app에서만 허용합니다. 다른 컴포넌트에 정의시 아래와 같은 오류를 냅니다

Global CSS cannot be imported from files other than your Custom <App>. Please move all global CSS imports to pages/_app.tsx. Or convert the import to Component-Level CSS (CSS Modules).

// _app.tsx
import "./globals.css";

function MyApp({ Component, pageProps }) {
  return <Component ponent {...pageProps} />;
}

export default MyApp;

server landing

서버렌더링을 합니다. 클라이언트 렌더링과 다르게 서버렌더링을 한 페이지의 페이지 소스보기를 클릭하면 내부에 소스가 있습니다.

code splitting

dynamic import를 이용하면 손쉽게 코드 스플리팅이 가능합니다.

코드 스플리팅은 내가 원하는 페이지에서 원하는 자바스크립트와 라이브러리를 렌더링 하는 것입니다. 모든 번들(chunk.js)이 하나로 묶이지 않고, 각각 나뉘어 좀 더 효율적으로 자바스크립트 로딩 시간을 개선할 수 있습니다.

typescript

타입스크립트 활용을 위해 웹팩을 만지거나 바벨을 만질 필요 없습니다. 타입스크립트를 설치하고 (yarn add typescript @types/node @types/react) 명령어 (yarn run dev)만 하면 자동으로 tsconfig, next-end.d.ts가 생성되어 타입스크립트로 코딩이 가능해집니다.

sass 사용하기

따로 config 파일을 정의 하지 않고이 css 파일을 scss로 바꾸고 yarn add sass --dev 를 해주면 next에서 알아서 설정을 해줍니다

---

_app.tsx

• 이곳에서 렌더링 하는 값은 모든 페이지에 영향을 줍니다.
• 최초로 실행되는 것은 _app.tsx
• _app.tsx은 클라이언트에서 띄우길 바라는 전체 컴포넌트 → 공통 레이아웃임으로 최초 실행되며 내부에 컴포넌트들을 실행함
• 내부에 컴포넌트가 있다면 전부 실행하고 html의 body로 구성
• Component, pageProps를 받습니다.
  • 여기서 props로 받은 Component는 요청한 페이지입니다. GET / 요청을 보냈다면, Component 에는 /pages/index.js 파일이 props로 내려오게 됩니다.
  • pageProps는 페이지 getInitialProps를 통해 내려 받은 props들을 말합니다.
• 그 다음 _document.tsx가 실행됨
• 페이지를 업데이트 하기 전에 원하는 방식으로 페이지를 업데이트 하는 통로
• _app.tsx에서 console.log 실행시 client, server 둘다 콘솔 찍힙니다. (localhost:3000 웹과 터미널에서 둘다 콘솔 보임)

---

Next 사용의 단점

1. 프레임워크의 공개빌드된 파일들의 폴더가 .next라서 next.js 사용 프로젝트인게 정말 잘 드러난다.
2. 속도SSR의 단점으로 서버가 느리면 웹사이트가 기하급수적으로 느려진다.
3. 서버 부하가 CSR에 비해 많은 편이다.
4. 페이지 이동할때마다 새로운 html 파일을 불러올 때 화면이 깜박거림. (UX적으로 좋지못함)

출처

next.js 기본 개념 알아보기

리액트에서 Next.js로, 넥스트JS의 특장점과 빠르게 시작하는 법 알아보기