# htmlLimitedBots 옵션 알아보기

안녕하세요! 오늘은 Next.js 설정 중 `htmlLimitedBots`에 대해 쉽고 재밌게 이야기해볼게요. 이 설정은 특정 봇(bots)이나 크롤러(crawlers)에게 ‘스트리밍 메타데이터(streaming metadata)’ 대신 ‘블로킹 메타데이터(blocking metadata)’를 보내고 싶을 때 사용해요.

---

### htmlLimitedBots란?

웹페이지를 로드할 때, 보통 사용자의 브라우저에 최적화된 방식으로 데이터를 보내게 되는데요. 이 중에서 일부 봇이나 크롤러는 스트리밍 방식이 제대로 작동하지 않을 수 있어요. 그래서 이런 봇들에게는 스트리밍 대신 **정적으로 완성된 HTML 메타데이터**를 보내도록 설정할 수 있답니다.

### 사용법

`NextConfig`에서 `htmlLimitedBots` 키에 봇의 유저 에이전트(user agent) 이름들을 '|'(파이프 기호)로 구분해서 적어주세요.

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

const config: NextConfig = {
  htmlLimitedBots: 'MySpecialBot|MyAnotherSpecialBot|SimpleCrawler',
}

export default config
```

위 코드를 보면, `MySpecialBot`, `MyAnotherSpecialBot`, 그리고 `SimpleCrawler` 이 세 가지 유저 에이전트에 대해 차단(블로킹) 메타데이터를 보내도록 설정하는 거예요.

---

### 참고 사항

- 이 옵션을 지정해주지 않으면 Next.js 내부의 기본 봇 리스트가 적용돼요.
- 봇이나 크롤러가 특정 방식의 메타데이터를 필요로 할 때, 이 설정으로 유연하게 대응할 수 있어서 SEO나 크롤링 최적화에 도움을 줍니다.
- 스트리밍 대신 블로킹 메타데이터를 보내는 이유는, 봇들이 스트리밍 데이터를 제대로 처리하지 못할 가능성 때문에 안정적인 크롤링 결과를 보장하기 위해서예요.

---

### 기본 봇 리스트

(여기에 Next.js의 기본값으로 설정된 봇 리스트를 보여주면 좋지만, 공식 문서에서 확인하면 편해요!)

---

### 추가 팁

만약 내가 관리하는 사이트에 너무 많은 봇이 방문해서 스트리밍 처리가 오작동하거나 느려진다면, 여기 추가해서 블로킹 메타데이터로 대응하는 것도 좋은 방법입니다. 그리고 SEO 도구를 이용해 어떤 봇들이 내 사이트에 방문하는지 확인하는 것도 잊지마세요!

---

다음에도 재미있고 유용한 개발 이야기를 들고 올게요! 궁금한 점 있으면 댓글로 알려주세요~ 😊


<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는 기본적으로 제한된 HTML 봇 리스트를 포함하고 있어요.

`htmlLimitedBots` 설정을 직접 지정하면 Next.js의 기본 리스트를 덮어쓰게 되서, 어떤 유저 에이전트가 이 동작을 적용받을지 완전히 제어할 수 있어요. 하지만 이건 고급 설정에 해당되니, 대부분의 경우엔 기본 설정만으로도 충분하답니다.

버전 히스토리도 간단히 살펴볼게요.

| Version | Changes                     |
|---------|-----------------------------|
| 15.2.0  | `htmlLimitedBots` 옵션 도입 | 

참고로, 이런 봇 리스트 제어는 SEO나 크롤링 관련 최적화를 할 때 유용하게 활용할 수 있어요. 필요하지 않으면 그냥 기본값 쓰는 걸 추천합니다!

Nextjs 15 htmlLimitedBots사용 방법



# generateBuildId

Next.js는 `next build`를 할 때 앱 버전을 구분하기 위해 고유한 빌드 ID(build ID)를 자동으로 생성해요. 이 빌드 ID는 여러 컨테이너가 같은 버전의 앱을 실행하도록 보장하는 역할을 하죠.

근데 환경마다(예: 개발, 스테이징, 프로덕션) 빌드를 다시 할 때마다 빌드 ID가 달라지면, 여러 컨테이너에서 같은 버전을 쓰는 게 어렵습니다. 그래서 이럴 땐 `generateBuildId` 함수를 사용해서 의도적으로 **일관된 빌드 ID**를 만들어주면 좋아요.

`next.config.js`에 다음처럼 작성하면, 환경 변수에 담긴 최신 Git 커밋 해시(GIT_HASH)를 빌드 ID로 사용할 수 있어요:

```js
module.exports = {
  generateBuildId: async () => {
    // 최신 git 커밋 해시를 빌드 ID로 사용
    return process.env.GIT_HASH
  },
}
```

### 추가 팁
- Git 해시 말고도 환경 변수, 날짜, 혹은 커스텀한 문자열을 조합해서 빌드 ID를 만들어도 좋아요.
- 이렇게 빌드 ID를 고정하면 CI/CD 파이프라인에서 배포 자동화할 때 같은 버전을 안전하게 여러 서버에 배포 가능하답니다.
- `generateBuildId` 함수는 비동기 함수로도 작성할 수 있어서, 필요하면 API 호출을 해서 받아오는 빌드 ID도 활용할 수 있어요.

Next.js 앱을 여러 환경에 안정적으로 배포할 때 꼭 기억해두세요!

Next.js 15에서 generateBuildId로 빌드 ID 커스텀하는 방법 완벽 가이드



# generateEtags 설정하기

Next.js에서는 기본적으로 모든 페이지에 대해 **etag**를 자동으로 생성해줘요. etag는 브라우저가 이전에 받아온 리소스가 변경되었는지 확인할 때 쓰는 값인데요, 캐시 전략에 따라 이 기능을 끄고 싶을 때가 있어요.

예를 들어, 내가 직접 캐시 정책을 세밀하게 조절하고 싶거나, etag 때문에 캐시가 제대로 동작하지 않는다고 생각될 때 generateEtags 옵션을 꺼주면 돼요.

방법은 아주 간단해요! 프로젝트 루트에 있는 `next.config.js` 파일을 열고, 아래처럼 `generateEtags` 옵션을 `false`로 설정해주면 됩니다.

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

이렇게 하면 Next.js가 페이지를 렌더링할 때 etag를 생성하지 않아서, 캐시 동작을 좀 더 직접 컨트롤할 수 있어요.

---

### 참고로!

- etag를 끄면 클라이언트가 서버에 리소스 변경 여부를 확인하는 요청을 덜 보내게 만들 수 있지만, 캐시가 제대로 동작하지 않을 수도 있으니 신중하게 사용하세요.
- 서버 캐시, CDN 캐시 등을 별도로 활용한다면 etag가 필요 없을 수도 있어요.
- 특히 API 응답에는 etag를 켜놓고, HTML 페이지에는 끄는 식으로 상황에 맞게 설정하면 좋답니다.

혹시 캐시 관련해서 더 궁금한 점 있으면 알려주세요!

Next.js 15에서 generateEtags로 효율적인 캐시 관리 방법

# expireTime 설정하기

이번에는 Next.js에서 ISR(Incremental Static Regeneration) 기능을 사용할 때 CDN이 참고할 수 있도록 Cache-Control 헤더에 `stale-while-revalidate` 만료 시간을 직접 지정하는 방법에 대해 알아볼게요.

### expireTime은 뭐예요?

`expireTime`은 ISR이 작동할 때, CDN이나 브라우저가 캐시된 페이지를 얼마나 오래 '신선한' 상태로 간주할지 초 단위로 지정하는 값이에요. 이 시간이 지나면, 캐시된 페이지는 'stale'(오래된) 상태가 되고, 사용자 요청 시 백엔드에서 페이지를 재생성하면서 동시에 이전 페이지를 제공하게 됩니다. 이렇게 하면 사용자 경험도 부드럽고, 신선한 컨텐츠도 유지할 수 있죠.

### 설정 방법

`next.config.js` 파일에 아래처럼 `expireTime` 옵션을 추가하면 됩니다.

```js
module.exports = {
  // 캐시 유효 시간: 1시간(3600초)
  expireTime: 3600,
}
```

위 예시는 1시간 동안 캐시된 페이지를 신선한 상태로 유지한다는 의미예요. 필요에 따라 이 시간을 더 짧게 설정해 자주 업데이트되는 페이지에는 빠른 갱신을, 변동이 적은 페이지는 좀 더 길게 설정해서 효율적으로 캐시를 활용할 수 있습니다.

---

### 추가 팁!

- `stale-while-revalidate` 전략은 사용자에게 빠른 응답을 주면서도 백그라운드에서 페이지를 재생성하므로, ISR을 적극 활용하는 사이트라면 꼭 캐시 시간도 신경 써주는 게 좋아요.
- CDN마다 이 헤더를 어떻게 해석하는지 조금씩 다를 수 있으니, 사용하는 CDN 문서도 한 번씩 확인해보는 걸 추천합니다.
- `expireTime`을 너무 길게 하면 업데이트가 늦어질 수 있고, 너무 짧으면 오히려 백엔드에 부하가 걸릴 수 있으니 적당한 균형을 찾아보세요.

이제 `expireTime`으로 한층 똑똑하고 빠른 ISR 환경을 만들어 보세요!


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

이번에 Cache-Control 헤더를 보낼 때, 만료 시간이 단순히 고정된 값이 아니라 특정 재검증(revalidate) 기간에 맞춰서 계산된다는 사실을 알려줄게요.

예를 들어, 어떤 경로(path)에 대해 재검증 기간을 15분(900초)으로 설정했고, 만료 시간은 1시간(3600초)으로 정했다면, 생성되는 Cache-Control 헤더는 이렇게 될 거예요:

| 헤더값                  | 설명                                                   |
|-------------------------|--------------------------------------------------------|
| s-maxage=900            | 캐시된 응답을 15분간(900초) 동안 새로 고침 없이 사용   |
| stale-while-revalidate=2700 | 만료 후에도 45분간(3600 - 900 = 2700초) 캐시된 콘텐츠를 '오래된 상태로' 사용하며 백그라운드에서 재검증 수행 |

여기서 중요한 점은 stale-while-revalidate 기간이 만료 시간에서 재검증 시간을 뺀 값이라는 거예요. 즉, 캐시는 만료되기 전 15분 동안은 완벽히 신선한 상태로, 그 이후 45분 동안은 다소 '오래된' 상태로 사용자에게 제공되면서 백그라운드에서 새로운 데이터를 가져와서 캐시를 업데이트하는 방식입니다.

이렇게 하면 사용자 입장에서는 캐시가 만료되자마자 바로 느려지는 게 아니라, 조금은 오래된 데이터로도 빠르게 응답받으면서 동시에 서버에서는 캐시를 새로 고치는 작업을 할 수 있어서 UX가 훨씬 개선돼요.

추가로, Cache-Control 헤더를 제대로 활용하면 CDN이나 프록시 서버에서 캐시 관리가 훨씬 효율적이니 꼭 이 부분을 이해하고 적용해보시길 추천합니다!

Next.js 15에서 expireTime 설정으로 세션 만료 관리하는 방법

# exportPathMap 알아보기

> 참고로 이 기능은 next export에서만 사용 가능하고, 현재는 pages의 getStaticPaths나 app의 generateStaticParams로 대체되어 점점 사용이 줄어드는 추세에요.

exportPathMap은 내보낼 때 요청 경로(request paths)를 페이지(destination)와 매핑해주는 기능입니다. 이걸 설정하면, next export를 할 때 원하는 경로나 이름으로 페이지를 만들 수 있어요. 그리고 exportPathMap에 정의된 경로는 `next dev` 모드에서도 똑같이 사용할 수 있답니다.

그럼 간단한 예제로 시작해볼게요! 다음과 같은 페이지들이 있는 앱에서 커스텀 exportPathMap을 만들어볼 거예요:

---

예를 들어, 다음과 같은 페이지들이 있다고 가정해봐요:

- /about
- /blog/post1
- /blog/post2

이제 exportPathMap을 어떻게 설정해야 할까요?

---

```js
// next.config.js

