# CSS Chunking이란?

CSS Chunking은 웹 애플리케이션의 성능을 높이기 위한 전략 중 하나예요. 간단히 말하면, CSS 파일을 여러 개의 작은 덩어리(Chunk)로 쪼개고, 필요한 부분만 골라서 로드하는 방식이죠. 예를 들어, 특정 페이지(라우트)를 볼 때 모든 CSS를 한꺼번에 불러오는 게 아니라 그 페이지에 필요한 CSS만 불러오게 해서 로딩 시간을 줄일 수 있어요.

Next.js에서는 `next.config.js` 파일 내에 실험적인 기능인 `experimental.cssChunking` 옵션으로 이 CSS Chunking 기능을 켤 수 있습니다. 기본값은 `true`로 되어 있어요.

```js
import type { NextConfig } from 'next'

const nextConfig = {
  experimental: {
    cssChunking: true, // 기본값이라 특별히 설정 안 해도 활성화됨
  },
} satisfies NextConfig

export default nextConfig
```

---

## 더 알아두면 좋은 점

- CSS Chunking을 활성화하면 사용자 경험이 개선되는 경우가 많아요. 특히 큰 프로젝트나 여러 페이지로 구성된 복잡한 앱에서 효과가 크죠.
- 하지만 작은 사이트에서는 chunk가 너무 잘게 쪼개져서 오히려 관리가 번거로울 수도 있어요.
- 이 기능이 아직 `experimental` 상태라서, 일부 환경에서는 예상치 못한 문제가 발생할 수도 있으니, 배포 전에 충분한 테스트가 필요해요.
- Next.js뿐만 아니라 다른 프레임워크나 번들러(예: Webpack)에서도 비슷한 CSS 분할 기능을 지원하니, 프로젝트에 맞게 선택하면 좋아요.

CSS Chunking을 활용해서 효율적인 스타일 로딩 전략을 세워보세요! 웹사이트가 한층 더 빨라질 거예요.


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

## 옵션 설명

- **true (기본값)**  
  Next.js는 가능한 한 CSS 파일을 병합하려고 시도해요. 파일 간의 명시적, 암묵적인 의존성을 import 순서에서 파악해서 CSS 청크(chunk)의 수를 줄이고, 결과적으로 요청(request) 수를 줄여주는 방식이에요.

- **false**  
  Next.js가 CSS 파일을 병합하거나 재정렬하지 않아요. 각 파일이 독립적으로 로드됩니다.

- **`strict`**  
  CSS 파일을 임포트된 순서 그대로 로드해줘요. 이 경우 청크와 요청 수가 늘어날 수 있지만, CSS가 예상치 못한 동작을 할 때 유용할 수 있어요.

---

### 언제 `strict` 모드를 쓸까?

예를 들어 `a.css`와 `b.css`를 서로 다른 파일에서 임포트하는데 순서가 다르다고 가정해봅시다. (어떤 파일에서는 `a.css`를 먼저 임포트하고, 다른 파일에서는 `b.css`를 먼저 임포트하는 경우) 기본 옵션인 `true`는 두 파일을 병합할 때 임포트 순서를 무시하고 병합할 수 있어요. 만약 `b.css`가 `a.css`에 의존한다면, 이 병합이 CSS 적용을 꼬이게 만들 수 있습니다.

이럴 때 `strict` 옵션을 사용하면 임포트 순서를 엄격히 지켜 각 CSS 파일이 실제 임포트된 순서대로 로드됩니다. 대신 청크와 요청 수가 늘어나죠.

---

### 결론 및 추천

대부분의 프로젝트에서는 **`true`(기본값)** 모드를 사용하는 걸 추천해요. 요청 수가 줄어들고 성능 향상에 도움되거든요. 다만, CSS가 복잡하고 의존성이 까다롭다면 `strict` 모드를 시도해보세요.

---

### 추가 팁: CSS 병합 최적화 고려하기

- CSS 파일이 많고, 임포트 순서가 복잡한 상황이라면 의존성 관계를 명확하게 정리해보세요.
- Styled Components, Emotion 같은 CSS-in-JS 라이브러리를 도입하면 이러한 문제를 깔끔하게 해결할 수도 있어요.
- 또한, Next.js 13부터는 app 디렉터리 기반의 새로운 라우팅과 CSS 처리 방법이 제공되니 최신 문서도 참고해 보는 걸 추천드립니다!

Next.js 15에서 cssChunking을 활용해 CSS 로딩 최적화하기

# devIndicators 소개

개발할 때 현재 보고 있는 **라우트(route)** 정보를 화면에 살짝 보여주는 표시기를 설정할 수 있는 기능인데요, 이름처럼 개발하면서 디버깅할 때 꽤 유용합니다.

```js
devIndicators: false | {
  position?: 'bottom-right' | 'bottom-left' | 'top-right' | 'top-left', // 기본값은 'bottom-left'
},
```

- **false로 설정하면** 표시기가 아예 안 보이게 되고,
- **객체로 설정하면** 표시기가 화면 어디에 나타날지 지정할 수 있어요.

기본 위치는 좌측 하단(bottom-left)인데, 필요에 따라 원하는 위치로 바꿔서 쓸 수 있습니다.

---

### 한 번에 짚고 가는 팁!

- `devIndicators`는 **개발 모드에서만 동작**합니다. 실제 프로덕션 빌드에서는 자동으로 표시되지 않으니까 걱정하지 않아도 되죠.
- **표시기를 끈다고 해서 에러가 안 보이는 게 아닙니다**! Next.js가 빌드 에러나 런타임 에러 메시지는 여전히 보여주니 개발에 지장 없으니 안심하시고요.
- 만약 화면에 표시되는 위치 때문에 UI가 살짝 가려진다고 생각하면, 위치 속성(`position`)을 살짝 옮겨보세요.

---

### 마무리

개발할 때 여기저기 화면 확인하느라 바쁘거나, 어떤 페이지에서 에러가 났는지 헷갈릴 때 이 devIndicators 기능이 꽤 도움 됩니다. 혹시 어디 있었지 싶은 여러분, 지금 바로 `next.config.js`에서 한번 설정해보세요~!

필요에 따라 끄거나, 위치 조정해가면서 편하게 개발 환경을 맞춰보시길 바랍니다 :)


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

## 문제 해결하기 (Troubleshooting)

### 인디케이터가 라우트를 정적(static)으로 표시하지 않을 때

만약 어떤 라우트가 정적으로 처리되길 기대했는데, 인디케이터가 이 라우트를 동적(dynamic)으로 표시한다면, 그 라우트가 정적 렌더링에서 제외(옵트아웃)되었을 가능성이 큽니다.

이게 맞는지 확인하려면, 터미널에서 다음 명령어로 애플리케이션을 빌드해보세요:

```bash
next build --debug
```

그 후 출력 메시지를 보면,  
- 정적(혹은 프리렌더)된 라우트는 ○ (동그라미) 기호로 표시되고,  
- 동적 라우트는 ƒ (함수) 기호로 표시됩니다.  

예를 들어 아래와 같은 형태로 확인할 수 있죠.

> 참고로 여기서 동적 라우트는 빌드 시점에 HTML이 생성되지 않고, 요청 시마다 서버 또는 클라이언트에서 렌더링이 이뤄지는 라우트를 말해요.  
> 반면 정적 라우트는 미리 컴파일 단계에서 HTML을 만들어서 빠르게 응답할 수 있도록 한 거예요.

이 방법으로 어떤 라우트가 왜 정적이 아닌지, 혹은 원래 기대와 달리 표시되는 이유를 찾아낼 수 있습니다.

---

추가 팁을 조금 드리자면, Next.js를 사용할 때 라우트가 정적이 되려면 `getStaticProps`를 사용하거나, 혹은 별도의 동적 데이터 가져오기 함수가 없어야 해요. 만약 `getServerSideProps` 같은 서버 사이드 렌더링 함수를 쓰면 당연히 동적 라우트가 됩니다.  
조금 더 깊게 캐치하고 싶다면, 라우트 파일의 내보낸(export) 함수를 한 번 점검해보세요!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

여러분, Next.js에서 라우트가 정적(static) 렌더링을 안 하고 동적(dynamic) 렌더링을 선택하는 경우가 있는데요. 위 표처럼 `/products/[id]` 같은 경로가 동적으로 서버에서 렌더링된다는 걸 볼 수 있어요.

