
## 데이터 캐시란


App Router의 데이터 캐시는 서버에서 가져온 데이터를 저장하고 재사용하는 메커니즘이다. 동일한 데이터를 반복해서 외부 API나 데이터베이스에서 가져오는 대신, 한 번 가져온 데이터를 서버 메모리에 저장해두고 다음 요청에서 빠르게 응답할 수 있다.


데이터 캐시를 사용하려면 `fetch` API를 사용해야 한다. Next.js는 Web API의 표준 fetch를 확장하여 다양한 캐싱 옵션을 제공한다.


## fetch API와 캐싱 옵션


Next.js의 fetch는 `cache`와 `next` 옵션을 통해 캐싱 동작을 제어할 수 있다.


```javascript
// 기본 사용법
const res = await fetch('<https://api.example.com/data>', {
  cache: 'force-cache',  // 캐싱 전략
  next: {
    revalidate: 60,  // 재검증 주기
    tags: ['posts']  // 캐시 태그
  }
});
```


각 옵션은 데이터의 특성과 업데이트 빈도에 따라 선택한다.


## no-store - 캐싱 비활성화


데이터 페칭 결과를 저장하지 않는다. 매 요청마다 서버에서 새로운 데이터를 가져온다.


```javascript
async function RealTimePrice() {
  const res = await fetch('<https://api.example.com/stock-price>', {
    cache: 'no-store'
  });
  const data = await res.json();

  return <div>현재 가격: {data.price}원</div>;
}
```


Next.js 서버가 브라우저로부터 접속 요청을 받으면 사전 렌더링을 진행하게 되는데, `no-store`로 설정된 fetch는 캐시를 무시하고 바로 원본 서버로 요청을 보낸 뒤 브라우저에 응답한다.


Next.js 15부터는 data cache의 기본값이 `no-store`로 변경되었다. 이전 버전에서는 `force-cache`가 기본값이었지만, 최신 데이터를 제공하는 것이 더 중요하다는 판단에 따라 기본 동작이 바뀌었다.


### 사용 시나리오

- 실시간 주식 가격, 환율 정보
- 사용자별로 다른 데이터 (개인화된 콘텐츠)
- 자주 변경되는 데이터 (뉴스, 댓글)

## force-cache - 영구 캐싱


요청의 결과를 무조건 캐싱한다. 한 번 호출된 이후에는 재배포하거나 수동으로 캐시를 초기화하기 전까지 다시 호출되지 않는다.


```javascript
async function StaticContent() {
  const res = await fetch('<https://api.example.com/terms>', {
    cache: 'force-cache'
  });
  const data = await res.json();

  return <div>{data.content}</div>;
}
```


첫 번째 요청에서는 cache miss가 발생하지만, 서버에서 데이터를 가져온 후 캐시에 저장(set)한다. 두 번째 요청부터는 cache hit이 발생하여 캐시된 데이터를 즉시 반환한다.


```plain text
1번째 요청: Miss → 서버 요청 → Set (캐시 저장)
2번째 요청: Hit → 캐시된 데이터 반환
3번째 요청: Hit → 캐시된 데이터 반환
```


### 사용 시나리오

- 거의 변경되지 않는 데이터 (이용약관, 회사 소개)
- 정적 콘텐츠 (블로그 글, 제품 설명)
- 외부 API 호출 비용이 높은 경우

## revalidate - 주기적 재검증


특정 시간을 주기로 캐시를 업데이트한다. [[사전 렌더링 방식 - SSR, SSG, ISR|Page Router의 ISR 방식]]과 유사하게 동작한다.


```javascript
async function ProductList() {
  const res = await fetch('<https://api.example.com/products>', {
    next: { revalidate: 3600 }  // 1시간마다 재검증
  });
  const products = await res.json();

  return (
    <ul>
      {products.map(p => <li key={p.id}>{p.name}</li>)}
    </ul>
  );
}
```


동작 과정은 다음과 같다.


```plain text
0초: 첫 요청 → 서버 요청 → 캐시 저장 (fresh)
30초: 두 번째 요청 → 캐시 반환 (fresh)
3600초: 캐시가 stale로 변경
3601초: 요청 → 캐시 반환 (stale) + 백그라운드에서 재검증 시작
3605초: 재검증 완료 → 캐시 업데이트 (fresh)
3610초: 요청 → 새로운 캐시 반환 (fresh)
```


정해진 주기(`revalidate` 시간)가 지나면 캐시가 stale 상태가 된다. 이 상태에서 요청이 들어오면 일단 오래된 캐시를 반환하고, 백그라운드에서 데이터를 새로 가져온다. 다음 요청부터는 업데이트된 데이터를 받을 수 있다.


### 사용 시나리오

- 자주는 아니지만 가끔 업데이트되는 데이터 (제품 목록, 카테고리)
- 실시간성이 중요하지 않은 데이터 (통계, 인기 게시물)
- 외부 API 호출을 줄이면서도 적절한 최신성을 유지하고 싶을 때

## tags - 온디맨드 재검증


캐시에 태그를 붙여서 원하는 시점에 특정 태그의 캐시를 업데이트할 수 있다.


```javascript
// 데이터 페칭
async function BlogPost({ id }) {
  const res = await fetch(`https://api.example.com/posts/${id}`, {
    next: { tags: ['posts', `post-${id}`] }
  });
  const post = await res.json();

  return <article>{post.content}</article>;
}
```


위 코드에서 fetch 요청에 `tags: ['posts', 'post-${id}']`를 지정했다. 이제 다른 곳에서 캐시를 수동으로 무효화할 수 있다.


```javascript
// app/api/revalidate/route.js
import { revalidateTag } from 'next/cache';

export async function POST(request) {
  const { tag } = await request.json();

  revalidateTag(tag);  // 특정 태그의 캐시 무효화

  return Response.json({ revalidated: true });
}
```


`revalidateTag('posts')`를 호출하면 'posts' 태그가 붙은 모든 캐시가 즉시 무효화되고, 다음 요청에서 새로운 데이터를 가져온다.


### 사용 시나리오

- CMS에서 콘텐츠 수정 후 즉시 반영
- 관리자가 제품 정보를 업데이트한 경우
- 사용자가 댓글을 작성한 직후
- Webhook을 통해 외부 시스템 변경 감지

### revalidatePath와의 차이


```javascript
import { revalidatePath } from 'next/cache';

// 특정 경로의 캐시 무효화
revalidatePath('/blog/post-1');

// 특정 태그의 캐시 무효화 (더 세밀한 제어)
revalidateTag('post-1');
```


`revalidatePath`는 페이지 단위로 캐시를 무효화하는 반면, `revalidateTag`는 fetch 요청 단위로 더 세밀하게 제어할 수 있다. 하나의 페이지에 여러 fetch 요청이 있을 때 특정 요청만 선택적으로 무효화하려면 태그를 사용한다.


## 실전 활용 패턴


### 페이지별로 다른 전략 사용


```javascript
// 홈페이지 - 자주 변경되는 데이터
async function HomePage() {
  const news = await fetch('/api/news', { cache: 'no-store' });
  const popular = await fetch('/api/popular', { next: { revalidate: 300 } });

  return (
    <div>
      <NewsList data={news} />
      <PopularPosts data={popular} />
    </div>
  );
}
```


하나의 페이지에서도 데이터의 특성에 따라 다른 캐싱 전략을 조합할 수 있다. 실시간 뉴스는 `no-store`로 매번 새로 가져오고, 인기 게시물은 5분마다 업데이트한다.


### 캐시 전략 선택 가이드


```plain text
데이터 변경 빈도 및 중요도에 따른 선택

실시간 필수 → no-store
거의 변경 안됨 → force-cache
주기적 업데이트 → revalidate (시간 지정)
이벤트 기반 업데이트 → tags + revalidateTag
```


캐싱은 성능과 최신성 사이의 트레이드오프다. 데이터의 특성과 사용자 경험을 고려하여 적절한 전략을 선택해야 한다.



Data Cache

App Router 데이터 캐시


## React Server Component란


React Server Component(RSC)는 서버에서 렌더링되는 React 컴포넌트다. Next.js App Router는 기본적으로 모든 컴포넌트를 Server Component로 취급한다.


기존 React 앱은 모든 컴포넌트가 브라우저에서 실행되었다. Server Component는 서버에서 렌더링을 완료한 뒤 결과만 클라이언트로 보낸다. 이를 통해 JavaScript 번들 크기를 줄이고 초기 로딩 속도를 개선할 수 있다.


## 왜 필요한가


기존 React 앱에서는 데이터를 가져오기 위해 다음과 같은 과정을 거친다.

1. 브라우저가 빈 HTML을 받는다
2. JavaScript 번들을 다운로드하고 실행한다
3. 컴포넌트가 마운트되면 `useEffect`로 API를 호출한다
4. 데이터를 받아서 화면을 업데이트한다

이 과정에서 사용자는 로딩 상태를 보게 되고, JavaScript 번들 크기가 커질수록 초기 로딩이 느려진다.


Server Component는 이 문제를 해결한다. 서버에서 데이터를 가져오고 렌더링까지 완료한 뒤 결과만 보내므로, 브라우저는 즉시 컨텐츠를 표시할 수 있다.


## Server Component의 장점


Server Component는 다음과 같은 장점을 제공한다.

- 데이터 소스에 가까운 위치에서 데이터를 가져온다. 서버는 데이터베이스나 내부 API와 같은 네트워크에 있으므로 데이터 조회가 빠르다.
- **클라이언트로 전송하는 JavaScript 크기를 줄인다.** 서버에서만 실행되는 코드는 브라우저로 보내지 않는다.
- 초기 페이지 로딩이 빠르다. HTML이 서버에서 생성되어 오므로 First Contentful Paint가 개선된다.
- 보안이 강화된다. API 키나 토큰 같은 민감한 정보를 서버에만 두고 사용할 수 있다.

## Server Component의 특징


Server Component에서는 다음과 같은 작업을 할 수 있다.


```typescript
import { db } from '@/lib/database'

export default async function ProductList() {
  // 데이터베이스 직접 조회
  const products = await db.query('SELECT * FROM products')

  return (
    <ul>
      {products.map(product => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  )
}
```


위 코드에서 컴포넌트를 `async` 함수로 선언하고 데이터베이스를 직접 조회한다. 이 코드는 서버에서만 실행되므로 데이터베이스 연결 정보가 클라이언트에 노출되지 않는다.


Server Component는 컴포넌트 함수 자체를 `async`로 만들 수 있다. 별도의 데이터 페칭 함수 없이 컴포넌트 내부에서 바로 비동기 작업을 수행할 수 있다.


## Server Component의 제약사항


Server Component는 서버에서만 실행되기 때문에 클라이언트 전용 기능을 사용할 수 없다. 다음과 같은 것들은 Server Component에서 사용할 수 없다.

- 상태 관리 훅: `useState`, `useReducer`
- 생명주기 훅: `useEffect`, `useLayoutEffect`
- 이벤트 핸들러: `onClick`, `onChange`
- 브라우저 전용 API: `window`, `localStorage`, `document`
- 사용자 정의 훅: 위 기능들을 사용하는 커스텀 훅
- React Context: `useContext`

예를 들어 Server Component에서 `useEffect`를 사용하려고 하면 다음과 같은 에러가 발생한다.


```plain text
Error: useEffect only works in Client Components. Add the "use client" directive at the top of the file to use it.
```


이런 기능이 필요하다면 해당 컴포넌트를 Client Component로 만들어야 한다. 파일 최상단에 `'use client'`를 추가하면 된다.


```typescript
// 에러 발생
export default function ProductList() {
  useEffect(() => {
    console.log('마운트됨')
  }, [])

  return <div>상품 목록</div>
}
```


```typescript
// ✓ 정상 작동
'use client'

export default function ProductList() {
  useEffect(() => {
    console.log('마운트됨')
  }, [])

  return <div>상품 목록</div>
}
```


Server Component는 HTML을 생성하는 데 집중하고, 인터랙션이 필요한 부분은 Client Component로 분리하는 것이 권장된다.


## Client Component란


하지만 모든 것을 Server Component로 만들 수는 없다. 사용자와의 상호작용, 상태 관리, 브라우저 API 사용 등은 클라이언트에서만 가능하다.


Client Component는 브라우저에서 실행되는 React 컴포넌트다. 다음과 같은 기능을 사용할 때는 Client Component가 필요하다.

- `useState`, `useReducer` 같은 상태 관리
- `useEffect`, `useLayoutEffect` 같은 생명주기 훅
- `onClick`, `onChange` 같은 이벤트 핸들러
- `window`, `localStorage` 같은 브라우저 전용 API
- 사용자 정의 훅

## 'use client' 디렉티브


Client Component를 만들려면 파일 최상단에 `'use client'` 디렉티브를 추가한다.


```typescript
'use client'

import { useState } from 'react'

export default function LikeButton() {
  const [likes, setLikes] = useState(0)

  return (
    <button onClick={() => setLikes(likes + 1)}>
      좋아요 {likes}
    </button>
  )
}
```


`'use client'`는 서버와 클라이언트 코드 사이의 경계를 선언한다. 이 디렉티브가 있는 파일과 그 파일이 import하는 모든 모듈은 클라이언트 번들에 포함된다.


`'use client'`를 추가하지 않으면 기본적으로 Server Component로 동작한다. Next.js App Router는 Server Component를 기본값으로 사용한다.


## 언제 무엇을 사용할지


다음 표는 어떤 상황에 어떤 컴포넌트를 사용해야 하는지 정리한 것이다.


| 작업                               | Server Component | Client Component |
| -------------------------------- | ---------------- | ---------------- |
| 데이터 가져오기                         | ✓                |                  |
| 백엔드 리소스 직접 접근                    | ✓                |                  |
| 민감한 정보를 서버에 보관                   | ✓                |                  |
| 큰 의존성을 서버에 유지                    | ✓                |                  |
| 상태 관리 (`useState`, `useReducer`) |                  | ✓                |
| 생명주기 훅 (`useEffect`)             |                  | ✓                |
| 이벤트 핸들러                          |                  | ✓                |
| 브라우저 전용 API                      |                  | ✓                |
| 사용자 정의 훅                         |                  | ✓                |


기본적으로 Server Component를 사용하고, 인터랙션이 필요한 부분만 Client Component로 분리하는 것이 권장된다.


## Server Component와 Client Component 조합하기


Server Component와 Client Component는 함께 사용할 수 있다.


### Server Component에서 Client Component로 데이터 전달하기


Server Component는 Client Component에 props로 데이터를 전달할 수 있다. 단, props는 직렬화 가능한 값이어야 한다.


```typescript
// app/page.tsx (Server Component)
import LikeButton from './like-button'

export default async function PostPage({ params }) {
  const post = await getPost(params.id)

  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
      <LikeButton initialLikes={post.likes} />
    </article>
  )
}
```


```typescript
// app/like-button.tsx (Client Component)
'use client'

import { useState } from 'react'

export default function LikeButton({ initialLikes }) {
  const [likes, setLikes] = useState(initialLikes)

  return (
    <button onClick={() => setLikes(likes + 1)}>
      좋아요 {likes}
    </button>
  )
}
```


위 코드에서 Server Component인 `PostPage`는 서버에서 포스트 데이터를 가져온다. 그리고 초기 좋아요 수를 `LikeButton`에 전달한다. `LikeButton`은 Client Component이므로 브라우저에서 상태를 관리하며 사용자의 클릭에 반응한다.


### Client Component 안에 Server Component 넣기


Client Component는 직접적으로 Server Component를 import할 수 없다. 하지만 `children` prop을 통해 Server Component를 받을 수 있다.


```typescript
// app/modal.tsx (Client Component)
'use client'

export default function Modal({ children }) {
  return (
    <div className="modal">
      {children}
    </div>
  )
}
```


```typescript
// app/page.tsx (Server Component)
import Modal from './modal'
import ServerContent from './server-content'

export default function Page() {
  return (
    <Modal>
      <ServerContent />
    </Modal>
  )
}
```


위 패턴에서 `Modal`은 Client Component지만 `children`으로 무엇을 받을지는 모른다. `ServerContent`는 Server Component로서 서버에서 렌더링된다. `Modal`은 단지 렌더링된 결과를 받아서 표시할 뿐이다.


이 패턴을 사용하면 Client Component와 Server Component를 독립적으로 렌더링할 수 있다. Client Component가 재렌더링되어도 Server Component는 서버에서 이미 렌더링되었기 때문에 다시 렌더링되지 않는다.


## 주의사항


### Client Component는 양쪽에서 실행된다


Server Component는 서버에서만 실행되지만, Client Component는 서버와 클라이언트 양쪽에서 실행된다.

- 서버: 초기 HTML 생성(사전 렌더링)을 위해 1번 실행
- 클라이언트: 하이드레이션을 위해 1번 실행

따라서 Client Component에는 브라우저 전용 API(`window`, `localStorage` 등)를 바로 사용하면 안 된다. 서버에서 실행될 때 에러가 발생한다. `useEffect` 안에서 사용하거나 조건부로 체크해야 한다.


```typescript
'use client'

export default function MyComponent() {
  // 에러: 서버에서 실행 시 window가 없음
  const width = window.innerWidth

  // useEffect는 클라이언트에서만 실행됨
  useEffect(() => {
    const width = window.innerWidth
  }, [])
}
```


### Client Component에서 Server Component를 import할 수 없다


Client Component는 다른 Client Component만 직접 import할 수 있다. Server Component를 사용하려면 `children`이나 props로 받아야 한다.


```typescript
// 불가능
'use client'
import ServerComponent from './server-component'

export default function ClientComponent() {
  return <ServerComponent />
}
```


```typescript
// children으로 받기
'use client'

export default function ClientComponent({ children }) {
  return <div>{children}</div>
}
```


### 직렬화 가능한 값만 전달할 수 있다


Server Component에서 Client Component로 props를 전달할 때는 직렬화 가능한 값만 보낼 수 있다. 함수, 클래스 인스턴스, Symbol 같은 값은 전달할 수 없다.


```typescript
// 불가능
<ClientComponent
  onClick={() => {}}  // 함수 전달 불가
  date={new Date()}   // Date 객체 전달 불가
/>

// 가능
<ClientComponent
  count={42}              // 숫자
  name="hello"            // 문자열
  data={{ id: 1 }}        // 객체
  items={[1, 2, 3]}       // 배열
  timestamp="2024-01-01"  // ISO 문자열
/>
```


이는 서버에서 컴포넌트를 렌더링한 결과를 JSON 형태로 클라이언트에 전송하기 때문이다. JSON으로 변환할 수 없는 값은 전달할 수 없다.


### 컴포넌트 계층 구조 설계


Client Component를 최대한 말단에 배치하는 것이 좋다. 상위에 Client Component가 있으면 그 하위의 모든 컴포넌트가 JavaScript 번들에 포함되어 용량이 커진다.


```typescript
// 비효율적인 구조
'use client'

export default function Page() {
  const [open, setOpen] = useState(false)

  return (
    <div>
      <Header />        {/* JavaScript 번들에 포함 */}
      <Content />       {/* JavaScript 번들에 포함 */}
      <Footer />        {/* JavaScript 번들에 포함 */}
      <Modal open={open} setOpen={setOpen} />
    </div>
  )
}
```


위 코드는 `Modal`의 상태 관리 때문에 전체를 Client Component로 만들었다. 이렇게 하면 `Header`, `Content`, `Footer` 같은 정적 컴포넌트까지 모두 JavaScript 번들에 포함되어 파일 크기가 커진다.


```typescript
// 효율적인 구조
export default function Page() {
  return (
    <div>
      <Header />        {/* Server Component */}
      <Content />       {/* Server Component */}
      <Footer />        {/* Server Component */}
      <ModalButton />   {/* Client Component */}
    </div>
  )
}
```


```typescript
// modal-button.tsx
'use client'

export default function ModalButton() {
  const [open, setOpen] = useState(false)

  return (
    <>
      <button onClick={() => setOpen(true)}>열기</button>
      <Modal open={open} setOpen={setOpen} />
    </>
  )
}
```


위 코드는 상태가 필요한 부분만 Client Component로 분리했다. `Header`, `Content`, `Footer`는 Server Component로 남아있어 JavaScript 번들에 포함되지 않는다. 이렇게 하면 번들 크기가 줄어들고 Time to Interactive(TTI)가 개선된다.


**핵심은 인터랙션이 필요한 최소한의 부분만 Client Component로 만드는 것이다.** 페이지 전체를 Client Component로 만들지 말고, 버튼이나 입력 폼처럼 실제로 상호작용이 필요한 부분만 분리한다.


## 참고 자료

- [Next.js 공식 문서 - Server Components](https://nextjs.org/docs/app/building-your-application/rendering/server-components)
- [Next.js 공식 문서 - Client Components](https://nextjs.org/docs/app/building-your-application/rendering/client-components)
- [Next.js 공식 문서 - Composition Patterns](https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns)


React Server Component


## Link 컴포넌트로 페이지 이동하기


Next.js에서 페이지 간 이동은 `<Link>` 컴포넌트를 사용한다.


```typescript
import Link from 'next/link'

export default function Navigation() {
  return (
    <nav>
      <Link href="/">홈</Link>
      <Link href="/about">소개</Link>
      <Link href="/blog/post-1">블로그</Link>
    </nav>
  )
}
```


`<Link>`는 HTML의 `<a>` 태그를 확장한 것으로, 클라이언트 사이드 네비게이션을 제공한다. 페이지 전체를 새로고침하지 않고 필요한 부분만 교체해서 빠른 이동이 가능하다.


## RSC Payload와 JS Bundle


App Router에서는 Server Component와 Client Component가 분리되어 있어서, 페이지 이동 시 두 가지를 각각 불러온다.

- **RSC Payload**: Server Component의 렌더링 결과. 서버에서 생성된 HTML과 데이터를 담고 있다.
- **JS Bundle**: Client Component의 JavaScript 코드. 브라우저에서 실행될 인터랙티브한 부분이다.

Page Router에서는 JS Bundle만으로 모든 컴포넌트를 처리했지만, App Router에서는 서버와 클라이언트 컴포넌트가 분리되어 각각 필요한 것만 전송한다. 이를 통해 전송량을 줄이고 초기 로딩 속도를 개선한다.


## Prefetching


Prefetching은 사용자가 링크를 클릭하기 전에 미리 해당 페이지의 데이터를 불러오는 기능이다. `<Link>` 컴포넌트는 기본적으로 prefetching을 자동으로 수행한다.


### 작동 방식


링크가 뷰포트에 나타나면 Next.js는 백그라운드에서 해당 페이지를 미리 불러온다. 사용자가 실제로 클릭했을 때는 이미 데이터가 준비되어 있어서 즉시 페이지가 전환된다.


```typescript
// 기본: prefetching 활성화
<Link href="/dashboard">대시보드</Link>

// prefetching 비활성화
<Link href="/dashboard" prefetch={false}>대시보드</Link>
```


### Static vs Dynamic 라우트


Prefetching 동작은 라우트가 정적인지 동적인지에 따라 다르다.


**Static 라우트**는 빌드 타임에 미리 생성된 페이지다. 데이터가 고정되어 있고 모든 사용자에게 동일한 내용을 보여준다.


```typescript
// app/about/page.tsx - Static 라우트
export default function About() {
  return <div>소개 페이지</div>
}
```


Static 라우트는 **RSC Payload와 JS Bundle을 모두 prefetch** 한다. 페이지 전체를 미리 불러오기 때문에 이동이 즉각적이다.


**Dynamic 라우트**는 요청 시점에 렌더링되는 페이지다. 사용자마다 다른 데이터를 보여주거나 실시간 데이터를 표시한다.


```typescript
// app/dashboard/page.tsx - Dynamic 라우트
export default async function Dashboard() {
  const user = await getCurrentUser() // 요청 시점에 실행
  return <div>환영합니다, {user.name}님</div>
}
```


Dynamic 라우트는 **RSC Payload만 일부 prefetch** 한다. 전체 페이지를 미리 렌더링할 수 없기 때문에 레이아웃이나 로딩 상태만 미리 준비한다.


### 개발 모드 vs 프로덕션 모드


Prefetching은 프로덕션 모드에서만 활성화된다.

- **개발 모드** (`npm run dev`): Prefetching이 비활성화되어 있다. 링크를 클릭할 때만 RSC Payload와 JS Bundle을 불러온다.
- **프로덕션 모드** (`npm run build && npm start`): Prefetching이 활성화되어 링크가 뷰포트에 나타나면 자동으로 데이터를 미리 불러온다.

개발 중에는 prefetching이 작동하지 않으므로, 실제 성능을 확인하려면 빌드 후 프로덕션 모드로 실행해야 한다.


## 클라이언트 사이드 네비게이션


`<Link>` 컴포넌트를 사용하면 클라이언트 사이드 네비게이션이 가능하다. 페이지 전체가 새로고침되지 않고, 변경된 부분만 교체된다.


```typescript
export default function Page() {
  return (
    <div>
      <Header />  {/* 페이지 이동 시 유지됨 */}
      <Content /> {/* 이 부분만 교체됨 */}
      <Footer />  {/* 페이지 이동 시 유지됨 */}
    </div>
  )
}
```


Layout으로 감싸진 부분은 그대로 유지되고, 페이지 컴포넌트만 교체되므로 빠르고 부드러운 전환이 가능하다. 이는 SPA(Single Page Application)와 유사한 경험을 제공한다.


## 프로그래매틱 네비게이션


때로는 버튼 클릭이나 폼 제출 후에 프로그래밍으로 페이지를 이동해야 할 때가 있다. 이럴 때는 `useRouter` 훅을 사용한다.


```typescript
'use client'

import { useRouter } from 'next/navigation'

export default function LoginButton() {
  const router = useRouter()

  const handleLogin = async () => {
    await login()
    router.push('/dashboard')
  }

  return <button onClick={handleLogin}>로그인</button>
}
```


App Router에서는 `next/navigation`에서 `useRouter`를 import 한다. Page Router의 `next/router`와는 다른 API다.


주요 메서드는 다음과 같다.

- `router.push(href)`: 새로운 페이지로 이동
- `router.replace(href)`: 히스토리를 남기지 않고 이동
- `router.back()`: 이전 페이지로 이동
- `router.refresh()`: 현재 페이지 새로고침

## 참고 자료

- [Next.js 공식 문서 - Linking and Navigating](https://nextjs.org/docs/app/building-your-application/routing/linking-and-navigating)


App Router navigating


## Layout이란


Layout은 여러 페이지에서 공유되는 UI를 말한다. Next.js App Router에서 Layout은 다음과 같은 특징을 가진다.

- 페이지 전환 시 상태를 유지한다
- 재렌더링되지 않는다
- 인터랙션을 유지한다

## 기본 사용법


특정 폴더 안에 `layout.tsx` 파일을 만들면 해당 폴더와 하위 폴더의 모든 페이지가 이 Layout을 공유한다.


```typescript
export default function DashboardLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <section>
      <nav>네비게이션 바</nav>
      <main>{children}</main>
    </section>
  )
}
```


위 코드에서 `children` prop으로 해당 Layout 안에 렌더링될 페이지나 하위 Layout을 받는다. Layout 컴포넌트는 반드시 `children`을 받아서 렌더링해야 한다.


## Root Layout


`app` 디렉토리의 최상위에는 반드시 Root Layout이 있어야 한다. 이 Layout은 애플리케이션 전체에 적용되며, 다른 Layout과 달리 특별한 요구사항이 있다.


```typescript
export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="ko">
      <body>{children}</body>
    </html>
  )
}
```


Root Layout은 `<html>`과 `<body>` 태그를 반드시 포함해야 한다. 이는 서버 사이드 렌더링 시 완전한 HTML 문서를 생성하기 위함이다.


## Layout 중첩


폴더 구조에 따라 Layout은 자동으로 중첩된다.


```plain text
app/
├── layout.tsx          # Root Layout
└── dashboard/
    ├── layout.tsx      # Dashboard Layout
    └── settings/
        ├── layout.tsx  # Settings Layout
        └── page.tsx    # Settings Page