module.exports = {
  exportPathMap: async function (
    defaultPathMap,
    { dev, dir, outDir, distDir, buildId }
  ) {
    return {
      '/': { page: '/' },
      '/about-us': { page: '/about' }, // 원하는 경로로 매핑 가능
      '/blog/post-1': { page: '/blog/post1' },
      '/blog/post-2': { page: '/blog/post2' },
    }
  },
}
```

---

여기서 `/about-us`가 실제 페이지 경로가 아니라 `/about` 페이지로 이동하게 해주고 있어요. 이렇게 하면 내보낸 정적 사이트에서 URL을 좀 더 커스터마이징할 수 있죠.

---

### 추가로 알려드릴 팁!

- exportPathMap은 페이지가 많거나 동적으로 경로를 여러 개 만들어야 할 때 유용합니다.
- 하지만 Next.js가 공식적으로 권장하는 방식은 `getStaticPaths` 또는 `generateStaticParams`를 활용하는 거예요. 이 함수들은 페이지 내부에서 직접 경로를 정의하고, 자동으로 정적 HTML을 생성해주기 때문에 관리하기 훨씬 편하답니다.
- 앞으로 새 프로젝트라면 exportPathMap보단 `getStaticPaths`(pages 디렉토리)나 `generateStaticParams`(app 디렉토리) 방식을 먼저 고려해보세요!

필요하다면 exportPathMap 활용법이나 위 함수들에 대해 더 자세히 소개해드릴게요. 편하게 질문해주세요!


<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에서 여러 페이지를 정적으로 내보내고 싶을 때 `exportPathMap` 설정을 사용해요. 예를 들어, 다음과 같이 `pages/index.js`, `pages/about.js`, `pages/post.js` 파일이 있다고 가정할게요.

여기서 `next.config.js`에 다음과 같은 `exportPathMap`을 추가하면:

```js
module.exports = {
  exportPathMap: async function (
    defaultPathMap,
    { dev, dir, outDir, distDir, buildId }
  ) {
    return {
      '/': { page: '/' },
      '/about': { page: '/about' },
      '/p/hello-nextjs': { page: '/post', query: { title: 'hello-nextjs' } },
      '/p/learn-nextjs': { page: '/post', query: { title: 'learn-nextjs' } },
      '/p/deploy-nextjs': { page: '/post', query: { title: 'deploy-nextjs' } },
    }
  },
}
```

이 설정은 빌드할 때 `/`, `/about`, `/p/hello-nextjs`, `/p/learn-nextjs`, `/p/deploy-nextjs` 경로들을 각각 대응되는 페이지에 연결해 줘요. 

하지만 여기서 주의할 점이 있어요! `query`를 이용한 파라미터 전달은 `next export` 환경에서는 제한적이에요. 왜냐하면 Next.js에서 자동으로 정적 최적화된 페이지나 `getStaticProps`를 사용하는 페이지들은 HTML로 미리 렌더링되기 때문에, 빌드 후에 쿼리 정보를 추가로 넘길 수 없거든요. 즉, `exportPathMap`에서 `query`를 쓰려면 페이지에서 `getInitialProps`를 사용하고 있어야 합니다.

---

### 추가 팁!

- **동적 라우팅과 정적 내보내기**: Next.js 9 버전부터는 `[param]` 형태의 동적 라우팅 지원과 함께 `getStaticPaths`로 동적 경로를 만들어 낼 수 있어요. 이 방법이 요즘은 더 권장돼서 `exportPathMap` 대신 사용되곤 합니다.
- **`exportPathMap` 사용 예시**: 구버전이나 Next.js의 `next export`를 꼭 써야 하는 경우에 유용해요.
  
---

### 간단 정리

| 설정 항목               | 설명                                                         |
|---------------------|------------------------------------------------------------|
| exportPathMap       | 내보낼 경로와 페이지 매핑을 정의하는 함수                            |
| query               | 각 경로에 전달할 쿼리 파라미터 (※ `getInitialProps`와 함께 사용 가능) |
| 자동 정적 최적화       | `getStaticProps` 등과 함께 빌드 타임에 HTML이 생성되는 방식                |
| 제한 사항             | 자동 정적 최적화 페이지에서 `query` 못 씀                            |

---

이렇게 설정해 두면 정적 사이트 생성 시 원하는 경로가 자동으로 만들어져서, 별도의 서버 없이도 깔끔하게 서비스할 수 있어요. 만약 Next.js로 정적 웹사이트를 만들 예정이라면, `exportPathMap`와 `getStaticProps`/`getStaticPaths` 차이점은 꼭 알아두시는 게 좋아요!


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

페이지들은 HTML 파일로 내보내지게 돼요. 예를 들어, `/about` 페이지는 `/about.html` 파일로 변환되는 식이죠.

여기서 중요한 게 `exportPathMap`이라는 비동기 함수인데요, 이 함수는 두 개의 인자를 받아요. 

- 첫 번째 인자는 `defaultPathMap`으로, Next.js가 기본적으로 사용하는 경로 맵이에요.
- 두 번째 인자는 객체 형태로 전달되는데, 이 안에는 다음과 같은 값들이 들어있답니다:

| 필드명  | 설명                                                                                          |
|---------|---------------------------------------------------------------------------------------------|
| dev     | `exportPathMap`가 개발 모드에서 호출될 때는 `true`, 즉 실제 `next export` 실행 시에는 `false`에요. 개발 모드에선 이 함수로 라우트를 정의해요. |
| dir     | 프로젝트 디렉토리의 절대 경로입니다.                                                         |
| outDir  | `out/` 디렉토리의 절대 경로로, `-o` 옵션으로 설정할 수 있어요. `dev`가 `true`일 땐 `null`이에요.  |
| distDir | `.next/` 디렉토리의 절대 경로로, `distDir` 설정으로 조정 가능해요.                            |
| buildId | 생성된 빌드 아이디입니다.                                                                    |

이 함수가 반환하는 건 페이지들의 맵 객체예요. 여기서 키(key)는 페이지의 경로명(pathname)이고, 값(value)은 객체인데요, 이 객체는 아래와 같은 필드를 받을 수 있답니다:

(아래는 대표적인 필드 예시입니다.)

| 필드명  | 설명                                                       |
|---------|------------------------------------------------------------|
| page    | 렌더링할 실제 페이지 경로, 예를 들어 `/about` 같은 경로명    |
| query   | 라우트에 필요한 쿼리 파라미터들을 객체 형태로 넣을 수 있어요   |

---

**팁 하나!**  
`exportPathMap`을 잘 활용하면 동적 라우트도 정적으로 내보낼 수 있어요. 예를 들어 블로그 글마다 페이지를 만드려면, 동적으로 글 목록을 불러와서 각각 `/posts/post1.html`, `/posts/post2.html` 이런 식으로 경로를 지정해 주는 거죠! 그래서 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>

- page: String - pages 디렉터리 내부에서 렌더링할 페이지입니다.
- query: Object - prerendering 시 getInitialProps에 전달되는 쿼리 객체입니다. 기본값은 ''입니다.

> 내보낸 경로명(pathname)은 파일명(예: /readme.md)도 가능합니다. 하지만 만약 .html과 다른 확장자라면, 콘텐츠를 제공할 때 Content-Type 헤더를 text/html로 설정해줘야 할 수도 있어요.

## 트레일링 슬래시 추가하기

Next.js에서 페이지를 index.html 파일로 내보내고, URL 끝에 슬래시(/)를 붙이도록 설정할 수 있어요. 예를 들어, /about 페이지는 /about/index.html로 내보내지고, 사용자는 /about/ 경로로 접근할 수 있게 됩니다. 이 방법은 Next.js 9 이전 버전의 기본 동작이었답니다.

---

좀 더 설명하자면, 트레일링 슬래시를 사용하는 이유는 SEO 최적화나 서버 설정에 따라 URL 끝에 슬래시를 붙이는 것이 더 깔끔하거나 일관된 주소 체계를 유지하는 데 도움을 준다는 점이에요. Next.js에서 이 옵션을 켜려면 `next.config.js`에서 `trailingSlash: true`를 설정하면 됩니다!

```js
// next.config.js
module.exports = {
  trailingSlash: true,
}
```

이렇게 하면, 모든 경로가 `/about/`처럼 슬래시가 붙은 형태로 자동 리다이렉트되거나 정적 파일이 생성돼서 편리하게 사용할 수 있답니다!


<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에서 trailing slash(끝에 슬래시) 설정하는 법과 출력 디렉토리 바꾸는 방법에 대해 알려드릴게요.

---

### 1. trailing slash 추가하기

보통 URL 끝에 슬래시(/)가 있냐 없냐에 따라 SEO나 서버 설정에서 차이가 나기도 하죠. Next.js에서는 쉽게 설정할 수 있어요.

`next.config.js` 파일을 열고 아래처럼 `trailingSlash` 옵션을 `true`로 설정하면, 모든 페이지의 URL 끝에 자동으로 슬래시가 붙어요.

```js
module.exports = {
  trailingSlash: true,
}
```

이렇게 하면 `/about` 대신 `/about/`처럼 URL이 처리됩니다. 

> 참고로, trailing slash를 사용하는 게 좋은지 아닌지는 프로젝트 상황에 따라 다르니, 팀이나 서버 환경에 맞춰 선택하세요!

---

### 2. 출력 디렉토리(custom output directory) 변경하기

Next.js의 `next export` 명령어를 쓰면 정적 사이트를 만들 수 있는데, 기본 출력 폴더가 `out`이에요. 그런데, 다른 폴더를 쓰고 싶으면 `-o` 옵션을 사용해서 바꿀 수 있답니다.

예를 들어,

```bash
next export -o build
```

이렇게 하면 빌드 결과물이 `build` 폴더에 생성돼요.

---

| 기능                           | 기본 설정    | 변경 방법                              |
|------------------------------|------------|-------------------------------------|
| URL 끝에 trailing slash 추가하기 | 없음          | `next.config.js`에 `trailingSlash: true` 설정 |
| 출력 디렉토리 변경              | `out`       | `next export -o <원하는폴더명>`          |

---

앞으로 정적 사이트나 URL처리가 조금더 헷갈릴 때 참고하시면 좋을 것 같아요! 필요하면 `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 export -o outdir` 명령어는 Next.js에서 정적 사이트를 생성(export)하면서 결과물을 `outdir` 폴더에 저장하는 역할을 해요. 쉽게 말해, Next.js 프로젝트를 정적인 HTML 파일로 뽑아내서 별도의 서버 없이도 웹사이트를 운영할 수 있게 해주는 거죠.

그런데 여기서 경고 메시지가 하나 나왔네요.

> Warning: Using exportPathMap is deprecated and is overridden by getStaticPaths inside pages. We don`t recommend using them together.