```js
Route (app)                              Size     First Load JS
┌ ○ /_not-found                          0 B               0 kB
└ ƒ /products/[id]                       0 B               0 kB
 
○  (Static)   prerendered as static content
ƒ  (Dynamic)  server-rendered on demand
```

왜 이런 선택이 발생하는 걸까요? 주된 두 가지 이유가 있어요.

| 이유                                      | 설명                                                                                     |
|-----------------------------------------|----------------------------------------------------------------------------------------|
| 동적 API 사용 (Dynamic APIs)             | 런타임에 실행되는 정보를 필요로 하는 API가 있을 때, 예를 들어 사용자의 로그인 상태에 따라 다른 데이터를 보여줘야 할 때.      |
| 캐시되지 않는 데이터 요청 (Uncached data) | ORM이나 데이터베이스 드라이버에 직접 데이터를 요청하는 상황. 이 경우 요청마다 데이터가 달라지므로 정적으로 미리 만들기 어려움. |

만약 여러분의 라우트에서 위 두 가지 상황 중 하나라도 해당하면, 정적 렌더링은 어렵다고 볼 수 있어요. 이럴 때는 어떻게 해야 할까요? Next.js가 제공하는 좋은 방법들이 있어요.

### `loading.js` 혹은 React의 `Suspense` 활용하기

정적 렌더링이 어려워서 서버에서 데이터를 받아와야 할 때, 유저 경험을 끌어올리기 위해 로딩 상태를 잘 처리하는 것이 중요하죠. Next.js에서는 특정 라우트 또는 컴포넌트에 `loading.js` 파일을 만들어서 로딩 화면을 쉽게 관리할 수 있고, React 18의 `Suspense`와 스트리밍 기능을 이용해 점진적으로 UI를 보여줄 수도 있어요.

이렇게 하면 사용자 입장에서는 페이지가 느리게 느껴지지 않고, 필요한 콘텐츠가 준비되는 대로 자연스럽게 화면에 나타나도록 할 수 있답니다.

---

#### 간단 요약!

- 동적 API나 데이터베이스 호출이 있으면 정적 렌더링 못 함.
- 이럴 때는 `loading.js`나 `Suspense`로 로딩 상태 UX 챙기기!
- 꼭 정적 렌더링만 고집하지 말고, 상황에 맞게 스트리밍 방식도 활용해 보세요.

필요하면 더 자세한 예제도 만들어서 공유할게요. 궁금한 점 있으면 언제든 물어보세요!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

## 버전 히스토리

| 버전           | 변경 사항                                                                                                   |
| -------------- | ---------------------------------------------------------------------------------------------------------- |
| `v15.2.0`      | 새로운 `position` 옵션을 추가해 화면 표시기가 더 좋아졌어요! 대신에 `appIsrStatus`, `buildActivity`, `buildActivityPosition` 옵션은 이제 더 이상 사용되지 않으니 참고하세요. |
| `v15.0.0`      | `appIsrStatus` 옵션을 통해 정적인(on-screen) 표시기가 새롭게 추가되었습니다.                                    |

버전 기록을 보면 기능이 점점 개선되어 가는 모습이 보이죠? 특히 화면에 표시되는 인디케이터 같은 UI 요소는 사용자의 편의성을 크게 증가시키니까 이런 업데이트는 반가운 소식이에요. 개발할 때는 deprecated 된 옵션들을 미리 확인하고 최신 옵션으로 바꿔주는 것이 나중에 문제를 줄이는 데 도움이 됩니다!

Next.js 15에서 devIndicators 활성화 및 활용법 완벽 가이드

# 압축(compress) 알아보기

Next.js에서는 기본적으로 next start 명령어나 커스텀 서버를 사용할 때 렌더된 콘텐츠와 정적 파일에 gzip 압축을 자동으로 적용해줘요. 이건 압축 설정이 따로 되어 있지 않은 애플리케이션을 위한 최적화 기능이라 보면 돼요. 만약 여러분이 이미 커스텀 서버에서 압축을 설정해놨다면, Next.js는 중복으로 압축을 추가하지 않습니다.

> 참고할 점:
> 
> Vercel에 애플리케이션을 호스팅하면 압축 방식이 먼저 brotli를 사용하고 그 다음에 gzip 방식을 사용해요. 이 두 가지는 모두 흔히 쓰이는 웹 압축 알고리즘이고, brotli가 최신 방식이라 더 효율적인 경우가 많답니다.
> 
> 내 사이트가 압축을 제대로 적용하고 있는지, 그리고 어떤 알고리즘을 쓰는지는 브라우저가 서버에 보내는 `Accept-Encoding` 헤더와, 서버가 실제로 응답하는 `Content-Encoding` 헤더를 보면 확인할 수 있어요.

---

## 압축 비활성화하기

Next.js에서 기본 압축 기능을 끄고 싶을 때가 있죠? 예를 들어, 이미 서버 레벨에서 압축을 관리하거나, 특정 환경에서 이 기능을 조절해야 할 때요. 이럴 땐 어떻게 해야 할까요?

Next.js 공식 문서에 따르면, 커스텀 서버를 쓰는 경우에만 압축 설정을 직접 조절할 수 있습니다. 기본 `next start` 명령어 사용 시에는 압축을 끄는 옵션이 따로 없으니, 서버 레벨에서 하는 쪽이 좋습니다.

---

### 조금 더 알려드리는 팁!

- **서버에서 직접 압축 설정을 관리하고 싶다면?**  
  Express.js 같은 커스텀 서버를 쓰면서 `compression` 미들웨어를 직접 설치하고 설정할 수 있어요. 이 경우 Next.js는 기본 압축을 넣지 않으니, 내가 원하는 방식과 수준으로 압축을 제어할 수 있죠.

- **왜 압축이 중요할까?**  
  압축은 네트워크 대역폭을 아껴주고 페이지 로딩 속도를 크게 개선해줍니다. 특히 이미지나 스크립트, CSS 같은 정적 파일에는 gzip이나 brotli 압축이 필수라고 할 만큼 효과가 크죠.

- **brotli와 gzip 차이는?**  
  브라우저 지원이 점점 좋아지고 있는 brotli는 gzip보다 더 높은 압축률을 보여 줍니다. Vercel이 brotli를 먼저 사용하는 이유기도 하고요. 다만, 모든 브라우저가 빠르게 brotli를 지원하지 않을 때 fallback으로 gzip을 쓰면서 호환성을 챙기죠.

압축 설정은 사용 환경과 요구사항에 따라 다르게 적용해야 하니까, 내 애플리케이션에 맞는 최적화를 고민해보세요!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

압축 기능을 끄고 싶다면, `compress` 설정 옵션을 `false`로 지정하면 돼요:

```js
module.exports = {
  compress: false,
}
```

그런데, 압축 기능을 끄는 건 추천하지 않아요! 왜냐하면 압축은 네트워크 대역폭을 줄여주고 애플리케이션 성능을 올려주거든요. 만약 이미 서버 쪽에서 별도의 압축 설정을 해두었다면 그때는 꺼도 괜찮아요.

## 압축 알고리즘 변경하기

기본 압축 알고리즘 외에 다른 알고리즘을 쓰고 싶을 때가 있죠? 압축 알고리즘을 변경하면 성능이나 압축률에 차이가 생길 수 있어요. 다음엔 어떻게 바꾸는지 간단하게 알아볼게요!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

압축 알고리즘을 바꾸고 싶을 때는, 직접 커스텀 서버를 구성하고 `next.config.js` 파일에서 `compress` 옵션을 `false`로 설정해줘야 해요.

예를 들어, nginx를 사용하고 있고 Brotli 압축으로 바꾸려고 한다면, `compress` 옵션을 `false`로 해서 Next.js가 아닌 nginx가 압축을 담당하도록 설정하는 거죠.

> 참고로 알아두면 좋은 점:
Next.js 애플리케이션을 Vercel에서 운영할 경우에는, 압축 처리는 Next.js가 아니라 Vercel의 Edge Network에서 해줍니다. 따라서 `compress` 옵션을 조절하지 않아도 괜찮아요. 자세한 내용은 Vercel 공식 문서를 참고해 보세요.