```


위와 같은 구조에서 `/dashboard/settings` 경로에 접근하면 다음 순서로 중첩된다.

1. Root Layout이 Dashboard Layout을 감싼다
2. Dashboard Layout이 Settings Layout을 감싼다
3. Settings Layout이 Settings Page를 감싼다

각 Layout은 자신의 `children`으로 다음 단계의 Layout 또는 Page를 받는다.


## Layout의 동작 방식


Layout은 페이지 전환 시 재렌더링되지 않는다. 예를 들어 `/dashboard/analytics`에서 `/dashboard/settings`로 이동할 때, 두 페이지가 같은 Dashboard Layout을 공유한다면 Dashboard Layout은 그대로 유지되고 내부의 페이지 컴포넌트만 교체된다.


이로 인해 다음과 같은 이점이 있다.

- Layout 내부의 상태가 유지된다
- 불필요한 재렌더링을 방지해 성능이 향상된다
- Layout 내부의 인터랙티브한 요소가 초기화되지 않는다

## Route Group으로 Layout 구성하기


Route Group은 폴더 이름을 괄호 `(folderName)`로 감싸서 만든다. 이렇게 만든 폴더는 URL 경로에 포함되지 않고, 단순히 라우트를 구조화하는 용도로만 사용된다.


### Route Group의 활용


Route Group을 사용하면 다음과 같은 작업을 할 수 있다.

- 팀, 기능, 관심사별로 라우트를 논리적으로 그룹화한다
- 동일한 라우트 세그먼트 레벨에서 여러 개의 Root Layout을 정의한다
- 특정 라우트에만 선택적으로 Layout을 적용한다

### 사용 예시


```plain text
app/
├── (marketing)/
│   ├── layout.tsx      # 마케팅 전용 Layout
│   ├── about/
│   │   └── page.tsx    # URL: /about
│   └── blog/
│       └── page.tsx    # URL: /blog
└── (shop)/
    ├── layout.tsx      # 쇼핑 전용 Layout
    ├── products/
    │   └── page.tsx    # URL: /products
    └── cart/
        └── page.tsx    # URL: /cart
```


위 구조에서 `(marketing)`과 `(shop)`은 URL에 포함되지 않는다. `/about` 페이지는 마케팅 Layout을 사용하고, `/products` 페이지는 쇼핑 Layout을 사용한다.


### 여러 Root Layout 만들기


Route Group을 사용하면 하나의 앱 안에서 완전히 다른 Root Layout을 여러 개 만들 수 있다.


```plain text
app/
├── (site)/
│   ├── layout.tsx      # 일반 사이트용 Root Layout
│   └── page.tsx        # URL: /
└── (admin)/
    ├── layout.tsx      # 관리자용 Root Layout
    └── page.tsx        # URL: /admin (route group 내부에서는 /page로 처리)
```


다만 서로 다른 Root Layout 사이를 이동할 때는 전체 페이지가 다시 로드된다. 같은 Root Layout 내에서 이동할 때처럼 부분 렌더링이 일어나지 않는다.


### 주의사항


공식 문서에서 언급하는 주의사항이다.

- 서로 다른 Route Group에서 같은 URL 경로가 생기지 않도록 해야 한다. 예를 들어 `(shop)/products/page.tsx`와 `(marketing)/products/page.tsx`는 둘 다 `/products` URL을 만들기 때문에 충돌이 발생한다.
- 여러 Root Layout을 사용할 때, 홈 페이지 `/`는 반드시 하나의 Route Group 안에 정의되어야 한다.

## 참고 자료

- [Next.js 공식 문서 - Layouts and Templates](https://nextjs.org/docs/app/building-your-application/routing/layouts-and-templates)
- [Next.js 공식 문서 - Route Groups](https://nextjs.org/docs/app/building-your-application/routing/route-groups)


App Router Layout 설정하기


## Page Router의 데이터 페칭 방식과 한계


Page Router에서는 서버 컴포넌트라는 개념이 없었다. 모든 컴포넌트가 클라이언트 컴포넌트로서 서버와 클라이언트 양쪽에서 실행되었기 때문에, 서버에서만 데이터를 가져오려면 `getServerSideProps`나 `getStaticProps` 같은 특수한 함수를 사용해야 했다.


```javascript
// Page Router 방식
export default function Page({ data }) {
  return <div>{data.title}</div>;
}

export async function getServerSideProps() {
  const res = await fetch('<https://api.example.com/data>');
  const data = await res.json();

  return {
    props: { data }
  };
}
```


이 방식의 문제는 **데이터 흐름의 비효율성**이다. 서버에서 가져온 데이터는 항상 페이지 최상단에 위치하게 되고, 실제로 그 데이터가 필요한 하위 컴포넌트까지 props나 Context API로 전달해야 한다. 컴포넌트 트리가 깊어질수록 props drilling이 심해지고, 데이터가 필요한 곳에서 직접 가져올 수 없다는 근본적인 제약이 있었다.


## App Router의 해결 방법


App Router에서는 서버 컴포넌트가 추가되면서 이런 문제가 해결되었다. 서버 컴포넌트는 서버에서만 실행되기 때문에 컴포넌트 함수 자체를 `async`로 선언하고 내부에서 직접 데이터를 가져올 수 있다.


```javascript
// App Router 방식
async function PostList() {
  const res = await fetch('<https://api.example.com/posts>');
  const posts = await res.json();

  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}
```


위 코드에서 `PostList` 컴포넌트는 서버 컴포넌트다. 서버에서만 실행되므로 브라우저 환경에서 발생할 수 있는 비동기 처리 문제를 신경 쓸 필요가 없다. 기존에는 클라이언트 컴포넌트에서 `async` 키워드를 사용하면 브라우저에서 동작할 때 문제를 일으킬 수 있어 권장되지 않았지만, 서버 컴포넌트는 브라우저에 전송되지 않으므로 안전하게 사용할 수 있다.


## 주요 변화점


이제 `getServerSideProps`, `getStaticProps` 같은 함수를 사용하지 않아도 된다. **데이터가 필요한 컴포넌트에서 직접 가져오면** 된다. Next.js 공식 문서에서 강조하는 "fetching data where it's needed"라는 best practice가 이제 실제로 가능해진 것이다.


```javascript
// 페이지 컴포넌트
export default function BlogPage() {
  return (
    <div>
      <Header />
      <PostList />  {/* 데이터가 필요한 곳에서 직접 fetch */}
      <Sidebar />
    </div>
  );
}

// 데이터가 필요한 컴포넌트
async function PostList() {
  const posts = await fetchPosts();
  return <ul>...</ul>;
}
```


데이터를 상위에서 하위로 전달할 필요가 없어지면서 컴포넌트 구조가 단순해지고, 각 컴포넌트가 자신이 필요한 데이터를 독립적으로 관리할 수 있게 되었다.


## 서버 컴포넌트에서 데이터 페칭 패턴


서버 컴포넌트에서 데이터를 가져오는 기본 패턴은 다음과 같다.


```javascript
async function ProductDetail({ id }) {
  // 1. fetch 요청
  const res = await fetch(`https://api.example.com/products/${id}`);

  // 2. 에러 처리
  if (!res.ok) {
    throw new Error('Failed to fetch product');
  }

  // 3. 데이터 파싱
  const product = await res.json();

  // 4. 렌더링
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <p>Price: ${product.price}</p>
    </div>
  );
}
```


컴포넌트 함수를 `async`로 선언하고, 내부에서 `await`로 비동기 작업을 처리한다. 이 컴포넌트는 서버에서 데이터를 가져온 후 완성된 HTML을 클라이언트에 전송하므로, 사용자는 로딩 상태 없이 바로 완성된 콘텐츠를 볼 수 있다.


## fetch API 확장 기능


App Router의 서버 컴포넌트에서 사용하는 `fetch`는 Web API의 표준 fetch를 확장한 것으로, Next.js만의 추가 기능을 제공한다.


```javascript
// 캐싱 제어
const res = await fetch('<https://api.example.com/data>', {
  cache: 'force-cache'  // 기본값: 캐시 사용
});

const res2 = await fetch('<https://api.example.com/data>', {
  cache: 'no-store'  // 매번 새로 가져오기
});

// 재검증 시간 설정
const res3 = await fetch('<https://api.example.com/data>', {
  next: { revalidate: 60 }  // 60초마다 재검증
});
```


이 옵션들을 통해 SSG, SSR, ISR 방식을 자연스럽게 구현할 수 있다.


## 병렬 데이터 페칭


여러 데이터를 동시에 가져와야 할 때는 `Promise.all`을 사용하면 된다.


```javascript
async function Dashboard() {
  const [user, posts, comments] = await Promise.all([
    fetch('/api/user').then(r => r.json()),
    fetch('/api/posts').then(r => r.json()),
    fetch('/api/comments').then(r => r.json())
  ]);

  return (
    <div>
      <UserProfile user={user} />
      <PostList posts={posts} />
      <CommentList comments={comments} />
    </div>
  );
}
```


세 개의 API 요청이 순차적이 아닌 병렬로 실행되어 전체 로딩 시간이 단축된다.


## 클라이언트 컴포넌트에서의 데이터 페칭


클라이언트 컴포넌트에서는 여전히 `useEffect`나 React Query 같은 라이브러리를 사용해 데이터를 가져온다.


```javascript
'use client'

import { useState, useEffect } from 'react';

export default function ClientComponent() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetch('/api/data')
      .then(r => r.json())
      .then(setData);
  }, []);

  if (!data) return <div>Loading...</div>;

  return <div>{data.title}</div>;
}
```


서버 컴포넌트에서는 `async/await`로 간단하게 처리하고, 클라이언트 컴포넌트에서는 기존 방식을 사용하는 것이 일반적인 패턴이다.



App Router data fetching


## 사전 렌더링이란


Next.js는 모든 페이지를 기본적으로 사전 렌더링(Pre-rendering)한다. 클라이언트 측 JavaScript가 모든 작업을 처리하는 전통적인 React SPA와 달리, Next.js는 서버에서 미리 HTML을 생성한다.


사전 렌더링의 핵심 장점은 초기 로딩 성능과 SEO 개선이다. 서버에서 완성된 HTML을 보내기 때문에 브라우저는 즉시 컨텐츠를 표시할 수 있고, 검색 엔진 크롤러도 페이지 내용을 정확히 파악할 수 있다.


Next.js는 세 가지 사전 렌더링 방식을 제공한다. 각 방식은 페이지를 생성하는 시점과 주기가 다르며, 데이터의 신선도와 성능 사이에서 서로 다른 균형점을 찾는다.


## SSR (Server-Side Rendering)


### 왜 필요한가


서버 사이드 렌더링은 요청이 들어올 때마다 서버에서 HTML을 새로 생성한다. 사용자마다 다른 컨텐츠를 보여주거나, 실시간으로 변하는 데이터를 표시해야 할 때 필요하다.


예를 들어 대시보드 페이지는 로그인한 사용자의 최신 활동 내역을 보여줘야 한다. 이런 경우 빌드 타임에 미리 만들어둔 정적 페이지로는 해결할 수 없다.


### 동작 방식


SSR은 `getServerSideProps` 함수로 구현한다. 이 함수는 매 요청마다 서버에서 실행되며, 데이터를 가져온 뒤 페이지 컴포넌트에 props로 전달한다.


```typescript
export default function Dashboard({ userData }) {
  return (
    <div>
      <h1>{userData.name}의 대시보드</h1>
      <p>마지막 로그인: {userData.lastLogin}</p>
    </div>
  )
}

export async function getServerSideProps(context) {
  const { req, res } = context

  // 쿠키에서 사용자 정보 가져오기
  const userId = req.cookies.userId

  // API에서 최신 데이터 조회
  const response = await fetch(`https://api.example.com/users/${userId}`)
  const userData = await response.json()

  return {
    props: {
      userData
    }
  }
}
```


위 코드에서 사용자가 `/dashboard` 페이지를 요청하면 Next.js는 먼저 `getServerSideProps`를 실행한다. 이 함수는 쿠키에서 사용자 ID를 읽고, API를 호출해서 최신 데이터를 가져온다. 그 다음 이 데이터를 props로 전달받은 컴포넌트가 렌더링되어 HTML로 변환되고, 최종적으로 브라우저에 전송된다.


### 타입 추론


TypeScript를 사용할 때는 `InferGetServerSidePropsType`으로 props 타입을 자동 추론할 수 있다.


```typescript
import type { InferGetServerSidePropsType } from 'next'

export default function Dashboard({
  userData
}: InferGetServerSidePropsType<typeof getServerSideProps>) {
  // userData의 타입이 자동으로 추론됨
}
```


### 실행 환경


`getServerSideProps`는 오직 서버에서만 실행된다. 이 함수 안에서 `console.log`를 찍으면 브라우저 콘솔이 아닌 Next.js 서버 터미널에 출력된다. 따라서 데이터베이스 직접 조회나 서버 파일 시스템 접근 같은 서버 전용 작업을 안전하게 수행할 수 있다.


### 장단점


SSR의 장점은 항상 최신 데이터를 보여줄 수 있다는 점이다. 매 요청마다 새로 렌더링하기 때문에 실시간성이 중요한 페이지에 적합하다.


하지만 단점도 명확하다. 데이터를 가져오는 API가 느리면 사용자는 빈 화면을 오래 봐야 한다. 서버는 매번 렌더링 작업을 수행해야 하므로 트래픽이 많을수록 서버 부하가 증가한다. CDN 캐싱도 기본적으로는 불가능하다.


## SSG (Static Site Generation)


### 왜 필요한가


정적 사이트 생성은 빌드 타임에 페이지를 미리 만들어둔다. SSR의 성능 문제를 해결하기 위해 등장했다. 내용이 자주 바뀌지 않는 페이지라면 매번 서버에서 렌더링할 필요가 없다.


블로그 글, 문서 페이지, 상품 목록처럼 모든 사용자에게 동일한 컨텐츠를 보여주는 경우 SSG가 가장 효율적이다.


### 동작 방식


SSG는 `getStaticProps` 함수로 구현한다. 이 함수는 빌드할 때 한 번만 실행되며, 가져온 데이터로 HTML 파일을 생성한다.


```typescript
export default function BlogPost({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <div>{post.content}</div>
    </article>
  )
}

export async function getStaticProps() {
  const response = await fetch('<https://api.example.com/posts/1>')
  const post = await response.json()

  return {
    props: {
      post
    }
  }
}
```


위 코드는 빌드 시점에 실행되어 HTML 파일을 생성한다. 사용자가 페이지를 요청하면 서버는 이미 만들어진 HTML을 즉시 반환한다. API 호출이나 렌더링 과정이 필요 없으므로 응답 속도가 빠르다.


### 동적 라우팅


동적 라우팅(예: `/posts/[id]`)을 사용하는 경우 `getStaticPaths`로 어떤 경로들을 미리 생성할지 지정해야 한다.


```typescript
// pages/posts/[id].tsx

export async function getStaticPaths() {
  const response = await fetch('<https://api.example.com/posts>')
  const posts = await response.json()

  const paths = posts.map(post => ({
    params: { id: post.id.toString() }
  }))

  return {
    paths,
    fallback: false
  }
}

export async function getStaticProps({ params }) {
  const response = await fetch(`https://api.example.com/posts/${params.id}`)
  const post = await response.json()

  return {
    props: {
      post
    }
  }
}
```


`getStaticPaths`는 빌드 시점에 어떤 ID들로 페이지를 만들지 결정한다. 위 예시에서는 API에서 모든 포스트 목록을 가져와서, 각 포스트마다 정적 페이지를 생성한다. 예를 들어 포스트가 10개라면 `/posts/1`, `/posts/2`, ... `/posts/10` 경로의 HTML이 모두 빌드 시점에 만들어진다.


### fallback 옵션


`fallback` 옵션은 `getStaticPaths`에서 지정하지 않은 경로로 요청이 들어왔을 때 어떻게 처리할지 결정한다.


```typescript
return {
  paths,
  fallback: false  // 404 반환
  // fallback: true  // 빌드 후 생성
  // fallback: 'blocking'  // SSR처럼 동작
}
```


`fallback: false`는 지정한 경로 외에는 모두 404를 반환한다. `fallback: true`는 존재하지 않는 경로를 요청하면 즉시 빈 페이지를 보여주고 백그라운드에서 페이지를 생성한 뒤 교체한다. `fallback: 'blocking'`은 SSR처럼 동작해서 페이지 생성이 완료될 때까지 기다린 후 완성된 HTML을 반환한다.


대규모 사이트에서 모든 페이지를 빌드 시점에 생성하면 시간이 오래 걸린다. 이럴 때는 자주 접근하는 페이지만 미리 생성하고, 나머지는 `fallback: 'blocking'`으로 처리하는 것이 효율적이다.


### 제약사항


SSG는 요청 시점의 정보에 접근할 수 없다. 예를 들어 검색 페이지에서 쿼리 파라미터로 검색어를 받는다면, 빌드 시점에는 사용자가 어떤 검색어를 입력할지 알 수 없으므로 SSG를 사용할 수 없다.


```typescript
// pages/search.tsx
export async function getStaticProps(context) {
  // context.query는 빌드 시점에 undefined
  const searchTerm = context.query.q  // 이 값을 알 수 없음

  return {
    props: {}
  }
}
```


이런 경우에는 클라이언트에서 직접 데이터를 가져오거나 SSR을 사용해야 한다.


### 장단점


SSG의 장점은 속도다. 이미 만들어진 HTML을 반환하기만 하면 되므로 응답이 즉각적이다. CDN에 캐싱할 수 있어서 전 세계 어디서든 빠른 접근이 가능하다. 서버 부하도 거의 없다.


단점은 데이터 신선도다. 빌드 이후로는 페이지가 업데이트되지 않기 때문에 컨텐츠가 변경되어도 재배포하기 전까지는 이전 내용이 표시된다.


## ISR (Incremental Static Regeneration)


### 왜 필요한가


증분 정적 재생성은 SSG의 성능 장점을 유지하면서 데이터 신선도 문제를 해결한다. 모든 요청마다 렌더링하지는 않지만, 일정 주기로 페이지를 재생성해서 최신 상태를 유지한다.


블로그 조회수처럼 실시간성이 중요하지는 않지만 완전히 정적이지도 않은 데이터를 다룰 때 유용하다.


### 시간 기반 ISR


`getStaticProps`에서 `revalidate` 옵션을 추가하면 ISR이 활성화된다.


```typescript
export async function getStaticProps() {
  const response = await fetch('<https://api.example.com/posts>')
  const posts = await response.json()

  return {
    props: {
      posts
    },
    revalidate: 60  // 60초
  }
}
```


위 코드는 60초마다 페이지를 재검증한다. 동작 방식은 다음과 같다.


첫 번째 요청이 들어오면 캐시된 페이지를 즉시 반환한다. 만약 마지막 생성 시점으로부터 60초가 지났다면, Next.js는 백그라운드에서 페이지를 재생성한다. 재생성이 완료되면 새로운 버전으로 교체되고, 그 다음 요청부터는 업데이트된 페이지가 제공된다.


중요한 점은 재생성 중에도 이전 버전의 페이지가 계속 제공된다는 것이다. 사용자는 절대 로딩 화면을 보지 않는다. 이를 Stale-While-Revalidate 전략이라고 한다.


### On-Demand ISR


시간 기반 ISR은 주기적으로 재생성하지만, 때로는 특정 시점에 즉시 업데이트해야 할 때가 있다. 예를 들어 관리자가 블로그 글을 수정했다면, 다음 `revalidate` 주기를 기다리지 않고 바로 페이지를 갱신하고 싶다.


On-Demand ISR은 API 라우트에서 `res.revalidate()` 메서드로 특정 경로를 즉시 재생성할 수 있다.


```typescript
// pages/api/revalidate.ts

export default async function handler(req, res) {
  // 비밀 토큰으로 인증
  if (req.query.secret !== process.env.REVALIDATE_TOKEN) {
    return res.status(401).json({ message: 'Invalid token' })
  }

  try {
    // 특정 경로 재검증
    await res.revalidate('/posts/1')
    return res.json({ revalidated: true })
  } catch (err) {
    return res.status(500).send('Error revalidating')
  }
}
```


위 코드는 `/api/revalidate?secret=TOKEN` 엔드포인트를 호출하면 `/posts/1` 페이지를 즉시 재생성한다. CMS 웹훅과 연결하면 컨텐츠 수정 시 자동으로 페이지를 갱신할 수 있다.


```typescript
// CMS에서 글 수정 후 웹훅으로 호출
await fetch(`https://yoursite.com/api/revalidate?secret=${token}&path=/posts/${postId}`)
```


### 주의사항


ISR은 Node.js 런타임에서만 동작한다. `next export`로 생성한 정적 사이트에서는 사용할 수 없다.


On-Demand ISR로 재검증을 트리거할 때 미들웨어는 실행되지 않는다. 인증이나 로깅이 필요하다면 API 라우트 내부에서 직접 처리해야 한다.


`revalidate` 값이 너무 짧으면 서버 부하가 증가하고, 너무 길면 데이터가 오래된 채로 유지된다. 컨텐츠 업데이트 빈도와 트래픽 패턴을 고려해서 적절한 값을 설정해야 한다.


## 페이지 별 특성에 맞는 렌더링 방식 선택


각 페이지의 특성에 맞는 렌더링 방식을 선택해야 한다.


SSR을 사용해야 하는 경우는 사용자별로 다른 컨텐츠를 보여주는 대시보드나 마이페이지, 실시간 데이터를 표시하는 주식 시세나 스포츠 스코어, 요청 헤더나 쿠키를 읽어야 하는 인증 페이지에 적합하다.


SSG를 사용해야 하는 경우는 마케팅 랜딩 페이지, 블로그 글, 제품 소개 페이지, 도움말 문서처럼 모든 사용자에게 동일한 컨텐츠를 보여주고 데이터가 거의 바뀌지 않는 페이지다.


ISR을 사용해야 하는 경우는 블로그 조회수나 좋아요 수처럼 자주 변하지만 실시간성이 중요하지 않은 데이터, 뉴스 기사처럼 주기적으로 업데이트되는 컨텐츠, 전자상거래 상품 목록처럼 재고나 가격이 변경되는 페이지다.


하나의 애플리케이션에서 여러 방식을 혼합해서 사용하는 것이 일반적이다. Next.js는 페이지별로 다른 렌더링 방식을 적용할 수 있으므로, 각 페이지의 요구사항에 맞는 최적의 전략을 선택하면 된다.


## 참고 자료

- [Next.js 공식 문서 - Server-side Rendering](https://nextjs.org/docs/pages/building-your-application/rendering/server-side-rendering)
- [Next.js 공식 문서 - Static Site Generation](https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation)
- [Next.js 공식 문서 - Incremental Static Regeneration](https://nextjs.org/docs/pages/building-your-application/rendering/incremental-static-regeneration)


사전 렌더링 방식 - SSR, SSG, ISR


Next.js에서 페이지마다 다른 레이아웃을 적용하는 패턴이다. `_app.tsx`에서 모든 페이지에 동일한 레이아웃을 적용하는 대신, 각 페이지가 자신만의 레이아웃을 정의할 수 있다.


## 왜 필요한가?


일반적으로 `_app.tsx`에서 레이아웃을 적용하면 모든 페이지가 동일한 레이아웃을 사용한다.


```typescript
// pages/_app.tsx
export default function App({ Component, pageProps }: AppProps) {
  return (
    <Layout>
      <Component {...pageProps} />
    </Layout>
  );
}
```


하지만 실제 애플리케이션에서는 페이지마다 다른 레이아웃이 필요한 경우가 많다.

- 홈페이지는 헤더만 있고 사이드바가 없다
- 대시보드는 사이드바가 있다
- 관리자 페이지는 다른 네비게이션을 사용한다
- 로그인 페이지는 레이아웃이 아예 없다

Per-page Layouts 패턴을 사용하면 각 페이지가 필요한 레이아웃을 자유롭게 선택할 수 있다.


## 기본 구조


페이지 컴포넌트에 `getLayout` 메서드를 추가하고, `_app.tsx`에서 이를 호출하는 방식이다.


### 1. `_app.tsx` 설정


```typescript
// pages/_app.tsx
import type { AppProps } from 'next/app';
import type { ReactElement, ReactNode } from 'react';
import type { NextPage } from 'next';

type NextPageWithLayout = NextPage & {
  getLayout?: (page: ReactElement) => ReactNode;
};

type AppPropsWithLayout = AppProps & {
  Component: NextPageWithLayout;
};

export default function App({ Component, pageProps }: AppPropsWithLayout) {
  // getLayout이 있으면 사용, 없으면 페이지 그대로 렌더링
  const getLayout = Component.getLayout ?? ((page) => page);

  return getLayout(<Component {...pageProps} />);
}
```


위 코드에서 `Component.getLayout`이 있는지 확인한다. 있으면 해당 함수를 호출하여 페이지를 레이아웃으로 감싸고, 없으면 페이지를 그대로 렌더링한다.


`??` 연산자는 왼쪽 값이 `null` 또는 `undefined`일 때 오른쪽 값을 사용한다.


### 2. 레이아웃이 필요한 페이지


```typescript
// pages/dashboard.tsx
import { ReactElement } from 'react';
import DashboardLayout from '@/components/DashboardLayout';

export default function Dashboard() {
  return (
    <div>
      <h1>대시보드</h1>
      <p>통계와 차트가 여기에 표시된다</p>
    </div>
  );
}

Dashboard.getLayout = function getLayout(page: ReactElement) {
  return <DashboardLayout>{page}</DashboardLayout>;
};
```


페이지 컴포넌트에 `getLayout` 메서드를 추가한다. 이 메서드는 페이지를 받아서 레이아웃으로 감싼 결과를 반환한다.


### 3. 레이아웃이 없는 페이지


```typescript
// pages/login.tsx
export default function Login() {
  return (
    <div>
      <h1>로그인</h1>
      <form>{/* 로그인 폼 */}</form>
    </div>
  );
}

// getLayout을 정의하지 않으면 레이아웃 없이 페이지만 렌더링된다
```


`getLayout`을 정의하지 않으면 `_app.tsx`에서 `(page) => page`가 사용되어 페이지가 그대로 렌더링된다.


## 레이아웃 컴포넌트 작성


레이아웃 컴포넌트는 일반적인 React 컴포넌트다.


```typescript
// components/DashboardLayout.tsx
import Link from 'next/link';
import { ReactNode } from 'react';

export default function DashboardLayout({ children }: { children: ReactNode }) {
  return (
    <div>
      <nav>
        <Link href="/dashboard">대시보드</Link>
        <Link href="/dashboard/analytics">분석</Link>
        <Link href="/dashboard/settings">설정</Link>
      </nav>
      <main>{children}</main>
    </div>
  );
}
```


`children` prop으로 페이지 컴포넌트를 받아서 원하는 위치에 렌더링한다.


## 중첩 레이아웃


레이아웃 안에 또 다른 레이아웃을 중첩할 수 있다.


```typescript
// pages/dashboard/analytics.tsx
import { ReactElement } from 'react';
import DashboardLayout from '@/components/DashboardLayout';
import AnalyticsLayout from '@/components/AnalyticsLayout';

export default function Analytics() {
  return <div>분석 페이지 내용</div>;
}

Analytics.getLayout = function getLayout(page: ReactElement) {
  return (
    <DashboardLayout>
      <AnalyticsLayout>{page}</AnalyticsLayout>
    </DashboardLayout>
  );
};
```


위 코드는 `DashboardLayout` 안에 `AnalyticsLayout`을 중첩한다. 페이지 전환 시 `DashboardLayout`의 상태는 유지되고 `AnalyticsLayout`만 교체된다.


## 레이아웃 상태 유지


Per-page Layouts의 중요한 장점은 페이지 전환 시 레이아웃의 상태가 유지된다는 점이다.


```typescript
// components/DashboardLayout.tsx
import { useState } from 'react';
import Link from 'next/link';

