

# poweredByHeader 설정

Next.js를 사용하다 보면, 기본적으로 모든 응답 헤더에 `x-powered-by`라는 헤더가 붙어요. 이 헤더는 "이 사이트가 Next.js로 만들어졌다"는 걸 알려주는데, 보안상 노출을 줄이거나 단순히 이 헤더를 빼고 싶을 때가 있죠.

이럴 때는 `next.config.js` 파일을 열어서 `poweredByHeader` 설정을 꺼주면 돼요.

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

이렇게 하면 서버가 응답할 때 `x-powered-by` 헤더가 더 이상 붙지 않아요.

---

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

- **보안성 강화**  
  노출되는 정보는 최소화하는 게 좋은 보안 습관이에요. `x-powered-by` 헤더를 빼면 해커가 사용하는 도구가 사이트의 기술 스택을 파악하는 걸 조금이나마 어렵게 만들 수 있습니다.

- **SEO나 서비스 성능에는 영향 없음**  
  이 설정은 단지 헤더 노출 여부만 바꾸는 거라 웹사이트 성능이나 검색엔진 최적화(SEO)에 영향은 없어요.

- **Next.js 기본 설정**  
  Next.js는 편의를 위해 기본으로 켜져있지만, 필요에 따라 언제든 끌 수 있으니 맞춤 설정 해주세요.

혹시 더 궁금한 내용이나 Next.js 설정에 대해 알고 싶다면 언제든 질문해주세요!

Next.js 15에서 poweredByHeader 비활성화하는 방법



# onDemandEntries 설정으로 Next.js 개발 서버 메모리 관리하기

Next.js에서 개발할 때 서버가 빌드된 페이지들을 메모리에 얼마나 오래, 몇 개까지 유지할지 제어할 수 있는 옵션이 있다는 걸 아셨나요? 이 옵션이 바로 **onDemandEntries**입니다.

기본값도 있지만, 직접 설정을 바꿔주면 개발환경에서 페이지 리로딩 속도나 메모리 사용량을 조절하는 데 도움이 될 수 있어요.

예를 들어, `next.config.js` 파일에 다음처럼 추가하면 됩니다:

```js
module.exports = {
  onDemandEntries: {
    // 페이지를 메모리에 유지하는 최대 시간 (밀리초 단위)
    maxInactiveAge: 25 * 1000,  // 25초 동안 비활성 페이지 유지
    // 동시에 메모리에 유지할 페이지 수
    pagesBufferLength: 2,
  },
}
```

- **maxInactiveAge**: 개발 서버가 사용하지 않는 페이지를 메모리에 남겨두는 시간이에요. 기본값은 25초 정도입니다. 너무 짧게 하면 자주 페이지를 다시 빌드해서 느릴 수 있고, 너무 길면 메모리 낭비가 발생할 수 있죠.
- **pagesBufferLength**: 서버가 한 번에 메모리에 유지할 페이지 수입니다. 이 숫자를 늘리면 여러 페이지를 빠르게 전환할 때 빌드 시간을 줄일 수 있지만, 메모리도 더 많이 사용해요.

### 참고! onDemandEntries가 어떻게 도움이 될까?

앱 개발 중에 페이지를 자주 수정하거나 이동할 때, 이 옵션을 조절하면 번거로운 리로딩이나 대기 시간을 줄일 수 있어요. 특히 큰 프로젝트에서는 이걸 적절히 설정하면 개발 속도가 확실히 빨라집니다.

### 추가 팁

- 너무 짧거나 너무 길게 설정하지 말고, 본인 프로젝트 상황에 맞게 한번씩 조절해보세요.
- `pagesBufferLength`는 너무 크게 설정하면 메모리 사용량이 커지므로, 적절히 테스트해서 맞추는 게 좋습니다.
- 프로덕션 환경에는 영향을 미치지 않는 설정이니 걱정 없이 개발할 때만 조절하세요!

그럼 오늘도 Next.js 개발 즐겁게 하시길 바랍니다! 😊

Next.js 15 onDemandEntries 사용 방법

# optimizePackageImports

개발하다 보면 어떤 패키지들은 수백 개, 많게는 수천 개의 모듈을 내보내기도 하죠. 이런 경우, 필요하지 않은 모듈들까지 다 불러오면 개발 속도가 느려지고, 최종 빌드 결과물도 커져서 성능에 악영향을 줄 수 있어요.

그래서 Next.js에서는 `experimental.optimizePackageImports`라는 실험적인 기능을 제공하는데요. 여기에 패키지 이름을 등록해두면, 실제로 사용하는 모듈들만 딱 로드해줘서 부담을 확 줄일 수 있어요. 그렇지만, 평소처럼 여러 named export를 한꺼번에 import하는 작성 방식은 그대로 유지할 수 있어서 편리하답니다.

사용법은 아주 간단해요. `next.config.js`에 아래처럼 추가하면 됩니다:

```js
module.exports = {
  experimental: {
    optimizePackageImports: ['package-name'],
  },
}
```

이렇게 하면 `package-name` 내에서 내가 쓰는 부분만 덜 불러오니까, 개발 속도도 더 빠르고 빌드 사이즈도 더 작아질 수 있어요.

---

### 조금 더 추가로!

- 아직 실험적인 기능이라서, 모든 패키지에서 완벽하게 동작하지 않을 수 있으니 주의하세요.
- 보통 대용량 UI 라이브러리(e.g., lodash, moment, antd 등)에서 특히 효과가 좋습니다.
- 추후 정식 기능으로 자리잡으면 더 안정적으로 지원될 가능성이 높으니 깃허브나 공식 문서에서 업데이트를 계속 체크하는 게 좋아요.

복잡한 임포트 덕분에 빌드 시간이 느려지거나, 최종 번들 파일이 너무 커지는 분들에게는 꽤 유용한 옵션이니 꼭 기억해두면 좋아요!


<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>

안녕하세요 여러분! 오늘은 웹 개발할 때 자주 쓰는 라이브러리들 중에서 **기본적으로 최적화가 적용되는 라이브러리들**을 소개해드릴게요. 최적화가 미리 되어있는 라이브러리를 사용하면 번들 사이즈가 줄어들고, 성능도 더 좋아져서 프로젝트에 큰 도움이 된답니다.

아래는 기본적으로 최적화가 되어 있는 라이브러리 목록이에요:

