React 프로젝트를 하면, 십중팔구는 Next.js를 쓰게 된다. 최근에 블로그를 개편하면서 create-next-app을 돌렸는데, 13버전으로 업데이트 되면서 눈에 띄는 변경점이 있는 듯 하다.

그 중 몇몇 변경점은 기존 사용법과 상이해져서 쓰는데 살짝 애를 좀 먹었는데, 이러한 변경점에 대해 다뤄보고자 한다.

13버전이 되면서 정의된 변경점은 아래와 같다.

• app Directory: 더 쉽고, 더 빠르고, 더 적은 클라이언트 JavaScript
  • Layouts
  • React Server Components
  • Streaming
• Turbopack: 최대 700배 이상 빠른 Rust 기반 Webpack 적용
• New next/image: 네이티브 브라우저의 lazy loading 기법으로 더욱 빨라진 이미지 컴포넌트
• New @next/font: Zero Layout Shift를 위한 셀프 호스팅 폰트
• Improved next/link: 자동 a 태그로 단순화된 링크 API

Layout Shift란, 클라이언트의 렌더링 과정에서 사용자에게 렌더링 이전의 UI가 보여지는 현상을 의미한다. 비슷한 용어로 FOUC(Flash Of Unstyled Content)가 있다.
비동기 로딩 자원(폰트, 이미지 등)의 지연에 의해 발생하며, 사용자에게 의도하지 않은 UI를 보여주어 사이트의 신뢰도 및 미관을 해칠 수 있다.

이 중 몇 가지는 내부적인 성능 향상이라 코드 사용상의 변경점은 없다.

12버전부터 experimental 기능으로 제공됐던 app Directory 기능이 메인으로 올라온 것 같다. 그 당시 사용해볼까 하다가 실험적 기능이라길래 넘겼던 기억이 있다.

13버전에서 가장 크게 체감되는 변경점이다. 이 항목은 주요 기능 중 하나인 라우팅에 대한 변경점이다.

아래의 예시는 TypeScript를 기준으로 한다.

기존

기존 프로젝트 구조는 아래와 같다.

BASH
1
2
3
4
5
6
7
📦src
 ┣ 📂page
 ┃ ┣ 📂mypage
 ┃ ┃ ┣ 📜info.tsx # /mypage/info
 ┃ ┃ ┗ 📜update.tsx # /mypage/update
 ┃ ┣ 📜index.tsx # /
 ┃ ┗ 📜login.tsx # /login

위와 같이 page라는 폴더에 페이지 파일을 생성하는 형태다. 파일의 이름이 곧 URL이 된다. page/ 하위엔 반드시 페이지 컴포넌트만 있어야하므로, 서브 컴포넌트나 디자인같은 파일이 위치해선 안 된다는 단점이 있다.

변경

Next.js 13의 app Directory를 적용하면 아래와 같은 구조가 기본이 된다.

BASH
1
2
3
4
5
6
7
8
9
10
📦src
 ┣ 📂app
 ┃ ┣ 📂login
 ┃ ┃ ┗ 📜page.tsx # /login
 ┃ ┣ 📂mypage
 ┃ ┃ ┣ 📂info
 ┃ ┃ ┃ ┗ 📜page.tsx # /mypage/info
 ┃ ┃ ┗ 📂update
 ┃ ┃    ┗ 📜page.tsx # /mypage/update
 ┃ ┗ 📜page.tsx # /

파일명이 URL이였던 기존과 달리 폴더명이 URL이 되며, 폴더명 하위에는 반드시 page 파일이 있어야한다.

변경된 라우팅에선, 파일명마다 동작하는 역할이 정해져 있는데, 각각의 역할은 아래와 같다.

각 폴더 하위에 위와 같이 정의된 파일명을 추가하면, 별도의 연결작업 없이 파일을 선언하는것 만으로도 위와 같은 동작을 수행할 수 있다.

Next.js의 공식문서에서 각 컴포넌트의 동작을 위와 같이 묘사한다. Layout 컴포넌트와 Template 컴포넌트가 감싸지고, 선언된 로딩, 에러 컴포넌트들이 묶인 뒤에 비로소 실제 페이지 컴포넌트가 렌더링된다.