사실 요즘은 서버에서 압축을 어떻게 처리하느냐에 따라 성능 차이가 꽤 크기 때문에, 직접 제어할 수 있는 환경이라면 Brotli 같은 최신 압축 방식을 적용하는 게 웹사이트 속도 향상에 도움이 됩니다. 그리고 nginx에는 brotli 모듈을 설치하고 설정하는 것도 잊지 마세요!

nextjs 15 컴프레스(압축) 하는 방법



# authInterrupts 옵션 쉽게 이해하기

Next.js에서 `authInterrupts`라는 설정 옵션이 있어요. 이걸 사용하면 보통 제한되어 있는 **금지된 API(forbidden API)** 와 **권한 없는 API(unauthorized API)**를 여러분의 애플리케이션에서 활용할 수 있답니다. 다만, 아직은 실험적인 기능이라서 실제 서비스에 적용할 때는 주의가 필요해요.

사용하려면 `next.config.js` 파일에 아래처럼 설정을 추가해주면 돼요:

```js
import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  experimental: {
    authInterrupts: true,
  },
}
 
export default nextConfig
```

## authInterrupts를 왜 쓸까?

일반적으로 인증과 권한 관련 API들은 보안상 제한되어 있어요. 그런데 개발 중에 이런 제한 때문에 테스트가 어려운 경우가 있잖아요? 이때 `authInterrupts` 옵션을 켜면 다음과 같은 장점이 있어요.

- **실험적인 API 접근 가능**  
  아직 공식 지원이 완벽하지 않은 기능을 미리 써볼 수 있죠.

- **유연한 인증 흐름 제어**  
  인증 과정 중에 특정 API 호출을 가로채거나 변경하는 등, 사용자 경험을 더 세밀하게 다듬을 수 있어요.

## 주의할 점

- **실험적 기능**  
  공식 문서에도 나오듯이 아직 완전한 안정성을 보장할 수 없어요. 실제 서비스에 적용하기 전 충분한 테스트는 필수.

- **보안 위험**  
  권한이 없는 API에 접근할 수 있어서, 잘못 설정하면 보안 취약점이 생길 수 있습니다.

> 개인적으로는 개발 환경과 프로덕션 환경을 구분해서, 예를 들어 `NODE_ENV !== 'production'` 일 때만 사용하는 걸 추천해요!

---

## 마무리

`authInterrupts` 옵션은 Next.js에서 인증 관련 API 사용을 조금 더 실험적으로 다뤄보고 싶은 분들에게 유용한 설정입니다. 하지만 아직 완벽하지 않은 만큼, 안정성과 보안에 특히 신경 써서 다뤄야 해요. 앞으로 Next.js가 이 기능을 더 확장할 수도 있으니, 관심 있는 분들은 꾸준히 업데이트 체크해보세요!

Next.js 15에서 authInterrupts로 사용자 인증 관리하는 방법

# basePath

Next.js 애플리케이션을 도메인의 특정 하위 경로(sub-path) 아래에 배포하고 싶을 때, `basePath` 설정을 사용하면 됩니다.

`basePath`는 애플리케이션에 경로 접두사를 붙여주는 역할을 해요. 예를 들어, 기본값인 빈 문자열(`""`) 대신 `/docs` 경로로 앱을 서비스하고 싶을 때는, `next.config.js` 파일을 열고 아래처럼 `basePath`를 추가하면 됩니다.

```js
module.exports = {
  basePath: '/docs',
}
```

이렇게 하면 내 사이트 주소가 `https://yourdomain.com/docs` 같은 형태가 되겠죠.

---

## 추가 팁!

- `basePath`를 사용할 때는 정적 파일이나 API 호출 경로도 이 경로를 고려해서 작성해야 해요.
- 예를 들어, 이미지 경로나 API 요청할 때 `/docs/images/logo.png`, `/docs/api/data` 이런 식으로 경로를 맞춰줘야 합니다.
- 만약 로컬에서 개발할 땐 `basePath`가 없으니, 경로 문제로 헷갈릴 수 있으니 환경별로 경로를 분리해서 쓰는 것도 좋습니다.
- 또한, `next/link`나 `next/router`를 사용할 때는 자동으로 `basePath`를 인식하기 때문에 경로를 따로 신경 쓸 필요 없다는 점도 기억해 주세요.

실제로 여러 프로젝트를 운영하다 보면, 하나의 도메인에 여러 Next.js 앱을 각기 다른 하위 경로에 딱 맞게 배포할 때 이 설정을 자주 쓰게 됩니다! 활용해보세요 :)


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

> 참고할 점: 이 값은 빌드할 때 반드시 설정되어야 하며, 클라이언트 측 번들에 직접 삽입되기 때문에 빌드 후에는 변경할 수 없어요.

### 링크 관련

next/link나 next/router를 사용할 때 다른 페이지로 이동하는 링크를 만들면, basePath가 자동으로 적용됩니다.

예를 들어, basePath가 `/docs`로 설정되어 있을 때 `/about`이라는 경로를 사용하면 실제 링크는 `/docs/about`으로 자동 변환돼요.

---

추가로 알아두면 좋은 팁을 하나 알려드리자면, basePath를 설정할 때는 실제 배포 환경에서 경로가 어떻게 작동할지를 꼭 확인해보세요. 특히 여러 경로나 서브 디렉터리를 다룰 때는 혼란이 생기기 쉬우니, dev 환경과 prod 환경에서 모두 테스트하는 걸 추천해요!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

요즘 React 프로젝트에서 자주 보이는 `Link` 컴포넌트 예제인데요, 여기서 기본 경로(basePath)가 설정되어 있을 때 정말 유용한 부분을 하나 알려드릴게요.

아래 코드를 한번 볼게요:

```jsx
export default function HomePage() {
  return (
    <>
      <Link href="/about">About Page</Link>
    </>
  )
}
```

JavaScript에선 이렇게 `Link` 컴포넌트를 사용하는데, 실제 브라우저에 렌더링 될 때는 아래와 같이 바뀐답니다.

```html
<a href="/docs/about">About Page</a>
```

즉, `href` 속성에 `/docs`라는 basePath가 자동으로 붙어서 렌더링이 되는 거죠.

### 왜 이게 좋은 걸까?

만약 프로젝트 루트 경로가 나중에 바뀌어서 `/docs` 같은 경로가 앞에 붙어야 한다면, 기존에 `/about` 같은 경로를 모두 일일이 바꾸는 게 엄청 번거로울 거예요. 근데 이 `Link` 컴포넌트를 쓰면, 앱 안에서 링크를 쓸 때는 항상 깔끔하게 `/about`처럼 기본 경로만 쓰고, 실제 최종 경로는 basePath 설정에 맞게 자동 변경되니까 유지보수가 훨씬 수월해집니다.

---

### 추가 팁

- Next.js 같은 프레임워크에서는 `next.config.js`에서 `basePath` 설정을 해주면 이런 동작이 자동으로 처리돼요.
- 이 방법은 SEO(검색엔진최적화)나 클라이언트 라우팅에서도 깔끔하게 URL 관리를 할 수 있게 도와줍니다.
- 만약 직접 `<a>` 태그를 쓰면 basePath를 수동으로 붙여줘야 하니, 링크 관련 컴포넌트는 꼭 프레임워크에서 제공하는 걸 쓰는 게 좋아요.

나중에 내가 만든 앱이 다른 경로에서 배포될 수도 있겠다 싶으면, 초기부터 이런 basePath를 고려한 링크 방식을 꼭 도입해보세요! 생각보다 개발자 경험(Developer Experience) 측면에서 큰 도움이 됩니다 :)


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

### 이미지 사용할 때 주의사항

Next.js에서 `next/image` 컴포넌트를 사용할 때는 이미지 경로 앞에 `basePath`를 꼭 붙여줘야 해요.

예를 들어, `basePath`가 `/docs`로 설정되어 있으면, 이미지 경로는 `/docs/me.png`로 지정해야 제대로 작동합니다. 이렇게 해야 이미지를 올바르게 불러올 수 있거든요.

```js
import Image from 'next/image'

function Home() {
  return (
    <>
      <h1>나의 홈페이지</h1>
      <Image
        src="/docs/me.png"
        alt="작성자의 사진"
        width={500}
        height={500}
      />
      <p>홈페이지에 오신 걸 환영합니다!</p>
    </>
  )
}

export default Home
```

---