| 라이브러리명                     | 설명 및 특징                                      |
|---------------------------------|------------------------------------------------|
| lucide-react                    | 가벼운 SVG 아이콘 라이브러리                     |
| date-fns                       | 날짜/시간 다루기 편한 함수 모음                   |
| lodash-es                      | 함수형 프로그래밍 기반 유틸리티 라이브러리         |
| ramda                         | 함수형 프로그래밍 도구, 불변성 유지에 도움         |
| antd                          | 기업용 UI 컴포넌트 라이브러리                        |
| react-bootstrap               | Bootstrap을 React 전용으로 재구현한 컴포넌트 모음    |
| ahooks                        | React 훅(Hooks) 유틸리티                            |
| @ant-design/icons             | Ant Design 아이콘 모음                              |
| @headlessui/react            | UI 로직만 제공하고 스타일링은 자유롭게 할 수 있는 컴포넌트 |
| @headlessui-float/react      | Headless UI 기능 중 'float' 관련 컴포넌트            |
| @heroicons/react/20/solid    | 깔끔한 20px 사이즈의 Heroicons 솔리드 버전          |
| @heroicons/react/24/solid    | 깔끔한 24px 사이즈의 Heroicons 솔리드 버전          |
| @heroicons/react/24/outline  | 깔끔한 24px 사이즈의 Heroicons 아웃라인 버전        |
| @visx/visx                   | 데이터 시각화용 React 컴포넌트                        |
| @tremor/react                | 대시보드 UI 컴포넌트 라이브러리                      |
| rxjs                         | 반응형 프로그래밍 라이브러리                          |
| @mui/material                | 머티리얼 UI 핵심 컴포넌트                             |
| @mui/icons-material          | 머티리얼 UI 아이콘 모음                               |
| recharts                     | 그래프 시각화용 React 컴포넌트                         |
| react-use                    | 유용한 React 훅들 모음                               |
| @material-ui/core            | 구버전 머티리얼 UI의 핵심 컴포넌트                     |
| @material-ui/icons           | 구버전 머티리얼 UI 아이콘 모음                         |
| @tabler/icons-react          | SVG 아이콘 라이브러리                                  |
| mui-core                     | MUI의 코어 컴포넌트 패키지                            |
| react-icons/*                | 다양한 아이콘을 쉽게 불러올 수 있는 아이콘 라이브러리     |

---

### 왜 최적화된 라이브러리를 써야 할까?

웹 앱 성능이 점점 중요해지면서, **번들 사이즈 줄이기**와 **필요한 코드만 가져오기(tree-shaking)**가 필수가 되었어요. 만약 최적화가 안 되어있는 라이브러리를 쓰면, 불필요한 코드까지 함께 번들에 포함돼서 로딩 속도가 느려질 수 있어요.

그래서 React 프로젝트에서는 위와 같은 미리 최적화가 잘 된 라이브러리를 많이 추천하죠. 특히 아이콘이나 UI 컴포넌트 같이 많이 쓰이는 라이브러리라면 이런 점이 더 중요해요.

---

### 팁!

- 라이브러리 import할 때 **ES 모듈 방식을 사용하면** 트리쉐이킹에 더 유리해요.
- 같은 종류의 아이콘이라도 `react-icons` 같은 라이브러리는 필요한 아이콘만 골라서 import 할 수 있어서 번들 사이즈 절감에 좋죠.
- MUI 같은 경우도 최신 버전에서는 tree-shaking에 꽤 신경을 많이 쓰고 있으니 최신 버전을 사용하는 걸 추천해요.

---

### 마무리

어떤 라이브러리를 쓰느냐에 따라서 프로젝트 성능이 달라질 수 있으니, 꼭 위 라이브러리들을 참고해서 최적화를 신경써보세요. 😊  
앞으로도 유용한 정보와 꿀팁들 많이 공유할게요!

궁금한 점 있으면 댓글로 남겨주세요~!  
좋은 하루 보내세요!🚀

Next.js 15에서 optimizePackageImports로 불필요한 패키지 자동 최적화하는 방법

# Output

Next.js는 빌드 과정에서 각 페이지와 그 의존성들을 자동으로 추적해서, 프로덕션 버전을 배포하는 데 필요한 파일들만 골라내요.

이 기능 덕분에 배포 크기를 확 줄일 수 있어요. 예전에는 Docker로 배포할 때 `next start`를 실행하려면 패키지 의존성에 포함된 모든 파일을 다 설치해야 했죠. 그런데 Next.js 12부터는 `.next/` 디렉터리 안의 Output File Tracing을 활용해서 꼭 필요한 파일만 포함할 수 있게 되었답니다.

게다가 이 방법은 이제 더 이상 사용하지 않는 `serverless` 타깃을 쓸 필요도 없게 만드는데요, 이 `serverless` 모드는 여러 가지 문제를 일으키기도 하고 불필요한 파일 복제를 만들어내기도 했었거든요.

---

추가로, Output File Tracing이 잘 작동하려면, 여러분이 직접 추가한 네이티브 모듈(native modules)이나 외부 파일들이 제대로 인식되는지 꼭 확인해보세요. 때때로 수동으로 설정을 조금 조정해줘야 할 수도 있거든요. 전체 빌드와 배포 최적화를 목표로 한다면 이 부분도 신경 쓰는 게 좋아요!


<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가 빌드될 때, 내부적으로 **@vercel/nft**라는 도구를 사용해서 코드를 정적으로 분석해요. 여기서 import, require, 그리고 fs(파일 시스템)를 어떻게 쓰는지 살펴보면서, 특정 페이지가 로딩할 수 있는 모든 파일을 미리 파악하죠.

또한, Next.js의 프로덕션 서버도 필요한 파일들을 추적해서 `.next/next-server.js.nft.json`이라는 결과물을 만들어줘요. 이 파일은 실제 운영 환경에서 어떤 파일들이 필요한지 알려주는 중요한 파일이에요.

이렇게 생성된 `.nft.json` 파일들을 활용하려면, 이 JSON 안에 적힌 파일 목록을 읽고, 실제 파일 경로를 기준으로 필요한 파일들을 복사해서 배포할 위치에 넣으면 된답니다.

---

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

- **@vercel/nft**는 Node.js 프로젝트에서 필요한 파일들을 추적하는 데 정말 유용한 도구에요. Next.js 외에도 서버리스 환경에서 최적화된 배포를 할 때도 활용하곤 하죠.
- 이 방식을 이용하면, 불필요한 파일들을 빼고 정말 필요한 파일만 배포할 수 있어서 용량도 줄이고, 보안 측면에서도 이점이 있어요.
- 만약 환경변수에 따라 동적으로 파일을 로딩하는 코드를 쓰면, 그 부분은 정적 분석에서 누락될 수 있으니 주의해야 해요. 그러니 동적 import를 많이 쓴다면 직접 확인해주는 게 좋아요.

간단히 말해서, 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.js에서는 배포할 때 필요한 파일들만 쏙쏙 골라서 복사해주는 'standalone' 폴더를 자동으로 만들어줍니다. 여기에는 프로젝트 파일뿐만 아니라, 꼭 필요한 node_modules 내의 파일들도 포함돼요. 덕분에 용량도 줄고, 배포 속도도 빨라지니 아주 편리하답니다!

이 기능을 사용하려면 `next.config.js` 파일에 아래처럼 설정만 추가해주면 끝!

```js
module.exports = {
  output: 'standalone',
}
```

이렇게 설정하면 Next.js가 빌드할 때 필요한 파일들만 골라서 따로 모아준답니다. 특히 서버리스 함수나 도커 환경처럼 가볍고 독립적인 배포가 필요할 때 정말 유용해요.

**추가 팁!**  
- 만약 직접 추가로 복사해야 할 파일이나 폴더가 있다면, `next.config.js`에서 `webpack` 설정을 활용해 커스터마이징할 수도 있어요.  
- standalone 모드는 기본적으로 빌드된 output을 따로 분리하다 보니, 기존의 `next start` 명령어로도 다루기 쉬워진답니다.

필요한 파일만 추려서 배포하고 싶다면 꼭 한 번 적용해보세요!


<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/standalone`이라는 폴더가 생기는데, 이 폴더는 따로 `node_modules`를 설치하지 않고도 바로 배포할 수 있어요. 즉, 배포 환경을 좀 더 간소화할 수 있는 장점이 있죠.

그리고 `server.js`라는 작은 서버 파일도 함께 만들어지는데, 이 파일은 기존에 `next start`로 서버를 띄우는 대신 사용할 수 있어요. 여기서 중요한 점은, 이 작은 서버는 기본적으로 `public` 폴더나 `.next/static` 폴더를 복사하지 않아요. 보통 정적 파일은 CDN에서 처리하는 게 효율적이기 때문이에요.

하지만 만약 CDN을 사용하지 않고 직접 서버에서 이 정적 파일들도 서비스하고 싶다면, 빌드 후에 아래 명령어로 직접 폴더를 복사해주면 돼요:

```bash
cp -r public .next/standalone/ && cp -r .next/static .next/standalone/.next/
```

복사가 끝나면, `server.js`가 이 경로에 있는 정적 파일들을 자동으로 서빙하게 됩니다.

---

조금 더 덧붙이자면, 단독 배포(standalone deployment)는 서버리스 환경이나 컨테이너 배포 등에서 아주 유용해요. 보통 `node_modules` 폴더 크기가 꽤 되는데, 이걸 제외하고 필요한 코드만 딱 가져가니까 훨씬 가볍고 빠르게 배포할 수 있어요.

또한, CDN을 활용하면 정적 파일 로딩 속도가 더 빨라져서 사용자 경험도 좋아지니까, 가능하면 CDN을 쓰는 방향을 추천해요. 그래도 간단하게 로컬 서버에서 정적 파일도 서비스해보고 싶다면, 위 복사 명령어 기억해두면 되겠죠?

---

필요할 때마다 이렇게 `standalone` 빌드 사용하시고, 배포 환경에 맞게 정적 파일 처리 방법도 유연하게 선택해보세요!


<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>

로컬에서 최소한의 server.js 파일을 실행하고 싶다면, 아래 커맨드를 사용하면 돼요:

```bash
node .next/standalone/server.js
```

> 참고할 점:  
만약 여러분의 프로젝트가 특정 포트나 호스트네임에서 서버를 띄워야 한다면, 실행 전에 환경변수로 PORT나 HOSTNAME을 설정할 수 있어요.  
예를 들어,  
```bash
PORT=8080 HOSTNAME=0.0.0.0 node server.js
```
이렇게 하면 http://0.0.0.0:8080 에서 서버가 실행됩니다.

---

## 주의할 점 (Caveats)

이어서, server.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>

monorepo 환경에서 Next.js의 트레이싱 기능을 사용할 때, 기본적으로 프로젝트 디렉토리가 트레이싱의 기준이 돼요. 예를 들어 `packages/web-app`이라는 패키지를 빌드할 때, `packages/web-app` 폴더만 트레이싱 루트로 잡히고, 그 밖의 파일들은 포함되지 않아요. 만약 이 외부 파일들도 포함시키고 싶다면 `next.config.js`에서 `outputFileTracingRoot`를 설정해주면 됩니다.

```js
module.exports = {
  // monorepo 루트가 현재 디렉토리에서 두 단계 위에 있는 경우
  outputFileTracingRoot: path.join(__dirname, '../../'),
}
```

이렇게 하면 monorepo의 최상위 폴더부터 파일을 추적하기 때문에, 여러 패키지에서 필요한 공통 파일도 문제없이 포함될 수 있어요.

---

근데 가끔 Next.js가 필요한 파일을 빼먹거나, 반대로 필요 없는 파일을 잘못 포함시키는 경우가 있어요. 이럴 때 `outputFileTracingExcludes`와 `outputFileTracingIncludes` 옵션을 활용할 수 있습니다. 

- `outputFileTracingExcludes`: 특정 페이지나 API 라우트에 대해 추가적으로 제외하고 싶은 파일이나 폴더를 지정
- `outputFileTracingIncludes`: 특정 페이지나 API 라우트에 대해 추가로 포함해야 하는 파일이나 폴더를 지정

두 옵션 모두 minimatch glob 형식의 패턴을 받아서 더 세밀하게 조절할 수 있답니다.

```js
module.exports = {
  outputFileTracingExcludes: {
    '/api/hello': ['./un-necessary-folder/**/*'], // '/api/hello' 라우트에 un-necessary-folder 아래 모든 파일 제외
  },
  outputFileTracingIncludes: {
    '/api/another': ['./necessary-folder/**/*'], // '/api/another' 라우트에 necessary-folder 포함
    '/api/login/\\[\\[\\.\\.\\.slug\\]\\]': [
      './node_modules/aws-crt/dist/bin/**/*', // 동적 라우트 '[...slug]'에 node_modules aws-crt 라이브러리 포함
    ],
  },
}
```

---

팁을 하나 더 드리자면, monorepo에서 이렇게 설정을 잘 해두면 빌드할 때 누락된 파일 문제를 방지하고, 불필요한 파일까지 묶이는 걸 막을 수 있어서 배포 용량 최적화에도 큰 도움이 돼요. 꼭 필요하다면 로깅 기능이나 자체 스크립트를 활용해서 다음 빌드에 포함되는 파일들을 점검해보는 것도 좋아요!  

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>

참고: outputFileTracingIncludes/outputFileTracingExcludes의 키는 glob 패턴이라서, 특수 문자는 꼭 이스케이프 처리를 해줘야 해요.

- 현재 Next.js는 생성된 `.nft.json` 파일들을 따로 처리하지 않아요. 이 파일들은 배포 플랫폼(예: Vercel)에서 읽어서, 최소한의 용량으로 배포하기 위해 사용됩니다. 앞으로 출시될 버전에서는 이 `.nft.json` 파일들을 활용하는 새로운 명령어도 계획 중이라고 하네요.

## 실험적인 turbotrace 기능

의존성 추적(tracing)은 복잡한 계산과 분석을 필요로 해서 속도가 느릴 수밖에 없어요. 그래서 저희는 Rust로 turbotrace라는 도구를 만들었는데요, 기존 자바스크립트 구현체보다 훨씬 빠르고 똑똑한 대안이랍니다.

---

여기서 잠깐! glob 패턴을 쓸 때는 `*`, `?`, `[` 같은 특수 문자를 적절히 이스케이프해야 예상치 못한 결과를 막을 수 있어요. 예를 들어, `\*`처럼 백슬래시를 붙여주면 안전합니다.

그리고 turbotrace가 나중에 공식 next.js에 통합되면, 배포 속도도 많이 가뿐해질테니 기대해봐도 좋겠네요! Rust 기반이라 메모리 관리가 더 효율적인 점도 큰 장점입니다.


<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에서 turbotrace 기능을 활성화하려면, `next.config.js` 파일에 아래와 같은 설정을 추가해주면 됩니다:

```js
module.exports = {
  experimental: {
    turbotrace: {
      // turbotrace 로그 레벨을 제어합니다. 기본값은 'error'입니다.
      logLevel:
        | 'bug'
        | 'fatal'
        | 'error'
        | 'warning'
        | 'hint'
        | 'note'
        | 'suggestions'
        | 'info',
      
      // 분석의 상세 내용을 로그에 포함할지 여부 (기본값: false)
      logDetail: false,
      
      // 모든 로그 메시지를 제한 없이 보여줍니다.
      // 기본적으로 turbotrace는 각 카테고리별로 1개의 로그 메시지만 표시합니다.
      logAll: false,
      
      // turbotrace의 컨텍스트 디렉터리를 지정합니다.
      // 컨텍스트 디렉터리 외부의 파일은 추적 대상에서 제외됩니다.
      // `outputFileTracingRoot` 설정과 유사한 역할을 합니다.
      // 만약 `outputFileTracingRoot`와 `contextDirectory`가 모두 설정되어 있으면, `contextDirectory`가 우선됩니다.
      contextDirectory: '',
      
      // 코드 내 `process.cwd()` 표현이 있다면 이것을 turbotrace에 알리기 위한 설정입니다.
      // 예를 들어 `require(process.cwd() + '/package.json')` 같은 경우 올바르게 추적됩니다.
      processCwd: '',
      
      // turbotrace의 최대 메모리 사용량(MB 단위)을 설정합니다. 기본값은 6000MB입니다.
      memoryLimit: 6000,
    },
  },
}
```

---

### turbotrace 기능이 뭐죠?

turbotrace는 Next.js에서 사용되는 파일 의존성 추적 도구에요. 앱 번들링이나 서버리스 배포할 때 어떤 파일들이 실제로 필요한지 스스로 추적해서 정확한 파일만 포함할 수 있게 도와줍니다. 이 덕분에 배포 크기 최적화나 빌드 시간 단축에 효과적이죠.

---

### 몇 가지 팁!

- `logLevel`을 `'info'`나 `'suggestions'`로 높여두면 turbotrace가 어떻게 동작하는지 더 자세한 정보들을 확인할 수 있으니 디버깅할 때 유용해요.
- `contextDirectory`를 프로젝트 루트로 지정하면 외부 라이브러리나 임시 파일 같은 엉뚱한 파일 추적을 줄일 수 있어요.
- 메모리 제한(`memoryLimit`)은 상황에 맞게 조절해보세요. 큰 프로젝트라면 기본 6000MB보다 더 늘려야 문제가 생기지 않을 수 있어요.

---

Next.js를 사용할 때 이런 실험적인 기능들을 직접 써보면서 프로젝트에 맞게 튜닝해보는 것도 재미있는 경험이 될 거예요! 언제든 최신 문서나 커뮤니티 의견도 참고하면서 최적화해보세요 :)

Next.js 15 output 파일이란

# 로깅(logging) 설정하기

## 옵션(Options)

### 정보 가져오기(Fetching)

Next.js를 개발 모드에서 실행할 때, 콘솔에 찍히는 로그의 수준(logging level)과 전체 URL이 출력될지 여부를 설정할 수 있어요.

이 기능을 잘 활용하면 디버깅할 때 필요한 정보만 골라서 볼 수 있어서 개발 생산성이 쑥쑥 올라가죠!

---

추가로 알아두면 좋은 점!

- 로깅 레벨을 너무 자세하게 설정하면 로그가 너무 많아서 오히려 원하는 정보를 찾기 어려울 수 있어요.
- 반대로 너무 적게 설정하면 중요한 디버깅 정보가 누락될 수 있으니 상황에 맞게 조절하는 게 좋아요.
- 전체 URL 출력은 인증 토큰 같은 민감한 정보가 포함될 수 있으니, 실제 서비스 환경에서는 주의를 기울이는 게 좋습니다.

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>

현재 로깅(logging) 기능은 fetch API를 사용한 데이터 가져오기(fetching)에만 적용되고 있어요. 즉, Next.js 내부에서 발생하는 다른 로그들은 아직 이 설정에 포함되지 않습니다.

```js
module.exports = {
  logging: {
    fetches: {
      fullUrl: true,
    },
  },
}
```
위 설정을 추가하면 fetch 요청 시 전체 URL이 로그에 출력돼서, 어느 경로로 데이터를 요청했는지 더 명확하게 알 수 있어요.

그리고 Next.js의 Server Components 기능에서 **HMR(Hot Module Replacement)** 캐시에서 복원된 fetch 요청들은 기본적으로는 로그에 찍히지 않습니다. 만약 이 부분도 로그로 보고 싶다면, 아래처럼 `hmrRefreshes` 옵션을 true로 설정하면 돼요.

```js
module.exports = {
  logging: {
    fetches: {
      hmrRefreshes: true,
    },
  },
}
```

이렇게 하면 코드 변경 시 HMR로 인해 캐시된 fetch 요청들도 모두 로그로 확인할 수 있어서, 개발 중 네트워크 요청의 흐름을 더 잘 파악할 수 있답니다.

---

💡 **추가 팁!**  
- 로그 레벨 관리나 커스텀 로깅을 추가하고 싶으면, Next.js 자체 로깅이 아닌 별도의 로깅 라이브러리(winston, pino, loglevel 등)를 도입하는 것도 좋은 방법이에요.  
- 특히 서버 환경과 클라이언트 환경에서 각각 로그를 구분하는 게 필요할 때 유용하니 참고하세요!  
- 그리고 로그가 너무 많이 찍히면 개발 속도가 느려질 수 있으니, 필요한 부분만 선별적으로 켜는 게 좋아요.

필요한 설정을 통해 fetch 요청에 대해 잘 관찰하면서, 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>

### 들어오는 요청( Incoming Requests ) 로그 관리하기

개발할 때 보통 콘솔 창에서 들어오는 요청들이 쭉 찍히는 걸 보신 적 있죠? 기본 설정은 그렇게 모든 요청을 다 로그로 남기도록 되어 있는데요, 이게 너무 많아서 중요한 로그가 묻히거나 콘솔이 지저분해질 때가 있어요.

그래서 `incomingRequests` 옵션을 활용해서 어떤 요청은 로그에서 아예 빼버릴 수 있습니다. 참고로 이 옵션은 개발 환경에서만 작동하고, 실제 배포된 프로덕션 환경에는 영향이 없으니 걱정 말고 사용하시면 돼요!

간단하게 예를 들어보면:

```js
module.exports = {
  logging: {
    incomingRequests: {
      ignore: [/\api\/v1\/health/],
    },
  },
}
```

위 설정은 API 내 건강 체크용 엔드포인트 `/api/v1/health`에 대한 요청만 콘솔 로그에서 무시하는 거예요. 보통 이런 헬스 체크는 너무 자주 호출되기 때문에 로그에 계속 찍히면 방해가 될 때가 많죠.

그리고 만약 **아예 모든 들어오는 요청 로그를 끄고 싶을 때**는 이렇게 할 수 있어요:

```js
module.exports = {
  logging: {
    incomingRequests: false,
  },
}
```

이렇게 하면 개발 중일 때도 요청 로그가 완전히 안 찍히니, 정말 필요 없을 때 과감히 꺼버리는 것도 방법이에요.

---

> TIP!  
> 로그 정리는 개발 생산성을 크게 높여요. 너무 많은 불필요한 로그로 중요한 오류 메시지를 놓치지 않도록 필요한 것만 남겨두는 습관을 들여보세요~


<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>

JS 설정 파일에서 로그(logging)를 제어하는 방법에 대해 간단하게 정리해볼게요.

---

## 로그 끄기 설정하기

기본적으로 `logging` 옵션을 객체 형태로 설정해서 `incomingRequests` 같은 세부 로그 항목을 조절할 수 있어요. 예를 들어, 들어오는 요청에 대한 로그를 끄고 싶으면 이렇게 설정하죠:

```js
module.exports = {
  logging: {
    incomingRequests: false,
  },
}
```

그런데 만약 개발 환경에서 아예 로그를 전부 끄고 싶다면, `logging`을 `false`로 바꾸면 돼요:

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

이렇게 하면 불필요한 로그가 쏟아지는 걸 막아서 콘솔이 깔끔해지고, 개발할 때 필요한 정보만 집중할 수 있답니다.

---

### 좀 더 알려드리자면

- 로그를 완전히 끄는 것보다 필요한 로그만 필터링해서 사용하는 게 보통 좋아요. 예를 들어 오류 로그만 켜두고, 디버그용 로그는 끄는 식으로요.
- 로그는 개발할 때만 끄고, 배포 환경에서는 문제가 발생할 때 빠르게 원인을 찾을 수 있도록 적절히 켜두는 게 중요합니다.
- 만약 로그가 너무 많아지면, 나중에 로그 분석 도구나 미들웨어를 써서 편리하게 관리해보는 것도 추천해요.

---

아래는 정리한 로그 설정 예시입니다.

| 설정 | 설명                      |
|-------|---------------------------|
| `{ logging: false }` | 모든 로그 끄기            |
| `{ logging: { incomingRequests: false } }` | 들어오는 요청 로그만 끄기 |

이렇게 간단하게 로그를 껐다 켰다 하면서 개발 편의성을 높여보세요!

Nextjs15에서 로깅(logging) 설정하는 방법



# mdxRs

이번 글에서는 Next.js에서 MDX 파일을 컴파일 할 때 사용하는 새로운 러스트(Rust) 기반 컴파일러인 `mdxRs`에 대해 이야기해볼게요.

---

MDX란, 마크다운(Markdown)과 JSX가 합쳐진 형태로, 리액트 컴포넌트를 마크다운 문서에 자연스럽게 섞어서 사용할 수 있게 해줘서 개발자들에게 아주 인기 있는 포맷이에요.

기존 `@next/mdx` 플러그인은 자바스크립트로 작성된 컴파일러를 사용했는데요, 이번에 실험적으로 러스트로 작성된 훨씬 빠른 컴파일러를 지원하는 게 바로 `mdxRs`입니다. 러스트 컴파일러 덕분에 속도가 빨라지고 메모리 사용량도 줄일 수 있어 성능 효율이 좋아졌다는 장점이 있어요.

---

다음은 `mdxRs`를 Next.js 프로젝트에 적용하는 기본 설정입니다:

```js
const withMDX = require('@next/mdx')()

/** @type {import('next').NextConfig} */
const nextConfig = {
  pageExtensions: ['ts', 'tsx', 'mdx'], // mdx 파일도 페이지로 인식하게 합니다.
  experimental: {
    mdxRs: true, // 러스트 기반 MDX 컴파일러 활성화
  },
}

module.exports = withMDX(nextConfig)
```

- `pageExtensions`: 여기서 MDX 확장자를 추가해서 `.mdx` 파일을 라우트 페이지로 사용할 수 있게 해주고요.
- `experimental.mdxRs`: 실험 기능인 러스트 MDX 컴파일러를 활성화합니다. (오늘 기준으로는 실험 단계라 API가 바뀔 가능성도 있으니 참고하세요!)

---

### 참고로, 더 알아두면 좋은 점들

- `mdxRs` 기능은 Next.js의 실험적인 기능에 해당하기 때문에, 버전을 업그레이드 할 때 호환성 문제나 기능 변경이 있을 수 있어요.
- Rust 기반 컴파일러라서 최적화가 잘 되어 있어 특히 대용량 MDX 파일이나 빌드 시간이 긴 프로젝트에서 효과를 더 느낄 수 있습니다.
- 이미 `@next/mdx` 플러그인에 익숙하다면, 특별한 변경 없이 옵션만 켜주면 되니까 도입도 쉽다는 장점이 있습니다.
- 만약 MDX 내부에 복잡한 커스텀 컴포넌트가 많거나, 특별한 Babel/ESLint 설정이 필요하면 `withMDX` 함수 인자로 옵션들을 함께 전달해 더 세밀한 설정이 가능합니다.

---

마지막으로 실험적으로 만나볼 수 있는 이 기능, 직접 적용해보고 빌드 속도나 번들 결과물 차이가 어떤지 체감해 보는 것도 개발자로서 재미있는 경험이 될 거예요!

더 많은 Next.js, MDX 관련 이야기는 앞으로도 공유할게요. 궁금한 점 있으면 댓글로 알려주세요 :)

Nextjs에서 mdxRs 사용하는 방법

# 커스텀 Next.js 캐시 핸들러

Next.js에서 페이지 캐싱과 재검증(Incremental Static Regeneration, ISR)은 같은 캐시를 공유해요. Vercel 같은 플랫폼에 배포하면 이 ISR 캐시는 자동으로 내구성 있는 저장소에 저장되기 때문에 걱정할 필요가 없죠.

그런데 만약 직접 서버를 운영한다면? 이 경우 ISR 캐시는 Next.js 서버의 파일 시스템(디스크)에 저장됩니다. Pages Router와 App Router 모두에서 이 방식이 기본적으로 잘 작동해요.

하지만 만약 캐시를 좀 더 오래 보존하고 싶거나, 여러 컨테이너나 서버 인스턴스 간에 같은 캐시를 공유하고 싶다면? Next.js 캐시 저장 위치를 직접 설정할 수 있습니다. 이렇게 하면 내구성 있는 저장소(예: 네트워크 파일 시스템, 클라우드 스토리지 등)에 캐시를 저장하거나, 여러 서버가 같은 캐시를 함께 사용할 수 있죠.

---

> **TIP!**  
> 직접 캐시 위치를 바꾸는 건 고급 설정이긴 하지만, 대규모 서비스에서는 상당히 유용해요. 예를 들어, 여러 서버가 동시에 캐시를 공유하면 캐시 미스(cache miss)를 줄이고, 전체 앱의 응답 속도를 개선할 수 있거든요.  
>  
> 참고로, 캐시 파일을 저장하는 경로는 Next.js 설정에서 `experimental` 옵션 아래 `cacheHandlerPath`를 지정해 관리할 수 있어요. (`next.config.js`에서 설정 가능)  
>  
> 나중에 여러 서버를 운영하거나 클러스터를 구성할 일이 있다면, 이 부분을 꼭 알아두시면 도움이 됩니다!

---

궁금하면 직접 `next.config.js`에 적용해보면서 전체 작동 흐름을 살펴보는 것도 좋아요. 아래에 간단한 예시를 덧붙일게요!

```js
// next.config.js
module.exports = {
  experimental: {
    cacheHandlerPath: './custom-cache-handler.js',
  },
}
```

이렇게 하면 캐시 저장과 재검증 로직을 직접 커스텀한 파일에서 처리할 수 있어요. 물론, 고급 내용이라 추가 구현이 필요함을 기억하세요!

---

Next.js ISR 캐시 동작에 대해 한 번쯤 정리하면, 배포 환경이나 서버 정책에 따라 적절한 캐시 전략을 세울 때 큰 도움이 될 거예요.  
앞으로 나올 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>

```js
module.exports = {
  cacheHandler: require.resolve('./cache-handler.js'),
  cacheMaxMemorySize: 0, // 기본 메모리 캐싱 비활성화
}
```

위 코드는 커스텀 캐시 핸들러를 적용하는 간단한 예시입니다. 기본적으로 제공되는 메모리 캐시를 끄고, 직접 만든 캐시 핸들러 파일을 사용하도록 설정하죠.

---

## 커스텀 캐시 핸들러란?

보통 캐시는 데이터나 결과를 서버 메모리에 저장해 재사용 속도를 높여주는 역할을 해요. 그런데 기본 캐시 방식이 내 프로젝트에 꼭 맞지 않거나, Redis 같은 외부 캐시 서버를 쓰고 싶을 때가 있죠. 그럴 경우 직접 캐시 저장/조회 로직을 짤 수 있는 커스텀 캐시 핸들러를 만들어서 적용할 수 있어요.

---

## API 참고: 캐시 핸들러에서 구현할 수 있는 메서드들

| 메서드명       | 설명                                                            |
|---------------|-----------------------------------------------------------------|
| get           | 캐시에 저장된 데이터를 불러올 때 호출됩니다.                    |
| set           | 새로운 데이터를 캐시에 저장할 때 사용합니다.                    |
| revalidateTag | 특정 태그와 관련된 캐시를 무효화하거나 갱신할 때 사용됩니다.    |

---

### 조금 더 쉽게 풀어 설명하면...

- `get`은 "어? 내가 저장해 둔 자료 있나?" 하고 찾아보는 함수에요.
- `set`은 "내가 새로 알게 된 정보를 저장해두자!" 하고 기록하는 함수고요.
- `revalidateTag`는 "이 태그가 붙은 모든 캐시, 이제 좀 다시 확인해볼래요?" 라고 해서 부분적인 캐시 무효화를 담당합니다.

---

### 참고

- `cacheMaxMemorySize : 0` 으로 설정하면 Next.js나 다른 프레임워크가 제공하는 기본 메모리 캐시는 비활성화되어서, 완전히 내가 만든 캐시 핸들러만 동작합니다.
- 캐시 핸들러는 비동기 함수일 수 있으니, async/await 문법을 활용해서 외부 저장소(예: Redis, Memcached)와 통신하는 게 일반적이에요.
- 캐시 전략을 잘 짜야 성능과 일관성 모두 잡을 수 있으니, 상황에 맞게 TTL(Time To Live)이나 무효화 전략을 적절히 설정하세요.

---

궁금한 점이나 적용하면서 어려움 있으면 언제든지 댓글로 물어보세요. 직접 써보고 공부하는 것이 가장 빠른 길이니까요!


<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>

### get()

| Parameter | Type   | Description                |
| --------- | ------ | --------------------------|
| `key`     | string | 캐시에 저장된 값의 키입니다. |

이 메서드는 캐시된 값을 반환해줍니다. 만약 해당 키에 맞는 값이 없으면 `null`을 돌려줘요.  
개발할 때 자주 사용하는 캐시 기능인데, 예를 들어 어떤 API 결과를 캐시에 저장해 놓으면 나중에 똑같은 데이터를 다시 받아올 필요 없이 빠르게 꺼내 쓸 수 있죠.

### set()

(다음에 `set()` 메서드에 대해서도 이어서 설명해 드릴게요!)  

---  
참고로 캐시 캐이터를 활용할 때는 저장된 데이터의 라이프사이클, 만료시간 등을 잘 관리하는 게 성능 최적화에 큰 도움이 됩니다. 필요 없는 오래된 데이터가 계속 쌓이면 오히려 성능 저하를 초래할 수 있으니 주의하세요!


<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>

아래는 캐시 관련 함수들의 파라미터와 설명을 정리한 내용이에요. 개발하면서 캐시를 효율적으로 관리하려면 이런 정보들을 잘 이해하는 게 중요하죠!

### setCacheData()

| Parameter | Type | Description |
| --------- | ---- | ----------- |
| `key` | `string` | 데이터를 저장할 때 사용할 키입니다. |
| `data` | 데이터 타입 혹은 `null` | 캐시에 저장할 데이터입니다. |
| `ctx` | `{ tags: [] }` | 캐시 태그들을 지정해주는 영역이에요. 관리 목적이나, 특정 태그를 기준으로 캐시를 무효화할 때 유용합니다. |

이 함수는 데이터를 캐시에 저장하며, `Promise<void>`를 반환해서 비동기 작업임을 알려줍니다.

---

### revalidateTag()

| Parameter | Type | Description |
| --------- | ---- | ----------- |
| `tag` | `string` 또는 `string[]` | 재검증할 캐시 태그들이에요. 배열로 여러 태그를 한 번에 지정할 수도 있고, 단일 문자열로 한 태그를 지정할 수도 있답니다. |

이 함수는 특정 태그에 해당하는 캐시들을 재검증(재갱신)하는 역할을 해요. 캐시 무효화 전략에 있어서 태그 기반 관리는 꽤 강력한 수단이라서 알아두면 좋아요.

---

#### 개인적으로 덧붙이자면…

- 캐시를 태그로 관리하면, 데이터의 특정 변경 사항에 맞춰 관련 데이터만 효율적으로 업데이트할 수 있어요.
- 예를 들어, 블로그 포스트 리스트 페이지와 단일 포스트 페이지가 각각 다른 태그를 갖고 있으면, 특정 포스트가 수정될 때 해당 포스트 태그만 재검증해서 불필요한 전체 캐시 갱신을 줄일 수 있답니다.
- `ctx` 같은 컨텍스트 객체를 활용해 다양한 태그를 잘 관리하는 것도 중요하니, 실제 프로젝트에서 캐시 전략을 짤 때 참고하세요!

필요하면 이 내용을 기반으로 캐시 전략이나 코드를 더 자세히 다뤄볼게요. 언제든 궁금한 점 댓글로 남겨주세요! 😄


<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>

`Promise<void>`를 반환하는 함수에 대해 알아볼게요. 여기서는 주로 데이터 재검증(revalidation)이나 `revalidateTag()` 함수와 관련된 내용이에요.

### 핵심 포인트

- `revalidatePath`는 캐시 태그(cache tags)를 활용하기 위한 편의 함수예요.  
- 이걸 호출하면 내부적으로 `revalidateTag` 함수가 실행되는데, 개발자가 원하는 대로 경로(path)를 기준으로 캐시 키를 태그할 수 있게끔 설계되어 있죠.

즉, `revalidatePath`를 쓰면 경로나 특정 조건에 따라 캐시를 좀 더 세밀하게 관리할 수 있어서, 데이터가 바뀌었을 때 꼭 필요한 부분만 다시 새로고침할 수 있어요.

---

조금 더 쉽게 말하자면, 예전에는 전체 페이지 새로고침이나 데이터 재호출이 번거롭고 비용도 컸는데, 이 기능을 통해 '이 경로에 해당하는 데이터만' 선택적으로 빠르게 다시 불러올 수 있어서 효율성이 훨씬 높아졌다는 얘기죠.

---

## 버전 히스토리(Version History)

아래 표에는 이 기능이 언제 어떤 부분이 업데이트되었는지 간단히 정리해봤어요.

| 버전 | 변경 내용                         |
|------|---------------------------------|
| v1.0 | `revalidatePath` 기능 첫 도입    |
| v1.1 | `revalidateTag` 호출 방식 개선  |
| v1.2 | 캐시 태그 관리 최적화            |

---

혹시 이 부분과 관련해서 더 궁금한 게 있으면 언제든 질문해 주세요! 개발하면서 캐시나 데이터 최신화가 고민인 분들께 정말 좋은 팁이 될 거예요.


<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>

아래는 버전별 주요 변경사항을 정리한 표입니다. 이 표는 개발자들이 버전 업그레이드 시 참고할 수 있도록 쉽게 정리했어요.

| Version   | Changes                                                  |
|-----------|----------------------------------------------------------|
| `v14.1.0` | `cacheHandler`로 이름 변경 및 안정화                       |
| `v13.4.0` | `incrementalCacheHandlerPath`가 `revalidateTag` 지원      |
| `v13.4.0` | `incrementalCacheHandlerPath`가 standalone output 지원    |
| `v12.2.0` | 실험적 기능으로 `incrementalCacheHandlerPath` 추가          |

여기서 `incrementalCacheHandlerPath`는 점진적 캐시 핸들링 기능인데, 최근 버전들에서 점점 더 안정화되고 범용적으로 지원되는 추세입니다. '재검증 태그(revalidateTag)'도 캐시 관리에 큰 도움이 되니, 최신 프로젝트에서는 이 기능들을 적극 활용해 보는 걸 추천해요!

또한, `cacheHandler`가 안정화된 건 중요한 포인트인데요, 이름 변경과 함께 API가 더 견고해졌다는 뜻이니, 사용하는 라이브러리나 프레임워크에서 이 부분을 꼭 최신 상태로 유지하는 게 좋겠죠?

Next.js 15 커스텀 캐시 핸들러 구현 방법

# inlineCss

## 사용 방법

`inlineCss`는 Next.js에서 CSS를 외부 링크(`link` 태그) 대신에 내부 스타일(`style` 태그)로 인라인 처리해주는 실험적 기능이에요. 이걸 켜면, 보통 CSS 파일을 불러올 때 사용하는 `link` 태그 대신 `head` 태그 내에 직접 `style` 태그를 생성해서 CSS를 넣어줍니다.

### 왜 이 기능을 쓸까?

- **초기 렌더링 속도 개선**: 외부에서 CSS 파일을 불러오지 않고 바로 HTML 문서 안에 CSS가 들어가 있어서, 스타일 로딩에 걸리는 시간이 줄어들 수 있어요.
- **더 나은 퍼포먼스**: 네트워크 요청 수가 줄어드니 실제 렌더링 속도가 더 빨라질 가능성이 큽니다.
- **적용법도 간단**해요! next.config.js에 아래처럼 설정만 해주면 끝~

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

const nextConfig: NextConfig = {
  experimental: {
    inlineCss: true,
  },
}

export default nextConfig
```

### 주의할 점!

- 아직 **실험적인 기능**이라서, 프로젝트에 바로 적용하기 전에 꼼꼼히 테스트해보는 걸 추천해요.
- 스타일 규모가 아주 크거나 CSS 파일이 많이 분할된 경우, HTML 문서 크기가 커질 수 있어서 오히려 성능에 악영향을 줄 수도 있어요.
- 자바스크립트 번들 사이즈와 별개로, CSS가 HTML에 포함되므로 SEO 측면에서는 스타일이 빨리 적용되어 긍정적일 수 있습니다.

Next.js에서 이런 기능들이 점점 늘어나면서, 우리는 더 편하게 최적화된 웹사이트를 만들 수 있죠! 혹시 CSS 인라인 처리에 관심 있으면 꼭 한 번 테스트해보세요. 도움이 필요하면 언제든 물어봐 주세요!


<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>

## 장단점 비교: 언제 인라인 CSS를 사용할까?

인라인 CSS를 사용하면 좋은 경우가 몇 가지 있어요. 간단히 정리해볼게요!

| 상황 | 설명 |
|---|---|
| **첫 방문자** | CSS 파일은 렌더링을 차단하는 리소스라서, 외부 CSS를 불러올 때 처음 방문자는 로딩 지연을 겪어요. 이때 CSS를 인라인으로 넣으면 처음부터 스타일이 바로 적용돼서 페이지 로드 속도가 확 좋아집니다. |
| **성능 지표 개선** | 네트워크 요청 횟수를 줄이면 FCP(First Contentful Paint)나 LCP(Largest Contentful Paint)같은 중요한 웹 성능 지표가 대폭 상승하죠. 인라인 CSS가 이 부분에서 효과적입니다. |
| **느린 네트워크 환경** | 와이파이가 약하거나 모바일 데이터 연결이 느릴 때, 네트워크 라운드 트립(왕복시간)이 꽤 크게 느껴져요. 인라인 CSS는 이런 환경에서 성능 향상이 두드러집니다. |
| **아토믹 CSS 번들 (예: Tailwind CSS)** | Tailwind처럼 유틸리티 중심의 CSS 프레임워크는 페이지에 필요한 스타일 양이 디자인 복잡도와 크게 무관해요. 즉, 스타일의 전체 크기가 작고 일정하다는 말인데요, 그래서 인라인으로 넣으면 네트워크 요청도 줄이고 페이로드도 가볍게 유지할 수 있어요! |

---

### 추가로 알아두면 좋은 팁!

- 인라인 CSS는 초반 로딩에 장점이 있지만, 너무 많은 스타일을 인라인으로 넣으면 HTML 파일 크기가 커져서 오히려 로드가 느려질 수 있어요. 적당한 선에서 재사용성이 낮거나 꼭 필요한 스타일만 넣는 게 좋아요.
- 그리고 자주 바뀌는 스타일에는 별도의 CSS 파일을 사용하는 게 캐싱 측면에서 유리합니다. 인라인 스타일은 캐시가 어려워서 매번 새로 받아야 하거든요.
- 결국 사용자 경험과 유지보수 편의성, 성능 지표 사이의 '적절한 균형'을 찾아야 하는 게 관건입니다.

이런 점들 참고해서 프로젝트 상황에 맞게 인라인 CSS를 써보세요! 배운 만큼 웹 페이지가 확실히 빨라지고 사용자 만족도도 올라갈 거예요.


<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>

### 언제 인라인 CSS를 피해야 할까?

인라인 CSS는 성능 향상에 꽤 도움이 되지만, 상황에 따라선 꼭 좋은 선택이 아닐 수 있어요. 어떤 경우인지 한번 살펴볼게요.

| 상황 | 이유 및 설명 |
|-------|-------------|
| **큰 CSS 번들** | CSS 파일이 너무 크면, 인라인으로 모두 넣을 경우 HTML 파일 크기가 크게 늘어나요. 그러면 초기 응답 시간(Time to First Byte, TTFB)이 느려지고, 인터넷 속도가 느린 사용자에겐 오히려 성능 저하로 이어질 수 있어요. |
| **동적 혹은 페이지별 CSS** | 페이지마다 스타일이 많이 달라지고, CSS가 동적으로 변하는 경우 인라인 CSS가 중복되고 과도하게 커질 수 있어요. 이렇게 되면 관리도 어렵고, 전반적인 로딩 효율도 떨어져요. |
| **브라우저 캐싱 활용 시** | 다시 방문하는 사용자가 많을 땐 외부 CSS 파일이 유리해요. 브라우저가 파일을 캐시해서 재접속 때 파일을 다시 다운로드하지 않아도 되니까 데이터 절약도 되고 빠르죠. 인라인은 이 캐싱 이점을 포기하는 셈이에요. |

---

내 개인적인 팁을 하나 덧붙이면, 단순히 인라인 CSS냐 아니냐로만 고민하기보단, 중요한 부분(Critical CSS)만 인라인 하고 나머지는 외부 stylesheet로 분리하는 ‘하이브리드’ 전략을 쓰면 좋아요. 이렇게 하면 첫 화면 렌더링 속도를 잡으면서도 캐싱의 장점도 누릴 수 있거든요.

여러분이 만드는 사이트나 앱의 특성에 맞게, 이런 장단점을 꼼꼼히 따져보시면서 유연하게 적용해 보세요!


<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>

> 참고할 점:
이 기능은 현재 실험 단계이며 몇 가지 알려진 제한 사항이 있어요:
- CSS 인라인 처리는 전역적으로 적용되며, 개별 페이지별 설정은 불가능해요.
- 초기 페이지 로드 시 스타일이 두 번 중복돼요. 한 번은 SSR용 `style` 태그 안에, 또 한 번은 RSC 페이로드 안에 포함돼요.
- 정적으로 렌더링된 페이지로 이동할 때는 중복을 피하기 위해 인라인 CSS 대신 `link` 태그를 사용해요.
- 이 기능은 개발 모드에서는 사용할 수 없고, 프로덕션 빌드에서만 작동해요.

---

조금 더 풀어서 설명해볼게요. 이 기능은 웹사이트의 성능 최적화를 위해 CSS를 HTML 내부에 직접 넣는 방식(인라인 CSS)을 사용해요. 인라인 CSS는 초기 로딩 속도를 높여주고, 스타일이 빠르게 적용되는 장점이 있죠. 다만 아직 실험적인 기능이라서, 스타일 중복 문제나 상황에 따라 인라인 대신 외부 링크를 사용하는 식으로 처리하는 등 몇 가지 제한이 있어요.

개발할 때는 이 기능을 동작시키기 힘드니, 실제 프로덕션 환경에서만 효과를 확인하는 게 좋아요. 앞으로 개선되면서 더 유연한 설정이 가능해지길 기대해봅니다.

Next.js 15에서 Inline CSS 작성하는 방법



# httpAgentOptions 설정하기

안녕하세요! 오늘은 Next.js에서 `httpAgentOptions` 옵션을 활용해 서버 사이드에서 `fetch()` 호출 시 HTTP Keep-Alive를 제어하는 방법에 대해 이야기해볼게요.

## 왜 이 설정이 필요할까?

Node.js 18 버전 이전에서는 Next.js가 내부적으로 `fetch()` 함수를 사용할 때 `undici` 라이브러리를 통해 자동으로 polyfill(대체)해주는데요, 이 과정에서 기본적으로 HTTP Keep-Alive 설정이 켜져 있습니다. Keep-Alive는 같은 서버로 여러 요청을 보낼 때 TCP 연결을 유지해서 성능을 높여주지만, 특정 상황에서는 연결을 계속 유지하는 게 오히려 문제가 될 수도 있어요.

예를 들어, 짧게 끊는 요청이 많거나 프록시 서버를 사용 중이라면 Keep-Alive를 꺼서 연결이 오래 유지되는 걸 방지하는 게 유리할 수 있어요.

## Next.js에서 HTTP Keep-Alive 끄는 방법

`next.config.js` 파일에 간단히 다음과 같은 옵션을 추가하면, 서버 쪽에서 호출하는 모든 `fetch()`에 대해 Keep-Alive를 끌 수 있습니다:

```js
module.exports = {
  httpAgentOptions: {
    keepAlive: false,
  },
}
```

이걸 넣으면 Next.js가 내부에서 사용하는 HTTP 에이전트에 `keepAlive: false`가 적용돼서, 연결이 요청마다 끊기게 돼요.

## 참고로 알아두면 좋은 점!

- 이 설정은 서버사이드에서만 적용되는 점, 클라이언트 사이드 `fetch()`에는 영향을 미치지 않는 점 기억하세요.
- Node.js 18 이상에서는 기본적으로 글로벌 `fetch`가 내장되어 있고, Next.js에서도 undici보다 내장 fetch를 사용할 수 있기 때문에 이 설정이 영향을 미치지 않을 수 있습니다.
- 개발 환경이나 서버 환경에 따라 Keep-Alive 연결 유지 여부에 따라 성능이나 네트워크 자원 활용도가 달라지기 때문에, 꼭 상황에 맞게 설정해주시면 좋아요!

이렇게 간단히 `httpAgentOptions`를 활용해서 서버 fetch의 동작을 제어할 수 있으니, 참고해보시고 꼭 필요한 경우에 맞춰 설정해보세요. 오늘도 좋은 개발 하세요! 🚀

Posts