특히 이 중에서 app 바로 하위에 위치하는 layout 컴포넌트는 모든 페이지에 공통으로 적용되는 전역 레이아웃이다. 이전 버전의 _app, _document의 역할을 대체한다.

layout, loading 등, 위 표에서 현재 및 하위라고 명시된 컴포넌트들은 전부 하위 경로에도 적용되는 컴포넌트들이다.

하위 컴포넌트는 위와 같이 렌더링된다. 부모의 공유 컴포넌트들이 같이 렌더링되는 것을 확인할 수 있다. 덮어씌우는 게 아니니 주의하자.

이를 코드로 보면 아래와 같다.

• app/layout.tsx

TSX
1
2
3
4
5
6
7
8
9
10
// app/layout.tsx
export default function Layout({children}: PropsWithChildren) {
  return (
    <div style={{backgroundColor: '#8F85ED', padding: 20}}>
      <p>app/layout</p>

      {children}
    </div>
  )
}

• app/template.tsx

TSX
1
2
3
4
5
6
7
8
9
10
// app/template.tsx
export default function Template({children}: PropsWithChildren) {
  return (
    <div style={{backgroundColor: '#8B9DF7', padding: 20}}>
      <p>app/template</p>

      {children}
    </div>
  )
}

• app/page.tsx

TSX
1
2
3
4
5
6
7
8
// app/page.tsx
export default function Page() {
  return (
    <div style={{backgroundColor: '#8AAFE1', padding: 20}}>
      <p>app/page.tsx</p>
    </div>
  )
}

결과는 아래와 같이 렌더링된다. (CSS는 임의 적용)

위의 그림과 같이, <Layout /> 컴포넌트가 가장 바깥에 위치하고, 그 자식으로 동일 경로의 <Template /> 컴포넌트가 위치한다. 이후 실제 <Page /> 컴포넌트가 렌더링되어 하나의 페이지가 완성된다.

만약, app/ 하위에 main이라는 폴더를 두어 하위 경로를 생성하면 어떻게 표현될까?

main/ 폴더에 아래와 같은 파일이 있다고 가정하자.

• app/home/layout.tsx

TSX
1
2
3
4
5
6
7
8
9
10
// app/home/layout.tsx
export default function Layout({children}: PropsWithChildren) {
  return (
    <div style={{backgroundColor: '#ED8774', padding: 20}}>
      <p>app/home/layout</p>

      {children}
    </div>
  )
}

• app/home/template.tsx

TSX
1
2
3
4
5
6
7
8
9
10
// app/home/template.tsx
export default function Template({children}: PropsWithChildren) {
  return (
    <div style={{backgroundColor: '#F7A079', padding: 20}}>
      <p>app/home/template</p>

      {children}
    </div>
  )
}

• app/home/page.tsx

TSX
1
2
3
4
5
6
7
8
// app/home/page.tsx
export default function Page() {
  return (
    <div style={{backgroundColor: '#E1A97A', padding: 20}}>
      <p>app/home/page.tsx</p>
    </div>
  )
}

부모의 공유 컴포넌트 <Layout />, <Template />가 상위에 렌더링되고, 그 하위에 main/ 폴더의 요소들이 렌더링되는 걸 확인할 수 있다.

이 구조를 잘 활용하면 서비스 전역에 적용해야할 레이아웃을 쉽게 적용할 수 있으며, 각 페이지 주제별로 URL을 그룹화해서 레이아웃을 짜기에도 용이하다. 또한, 이런식으로 공유 컴포넌트를 알맞게 활용하면, 불필요한 컴포넌트의 렌더링을 방지할 수 있다.

다만 이런 구조 상 주의할 점이 하나 있다면, 상위에 선언된 공유 컴포넌트를 하위에서 임의로 제외할 수 없는 것 같다. 즉, 특정 하위 경로에선 부모의 layout.tsx 혹은 template.tsx를 제외시킬 수 없으니, 공유 컴포넌트를 설계할 때, 이러한 케이스가 발생하지 않거나, 발생해도 영향을 미치지 않도록 잘 설계해야할 것 같다.