추가로, `next/image`는 기본적으로 이미지 최적화 기능을 제공해서 자동으로 크기 조절, WebP 변환 등 최적화 작업을 해주기 때문에 성능 향상에 큰 도움이 돼요. 하지만 외부 URL 이미지를 사용하거나 `basePath`가 꼭 필요한 경우에는 이 점을 꼭 기억하세요!

또 하나 팁을 드리자면, `width` 와 `height` 속성을 꼭 명시해야 이미지 레이아웃이 흔들리지 않고 안정적으로 렌더링됩니다. 만약 `layout="fill"`을 쓰면 컨테이너 크기에 맞게 이미지가 자동으로 꽉 차게 조절되니 상황에 맞게 사용하면 좋아요.

Next.js 15에서 basePath 설정하는 방법 정리



# appDir

> 참고할 점: Next.js 13.4부터는 이 옵션이 더 이상 필요하지 않습니다. App Router가 이제 안정화되었기 때문이죠.

App Router(즉, app 디렉토리)는 레이아웃, 서버 컴포넌트, 스트리밍, 그리고 데이터 페칭을 컴포넌트와 같은 위치에 두는 ‘colocated data fetching’ 같은 최신 기능들을 지원합니다.

또한, app 디렉토리를 사용하면 React Strict Mode가 자동으로 활성화됩니다. 이 모드는 개발 중에 더 엄격한 검사와 경고를 통해 버그를 미리 찾아내는 데 큰 도움이 되니 참고하세요.

만약 기존 페이지 기반 라우팅에서 app 디렉토리 기반 라우팅으로 천천히 옮겨가고 싶다면, Next.js 공식 문서에 ‘incremental adoption’에 대한 좋은 가이드가 있으니 꼭 한번 확인해 보세요!

---

### 추가 팁: app 폴더를 쓰면 좋은 점

- **레이아웃 분리와 재사용이 쉬워져요.** 예를 들어, 공통 헤더나 사이드바를 레이아웃 파일에 넣고 원하는 페이지에서 쉽게 가져다 쓸 수 있죠.
- **서버 컴포넌트를 이용해 성능 최적화**가 가능해요. 서버에서만 렌더링하도록 지정하면 클라이언트 번들 크기가 줄어들고, 초기 로딩 속도가 빨라집니다.
- **스트리밍 지원** 덕분에 유저에게 콘텐츠를 조금씩 빠르게 보여줄 수 있어요. 대기 시간이 줄어든다는 이야기죠.

Next.js가 점점 발전하면서 이런 최신 기능들을 쉽게 쓰게 해주니까, 최신 버전으로 업데이트해두고 꼭 활용해 보시길 추천합니다!

Nextjs 15의 appDir 사용하는 방법

# assetPrefix

> 주의: Vercel에 배포하면 Next.js 프로젝트에 전역 CDN이 자동으로 설정되기 때문에, Asset Prefix를 따로 수동으로 설정하지 않아도 됩니다.

> 참고로: Next.js 9.5 버전부터는 Base Path를 커스터마이징하는 기능이 추가됐어요. 이 기능을 이용하면 `/docs` 같은 서브 경로에 앱을 호스팅하기 적합해서, 이런 경우에는 Asset Prefix 대신 Base Path를 사용하는 걸 추천합니다.

## CDN 설정하기

자, 이제 직접 CDN 설정을 해보고 싶을 때 어떻게 하는지 살펴볼게요.

---

### assetPrefix란?

`assetPrefix`는 Next.js에서 빌드된 정적 자산들(js, css, 이미지 등)이 로드되는 기본 URL 경로를 지정할 때 사용해요. 예를 들어, CDN 도메인을 지정해두면 사용자들은 CDN에서 자산들을 빠르게 받아볼 수 있죠.

예전에는 배포 환경마다 직접 CDN 주소를 설정해야 했는데, 요즘은 Vercel을 사용하면 자동으로 글로벌 CDN이 세팅되니 크게 신경 쓰지 않아도 됩니다!

---

### 직접 CDN을 연결해야 하는 경우

만약 Vercel이 아닌 AWS S3, CloudFront, Netlify, 또는 다른 호스팅 환경을 사용한다면, 아래처럼 `next.config.js`에 `assetPrefix`를 설정하게 됩니다.

```js
module.exports = {
  assetPrefix: 'https://cdn.mydomain.com',
};
```

이 설정을 하면, 정적 자산들의 경로가 `https://cdn.mydomain.com/_next/static/...`으로 변경되어 CDN에서 서빙됩니다.

---

### 주의할 점

다만, 이렇게 `assetPrefix`를 설정하면 정적 파일뿐 아니라 내부 스크립트와 스타일도 모두 여기서 불러오기 때문에 CDN 도메인의 SSL이나 CORS 설정이 올바르게 되어 있어야 해요. 그렇지 않으면 자원이 제대로 로드 안 되는 문제가 발생할 수 있습니다.

---

### Base Path 활용하기

또 한 가지 중요한 기능! Next.js 9.5버전부터는 `basePath` 옵션도 사용할 수 있어요. `basePath`는 애플리케이션 URL의 기본 경로를 설정하는 건데, 보통 `/docs`나 `/blog` 같이 서브 디렉토리에 앱을 배포할 때 쓰입니다.

```js
module.exports = {
  basePath: '/docs',
};
```

이렇게 설정하면 페이지들이 모두 `/docs` 경로 하위에서 서비스되고, 라우팅 관리가 훨씬 수월해져요.

그리고 중요한 점! 이런 경우에는 굳이 `assetPrefix`를 쓰지 않고, `basePath` 만으로 충분하니 참고하세요.

---

## 정리하자면!

| 상황                                 | 권장 설정                  |
|----------------------------------|-------------------------|
| Vercel 배포                         | 자동 CDN 설정, assetPrefix 불필요 |
| 서브 경로(예: `/docs`)로 앱 배포           | basePath 활용              |
| 직접 CDN 도메인 연결 필요 (Vercel 외)    | assetPrefix에 CDN 주소 설정    |

---

내가 개인적으로 추천하는 팁은 Vercel이나 요즘 메이저 플랫폼들은 대부분 CDN을 자동으로 설정해주니 복잡하게 assetPrefix 건드리지 않고, 필요하면 basePath만 적절히 활용하는 게 가장 깔끔하다는 거예요.

혹시 여러분도 서브 디렉토리로 앱을 배포하거나 직접 CDN 연결해야 하는 상황이 생기면, 위 내용을 참고해서 차근차근 설정해 보세요! 문제 생기면 댓글로 물어봐도 좋고요 :)


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

CDN(Content Delivery Network)을 설정하는 방법에 대해 이야기해볼게요. 좋은 성능을 위해 정적 자산(이미지, JS, CSS 등)을 CDN으로 배포하면 사용자에게 훨씬 빠르게 콘텐츠를 전달할 수 있어요.

Next.js에서는 assetPrefix라는 설정을 이용해서 CDN 주소를 쉽게 지정할 수 있어요. 예를 들어, 여러분의 CDN 도메인이 `https://cdn.mydomain.com`이라면, 다음과 같이 `next.config.mjs` 파일에 설정할 수 있습니다.

```js
// @ts-check
import { PHASE_DEVELOPMENT_SERVER } from 'next/constants'
 
export default (phase) => {
  const isDev = phase === PHASE_DEVELOPMENT_SERVER
  /**
   * @type {import('next').NextConfig}
   */
  const nextConfig = {
    // 개발 환경에서는 assetPrefix를 사용하지 않고, 배포 환경에서만 CDN 도메인을 붙임
    assetPrefix: isDev ? undefined : 'https://cdn.mydomain.com',
  }
  return nextConfig
}
```

이렇게 설정하면 Next.js는 자동으로 자바스크립트나 CSS 같은 정적 파일을 `/next/static/` 폴더에서 불러올 때 CDN 주소를 붙여 요청해줍니다.

예를 들어, 원래라면 `/next/static/chunks/main.js`로 요청할 파일이


https://cdn.mydomain.com/_next/static/chunks/main.js


이런 식으로 바뀌어서 CDN 서버에서 빠르게 제공되겠죠.

---

### 추가로 알아두면 좋은 점들

