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

한빛미디어

2023-01-30

by 미셸 리바, 박수현

89,714

Next.js란 무엇인가?

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

수많은 내장 컴포넌트와 플러그인 덕분에 소규모 웹 사이트뿐만 아니라 거대한 상용 애플리케이션에도 즉시 Next.js를 적용할 수 있죠.

확장 가능하고 유지 보수가 쉬운 웹 애플리케이션을 만들기 위한 여러 가지 방법을 제공한다고 보시면 되겠습니다.

오늘은 아래 내용을 알아 보겠습니다.

● Next.js 프레임워크 소개

● Next.js와 다른 유명한 프레임워크 비교

● Next.js와 클라이언트 사이드client-side 리액트의 차이점

● Next.js 프로젝트의 기본 구조

● Next.js에서 타입스크립트TypeScript를 사용하는 방법

● 바벨Babel과 웹팩webpack 설정 커스터마이징

Next.js 준비하기

Next.js를 시작하려면 개발 장비에 몇 가지 준비가 필요합니다.

먼저 Node.js와 npm을 설치해야 합니다.

여러분의 개발 장비에 Node.js를 설치하고 싶지 않다면 무료 온라인 IDE3에서 예제 코드를 작성하고 실행할 수도 있습니다.

Node.js와 npm을 모두 설치했거나 온라인 환경을 사용하기로 결정했다면 이제부터는 책의 내용을 따라가며 프로젝트별로 필요한 의존성 패키지들만 npm으로 설치하면 됩니다.

Node.js와 npm 설치 방법

코드는 GitHub 저장소에서 확인할 수 있습니다.

필요하다면 코드를 마음껏 포크fork하고, 클론clone하고, 편집하고, 실험하기 바랍니다.

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는 첫 릴리스부터 리액트가 제공하지 않는 다양한 기능을 제공하면서 리액트 웹 앱 개발 분야의 판도를 뒤흔들어 놓았습니다.

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

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

● 정적 사이트 생성

● 증분 정적 콘텐츠 생성

● 타입스크립트에 대한 기본 지원

● 자동 폴리필polyfill 적용

● 이미지 최적화

● 웹 애플리케이션의 국제화 지원

● 성능 분석

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.js일까?

앞서 Next.js 대신 사용할 수 있는 유명한 프레임워크들의 장단점을 살펴보았습니다.

하지만 필자는 여전히 Next.js를 추천합니다.

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

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

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

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

이는 정말 큰 장점입니다.

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

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

리액트에서 Next.js로.png

리액트에서 Next.js로

리액트를 사용해본 경험이 있다면 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 시작하기

Next.js에 관한 기본 지식과 클라이언트 사이드 리액트 및 다른 프레임워크의 차이점을 알아보았으니 이제 Next.js 코드를 살펴볼 차례입니다.

우선 새로운 앱을 하나 만들고 웹팩과 바벨 기본 설정을 커스터마이징해보겠습니다.

또한 Next.js 앱을 만들 때 기본 언어로 타입스크립트를 사용하는 방법도 알아보겠습니다.

프로젝트 기본 구조

Next.js는 시작하기 정말 쉽습니다.

개발 환경에 Node.js와 npm만 설치하면 됩니다. 또한 Vercel 팀에서 제공하는 아주 강력하고 직관적인 도구인 create-next-app이 기본적인 Next.js 앱을 시작할 수 있는 코드를 생성해줍니다. 따라서 다음과 같이 터미널에서 Next.js 개발을 간단하게 시작할 수 있습니다.

npx create-next-app <app-name>

이렇게 하면 필요한 의존성 패키지들이 설치되고 몇 개의 기본 페이지가 생성됩니다.

그런 다음 npm run dev 명령을 실행하면 개발 서버가 시작되며, 3000번 포트로 접근해서 웹 페이지를 볼 수 있습니다.

yarn 패키지가 설치되어 있는 경우 Next.js는 yarn 패키지 관리자를 사용해서 프로젝트를 초기화합니다.