이 메시지를 풀어보면, `exportPathMap` 옵션은 이제 구식(deprecated)이 되었고, `pages` 폴더 내에서 사용되는 `getStaticPaths` 함수가 그 역할을 대신한다는 뜻이에요. 그리고 둘을 동시에 사용하는 건 권장되지 않아요.

### 간단 요약

| 용어            | 설명                                                         |
|-----------------|--------------------------------------------------------------|
| `exportPathMap` | 과거에 정적 경로를 직접 정의하기 위해 쓰던 함수인데, 이제 deprecated돼요. |
| `getStaticPaths` | Next.js 9.3부터 도입된 함수로, 다이나믹 라우팅을 위한 경로 생성을 담당해요. |

---

### 왜 `getStaticPaths`를 써야 할까?

`exportPathMap`은 종종 경로를 직접 하드코딩하거나 한 곳에서 한꺼번에 경로를 정의하는 방식이라 유연성이 떨어지고, 최신 Next.js의 기능들과 잘 안 맞아요.

반면, `getStaticPaths`는 페이지별로 경로를 선언할 수 있어서 다이나믹 라우팅과 SSG(Static Site Generation)를 아주 자연스럽게 지원합니다.

---

### 정리하면서 한 가지 팁!

- **새 프로젝트**를 시작하거나 **Next.js 9.3 이상**을 쓴다면, `getStaticPaths`와 `getStaticProps` 조합을 랜딩 페이지나 다이나믹 라우팅 페이지에 적용해보세요.
- 이미 `exportPathMap`으로 작업 중인 프로젝트가 있다면, 점차 `getStaticPaths` 쪽으로 마이그레이션 하는 게 좋습니다.
- 그리고 `next export` 명령을 쓸 때는, `getStaticPaths`로 생성한 경로가 잘 포함되는지 꼭 확인하세요.