- **환경별 분리**: 개발 단계에선 로컬에서 바로 파일을 불러오는 게 편하니까 assetPrefix를 사용하지 않고, 실제 배포 때만 CDN 주소를 사용하도록 phase를 분리하는 게 일반적이에요.
- **CDN 설정**: Next.js 쪽에서 assetPrefix만 설정한다고 CDN이 완성되는 건 아니에요. CDN 제공 업체(Cloudflare, AWS CloudFront 등)에서 원본(origin)을 Next.js가 호스트 중인 도메인(예: 내 서버 도메인)으로 설정해야 합니다. 즉, CDN 주소로 들어온 요청을 실제 Next.js 서버로 전달해주는 역할이 필요해요.
- **_next 폴더 주의**: Next.js가 내부적으로 사용하는 `_next` 경로는 정적 파일 및 페이지 정보를 담고 있어서, assetPrefix 설정 시 해당 경로가 포함되니 CDN에서도 해당 경로들을 캐싱하도록 설정하는 게 좋아요.

---

CDN을 붙여놓으면 사용자의 로드 속도가 확실히 개선되니까 배포할 땐 꼭 한번 시도해보세요! 만약 추가로 리소스 압축이나 캐시 설정 등을 손보고 싶다면, CDN 설정 메뉴에서 조절하면 되고, Next.js에서도 `next.config.js`로 다양한 빌드 옵션을 더 줄 수 있습니다. 앞으로도 여러 팁 공유할게요!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

`table` 태그를 마크다운 형식으로 바꿔서 설명해볼게요.

먼저, CDN에 파일을 업로드할 때 중요한 건 `.next/static/` 폴더 안에 있는 내용만 올려야 한다는 점이에요. 이걸 올릴 때는 URL 경로와 맞춰서 `_next/static/` 형태로 업로드해야 하죠. 다른 `.next/` 폴더 전체를 올리면 서버 쪽 코드나 중요한 설정들이 공개될 수 있으니까 절대 업로드하지 마세요!

요약하자면, 이렇게 생각하면 편해요:

| 할 일                     | 설명                                    |
|--------------------------|---------------------------------------|
| 업로드할 폴더              | `.next/static/` 폴더 안의 파일들만            |
| 업로드 경로               | CDN 상에서 `_next/static/` 경로로 업로드       |
| 업로드하지 말아야 할 것     | `.next/` 폴더 전체 (서버 코드, 설정 등 민감한 내용 포함) |

이 부분은 Next.js 같은 프레임워크를 사용할 때 꼭 주의해야 하는 보안 포인트 중 하나예요. CDN에서 정적 파일만 안전하게 제공하고, 서버 쪽 코드는 절대 노출되지 않게 하는 거죠.

만약 CDN 설정이 처음이라면, 사용하는 CDN 서비스에 따라 조금씩 방법이 다르니 공식 문서나 가이드를 참고하는 게 좋아요. AWS S3, CloudFront, Netlify, Vercel 등 흔히 쓰이는 CDN 서비스들은 각각 업로드 방법과 경로 규칙을 제공하니까요.

추가로, `.next/static/` 폴더는 빌드 시 자동으로 생성되는 정적 자원들이 들어가기 때문에, 빌드(F5)를 할 때마다 최신 버전으로 갱신되는 게 포인트입니다. 따라서 CDN 캐싱 정책도 적절히 설정해줘야 오래된 파일이 서빙되는 걸 방지할 수 있어요!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

assetPrefix 설정은 _next/static 경로에 요청하는 파일들에는 적용되지만, 다음 경로들에는 영향을 주지 않아요:

- public 폴더 내의 파일들; 이 파일들을 CDN으로 제공하고 싶다면, assetPrefix를 사용하는 것만으로는 부족하고 직접 경로 앞에 CDN prefix를 붙여줘야 해요.

조금 더 쉽게 말하자면, Next.js에서 assetPrefix를 설정하면 빌드 후 생성되는 정적 파일들(예: _next/static 안에 있는 JS, CSS 파일)에 대해 해당 prefix가 자동으로 적용돼요. 하지만 public 폴더 안에 넣은 이미지나 favicon 같은 파일들은 assetPrefix 설정과 상관없이 그냥 루트 경로(/)를 기준으로 접근해요. 그래서 public 폴더 자산을 CDN에서 직접 서비스하고 싶다면, 예를 들어 이미지 태그에 `${assetPrefix}/image.png`처럼 prefix를 직접 넣어줘야 한다는 점, 꼭 기억하세요!

이 과정에서 흔히 헷갈리기도 하는데, 실제 배포 환경에서 자주 실수하는 부분이라 꼭 확인하는걸 추천드려요! CDN으로 빠르게 자산을 제공하고 싶다면 public 폴더 자산도 prefix를 잘 적용해주는게 중요하답니다.

Next.js 15에서 assetPrefix 설정하여 CDN 연동하는 방법

# allowedDevOrigins

Next.js는 개발 중에 기본적으로 크로스 도메인 요청(cross-origin requests)을 차단하지 않습니다. 하지만 앞으로 나올 주요 버전에서는 개발 모드에서 내부 자원이나 엔드포인트에 대한 무단 요청을 막기 위해 기본적으로 차단 설정이 될 예정이에요.

그래서 개발 중에 서버가 시작된 호스트 이름(기본값은 localhost)이 아닌 다른 출처(origin)에서도 요청을 허용하고 싶다면, `allowedDevOrigins` 옵션을 활용할 수 있습니다.

### allowedDevOrigins란?

`allowedDevOrigins`는 개발 모드에서 허용할 추가 출처(origin)를 설정하는 옵션이에요. 예를 들어, localhost뿐만 아니라 `local-origin.dev` 같은 다른 도메인에서도 요청을 허용하고 싶다면, `next.config.js` 파일에 아래처럼 설정하면 됩니다:

```js
// next.config.js
module.exports = {
  allowedDevOrigins: ['http://local-origin.dev'],
}
```

이렇게 설정하면 개발 환경에서 `http://local-origin.dev` 도메인도 Next.js 서버에 요청을 보낼 수 있게 됩니다.

---

### 참고로 더 알려드릴게요!

- 이 설정은 오직 **개발 모드**에서만 영향을 미칩니다. 프로덕션에서는 CORS 설정을 별도로 관리하는 게 좋습니다.
- 만약 여러 개의 출처를 허용하고 싶다면 배열 안에 여러 URL을 넣으면 됩니다.

예시:

```js
module.exports = {
  allowedDevOrigins: ['http://local-origin.dev', 'http://another-origin.dev'],
}
```

- 내부 API나 자원에 대해 외부에서 자유롭게 접근하지 못하게 하려면, 개발이 완료된 후엔 이 옵션을 비워 두거나 제거해서 보안을 강화하는 것을 잊지 마세요!

Next.js 계속 발전하는 만큼 이런 보안 설정도 업데이트되고 있으니, 공식 문서나 릴리즈 노트를 자주 확인하는 습관을 들이면 좋아요!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

안녕하세요! 오늘은 Node.js 환경에서 사용되는 설정 예제 하나를 간단히 살펴볼게요.

```js
module.exports = {
  allowedDevOrigins: ['local-origin.dev', '*.local-origin.dev'],
}
```

이 코드는 `module.exports`를 통해 외부에서 사용할 수 있는 설정 객체를 내보내고 있어요. 여기서 `allowedDevOrigins`라는 속성은 개발환경에서 허용되는 출처(origin) 목록을 담고 있죠.

- `'local-origin.dev'`는 정확히 이 도메인에서 오는 요청을 허용한다는 의미고,
- `'*.local-origin.dev'`는 서브도메인 전체를 허용한다는 뜻입니다. 예를 들면, `app.local-origin.dev`, `test.local-origin.dev` 같은 도메인들이죠.

이런 식으로 origin을 명시하면, 보안이나 CORS 설정에서 특정 출처만 허용할 때 매우 유용해요. 다만, 와일드카드(*)를 사용할 때는 보안상 주의가 필요합니다. 개발용이라면 괜찮지만, 프로덕션 환경에서는 허용 범위를 최대한 좁히는 게 좋아요.

> 참고로, Node.js나 JavaScript 환경에서 `module.exports`는 해당 파일의 기능이나 데이터를 다른 파일에서 불러다 쓸 수 있게 해주는 역할을 합니다. 예를 들어, 이 설정을 다른 파일에서 이렇게 불러올 수 있죠:

```js
const config = require('./config');
console.log(config.allowedDevOrigins);
```

마지막으로, 만약 여러 도메인을 관리할 때는 배열로 깔끔하게 관리하는 것도 좋은 팁이에요. 필요하면 정규식이나 다른 로직으로 확장도 가능하고요.