이 경우에도 npm을 기본으로 사용하고 싶다면 다음 명령으로 설정을 덮어쓸 수 있습니다.

npx create-next-app <app-name> --use-npm

Next.js GitHub 저장소에서 원하는 보일러플레이트 코드를 다운로드해서 새 Next.js 프로젝트를 시작할 수도 있습니다.

Next.js 저장소에는 example 디렉터리가 있는데 이곳에는 다양한 기술이 사용된 훌륭한 예제 코드가 있습니다.

만약 Next.js 앱을 도커 환경에서 실행하는 예시를 보고 싶다면 다음과 같이 --example 옵션으로 어떤 보일러플레이트 코드를 사용할 것인지 알려주면 됩니다.

npx create-next-app <app-name> --example with-docker

그럼 create-next-app이 웹 사이트에서 코드를 다운로드한 다음 필요한 의존성 패키지들을 설치할 것입니다.

이제 다운로드한 파일을 수정하거나 커스터마이징하는 방법으로 개발을 시작할 수 있습니다.

그 외에도 웹 사이트에서 다양한 예제 코드를 살펴볼 수 있습니다. 이미 Next.js를 사용해봤다면 다른 서비스나 도구를 Next.js와 어떻게 함께 사용하는지 살펴보는 것도 도움이 됩니다. 물론 이런 내용 역시 이 책의 후반부에서 다룹니다.

다시 create-next-app 설치 부분으로 돌아가겠습니다. 터미널을 열고 다음 명령을 실행해서 Next.js 앱을 시작해봅시다.

npx create-next-app my-first-next-app --use-npm

기본 코드가 생성되고 나면 다음과 같은 구조의 my-first-next-app 디렉터리가 만들어집니다.

- README.md

- next.config.js

- node_modules/

- package-lock.json

- package.json

- pages/

- _app.js

- api/

- hello.js

- index.js

- public/

- favicon.ico

- vercel.svg

- styles/

- Home.module.css

- globals.css

리액트를 사용해본 경험이 있다면 클라이언트에서의 내비게이션을 위한 react-router 또는 이와 비슷한 라이브러리를 사용해보았을 것입니다.

Next.js에서의 내비게이션은 pages/ 디렉터리를 사용하기 때문에 훨씬 쉽습니다.

pages/ 디렉터리 안의 모든 자바스크립트 파일은 퍼블릭public 페이지가 되며, pages/ 디렉터리의 index.js 파일을 복사해서 about.js로 이름을 바꾸면 http://localhost:3000/about 주소로 접근했을 때 똑같은 페이지를 볼 수 있습니다.

지금은 pages/ 디렉터리에 퍼블릭 페이지들이 있다는 사실만 기억하기 바랍니다.(Next.js가 어떻게 클라이언트와 서버에서 라우트를 다루는지는 책에서 자세히 살펴 보겠습니다.)

public/ 디렉터리에는 웹 사이트의 모든 퍼블릭 페이지와 정적 콘텐츠가 있습니다. 이를테면 이미지 파일, 컴파일된 CSS 스타일시트, 컴파일된 자바스크립트 파일, 폰트 등이 있을 수 있습니다.

styles/ 디렉터리도 기본으로 생성됩니다. 웹 애플리케이션에서 사용하는 스타일시트를 여기에 둘 수 있지만 Next.js 프로젝트에 styles/ 디렉터리가 꼭 필요한 것은 아닙니다.

반드시 있어야 하고 용도가 정해져 있는 디렉터리는 public/과 pages/뿐이며, 나머지 디렉터리는 필요에따라 다른 목적으로 사용하거나 지워도 됩니다.

또한 프로젝트 최상위 디렉터리에 필요한 디렉터리나 파일을 추가해도 Next.js의 빌드 및 개발 프로세스에는 아무런 영향을 주지 않습니다.

컴포넌트를 components/ 디렉터리 아래에, 유틸리티 기능을 utilities/ 디렉터리에 두고 사용해도 아무 상관없습니다.

