← 전체 글로 돌아가기

Next.js

Next.js 프로덕션 소스맵을 공개하지 않도록 빌드 설정을 바꾼 이유

에러 추적에는 필요하지만 브라우저에 원본 코드가 내려가던 소스맵을 다룬 설정 노트입니다.

에러 추적 때문에 무심코 열어 둔 파일

배포 후 브라우저 개발자 도구의 Sources 탭에서 TypeScript 원본과 내부 폴더 구조가 보였다. 원인은 에러 추적 도구에 연결하려고 켜 둔 production source map이었다. 비밀키가 소스에 들어 있지는 않았지만, 내부 API 경로와 주석까지 공개할 이유도 없었다.

소스맵은 디버깅 편의 기능이지 인증 장치가 아니다. 공개 번들에 포함되는지와 추적 서비스로 업로드되는지를 분리해서 보기로 했다.

Next.js 설정에서 공개와 업로드를 나누기

공개 빌드에서는 브라우저용 소스맵을 만들지 않도록 설정했다.

// next.config.js
const nextConfig = {
  productionBrowserSourceMaps: false,
}

module.exports = nextConfig

배포 파이프라인에서는 빌드 산출물을 임시로 저장하고, 추적 서비스의 전용 CLI가 지원하는 방식으로 서버에서만 소스맵을 업로드했다. 토큰은 NEXT_PUBLIC_ 계열이 아닌 CI 비밀 변수로 넣었다.

export ERROR_TRACKING_AUTH_TOKEN="$CI_TOKEN"
npx error-tracker-cli sourcemaps upload .next

서비스마다 명령과 이름은 다르지만, 핵심은 브라우저가 받는 파일과 오류 서비스에만 올릴 파일의 경로를 분리하는 것이다.

확인할 때 파일 이름만 보지 않기

배포 결과를 확인할 때 HTML에서 sourceMappingURL 문자열을 찾고, 정적 파일 목록에 .map이 실제로 응답되는지도 확인했다.

curl -fsS https://example.com/_next/static/chunks/app.js | grep -F 'sourceMappingURL'
curl -o /dev/null -s -w '%{http_code}\n' https://example.com/_next/static/chunks/app.js.map

첫 번째 명령이 아무것도 출력하지 않고 두 번째가 404인지 보는 식이다. 단, CDN이 예전 파일을 제공할 수 있으므로 새 배포의 해시가 포함된 JS 파일로 테스트해야 했다.

선택 기준

  • 프론트 소스맵은 기본적으로 공개하지 않는다.
  • 오류 추적이 필요하면 서버 업로드와 공개 제공을 따로 설정한다.
  • CI 토큰은 클라이언트 번들에 들어가지 않는 이름과 위치를 사용한다.
  • 배포 후 HTML, JS, .map 응답을 직접 확인한다.

디버깅 편의 때문에 공개 범위를 넓히기보다, 필요한 도구에만 원본 정보를 전달하는 편이 관리하기 쉬웠다.