궁금한 점 있으면 언제든지 댓글로 남겨주세요!

Next.js 15에서 allowedDevOrigins 설정하는 방법

# next.config.js 설정하기

Next.js는 프로젝트 최상단(예: package.json이 위치한 같은 폴더)에 `next.config.js` 파일을 만들어 다양한 설정을 할 수 있어요. 이 파일은 기본적으로 `module.exports`로 구성한 객체를 내보내는 형태입니다.

```js
// @ts-check
 
/** @type {import('next').NextConfig} */
const nextConfig = {
  /* 여기에 설정 옵션들을 적어주세요 */
}
 
module.exports = nextConfig
```

이렇게 하면 Next.js가 프로젝트를 빌드하거나 실행할 때 이 설정을 참조하게 되죠.

---

## ECMAScript 모듈 방식으로 작성하기

최근에는 Node.js가 ECMAScript Modules(ESM)을 더 잘 지원하면서, `next.config.js` 파일을 `ESM` 방식으로 작성하고 싶을 때도 있어요. 예를 들어 `export default`를 사용하는 식이죠.

```js
/** @type {import('next').NextConfig} */
const nextConfig = {
  /* 설정 작성 */
}

export default nextConfig
```

단, 이렇게 하려면 `package.json`에 `"type": "module"`을 명시하거나, `next.config.mjs`와 같이 `.mjs` 확장자를 사용해야 해요. 그렇지 않으면 여전히 CommonJS 형식(`module.exports`)을 사용해야 합니다.

### 참고로!  
- 기본적으로 Next.js는 CommonJS 방식을 선호하고, 대부분 예제도 이 방식을 따라요.  
- 만약 ESM 방식으로 작성했다면, Node.js 버전 호환과 프로젝트 설정을 꼼꼼히 확인하는 게 좋아요.  
- 또, 환경 변수 설정이나 커스텀 웹팩 등 고급 설정을 할 때 이 차이가 영향을 줄 수 있으니 주의하세요!

---