만약 보일러플레이트 코드 생성 방식을 사용하지 않는다면, 모든 의존성 패키지를 따로 추가한 다음 기본적인 디렉터리 구조를 추가하는 것만으로도 새로운 Next.js 애플리케이션을 만들 수 있습니다. 그 외에는 별도로 설정을 할 필요가 없습니다.

타입스크립트 지원

Next.js는 타입스크립트로 작성된 프레임워크라서 태생적으로 고품질의 타입 정의type definition를 지원합니다.

개발자들에게 훨씬 더 좋은 개발 환경을 제공하는 것이죠. Next.js 앱에서 기본 언어를 타입스크립트로 지정하는 방법은 아주 간단합니다.

프로젝트의 최상위 디렉터리 안에 tsconfig.json이라는 타입스크립트 설정 파일만 만들면 됩니다. 그리고 npm run dev 명령을 실행하면 다음과 같은 메시지를 확인할 수 있습니다.

It looks like you're trying to use TypeScript but do not have the required package(s) installed.

Please install typescript, @types/react, and @types/node by running:

npm install --save-dev typescript @types/react @types/node

If you are not trying to use TypeScript, please remove the tsconfig.json file from your package root (and any TypeScript files in your pages directory).

보다시피 Next.js가 타입스크립트를 사용한다는 것을 알고 프로젝트가 사용하는 주 언어에 대한 의존성 패키지를 설치해달라고 합니다.

표시된 메시지와 같이 필요한 패키지를 설치하고 나면 자바스크립트 파일을 타입스크립트로 바꾸어서 타입스크립트 앱을 시작할 수 있습니다.

새로 만든 tsconfig.json 파일은 아무 내용도 없는 빈 파일이지만 패키지들을 설치하고 나면 Next.js는 기본 설정 내용을 이 파일에 기록합니다.

필요한 경우 이 파일의 내용을 수정해서 타입스크립트 설정을 바꿀 수 있지만 Next.js가 바벨의 @babel/plugin-transform-typescript를 사용해서 설정 파일을 관리하기 때문에 다음 주의사항을 숙지해야 합니다.

● @babel/plugin-transform-typescript 플러그인은 타입스크립트에서 자주 사용하는 const enum을 지원하지 않습니다. const enum을 사용하고 싶다면 바벨 설정에 babel-plugin-const-enum을 추가해야 합니다. 자세한 내용은 <바벨과 웹팩 설정 커스터마이징>에서 설명합니다.

● export =와 import = 구문은 사용할 수 없습니다. 두 가지 모두 ECMAScript 코드로 컴파일할 수 없기 때문입니다. babel-plugin-replacets-export-assignment를 설치하거나 import x, {y} from 'same-package' 또는 export default x와 같은 올바른 ECMAScript 구문으로 바꾸어야 합니다.

이 외에도 많은 주의사항이 있습니다. Next.js 앱에서 타입스크립트를 주 언어로 사용하고 싶다면 먼저 공식 바벨 문서를 읽어보기 바랍니다.

또한 몇 가지 컴파일러 옵션이 기본 타입스크립트와 조금 다릅니다. 이 내용 역시 공식 바벨 문서에서 확인할 수 있습니다.

Next.js는 프로젝트 최상위 디렉터리에 next-env.d.ts 파일도 만듭니다. 이 파일은 마음대로 수정해도 되지만 지워서는 안 됩니다.

바벨과 웹팩 설정 커스터마이징

타입스크립트 설정 부분에서도 설명했듯이 바벨이나 웹팩 설정을 커스터마이징할 수 있습니다.

바벨 설정을 커스터마이징하는 이유는 여러 가지입니다. 바벨은 자바스크립트 트랜스컴파일러transcompiler이며, 최신 자바스크립트 코드를 하위 호환성을 보장하는 스크립트 코드로 변환하는 일을 주로 담당합니다.

하위 호환성이 보장된다면 어떤 웹 브라우저에서든 자바스크립트 코드를 실행할 수 있습니다.

