👋 손에 익는 Next.js Part.1 정리하기

🌱 인프런에서 [손에 익는 Next.js] Part 1 - 공식 문서 훑어보기를 읽은 후 강의 내용을 정리했습니다.
필요한 부분에 대해서만 정리했기 때문에 부족한 부분이 있을 수 있습니다.

01. App Router

---

• App 폴더 아래 두면 알아서 파일 시스템을 기반으로 라우팅되는 것을 말한다.

02. 서버 컴포넌트

---

① 서버 컴포넌트 = React Server Component(RSC)

• RSC는 리액트 18에서 도입된 기술로, 이를 Next에서 사용할 때 "서버 컴포넌트"라고 부르는 것이다.
• Next.js에서 기본은 서버 컴포넌트이다.

② 서버 컴포넌트가 필요한 이유, 서버 컴포넌트의 장점

1. 데이터 패칭에서 성능상 이점 : 서버에서 데이터를 가져오니까 빠르다. 당연하다. 왜냐하면 물리적으로 보면 서버가 클라이언트보다 데이터베이스에서 더 가까우니까
2. 보안 상 이점 : 브라우저에서 관리해선 안되는 민감한 정보를 클라이언트에 두지 않고 서버에만 두니까
3. 캐싱 : 렌더링된 값을 캐싱해두고 있다 재사용하니까 여러 번 요청이 와도 이미 만들어진 결과를 내려주면 되니까
4. 자바스크립트 번들 크기 감소 : 서버 컴포넌트의 경우, 서버에서 렌더링까지 다 된 컴포넌트를 내려주므로 하이드레이션에 필요한 자바스크립 파일이 줄어들게 된다.

03. 클라이언트 컴포넌트

---

• 클라이언트 컴포넌트를 사용하려면 상단에 "use client"라고 명시 필요

🚨 클라이언트 컴포넌트 사용 시 주의할 점
→ 클라이언트 컴포넌트에서 서버 컴포넌트를 import할 수 없다.
→ 클라이언트 컴포넌트에서 서버 컴포넌트를 쓰고 싶을 땐, props로 넘겨주어야 한다.

"use client"

import { useState } from 'react';

export default function ExampleClientComponent({
	children,
} : {
	children : React.ReactNode
}) {
	const [count, setCount] = useState(0);

	return (
	<button onClick={() => setCount(count+1)}>
	{children}
	</button>
	)
}

// -> 이처럼 클라이언트 컴포넌트에서 서버 컴포넌트를 쓰고 싶다면 children과 같이 props로 전달해 사용해야 한다.

① 클라이언트 컴포넌트는 클라이언트에서만 렌더링되는 컴포넌트가 아니다.

• 클라이언트 컴포넌트는 기존의 Next.js가 pre-rendering이라는 방식으로 제공하던 방식으로 여전히 렌더링할 수 있다.
• 클라이언트 컴포넌트 = 클래식 컴포넌트라고 이해하면 좀 더 쉽게 이해할 수 있다.
• 클라이언트 컴포넌트도 SSR, SSG 같은 방식으로 렌더링 가능하다.
  → 즉 서버 컴포넌트와 마찬가지로, 서버에서 컴포넌트를 미리 렌더링해 둘 수 있다.

② 클라이언트 컴포넌트가 SSR이 된다면, RSC랑 뭐가 다른 걸까?

• 앞서 말했듯이 서버 클라이언트는 "데이터 패칭, 보안, 캐싱, 자바스크립트 번들 크기 줄어듬"의 강점이 있다.

③ 'use client' 최대한 뒤로 미루기

• 클라이언트 컴포넌트는 제일 말단에!
• Next.js에서는 클라이언트 컴포넌트를 최대한 트리의 끝에 위치하도록 두는 것이 좋다.

🧐 왜 클라이언트 컴포넌트가 트리의 끝에 위치하는 것이 좋을까?
→ 서버 컴포넌트를 최대한 활용하기 위해서 이다.

• 클라이언트 컴포넌트가 트리의 상위에 있으면, 하위에 있는 컴포넌트는 자식 요소로 전달되지 않은 이상 서버 컴포넌트를 활용하기 어렵다.
• 때문에 가능하면 클라이언트 컴포넌트를 트리의 끝에 두면 앱 전체에서 서버 컴포넌트의 비중을 늘릴 수 있다.
• 이는 결과적으로 번들 크기의 감소로 이어져 전체적인 성능 향상으로 이어진다.

④ 정리하자면,

1. 서버 컴포넌트는 서버에서 렌더링 되어진 React 컴포넌트이고, 클라이언트 컴포넌트는 Pre-render이 가능한 기존의 컴포넌트이다.