이 밖의 더 자세한 내용은 Next.js 13 라우팅 공식문서에서 확인하자.

Next.js의 컴포넌트는 서버와 클라이언트 컴포넌트로 구분된다. 각 컴포넌트의 구분에 따라 수행 가능한 역할이 조금씩 다르다.

결국 해당 컴포넌트의 렌더링 방식이 SSR이냐, CSR이냐 명시하는 것이다. 이전 버전의 경우, 별도의 선언 없이, getServerSideProps, getStaticProps 같은 메서드의 사용에 따라 구분했었다.

13 버전부터는 컴포넌트 파일 상단에 use client를 작성하여 구분한다. 기본은 서버 컴포넌트로, 아무것도 명시하지 않으면 서버 컴포넌트로 동작한다.

이를 코드로 보면 아래와 같다.

TSX
1
2
3
4
5
6
// 서버 컴포넌트 (명시하지 않아도 됨)

export default function Component(): ReactNode
{
    // ...
}

TSX
1
2
3
4
5
6
7
// 클라이언트 컴포넌트
'use client'

export default function Component(): ReactNode
{
    // ...
}

Next.js 설치 시 기본적으로 포함되는 ESLint의 eslint-config-next 설정 플러그인을 활용하면, 각 컴포넌트마다 불가능한 로직을 잡아준다. 이를테면 서버 컴포넌트에서 useState, 브라우저 이벤트의 사용을 감지하고 경고하는 식.

컴포넌트에 대한 자세한 정보는 Next.js 13 렌더링 공식문서에서 확인하자.

위 두 변경점과 달리, 이건 추가된 기능같은데, 폰트 적용의 편의성을 높인 기능이다. next/font를 활용하면, 기존의 방식에 비해 폰트를 손쉽게 적용할 수 있다.

지원하는 공식 서비스는 아직 Google Font 하나다. 그 밖에 로컬 폰트파일의 연결도 지원한다.

Google Font는 아래와 같이 선언해서 사용할 수 있다.

TSX
1
2
3
4
5
6
7
8
9
10
11
12
13
import { Noto_Sans_KRr } from 'next/font/google';

export const notoSans = Noto_Sans_KR({ subsets: [ 'latin' ], weight: [ '100', '300', '400', '500', '700', '900' ] });

export default function Component(): ReactNode
{
    return (
        <div>
            <div className={notoSans.className}>className 적용</div>
            <div style={{ fontFamily: notoSans.style.fontFamily }}>font-family 적용</div>
        </div>
    );
}

위 코드는 유명한 한글 글꼴 중 하나인 Noto Sans KR을 적용한 예시다.

className으로 적용하는 방식과 font-family로 적용하는 방식 두 가지가 있다.

폰트 파일을 로컬 혹은 CDN으로 받아 CSS를 적용하는 것보다 훨씬 간단하여, Google Font에서 원하는 폰트를 고르고 이를 next/font로 찾아 적용하면 된다.

next/font의 가장 큰 단점은 Google Font 이외에 지원하는 서비스가 아직 없다는 것이다. 다행히, 로컬 폰트도 지원해주기 때문에, Google Font에 등록되지 않은 폰트도 사용이 가능하다.

TSX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
import localFont from 'next/font/local';

const pretendard = localFont({
    src: [
        {
            path: './pretendard-regular.otf',
            weight: 'normal',
            style: 'normal',
        },
        {
            path: './pretendard-bold.otf',
            weight: 'bold',
            style: 'normal',
        },
        {
            path: './pretendard-italic.otf',
            weight: 'normal',
            style: 'italic',
        },
    ],
});

export default function Component(): ReactNode
{
    return (
        <div>
            <div className={pretendard.className}>className 적용</div>
            <div style={{ fontFamily: pretendard.style.fontFamily }}>font-family 적용</div>
        </div>
    );
}

위와 같이 폰트의 경로에 직접 접근하여 사용이 가능하다.

폰트에 대한 더욱 자세한 정보는 Next.js 13 폰트 공식문서에서 확인하자.