export default function DashboardLayout({ children }: { children: ReactNode }) {
  const [sidebarOpen, setSidebarOpen] = useState(true);

  return (
    <div>
      <button onClick={() => setSidebarOpen(!sidebarOpen)}>
        사이드바 토글
      </button>

      {sidebarOpen && (
        <nav>
          <Link href="/dashboard">대시보드</Link>
          <Link href="/dashboard/analytics">분석</Link>
        </nav>
      )}

      <main>{children}</main>
    </div>
  );
}
```


사용자가 사이드바를 닫은 상태에서 `/dashboard`에서 `/dashboard/analytics`로 이동해도 사이드바는 닫힌 상태로 유지된다. 같은 레이아웃을 사용하는 페이지 간 이동에서는 레이아웃이 언마운트되지 않기 때문이다.


## TypeScript 타입 정의


타입 안정성을 위해 페이지 타입을 확장할 수 있다.


```typescript
// types/page.ts
import type { NextPage } from 'next';
import type { ReactElement, ReactNode } from 'react';

export type NextPageWithLayout<P = {}, IP = P> = NextPage<P, IP> & {
  getLayout?: (page: ReactElement) => ReactNode;
};
```


```typescript
// pages/_app.tsx
import type { AppProps } from 'next/app';
import type { NextPageWithLayout } from '@/types/page';

type AppPropsWithLayout = AppProps & {
  Component: NextPageWithLayout;
};

export default function App({ Component, pageProps }: AppPropsWithLayout) {
  const getLayout = Component.getLayout ?? ((page) => page);
  return getLayout(<Component {...pageProps} />);
}
```


```typescript
// pages/dashboard.tsx
import type { NextPageWithLayout } from '@/types/page';
import DashboardLayout from '@/components/DashboardLayout';

const Dashboard: NextPageWithLayout = () => {
  return <div>대시보드</div>;
};

Dashboard.getLayout = function getLayout(page) {
  return <DashboardLayout>{page}</DashboardLayout>;
};

export default Dashboard;
```


타입을 정의하면 `getLayout` 메서드의 시그니처가 자동완성되고 타입 체크가 된다.


## 주의사항


### getLayout은 Next.js 기능이 아니다


`getLayout`은 Next.js가 제공하는 API가 아니라 **개발자가 만드는 패턴**이다. JavaScript에서 함수도 객체이므로 함수 컴포넌트에 프로퍼티를 추가할 수 있다.


이름도 `getLayout` 대신 `withLayout`, `customLayout` 등 원하는 대로 정할 수 있다. 다만 Next.js 공식 문서에서 `getLayout`이라는 이름으로 소개했기 때문에 이것이 관례가 되었다.


### _app.tsx 레이아웃과 함께 사용


Per-page Layouts와 `_app.tsx`의 레이아웃을 함께 사용할 수도 있다.


```typescript
// pages/_app.tsx
export default function App({ Component, pageProps }: AppPropsWithLayout) {
  const getLayout = Component.getLayout ?? ((page) => page);

  return (
    <GlobalLayout>
      {getLayout(<Component {...pageProps} />)}
    </GlobalLayout>
  );
}
```


위 코드는 모든 페이지에 `GlobalLayout`을 적용하고, 추가로 각 페이지의 `getLayout`도 적용한다.


### getStaticProps, getServerSideProps와 함께 사용


Per-page Layouts는 데이터 페칭 메서드와 함께 사용할 수 있다.


```typescript
// pages/posts/[id].tsx
import type { NextPageWithLayout } from '@/types/page';
import { GetStaticProps, GetStaticPaths } from 'next';
import BlogLayout from '@/components/BlogLayout';

type Props = {
  post: {
    id: string;
    title: string;
    content: string;
  };
};

const Post: NextPageWithLayout<Props> = ({ post }) => {
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </article>
  );
};

Post.getLayout = function getLayout(page) {
  return <BlogLayout>{page}</BlogLayout>;
};

export const getStaticProps: GetStaticProps<Props> = async ({ params }) => {
  // 데이터 페칭 로직
  const post = await fetchPost(params?.id as string);
  return { props: { post } };
};

export const getStaticPaths: GetStaticPaths = async () => {
  // 경로 생성 로직
  return { paths: [], fallback: 'blocking' };
};

export default Post;
```


데이터 페칭과 레이아웃 설정을 모두 같은 페이지 파일에서 처리할 수 있다.


## 참고 자료

- [Next.js 공식 문서 - Pages and Layouts](https://nextjs.org/docs/pages/building-your-application/routing/pages-and-layouts)


Per-page Layouts


Next.js의 Page Router는 `pages` 폴더 내의 파일 구조를 기반으로 자동으로 라우팅을 생성하는 시스템이다. 별도의 라우팅 설정 파일 없이 파일과 폴더만으로 URL 경로를 정의할 수 있다.

> Page Router vs App Router  
> Next.js 13부터 App Router가 도입되었지만, Page Router는 여전히 안정적이고 널리 사용된다. App Router는 Server Components를 기본으로 하는 새로운 패러다임이며, Page Router는 기존의 Client-side Navigation을 중심으로 한다.

## 기본 라우팅


`pages` 폴더 내의 파일이 자동으로 라우트가 된다. 파일명이 곧 URL 경로다.


```plain text
pages/
├── index.tsx          → /
├── about.tsx          → /about
├── contact.tsx        → /contact
└── products.tsx       → /products
```


위 구조에서 `index.tsx`는 루트 경로 `/`에 매핑되고, `about.tsx`는 `/about` 경로에 매핑된다.


```typescript
// pages/index.tsx
export default function Home() {
  return <h1>홈 페이지</h1>;
}
```


```typescript
// pages/about.tsx
export default function About() {
  return <h1>소개 페이지</h1>;
}
```


각 파일은 기본적으로 React 컴포넌트를 default export 해야 한다. Next.js는 이 컴포넌트를 자동으로 페이지로 렌더링한다.


## 중첩 라우팅


폴더를 사용하면 중첩된 경로를 만들 수 있다.


```plain text
pages/
├── index.tsx              → /
├── blog/
│   ├── index.tsx          → /blog
│   ├── first-post.tsx     → /blog/first-post
│   └── second-post.tsx    → /blog/second-post
└── products/
    ├── index.tsx          → /products
    └── electronics.tsx    → /products/electronics
```


폴더 내의 `index.tsx`는 해당 폴더 경로의 기본 페이지가 된다. 예를 들어 `blog/index.tsx`는 `/blog` 경로에 매핑된다.


```typescript
// pages/blog/index.tsx
export default function Blog() {
  return <h1>블로그 목록</h1>;
}
```


```typescript
// pages/blog/first-post.tsx
export default function FirstPost() {
  return <h1>첫 번째 포스트</h1>;
}
```


이렇게 폴더 구조만으로 직관적인 URL 계층을 구성할 수 있다.


## 동적 라우팅 (URL Parameter)


동적 경로를 갖는 페이지를 생성하려면 파일명을 대괄호로 감싸면 된다. `[id].tsx`와 같이 작성하면 해당 부분이 동적 세그먼트가 된다.


```plain text
pages/
└── posts/
    ├── index.tsx          → /posts
    └── [id].tsx           → /posts/:id
```


`[id].tsx` 파일은 `/posts/1`, `/posts/abc`, `/posts/hello` 등 모든 경로에 매칭된다.


```typescript
// pages/posts/[id].tsx
import { useRouter } from 'next/router';

export default function Post() {
  const router = useRouter();
  const { id } = router.query;

  return <h1>포스트 ID: {id}</h1>;
}
```


위 코드에서 `useRouter` 훅을 통해 URL의 동적 파라미터에 접근할 수 있다. `router.query` 객체에서 파일명에 정의한 `id`를 구조 분해 할당으로 가져온다.


사용자가 `/posts/123`에 접속하면 `id`는 `"123"`이 되고, `/posts/hello`에 접속하면 `id`는 `"hello"`가 된다.


### 여러 동적 세그먼트


여러 동적 세그먼트를 조합할 수도 있다.


```plain text
pages/
└── posts/
    └── [category]/
        └── [id].tsx       → /posts/:category/:id
```


```typescript
// pages/posts/[category]/[id].tsx
import { useRouter } from 'next/router';

export default function Post() {
  const router = useRouter();
  const { category, id } = router.query;

  return (
    <div>
      <h1>카테고리: {category}</h1>
      <p>포스트 ID: {id}</p>
    </div>
  );
}
```


`/posts/tech/123`에 접속하면 `category`는 `"tech"`, `id`는 `"123"`이 된다.


## Query String


Query String은 페이지 경로에 영향을 주지 않으며, `?` 뒤에 오는 파라미터들을 의미한다. 예를 들어 `/search?q=nextjs&sort=latest`에서 `q`와 `sort`가 Query String이다.


별도의 설정 없이 `useRouter` 훅의 `query` 속성으로 접근할 수 있다.

> 주의: next/router 사용useRouter는 next/router에서 import 해야 한다. next/navigation의 useRouter는 App Router 전용이므로 Page Router에서는 사용할 수 없다.

```typescript
// pages/search.tsx
import { useRouter } from 'next/router';

export default function Search() {
  const router = useRouter();
  const { q, sort } = router.query;

  return (
    <div>
      <h1>검색어: {q}</h1>
      <p>정렬: {sort}</p>
    </div>
  );
}
```


사용자가 `/search?q=nextjs&sort=latest`에 접속하면 `q`는 `"nextjs"`, `sort`는 `"latest"`가 된다.


Query String은 동적 라우팅 파라미터와 함께 사용할 수도 있다. 모든 파라미터는 `router.query`에 통합된다.


```typescript
// pages/posts/[id].tsx
import { useRouter } from 'next/router';

export default function Post() {
  const router = useRouter();
  const { id, comments } = router.query;

  return (
    <div>
      <h1>포스트 ID: {id}</h1>
      {comments && <p>댓글 표시 모드</p>}
    </div>
  );
}
```


`/posts/123?comments=true`에 접속하면 `id`는 `"123"`, `comments`는 `"true"`가 된다.


## Catch-all Routes


단일 동적 세그먼트는 한 단계의 경로만 매칭한다. `/posts/[id].tsx`는 `/posts/123`은 매칭하지만 `/posts/123/comments`는 매칭하지 못한다.


여러 단계의 경로를 한 번에 처리하려면 **Catch-all Routes**를 사용한다. 대괄호 안에 `...`을 붙이면 된다.


```plain text
pages/
└── docs/
    └── [...slug].tsx      → /docs/* (모든 하위 경로)
```


`[...slug].tsx`는 `/docs/a`, `/docs/a/b`, `/docs/a/b/c` 등 모든 하위 경로를 매칭한다.


```typescript
// pages/docs/[...slug].tsx
import { useRouter } from 'next/router';

export default function Docs() {
  const router = useRouter();
  const { slug } = router.query;

  // slug는 배열로 전달됨
  return (
    <div>
      <h1>문서 경로</h1>
      <p>세그먼트: {Array.isArray(slug) ? slug.join(' / ') : slug}</p>
    </div>
  );
}
```


위 코드에서 `slug`는 경로 세그먼트를 배열로 담는다.

- `/docs/introduction` 접속 시: `slug = ["introduction"]`
- `/docs/getting-started/installation` 접속 시: `slug = ["getting-started", "installation"]`
- `/docs/api/hooks/useRouter` 접속 시: `slug = ["api", "hooks", "useRouter"]`

배열의 각 요소가 경로의 각 세그먼트에 해당한다. 이를 활용해 동적으로 컨텐츠를 렌더링하거나 파일 시스템에서 마크다운 파일을 읽어올 수 있다.


### Catch-all Routes의 한계


하지만 `[...slug].tsx`는 최소 하나의 세그먼트가 필요하다. `/docs`에는 매칭되지 않고 `/docs/something`부터 매칭된다.


`/docs`도 같은 컴포넌트로 처리하고 싶다면 두 가지 방법이 있다.

1. `docs/index.tsx`를 별도로 만든다
2. **Optional Catch-all Routes**를 사용한다

## Optional Catch-all Routes


대괄호를 한 번 더 감싸면 Optional Catch-all Routes가 된다.


```plain text
pages/
└── docs/
    └── [[...slug]].tsx    → /docs 및 /docs/* (모든 하위 경로)
```


`[[...slug]].tsx`는 `/docs`도 매칭하고, `/docs/a`, `/docs/a/b` 등 모든 하위 경로도 매칭한다.


```typescript
// pages/docs/[[...slug]].tsx
import { useRouter } from 'next/router';

export default function Docs() {
  const router = useRouter();
  const { slug } = router.query;

  if (!slug) {
    // /docs 경로
    return <h1>문서 홈</h1>;
  }

  // /docs/* 경로
  return (
    <div>
      <h1>문서 경로</h1>
      <p>세그먼트: {slug.join(' / ')}</p>
    </div>
  );
}
```

- `/docs` 접속 시: `slug = undefined`
- `/docs/introduction` 접속 시: `slug = ["introduction"]`
- `/docs/api/hooks` 접속 시: `slug = ["api", "hooks"]`

이렇게 하면 하나의 컴포넌트로 모든 문서 경로를 처리할 수 있다.


## 라우팅 우선순위


여러 라우트 패턴이 동일한 URL에 매칭될 수 있는 경우, Next.js는 다음 우선순위로 라우트를 결정한다.

1. **정적 라우트** (우선순위 가장 높음)
2. **동적 라우트**
3. **Catch-all 라우트** (우선순위 가장 낮음)

```plain text
pages/
├── posts/
│   ├── index.tsx          (1) /posts
│   ├── create.tsx         (2) /posts/create
│   ├── [id].tsx           (3) /posts/:id
│   └── [...slug].tsx      (4) /posts/*
```


위 구조에서:

- `/posts` 접속 시: `index.tsx` 매칭
- `/posts/create` 접속 시: `create.tsx` 매칭 (정적 라우트가 우선)
- `/posts/123` 접속 시: `[id].tsx` 매칭
- `/posts/a/b/c` 접속 시: `[...slug].tsx` 매칭

`create.tsx`가 있다면 `/posts/create`는 `[id].tsx`보다 우선한다. 정적 라우트가 동적 라우트보다 우선순위가 높기 때문이다.


## 404 페이지


존재하지 않는 경로에 접속할 때 표시되는 404 페이지를 커스터마이징할 수 있다. `pages` 폴더 최상위에 `404.tsx` 파일을 만들면 된다.


```typescript
// pages/404.tsx
import Link from 'next/link';

export default function Custom404() {
  return (
    <div>
      <h1>404 - 페이지를 찾을 수 없습니다</h1>
      <p>요청하신 페이지가 존재하지 않습니다.</p>
      <Link href="/">홈으로 돌아가기</Link>
    </div>
  );
}
```


빌드 시 자동으로 정적 페이지로 생성되므로 추가 서버 부하 없이 빠르게 제공된다.


## 참고 자료

- [Next.js 공식 문서 - Pages Router Routing](https://nextjs.org/docs/pages/building-your-application/routing)


Page Router routing 설정하기

Page Router vs. App Router


Next.js에서는 CSS를 사용하는 두 가지 기본 방법을 제공한다. **Global CSS**와 **CSS Modules**다.


## Global CSS


전역 CSS는 애플리케이션 전체에 적용되는 스타일이다. Next.js에서는 `pages/_app.tsx` 파일에서만 Global CSS를 import할 수 있다.


### 왜 `_app.tsx`에서만 가능한가?


일반 컴포넌트나 페이지에서 Global CSS를 import하면 **다른 페이지의 스타일과 충돌**할 수 있다.


예를 들어 다음과 같은 상황을 생각해보자.


```css
/* pages/home.css */
.button {
  background: red;
}
```


```css
/* pages/about.css */
.button {
  background: blue;
}
```


```typescript
// pages/index.tsx
import './home.css';  // ❌ 허용되지 않음

export default function Home() {
  return <button className="button">홈</button>;
}
```


```typescript
// pages/about.tsx
import './about.css';  // ❌ 허용되지 않음

export default function About() {
  return <button className="button">소개</button>;
}
```


위 코드에서 `/` 페이지를 방문한 후 `/about` 페이지로 이동하면, `home.css`가 이미 로드된 상태에서 `about.css`가 추가로 로드된다. 두 CSS 파일 모두 `.button` 클래스를 정의하므로 스타일이 충돌한다.


Next.js는 클라이언트 사이드 네비게이션을 사용하므로, 페이지를 이동해도 **이전 페이지의 CSS가 언로드되지 않는다**. 따라서 모든 페이지의 CSS가 누적되면서 예측 불가능한 스타일 충돌이 발생한다.


### 사용법


`_app.tsx`는 모든 페이지에 공통으로 적용되는 컴포넌트이므로, 여기에서 Global CSS를 import하는 것은 안전하다.


```typescript
// pages/_app.tsx
import '@/styles/globals.css';  // 허용됨
import type { AppProps } from 'next/app';

export default function App({ Component, pageProps }: AppProps) {
  return <Component {...pageProps} />;
}
```


```css
/* styles/globals.css */
* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}

body {
  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;
}

a {
  color: inherit;
  text-decoration: none;
}
```


### 언제 사용하는가?


Global CSS는 다음과 같은 경우에 사용한다.

- CSS Reset 또는 Normalize
- 전역 폰트 설정
- 전역 색상 변수
- 모든 페이지에 공통으로 적용되는 기본 스타일

페이지나 컴포넌트별 스타일은 CSS Modules를 사용하는 것이 좋다.


## CSS Modules


CSS Modules는 CSS 파일을 모듈로 import하여 **로컬 스코프**로 사용하는 방법이다. Next.js에 기본으로 내장되어 있어 별도 설정 없이 사용할 수 있다.


### 왜 필요한가?


일반 CSS는 전역 스코프를 사용하므로 클래스명이 충돌할 수 있다.


```css
/* home.css */
.title {
  color: red;
}
```


```css
/* about.css */
.title {
  color: blue;
}
```


두 파일 모두 `.title` 클래스를 정의하므로, 나중에 로드된 스타일이 이전 스타일을 덮어쓴다.


CSS Modules는 각 클래스명을 **유니크한 이름으로 자동 변환**하여 이 문제를 해결한다.


```css
/* 원본 */
.title {
  color: red;
}

/* 빌드 후 실제 클래스명 */
.Home_title__abc123 {
  color: red;
}
```


### 사용법


CSS Modules를 사용하려면 파일명을 `.module.css` 형식으로 만든다.


```css
/* components/Button.module.css */
.button {
  padding: 12px 24px;
  background: #0070f3;
  color: white;
  border: none;
  border-radius: 4px;
  cursor: pointer;
}

.button:hover {
  background: #0051cc;
}
```


컴포넌트에서 import하여 사용한다.


```typescript
// components/Button.tsx
import styles from './Button.module.css';

export default function Button({ children }: { children: React.ReactNode }) {
  return <button className={styles.button}>{children}</button>;
}
```


`styles.button`은 빌드 시 `Button_button__abc123`과 같은 유니크한 클래스명으로 변환된다.


### 여러 클래스 사용하기


여러 클래스를 함께 사용하려면 템플릿 리터럴이나 배열을 사용한다.


```css
/* Card.module.css */
.card {
  padding: 20px;
  border: 1px solid #ddd;
  border-radius: 8px;
}

.featured {
  border-color: #0070f3;
  background: #f0f8ff;
}
```


```typescript
// Card.tsx
import styles from './Card.module.css';

export default function Card({ featured }: { featured?: boolean }) {
  return (
    <div className={`${styles.card} ${featured ? styles.featured : ''}`}>
      카드 내용
    </div>
  );
}
```


### 글로벌 클래스와 함께 사용


CSS Modules 내에서 글로벌 클래스를 선택해야 할 때는 `:global` 선택자를 사용한다.


```css
/* Component.module.css */
.wrapper :global(.external-class) {
  color: red;
}
```


## 참고 자료

- [Next.js 공식 문서 - Styling](https://nextjs.org/docs/pages/building-your-application/styling)
- [Next.js 공식 문서 - CSS Modules](https://nextjs.org/docs/pages/building-your-application/styling/css-modules)


Styling


사전에(pre-) 미리 불러온다(fetching).


연결되어 있는 페이지들을 사전에 미리 불러온다. 빠른 페이지 이동을 위해 미리 데이터를 로드해둔다.


## 왜 Prefetching이 필요한가?


생각해보면 이 기능은 뭔가 이상하다. 초기 접속 이후의 활동들은 서버에게 별도 추가 요청 없이 브라우저에서 직접 React 컴포넌트를 교체하는 방식으로 처리한다. 그렇기 때문에 페이지를 이동하더라도 브라우저가 서버에게 추가 리소스를 요구하지 않는 것으로 알고 있는데 prefetching은 왜 있는가?


### Code Splitting


Next.js는 모든 JavaScript 코드를 자동으로 페이지별로 분리(splitting)해서 저장한다. **모든 코드가 전달되는 것이 아니라 현재 페이지의 번들만 전달된다**. `/search`로 접속하면 search 페이지의 번들만 전달된다.


이렇게 하는 이유는 파일 크기를 줄이기 위해서다. 모든 페이지의 번들을 한 번에 전달하면 용량이 커져서 하이드레이션이 늦어진다. 그럼 **TTI(Time To Interactive)가 최종적으로 늦어진다.


따라서 페이지를 이동할 때는 해당 페이지의 번들을 새로 요청해야 한다. Prefetching은 페이지 이동 요청 전에 미리 번들을 불러오는 방식이다.


## Prefetching 확인하기


### 개발 모드에서는 작동하지 않는다


`npm run dev`로 실행하면 prefetching이 작동하지 않는다. 페이지를 이동할 때마다 번들을 매번 불러온다.


Prefetching 동작을 제대로 확인하려면 **build 후 production 모드**로 실행해야 한다. `npm run build`를 하면 페이지별로 빌드 결과가 출력된다.


```plain text
Route (pages)                             Size     First Load JS
┌ ○ /                                     256 B          82.7 kB
├   /_app                                 0 B            82.5 kB
├ ○ /404                                  180 B          82.7 kB
├ ƒ /api/hello                            0 B            82.5 kB
├ ○ /book/[id]                            300 B          82.8 kB
└ ○ /search                               296 B          82.8 kB
+ First Load JS shared by all             82.5 kB
  ├ chunks/framework-64ad27b21261a9ce.js  44.8 kB
  ├ chunks/main-a2464d6d00b134e7.js       34 kB
  └ other shared chunks (total)           3.61 kB

○  (Static)   prerendered as static content
ƒ  (Dynamic)  server-rendered on demand
```


위 결과에서 각 페이지별로 번들이 분리(splitting)되어 있는 것을 확인할 수 있다. 각 페이지는 독립적인 크기를 갖고 있으며, 공통 코드는 "shared by all"로 분리되어 있다.


### Production 모드에서 확인


Code splitting이 되는 것을 확인했다. `npm run start`를 하면 `localhost:3000`에서 네트워크 탭을 열었을 때 많은 요청이 일어난다. search, book에 필요한 페이지들도 모두 prefetching 되어 있다.


브라우저 개발자 도구의 Network 탭을 열고 페이지를 로드하면, 현재 페이지뿐만 아니라 화면에 보이는 Link 컴포넌트가 가리키는 페이지들의 번들도 함께 다운로드된다.


## Link 컴포넌트의 자동 Prefetching


Link 컴포넌트로 구현된 링크는 자동으로 prefetching이 이루어진다.


`Link` 컴포넌트는 기본적으로 **viewport에 보이는 링크를 자동으로 prefetch**한다. 사용자가 링크를 클릭하기 전에 미리 페이지를 로드해두기 때문에 즉각적인 페이지 전환이 가능하다.


```typescript
import Link from 'next/link';

export default function Navigation() {
  return (
    <nav>
      {/* 이 링크들은 viewport에 보이면 자동으로 prefetch된다 */}
      <Link href="/">홈</Link>
      <Link href="/about">소개</Link>
      <Link href="/blog">블로그</Link>
    </nav>
  );
}
```


이 기능은 **프로덕션 빌드에서만 동작**하며, 개발 모드에서는 작동하지 않는다.


## 프로그래매틱 네비게이션의 수동 Prefetching


프로그래매틱하게 구현된 네비게이션은 페이지 이동 시 번들을 다시 요청한다. 여기에서도 prefetching을 하고 싶다면 컴포넌트 마운트 시 router 객체의 메서드를 통해 수동으로 prefetching할 수 있다.


```typescript
import { useRouter } from 'next/router';
import { useEffect } from 'react';

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

  useEffect(() => {
    // 컴포넌트 마운트 시 /test 페이지를 미리 로드
    router.prefetch('/test');
  }, []);

  const handleClick = () => {
    // 이미 prefetch되어 있으므로 즉시 이동
    router.push('/test');
  };

  return <button onClick={handleClick}>테스트 페이지로 이동</button>;
}
```


`router.prefetch()`를 사용하면 특정 페이지의 번들을 미리 로드할 수 있다. 이후 `router.push()`로 페이지 이동 시 즉각적인 전환이 가능하다.


### 조건부 Prefetching


특정 조건에서만 prefetch하고 싶을 때도 사용할 수 있다.


```typescript
import { useRouter } from 'next/router';
import { useEffect } from 'react';

export default function Dashboard({ user }) {
  const router = useRouter();

  useEffect(() => {
    // 관리자일 경우에만 admin 페이지를 prefetch
    if (user.isAdmin) {
      router.prefetch('/admin');
    }
  }, [user.isAdmin]);

  return <div>대시보드</div>;
}
```


## Prefetching 비활성화


Prefetching을 하고 싶지 않다면 `prefetch={false}`를 설정한다.


대용량 페이지나 데이터가 자주 변경되는 페이지의 경우 불필요한 네트워크 요청을 줄이고 싶을 수 있다. `Link` 컴포넌트에서 `prefetch={false}`를 설정하면 자동 prefetch를 비활성화할 수 있다.


```typescript
import Link from 'next/link';

export default function Navigation() {
  return (
    <nav>
      {/* 일반 페이지는 prefetch */}
      <Link href="/">홈</Link>

      {/* 대용량 페이지는 prefetch 비활성화 */}
      <Link href="/heavy-page" prefetch={false}>
        대용량 페이지
      </Link>

      {/* 자주 변경되는 페이지도 prefetch 비활성화 */}
      <Link href="/live-data" prefetch={false}>
        실시간 데이터
      </Link>
    </nav>
  );
}
```


## 정리

- **Code Splitting**: Next.js는 페이지별로 번들을 자동으로 분리한다
- **Prefetching**: 페이지 이동 전에 미리 번들을 로드하여 빠른 전환을 가능하게 한다
- **Link 컴포넌트**: viewport에 보이는 링크를 자동으로 prefetch (프로덕션 모드에서만)
- **router.prefetch()**: 수동으로 특정 페이지를 미리 로드
- **prefetch={false}**: Link 컴포넌트의 자동 prefetch를 비활성화
- **개발 모드**: prefetching이 작동하지 않으므로 테스트는 production 모드에서

## 참고 자료

- [Next.js 공식 문서 - Link prefetching](https://nextjs.org/docs/pages/api-reference/components/link#prefetch)
- [[Navigating]] - 페이지 간 이동 방법


Prefetching


Next.js에서 페이지 간 이동하는 방법을 다룬다. Link 컴포넌트와 useRouter 훅을 사용하여 클라이언트 사이드 네비게이션을 구현한다.


## a 태그 vs Link 컴포넌트


HTML의 `<a>` 태그는 매번 서버에 새로운 페이지를 요청한다. 페이지 전체가 새로고침되며 JavaScript 상태가 초기화된다.


```typescript
// 느린 방식 - 전체 페이지 새로고침
<a href="/about">소개</a>
```


Next.js의 `Link` 컴포넌트는 **클라이언트 사이드 네비게이션**을 제공한다. 페이지 전체를 새로고침하지 않고 필요한 부분만 업데이트한다.


```typescript
// 빠른 방식 - 클라이언트 사이드 네비게이션
import Link from 'next/link';