---

혹시 더 궁금한 점이 있으면 언제든 물어봐 주세요! Next.js로 멋진 사이트 만드세요 :)

Nextjs 15에서 exportPathMap로 정적 페이지 경로 설정하는 방법

# env 설정하기 (Next.js 9.4 버전 이후)

Next.js 9.4 버전부터는 환경 변수(environment variables)를 다루는 게 훨씬 직관적이고 편리해졌어요. 실제로 프로젝트에 적용해보면 훨씬 깔끔하게 환경 변수를 관리할 수 있답니다. 한번 사용해보세요!

---

### 중요한 점

- 여기서 설정한 환경 변수들은 모두 JavaScript 번들에 포함됩니다.
- `NEXT_PUBLIC_` 접두어(prefix)를 붙이는 건 환경 변수나 `.env` 파일을 통해 지정할 때만 의미가 있어요.
- 즉, next.config.js의 `env` 필드에 설정된 변수들은 모두 클라이언트와 서버 어디서든 접근 가능하니까, 민감한 정보는 넣지 말아야 해요!

---

### 환경 변수 추가하는 방법

`next.config.js` 파일을 열고, `env` 설정을 추가해줍니다.

```js
// next.config.js
module.exports = {
  env: {
    CUSTOM_KEY: 'my-value',
    ANOTHER_KEY: 'another-value',
  },
}
```