`next.config.js`는 Next.js 프로젝트를 내 입맛에 맞게 조정하는 아주 중요한 파일이에요. 설정 가능한 옵션들은 [공식 문서](https://nextjs.org/docs/api-reference/next.config.js/introduction)를 참고하면 더 다양한 기능을 활용할 수 있어요!

필요한 설정을 넣고 내 프로젝트를 더 똑똑하게 만들어봅시다! 🚀


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

next.config.js는 일반적인 Node.js 모듈이지 JSON 파일이 아니에요. 이 파일은 Next.js 서버와 빌드 단계에서 사용되고, 브라우저 빌드에는 포함되지 않아요.

만약 ECMAScript 모듈 방식을 사용하고 싶다면, next.config.mjs 파일을 쓸 수 있는데요, 이렇게 작성하면 됩니다:

```js
// @ts-check

/**
 * @type {import('next').NextConfig}
 */
const nextConfig = {
  /* 여기에 설정 옵션을 넣으면 돼요 */
}

export default nextConfig
```

> 참고로 좋은 정보! 현재 next.config 파일은 .cjs, .cts, .mts 확장자는 지원하지 않으니 꼭 .js 나 .mjs 확장자를 사용해야 해요.

추가로, next.config.js는 서버 사이드에서만 동작하기 때문에 브라우저에 환경 설정이 노출되지 않는다는 점이 큰 장점이에요. 그래서 보안에 민감한 설정이나 API 키 같은 걸 넣어도 안전하게 사용할 수 있답니다.


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

## 함수 형태로 설정하기

Next.js 설정을 할 때, 단순히 객체를 내보내는 것 말고도 함수를 사용해서 설정할 수 있어요. 이렇게 하면 환경에 따라 동적으로 설정값을 다르게 줄 수 있어서 유용하답니다.

```js
// @ts-check

export default (phase, { defaultConfig }) => {
  /**
   * @type {import('next').NextConfig}
   */
  const nextConfig = {
    /* 여기에 설정 옵션 작성 */
  }
  return nextConfig
}
```

예를 들어, 빌드 시점(phase)에 따라 다른 옵션을 주거나, 기본 설정(defaultConfig)을 참고할 수도 있어요.

### 비동기 설정도 가능해요!

여기까지 보면 그냥 동기 함수 같지만, async 함수로 만들 수도 있어요. 예를 들어 외부 API에서 설정 정보를 받아 와야 한다면, async/await를 이용해서 처리할 수 있답니다.

```js
export default async (phase, { defaultConfig }) => {
  // 예: 외부 API에서 설정 가져오기
  const externalSettings = await fetchSomeSettings()

  return {
    ...defaultConfig,
    ...externalSettings,
  }
}
```

이렇게 하면 설정 값도 API 호출 결과에 따라 유연하게 바꿀 수 있으니, 복잡한 환경에서도 활용하기 딱 좋겠죠?

---

다만, async 설정을 쓸 때는 빌드 시간에 네트워크 요청이 포함되니까 빌드 속도가 느려질 수 있어요. 꼭 필요한 경우에만 사용하는 게 좋아요!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

Next.js 12.1.0 버전부터는 async 함수를 사용해서 설정 파일을 작성할 수 있어요. 예를 들어:

```js
// @ts-check

module.exports = async (phase, { defaultConfig }) => {
  /**
   * @type {import('next').NextConfig}
   */
  const nextConfig = {
    /* 여기에 설정 옵션을 작성하세요 */
  }
  return nextConfig
}
```

여기서 `phase`는 현재 설정이 로드되는 상황(컨텍스트)을 의미해요. 어떤 상황에서 설정이 호출되는지 구분해서 설정을 다르게 할 수 있죠. Next.js에서는 여러 가지 phase를 제공합니다.

그리고 이런 phase 값들은 `next/constants` 모듈에서 가져올 수 있어요. 예를 들어 이렇게요:

```js
const { PHASE_DEVELOPMENT_SERVER, PHASE_PRODUCTION_BUILD } = require('next/constants')
```

이걸 활용하면 특정 상황에서만 설정을 다르게 하거나, 개발 모드와 프로덕션 모드에 맞는 설정을 분리할 수 있답니다.

### Phase 종류 예시

| 상수                          | 의미                                   |
|----------------------------|--------------------------------------|
| `PHASE_DEVELOPMENT_SERVER` | 개발 서버 실행 시                       |
| `PHASE_PRODUCTION_BUILD`    | 프로덕션 빌드 시                      |
| `PHASE_PRODUCTION_SERVER`   | 프로덕션 서버 실행 시                 |
| `PHASE_EXPORT`              | 정적 HTML Export 수행 시               |

이렇게 상황에 따라 설정을 구분해놓으면 훨씬 유연하고 관리하기 쉬워져요. 예를들어 개발환경에선 디버깅 옵션을 켜고, 프로덕션에선 최적화 옵션을 켜는 식으로 말이죠.

만약 더 복잡한 설정을 원한다면, async 함수 내에서 API 호출이나 파일 읽기 같은 비동기 작업도 할 수 있어서 설정을 더 동적으로 만들어 줄 수 있어요. Next.js 12.1.0부터 이 기능 덕분에 한층 더 풍부한 설정 구성이 가능해졌답니다!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

자, 오늘은 Next.js 설정 파일을 다루는 방법에 대해서 이야기해볼게요. Next.js를 사용하다 보면 각 환경(development, production 등)에 따라 다르게 설정하고 싶을 때가 있잖아요? 이럴 때 유용한 예제를 하나 가지고 왔어요.

### Next.js 설정 파일 예제 (JavaScript)

```js
// @ts-check

const { PHASE_DEVELOPMENT_SERVER } = require('next/constants')

module.exports = (phase, { defaultConfig }) => {
  if (phase === PHASE_DEVELOPMENT_SERVER) {
    return {
      /* 개발 서버 환경일 때만 적용할 설정을 여기에 작성하세요 */
    }
  }

  return {
    /* 개발 서버가 아닌 모든 환경에서 공통적으로 적용할 설정을 여기에 작성하세요 */
  }
}
```

자, 이 코드는 Next.js의 설정 파일인 `next.config.js`에서 주로 사용됩니다. `phase`라는 매개변수를 받아서 현재 실행 중인 환경을 판단할 수 있어요. 예를 들면, `PHASE_DEVELOPMENT_SERVER`는 로컬 개발 서버를 의미하니까 개발용 설정을 넣고, 그렇지 않은 경우엔 production 등 다른 환경 설정을 넣으면 된답니다.

> 참고로, `defaultConfig` 매개변수에는 Next.js가 기본으로 제공하는 설정 값들이 포함돼 있어 필요할 때 활용할 수 있어요.

---

그리고 요즘은 TypeScript를 많이 쓰니 Next.js 설정에도 TypeScript를 적용할 수 있어요. 그래서 `next.config.ts` 라는 파일을 사용하면 훨씬 더 타입 안정성을 갖추면서 편하게 작업할 수 있죠.

### Next.js 설정 파일 예제 (TypeScript)

```ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  /* 원하는 설정 옵션을 작성하세요 */
}

export default nextConfig
```

여기서 중요한 점은 `NextConfig` 타입을 임포트해서 사용하면, 지원하는 설정 옵션들을 타입으로 미리 확인하고 잘못된 설정을 방지할 수 있다는 점이에요.

---

### 추가 팁!

- `phase`가 다양한 값이 있으니 필요하면 `next/constants`에서 다른 상수들도 확인해보세요. (예: `PHASE_PRODUCTION_BUILD`, `PHASE_EXPORT`)
- 설정이 많아지면 환경 변수도 함께 관리하는 게 좋아요. `.env.local`, `.env.production` 같은 파일을 Next.js가 자동으로 읽어줍니다.
- Next.js 공식 문서에서는 환경에 따라 설정 분리하기 좋은 패턴이 많으니 한번 살펴보시면 좋아요.

혹시 더 궁금한 점 있으면 언제든지 물어봐 주세요! 개발하면서 이런 설정들은 꼭 익혀두면 나중에 디버깅도 수월해지고 프로젝트 관리도 편하답니다.


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

여기 주석 처리된 줄들은 next.config.js에서 허용하는 설정들을 넣을 수 있는 자리예요. 이 설정들은 이 파일에 정의되어 있죠.

하지만, 꼭 모든 설정을 알아야 하는 건 아니에요! 각 설정이 무슨 역할을 하는지를 다 이해할 필요 없이, 필요에 따라 원하는 기능을 이 부분에서 찾아보고 어떻게 하면 되는지 참고하면 돼요.

> 참고로, target Node.js 버전에 지원되지 않는 최신 JavaScript 기능은 사용하지 않는 게 좋아요. next.config.js 파일은 Webpack이나 Babel로 변환되지 않으니까요.

아래 페이지에서 next.config.js로 설정할 수 있는 모든 옵션들을 자세히 확인할 수 있어요:


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

## 단위 테스트 (실험적 기능)

Next.js 15.1부터는 `next/experimental/testing/server` 패키지에 next.config.js 파일을 단위 테스트할 수 있는 유틸리티가 포함되어 있어요.

여기서 `unstable_getResponseFromNextConfig` 함수는 next.config.js에 정의된 headers, redirects, rewrites 함수들을 실제 요청 정보와 함께 실행하고, 라우팅 결과를 담은 `NextResponse` 객체를 돌려줍니다.

> 다만, `unstable_getResponseFromNextConfig` 함수는 next.config.js에 정의된 필드만 고려해서 결과를 반환하기 때문에, 미들웨어(middleware)나 파일 시스템 라우트(filesystem routes)는 반영되지 않아요. 그래서 실제 프로덕션 환경에서의 동작과 테스트 결과가 약간 다를 수 있다는 점 기억하세요.

---

제가 좀 더 덧붙이자면, 앞으로 이런 실험적 기능들이 안정화되면, 별도의 E2E(End-to-End) 테스트 없이도 설정 파일을 좀 더 쉽고 빠르게 검증할 수 있을 것 같아요. 현재는 아직 불안정하니, 중요한 부분은 반드시 프로덕션 환경에서 추가 테스트를 하는 것을 추천합니다!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

이번에 소개할 코드는 Next.js의 실험적 API를 활용해서 리다이렉트 설정을 테스트하는 방법에 관한 예제예요. Next.js 개발할 때 리다이렉트(redirects) 설정 잘 되어 있는지 테스트하고 싶다면 꽤 유용하게 쓸 수 있죠.

```js
import {
  getRedirectUrl,
  unstable_getResponseFromNextConfig,
} from 'next/experimental/testing/server'

const response = await unstable_getResponseFromNextConfig({
  url: 'https://nextjs.org/test',  // 테스트할 URL
  nextConfig: {
    async redirects() {
      return [{ source: '/test', destination: '/test2', permanent: false }]
    },
  },
})

expect(response.status).toEqual(307)  // 임시 리다이렉트인지 확인
expect(getRedirectUrl(response)).toEqual('https://nextjs.org/test2')  // 리다이렉트 목적지 확인
```

### 핵심 포인트
- `unstable_getResponseFromNextConfig`는 Next.js 설정(여기서는 `redirects`)에 따라 주어진 URL에 대한 응답 객체를 생성해줘요.
- `getRedirectUrl`은 응답 헤더 중 리다이렉트 위치(URL)를 쉽게 추출할 수 있게 도와줍니다.
- 여기서는 '/test'가 '/test2'로 임시 리다이렉트(307) 되는지 검사중이에요.

### 참고할 점
- 아직 `unstable_` 접두어가 붙어있으니 API가 안정화되지 않았고, 향후 바뀔 수도 있어요.
- 실제 프로젝트에서는 이런 테스트를 CI 파이프라인에 넣어두면 배포 전에 리다이렉트 설정 및 동작을 자동으로 검증할 수 있어 매우 편리하답니다.

### 마무리
이렇게 Next.js의 내부 설정을 직접 불러와서 테스트할 수 있는 방법이 있어서, 리다이렉트뿐 아니라 다른 설정도 비슷하게 점검할 수 있어요. 실험적인 API지만 앞으로 점점 정식화될 가능성이 크니 주목해 보세요! 

필요하면 `next.config.js` 내 redirects 설정 외에 rewrites, headers 등도 유사하게 검증할 수 있다는 점도 덧붙여 드립니다.

Next.js 15 next.config.js 기본 설정 방법

# userAgent 사용하기

Next.js에서 `userAgent` 헬퍼는 Web Request API를 확장해서, 들어오는 요청(request)에서 유저 에이전트(user agent) 정보를 쉽게 다룰 수 있도록 도와줘요. 예를 들어, 어떤 기기에서 접속했는지(device type)를 파악하는 데 아주 유용하죠.

```js
import { NextRequest, NextResponse, userAgent } from 'next/server'

export function middleware(request: NextRequest) {
  const url = request.nextUrl
  const { device } = userAgent(request)

  // device.type에는 'mobile', 'tablet', 'console', 'smarttv',
  // 'wearable', 'embedded' 또는 'desktop'(undefined일 때) 같은 값이 들어와요.
  const viewport = device.type || 'desktop'

  url.searchParams.set('viewport', viewport)
  return NextResponse.rewrite(url)
}
```

위 코드에서는 미들웨어 안에서 요청 객체 `request`를 이용해 `userAgent(request)`를 호출하고, 그 결과로부터 기기 타입(`device.type`)을 얻고 있어요. 그리고 이 정보를 쿼리 파라미터로 추가해서 나중에 라우팅이나 렌더링 시 조건문으로 활용할 수 있도록 했답니다.

---

## isBot 속성 활용하기

`userAgent` 헬퍼는 단순히 기기 타입뿐 아니라, 방문자가 봇(bot)인지 아닌지도 알려주는 `isBot` 속성도 제공해요. 이걸 활용하면, 봇이 방문할 때 SEO 최적화나 캐싱 전략을 다르게 적용하는 등의 스마트한 대응이 가능하죠.

예시를 들어볼게요:

```js
import { NextRequest, NextResponse, userAgent } from 'next/server'

export function middleware(request: NextRequest) {
  const { isBot } = userAgent(request)

  if (isBot) {
    // 봇 방문자라면, 예를 들어, 캐싱을 더 강하게 적용하거나 
    // 특정 페이지로 리다이렉트 할 수도 있어요.
    console.log('봇 방문 감지됨!')
  }

  return NextResponse.next()
}
```

이처럼 `isBot`은 크롤러나 검색 엔진 봇 감지에 유용하니, SEO를 신경 쓰는 프로젝트라면 꼭 활용해보세요.

---

### 참고: device.type 예상 값 정리

| device.type  | 설명                                      |
|--------------|-------------------------------------------|
| mobile       | 모바일 기기 (스마트폰 등)                 |
| tablet       | 태블릿 기기                              |
| console      | 게임 콘솔                                |
| smarttv      | 스마트 TV                               |
| wearable     | 스마트 워치 같은 웨어러블 디바이스       |
| embedded     | 내장형 디바이스                          |
| undefined    | 데스크탑 브라우저 (특별한 타입 없을 때) |

---

마지막으로, `userAgent` 헬퍼는 사용자 단말 정보 기반 맞춤 UI나 미디어 쿼리 없이 기기 특성 판별이 필요한 상황에서 정말 강력한 도구니까, Next.js 프로젝트를 다룰 때 많이 활용해보면 좋습니다!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

요청이 알려진 봇(bot)인지 여부를 나타내는 불리언 값이 있어요.

## browser

요청에 사용된 브라우저에 대한 정보를 담고 있는 객체입니다.

- name: 브라우저 이름을 나타내는 문자열이에요. 만약 식별이 불가능하면 undefined가 될 수 있습니다.
- version: 브라우저 버전을 나타내는 문자열이며, 역시 알 수 없는 경우엔 undefined가 됩니다.

---

참고로, 클라이언트가 어떤 브라우저를 쓰는지 아는 건 다양한 이유에서 유용해요. 예를 들어, 특정 브라우저에서만 발생하는 버그를 파악하거나, 특정 버전에 맞게 기능을 조정하는 거죠. 

또, 사용자 경험을 개선하기 위해서도 브라우저 정보는 중요해요. 만약 너무 오래된 버전을 쓰는 사용자가 많다면, 최신 기능 지원 여부를 알 수 있으니까요.

Markdown 방식으로 표로 정리해봤어요!

| 속성명   | 설명                                 | 타입        | 비고                |
|---------|------------------------------------|------------|---------------------|
| isBot   | 요청이 알려진 봇인지 여부           | Boolean    | true 또는 false      |
| name    | 브라우저 이름                      | String     | 식별 불가 시 undefined |
| version | 브라우저 버전                      | String     | 식별 불가 시 undefined |

이렇게 정보를 잘 활용하면 API를 더 똑똑하게, 사용자에게 더 친절하게 만들 수 있답니다!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

## device

요청에 사용된 기기에 대한 정보를 담고 있는 객체입니다.

| 속성명  | 설명                                                                                   |
|---------|----------------------------------------------------------------------------------------|
| model   | 기기의 모델명을 나타내는 문자열입니다. 값이 없을 경우 `undefined`일 수 있어요.             |
| type    | 기기 종류를 나타내는 문자열로, `console`, `mobile`, `tablet`, `smarttv`, `wearable`, `embedded` 중 하나거나 `undefined`일 수 있어요. |
| vendor  | 기기 제조사명을 표시하는 문자열입니다. 없으면 `undefined`가 될 수 있어요.                   |

기기 정보를 활용하면 어떤 환경에서 접속했는지 파악하기 쉽기 때문에 UI나 기능을 그에 맞게 최적화하기 좋아요. 예를 들어 스마트 TV와 모바일은 화면 크기 차이가 크니, 그에 맞게 인터페이스를 조절할 수 있겠죠?

## engine

다음은 `engine`에 대한 설명이 필요하다면 언제든 알려주세요! 기본적으로 `engine`은 브라우저나 플랫폼 동작의 핵심적인 렌더링 엔진 정보를 나타내는 경우가 많아요. 웹 개발 시엔 이 정보를 통해 브라우저 호환성을 체크하는 데 유용하죠.


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

브라우저 엔진(engine)에 대한 정보를 담고 있는 객체에 대해 조금 쉽게 설명해볼게요.

### 브라우저 엔진 정보 객체

이 객체는 우리가 사용하는 브라우저가 어떤 엔진을 쓰고 있는지 알려줘요. 엔진이라는 건 쉽게 말해, 웹페이지를 해석하고 화면에 보여주는 소프트웨어 핵심 부분이에요.

- **name**: 이건 엔진의 이름을 문자열로 알려줘요. 예를 들어 Amaya, Blink, EdgeHTML, Gecko, WebKit 등 꽤 다양한 엔진들이 있고, 어떤 브라우저가 어느 엔진을 쓰는지 판단할 수 있죠.
- **version**: 그리고 그 엔진의 버전도 문자열로 알려주고, 가끔은 undefined일 수도 있어요.

브라우저 엔진을 알면, 웹 개발할 때 특정 엔진에서 잘못 표시되거나 동작하는 문제를 잡는데 도움이 돼요. 예를 들면, 구글 크롬은 Blink 엔진, 사파리는 WebKit 엔진을 쓰는 식이에요.

---

### OS (운영체제) 정보 객체

이 객체는 컴퓨터나 모바일 기기에서 어떤 운영체제를 쓰고 있는지 알려줘요. OS 정보는 웹사이트를 최적화하거나, 특정 OS에서만 작동하는 기능을 설정할 때 쓰이죠.

---

표로 정리하면 이렇게 될 거예요.

| 속성    | 설명                                                                                                     |
|---------|--------------------------------------------------------------------------------------------------------|
| name    | 브라우저 엔진 이름 (예: Amaya, Blink, EdgeHTML, Gecko, WebKit 등)                                      |
| version | 엔진 버전 문자열, 없으면 undefined                                                                     |
| os      | 운영체제 정보 객체                                                                                      |

필요하면 OS 정보에 대해서도 더 자세히 다뤄볼게요. 실제로 개발할 때는 userAgent 라이브러리나 플랫폼 감지 API를 통해 이런 정보를 쉽게 얻을 수 있죠.

필요하면 내가 사용해본 라이브러리도 추천해줄게요. 혹시 궁금하면 말해주세요!


<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="ca-pub-4877378276818686"
     data-ad-slot="1549334788"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

자, 오늘은 운영체제(OS)와 CPU에 대한 정보를 담고 있는 데이터 구조에 대해 얘기해볼게요. 개발하면서 시스템 정보를 처리해야 할 때 종종 마주치는 내용인데, 이해하기 쉽게 정리해볼게요.

---

### 운영체제 정보 (OS)

- `name`: 운영체제의 이름을 문자열로 나타내요. 예를 들어, 'Windows', 'Linux', 'macOS' 같은 것들이죠. 만약 정보가 없으면 undefined일 수 있어요.
- `version`: 운영체제의 버전을 문자열로 나타내요. 예를 들어 '10.0.19042' 같은 숫자나 'Big Sur'처럼 이름 형태가 될 수도 있죠. 역시 없으면 undefined일 수도 있어요.

이렇게 이름과 버전을 알면 해당 운영체제에 맞는 분기 처리를 하거나 업데이트 정보를 관리하는 데 유용하죠.

---

### CPU 정보

CPU 정보는 보통 CPU 아키텍처 *architecture*에 초점을 맞춥니다. 

| 필드          | 설명                                   | 예시                                                   |
|--------------|--------------------------------------|--------------------------------------------------------|
| architecture | CPU 아키텍처를 나타내는 문자열입니다. | 68k, amd64, arm, arm64, armhf, avr, ia32, ia64, mips 등 |

여기서 가능한 아키텍처 값들은 꽤 다양합니다. 흔히 개발할 때 많이 듣는 건 `amd64` (x86-64), `arm64` (애플 M1/M2, 최신 모바일 기기), `ia32` (x86 32비트), 그리고 `arm` (주로 모바일용) 정도가 있죠.

---

#### 추가 팁!

- CPU 아키텍처와 OS 정보를 함께 알면, 예를 들어 어느 환경에서 특정 바이너리가 돌아가는지 정확히 파악할 수 있어요.
- 웹 개발할 때도 클라이언트나 서버의 환경을 파악해서 최적화 또는 디버깅하는 데 도움이 됩니다.
- Node.js 환경에서는 `process.arch` (CPU 아키텍처)랑 `process.platform` (운영체제) 같은 내장 변수를 활용해 비슷한 정보를 얻을 수 있어요.

---

필요할 때 이 정보를 잘 활용해서 더 똑똑한 환경별 로직을 작성해 보세요. 그럼 오늘 내용은 여기까지!

Posts