• 따라서 서버 컴포넌트와 클라이언트 컴포넌트를 적절히 조합해 사용하는 것이 중요하다.
• 이때 되도록이면 클라이언트 컴포넌트는 트리의 끝에 위치하도록 노력하는 것이 좋다.

2. 서버 컴포넌트는 서버에서 미리 렌더링되었기 때문에 전체적인 JS 번들 크기가 감소하므로 First View를 개선할 수 있으며, TTI에서도 간접적인 영향을 줄 수 있다.

✏️ TTI(Time To Interact)

• 사용자가 클릭을 하거나 인터렉션이 가능하게 되는데 걸리는 시간

✏️ TTV(Time To View)

• 사용자가 웹사이트를 보는데까지 걸리는 시간

04. Next.js의 오해와 진실

---

① SSR 방식과 === 서버 컴포넌트 방식?

SSR 방식은 서버 컴포넌트와 다른 방식이다.
→ 서버에서 컴포넌트를 렌더링한다는 점에선 동일하지만, 렌더링의 결과값과 동작 방식이 다르다.

❶ SSR

• Pre-rendering 방식으로 서버에서 HTML을 만들어낸다. 이후 클라이언트로 전달된 JS 번들 파일과 수화되는 과정을 거쳐 React 컴포넌트로 사용된다.
• 이것이 기존의 React 컴포넌트이며, 이를 클라이언트 컴포넌트라고 한다.

❷ 서버 컴포넌트

• 서버 컴포넌트는 JSON과 유사항 형태가 만들어진다. 서버 컴포넌트는 그 자체로 React 컴포넌트이기 때문에 별도의 JS 번들 없이 브라우저에서 컴포넌트로 사용된다.
• 이는 새로운 컴포넌트이고, React Server Component(RSC) 라고 한다.

❸ SSR + RSC

• 두 가지의 렌더링 방식을 함께 사용하는 대표적인 경우로는, 서버 컴포넌트가 children요소로 클라이언트 컴포넌트에게 전달되는 경우이다.
• 이때 모든 컴포넌트가 서버에서 렌더링되어 브라우저로 전달되게 된다.

📢 Hydration이란

• Hydration이란 HTML 코드가 React 컴포넌트로 인식되도록 JavaScript 코드와 매칭시키는 단계이다.
• 서버 컴포넌트는 서버에서 Pre-rendering 방식으로 HTML을 만들어 전달하기 때문에 Hydration 단계가 없다.
  - 서버 컴포넌트는 서버에서 내려올 때 RSC Payload라는 일종의 JSON으로 전달되며 곧장 React 컴포넌트로 사용될 수 있다.

05. Routing

---

① NEXT.JS는 폴더 이름을 따라 URL Patch를 정의할 수 있다.

• Next.js에서는 라우트를 표현하는 폴더인 경우엔 라우트 세그먼트(Route Segment) 라고 부른다.
  

② 약속된 파일 이름

• Next.js에서는 상황에 맞는 UI를 정의할 때 쓰는 파일명이 미리 정해져있다.
  

위 약속된 파일명에 따라 파일 이름을 지정해 세그먼트(폴더) 안에 정의하면 Next.js가 다음과 같이 알아서 React 컴포넌트를 배치해준다.

③ 동적으로 변할 수 있는 URL Patch 만들기

• Next.js에서는 Dynamic Routes라는 기능을 제공한다.

export default function Page({ params }: { params: { id: string } }) {
	return <div>My Post: {params.id}</div>
}

✏️ Dynamic Routes

• Dynamic Routes는 파일 이름을 대괄호로 묶어주는 걸 원칙으로 한다.
• 사용방법은 대괄호 안에 지정한 이름을 Page 컴포넌트의 인자로 받을 수 있다.

06. 페이지간 이동

---

① Link 컴포넌트 사용하기

• Next.js에서 제공하는 Link 컴포넌트는 HTML의 a 태그의 확장된 버전이다.

import Link from "next/link";

export default function Page() {
	return <Link href="/dashboard">Dashboard</Link>
}

② useRouter 사용하기

• 이때 주의할 점은 "useRouter"를 사용할 땐 해당 컴포넌트를 클라이언트 컴포넌트로 작성해줘야 한다.

'use client';
import { useRouter } from "next/navigation";

export default function Page() {
	const router = useRouter();

	return (
	<button onClick={() => router.push('/dashboard')}>
		Dashboard
	</button>
	)
}

📢 Link / Router에 대한 더 자세한 내용은 별도 포스팅에서 확인할 수 있다!

07. 스타일링 with CSS Modules

---

① CSS Modules

• CSS Modules은 CSS 클래스의 이름 중복 문제를 피할 수 있는 지역 스코프의 스타일 방식이다.
• .module.css 확장자로 이름을 붙여 스타일을 정의하고 컴포넌트에서 가져와 사용할 수 있다.

// styles.modules.css

.dashboard {
  padding: 24px;
}