위와 같이 설정하면, 앱 전역에서 `process.env.CUSTOM_KEY`나 `process.env.ANOTHER_KEY`로 값을 사용할 수 있어요.

---

### .env 파일과 NEXT_PUBLIC_의 차이점

- `.env` 파일에 `NEXT_PUBLIC_` 접두어가 붙은 변수는 클라이언트에서도 접근 가능해요.
- `next.config.js`에 직접 추가한 `env` 변수들은 처음에 말씀드린 대로, 모두 번들에 포함되어 클라이언트와 서버 모두에서 볼 수 있어요.
- 가급적이면 민감한 정보를 다룰 때는 서버 전용이나 런타임에 주입하는 방식으로 하는 걸 추천합니다.

---

### 여기서 더!

- 개발 시에는 `.env.local` 파일에 환경 변수를 넣고, 빌드 시에만 `next.config.js`에서 값을 덮어쓰는 방식을 많이 씁니다.
- `process.env`를 사용해서 접근할 때, 타입스크립트를 쓴다면 `next-env.d.ts`에서 타입 선언도 해두면 편리하답니다.
- 환경 변수를 바꾸고 나면 서버 재시작이 필요하다는 점 잊지 마세요!

---

어렵지 않으니 한번 적용해보고, 번거로운 환경 변수 관리에서 자유로워져봅시다!


<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.config.js` 파일에 이렇게 작성할 수 있어요:

```js
module.exports = {
  env: {
    customKey: 'my-value',
  },
}
```

그러면 앱 어디에서든 `process.env.customKey`로 값을 가져올 수 있답니다. 예를 들어, 컴포넌트에서 이렇게 사용할 수 있어요:

```js
function Page() {
  return <h1>The value of customKey is: {process.env.customKey}</h1>
}

export default Page
```

Next.js는 빌드 타임에 `process.env.customKey`를 `'my-value'`로 알아서 바꿔주기 때문에 실제 런타임에 특별한 설정 없이도 값을 쓸 수 있어요.

여기서 주의할 점!  

`process.env`를 구조 분해할당(destructuring)으로 쓰는 건 안 돼요. 예를 들어:

```js
const { customKey } = process.env; // 이런 식은 동작하지 않아요!
```

이유는 Next.js가 내부적으로 webpack의 DefinePlugin을 사용해서 환경변수를 빌드 타임에 직접 소스코드에 치환하기 때문인데요, 구조 분해할당을 하면 변수 치환이 제대로 안 되거든요.

---

또 한가지 팁!

- 만약 보안이 필요한 비밀 키(secret key) 같은 값을 환경변수에 넣고 싶다면, `env` 옵션보다 `.env` 파일과 `next.config.js`의 `dotenv` 설정을 이용하는 게 더 안전해요.
- 또한, Next.js 9.4 이상부터는 `.env.local`, `.env.development`, `.env.production` 같은 파일을 통해 환경변수를 관리할 수 있어서 좀 더 편리해졌답니다.

이 외에도 공식 문서에서 [Environment Variables](https://nextjs.org/docs/basic-features/environment-variables)를 참고하면 도움이 많이 될 거예요!


<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
return <h1>The value of customKey is: {process.env.customKey}</h1>
```

이 코드는 실제로 실행될 때 이렇게 바뀌게 됩니다:

```js
return <h1>The value of customKey is: {'my-value'}</h1>
```

여기서 중요한 점은, `process.env.customKey`가 런타임 환경변수에서 읽히는 게 아니라, 빌드 타임에 실제 값이 주입된다는 거예요. 그래서 결국 문자열 `'my-value'`가 JSX에 직접 들어가게 되는 거죠.

추가로, 리액트 같은 프론트엔드 프레임워크에서 환경 변수를 사용할 때는 보통 `.env` 파일에 변수를 선언하고, 변수명 앞에 `REACT_APP_` (또는 사용하는 프레임워크 규칙에 따라) 접두사를 붙여야 잘 인식되는 경우가 많습니다. 예를 들어:


REACT_APP_CUSTOM_KEY=my-value


그리고 코드에서는 이렇게 씁니다:

```js
return <h1>The value of customKey is: {process.env.REACT_APP_CUSTOM_KEY}</h1>
```

환경변수를 이렇게 사용하면, 빌드 시점에 안전하게 값이 들어가고, 코드상에서는 직접 하드코딩하지 않아도 돼서 유지보수도 편리해집니다.

참고로, 환경변수는 보안에 민감할 수 있으니 백엔드에만 필요한 시크릿 값들은 프론트엔드에 노출되지 않도록 주의하는 게 좋습니다!

Next.js 15 환경변수(env) 설정 방법

# ESLint와 Next.js 빌드 오류 해결하기