<Link href="/about">소개</Link>
```


`Link` 컴포넌트를 사용하면 다음과 같은 장점이 있다.

- 페이지 전환이 즉각적이다
- JavaScript 상태가 유지된다
- viewport에 보이는 링크를 미리 로드한다 (자세한 내용은 [[prefetching]] 참조)
- 브라우저 히스토리가 정상적으로 동작한다

## Link 컴포넌트


`next/link`에서 제공하는 `Link` 컴포넌트는 페이지 간 이동의 기본이다.


### 기본 사용법


```typescript
import Link from 'next/link';

export default function Navigation() {
  return (
    <header>
      <Link href="/">index</Link>
      &nbsp;
      <Link href="/search">search</Link>
      &nbsp;
      <Link href="/book/1">book/1</Link>
    </header>
  );
}
```


`href` prop에 이동할 경로를 문자열로 전달한다.


### 동적 경로에 Link 사용


동적 경로는 문자열 보간이나 객체 형태로 전달할 수 있다.


```typescript
import Link from 'next/link';

export default function PostList() {
  const posts = [
    { id: 1, title: '첫 번째 포스트' },
    { id: 2, title: '두 번째 포스트' },
    { id: 3, title: '세 번째 포스트' },
  ];

  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>
          {/* 문자열 보간 방식 */}
          <Link href={`/posts/${post.id}`}>{post.title}</Link>
        </li>
      ))}
    </ul>
  );
}
```


객체 형태로도 전달할 수 있다.


```typescript
<Link
  href={{
    pathname: '/posts/[id]',
    query: { id: post.id },
  }}
>
  {post.title}
</Link>
```


Query String도 함께 전달할 수 있다.


```typescript
// 문자열 방식
<Link href="/posts/1?comments=true">포스트 1</Link>

// 객체 방식
<Link
  href={{
    pathname: '/posts/[id]',
    query: { id: 1, comments: 'true' },
  }}
>
  포스트 1
</Link>
```


### 외부 링크


외부 링크는 일반 `<a>` 태그를 사용한다.


```typescript
{/* 외부 링크는 a 태그 사용 */}
<a href="<https://github.com>" target="_blank" rel="noopener noreferrer">
  GitHub
</a>

{/* 내부 링크는 Link 컴포넌트 사용 */}
<Link href="/about">소개</Link>
```


## useRouter 훅


`useRouter` 훅은 현재 라우터 정보에 접근하고 프로그래매틱하게 네비게이션을 제어할 수 있게 한다.

> 주의: next/router 사용useRouter는 next/router에서 import 해야 한다. next/navigation의 useRouter는 App Router 전용이다.

```typescript
import { useRouter } from 'next/router';

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

  console.log(router.pathname);  // 현재 경로 패턴 (예: /posts/[id])
  console.log(router.asPath);    // 브라우저 주소창의 전체 경로 (예: /posts/123?sort=latest)
  console.log(router.query);     // 쿼리 파라미터 객체 (예: { id: '123', sort: 'latest' })

  return <div>페이지</div>;
}
```


### router 주요 속성

- `pathname`: 현재 페이지의 경로 패턴 (동적 세그먼트는 대괄호 형태)
- `asPath`: 실제 브라우저에 표시되는 전체 경로
- `query`: URL 파라미터와 Query String을 담은 객체
- `route`: `pathname`과 동일

### Query String 접근


`router.query`로 URL의 모든 파라미터에 접근할 수 있다.


```typescript
// pages/search.tsx
import { useRouter } from 'next/router';

export default function Search() {
  const router = useRouter();
  const { q, sort } = router.query;

  return (
    <div>
      <h1>검색어: {q}</h1>
      <p>정렬: {sort}</p>
    </div>
  );
}
```


`/search?q=nextjs&sort=latest`에 접속하면 `q`는 `"nextjs"`, `sort`는 `"latest"`가 된다.


동적 라우팅 파라미터와 Query String이 모두 `router.query`에 통합된다.


```typescript
// pages/posts/[id].tsx
import { useRouter } from 'next/router';

export default function Post() {
  const router = useRouter();
  const { id, comments } = router.query;

  return (
    <div>
      <h1>포스트 ID: {id}</h1>
      {comments && <p>댓글 표시 모드</p>}
    </div>
  );
}
```


`/posts/123?comments=true`에 접속하면 `id`는 `"123"`, `comments`는 `"true"`가 된다.


## 프로그래매틱 네비게이션


특정 조건이 충족되었을 때 코드로 페이지를 이동할 수 있다. `router.push()`와 `router.replace()`를 사용한다.


### router.push()


`router.push()`는 새로운 URL을 브라우저 히스토리에 추가하고 이동한다. 뒤로가기 버튼으로 이전 페이지로 돌아갈 수 있다.


```typescript
import { useRouter } from 'next/router';

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

  const handleLogin = async () => {
    // 로그인 로직...
    const success = true;

    if (success) {
      // 로그인 성공 후 대시보드로 이동
      router.push('/dashboard');
    }
  };

  return <button onClick={handleLogin}>로그인</button>;
}
```


Query String이나 동적 세그먼트도 전달할 수 있다.


```typescript
// 문자열 형태
router.push('/posts/123?sort=latest');

// 객체 형태
router.push({
  pathname: '/posts/[id]',
  query: { id: '123', sort: 'latest' },
});
```


### router.replace()


`router.replace()`는 현재 히스토리를 대체한다. 뒤로가기를 눌렀을 때 이전 페이지로 돌아가지 않는다.


```typescript
const handleRedirect = () => {
  // 히스토리에 추가하지 않고 대체
  router.replace('/new-page');
};
```


로그인 후 리다이렉트처럼 사용자가 뒤로가기로 돌아가지 못하게 하고 싶을 때 사용한다.


```typescript
import { useRouter } from 'next/router';

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

  const handleLogin = async () => {
    // 로그인 로직...
    const success = true;

    if (success) {
      // 뒤로가기로 로그인 페이지로 돌아가지 않도록 replace 사용
      router.replace('/dashboard');
    }
  };

  return <button onClick={handleLogin}>로그인</button>;
}
```


### router.back()


브라우저 히스토리에서 뒤로 이동한다.


```typescript
import { useRouter } from 'next/router';

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

  return (
    <div>
      <button onClick={() => router.back()}>뒤로 가기</button>
      <h1>포스트 상세</h1>
    </div>
  );
}
```


### router.reload()


현재 페이지를 새로고침한다. 서버에서 다시 페이지를 가져온다.


```typescript
const handleReload = () => {
  router.reload();
};
```


## push vs replace 비교


```typescript
import { useRouter } from 'next/router';

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

  return (
    <div>
      {/* push: 히스토리에 추가, 뒤로가기 가능 */}
      <button onClick={() => router.push('/page-a')}>
        Page A로 이동 (push)
      </button>

      {/* replace: 히스토리 대체, 뒤로가기로 돌아올 수 없음 */}
      <button onClick={() => router.replace('/page-b')}>
        Page B로 이동 (replace)
      </button>

      {/* back: 이전 페이지로 */}
      <button onClick={() => router.back()}>
        뒤로 가기
      </button>
    </div>
  );
}
```


## 참고 자료

- [Next.js 공식 문서 - next/link](https://nextjs.org/docs/pages/api-reference/components/link)
- [Next.js 공식 문서 - useRouter](https://nextjs.org/docs/pages/api-reference/functions/use-router)


Navigating


Next.js에서 서버 사이드 API 엔드포인트를 만들 수 있는 기능이다. `pages/api` 폴더 안에 파일을 생성하면 자동으로 API 엔드포인트가 된다.


## 왜 필요한가?


프론트엔드 애플리케이션을 만들 때 종종 서버와 통신할 API가 필요하다. 일반적으로는 별도의 백엔드 서버(Express, Django 등)를 구축하지만, Next.js는 **같은 프로젝트 내에서 API를 만들 수 있다**.


이렇게 하면 다음과 같은 장점이 있다.

- 별도의 백엔드 서버 없이 API를 만들 수 있다
- 같은 코드베이스에서 프론트엔드와 백엔드를 관리할 수 있다
- 배포가 간단하다 (하나의 프로젝트로 배포)
- TypeScript 타입을 공유할 수 있다

간단한 API가 필요한 경우나, 서버리스 함수로 충분한 경우에 유용하다.


## 기본 구조


`pages/api` 폴더 안에 파일을 만들면 자동으로 API 엔드포인트가 된다.


```plain text
pages/
└── api/
    ├── hello.ts         → /api/hello
    ├── users.ts         → /api/users
    └── posts/
        └── [id].ts      → /api/posts/:id
```


파일 이름이 곧 API 경로가 된다. 페이지 라우팅과 동일한 방식이다.


## 기본 핸들러 작성


API Route는 `handler` 함수를 default export 해야 한다.


```typescript
// pages/api/hello.ts
import type { NextApiRequest, NextApiResponse } from 'next';

export default function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  res.status(200).json({ message: 'Hello from API' });
}
```


`handler` 함수는 두 개의 인자를 받는다.

- `req`: HTTP 요청 정보를 담은 객체
- `res`: HTTP 응답을 보내는 객체

위 코드는 `/api/hello`로 요청이 오면 `{ message: 'Hello from API' }` JSON을 200 상태 코드와 함께 응답한다.


## HTTP 메서드 처리


`req.method`로 HTTP 메서드를 확인하여 다르게 처리할 수 있다.


```typescript
// pages/api/users.ts
import type { NextApiRequest, NextApiResponse } from 'next';

export default function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  if (req.method === 'GET') {
    // 사용자 목록 조회
    res.status(200).json({ users: ['Alice', 'Bob'] });
  } else if (req.method === 'POST') {
    // 새 사용자 생성
    const { name } = req.body;
    res.status(201).json({ message: `Created user: ${name}` });
  } else {
    // 지원하지 않는 메서드
    res.status(405).json({ message: 'Method not allowed' });
  }
}
```


일반적인 HTTP 메서드는 다음과 같다.

- `GET`: 데이터 조회
- `POST`: 데이터 생성
- `PUT`: 데이터 전체 수정
- `PATCH`: 데이터 부분 수정
- `DELETE`: 데이터 삭제

## Request 처리


### Query 파라미터


URL의 쿼리 파라미터는 `req.query`로 접근한다.


```typescript
// pages/api/search.ts
export default function handler(req: NextApiRequest, res: NextApiResponse) {
  const { q, page } = req.query;

  res.status(200).json({
    query: q,
    page: page || '1'
  });
}
```


`/api/search?q=nextjs&page=2`로 요청하면 `q`는 `"nextjs"`, `page`는 `"2"`가 된다.


### Request Body


POST, PUT 등의 요청에서 본문 데이터는 `req.body`로 접근한다.


```typescript
// pages/api/posts.ts
export default function handler(req: NextApiRequest, res: NextApiResponse) {
  if (req.method === 'POST') {
    const { title, content } = req.body;

    // 데이터베이스에 저장하는 로직...

    res.status(201).json({
      id: 1,
      title,
      content,
      createdAt: new Date().toISOString()
    });
  } else {
    res.status(405).json({ message: 'Method not allowed' });
  }
}
```


클라이언트에서 JSON으로 요청을 보내면 Next.js가 자동으로 파싱해준다.


### Cookies


쿠키는 `req.cookies`로 접근한다.


```typescript
export default function handler(req: NextApiRequest, res: NextApiResponse) {
  const token = req.cookies.token;

  if (!token) {
    res.status(401).json({ message: 'Unauthorized' });
    return;
  }

  res.status(200).json({ message: 'Authenticated' });
}
```


## Response 처리


### 상태 코드


`res.status()`로 HTTP 상태 코드를 설정한다.


```typescript
// 성공
res.status(200).json({ success: true });

// 생성됨
res.status(201).json({ id: 1 });

// 잘못된 요청
res.status(400).json({ error: 'Bad request' });

// 인증 필요
res.status(401).json({ error: 'Unauthorized' });

// 권한 없음
res.status(403).json({ error: 'Forbidden' });

// 찾을 수 없음
res.status(404).json({ error: 'Not found' });

// 서버 오류
res.status(500).json({ error: 'Internal server error' });
```


### JSON 응답


`res.json()`으로 JSON 응답을 보낸다.


```typescript
export default function handler(req: NextApiRequest, res: NextApiResponse) {
  res.status(200).json({
    name: 'John Doe',
    age: 30,
    hobbies: ['reading', 'coding']
  });
}
```


### 리다이렉트


`res.redirect()`로 다른 경로로 리다이렉트할 수 있다.


```typescript
export default function handler(req: NextApiRequest, res: NextApiResponse) {
  res.redirect(307, '/api/new-endpoint');
}
```


## 동적 API 라우트


페이지 라우팅과 마찬가지로 동적 세그먼트를 사용할 수 있다.


### 단일 동적 세그먼트


```typescript
// pages/api/posts/[id].ts
export default function handler(req: NextApiRequest, res: NextApiResponse) {
  const { id } = req.query;

  if (req.method === 'GET') {
    // ID로 포스트 조회
    res.status(200).json({
      id,
      title: `Post ${id}`,
      content: 'Content here'
    });
  } else if (req.method === 'DELETE') {
    // ID로 포스트 삭제
    res.status(200).json({ message: `Deleted post ${id}` });
  }
}
```


`/api/posts/123`으로 요청하면 `id`는 `"123"`이 된다.


### Catch-all 라우트


```typescript
// pages/api/posts/[...slug].ts
export default function handler(req: NextApiRequest, res: NextApiResponse) {
  const { slug } = req.query;

  // slug는 배열로 전달됨
  res.status(200).json({
    path: slug
  });
}
```

- `/api/posts/a` → `slug = ["a"]`
- `/api/posts/a/b` → `slug = ["a", "b"]`
- `/api/posts/a/b/c` → `slug = ["a", "b", "c"]`

## 환경 변수 사용


API Route는 서버에서만 실행되므로 환경 변수를 안전하게 사용할 수 있다.


```typescript
// pages/api/secret.ts
export default function handler(req: NextApiRequest, res: NextApiResponse) {
  const apiKey = process.env.SECRET_API_KEY;

  // 외부 API 호출 등에 사용
  res.status(200).json({ message: 'Success' });
}
```


`.env.local` 파일에 환경 변수를 정의한다.


```plain text
SECRET_API_KEY=your-secret-key
DATABASE_URL=postgresql://...
```


환경 변수는 클라이언트 번들에 포함되지 않으므로 민감한 정보를 안전하게 사용할 수 있다.


## 설정 옵션


API Route의 동작을 커스터마이징할 수 있다.


### Body Parser 설정


기본적으로 Next.js는 요청 본문을 자동으로 파싱한다. 이를 비활성화하거나 크기 제한을 설정할 수 있다.


```typescript
export const config = {
  api: {
    bodyParser: {
      sizeLimit: '1mb', // 요청 본문 크기 제한
    },
  },
};

export default function handler(req: NextApiRequest, res: NextApiResponse) {
  // 핸들러 로직
}
```


Body parser를 완전히 비활성화하려면 다음과 같이 한다.


```typescript
export const config = {
  api: {
    bodyParser: false,
  },
};
```


파일 업로드나 스트리밍을 처리할 때 유용하다.


### 실행 시간 제한


서버리스 환경에서 실행 시간을 제한할 수 있다.


```typescript
export const config = {
  api: {
    maxDuration: 5, // 최대 5초
  },
};
```


## 주의사항


### 클라이언트 번들에 포함되지 않는다


API Routes의 코드는 **클라이언트 번들에 포함되지 않는다**. 서버에서만 실행된다.


따라서 다음을 안전하게 사용할 수 있다.

- 데이터베이스 쿼리
- 환경 변수
- 서버 전용 라이브러리
- 비밀 키

### CORS 처리


다른 도메인에서 API를 호출해야 한다면 CORS 헤더를 설정해야 한다.


```typescript
export default function handler(req: NextApiRequest, res: NextApiResponse) {
  // CORS 헤더 설정
  res.setHeader('Access-Control-Allow-Origin', '*');
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type');

  // Preflight 요청 처리
  if (req.method === 'OPTIONS') {
    res.status(200).end();
    return;
  }

  // 실제 로직
  res.status(200).json({ message: 'Hello' });
}
```


### 정적 생성과 함께 사용할 수 없다


API Routes는 서버에서 실행되므로 정적 사이트 생성(SSG) 시에는 호출할 수 없다. `getStaticProps`에서 API Route를 호출하면 안 된다.


대신 데이터를 직접 가져오는 로직을 공유한다.


```typescript
// lib/data.ts
export async function getProducts() {
  // 데이터베이스 쿼리
  return products;
}

// pages/api/products.ts
import { getProducts } from '@/lib/data';

export default async function handler(req, res) {
  const products = await getProducts();
  res.status(200).json(products);
}

// pages/index.tsx
import { getProducts } from '@/lib/data';

export async function getStaticProps() {
  const products = await getProducts(); // API Route 호출 X, 직접 호출 O
  return { props: { products } };
}
```


## 참고 자료

- [Next.js 공식 문서 - API Routes](https://nextjs.org/docs/pages/building-your-application/routing/api-routes)


API Routes


Next.js의 Page Router는 `pages` 폴더 내의 파일 구조를 기반으로 자동으로 라우팅을 생성하는 시스템이다. 별도의 라우팅 설정 파일 없이 파일과 폴더만으로 URL 경로를 정의할 수 있다.

> Page Router vs App Router  
> Next.js 13부터 App Router가 도입되었지만, Page Router는 여전히 안정적이고 널리 사용된다. App Router는 Server Components를 기본으로 하는 새로운 패러다임이며, Page Router는 기존의 Client-side Navigation을 중심으로 한다.

## 기본 라우팅


`pages` 폴더 내의 파일이 자동으로 라우트가 된다. 파일명이 곧 URL 경로다.


```plain text
pages/
├── index.tsx          → /
├── about.tsx          → /about
├── contact.tsx        → /contact
└── products.tsx       → /products
```


위 구조에서 `index.tsx`는 루트 경로 `/`에 매핑되고, `about.tsx`는 `/about` 경로에 매핑된다.


```typescript
// pages/index.tsx
export default function Home() {
  return <h1>홈 페이지</h1>;
}
```


```typescript
// pages/about.tsx
export default function About() {
  return <h1>소개 페이지</h1>;
}
```


각 파일은 기본적으로 React 컴포넌트를 default export 해야 한다. Next.js는 이 컴포넌트를 자동으로 페이지로 렌더링한다.


## 중첩 라우팅


폴더를 사용하면 중첩된 경로를 만들 수 있다.


```plain text
pages/
├── index.tsx              → /
├── blog/
│   ├── index.tsx          → /blog
│   ├── first-post.tsx     → /blog/first-post
│   └── second-post.tsx    → /blog/second-post
└── products/
    ├── index.tsx          → /products
    └── electronics.tsx    → /products/electronics
```


폴더 내의 `index.tsx`는 해당 폴더 경로의 기본 페이지가 된다. 예를 들어 `blog/index.tsx`는 `/blog` 경로에 매핑된다.


```typescript
// pages/blog/index.tsx
export default function Blog() {
  return <h1>블로그 목록</h1>;
}
```


```typescript
// pages/blog/first-post.tsx
export default function FirstPost() {
  return <h1>첫 번째 포스트</h1>;
}
```


이렇게 폴더 구조만으로 직관적인 URL 계층을 구성할 수 있다.


## 동적 라우팅 (URL Parameter)


동적 경로를 갖는 페이지를 생성하려면 파일명을 대괄호로 감싸면 된다. `[id].tsx`와 같이 작성하면 해당 부분이 동적 세그먼트가 된다.


```plain text
pages/
└── posts/
    ├── index.tsx          → /posts
    └── [id].tsx           → /posts/:id
```


`[id].tsx` 파일은 `/posts/1`, `/posts/abc`, `/posts/hello` 등 모든 경로에 매칭된다.


```typescript
// pages/posts/[id].tsx
import { useRouter } from 'next/router';

export default function Post() {
  const router = useRouter();
  const { id } = router.query;

  return <h1>포스트 ID: {id}</h1>;
}
```


위 코드에서 `useRouter` 훅을 통해 URL의 동적 파라미터에 접근할 수 있다. `router.query` 객체에서 파일명에 정의한 `id`를 구조 분해 할당으로 가져온다.


사용자가 `/posts/123`에 접속하면 `id`는 `"123"`이 되고, `/posts/hello`에 접속하면 `id`는 `"hello"`가 된다.


### 여러 동적 세그먼트


여러 동적 세그먼트를 조합할 수도 있다.


```plain text
pages/
└── posts/
    └── [category]/
        └── [id].tsx       → /posts/:category/:id
```


```typescript
// pages/posts/[category]/[id].tsx
import { useRouter } from 'next/router';

export default function Post() {
  const router = useRouter();
  const { category, id } = router.query;

  return (
    <div>
      <h1>카테고리: {category}</h1>
      <p>포스트 ID: {id}</p>
    </div>
  );
}
```


`/posts/tech/123`에 접속하면 `category`는 `"tech"`, `id`는 `"123"`이 된다.


## Query String


Query String은 페이지 경로에 영향을 주지 않으며, `?` 뒤에 오는 파라미터들을 의미한다. 예를 들어 `/search?q=nextjs&sort=latest`에서 `q`와 `sort`가 Query String이다.


별도의 설정 없이 `useRouter` 훅으로 접근할 수 있다.

> 주의: next/router 사용useRouter는 next/router에서 import 해야 한다. next/navigation의 useRouter는 App Router 전용이므로 Page Router에서는 사용할 수 없다.

```typescript
// pages/search.tsx
import { useRouter } from 'next/router';

export default function Search() {
  const router = useRouter();
  const { q, sort } = router.query;

  return (
    <div>
      <h1>검색어: {q}</h1>
      <p>정렬: {sort}</p>
    </div>
  );
}
```


사용자가 `/search?q=nextjs&sort=latest`에 접속하면 `q`는 `"nextjs"`, `sort`는 `"latest"`가 된다.


Query String은 동적 라우팅 파라미터와 함께 사용할 수도 있다. 모든 파라미터는 `router.query`에 통합된다.


```typescript
// pages/posts/[id].tsx
import { useRouter } from 'next/router';