만약 웹 앱이 반드시 인터넷 익스플로러 10, 11과 같은 오래된 브라우저를 지원해야 한다면 바벨이 큰 도움을 줄 수 있습니다.

바벨을 사용해서 ES6 또는 ESNext의 기능을 사용한 자바스크립트 코드를 빌드 시점에 인터넷 익스플로러와 호환되는 코드로 바꿀 수 있습니다.

별다른 노력 없이도 뛰어난 기능을 구식 브라우저에서 계속 사용할 수 있는 것이죠.

또한 ECMAScript 명세를 따르는 자바스크립트 코드는 급속도로 발전하고 있습니다.

사용해보고 싶은 훌륭한 기능이 발표되더라도 이를 실행할 웹 브라우저나 Node.js가 해당 기능을 지원하기까지 수년이 걸릴 수 있습니다.

그래서 ECMA 위원회에서 새로운 기능을 적용한다는 사실을 발표할 때마다 웹 브라우저를 만드는 회사나 Node.js 커뮤니티에서 해당 기능을 어떤 식으로 도입할지 계획을 세우고 사용자에게 로드맵을 공유하는 것이죠.

바벨을 사용하면 브라우저나 Node.js 등에서 지원하지 않는 새롭고 훌륭한 기능을 현재의 환경에서도 실행할 수 있습니다.

예를 들어 다음과 같은 코드를 생각해봅시다.

export default function() {

console.log("Hello, World!");

}

이 코드를 Node.js에서 실행하면 문법 오류 메시지가 출력됩니다. 자바스크립트 엔진이 아직 export default라는 키워드를 모르기 때문이죠. 이럴 때 바벨을 사용하면 다음과 같이 동일한 기능을 실행할 수 있는 ECMAScript 코드로 바꿔줍니다.

Node.js가 export default 키워드를 지원할 때까지는 이렇게 쓸 수 있겠죠.

"use strict";

Object.defineProperty(exports, "__esModule", {

value: true

});

exports.default = _default;

function _default() {

console.log("Hello, World!");

}

이렇게 바뀐 코드는 Node.js에서 아무런 문제 없이 실행됩니다.

Next.js의 바벨 설정을 커스터마이징하고 싶다면 프로젝트 최상위 디렉터리에 .babelrc 파일을 새로 만들면 됩니다.

해당 파일이 비어있으면 Next.js의 빌드 또는 개발 과정에서 에러가 발생하기 때문에 이 파일에는 최소한 다음과 같은 내용을 저장해두어야 합니다.

{

"presets": ["next/babel"]

}

이 내용은 Vercel 팀에서 Next.js 애플리케이션을 빌드하고 개발할 때 사용할 수 있는 설정을 미리 저장해둔 바벨 설정값입니다.

이제 ECMAScript 기능 중 파이프라인 연산자와 같은 실험적인 기능을 사용할 수 있도록 설정해봅시다.

파이프라인 연산자는 기본적으로 다음과 같이 코드를 작성할 수 있도록 해줍니다.

console.log(Math.random() * 10);

// 파이프라인 연산자를 사용하면 위 코드를 아래와 같이 바꿀 수 있습니다.

Math.random()

|> x => x * 10

|> console.log;

ECMAScript 내의 기술 위원회인 TC39에서 이 연산자를 공식적으로 채택하지는 않았지만 바벨 덕분에 지금 당장 사용해볼 수 있습니다.

Next.js 앱에서 파이프라인 연산자를 사용하고 싶다면 먼저 다음과 같이 npm으로 바벨 플러그인을 설치해야 합니다.

npm install --save-dev @babel/plugin-proposal-pipeline-operator @babel/core

그리고 .babelrc 파일을 다음과 같이 수정합니다.

{

"presets": ["next/babel"],

"plugins": [

[

"@babel/plugin-proposal-pipeline-operator",

{ "proposal": "fsharp" }

]

]

}

이제 개발 서버를 재시작하면 실험적인 기능을 사용해볼 수 있습니다.