Next.js 프로젝트에서 ESLint를 사용하고 있다면, **`next build`** 실행 시 ESLint 오류가 있을 경우 프로덕션 빌드가 실패하는 걸 경험해봤을 거예요. 이건 Next.js가 기본으로 빌드 단계에서 ESLint 검사를 해서, 오류가 있으면 빌드를 중단하기 때문이죠.

그런데 가끔은, 빌드가 꼭 성공해야 할 상황에서 ESLint 오류가 있어도 일단 빌드는 통과시키고 싶을 때가 있잖아요? 이럴 땐 Next.js 내장 ESLint 검사 기능을 *완전히 비활성화*할 수 있어요. 다만, 이 방법은 **이미 ESLint를 다른 워크플로우(예: CI, 프리커밋 훅 등)에서 따로 검사하고 있을 때만 권장**됩니다.

## ESLint 검사 비활성화 방법

프로젝트 루트에 있는 `next.config.js` 파일을 열고, 아래와 같이 `eslint.ignoreDuringBuilds` 옵션을 활성화해 주세요:

```js
// next.config.js
module.exports = {
  eslint: {
    ignoreDuringBuilds: true,
  },
};
```

이렇게 하면 빌드할 때 ESLint 오류가 있어도 무시하고 빌드를 계속 진행해줍니다.

---

### 만약 ESLint를 아예 끄고 싶다면?

- `next build`뿐 아니라 개발 중에도 ESLint 경고/오류가 안 뜨게 하고 싶다면, `next.config.js`에서 `eslint` 옵션을 더 강하게 조절해야 합니다.
- 또는 `.eslintrc` 설정 자체를 너무 엄격하지 않게 바꾸는 방법도 있지만, 권장하지 않아요.
- 가능하면 **코드를 깨끗하게 유지하는 것이 장기적으로 개발 생산성에 훨씬 좋으니, ESLint 오류는 최대한 빨리 해결하는 걸 추천**합니다.

---

### 추가 팁!

- CI(Continuous Integration) 환경에서 별도로 ESLint를 돌리고 있다면, Next.js 내장 ESLint를 끄는 것이 더 효율적입니다.
- 프리커밋 훅(`husky` + `lint-staged`)을 사용하면 커밋 전에 ESLint 검사로 코드 질을 확보할 수 있어요.
- 만약 ESLint 오류가 많아서 빌드가 자꾸 실패한다면, 이 옵션을 임시방편으로 켜고 문제를 하나씩 해결해 나가세요!

---

## 요약

| 내용                            | 설명                                              |
|-------------------------------|---------------------------------------------------|
| 기본 동작                      | ESLint 오류 있으면 Next.js 프로덕션 빌드 실패       |
| 빌드 중 ESLint 검사를 무시하려면 | `next.config.js`에 `eslint.ignoreDuringBuilds: true` 설정 |
| 권장 방법                      | 코드 품질을 위해 ESLint 오류는 최대한 빨리 수정      |
| 대안                          | CI나 프리커밋 훅에서 별도로 ESLint 검사 설정         |

---

이렇게 Next.js에서 ESLint 오류 때문에 빌드 실패해서 당황스럽던 분들은, `ignoreDuringBuilds` 옵션을 기억해두시면 꽤 편리할 거예요! 하지만 항상 코드 퀄리티 관리도 잊지 마시고요. Happy coding! 🚀


<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 프로젝트에서 ESLint 설정하는 부분인데요.

```js
module.exports = {
  eslint: {
    // Warning: This allows production builds to successfully complete even if
    // your project has ESLint errors.
    ignoreDuringBuilds: true,
  },
}
```

설명하자면, `ignoreDuringBuilds: true` 옵션은 빌드할 때 ESLint 에러가 있어도 빌드를 멈추지 않고 계속 진행하게 해줍니다. 즉, 코드에 문법적 문제나 스타일 가이드 위반이 있어도 생산용 빌드가 성공하도록 허용하죠.

이게 왜 필요하냐면, 가끔 프로젝트를 배포해야 하는데 ESLint 문제 때문에 빌드가 멈춰버리면 난감할 때가 있어요. 그래서 임시방편으로 이 옵션을 켜두고 빌드 성공을 할 수도 있죠. 하지만 권장하는 방법은 절대 아닙니다!

> 추천 팁!  
> 빌드 성공은 중요하지만 더 중요한 건 코드 품질입니다. 가능하면 `ignoreDuringBuilds`를 `false`로 두고 로컬 환경에서 ESLint를 철저하게 점검하는 게 좋아요. CI(Continuous Integration) 파이프라인에 ESLint 검사를 추가해서 문제 발생시 바로 잡는 습관을 들이길 권해요.

마지막으로 Next.js에서 ESLint 관련 더 자세한 설정이나 자동 수정 기능 같은 것도 있으니 공식 문서도 한번 훑어보세요. 

그럼 오늘도 좋은 코딩 하세요! 🚀

ESLint 8 최신 버전에서 실무에 바로 활용하는 방법

# distDir 설정하기

Next.js 프로젝트를 하다 보면 기본적으로 빌드 결과물이 `.next` 폴더 안에 생성되죠. 근데 가끔은 `.next` 대신 다른 이름의 폴더에 빌드 결과물을 저장하고 싶을 때가 있어요. 예를 들어, `build`라는 이름으로 폴더명을 바꾸고 싶을 때가 그렇답니다.

이럴 때는 `next.config.js` 파일에 `distDir` 설정을 추가하면 돼요.

```js
module.exports = {
  distDir: 'build',
}
```

위처럼 설정하면 빌드할 때 Next.js가 `.next` 대신 `build`라는 폴더를 만들어서 거기에 결과물을 넣어줍니다. 이렇게 하면 배포 스크립트나 CI/CD 환경에서 빌드 디렉토리 이름을 내가 원하는 대로 조정할 수 있어서 편리해요.

추가로, 만약 여러 개의 빌드 디렉토리를 상황에 맞게 쉽게 변경하려면 환경 변수와 연동하는 것도 좋은 방법입니다. 예를 들어 `next.config.js`에서 이렇게 설정할 수도 있죠:

```js
module.exports = {
  distDir: process.env.NEXT_DIST_DIR || '.next',
}
```

그럼 환경 변수 `NEXT_DIST_DIR`에 원하는 디렉토리 이름을 지정하면 그걸로 빌드가 되고, 설정이 없으면 기본 `.next` 폴더를 사용하게 돼요.