export default function Post() {
  const router = useRouter();
  const { id, comments } = router.query;

  return (
    <div>
      <h1>포스트 ID: {id}</h1>
      {comments && <p>댓글 표시 모드</p>}
    </div>
  );
}
```


`/posts/123?comments=true`에 접속하면 `id`는 `"123"`, `comments`는 `"true"`가 된다.


## Catch-all Routes


단일 동적 세그먼트는 한 단계의 경로만 매칭한다. `/posts/[id].tsx`는 `/posts/123`은 매칭하지만 `/posts/123/comments`는 매칭하지 못한다.


여러 단계의 경로를 한 번에 처리하려면 **Catch-all Routes**를 사용한다. 대괄호 안에 `...`을 붙이면 된다.


```plain text
pages/
└── docs/
    └── [...slug].tsx      → /docs/* (모든 하위 경로)
```


`[...slug].tsx`는 `/docs/a`, `/docs/a/b`, `/docs/a/b/c` 등 모든 하위 경로를 매칭한다.


```typescript
// pages/docs/[...slug].tsx
import { useRouter } from 'next/router';

export default function Docs() {
  const router = useRouter();
  const { slug } = router.query;

  // slug는 배열로 전달됨
  return (
    <div>
      <h1>문서 경로</h1>
      <p>세그먼트: {Array.isArray(slug) ? slug.join(' / ') : slug}</p>
    </div>
  );
}
```


위 코드에서 `slug`는 경로 세그먼트를 배열로 담는다.

- `/docs/introduction` 접속 시: `slug = ["introduction"]`
- `/docs/getting-started/installation` 접속 시: `slug = ["getting-started", "installation"]`
- `/docs/api/hooks/useRouter` 접속 시: `slug = ["api", "hooks", "useRouter"]`

배열의 각 요소가 경로의 각 세그먼트에 해당한다. 이를 활용해 동적으로 컨텐츠를 렌더링하거나 파일 시스템에서 마크다운 파일을 읽어올 수 있다.


### Catch-all Routes의 한계


하지만 `[...slug].tsx`는 최소 하나의 세그먼트가 필요하다. `/docs`에는 매칭되지 않고 `/docs/something`부터 매칭된다.


`/docs`도 같은 컴포넌트로 처리하고 싶다면 두 가지 방법이 있다.

1. `docs/index.tsx`를 별도로 만든다
2. **Optional Catch-all Routes**를 사용한다

## Optional Catch-all Routes


대괄호를 한 번 더 감싸면 Optional Catch-all Routes가 된다.


```plain text
pages/
└── docs/
    └── [[...slug]].tsx    → /docs 및 /docs/* (모든 하위 경로)
```


`[[...slug]].tsx`는 `/docs`도 매칭하고, `/docs/a`, `/docs/a/b` 등 모든 하위 경로도 매칭한다.


```typescript
// pages/docs/[[...slug]].tsx
import { useRouter } from 'next/router';

export default function Docs() {
  const router = useRouter();
  const { slug } = router.query;

  if (!slug) {
    // /docs 경로
    return <h1>문서 홈</h1>;
  }

  // /docs/* 경로
  return (
    <div>
      <h1>문서 경로</h1>
      <p>세그먼트: {slug.join(' / ')}</p>
    </div>
  );
}
```

- `/docs` 접속 시: `slug = undefined`
- `/docs/introduction` 접속 시: `slug = ["introduction"]`
- `/docs/api/hooks` 접속 시: `slug = ["api", "hooks"]`

이렇게 하면 하나의 컴포넌트로 모든 문서 경로를 처리할 수 있다.


## Link 컴포넌트


Next.js에서 페이지 간 이동은 `next/link`의 `Link` 컴포넌트를 사용한다. HTML의 `<a>` 태그와 달리 **클라이언트 사이드 네비게이션**을 제공한다.


```typescript
import Link from 'next/link';

export default function Nav() {
  return (
    <nav>
      <Link href="/">홈</Link>
      <Link href="/about">소개</Link>
      <Link href="/blog">블로그</Link>
    </nav>
  );
}
```


`Link` 컴포넌트를 사용하면 페이지 전체를 새로고침하지 않고 필요한 부분만 업데이트한다. 이를 통해 빠른 페이지 전환과 상태 유지가 가능하다.


### 동적 경로에 Link 사용


동적 경로는 문자열 보간이나 객체 형태로 전달할 수 있다.


```typescript
import Link from 'next/link';

export default function PostList() {
  const posts = [
    { id: 1, title: '첫 번째 포스트' },
    { id: 2, title: '두 번째 포스트' },
  ];

  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>
          <Link href={`/posts/${post.id}`}>{post.title}</Link>
        </li>
      ))}
    </ul>
  );
}
```


객체 형태로도 전달할 수 있다.


```typescript
<Link
  href={{
    pathname: '/posts/[id]',
    query: { id: post.id },
  }}
>
  {post.title}
</Link>
```


### Prefetching


`Link` 컴포넌트는 기본적으로 viewport에 보이는 링크를 **자동으로 prefetch**한다. 사용자가 링크를 클릭하기 전에 미리 페이지를 로드해두기 때문에 즉각적인 페이지 전환이 가능하다.


프로덕션 빌드에서만 동작하며, `prefetch={false}`로 비활성화할 수 있다.


```typescript
<Link href="/about" prefetch={false}>
  소개
</Link>
```


## useRouter 훅


`useRouter` 훅은 현재 라우터 정보에 접근하고 프로그래매틱하게 네비게이션을 제어할 수 있게 한다.


```typescript
import { useRouter } from 'next/router';

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

  console.log(router.pathname);  // 현재 경로 (예: /posts/[id])
  console.log(router.asPath);    // 브라우저에 표시되는 전체 경로 (예: /posts/123?sort=latest)
  console.log(router.query);     // 쿼리 파라미터 객체 (예: { id: '123', sort: 'latest' })

  return <div>페이지</div>;
}
```


주요 속성은 다음과 같다.

- `pathname`: 현재 페이지의 경로 패턴 (동적 세그먼트는 대괄호 형태로 표시됨)
- `asPath`: 실제 브라우저에 표시되는 전체 경로
- `query`: URL 파라미터와 Query String을 담은 객체
- `route`: `pathname`과 동일

## 프로그래매틱 네비게이션


`Link` 컴포넌트 외에 코드로 페이지를 이동할 수 있다. `router.push()`와 `router.replace()`를 사용한다.


### router.push()


`router.push()`는 새로운 URL을 브라우저 히스토리에 추가하고 이동한다.


```typescript
import { useRouter } from 'next/router';

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

  const handleLogin = async () => {
    // 로그인 로직...

    // 로그인 성공 후 대시보드로 이동
    router.push('/dashboard');
  };

  return <button onClick={handleLogin}>로그인</button>;
}
```


Query String이나 동적 세그먼트도 전달할 수 있다.


```typescript
// 문자열 형태
router.push('/posts/123?sort=latest');

// 객체 형태
router.push({
  pathname: '/posts/[id]',
  query: { id: '123', sort: 'latest' },
});
```


### router.replace()


`router.replace()`는 현재 히스토리를 대체한다. 뒤로가기를 눌렀을 때 이전 페이지로 돌아가지 않는다.


```typescript
const handleRedirect = () => {
  // 히스토리에 추가하지 않고 대체
  router.replace('/new-page');
};
```


로그인 후 리다이렉트처럼 사용자가 뒤로가기로 돌아가지 못하게 하고 싶을 때 유용하다.


### 기타 메서드

- `router.back()`: 브라우저 히스토리에서 뒤로 이동
- `router.reload()`: 현재 페이지 새로고침
- `router.prefetch(url)`: 특정 페이지를 미리 로드

## 라우팅 우선순위


여러 라우트 패턴이 동일한 URL에 매칭될 수 있는 경우, Next.js는 다음 우선순위로 라우트를 결정한다.

1. **정적 라우트** (우선순위 가장 높음)
2. **동적 라우트**
3. **Catch-all 라우트** (우선순위 가장 낮음)

```plain text
pages/
├── posts/
│   ├── index.tsx          (1) /posts
│   ├── create.tsx         (2) /posts/create
│   ├── [id].tsx           (3) /posts/:id
│   └── [...slug].tsx      (4) /posts/*
```


위 구조에서:

- `/posts` 접속 시: `index.tsx` 매칭
- `/posts/create` 접속 시: `create.tsx` 매칭 (정적 라우트가 우선)
- `/posts/123` 접속 시: `[id].tsx` 매칭
- `/posts/a/b/c` 접속 시: `[...slug].tsx` 매칭

`create.tsx`가 있다면 `/posts/create`는 `[id].tsx`보다 우선한다. 정적 라우트가 동적 라우트보다 우선순위가 높기 때문이다.


## 404 페이지


존재하지 않는 경로에 접속할 때 표시되는 404 페이지를 커스터마이징할 수 있다. `pages` 폴더 최상위에 `404.tsx` 파일을 만들면 된다.


```typescript
// pages/404.tsx
import Link from 'next/link';

export default function Custom404() {
  return (
    <div>
      <h1>404 - 페이지를 찾을 수 없습니다</h1>
      <p>요청하신 페이지가 존재하지 않습니다.</p>
      <Link href="/">홈으로 돌아가기</Link>
    </div>
  );
}
```


빌드 시 자동으로 정적 페이지로 생성되므로 추가 서버 부하 없이 빠르게 제공된다.


## 참고 자료

- [Next.js 공식 문서 - Pages Router Routing](https://nextjs.org/docs/pages/building-your-application/routing)
- [Next.js 공식 문서 - next/link](https://nextjs.org/docs/pages/api-reference/components/link)
- [Next.js 공식 문서 - useRouter](https://nextjs.org/docs/pages/api-reference/functions/use-router)


페이지 라우팅 설정하기

React Compiler 톺아보기


## 왜 필요한가?


React 개발을 하다 보면 다음과 같은 당황스러운 상황들을 만날 수 있다.

- "분명 같은 객체인데 왜 useEffect가 무한 루프에 빠지지?"
- "React.memo를 썼는데도 왜 계속 리렌더링이 일어나지?"
- "객체를 의존성 배열에 넣으니까 이상하게 동작해..."

이 모든 문제의 원인은 React가 객체를 어떻게 비교하는지의 메커니즘에 이유가 숨어있을 수 있다. React의 모든 최적화(가상 DOM 비교, 컴포넌트 리렌더링 판단, 메모이제이션)가 이 객체 비교 방식에 의존하기 때문이다.


## 문제 상황


실제로 겪을 수 있을 법한 예제를 살펴보자.


```javascript
function DataFetcher() {
  const [data, setData] = useState(null)
  const [loading, setLoading] = useState(false)

  const fetchOptions = {
    method: 'GET',
    headers: { 'Authorization': 'Bearer token' }
  }

  useEffect(() => {
    setLoading(true)
    fetch('/api/data', fetchOptions)
      .then(res => res.json())
      .then(result => {
        setData(result)
        setLoading(false)
      })
  }, [fetchOptions])

  return loading ? <div>Loading...</div> : <div>{data}</div>
}
```


위 컴포넌트는 무한 루프에 빠진다. 왜 그럴까? 단계별로 분석해보자.


### 무한 루프가 발생하는 과정


1단계: 첫 렌더링


```plain text
컴포넌트 실행 → fetchOptions 객체 생성 (메모리 주소: 0xA001)
→ useEffect 실행 (첫 렌더링이므로)
→ API 호출 → setData 실행
```


2단계: 상태 업데이트로 리렌더링


```plain text
setData로 인한 리렌더링 → 컴포넌트 함수 다시 실행
→ fetchOptions 객체 다시 생성 (새로운 메모리 주소: 0xA002)
```


여기가 핵심이다. 똑같은 `{ method: 'GET', headers: {...} }` 내용이지만, 자바스크립트에서는 새로운 객체로 취급된다.


3단계: React의 의존성 비교


```plain text
React: "이전 fetchOptions(0xA001)와 현재 fetchOptions(0xA002)를 비교해보자"
→ Object.is(0xA001, 0xA002) === false
→ "의존성이 변경되었네! useEffect를 다시 실행하자"
```


4단계: 무한 반복


```plain text
useEffect 재실행 → API 호출 → setData → 리렌더링
→ 새 fetchOptions 생성 → 의존성 변경 감지 → useEffect 재실행 → ...
```


이것이 바로 React가 객체 비교에 민감한 이유다. 개발자 눈에는 같은 객체지만, React는 참조(메모리 주소)로 비교하기 때문에 "다른 객체"로 인식한다.


## 자바스크립트의 객체 비교 방식 이해


### 원시 타입과 객체 타입의 차이점


자바스크립트에서 값을 비교하는 방식을 이해해보자.


```javascript
let name1 = 'React'
let name2 = 'React'
console.log(name1 === name2)  // true

const config1 = { theme: 'dark' }
const config2 = { theme: 'dark' }
console.log(config1 === config2)  // false
```


원시 타입인 문자열은 값 자체를 비교해서 `true`가 나오지만, 객체는 참조를 비교해서 `false`가 나온다.


이것이 중요한 이유는 메모리에 저장되는 방식이 다르기 때문이다. 원시 타입은 값 자체가 변수에 저장되지만, 객체는 힙 메모리의 주소(참조)만 변수에 저장된다.


```javascript
// 메모리 관점에서 보면
const obj1 = { name: 'Kim' }  // 변수: 0x001 → 힙: 0xA001번지에 실제 객체
const obj2 = { name: 'Kim' }  // 변수: 0x002 → 힙: 0xA002번지에 실제 객체

// 비교할 때는 주소를 비교
console.log(obj1 === obj2)  // 0xA001 === 0xA002 → false
```


여기서 핵심은 내용이 완전히 같아도 서로 다른 메모리 위치에 있으면 다른 객체로 인식된다는 점이다.


## React의 비교 메커니즘 분석


### Object.is()의 동작 원리


React는 기본적으로 `Object.is()`를 사용한다. `packages/shared/objectIs.js`에서 Object.is의 폴리필을 구현하고 있다.


```javascript
function is(x, y) {
  return (
    (x === y && (x !== 0 || 1 / x === 1 / y)) ||
    (x !== x && y !== y)
  );
}

const objectIs = typeof Object.is === 'function' ? Object.is : is;
```


네이티브 `Object.is`가 있으면 사용하고, 없으면 자체 구현한 `is` 함수를 사용한다.


**Object.is의 실제 동작 예시**


```javascript
Object.is(5, 5)           // true
Object.is('hello', 'hello') // true
Object.is({}, {})         // false
Object.is(+0, -0)         // false (=== 는 true)
Object.is(NaN, NaN)       // true (=== 는 false)
```


이 함수가 하는 일은 기본적으로 `===` 비교이지만, `+0`과 `-0`, 그리고 `NaN` 케이스를 올바르게 처리한다는 점이다. 공식 문서에서도 **useEffect는 Object.is를 사용해 의존성을 비교한다고 명시**되어 있다. 이로 인해 React에서는 개발자가 기대하는 방식으로 특수한 값들이 비교된다.


### ShallowEqual


React는 `Object.is()`만으로는 부족한 객체 비교를 위해 `shallowEqual` 함수를 사용한다.


```javascript
// packages/shared/shallowEqual.js
function shallowEqual(objA, objB) {
  if (Object.is(objA, objB)) {
    return true
  }

  if (typeof objA !== 'object' || objA === null ||
      typeof objB !== 'object' || objB === null) {
    return false
  }

  const keysA = Object.keys(objA)
  const keysB = Object.keys(objB)

  if (keysA.length !== keysB.length) {
    return false
  }

  for (let i = 0; i < keysA.length; i++) {
    const currentKey = keysA[i]
    if (!objB.hasOwnProperty(currentKey) ||
        !Object.is(objA[currentKey], objB[currentKey])) {
      return false
    }
  }

  return true
}
```


위 함수의 실행 과정을 단계별로 분석해보면,

1. 참조가 동일한지 검사해 같은 객체를 가리키는지 확인한다.
2. 타입을 비교해 둘 다 객체인지 확인한다.
3. 키 개수를 비교해 속성 개수가 다르면 즉시 false한다.
4. 각 속성값을 비교해 **1 depth 까지만** `Object.is()`로 비교한다.

이것이 "얕은 비교"라고 불리는 이유는 객체의 첫 번째 깊이만 검사하기 때문이다.


### 얕은 비교의 동작


얕은 비교가 어떻게 동작하는지 자바스크립트로 확인해보자.


```javascript
const user1 = { name: 'Kim', age: 30 }
const user2 = { name: 'Kim', age: 30 }
shallowEqual(user1, user2)  // true
```

1. `Object.is(user1, user2)` → false (다른 참조)
2. 둘 다 객체임 → 계속 진행
3. 키 개수 동일 (2개) → 계속 진행
4. `user1.name === user2.name` → 'Kim' === 'Kim' → true
5. `user1.age === user2.age` → 30 === 30 → true
6. 모든 속성이 일치 → true 반환

하지만 중첩된 객체에서는 실패한다.


```javascript
const profile1 = { user: { name: 'Kim', age: 30 } }
const profile2 = { user: { name: 'Kim', age: 30 } }
shallowEqual(profile1, profile2)  // false
```

1. `Object.is(profile1, profile2)` → false
2. 둘 다 객체임 → 계속 진행
3. 키 개수 동일 (1개) → 계속 진행
4. `profile1.user === profile2.user` 비교
    - `{name:'Kim', age:30}` === `{name:'Kim', age:30}`
    - 서로 다른 객체 참조 → false
5. false 반환

## 이것이 React에서 문제가 되는 이유


### 의존성 배열에서의 함정


```javascript
function WeatherWidget({ city }) {
  const [weather, setWeather] = useState(null)

  // 매 렌더링마다 새로운 객체 생성
  const apiConfig = {
    method: 'GET',
    headers: { 'API-Key': process.env.WEATHER_API_KEY }
  }

  useEffect(() => {
    fetch(`/api/weather/${city}`, apiConfig)
      .then(res => res.json())
      .then(setWeather)
  }, [city, apiConfig])  // apiConfig가 의존성 배열에 포함됨

  return <div>{weather?.temperature}°C</div>
}
```


위 코드는 무한 루프에 빠진다. 실행 과정을 자세히 살펴보자.


### 무한 루프 발생 과정


```plain text
1) 첫 렌더링
   컴포넌트 실행 → apiConfig 생성 (메모리 주소: 0xA001)
   → useEffect 실행 (첫 렌더링이므로)
   → fetch 호출 → 응답 받음 → setWeather(data) 실행

2) state 변경으로 리렌더링
   setWeather로 인한 리렌더링 → 컴포넌트 함수 다시 실행
   → 새로운 apiConfig 객체 생성 (메모리 주소: 0xA002)

3) React의 의존성 비교
   React: 이전 apiConfig(0xA001)와 현재 apiConfig(0xA002) 비교
   → Object.is(0xA001, 0xA002) === false
   → '의존성이 변경되었군.. useEffect를 다시 실행해야지'

4) 무한 반복
   useEffect 재실행 → fetch 호출 → setWeather
   → 리렌더링 → 새 apiConfig 생성 → useEffect 재실행...
```


### 실제로 확인해보기


![2025-08-2411.36.34-ezgif.com-video-to-gif-converter.gif](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/react-object-comp/image-1756020669758-0.gif)


내용은 완전히 동일하지만 React는 참조(메모리 주소)로 비교하기 때문에 다른 객체로 인식한다.


### 해결 방법


```javascript
// 1: useMemo
function WeatherWidget({ city }) {
  const [weather, setWeather] = useState(null)

  const apiConfig = useMemo(() => ({
    method: 'GET',
    headers: { 'API-Key': process.env.WEATHER_API_KEY }
  }), [])

  useEffect(() => {
    fetch(`/api/weather/${city}`, apiConfig)
      .then(res => res.json())
      .then(setWeather)
  }, [city, apiConfig])

  return <div>{weather?.temperature}°C</div>
}
```


useMemo는 가장 일반적인 해결 방법이다. 의존성 배열이 빈 배열 `[]`이므로 컴포넌트가 처음 마운트될 때 한 번만 객체를 생성하고, 그 이후로는 항상 같은 참조를 반환한다. 따라서 useEffect의 의존성 배열에 `apiConfig`를 포함해도 참조가 변하지 않으므로 무한 루프가 발생하지 않는다.


이 방법은 코드가 명확해 예측하기 쉽다. 코드를 보면 "이 객체는 한 번만 생성되고 재사용된다"고 바로 알 수 있다. 또한 나중에 의존성이 추가되어야 할 상황에도 쉽게 추가할 수 있다. 의존성 배열에 값을 추가하기만 하면 된다.


단점이라면 약간의 메모리 오버헤드와 초기 계산 비용이 있다는 점이다. 복잡한 객체를 생성하는 경우에는 오히려 성능상 이득이 있다.


```javascript
// 2: useEffect 내부로 이동
function WeatherWidget({ city }) {
  const [weather, setWeather] = useState(null)

  useEffect(() => {
    const apiConfig = {
      method: 'GET',
      headers: { 'API-Key': process.env.WEATHER_API_KEY }
    }

    fetch(`/api/weather/${city}`, apiConfig)
      .then(res => res.json())
      .then(setWeather)
  }, [city])

  return <div>{weather?.temperature}°C</div>
}
```


이 방법이 동작하는 이유는 React가 의존성 배열에 있는 값들만 비교하기 때문이다. useEffect 내부에서 생성되는 객체는 의존성 배열에 포함시킬 필요가 없다. `apiConfig` 객체가 매번 새로 생성되지만 의존성 배열에 없으므로 무한 루프가 발생하지 않는다. city가 변경될 때만 useEffect가 실행되고, 그때마다 내부에서 새로운 apiConfig를 생성해서 사용한다. ESLint의 exhaustive-deps 규칙도 이 패턴을 허용한다.


다만 주의할 점이 있다. 만약 객체 내부에서 외부 변수(props나 state)를 참조한다면 반드시 해당 변수들을 의존성 배열에 포함해야 한다. 예를 들어 `headers: { 'API-Key': apiKey }`처럼 props의 apiKey를 사용한다면 `[city, apiKey]`로 의존성을 설정해야 한다.


```javascript
// 3: 컴포넌트 외부에 정의
const API_CONFIG = {
  method: 'GET',
  headers: { 'API-Key': process.env.WEATHER_API_KEY }
}

function WeatherWidget({ city }) {
  const [weather, setWeather] = useState(null)

  useEffect(() => {
    fetch(`/api/weather/${city}`, API_CONFIG)
      .then(res => res.json())
      .then(setWeather)
  }, [city])

  return <div>{weather?.temperature}°C</div>
}
```


컴포넌트 외부에 객체를 정의하는 방법은 객체가 절대 변하지 않을 때 사용한다. `API_CONFIG`는 모든 컴포넌트 인스턴스가 공유하는 단일 객체이므로 참조가 항상 동일하다. 따라서 의존성 배열에 넣어도 무한 루프가 발생하지 않는다.


하지만 실제로는 의존성 배열에 넣을 필요도 없다. React는 컴포넌트 외부의 값들이 렌더링 사이클과 무관하다는 것을 알고 있기 때문이다. 이 방법의 장점은 메모리 효율성이다. 여러 컴포넌트 인스턴스가 있어도 객체는 하나만 존재한다. 단점은 환경변수나 전역 설정이 바뀌어도 자동으로 반영되지 않는다는 점이다.


이것이 바로 React가 객체 비교에 민감한 이유다. 개발자 눈에는 같은 객체지만, React는 완전히 다른 객체로 인식한다.


### 왜 React는 깊은 비교를 하지 않을까?


React가 shallow comparison을 선택한 이유는 성능뿐만 아니라 설계 철학과 관련이 있다.


### React 공식 설계 원칙


React가 shallow comparison을 선택한 배경에는 몇 가지 기술적 고려사항들이 있다.


**예측 가능한 성능**


[useEffect 문서](https://react.dev/reference/react/useEffect)에 따르면 의존성 비교는 Object.is를 사용한다고 명시되어 있다. 객체의 깊이를 미리 알 수 없는 상황에서 깊은 비교는 성능을 예측하기 어렵게 만들기 때문으로 추론된다.


**불변성 기반 아키텍처**


React 공식 문서의 ["객체 State 업데이트하기"](https://react.dev/learn/updating-objects-in-state) 섹션에서는 "객체나 배열을 업데이트할 때는 새로운 객체를 생성해야 한다"고 강조한다. 이런 불변성 패턴이 shallow comparison과 잘 맞아떨어진다.


```javascript
// React가 권장하는 패턴
const [user, setUser] = useState({name: 'John', age: 30})

// 올바른 업데이트 방식 - 새로운 객체 생성
setUser(prev => ({...prev, age: 31}))

// 잘못된 업데이트 방식 - 기존 객체 변경
user.age = 31 
setUser(user)
```


**명시적 의존성 관리**


useEffect 문서에서는 "모든 의존성을 명시적으로 선언하라"고 권장한다. 이는 개발자가 어떤 값이 변경될 때 Effect가 실행되는지 명확히 알 수 있게 하기 위함으로 보인다.


### 메모리와 가비지 컬렉션 관점


깊은 비교는 메모리 사용량에도 영향을 미친다.


```javascript
// 깊은 비교 시 발생하는 문제들
function deepCompare(obj1, obj2, visited = new WeakSet()) {
  // 순환 참조 체크를 위한 추가 메모리 필요
  if (visited.has(obj1)) return obj1 === obj2

  visited.add(obj1)  // WeakSet에 객체 추가

  // 재귀 호출로 인한 콜 스택 증가
  // 큰 객체의 경우 스택 오버플로우 위험
}
```


React 애플리케이션에서는 컴포넌트 트리가 깊고 state가 복잡할 수 있기 때문에, 매 렌더링마다 깊은 비교를 수행하면 가비지 컬렉션 압박이 증가한다.


### React 팀의 실제 구현 선택


React 소스코드를 살펴보면 일관되게 shallow comparison을 사용한다.


```javascript
// packages/shared/shallowEqual.js (React 소스코드)
function shallowEqual(objA, objB) {
  if (is(objA, objB)) return true

  // 타입 체크 후 1 depth만 비교
  for (let i = 0; i < keysA.length; i++) {
    if (!is(objA[currentKey], objB[currentKey])) {
      return false  // 깊이 들어가지 않고 즉시 false
    }
  }
  return true
}

// packages/react-reconciler/src/ReactFiberClassComponent.js
// PureComponent도 shallowEqual 사용
return !shallowEqual(oldProps, newProps) || !shallowEqual(oldState, newState)
```


### 왜 이것이 더 나은 선택인가


React의 shallow comparison 선택은 무엇보다 일관된 성능을 보장한다. 객체의 복잡성에 관계없이 O(n) 시간 복잡도를 유지하는데, 여기서 n은 객체의 첫 번째 레벨에 있는 속성의 개수를 의미한다.


```javascript
const obj1 = {
  name: 'Kim',    // 1 depth 속성 1
  age: 30         // 1 depth 속성 2
}

const obj2 = {
  name: 'Kim',    // 1 depth 속성 1
  profile: {      // 1 depth 속성 2 (내용이 아무리 복잡해도)
    personal: {
      address: { city: 'Seoul', district: 'Gangnam', street: '...' },
      contacts: { phone: '...', email: '...', sns: [...] }
    },
    work: {
      company: '...',
      projects: [/* 수백 개의 프로젝트 */]
    }
  }
}

// shallow comparison에서는 둘 다 동일하게 2번의 비교만 수행
```


`obj1`이든 `obj2`든 shallow comparison은 항상 2번의 비교만 수행한다. `profile` 객체 안에 얼마나 복잡한 중첩 구조가 있든 상관없이 `profile` 참조 자체만 비교하기 때문이다. 반면 deep comparison이었다면 중첩된 모든 속성을 순회한다.


이렇게 함으로써 개발자가 변경 사항을 명시적으로 표현하도록 유도한다. 객체 내부의 값을 변경하고 싶다면 반드시 새로운 객체를 만들어야 한다. `setUser({...user, age: 31})`처럼 새 객체를 만드는 것을 보면 "age가 변경되었다"는 의도가 즉시 드러난다.


디버깅 관점에서도 참조가 바뀌면 확실히 무언가 변경된 것이므로 문제를 추적하기 쉽다. 깊은 비교에서는 거대한 객체 구조에서 정확히 어느 부분이 변경되었는지 찾아내기 어렵다. shallow comparison에서는 참조 변경 자체가 신호가 될 수 있다.


```javascript
// 디버깅이 쉬운 경우
const prevState = state
const nextState = {...state, count: state.count + 1}
console.log('참조가 변했나?', prevState !== nextState)  // true
console.log('무엇이 변했나?', 'count가 변경됨')