Next.js 앱 개발 시 타입스크립트를 주 언어로 쓰고 싶다면 앞서 살펴본 것과 같은 방법으로 타입스크립트 전용 플러그인을 바벨 설정에 추가하면 됩니다.

개발하다 보면 바벨과 마찬가지로 기본 웹팩 설정을 커스터마이징해야 하는 경우도 생깁니다.

바벨이 최신 자바스크립트 코드를 받아서 하위 호환성을 보장하는 코드로 바꾸어준다면 웹팩은 특정 라이브러리, 페이지, 기능에 대해 컴파일된 코드를 전부 포함하는 번들을 만들어줍니다. 예를 들어 서로 다른 라이브러리에서 각각 한 개씩 세 개의 컴포넌트를 불러오는 페이지를 만들었다면 웹팩은 이들을 클라이언트가 받아서 실행할 수 있는 하나의 번들로 합쳐줍니다.

웹팩은 자바스크립트 파일, CSS, SVG 등 웹에서 사용하는 모든 자원에 대한 각기 다른 컴파일, 번들, 최소화 작업을 조율하고 처리해주는 일종의 인프라infrastructure라고 볼 수 있습니다.

SASS나 LESS 같은 CSS 전처리기preprocessor를 사용해서 애플리케이션의 스타일을 만들고 싶다면 웹팩 설정을 수정해서 SASS나 LESS 파일들을 분석 및 처리하여 CSS 파일들을 만들도록 해야 합니다. 이 과정은 바벨을 트랜스파일러transpiler로 사용해서 자바스크립트 코드를 변환하는 것과 비슷합니다.

CSS 전처리는 이후에 자세히 알아볼 것이며 우선은 Next.js에서 기본 웹팩 설정을 자유롭게 바꿀 수 있다는 점만 기억하기 바랍니다.

Next.js가 ‘설정보다 관습’이라는 취지 아래 만들어졌기 때문에 실제 애플리케이션 개발 과정에서 설정을 바꿀 일은 그렇게 많지 않습니다.

그보다는 적절한 코드 컨벤션을 따라서 개발하는 일이 더 많습니다. 애플리케이션 빌드 과정을 꼭 수정해야 한다면 대부분 next.config.js 파일의 기본값을 변경하는 것으로도 충분합니다. 이 파일을 프로젝트의 최상위 디렉터리에 만들고 객체를 익스포트하면 해당 내용은 Next.js의 기본 설정값을 덮어씁니다.

module.exports = {

// 변경할 설정값을 여기에 저장합니다.

}

기본 웹팩 설정을 바꾸고 싶다면 앞서 만든 객체의 webpack이라는 키에 새로운 속성값을 지정합니다.

예를 들어 웹팩 로더에 my-custom-loader라는 가상의 로더를 추가하고 싶다면 다음과 같이 설정을 변경하면 됩니다.

module.exports = {

webpack: (config, options) => {

config.module.rules.push({

test: /\.js/,

use: [

options.defaultLoaders.babel,

// 이 부분의 내용은 예시이기 때문에

// 실제로 사용하면 애플리케이션이 작동하지 않습니다.

{

loader: "my-custom-loader", // 사용할 로더 지정

options: loaderOptions, // 로더의 옵션 지정

},

],

});

return config;

},

}

이런 식으로 웹팩 설정을 추가하면 나중에 Next.js의 기본 설정과 합쳐집니다. 기본 설정을 지우거나 직접 바꾸는 것은 좋지 않습니다. 나중에 어떤 문제가 생길지 모르기 때문이죠. 그보다는 이렇게 기본 설정은 그대로 두고 추가로 설정값을 확장하거나 덮어쓰는 것이 훨씬 좋습니다.

정리하기

지금까지 리액트 앱과 Next.js의 차이점, Next.js와 다른 유명한 프레임워크의 장단점을 살펴보았습니다.

또한 바벨과 웹팩 설정을 수정하고 커스터마이징하는 방법과 자바스크립트 대신 타입스크립트로 애플리케이션을 개발하는 방법도 배웠습니다.

Next.js와 즐거운 여정 되시길 바랍니다.