참고로, `distDir`을 바꾸면 `.next` 폴더를 참조하는 다른 툴이나 스크립트도 함께 수정해줘야 하니 주의하세요!


<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 build`를 실행하면 Next.js가 기본 `.next` 폴더 대신 `build`라는 폴더를 사용하게 됩니다.

> 여기서 주의할 점! `distDir` 설정은 프로젝트 디렉터리 내에 있어야 해요. 예를 들어 `../build`처럼 프로젝트 밖 경로를 지정하면 안 됩니다.

---

추가로 설명을 조금 더 하자면, `distDir` 옵션은 `next.config.js` 파일에서 설정할 수 있어요. 이 옵션은 빌드 결과물이 저장될 폴더 이름과 위치를 바꾸고 싶을 때 유용하죠.

예를 들어:

```js
// next.config.js
module.exports = {
  distDir: 'build',
};
```

이렇게 하면 `.next`가 아니라 `build`라는 이름의 폴더에 빌드 결과물이 생성됩니다.

왜 이렇게 할까요? 보통 배포 파이프라인이나 특정 프로젝트 구조를 맞출 때 디렉토리 이름을 커스터마이징해야 하는 경우가 있어요. 예를 들어, 기존 프로젝트에 Next.js를 새로 도입하거나, CI/CD 설정과 맞추기 위해서죠.

하지만 프로젝트 밖 경로는 보안 및 관리상 문제로 제한됩니다. 경로가 프로젝트 폴더를 벗어나면 Next.js가 인식하지 못하니 참고하세요!

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

# dynamicIO

dynamicIO 플래그는 Next.js에서 실험적으로 제공되는 기능인데요, App Router에서 데이터 패칭(fetching) 작업을 미리 렌더링(pre-render)에서 제외시키는 역할을 해요. 단, 명시적으로 캐시가 설정된 경우는 예외입니다. 

이 기능이 왜 좋으냐면, 서버 컴포넌트에서 동적인 데이터를 다룰 때 성능 최적화에 도움이 되기 때문이에요. 예를 들어, 앱이 실행 중일 때마다 최신 데이터를 받아와야 하고, 미리 렌더된 캐시에 의존하고 싶지 않을 때 딱 맞습니다.

그러니 dynamicIO를 사용할 때는 보통 use cache와 함께 쓰는 게 좋아요. 기본적으로는 데이터 페칭이 런타임에 일어나도록 하면서, 특정 페이지나 함수, 컴포넌트 단위로 캐시를 적용하고 싶을 때 use cache를 활용하는 식이죠. 이렇게 하면 필요한 부분만 스마트하게 캐싱할 수 있어 성능과 최신 데이터 사이의 균형을 맞출 수 있습니다.

추가로, 아직 experimental(실험적) 상태이니 실제 운영 환경에 도입하기 전에는 충분히 테스트해보고, Next.js의 공식 문서와 업데이트 상황을 계속 체크하는 걸 추천드려요. 개발자 커뮤니티에서도 dynamicIO 관련 경험담이나 팁들이 올라오니 참고해 보시면 큰 도움이 될 거예요.


<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.ts 파일의 `experimental` 섹션에 `dynamicIO` 플래그를 `true`로 설정하면 동적 IO 기능을 활성화할 수 있어요:

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

이렇게 `dynamicIO`를 활성화하면, 여러가지 캐시 관련 함수와 설정을 사용할 수 있게 됩니다.

> 참고로, experimental 옵션은 아직 완전히 안정화된 기능은 아니기 때문에, 실제 프로젝트에 적용할 때는 항상 주의가 필요해요. 특히 프로덕션에 바로 적용하기보다는 테스트 환경에서 충분히 검증해보는 걸 권장합니다.

추가로 dynamicIO는 서버 IO 작업을 더 유연하게 관리할 수 있도록 도와주는데, 이 덕분에 캐시 처리나 데이터 동기화 관련 작업이 훨씬 편리해지는 장점이 있어요. 다음에 실제 예제와 함께 더 자세히 설명해 드릴게요!


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

안녕하세요! 오늘은 웹 개발에서 성능 최적화와 관련해 자주 쓰이는 **캐시(cache)** 기능에 대해 살펴보려고 해요. 특히 자주 사용하는 세 가지 개념, 즉 **`use cache` 디렉티브**, **`cacheLife` 함수**, 그리고 **`cacheTag` 함수**에 대해 쉽게 설명해드릴게요.

---

## 1. `use cache` 디렉티브란?

`use cache`는 React나 Next.js 같은 프레임워크에서 데이터를 가져올 때 캐시를 활용하겠다는 의미예요. 데이터를 한 번 받아오면, 그 결과를 메모리에 저장해 두었다가 같은 요청이 들어오면 저장된 데이터를 바로 반환해서 빠르게 처리할 수 있죠.

이걸 적용하면 서버 사이드 렌더링(SSR)이나 클라이언트 렌더링 시 네트워크 지연 없이 깔끔한 사용자 경험을 만들 수 있답니다.

### 예시

```js
export async function fetchData() {
  'use cache';  // 이 함수에서 캐시 사용 지정
  // 데이터 요청 로직
}
```

⚠️ 단, 캐시는 데이터가 바뀔 가능성이 적거나 실시간 변화가 필요 없는 경우에 쓰는 게 좋아요. 실시간 데이터는 별도의 로직이 필요하겠죠!

---

## 2. `cacheLife` 함수로 캐시 수명 지정하기

캐시는 무조건 오래 유지하는 게 좋은 건 아니에요. 데이터 특성에 맞게 캐시가 살아있는 시간을 정해야 하죠. `cacheLife` 함수는 바로 이 캐시의 **수명(Time-To-Live, TTL)**을 지정해주는 역할을 해요.

예를 들어, 오늘 날씨 같은 정보는 10분 정도만 캐시하고, 그 이후엔 새로 데이터를 받아오길 원할 때 쓰면 편리하답니다.

### 예시

```js
cacheLife(600);  // 캐시 유지 시간을 600초(10분)으로 설정
```

이렇게 하면 10분 동안은 캐시된 데이터를 재사용하고, 그 이후엔 새로운 데이터를 fetch 하도록 하죠.

---

## 3. `cacheTag` 함수로 태그를 달아 캐시 관리 쉽게 하기

`cacheTag`는 캐시에 **태그**를 붙여주는 역할이에요. 태그를 이용하면 특정 그룹의 캐시만 한 번에 지우거나 갱신할 수 있어서 관리가 훨씬 편해지죠. 예를 들어, '공지사항' 태그를 붙여둔 캐시가 있다면 새로운 공지사항이 등록될 때 그 태그가 달린 캐시만 쉽게 삭제할 수 있답니다.

### 예시

```js
cacheTag('news');  // 이 캐시 데이터에 'news' 태그 부여
```

관리자가 태그별로 캐시를 조작하거나, 특정 그룹만 최신 상태로 유지하고 싶을 때 무척 유용해요!

---

## 마무리하면서...

정리하자면,

| 기능          | 역할                        | 장점                                  |
| ------------- | --------------------------- | ------------------------------------ |
| `use cache`   | 데이터 요청 시 캐시 사용 지정 | 네트워크 호출 줄이고 속도 향상       |
| `cacheLife`   | 캐시 데이터 수명 지정        | 데이터 최신성 유지와 효율적 캐시 관리 |
| `cacheTag`    | 캐시에 태그 붙이기           | 태그별 캐시 일괄 제어 가능           |

그리고 참고할 점! 

> **dynamicIO** 같은 동적 데이터 fetching 기법은 오히려 매번 새로운 데이터를 받아오기 때문에 **지연 시간이 늘어날 수 있어요**. 그래서 빠른 응답이 중요한 경우에는 캐시를 활용하는 게 더 좋답니다 😀

---

혹시 더 궁금한 점이나 캐시를 활용해 본 경험이 있다면 댓글로 공유해 주세요! 

내일은 이 내용을 바탕으로 Next.js에서 캐시를 실제로 어떻게 적용하는지도 다뤄볼게요. 그럼 즐거운 개발 시간 되세요! 🚀

nextjs 15에서 데이터 패칭 최적화하는 방법

# crossOrigin

next/script 컴포넌트를 사용해서 생성되는 모든 `script` 태그에 `crossOrigin` 속성을 추가하고, 크로스 오리진 요청을 어떻게 처리할지 설정하고 싶을 때 `crossOrigin` 옵션을 사용하면 돼요.

예를 들어, 이렇게 설정할 수 있어요:

```js
module.exports = {
  crossOrigin: 'anonymous',
}
```

### 이 옵션, 왜 쓸까?

보통 다른 도메인에서 자원을 불러올 때 CORS 정책에 걸리기 쉬운데, 이 속성을 지정하면 브라우저가 스크립트를 어떻게 처리할지 알려주는 거예요. 예컨대, `anonymous`로 설정하면 자격 증명(쿠키, HTTP 인증 등) 없이 요청하게 된다거나 말이죠.

## Options

옵션으로는 주로 다음 값을 쓸 수 있어요:

| 옵션 값   | 설명                                                 |
|----------|------------------------------------------------------|
| `anonymous` | 자격 증명 없이 크로스 오리진 요청을 보냅니다.          |
| `use-credentials` | 쿠키, 인증 토큰 등을 포함한 자격 증명과 함께 요청됩니다. |

사실, `crossOrigin`을 제대로 설정하면, 브라우저 캐싱 전략에도 영향을 미치고 보안상 이점도 얻을 수 있어요. 예를 들어, `anonymous` 속성이 설정된 스크립트는 만약 CORS가 실패하면 로드가 차단되니까, 무분별한 외부 스크립트가 실행되는 걸 막을 수 있죠.

꼭 필요한 경우에만 써보고, 사용 전에 도메인의 CORS 정책도 확인하는 게 좋아요!

더 자세한 내용이나 궁금한 점 있으면 편하게 물어봐 주세요~


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

안녕하세요! 오늘은 웹 개발할 때 이미지나 리소스를 불러올 때 사용하는 `crossOrigin` 속성에 대해 간단하게 알려드릴게요.

`crossOrigin` 속성은 주로 `<img>`, `<script>`, `<link>` 태그 같은 요소에서 외부 리소스를 가져올 때, 브라우저가 CORS(Cross-Origin Resource Sharing) 정책을 어떻게 처리할지 결정해줍니다. 여기에 두 가지 주요 옵션이 있습니다.

| 옵션          | 설명                                       |
| ------------- | ------------------------------------------ |
| `anonymous`   | `crossOrigin="anonymous"` 속성을 추가해요. 서버에 인증 정보(쿠키나 HTTP 인증 정보)를 보내지 않고 리소스를 요청합니다. 대부분의 경우 이 설정을 추천해요. |
| `use-credentials` | `crossOrigin="use-credentials"` 속성을 추가해요. 요청에 인증 정보를 포함시켜서 서버에 보냅니다. 주로 인증된 사용자에게만 보여줘야 하는 리소스를 불러올 때 사용합니다. |

### 잠깐, 왜 `crossOrigin` 설정이 필요하냐고요?

브라우저는 보안을 위해 기본적으로 다른 도메인에서 불러오는 리소스에 제한을 둡니다. 예를 들어, 당신의 웹사이트에서 다른 도메인의 이미지를 불러왔을 때, 그 이미지에 대해 직접적인 접근(예: 캔버스에 그려서 픽셀 정보를 읽는 것)이 제한될 수 있죠. 이때 `crossOrigin` 속성을 설정하면, 서버가 CORS 규칙에 따라 맞게 응답하면 이런 제한을 우회할 수 있습니다.

### 팁!

- `anonymous`를 쓸 때는 서버가 반드시 CORS 헤더를 적절히 설정해줘야 해요 (`Access-Control-Allow-Origin`).
- `use-credentials`를 쓰면 서버가 `Access-Control-Allow-Credentials: true` 헤더를 포함시켜야 하고, `Access-Control-Allow-Origin`은 와일드카드(`*`)가 아니어야 합니다.

요약하면, 평범한 이미지나 스크립트 로딩에는 `anonymous`를 주로 쓰고, 인증이 필요한 리소스에는 `use-credentials`를 써보세요. 이렇게 설정하면 보안도 챙기고, 개발도 한결 수월해질 거예요! 😊

Posts