// layout.tsx

import styles from './styles.module.css'
 
export default function DashboardLayout({
  children,
}) {
  return <section className={styles.dashboard}>{children}</section>
}

08. 데이터 패칭, 캐싱, 재검증

---

📂 데이터 패칭(Data Fetching)

Next.js에서 다이나믹하게 어떤 id 를 통해 데이터를 받아왔을 때, 이후에 해당 데이터를 동적으로 받아오지 못한다면 동적인 페이지를 그릴 수 없다.
그렇기 때문에 데이터 패칭을 "얼마나 미려하게 처리했는가", 그리고 "데이터 패칭에서 얼마나 속도를 많이 줄일 수 있는가" 에 따라 유저 경험(UX) 및 웹 애플리케이션에 많은 영향을 끼친다.

📢 데이터 패칭은 서버와 클라이언트 모두에서 가능하지만, NEXT.js에서는 보안과 성능상의 이점이 많기 때문에 서버에서 데이터를 패칭하는 것을 권장한다.

또 주의할 점은 Next는 패칭된 데이터, 즉 동적으로 받아온 데이터를 캐싱하고 있다는 점이다.

📂 데이터 캐싱(Caching)

기본적으로 fetch에 의해 발생한 요청은 자동으로 캐싱된다. 따라서 여러번 요청해도 저장해둔 갓을 반환해 불필요한 API 호출을 줄여준다.
즉 캐시 데이터는 서버에 저장되어 빌드 타임 혹은 이후 요청에도 재사용할 수 있는 것이다.

// fetch의 cache 파라미터의 기본 값 : 'force-cache'  
fetch('https://...', { cache: 'force-cache' })

데이터 캐싱은 아래 그림에서 보라색 영역에 해당한다.

📂 데이터 재검증 (Data Revalidating)

캐싱된 데이터가 아닌 최신의 데이터를 원한다면, 데이터 재검증을 통해 캐싱된 데이터를 무효화할 수 있다.
이때 캐싱된 데이터를 재검증하는 방법에는 두 가지 방법을 사용할 수 있다.

① 시간 기반 재검증(Time-based revalidation)

parameter의 value로 정의한 특정 시간이 지난 후에 자동으로 데이터를 재검증하는 방법이다.

// 3600초(60분) 동안 유효한 fetch
fetch('https://...', { next: { revalidate: 3600 } })

1. 이때 시간이 지난 캐시 데이터는 신선하지 않은 데이터로 판별될 뿐, 삭제되지는 않는다.
2. 시간 기반 재검증은 데이터가 자주 변경되지 않고, 신선도가 중요하지 않은 경우에 유용하다.

1. 해당 URL로 호출된 데이터는 "60초 동안 유효한 데이터"로 선언한 함수를 만든다.
2. 아직 60초가 지나지 않은 경우, 위 함수를 재호출하지 않고 캐싱된 데이터를 전달한다.
3. 🚨 60초가 지난 경우, 유효시간이 지났기 때문에 위 함수를 다시 호출한다.

🚨 주의할 점!

이때 60초 후에 바로 새로운 데이터를 가져오는 것이 아니라, 60초가 지난 후 데이터를 요청했을 때 해당 데이터가 유효하지 않다는 것을 알게되는 것 뿐이다.
실제로 Revalidate가 일어난 이후에 데이터를 호출해야 신선한 데이터를 가져올 수 있다.

❶ 60초가 지난 후 첫번째 호출 때

"지금 주는 데이터는 이미 유효시간이 지난 데이터야, 즉 유효하지 않아. 하지만 일단 예전 데이터는 이거였어"라고 보내준다.

이후 Revalidate 해 다시 유효한 데이터를 가져온다.

❷ 두번째 호출 때

60초 이후 두 번째 호출부터 신선한 데이터를 볼 수 있게 된다.

② On-demand 재검증

demand, 즉 수요가 있을 때 재검증하는 방식으로, 시간 기반과 달리 수동으로 데이터를 재검증할 수 있는 방법이다.

태그(tag)혹은 경로(path)를 기반으로 특정 데이터 그룹을 일괄 재검증할 수 있다. 이때 재검증된 캐시 데이터는 삭제된다.

On-demand 재검증 방법은 즉각적으로 최신 데이터를 확보해야하는 경우 유용하다.

// 데이터에 태그를 달아둔다.
fetch('https://...', { next: { tags: ['collection'] } })

// 태그된 데이터를 재검증한다.
revalidateTag('collection')

💡 그림과 같이 재검증이 필요할 때 Revalidate 태그 함수를 호출하고, 매개변수로 태그 값을 전달하면 해당 캐시가 재검증된다.

📁 참고 문서

• SSR, CSR, SSG, TTV, TTI 개념 정리
• Next.js 공식문서 - App Router / Routing