// 디버깅이 어려운 경우 (deep mutation)
state.nested.deep.property.count += 1
console.log('참조가 변했나?', prevState !== state)  // false - 하지만 실제로는 변경됨
// 어느 부분이 변경되었는지 찾기 어려움
```


이런 설계 철학은 React 생태계 전반에 영향을 미쳤다. Immutable.js나 Immer 같은 불변성 도우미 라이브러리들이 발달한 것도 이런 맥락에서다. Redux의 상태 관리 철학, 함수형 프로그래밍의 확산, 심지어 최근의 상태 관리 라이브러리들까지 모두 불변성을 기반으로 한다. 결과적으로 React의 shallow comparison 선택은 성능상의 이유를 넘어 더 견고하고 예측 가능한 아키텍처를 만들어내는 역할을 했다.


## references

- [useEffect](https://react.dev/reference/react/useEffect)
- [React.memo](https://react.dev/reference/react/memo)
- [useMemo](https://react.dev/reference/react/useMemo)
- [useCallback](https://react.dev/reference/react/useCallback)
- [objectIs.js](https://github.com/facebook/react/blob/main/packages/shared/objectIs.js)
- [shallowEqual.js](https://github.com/facebook/react/blob/main/packages/shared/shallowEqual.js)
- [Object.is() - MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is)
- [JavaScript 메모리 관리 - MDN](https://developer.mozilla.org/ko/docs/Web/JavaScript/Memory_Management)


왜 React는 객체 비교에 민감할까

2025년 3~6월 회고

Symmetric key(대칭키) 암호화


## 📡 OpenFlow


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-05-31_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_10.16.42.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236228899-0)


SDN(Software-Defined Networking)은 네트워크 제어를 중앙에서 통합적으로 수행하는 구조다. 각 스위치는 단순히 패킷을 전달하고, 네트워크 전체를 어떻게 구성하고 제어할지는 하나의 중앙 컨트롤러가 결정한다. 이렇게 제어 평면과 데이터 평면을 분리한 구조는 유연하고 강력하지만, 여기서 한 가지 중요한 의문이 생긴다.


컨트롤러는 스위치에게 어떤 방식으로 명령을 전달할까? 예를 들어, ‘이런 조건의 패킷은 포트 3번으로 보내라’는 지시를 실제로 어떻게 전달하는 걸까?


바로 이 역할을 수행하는 것이 OpenFlow다. OpenFlow는 SDN 구조 안에서 컨트롤러와 스위치 사이의 통신을 담당하는 대표적인 프로토콜로, 컨트롤러가 계산한 포워딩 정책이나 트래픽 제어 명령을 스위치에 전달할 때 사용한다. 이 통신은 TCP 위에서 이루어져 필요에 따라 암호화도 적용할 수 있다.


OpenFlow는 하나의 명령어 묶음이 아니라, 컨트롤러가 네트워크 장비를 직접 제어할 수 있게 만들어주는 공식적인 언어라고 볼 수 있다. 스위치는 이 언어로 전달된 지시에 따라 내부 플로우 테이블을 수정하거나, 처리할 수 없는 패킷을 컨트롤러에게 다시 보내기도 한다.


이 글에서는 OpenFlow가 어떤 메시지들을 주고받으며, 실제로 컨트롤러와 스위치가 어떻게 협력하는지 하나씩 살펴본다. 이를 통해 SDN이라는 개념이 실제 네트워크에서 어떤 방식으로 구현되는지를 구체적으로 이해할 수 있을 것이다.


### controller-to-switch 메시지


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-05-29_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_12.33.12.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236231986-1)


controller-to-switch 메시지는 컨트롤러가 스위치의 동작을 직접 제어하거나 정보를 요청할 때 사용한다. 이 메시지 유형에는 여러 가지가 있다. 

- `features` 컨트롤러가 스위치의 기능을 조회할 때 사용된다. 컨트롤러가 쿼리를 보내면, 스위치는 자신이 지원하는 기능을 응답으로 알려준다.
- `configure` 컨트롤러가 스위치의 구성 파라미터를 조회하거나 설정할 때 사용된다. 스위치의 동작 방식을 제어하거나 제한할 수 있다.
- `modify-state` 컨트롤러는 스위치의 OpenFlow 테이블에 있는 플로우 항목을 추가, 삭제, 수정할 수 있다. 네트워크의 라우팅 경로를 동적으로 조정하거나 특정 트래픽에 대한 제어 정책을 적용할 수 있다.
- `packet-out` 컨트롤러가 특정 패킷을 스위치의 특정 포트를 통해 외부로 직접 전송하도록 지시할 때 사용된다. 일반적으로 스위치가 처리하지 못한 패킷을 컨트롤러가 수신한 후, 컨트롤러가 그에 대한 응답으로 패킷의 전송 경로를 명시할 때 활용된다.

### switch-to-controller 메시지


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-05-29_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_12.34.07.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236234615-2)


OpenFlow에서 switch-to-controller 메시지는 스위치가 네트워크 상의 변화나 특정 이벤트를 컨트롤러에게 알릴 때 사용된다. 비동기적으로 전달된다. 컨트롤러가 네트워크 상태를 실시간으로 파악하고 적절한 제어 결정을 내린다.

- `packet-in` 스위치가 처리할 수 없는 패킷을 컨트롤러에게 전달할 때 사용된다. 이 메시지를 통해 패킷 자체와 함께 그에 대한 제어 권한도 컨트롤러로 넘어가며, 이후 컨트롤러는 packet-out 메시지를 통해 해당 패킷의 처리 경로를 지시할 수 있다.
- `flow-removed` 스위치 내 플로우 테이블에 등록된 항목이 삭제되었을 때 이를 컨트롤러에 알리는 역할을 한다. 이 기능은 플로우의 수명이나 정책 변화 등을 추적하는 데 유용하다.
- `port status` 스위치 포트의 상태 변화(예: 포트 연결 또는 해제, 오류 발생 등)를 컨트롤러에게 통지한다. 이를 통해 컨트롤러는 물리적 링크 상태를 포함한 네트워크 토폴로지의 변화를 감지하고, 필요한 경우 트래픽 경로를 재조정할 수 있다.

다행히도, 네트워크 운영자가 이러한 OpenFlow 메시지를 일일이 수작업으로 작성하고 전송해야 하는 것은 아니다. 실제 운영 환경에서는 컨트롤러가 제공하는 상위 수준의 추상화 계층과 API를 통해 메시지가 자동 생성되고 전달된다. 이러한 구조 덕분에 운영자는 효율적으로 네트워크를 제어할 수 있고, OpenFlow의 세부 구현에 대해 깊이 이해하지 않아도 된다.


### SDN Control Plane, Data Plane 상호작용 예시


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-01_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_2.40.44.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236237516-3)


SDN에서 control plane과 data plane이 상호작용하는 과정을 예시를 통해 살펴보면, 전통적인 링크 상태 라우팅 방식과 유사하지만 훨씬 더 유연하게 작동함을 알 수 있다. 


(1) 네트워크 내에서 스위치 S1이 링크 장애를 감지하면, OpenFlow의 `port status` 메시지를 사용해 컨트롤러에게 해당 사실을 통지한다. 이 메시지는 data plane에서 control plane으로 전달되는 첫 단계다.


(2, 3) 컨트롤러는 이 메시지를 수신하고, 내부적으로 관리하고 있는 링크 상태 정보를 갱신한다. 이때, 컨트롤러는 링크 상태나 토폴로지의 변화가 있을 경우 감지하고 반응할 수 있도록 사전에 등록된 애플리케이션을 호출할 수 있다. 예를 들어, Dijkstra 라우팅 알고리즘이 등록되어 있다면, 링크 상태 변화 이벤트가 발생할 때 자동으로 호출된다.


(4) 호출된 라우팅 애플리케이션은 컨트롤러 내부에서 유지되는 네트워크 그래프, 링크 상태 정보, 스위치 및 호스트 정보 등을 활용해 새로운 라우팅 경로를 계산한다. 이후 이 경로 정보에 따라 필요한 플로우 테이블이 다시 계산되고, OpenFlow 프로토콜을 통해 해당 스위치들에 반영된다. 이 전 과정은 RESTful API, 그래프 추상화, 통계 및 상태 정보와 같은 고수준 추상화를 통해 이루어지고 운영자는 전체 흐름을 명확하게 설계하고 통제할 수 있다.


![0d5259ce-9eec-497d-bc3a-9ddf14fcfb65.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236240687-4)


(5) 링크 상태 라우팅 애플리케이션은 SDN 컨트롤러 내의 플로우 테이블 계산 컴포넌트와 상호작용하게 된다. 이 컴포넌트는 갱신된 네트워크 상태 정보를 바탕으로 새로운 라우팅 경로를 계산하고, 그에 따라 각 스위치가 필요로 하는 플로우 테이블 항목을 다시 생성한다. 이때 라우팅 알고리즘은 전체 네트워크의 토폴로지를 전역적으로 파악할 수 있기 때문에, 장애 이후에도 최적화된 경로를 빠르게 재설정할 수 있다.


(6) 새롭게 계산된 플로우 테이블 정보는 이후 컨트롤러가 OpenFlow 프로토콜을 사용해 각 스위치에 전송한다. 이 과정을 통해 영향을 받은 스위치들은 기존의 경로 정보를 갱신하게 되고, 새로운 경로에 따라 패킷을 전달하게 된다.


### OpenDaylight (ODL)

> 모듈형 설계 + 다양한 프로토콜 지원 = 유연한 플랫폼

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-01_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_2.53.25.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236243862-5)


OpenDaylight(ODL) 컨트롤러는 모듈화된 아키텍처를 기반으로 다양한 네트워크 제어 기능과 서비스를 유연하게 지원하는 오픈소스 SDN 플랫폼이다. 가장 상위에는 트래픽 엔지니어링, 방화벽, 부하 분산 등과 같은 네트워크 오케스트레이션 기능 및 응용 애플리케이션이 위치하고 이들은 Northbound API를 통해 ODL 컨트롤러와 통신한다. 이 API 계층에서는 REST, RESTCONF, NETCONF와 같은 표준 인터페이스가 사용되어 외부 애플리케이션이 컨트롤러 내부의 데이터 및 기능에 접근할 수 있도록 한다.


그 아래에는 AAA(인증, 인가, 계정관리)와 같은 향상된 서비스와 함께 기본적인 네트워크 기능들이 구성된다. 이 기능 모듈에는 네트워크 토폴로지를 처리하는 모듈, 스위치 관리 모듈, 통계 정보 관리 모듈, 포워딩 룰 관리, 호스트 추적 모듈 등이 포함되어 있고 구성 데이터와 운영 데이터 저장소와도 연결된다. 이 계층은 네트워크의 상태를 파악하고 필요한 조치를 결정하는 중추적인 역할을 수행한다.


이 모든 기능들은 Service Abstraction Layer(SAL)을 통해 서로 연결된다. SAL은 내부와 외부의 다양한 애플리케이션 및 서비스 모듈들 간의 연결을 중개하는 계층으로, 모듈 간의 독립성과 재사용성을 높여준다. SAL은 특히 Southbound API와도 연결되는데, 이 하위 계층에서는 OpenFlow, NETCONF, SNMP, OVSDB 등의 프로토콜을 이용해 실제 네트워크 장비와 직접 통신이 이루어진다.


### ONOS

> 대규모 분산 네트워크에 적합한 컨트롤러

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-01_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_2.53.34.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow-in-sdn/image-1753236246424-6)


ONOS(Open Network Operating System) 컨트롤러는 고신뢰성과 확장성을 중심으로 설계된 SDN 플랫폼으로 대규모 네트워크 인프라에서의 안정적인 제어를 목표로 한다. ONOS 아키텍처의 특징 중 하나는 제어 애플리케이션이 컨트롤러와 분리되어 있다는 점이다. 라우팅, 방화벽, 트래픽 엔지니어링, 부하 분산 등의 네트워크 애플리케이션은 ONOS의 외부에서 동작하면서 Northbound API를 통해 컨트롤러와 통신한다.


ONOS는 Intent Framework를 통해 고수준의 서비스 명세 방식을 지원한다. 이 프레임워크는 “어떻게(how)”보다 “무엇을(what)” 중심으로 서비스를 정의할 수 있게 해준다. 예를 들어 운영자는 특정 두 호스트 간 연결을 요청하기만 하면 ONOS가 그 구현 방법을 자동으로 결정해준다. 네트워크 제어를 직관적이고 정책 중심의 네트워크 운용을 가능하게 한다.


내부적으로 ONOS는 분산 코어에 많은 비중을 두고 있고 서비스의 신뢰성, 상태 복제, 성능, 확장성 등을 보장하기 위한 기반이다. 코어는 다양한 상태 정보를 관리하는 모듈들(예: 디바이스, 링크, 호스트, 플로우, 패킷 등)로 구성되어 있으며, 이 정보는 애플리케이션이 필요한 제어 결정을 내리는 데 활용된다.


Southbound API 계층에서는 OpenFlow, Netconf, OVSDB 등의 프로토콜을 통해 실제 네트워크 장비와 상호작용한다. 이 계층도 추상화되어 있어서, 다양한 장비와 기술을 통합적으로 관리할 수 있도록 설계되어 있다. 전체적으로 ONOS는 구조적으로 견고하고 추상화 수준이 높다.



SDN 안에서의 OpenFlow 역할과 동작 방식


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_1.37.14.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/network-security/image-1753236567044-0)


네트워크 보안은 인터넷이나 기타 네트워크를 통해 데이터를 주고받는 과정에서 발생할 수 있는 다양한 위협으로부터 정보를 보호하고, 통신 당사자 간의 신뢰를 보장하는 것을 목표로 한다. 이를 위해 네트워크 보안은 네 가지 요소로 구성된다.


첫 번째 요소는 기밀성(confidentiality)이다. 기밀성은 오직 송신자와 수신자만이 메시지의 내용을 이해할 수 있어야 한다는 원칙이다. 이를 위해 일반적으로 송신자는 메시지를 암호화하고, 수신자는 이를 복호화한다. 제3자가 메시지를 가로채더라도 그 내용을 이해하지 못하도록 막는다.


두 번째는 인증(authentication)이다. 인증은 네트워크 통신에서 통신하는 상대방의 신원을 확인하는 과정이다. 예를 들어 내가 정말 은행과 통신하고 있는지, 아니면 누군가가 은행인 척 하고 있는지를 확인하는 것이 인증이다. 인증을 통해 스푸핑(spoofing)이나 중간자 공격(man-in-the-middle attack) 같은 위협을 방지할 수 있다. 주로 암호학적 서명, 키 기반 프로토콜, 인증 서버 등을 이용해 구현된다.


세 번째는 무결성(integrity)이다.


무결성은 메시지가 전송 도중이나 저장 중에 변경되지 않았음을 확인하는 원칙이다. 메시지가 중간에 조금이라도 바뀌었다면, 수신자는 이를 알아차릴 수 있어야 한다. 이를 위해 보통 해시 함수(hash function)나 메시지 인증 코드(MAC) 등을 사용한다. 이런 기법을 통해 메시지의 변조 여부를 검증할 수 있다.


마지막으로는 가용성(availability)이다. 가용성은 네트워크 서비스가 인증된 사용자에게 항상 접근 가능하고 안정적으로 동작해야 한다는 원칙이다. 만약 서버가 마비되거나, 네트워크가 과부하되어 서비스를 사용할 수 없다면 가용성이 침해된 것이다. 대표적인 위협으로는 서비스 거부 공격(DDoS)이 있으며, 이런 공격은 네트워크 자원을 고의로 소모시켜 정상 사용자가 접근하지 못하게 만든다.


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_1.37.24.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/network-security/image-1753236569499-1)


네트워크 보안 분야에서 자주 사용되는 가상의 인물들이 있다. 대표적으로 Alice와 Bob, 그리고 Trudy다. 두 사람의 신뢰를 바탕으로 비밀스럽게 소통하고 싶어한다는 상황을 드러내기 위해 연인 관계로 설정하기도 한다.


Alice는 일반적으로 송신자(sender) 역할을, Bob은 수신자(receiver) 역할을 한다. 서로 주고받는 메시지는 기밀성, 무결성, 인증과 같은 보안이 충족되길 원한다. 예를 들어,

- Alice는 오직 Bob만 메시지를 읽을 수 있길 바란다. (기밀성)
- Bob은 그 메시지가 변조되지 않았고, 정말 Alice가 보낸 것임을 알고 싶어 한다. (무결성, 인증)

하지만 항상 평화로운 상황만 있는 것은 아니다. 여기에 등장하는 제3의 인물 Trudy는 공격자(intruder) 또는 도청자, 침입자 역할을 하고, 여러 악의적 행위를 시도할 수 있다.

- 메시지를 가로채거나 도청(intercept)
- 메시지를 삭제(delete)
- 위조된 메시지를 추가하거나 변경(add/modify)

Trudy는 이러한 행위를 통해 통신을 방해하거나 속이고, 민감한 정보를 탈취하거나 통신 내용을 왜곡할 수 있다. 따라서 Alice와 Bob은 통신을 보호하기 위해 암호화, 인증, 무결성 체크 등 다양한 보안 기법을 적용해야 한다.


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_1.37.39.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/network-security/image-1753236572094-2)


네트워크에는 단순한 행동을 넘는 적극적인 공격자들이 존재한다. 통신을 조작하거나 시스템을 마비시키는 등 직접 개입하는 다양한 행위를 시도한다.


가장 대표적인 수동적 공격은 도청(eavesdropping)이다. 네트워크를 통해 흐르는 메시지를 몰래 가로채는 것으로, 민감한 정보가 암호화되지 않은 경우 쉽게 탈취당할 수 있다. 


도청보다 더 위협적인 것은 **능동적 공격**이다. 공격자는 다음과 같은 방식으로 통신을 조작한다.

- 메시지 변조/삽입: 기존 메시지를 바꾸거나, 허위 메시지를 추가해 통신 내용을 왜곡한다. 예를 들어 결제 정보를 조작하면 실제 자금이 탈취될 수 있다.
- 스푸핑(Spoofing): 출발지 주소를 위조해 다른 사용자로 가장한다. 인증이 제대로 이루어지지 않으면, 신뢰 관계가 무너진다.
- 세션 하이재킹(Session Hijacking): 진행 중인 통신 세션에 침입해 정상 사용자를 배제하고 공격자가 그 자리를 차지한다. 사용자는 자신도 모르게 조작된 결과를 받게 된다.

가용성을 무너뜨리는 대표적인 공격은 서비스 거부 공격(DoS)이다. 네트워크나 서버에 **과도**한 요청을 보내 시스템을 마비시켜 정상 사용자가 서비스를 이용하지 못하게 만든다.



네트워크 보안이란

IPSec


## 📡 디지털 서명이란


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.34.15.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236434433-0)


디지털 서명(digital signature)은 손으로 직접 서명을 하는 것처럼, 문서의 작성자와 진위를 증명할 수 있게 해주는 암호 기술이다. 서명을 통해 ‘이 문서는 내가 작성한 것이고, 그 내용은 바뀌지 않았다’는 사실을 수학적으로 보장할 수 있다.


위 디지털 서명의 예시를 들어보자. Bob이 Alice에게 편지를 보내며 ‘내가 진짜 보낸 편지’라는 것을 증명하고 싶다고 하자. Bob은 이 편지의 내용을 자신의 개인키(private key)를 사용해 암호화한다. 이렇게 하면 그 누구도 (Alice조차도) 이 서명된 내용을 위조하거나 조작할 수 없다. 왜냐하면, Bob의 개인키는 오직 그만 가지고 있기 때문이다.


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.34.23.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236437503-1)


Alice는 이 서명된 편지를 받으면, Bob의 공개키(public key)를 이용해 복호화할 수 있다. 복호화 결과가 원래의 편지 내용과 일치하면, 다음 두 가지 사실을 동시에 확인할 수 있다.

1. 이 편지는 반드시 Bob이 서명한 것이다.
    - Bob의 공개키로 복호화가 가능하다는 것은 개인키로 암호화했다는 뜻이다.
2. 편지 내용이 바뀌지 않았다.
    - 서명된 데이터가 조금이라도 바뀌었으면 복호화가 깨졌을 것이다.

이 구조 덕분에 디지털 서명은 위조 방지(non-forgeability)와 부인 방지(non-repudiation)의 기능을 동시에 제공한다. Alice는 제3자에게 ‘이 메시지는 확실히 Bob이 보낸 것이다’라고 증명할 수 있다. 그리고 Bob은 ‘나는 그런 메시지 보낸 적 없다’고 주장할 수 없다.


## 📡 메시지 다이제스트


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.34.30.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236440009-2)


디지털 서명을 적용할 때 이런 문제를 마주하게 된다.

> 긴 메시지를 그대로 개인키로 암호화하려면 너무 많은 계산이 필요하다. 
>
> 그럼에도 메시지의 진위와 무결성을 어떻게 효율적으로 확인할 수 있을까?
>
>

이 문제를 해결해주는 것이 바로 메시지 다이제스트(message digest)다. 메시지 다이제스트는 원래의 긴 메시지를 고정된 길이의 짧은 값으로 요약하는 방식이다. 이를 위해 해시 함수(hash function)라는 수학적 함수를 사용한다.


해시 함수는 어떤 크기의 입력이 들어와도 항상 일정한 크기의 출력을 생성한다. 이 출력값은 흔히 디지털 지문(fingerprint)이라고 불리고 메시지를 대표하는 고유한 값처럼 사용된다. 예를 들어 수백 줄의 이메일 본문을 입력으로 넣어도, 해시 함수는 그 내용을 압축해서 단 몇 바이트 길이의 다이제스트를 만들어준다.


이 다이제스트는 다음과 같은 성질을 갖는다.

- 길이가 고정되어있다. 입력 길이에 관계없이 출력은 일정하다. (예: SHA-1은 160비트)
- 많은 입력, 같은 출력(many-to-one). 무한한 입력 공간을 유한한 출력에 맵핑하기 때문에, 서로 다른 메시지가 같은 해시 값을 가질 수도 있다. 하지만 이건 설계상 허용되며, 중요한 건…
- 역으로 찾기 어렵다. 어떤 해시 값 $x$가 주어졌을 때, 이를 만들어내는 입력 $m$을 찾는 건 계산적으로 불가능에 가깝다. 이것이 해시 함수의 핵심 보안 성질이다.

이러한 성질 덕분에 해시 함수는 디지털 서명과 결합되어 사용된다. 실제 서명 과정에서는 메시지 전체가 아닌, 해시 함수로 요약한 다이제스트에만 서명을 한다. 그 결과 서명은 빠르고 간결하면서도 메시지 전체의 무결성을 검증할 수 있게 된다.


### 작동 예시


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.35.33.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236442069-3)


실제 구현에서는 전체 메시지가 아니라, 그 메시지의 요약 값(hash)에 대해 서명을 한다. 이 구조를 사용하면 성능은 빠르면서도 무결성과 인증을 동시에 보장할 수 있다.


예를 들어 Bob이 Alice에게 메시지 m을 보내며 디지털 서명을 추가한다고 하자. 이때 전체 과정은 다음과 같이 이뤄진다.


<u>서명 생성: Bob → Alice</u>

- Bob은 먼저 메시지 $m$에 대해 해시 함수를 적용해 메시지 다이제스트 $H(m)$를 계산한다. 이 다이제스트는 메시지를 요약한 고정 길이의 값이다.
- 이어서, 이 $H(m)$을 자신의 개인키 $K_B^-$로 암호화한다. 이 암호화된 다이제스트가 곧 디지털 서명이다.
- Bob은 이제 두 가지를 Alice에게 전송한다.
    - 원본 메시지 $m$
    - 디지털 서명 $K_B^-(H(m))$

<u>서명 검증: Alice</u>

- Alice가 이 메시지를 받으면, 다음과 같은 과정을 통해 서명이 유효한지 확인할 수 있다.
    - Alice는 메시지 $m$에 똑같은 해시 함수를 적용해 자신만의 $H(m)$을 만든다.
    - 동시에 Bob이 보낸 디지털 서명을 Bob의 공개키 ${K_B}^+$를 사용해 복호화한다.
        - 이 결과는 Bob이 실제로 서명할 때 사용한 $H(m)$이어야 한다.
    - 마지막으로 두 개의 다이제스트를 비교한다.
        - Alice가 직접 계산한 $H(m)$
        - 서명으로부터 복호화한 $H(m)$
- 이 둘이 일치한다면, Alice는 다음 두 가지를 확신할 수 있다.
    - 이 메시지는 Bob이 보낸 것이고 제3자가 위조한 것이 아니다.
    - 메시지 내용은 전송 중에 변경되지 않았다.

## 📡 암호에는 부적절한 인터넷 체크섬


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.35.25.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236444978-4)


## 📡 실제로 사용되는 해시 함수들


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.35.41.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236447404-5)


위에서 봤듯이 디지털 서명과 메시지 무결성 검증에는 반드시 **해시 함수**가 필요하다. 하지만 해시 함수는 단지 ‘있으면 되는 도구’가 아니다. 충분히 안전하고, 빠르며, 충돌 가능성이 낮아야 실전에서 쓸 수 있다. 지금까지 널리 사용된 대표적인 해시 함수로는 MD5와 SHA-1이 있다.


### MD5


MD5(Message Digest 5)는 1991년, 로널드 리베스트(Ron Rivest)가 설계한 해시 함수로 RFC 1321에 표준으로 정의되어 있다. 이 알고리즘은 어떤 크기의 입력 메시지가 들어와도 **128비트의 고정된 해시 값**을 만들어낸다. 내부적으로는 4단계 과정을 거쳐 입력을 압축하고, 최종 요약값을 계산한다.


MD5는 오랜 기간 동안 암호화 검증, 파일 무결성 체크, 디지털 서명 등에 널리 사용되었다. 특히 계산이 매우 빠르다는 장점이 있어 시스템 전반에 많이 채택되었지만, 시간이 지나면서 보안 취약점이 드러났다.


2000년대 중반 이후에는 서로 다른 두 입력이 같은 해시 값을 갖는 ’충돌(collisions)’을 비교적 쉽게 찾을 수 있음이 밝혀졌고, 그 이후 보안 분야에서는 더 이상 안전한 해시 함수로 간주되지 않는다.


### **SHA-1**


SHA-1(Secure Hash Algorithm 1)은 미국 NIST(국립표준기술연구소)에서 표준으로 채택한 해시 함수로, 160비트의 메시지 다이제스트를 생성한다. MD5보다 출력이 길기 때문에 이론상 충돌 가능성이 더 낮으며, 한동안 보안적으로 더 안전한 대안으로 여겨졌다.


하지만 SHA-1 역시 2010년대 중반 이후 이론적 충돌 공격이 가능하다는 연구 결과가 발표되었고, 2017년에는 실제 충돌을 만들어내는 사례(SHAttered attack)도 등장했다. 그 결과 현재는 대부분의 보안 프로토콜이 SHA-1 사용을 중단하고, SHA-256이나 SHA-3 같은 더 강력한 해시 함수로 전환하고 있다.


## 📡 공개키 인증 방식은 안전할까?


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.35.49.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236449176-6)


공개키 암호화는 인증과 보안 통신에서 매우 강력한 도구다. 그래서 ap5.0 프로토콜에서는 다음과 같은 방식으로 인증을 시도한다.

1. Alice는 Bob에게 ‘나는 Alice야’라고 주장하며 공개키 기반 인증을 시작한다.
2. Bob은 Alice에게 난수 $R$을 보내고, 이것을 Alice의 비밀키로 암호화해 되돌려 달라고 한다.
3. 암호문을 Bob이 Alice의 공개키로 복호화했을 때 $R$과 일치한다면, 그 상대방은 Alice라고 확신할 수 있다.

이론상 아주 깔끔한 방식처럼 보이지만, 여기에 **치명적인 허점**이 있다.


### **ap5.0의 실패 시나리오, Trudy의 공격**


공격자인 Trudy는 다음과 같은 방식으로 공격을 수행할 수 있다.

1. Bob에게 접근해 ‘나는 Alice야’라고 주장한다.
2. Bob이 Trudy에게 공개키를 달라고 요청하자, Trudy는 자신의 공개키를 보내지만 그것이 Alice의 것처럼 속인다.
3. Bob은 이 키가 진짜 Alice의 것이라고 믿고, 거기에 난수 $R$을 보내 암호화된 응답을 기대한다.
4. Trudy는 자신의 비밀키로 $R$을 암호화해 다시 Bob에게 보낸다.
5. Bob은 그 암호문을 Trudy가 준 공개키로 복호화하므로, 결과적으로 R이 제대로 복호화된다고 착각하고 Trudy를 Alice로 신뢰하게 된다.

이 시점에서 Bob은 Trudy를 Alice로 완전히 잘못 인증하고, 이후 개인적인 메시지 $m$를 암호화해 보내게 된다.


Trudy는 이 메시지를 쉽게 복호화할 수 있다. 왜냐하면 메시지는 Trudy가 넘긴 공개키로 암호화되었고, Trudy는 그에 해당하는 비밀키를 가지고 있기 때문이다. 게다가 Trudy는 이 메시지를 다시 Alice의 공개키로 재암호화해서 전달할 수도 있다. 결과적으로 Alice와 Bob은 서로 안전하게 통신했다고 믿지만, 그 사이에서 Trudy는 모든 내용을 엿볼 수 있게 된다.


### **문제점**


이 시나리오의 가장 큰 문제는 다음 한 줄로 요약할 수 있다.

> Bob은 Trudy가 보내온 공개키가 진짜 Alice의 것인지 검증하지 않았다.

즉, 공개키 자체는 안전하더라도, **그 키가 실제 Alice에게 속하는지 확인하지 않으면 전체 인증 체계가 무너질 수 있다.** 이를 해결하려면 공개키와 사용자의 신원을 묶어주는 **공인 인증서(Certificate Authority)** 시스템이 필요하다.



Digital Signature (디지털 서명)


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.25.40.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/crpytography/image-1753236561617-0)


암호학(cryptography)은 평문(plaintext), 암호문(ciphertext), 그리고 키(key)를 중심으로 구성된다. 통신에서 Alice는 메시지를 안전하게 Bob에게 전달하고 싶어 한다. 이를 위해 Alice는 메시지를 암호화하고, Bob은 이를 복호화해서 원래의 내용을 읽는다.


Alice는 먼저 전달하려는 평문 메시지 $m$을 가지고, 자신의 암호화 키 $K_A$를 사용해 암호화한다. 이 과정을 통해 $K_A(m)$이라는 암호문(ciphertext)이 생성된다. 암호화는 평문을 외부에서 알아볼 수 없는 형태로 바꾸는 과정으로, 네트워크 상에서 중간에 누군가 메시지를 가로채더라도 내용을 파악하지 못하게 한다.


이 암호문은 Bob에게 전달된다. Bob은 자신의 복호화 키 $K_B$를 사용해 이 암호문을 복호화한다. 복호화는 암호화를 역으로 수행하는 과정이고, 아래 식으로 표현할 수 있다.


$$
m = K_B(K_A(m))
$$


즉, Bob이 자신의 키로 Alice의 암호문을 복원하면 원래 메시지 $m$이 다시 나타난다.


실제로는 $K_A$가 Alice의 공개키, $K_B$가 Bob의 개인키일 수도 있다. 대칭키 암호에서는 $K_A$와 $K_B$가 동일한 키를 공유하는 경우도 있다.


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.25.54.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/crpytography/image-1753236563968-1)


암호화 시스템도 완전히 안전하지는 않다. 만약 공격자인 Trudy가 시스템을 공격하려고 한다면, 사용 가능한 정보에 따라 다양한 방법을 시도할 수 있다.


첫 번째는 암호문만을 가지고 시도하는 공격(ciphertext-only attack)이다. 이 경우 Trudy는 평문은 전혀 모르고, 오직 암호화된 메시지(=ciphertext)만 가지고 분석해야 한다. 이 상황에서는 두 가지 주요 전략이 존재한다.

- 하나는 무차별 대입(brute force) 방식으로, 가능한 모든 키를 하나씩 대입해 복호화를 시도하고, 그중 자연스러운 결과가 나오는 키를 찾아내는 방식이다. 키 공간이 충분히 클 경우 시간과 자원이 매우 많이 들기 때문에 실용적인 키 크기를 사용하는 것이 중요하다.
- 다른 하나는 통계적 분석(statistical analysis)이다. 예를 들어 어떤 글자가 더 자주 나오는지를 분석해서 암호문 속 규칙을 추론하려는 시도다. 단순한 암호일수록 성공 확률이 높다.

두 번째는 알고 있는 평문을 기반으로 한 공격(known-plaintext attack)이다. 여기서 Trudy는 어떤 암호문이 어떤 평문에 대응되는지를 일부 알고 있다. 예를 들어, Trudy가 "alicebob"이라는 평문과 그에 대응하는 암호문을 알고 있다면, 특히 암호 체계가 단순하다면(ex, 단일 치환 암호) 각 알파벳이 어떻게 암호화되는지를 비교적 쉽게 유추할 수 있다.


세 번째는 선택 평문 공격(chosen-plaintext attack)이다. Trudy가 자신이 선택한 평문을 암호화해서 대응하는 암호문을 얻을 수 있는 상황을 의미한다. 이 경우 암호화 함수의 구조나 키에 대한 정보를 유추해내기가 상대적으로 쉬워진다. 특히 블록 암호나 대칭키 시스템에서는 주의가 필요하다.



cryptography 기본 용어 정리


## 📡 라우팅을 거대하게


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_9.48.16.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/inter-as-inter-as/image-1753236592459-0)


지금까지 살펴본 라우팅은 이상적인 가정을 바탕으로 설명된 것이었다. 모든 라우터가 동일하게 동작하고, 네트워크가 평평하게(flat) 구성되어 있다고 가정했지만 실제 인터넷 환경은 이와 다르다.


현실에서는 전 세계적으로 수십억 개의 목적지가 존재한다. 이 규모에서는 각 라우터가 모든 목적지를 라우팅 테이블에 저장할 수 없다. 뿐만 아니라, 이 테이블을 주기적으로 교환하게 되면 네트워크 링크 자체가 그 정보 전달만으로도 과부하에 빠질 수 있다.


또한 실제 인터넷은 단일 네트워크가 아니라 수많은 네트워크가 연결된 구조이고 각 네트워크는 독립적인 관리 주체 아래 운영된다. 이런 관리적 자율성(administrative autonomy) 때문에 각 네트워크는 자체 내부의 라우팅 방식을 설정하고 통제하고자 할 수 있다. 결국 이러한 요구와 제약을 충족하기 위해 라우팅 시스템은 규모에 맞게 설계되어야 하고 계층적 구조와 자율 시스템 개념이 필요하게 된다.


## 📡 계층적 네트워크


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_9.48.38.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/inter-as-inter-as/image-1753236596174-1)


인터넷에서는 라우팅의 확장성을 확보하기 위해 전체 네트워크를 하나의 평면 구조로 유지하지 않고, 자율 시스템(AS, Autonomous System)이라는 단위로 나누어 계층적으로 구성한다. 각 AS는 도메인(domain)이라고도 불린다. 일반적으로 하나의 ISP, 대기업 네트워크, 또는 대형 캠퍼스 네트워크와 같이 독립적으로 운영되는 네트워크 집합을 의미한다.


AS 내부에서의 라우팅은 intra-AS routing 또는 intra-domain routing이라고 부른다. 같은 AS 안에 있는 모든 라우터는 동일한 라우팅 프로토콜을 사용해야 한다. 대표적으로 OSPF, RIP, IS-IS가 여기에 해당한다. 반면 AS가 다르면 서로 다른 라우팅 프로토콜을 자유롭게 사용할 수 있다. 이 덕분에 각 네트워크는 자율적으로 내부 운영 방식을 선택할 수 있고, 관리 유연성이 확보된다.


AS의 경계에 위치한 라우터는 게이트웨이 라우터(gateway router)라 불린다. 이들은 자신의 AS에 속한 내부 라우터들과도 연결되어 있지만, 동시에 외부의 다른 AS에 속한 라우터와도 링크를 가지고 있다. 즉, AS 간의 경로 선택과 같은 외부 라우팅도 담당해야 한다.


AS 간의 라우팅은 inter-AS routing 또는 inter-domain routing이라 한다. 주로 게이트웨이 라우터들이 담당한다. 외부와의 경로 교환은 물론 내부 AS 내에서의 경로 결정도 함께 수행하게 된다. 이렇게 계층적이고 분할된 구조 덕분에 인터넷은 수십억 개의 목적지를 가진 거대한 네트워크임에도 불구하고 효율적이고 유연한 라우팅이 가능해진다.


## 📡 라우팅끼리의 협력


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_9.48.28.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/inter-as-inter-as/image-1753236598681-2)


intra-AS 라우팅과 inter-AS 라우팅은 각각 다른 목적지를 위해 동작하지만, 실제로는 서로 협력해 각 라우터의 포워딩 테이블을 완성한다.


Intra-AS 라우팅은 같은 AS 내부의 목적지로 가는 경로를 결정한다. 예를 들어, AS1에 속한 한 라우터가 동일한 AS1 내의 다른 호스트에게 데이터를 전달하려면 OSPF나 RIP 같은 내부 라우팅 프로토콜이 사용된다. 이때 라우팅 경로는 해당 AS의 정책과 네트워크 구조에 따라 자율적이고 독립적으로 결정된다. 따라서 같은 프로토콜을 사용하더라도 각 AS는 다른 라우팅 전략을 취할 수 있다.


Inter-AS 라우팅은 다른 자율 시스템에 속한 목적지로의 경로를 결정한다. 이때 사용되는 대표적인 프로토콜은 BGP(Border Gateway Protocol)이다. 하지만 BGP는 목적지 AS에 도달하기 위한 논리적 경로만 결정해 이 경로를 실제로 따라가기 위한 물리적인 전달 경로는 다시 내부 라우팅 프로토콜에 의해 계산된다.


즉, 외부 AS를 향하는 트래픽의 경우

- 어떤 외부 AS 경로를 선택할지는 BGP가 결정하고,
- 선택된 외부 경로까지 가는 실제 내부 경로는 intra-AS 라우팅 프로토콜이 다시 계산하는 구조다.

이렇게 두 계층이 분업해서 작동하기 때문에 외부 목적지에 대해서도 정확한 포워딩 테이블 항목이 생성될 수 있다.


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_9.48.50.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/inter-as-inter-as/image-1753236601390-3)


인터넷은 수많은 자율 시스템(AS)들이 서로 연결되어 구성된다. 이때 각 AS 내부에서 동작하는 라우터들은 단지 내부 목적지뿐 아니라, 외부 AS로 향하는 트래픽도 처리해야 한다. 특히 외부 목적지를 향하는 패킷을 처리할 때, AS 내부의 라우터가 어떤 경계 라우터(gateway router)를 통해 포워딩할지 결정하는 문제는 inter-AS 라우팅 정보에 의존하게 된다.


예를 들어 AS1 내부의 한 라우터가 도착지가 AS1 외부에 있는 데이터그램을 수신했다고 가정하자. 이 경우 해당 라우터는 패킷을 AS1 내부의 다른 라우터 중 하나인 게이트웨이 라우터(gateway router)에게 전달해야 한다. 하지만 AS1에는 여러 개의 게이트웨이 라우터가 있을 수 있고 어느 게이트웨이를 선택해야 하는지는 intra-AS 라우팅만으로는 판단할 수 없다.


이 문제를 해결하기 위해 inter-AS 라우팅 프로토콜(BGP 등)은 아래와 같은 역할을 수행해야 한다.

1. 외부 목적지에 도달 가능한 경로 정보를 수집해야 한다. 예를 들어 어떤 목적지는 AS2를 통해 접근 가능하고, 또 다른 목적지는 AS3을 통해 가능하다는 정보가 필요하다.
2. 수집한 도달 가능성(reachability) 정보를 AS1 내부의 모든 라우터에 전파해야 한다. 그래야 AS1 내부의 어느 라우터라도 외부 목적지에 대해 적절한 게이트웨이를 선택할 수 있다.
3. 이 정보를 바탕으로 intra-AS 라우팅 알고리즘은 각 목적지에 대해 해당 게이트웨이로 향하는 경로를 계산하고, 포워딩 테이블을 완성하게 된다.

결과적으로, 외부 목적지를 향한 포워딩 결정도 결국 AS 내부 라우팅 체계에 의해 수행되지만, 그 의사결정의 기반은 inter-AS 라우팅 정보에 있다. 즉, inter-AS 라우팅은 단순히 외부 경로를 계산하는 데 그치지 않고, AS 내부의 포워딩 경로 형성에도 영향을 미친다.


## 📡 intra-AS 라우팅 프로토콜


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-12_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_9.48.57.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/inter-as-inter-as/image-1753236604176-4)


intra-AS routing에는 여러 프로토콜이 사용된다. 각각은 목적지까지의 경로를 계산하는 방식과 네트워크 규모, 확장성 등에 따라 특징이 다르다. 실제 운영 환경에서는 다음과 같은 프로토콜들이 주로 사용된다.

- RIP (Routing Information Protocol)
    - 고전적인 거리 벡터(Distance Vector) 방식의 라우팅 프로토콜이다. 라우터들은 자신의 거리 벡터를 30초마다 이웃 라우터에게 주기적으로 전달해 이걸 바탕으로 경로를 갱신한다. 구현이 간단하고 구조가 직관적이지만, 수렴 속도가 느리고 홉 수 제한(최대 15홉) 등으로 인해 현재는 널리 사용되지 않는다.
- EIGRP (Enhanced Interior Gateway Routing Protocol)
    - 역시 거리 벡터 기반이지만, 전통적인 DV 방식보다 더 빠르고 안정적인 수렴을 목표로 한다. 수치적 거리 대신 복합적인 경로 메트릭(대역폭, 지연 등)을 고려하고 업데이트도 변화가 있을 때만 보내는 방식이 특징이다. 오랫동안 시스코(Cisco)의 독점 프로토콜이었지만 2013년에 표준화되면서 공개되었다.
- OSPF (Open Shortest Path First)
    - 링크 상태(link-state) 기반의 라우팅 프로토콜로, 네트워크 전체의 구조를 토폴로지 형태로 파악하고 Dijkstra 알고리즘을 이용해 최단 경로를 계산한다. 라우터들은 주기적으로 자신과 연결된 링크 상태 정보를 전체 AS에 광고해 모든 라우터가 동일한 네트워크 맵을 유지한다. 계층적 구조와 강력한 확장성을 바탕으로, 오늘날 가장 널리 사용되는 intra-AS 라우팅 프로토콜 중 하나다.
- IS-IS (Intermediate System to Intermediate System)
    - OSPF와 매우 유사한 링크 상태 기반 프로토콜로 ISO 표준에 기반한 점만 다를 뿐 핵심 원리는 거의 동일하다. 둘 다 대규모 네트워크에서의 정밀한 경로 제어와 빠른 수렴을 지원한다.


intra-AS, inter-AS

네트워크 관리: SNMP, NETCONF, YANG


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-03_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_11.58.36.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-link-layer/image-1753237162915-0)


컴퓨터 네트워크를 계층 구조로 나누었을 때, 링크 계층(Link Layer)은 물리적인 연결에 가장 가까운 위치에 있다. 이 계층은 네트워크를 구성하는 각 노드들이 실제로 연결된 통신 경로를 통해 데이터를 주고받을 수 있도록 도와주는 역할을 한다.


여기서 말하는 노드(node)는 데이터를 주고받는 **호스트**(예: 사용자 단말기나 서버) 또는 **라우터**를 의미하고, 이 노드들이 서로 통신하려면 물리적으로 인접한 노드와 연결되어 있어야 한다. 이러한 연결을 우리는 링크(link)라고 부른다. 링크 계층은 바로 이 링크를 통해 데이터를 전달하는 일을 맡고 있다.


링크는 물리적인 전송 매체를 기반으로 한다. 예를 들어, **유선(wired)** 링크는 이더넷 케이블이나 광케이블처럼 물리적인 전선을 통해 정보를 전달하고, **무선(wireless)** 링크는 Wi-Fi나 LTE처럼 전파를 통해 통신한다. 또한 LAN(Local Area Network)은 비교적 좁은 공간에서 여러 장치가 공유된 매체를 이용해 연결된 환경을 말하고 이 역시 링크 계층의 역할이 중요한 영역이다.


링크 계층에서 데이터를 주고받을 때는 프레임(frame)이라는 단위를 사용한다. 프레임은 상위 계층(예: 네트워크 계층)에서 전달받은 데이터그램(datagram)을 감싸는 형태로 구성된다. 이렇게 만들어진 프레임을 인접한 노드에게 전송하는 것이 이 계층의 기본적인 역할이다. 말하자면, 링크 계층은 데이터그램을 한 홉(hop)씩 다음 노드로 넘겨주는 연결의 다리 역할을 한다.


이 기능은 단순해 보일 수도 있지만, 실제 네트워크 환경은 매우 다양하다. 예를 들어 이동통신망, 글로벌 ISP 환경, 데이터센터, 기업 내부 네트워크 등 각각의 환경마다 링크 계층이 다루는 기술과 방식은 조금씩 다를 수밖에 없다. 그만큼 링크 계층은 네트워크 기술의 기반을 이루면서도 다양한 하드웨어와 프로토콜을 포괄해야 하는 중요한 위치에 있다.


결국 링크 계층은 “한 노드에서 인접한 노드로 데이터를 안정적으로 전달”하는 데 집중해 매체 접근 제어(MAC), 주소 지정, 오류 검출 등의 기능을 제공한다.


### 링크 계층의 맥락


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-03_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_11.58.26.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-link-layer/image-1753237167109-1)


링크 계층은 네트워크 전체에서 한 구간씩 데이터를 전달하는 역할을 맡는다. 우리가 하나의 목적지까지 데이터를 보낼 때, 그 경로에는 여러 개의 네트워크 링크들이 연결되어 있을 수 있다. 예를 들어 어떤 패킷이 전송되는 동안 처음 구간에서는 **Wi-Fi**, 다음 구간에서는 이더넷(Ethernet)을 이용할 수도 있다. 이처럼 각 구간(link)마다 사용하는 전송 기술은 다를 수 있고, 그에 따라 적용되는 링크 계층 프로토콜도 서로 다르다.


각 링크 프로토콜은 자신만의 방식으로 데이터를 전달하고 제공하는 기능도 다르다. 예를 들어 어떤 프로토콜은 오류를 자동으로 감지하고 재전송해주는 신뢰성 있는 전송(reliable transfer)을 지원할 수 있지만, 다른 프로토콜은 그런 기능 없이 데이터만 빠르게 전달하는 데 초점을 맞출 수도 있다. 이처럼 링크 계층은 네트워크 전체를 구성하는 각기 다른 구간들에서 저마다의 방식을 통해 데이터 전달을 책임지고 있는 것이다.


이를 보다 쉽게 이해할 수 있도록, 하나의 여행에 비유해보자. 예를 들어 누군가가 프린스턴에서 로잔(Lausanne)까지 여행을 간다고 해보자. 프린스턴에서 JFK 공항까지는 리무진, JFK에서 제네바까지는 비행기, 제네바에서 로잔까지는 기차를 이용한다면, 이 여행 전체는 여러 개의 이동 수단이 결합된 여정이 된다. 이때 여행자는 바로 데이터그램(datagram)이고, 각 교통 수단이 지나가는 경로는 통신 링크(link), 이동 수단 자체는 링크 계층 프로토콜, 그리고 여정을 설계해준 여행사(또는 경로를 선택해주는 존재)는 라우팅 알고리즘에 해당한다.


이 비유에서 보듯이, 링크 계층은 전체 여정에서 한 구간 한 구간의 이동을 책임진다. 각 구간마다 교통수단이 다르고, 그에 따라 이용 방식이나 제공되는 서비스도 다르지만, 전체 여정을 위해서는 이 다양한 방식들이 함께 잘 조화되어야 한다. 네트워크에서도 마찬가지다. 하나의 패킷이 목적지까지 잘 도달하려면 각 링크마다 적절한 링크 계층 프로토콜이 작동하면서, 상위 계층에서 설정한 경로에 따라 **순차적으로 안정적인 전달**이 이루어져야 한다.


결과적으로 링크 계층은 **이질적인 네트워크 환경**을 부드럽게 연결해주는 인터페이스 역할을 해 물리적으로 인접한 노드 간에 데이터를 안전하고 효율적으로 넘겨주는 데 집중한다.


### 링크 계층의 핵심 기능들


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-04_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_12.14.57.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-link-layer/image-1753237170002-2)


링크 계층은 단순히 데이터를 옆 노드로 전달하는 것 이상의 역할을 한다. 이 계층은 네트워크의 하위에 위치하면서, 인접한 노드 간의 데이터 전송을 좀 더 안정적이고 효율적으로 만들기 위한 다양한 기능들을 제공한다. 하위 계층인 물리 계층이 제공하지 못하는 논리적인 조율을 담당해 상위 계층이 제대로 작동할 수 있도록 돕는다.


가장 기본적인 기능 중 하나는 프레이밍(framing)이다. 링크 계층은 상위 계층에서 내려온 데이터그램(datagram)을 프레임(frame)이라는 형식으로 감싼다. 이 과정에서 앞쪽에는 헤더(header), 뒤쪽에는 트레일러(trailer)를 덧붙이는데, 이 안에는 출발지와 목적지를 식별하기 위한 MAC 주소 같은 정보가 포함된다. MAC 주소는 IP 주소와 달리 **물리적 장치에 부여된 고유한 식별자**로, 동일한 네트워크 내에서의 통신에서 주로 사용된다.


또한 링크 계층은 공유된 매체(shared medium)—예를 들어 이더넷이나 무선 네트워크처럼 여러 장치가 동시에 접근할 수 있는 환경—에서는 누가 언제 통신할지를 정하는 채널 접근 제어(channel access) 기능도 수행한다. 이를 통해 충돌을 최소화하고, 네트워크 자원을 공정하게 분배할 수 있게 된다.


그 외에도 링크 계층은 선택적으로 신뢰성 있는 데이터 전송(reliable delivery)을 제공할 수도 있다. 손실되거나 오류가 발생한 프레임을 다시 보내주는 기능인데, 보통 무선 링크처럼 오류율이 높은 환경에서 중요하게 쓰인다. 반면 이더넷처럼 비트 오류율이 낮은 환경에서는 이런 기능이 오히려 불필요한 오버헤드가 되어 생략되기도 한다.


<div class="notion-callout">💡 그렇다면 TCP 같은 end-to-end 신뢰성이 있으면 충분하지 않나?

무선 구간에서 손실이 많으면, 매번 TCP 수준에서 다시 전송하는 것보다 링크 계층에서 빠르게 재전송해주는게 더 효율적일 수 있다.

</div>


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-04_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_12.15.05.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-link-layer/image-1753237173459-3)


이 외에도 링크 계층은 흐름 제어(flow control) 기능을 통해 송신자와 수신자의 전송 속도를 조절함으로써 버퍼 오버플로우를 방지하고, 안정적인 통신을 유지하도록 돕는다. 그리고 오류 검출(error detection) 기능은 신호 감쇠나 잡음으로 인해 발생할 수 있는 비트 오류를 수신 측에서 인식해 잘못된 프레임을 폐기하거나 재전송을 요청할 수 있도록 한다. 나아가 일부 시스템에서는 오류 정정(error correction) 기능까지 제공되어 수신 측에서 비트 오류를 스스로 복구하기도 한다.


마지막으로, 링크의 통신 방식에는 half-duplex와 full-duplex가 있다. half에서는 양쪽 노드가 동시에 데이터를 주고받을 수 없고, 번갈아 가며 전송해야 하는 반면, full에서는 양방향 통신이 동시에 가능하다.


<div class="notion-callout">💡 현재 대부분의 Ethernet은 전이중을 사용하고 있다. 무선처럼 충돌 위험이 있는 경우에는 반이중이 사용되기도 한다.</div>


### 링크 계층은 어디에 구현되는가


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-04_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_1.01.34.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-link-layer/image-1753237176704-4)


링크 계층은 네트워크에 연결된 모든 호스트—즉, 컴퓨터, 스마트폰, 서버, 라우터 등 네트워크 통신을 수행하는 모든 장치—에 구현되어 있다. 단 한 대의 장치라도 링크 계층이 없으면 물리적으로 인접한 장치와의 데이터 전송이 불가능해진다.


링크 계층은 주로 네트워크 인터페이스 카드(NIC: Network Interface Card) 또는 네트워크 칩셋에 의해 구현된다. 예를 들어 우리가 흔히 사용하는 이더넷 카드, Wi-Fi 칩 등이 바로 링크 계층 기능을 담당하는 하드웨어이다. 물리적인 신호만 주고받는 것이 아니라, 링크 계층과 물리 계층을 모두 구현한 복합적인 구조를 갖고 있다. 즉, 프레임 생성, MAC 주소 처리, 오류 검출, 채널 접근 등의 링크 계층 기능뿐 아니라 전기적 신호를 주고받는 물리 계층의 역할까지 함께 수행한다.


이 NIC는 호스트의 내부 시스템 버스에 연결되어 있어 CPU, 메모리 등 시스템의 다른 구성 요소와 데이터를 주고받을 수 있다. 따라서 운영체제의 네트워크 스택에서 내려온 데이터그램이 링크 계층까지 도달하면 NIC를 통해 실제 프레임으로 변환되고, 물리 매체를 타고 외부로 전송된다. 반대로 수신된 프레임도 NIC에서 처리되어 상위 계층으로 전달된다.


흥미로운 점은, 이 구현이 하드웨어만 구성된 것이 아니다. 실제로 링크 계층은 하드웨어, 소프트웨어, 그리고 펌웨어가 결합된 형태로 동작한다. 예를 들어 프레임 포맷이나 주소 필드 해석 같은 기능은 하드웨어에 내장된 논리 회로에서 수행되지만, 드라이버나 펌웨어는 이러한 동작을 설정하거나 제어하는 데 쓰인다. 또한 운영체제는 NIC와의 인터페이스를 관리하면서 오류가 생겼을 때 로그를 남기거나 처리 순서를 조절하기도 한다.


### 링크 계층이 하는 일 - 송/수신 관점


![controller는 NIC나 칩셋을 의미하고, 여기서 프레임 생성 및 처리, 오류 검사 등을 맡음. physical layer는 전기 신호를 만들고 해석하는 계층.](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-link-layer/image-1753237179603-5)


컴퓨터에서 하나의 애플리케이션이 다른 장치의 애플리케이션과 통신을 할 때, 데이터는 여러 네트워크 계층을 차례로 거치며 포워딩된다. 송신 측에서는 애플리케이션 계층에서 만들어진 데이터가 전송 계층, 네트워크 계층을 거쳐, 마지막으로 링크 계층에 도달하게 된다.


이때 링크 계층은 상위 계층에서 전달받은 데이터그램(datagram)을 받아 이를 프레임으로 감싼다. 이 과정에서 헤더(link header)가 추가되며, 이 안에는 MAC 주소, 프레임 번호, 오류 검출 코드 등 전송에 필요한 다양한 정보들이 담긴다. 또한 링크 계층은 선택적으로 오류 검출(error checking), 신뢰성 있는 전송(reliable delivery), 흐름 제어(flow control) 기능을 수행하기도 한다. 이렇게 구성된 프레임은 네트워크 인터페이스 컨트롤러(NIC)를 통해 전선이나 전파와 같은 물리적 매체를 통해 전송된다.


수신 측에서도 이 흐름은 거꾸로 진행된다. 먼저 물리 계층을 통해 신호가 수신되고, NIC가 이를 프레임으로 재구성한다. 이 프레임은 링크 계층에서 처리되며, 이때 **오류가 있는지 검사하고**, 필요시 **재전송을 요청**하거나 프레임을 **버리기도** 한다. 오류가 없고 정상적인 프레임이라면, 그 안에서 데이터그램을 추출해 상위 계층(네트워크 계층)으로 전달한다.


이 과정은 송신자와 수신자 양쪽 모두에서 이루어지고 링크 계층은 노드 간의 직접적인 통신을 가능하게 하는 가장 가까운 계층으로서 기능한다. 데이터를 전달하는 것처럼만 보일 수 있지만 실제로는 오류 처리, 흐름 조절, 주소 해석 등 다양한 세부 기능들이 함께 작동하면서 안정적이고 신뢰성 있는 네트워크 통신을 만들어내고 있다.



데이터링크 계층이란


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-16_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.20.27.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/subnet-cidr/image-1753237554379-0)


인터넷에 연결된 장치는 모두 IP 주소를 가지고, 이 주소를 통해 서로를 식별하고 데이터를 주고받는다. 하지만 모든 장치를 단일 네트워크로 구성할 수는 없기 때문에 큰 네트워크를 여러 개의 작은 네트워크(서브넷, subnet)로 나누는 방식이 사용된다.


Subnet은 말 그대로 _Sub + Network_, 즉 하나의 큰 네트워크를 작은 단위로 나눈 것을 의미한다. 서브넷은 라우터를 거치지 않고도 직접 통신이 가능한 인터페이스들의 집합이다. 예를 들어 같은 스위치나 공유기에 연결된 장비들은 보통 하나의 서브넷에 속해 서로 라우터를 통과하지 않고 직접 데이터를 주고받을 수 있다.


IP 주소는 두 부분으로 구성된다.

- 네트워크 부분(network/subnet part): 이 주소가 어느 서브넷에 속하는지를 나타낸다. 라우터는 이 정보를 바탕으로 패킷의 전송 경로를 결정한다.
- 호스트 부분(host part): 해당 서브넷 내에서 각 장치를 구분하는 식별자 역할을 한다.

결과적으로 IP 주소만으로도 어느 네트워크에 있는 어떤 장치인지를 식별할 수 있게 된다. 이후 등장하는 서브넷 마스크나 CIDR 표기법으로 경계를 명확하게 표현할 수 있다.


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-16_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.20.38.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/subnet-cidr/image-1753237557667-1)


서브넷을 표현할 때는 일반적으로 CIDR(Classless Inter-Domain Routing) 표기법을 사용한다. 예를 들어 `223.1.1.1/24`라는 주소에서 /24는 이 주소가 서브넷 마스크 24비트를 사용하고 있다는 의미다.


이 경우, 앞의 24비트가 서브넷(네트워크) 주소로 사용되고 나머지 하위 8비트는 해당 서브넷 내의 호스트 주소로 사용된다. `223.1.1.0/24` 서브넷에는 총 256개의 주소(0~255)가 포함되지만, 일반적으로 네트워크 주소(.0)와 브로드캐스트 주소(.255)는 사용할 수 없기 때문에, 실제로는 223.1.1.1부터 223.1.1.254까지가 유효한 호스트 주소가 된다. 이 범위에 속하는 장비들은 모두 같은 서브넷에 속해 있고 서로 라우터 없이 직접 통신할 수 있다.


서브넷은 물리적 연결성과 논리적 경계를 함께 고려해 정의된다. 기본적으로, 각 인터페이스가 라우터 없이 직접 연결될 수 있는 장비들끼리 하나의 서브넷(섬)을 이룬다고 생각하면 된다. 유선이라면 같은 스위치에 연결된 장비들이, 무선이라면 같은 WiFi 액세스 포인트에 연결된 장비들이 보통 같은 서브넷에 속한다. 이러한 방식으로 네트워크를 분리하면 효율적인 트래픽 분산, 보안, 주소 공간 관리 측면에서도 유리하다.


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-16_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.20.47.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/subnet-cidr/image-1753237561250-2)


IP 주소가 같은 서브넷에 속한다는 것은 라우터를 거치지 않고 직접 통신할 수 있다는 것을 의미한다. 서브넷은 IP 주소의 앞부분을 공유하는 장비들의 집합이고, 앞부분의 길이는 서브넷 마스크로 정의된다. 예를 들어 `/24` 서브넷 마스크는 IP 주소의 상위 24비트가 서브넷을 식별하는 부분이고, 하위 8비트가 해당 서브넷 내의 호스트를 구분하는 부분이다. `223.1.1.x` 형식의 주소들은 모두 `223.1.1.0/24` 서브넷에 속하게 된다.


아래는 여러 서브넷과, 각각에 포함된 일부 IP 주소들의 예시다.


| **서브넷 주소 (/24)** | **포함된 IP 주소들**                             |
| ---------------- | ------------------------------------------ |
| **223.1.1.0/24** | 223.1.1.1, 223.1.1.2, 223.1.1.3, 223.1.1.4 |
| **223.1.2.0/24** | 223.1.2.1, 223.1.2.2, 223.1.2.6            |
| **223.1.3.0/24** | 223.1.3.1, 223.1.3.2, 223.1.3.27           |
| **223.1.7.0/24** | 223.1.7.0, 223.1.7.1                       |
| **223.1.8.0/24** | 223.1.8.0, 223.1.8.1                       |
| **223.1.9.0/24** | 223.1.9.1, 223.1.9.2                       |


각 서브넷은 `223.1.X.0/24` 형식으로 구성되어 동일한 X 값을 공유하는 장비들이 같은 서브넷에 속한다. 예를 들어 `223.1.3.1`과 `223.1.3.27`은 모두 `223.1.3.0/24` 서브넷에 속하므로, 서로 직접 통신할 수 있다. 반면 `223.1.3.1`과 `223.1.2.2`는 서로 다른 서브넷이므로, 라우터를 통해서만 통신할 수 있다.


### CIDR


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-16_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.20.54.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/subnet-cidr/image-1753237564231-3)


과거의 IP 주소 체계는 Class A, B, C처럼 고정된 블록 단위로 주소를 할당하는 클래스 기반 주소 체계였다.

- Class A: /8 – 약 16,777,216개의 호스트 주소
- Class B: /16 – 약 65,536개
- Class C: /24 – 256개

이 방식은 단순했지만 주소 공간을 매우 비효율적으로 사용하게 되었다. 작은 기업이나 조직도 필요 이상으로 큰 주소 블록을 할당받아야 했고, 전체 IP 주소 공간이 빠르게 고갈되었다.


이러한 문제를 해결하기 위해 등장한 방식이 바로 CIDR(Classless Inter-Domain Routing)이다. CIDR은 주소를 클래스에 구애받지 않고 필요한 만큼의 크기로 유연하게 나눌 수 있는 방식이다.


CIDR 표기법은 아래와 같은 형식을 따른다. 


```plain text
a.b.c.d/x
```


a.b.c.d는 IP 주소의 시작점, 즉 서브넷(네트워크)의 주소다. `/x`는 상위 x비트가 네트워크(서브넷) 식별자임을 나타닌다. 나머지 `32 - x` 비트는 호스트 구분에 사용한다.


예를 들어 `192.168.10.0/28`은 상위 28비트가 네트워크다. 나머지 4비트를 사용해 최대 16개의 호스트 주소를 지정할 수 있다. 단, 네트워크와 브로드캐스트 주소를 제외하면 실제 사용 가능한 호스트는 14개다.


CIDR 덕분에 IP 주소 공간을 훨씬 더 세밀하게 분할할 수 있게 되었고 네트워크 크기에 맞는 주소를 할당함으로써 주소 낭비를 줄이고 라우팅 효율도 향상시킬 수 있게 되었다.



Subnet & CIDR


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_7.55.33.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow/image-1753237429463-0)


OpenFlow는 소프트웨어 정의 네트워킹(SDN, Software-Defined Networking)의 기술 중 하나로, 네트워크 장비의 제어 기능을 중앙화된 컨트롤러로 분리해내기 위해 도입되었다. 기존의 네트워크 장비는 데이터 전달과 제어 기능을 모두 장비 내부에서 처리했기 때문에 복잡한 정책 변경이나 새로운 기능 적용이 어렵고 비효율적이었다. 하지만 OpenFlow는 제어 기능을 외부의 중앙 컨트롤러가 담당하고, 스위치나 라우터는 단순히 컨트롤러의 지시에 따라 패킷을 전달하는 역할만 수행하게 만든다.


OpenFlow를 사용하는 장비는 내부에 flow table이라는 구조를 가지고 있다. 이 테이블은 들어오는 패킷이 어떤 규칙에 일치하는지를 확인한 뒤, 그에 따라 어떤 동작을 취할지를 정의한다. 각 flow entry는 일치 조건(Match), 동작(Action), 그리고 통계 정보(Stats)로 구성된다.

- Match (일치 조건)
    - 패킷이 스위치에 도달하면 해당 패킷의 헤더 정보를 기반으로 flow table에서 일치하는 항목을 찾는다. 이때 참조하는 헤더 필드는 계층별로 다양하다.
    - 예를 들어 데이터링크 계층에서는 입력 포트나 MAC 주소, VLAN 정보 등을 사용할 수 있고, 네트워크 계층에서는 IP 주소나 프로토콜 번호, 전송 계층에서는 TCP/UDP 포트 번호 등이 사용된다. 이처럼 풍부한 헤더 필드를 기반으로 정교한 분류가 가능하다.
- Action (동작)
    - 일치하는 flow entry를 찾으면 정의된 동작에 따라 해당 패킷은 특정 포트로 전달되거나(drop), 헤더가 수정되거나, 혹은 컨트롤러로 전송되기도 한다. 네트워크의 제어 논리는 외부 컨트롤러에서 정의하고 각 스위치는 그것을 빠르게 실행하는 역할을 맡는다.
- Stats (통계)
    - 각 flow entry는 얼마나 많은 패킷과 바이트를 처리했는지에 대한 통계 정보를 유지한다. 네트워크 상태를 모니터링하거나 동적으로 정책을 조정할 때 활용될 수 있다.

## 📡 계층 분리 없는 제어: L2~L3


![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow/image-1753237432534-1)


OpenFlow는 패킷의 헤더 정보를 기반으로 구체적인 정책을 테이블 형식으로 정의하고 네트워크를 제어할 수 있다. 이 규칙들은 포워딩부터 방화벽 수준의 정책까지 다양하게 확장될 수 있다.


<u>Destination-Based Forwarding</u>

- IP 주소가 51.6.0.8인 패킷을 포트 6으로 전달한다
    - `IP Dst` 51.6.0.8
    - `나머지 필드` * (와일드카드)
    - `Action` forward to port6
- 전통적인 라우팅과 비슷하지만, 매우 구체적인 정책을 테이블로 명시할 수 있다

<u>Firewall (방화벽)</u>

- TCP 포트 22 (SSH)로 향하는 트래픽은 차단(drop), 특정 애플리케이션(SSH)을 정책적으로 차단할 수 있다
    - `IP Proto` TCP
    - `TCP Dst Port` 22
    - `나머지 필드` *
    - `Action` drop
- 특정 출발지 IP(128.119.1.1)에서 온 패킷은 모두 차단(drop)하고, 특정 장치나 유저의 트래픽을 정밀하게 필터링이 가능하다
    - `IP Src` 128.119.1.1
    - `나머지 필드` *
    - `Action` drop

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_8.12.30.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow/image-1753237435089-2)


<u>Layer 2 Destination-Based Forwarding</u>

- 목적지 MAC 주소가 22:A7:23:11:E1:02인 프레임, 스위치의 포트 3으로 전달한다
    - `MAC dst` 22:A7:23:11:E1:02
    - `나머지 필드` *
    - `Action` forward to port3
- L3 라우터 뿐만 아니라 L2 스위치까지 모두 통합적으로 제어 가능하다

## 📡 End-to-End 제어


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_8.17.42.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow/image-1753237437141-3)

- 네트워크 구성도
    - s3는 h5/h6과 연결
    - s1 → s2는 라우팅 중간 지점
    - s2는 목적지 h3/h4로 연결

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_8.17.49.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/openflow/image-1753237440316-4)


OpenFlow의 가장 큰 장점 중 하나는 여러 스위치를 거치는 복잡한 네트워크 흐름을 중앙 컨트롤러가 설계하고 각 스위치에는 이에 맞는 규칙만 설치하면 전체 트래픽 흐름을 구현할 수 있다는 점이다. 다음은 그런 end-to-end 제어의 대표적인 예시다.


네트워크에는 여러 호스트와 스위치가 존재한다. h5와 h6는 각각 IP 주소 `10.3.0.5`, `10.3.0.6`을 가지며 스위치 s3에 연결되어 있고, 최종 목적지는 `10.2.0.3`(h3) 또는 `10.2.0.4`(h4)다. 이 트래픽은 스위치 s1과 s2를 거쳐야 하고 이러한 흐름을 위해 각 스위치에는 다음과 같은 flow rule이 설정된다.

- s3 (엣지 스위치)
    - h5, h6에서 나온 트래픽은 일단 s1으로 포워딩한다

    ```plain text
    match:
      IP Src = 10.3.*.*
      IP Dst = 10.2.*.*
    action:
      forward(3)  // s1으로 향하는 포트
    ```

- s1 (중간 스위치)
    - s1은 s3에서 온 트래픽을 s2로 넘긴다

    ```plain text
    match:
      ingress port = 1
      IP Src = 10.3.*.*
      IP Dst = 10.2.*.*
    action:
      forward(4)  // s2로 전달
    ```

- s2 (마지막 스위치)
    - 목적지 IP에 따라 정확한 호스트로 포워딩한다

    ```plain text
    match:
      ingress port = 2
      IP Dst = 10.2.0.3
    action:
      forward(3)  // h3
    
    match:
      ingress port = 2
      IP Dst = 10.2.0.4
    action:
      forward(4)  // h4
    ```

- 전체 흐름
    - h5 → s3 (match) → s1 (match) → s2 (match) → h3 or h4
    - 모든 스위치의 Flow Table이 SDN 컨트롤러에 의해 조율된다(orchestrated). 즉, 하나의 중앙 지능이 전체 네트워크 동작을 설계하고 명령한다.


OpenFlow


### **왜 인터넷에는 계층적 주소 구조가 필요한가?**


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.07.00.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/hierarchical-ip-addressing/image-1753237511896-0)


인터넷은 수십억 개의 장치가 연결된 거대한 네트워크다. 이 장치들 각각이 고유한 IP 주소를 가지기 때문에 라우터는 목적지 IP 주소를 기반으로 올바른 경로를 선택해 패킷을 전달해야 한다. 하지만 전 세계의 모든 IP 주소에 대해 일일이 경로를 저장하고 유지하는 것은 기억 공간이나 관리 측면에서 비현실적이다.


이 문제를 해결하기 위해 인터넷은 계층적인 IP 주소 구조(hierarchical addressing)를 채택하고 있다. 즉, IP 주소를 조직, 지역, ISP 등의 논리적 단위로 묶고, 이 단위별로 요약된 경로 정보(route aggregation)만 라우터에 광고하게 한다.


### route aggregation


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.07.05.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/hierarchical-ip-addressing/image-1753237513737-1)


가령, Fly-By-Night ISP라는 지역 인터넷 제공업체가 다음과 같은 여러 조직에 IP 주소 블록을 할당했다고 하자.

- Organization 0 → `200.23.16.0/23`
- Organization 1 → `200.23.18.0/23`
- Organization 2 → `200.23.20.0/23`
- …
- Organization 7 → `200.23.30.0/23`

Fly-By-Night ISP는 이 모든 조직의 IP 주소들을 하나의 **더 큰 블록**으로 묶어 다음과 같이 광고할 수 있다.

> ‘`200.23.16.0/20`으로 시작하는 주소는 모두 내게 보내줘.’

이 말은 해당 ISP가 관리하는 조직들에 대한 **세부 경로 정보를 외부에 드러내지 않고**, 하나의 요약된 경로(prefix)만 인터넷 전체에 알려주는 것을 의미한다. 이처럼 여러 개의 세부 네트워크를 하나로 묶는 과정을 route aggregation(경로 집합화)라고 한다.


마찬가지로 더 상위 ISP인 “ISPs-R-Us”는 여러 하위 ISP가 사용하는 IP 대역 전체를 199.31.0.0/16처럼 더 넓은 범위로 요약해 상위 인터넷 백본에 광고할 수 있다.


### 더 구체적인 경로


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.07.10.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/hierarchical-ip-addressing/image-1753237515888-2)


계층적 IP 주소 구조는 주소 공간을 집약하고 요약된 경로(prefix)를 통해 라우팅 정보를 간결하게 유지할 수 있게 해준다. 하지만 인터넷은 끊임없이 변화하는 환경이기 때문에 라우팅 체계도 이 변화에 유연하게 대응해야 한다.


예를 들어 어떤 조직(Organization 1)이 기존에는 Fly-By-Night ISP를 통해 인터넷에 연결되어 있었지만, 이제 ISPs-R-Us라는 다른 ISP로 이관되었다고 하자.


이 경우 기존 라우팅 구조는 다음과 같았다.

- Fly-By-Night ISP는 전체 조직들(Organization 0~7)에 대해 `200.23.16.0/20`이라는 요약된 경로로 광고하고 있었고, 이 범위에는 Organization 1(200.23.18.0/23)도 포함되어 있었다.

하지만 이제 Organization 1은 ISPs-R-Us를 통해 연결되므로 더 이상 Fly-By-Night ISP에 속하지 않는다. 이에 따라 ISPs-R-Us는 `200.23.18.0/23`이라는 더 구체적인 경로를 별도로 광고하게 된다.

> ‘`199.31.0.0/16`은 내 소속이고, 추가로 `200.23.18.0/23`도 내 쪽으로 보내줘.’

이처럼 하나의 주소 대역(ex, `200.23.18.0/23`)에 대해 여러 ISP가 서로 다른 범위로 경로를 광고할 수 있고, 이 중 가장 구체적인 경로, 즉 Longest Prefix Match(가장 긴 일치 접두어)를 따르는 것이 인터넷 라우팅의 원칙이다.


### **IP 주소는 어떻게 할당되는가? 그리고 충분한가?**


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.07.27.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/hierarchical-ip-addressing/image-1753237518496-3)


전 세계의 IP 주소 공간은 무작위로 사용되는 것이 아니라, **글로벌한 관리 체계**를 통해 조직적으로 배분된다. 이 관리의 최상단에는 ICANN(Internet Corporation for Assigned Names and Numbers)이 있으며, ICANN은 다음과 같은 역할을 수행한다.

- IP 주소 공간을 전 세계 5개 지역 인터넷 등록기관(RIR, Regional Internet Registries)에 할당한다.

    각 RIR은 소속 국가와 지역의 ISP나 기관에 주소를 재분배한다.

- DNS 루트 영역을 관리하고, 각 최상위 도메인(TLD, 예: .com, .edu)에 대한 관리 권한을 위임한다.

하지만 인터넷이 급속도로 확산되면서 IPv4의 32비트 주소 공간이 예상보다 훨씬 빠르게 고갈되었다. 실제로 ICANN은 2011년에 IPv4 주소의 마지막 블록을 RIR에 모두 할당했다. 이로써 공식적인 IPv4 주소 배정은 종료되었고, 기존에 남아 있는 할당된 주소만이 재사용되고 있다.


이러한 주소 부족 문제를 해결하기 위한 대응은 두 가지 방향으로 이루어졌다.

1. NAT(Network Address Translation): 하나의 공용 IP 주소를 여러 장치가 공유하게 함으로써, IPv4 주소 공간의 활용도를 극대화.
2. IPv6의 도입: IPv6는 주소 길이를 128비트로 확장해 사실상 무한에 가까운 주소 공간을 제공한다.

IP 주소 체계를 설계할 당시엔 누구도 지금처럼 전 세계 수십억 대의 장치가 인터넷에 연결될 거라고 예측하지 못했다. 이에 대해 인터넷의 아버지 중 한 명인 Vint Cerf는 훗날 이렇게 회고했다.

> _**도대체 우리가 얼마나 많은 주소 공간이 필요할 줄 알았겠어?**_
>
> - Vint Cerf (IPv4를 32비트로 설계한 결정을 돌아보며)
>
>


인터넷은 어떻게 주소를 구조화할까 - Hierarchical IP Addressing


## 📡 네트워크 계층의 목표


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.04.54.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237347944-0)


네트워크 계층의 데이터 플레인(data plane)에 초점을 맞춰 네트워크 계층이 어떤 서비스 모델을 제공하는지, 라우팅과 포워딩의 차이, 실제 라우터가 어떻게 동작하는지를 살펴본다. IP 주소 체계를 포함한 주소 지정 방식, 전통적인 목적지 기반 포워딩을 확장한 generalized forwarding 개념, 그리고 이러한 구조가 전체 인터넷 아키텍처에서 어떤 역할을 수행하는지도 함께 다룬다.


실제 인터넷 환경에서 어떻게 구현되는지도 역시 중요한 학습 주제다. 구체적으로는 IP 프로토콜의 데이터그램 구조와 동작 방식, 여러 장비가 하나의 공용 IP 주소를 공유할 수 있게 해주는 NAT(Network Address Translation), 그리고 방화벽이나 프록시와 같은 미들박스(middleboxes)의 역할과 동작 방식까지 살펴본다.


## 📡 Data plane


### 네트워크 계층 서비스와 프로토콜


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.02.55.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237349723-1)


네트워크 계층은 송신 호스트에서 수신 호스트로 전송 계층의 세그먼트를 전달하는 역할을 한다.


송신 측에서는 전송 계층에서 생성된 세그먼트를 IP 데이터그램으로 캡슐화한 후, 링크 계층으로 넘긴다. 수신 측에서는 이 데이터그램에서 세그먼트를 추출해 전송 계층에 전달한다. 이 과정을 통해 애플리케이션 데이터는 여러 네트워크를 거쳐 목적지에 도달한다.


네트워크 계층 프로토콜은 인터넷에 연결된 모든 장치에 구현되어 있다. 호스트뿐 아니라, 경로를 선택하고 데이터그램을 전달하는 라우터에도 포함된다. 라우터는 수신한 데이터그램의 IP 헤더를 확인해 목적지를 파악하고, 이를 적절한 출력 포트로 전송한다.


네트워크 계층은 모바일, 기업, ISP, 데이터센터 등 다양한 종류의 네트워크를 하나로 연결하는 구조를 형성한다. 이질적인 네트워크들이 함께 동작할 수 있는 이유는 IP(Internet Protocol)라는 공통된 프로토콜이 존재하기 때문이다. IP는 서로 다른 네트워크 간 통신을 가능하게 해 인터넷이 전 세계적으로 작동할 수 있도록 한다.


### 네트워크 계층의 두 가지 주요 기능


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.04.14.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237354022-2)


네트워크 계층은 포워딩$_{forwarding}$과 라우팅$_{routing}$이라는 두 가지 필수적인 기능을 수행한다.


포워딩은 라우터가 입력 링크로 받은 패킷을 적절한 출력 링크로 이동시키는 과정이다. 로컬 작업으로, 각 라우터가 자신의 포워딩 테이블을 참조해 개별 패킷을 어디로 보낼지 결정한다. 여행에 비유하자면, 포워딩은 특정 교차로나 인터체인지를 통과하는 과정과 유사하다.


이 두 기능은 상호 보완적이다. 라우팅이 전체 경로의 청사진을 그린다면, 포워딩은 그 청사진에 따라 각 지점에서 다음 홉으로 패킷을 전달하는 작업을 수행한다. 네트워크 계층의 효율성은 이 두 기능이 얼마나 잘 조화를 이루는지에 달려 있다.


### 네트워크 계층: data plane, control plane


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.04.23.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237358395-3)


네트워크 계층은 기능적으로 data plane과 control plane이라는 두 가지 구분된 영역으로 나눌 수 있다.


data plane은 라우터 단위의 지역적$_{local}$ 기능을 담당한다. 주요 역할은 라우터의 입력 포트로 도착한 데이터그램을 어떤 출력 포트로 전달할지 결정하는 것이다. 이 결정은 주로 패킷 헤더에 있는 값들(특히 목적지 주소)을 검사해 이루어진다. data plane은 고속으로 동작해야 하므로 주로 하드웨어로 구현되고 나노초 단위의 시간 프레임 내에서 작동한다.


반면, control plane은 네트워크 전반에 걸친 논리를 구현한다. 출발지 호스트에서 목적지 호스트까지 데이터그램이 라우터들을 통해 어떻게 라우팅될지 결정한다. control plane은 밀리초 단위의 시간 프레임에서 작동하고 주로 소프트웨어로 구현된다.


control plane 구현에는 두 가지 접근 방식이 있다.

- 전통적인 라우팅 알고리즘
    - 각 라우터에 개별적으로 구현되어 있으며, 라우터들은 서로 라우팅 정보를 교환해 포워딩 테이블을 구성합니다.
- 소프트웨어 정의 네트워킹$_{SDN}$
    - 중앙집중식 접근 방식으로, 라우팅 결정은 원격 서버(컨트롤러)에서 이루어지고, 이 결정이 각 라우터의 포워딩 테이블에 설치됩니다.

## 📡 Control plane


### 라우터별 control plane


![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237375329-8)


전통적인 네트워크 구조에서는 각 라우터가 자체적으로 control plane 기능을 수행한다. 라우팅 알고리즘은 라우터마다 독립적으로 구현되고 라우터 간 상호작용을 통해 전체 네트워크의 control plane이 분산된 형태로 구성된다.


각 라우터는 인접한 라우터들과 주기적으로 라우팅 정보를 교환하고 이를 바탕으로 네트워크 토폴로지를 학습한다. 그 결과로 최적 경로를 계산해 포워딩 테이블에 저장한다. 포워딩 테이블은 데이터 패킷을 올바른 경로로 전달하기 위해 data plane이 참조하는 중요한 자료다.


포워딩 과정 자체는 단순하다. 라우터는 수신한 패킷의 헤더 중 목적지 IP 주소를 확인하고, 포워딩 테이블에서 해당 항목을 찾아 출력 포트를 결정한다. 포워딩은 테이블 기반의 헤더 조회를 통해 이루어진다.


이 구조는 control plane이 라우터별로 분산되어 있어 네트워크 확장성 측면에서 유리하다. 각 라우터가 독립적으로 동작하므로 단일 장애점이 없다는 장점도 있다. 하지만 일일이 정책을 정해줘야 하기 때문에, 네트워크 전체에 정책을 일관되게 적용하기 어려워 구성과 운영이 복잡해질 수 있다.


### 소프트웨어 정의 네트워킹(SDN) control plane


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.20.04.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237364316-5)


소프트웨어 정의 네트워킹(SDN: Software Defined Networking)은 네트워크의 control plane을 중앙에서 관리하는 방식이다. 전통적인 네트워크에서는 각 라우터가 자체적으로 라우팅 결정을 내리지만, SDN에서는 이러한 기능이 중앙의 컨트롤러로 옮겨진다.

> 기존의 분산형 네트워크 구조는 유연하지만, 네트워크 상태를 통합적으로 파악하거나 일관된 정책을 적용하는 데에는 한계가 있다. 이런 문제를 해결하기 위한 접근이 바로 소프트웨어 정의 네트워킹(SDN)이다.

컨트롤러는 네트워크 전체 상태에 대한 전반적인 정보를 가지고 있고 이걸 바탕으로 각 라우터에 필요한 포워딩 테이블을 계산해 전달한다. 이 과정에는 OpenFlow 같은 표준 프로토콜이 사용된다.


SDN 구조에서는 라우터가 제어 기능을 수행하지 않는다. 컨트롤러로부터 받은 포워딩 테이블을 참고해 data plane 수준에서 패킷을 전달하는 역할만 한다. 제어와 실행이 분리되어 라우터는 결정이 아닌 실행만 맡는다.


이렇게 되면 네트워크 운영을 단순화할 수 있고정책을 일관되게 적용할 수 있다는 장점이 있다. 또한 새로운 기능이나 정책을 컨트롤러에만 반영하면 전체 네트워크에 빠르게 확산시킬 수 있어, 트래픽 관리, 보안, 가상화 등 다양한 기능 구현에 유리하다.


하지만 중앙 컨트롤러는 단일 장애점(Single Point of Failure)이 될 수 있고, 네트워크 규모가 커질수록 컨트롤러의 부하와 확장성 문제가 나타날 수 있다. 이를 보완하기 위해 최근에는 복수의 컨트롤러를 사용하는 분산형 구조도 함께 연구되고 있다.


### 네트워크 계층 서비스 모델


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.20.14.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237368020-6)


네트워크 서비스 모델은 송신자에서 수신자로 데이터그램을 전달하는 “채널”이 어떤 수준의 서비스 보장을 제공할지를 정의한다. 이 모델은 단일 데이터그램에 대해 적용될 수도 있고, 데이터그램의 연속적인 흐름(플로우)에 대해 적용될 수도 있다. 개별 데이터그램에 대한 서비스로는 데이터그램이 반드시 목적지까지 전달되는 것을 보장하는 방식이나, 40밀리초 이하의 지연 시간 내에 도달할 것을 보장하는 방식이 있다. 


반면, 플로우 단위의 서비스에서는 더 정교한 보장이 필요하다. 예를 들어 데이터그램이 송신 순서대로 수신되도록 보장하거나, 특정 플로우에 대해 최소한의 대역폭을 보장하거나, 각 패킷 간의 간격이 일정 수준 이상 변하지 않도록 제한하는 방식이 해당한다.


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.20.25.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237370335-7)


네트워크 계층의 서비스 모델은 데이터그램 전송 시 어떤 품질 보장을 제공하는지를 정의하고, 네트워크 아키텍처가 애플리케이션에게 어떤 수준의 신뢰성과 성능을 제공할 수 있는지를 나타낸다. 현재의 인터넷은 best-effort 서비스 모델을 채택하고 있어 전송되는 데이터그램에 대해 대역폭, 손실 방지, 순서 보장, 지연 시간 등에 대해 아무런 보장을 제공하지 않는다.


![image.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237375329-8)


반면 ATM 네트워크는 Constant Bit Rate(CBR) 모델을 통해 고정된 대역폭을 제공하고, 패킷 손실 없이 순서와 타이밍까지 보장하는 높은 수준의 서비스를 제공한다. 같은 ATM 기반이라도 Available Bit Rate(ABR) 모델은 최소 대역폭만 보장하고, 그 외 품질 요소들은 보장하지 않는다.


인터넷 환경에서도 품질 보장을 제공하려는 시도로 Intserv(Integrated Services)와 Diffserv(Differentiated Services)라는 두 가지 모델이 있다. 


Intserv는 RFC 1633에 정의되어 데이터그램의 성공적인 목적지 전달은 물론, 도착 순서와 지연 시간까지 명시적으로 보장해 종단 간 흐름에 대해 필요한 대역폭을 사전에 예약하는 구조다. 이에 비해 Diffserv는 RFC 2475에서 정의되어 흐름이 아닌 트래픽 클래스 단위로 차별화된 처리를 통해 QoS를 제공한다. Diffserv는 일부 조건에서 순서나 지연, 대역폭에 대한 상대적 보장을 가능하게 하지만 Intserv처럼 정밀한 품질 보장을 명시적으로 제공하지는 않는다.


### best-effort 모델에 대한 고찰


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.25.23.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/data-plane-control-plane/image-1753237379182-9)


인터넷은 전 세계적으로 수많은 네트워크와 장비들이 연결되어 형성된 구조다. 이처럼 이질적인 환경에서 통일된 품질 보장을 제공하는 것은 기술적으로나 운영 측면에서 많은 제약이 따른다. 이러한 배경 속에서, 인터넷은 복잡한 보장 없이도 동작 가능한 단순한 전송 모델, 즉 best-effort 모델을 채택하게 되었다.


best-effort 모델은 가능한 한 데이터를 전달하되, 지연, 손실, 순서 보장 등을 명시적으로 보장하지 않는다. 그 대신 구현이 단순하고 확장성이 뛰어나 다양한 환경에서 손쉽게 도입될 수 있었다. 이 점이 인터넷이 빠르게 확산되는 데 중요한 역할을 했다.


충분한 대역폭이 확보된 환경에서는 실시간 음성 통화나 화상 회의처럼 지연에 민감한 애플리케이션도 대부분의 경우 수용 가능한 품질을 유지할 수 있다. 명시적인 보장 없이도 서비스 제공이 가능했던 것이다. 애플리케이션 계층에서도 이러한 한계를 보완할 수 있었다. 데이터센터와 콘텐츠 전송 네트워크(CDN)는 사용자와 가까운 위치에서 서비스를 제공함으로써 지연을 줄이고 전송 효율을 높였다. 분산된 애플리케이션 구조를 통해 네트워크 계층이 복잡한 보장을 제공하지 않아도 안정적인 사용자 경험이 가능해졌다.


게다가 탄력적인 애플리케이션은 네트워크 상황에 맞춰 전송 속도를 조절하는 혼잡 제어 메커니즘을 통해 혼잡 상태에서도 전체적인 안정성과 공정성을 유지할 수 있었다. 결과적으로 best-effort 모델은 단순함과 실용성이라는 강점을 바탕으로, 인터넷의 확장성과 유연성을 이끌어낸 설계가 될 수 있었다.



2025