내가 결국 Serverless + esbuild + Prisma 패키징 악몽을 해결한 방법
Source: Dev.to
문제
몇 주 동안 AWS Lambda 번들 크기가 전혀 변하지 않았습니다. package.patterns를 얼마나 추가하거나 제거해도 ZIP 파일에는 다음과 같은 거대한 파일들이 계속 포함되었습니다:
@prisma/engines/**
query_engine_bg.*.wasm-base64.js
*.wasm
typescript/**
prisma/**
패턴 리스트를 비워도:
package:
patterns: []
ZIP 크기는 동일하게 유지되었습니다. 결국 Serverless가 내 설정을 완전히 무시하고 있다는 것이 밝혀졌습니다.
근본 원인: esbuild가 실행되지 않음
verbose 모드로 패키징 명령을 실행해 보니 esbuild 활동이 전혀 나타나지 않았습니다:
npx serverless package --verbose
문제는 esbuild 설정이 잘못된 키 아래에 위치했기 때문이었습니다:
custom:
something:
esbuild:
bundle: true
serverless‑esbuild 플러그인은 설정을 다음 위치 중 하나에서만 읽습니다:
# 옵션 A
custom:
esbuild:
bundle: true
# 옵션 B (새로운 스타일)
esbuild:
bundle: true
해결 방법
esbuild 블록을 올바른 최상위 위치로 옮겼습니다:
esbuild:
bundle: true
minify: true
target: node20
이 변경 후:
- Serverless가 esbuild를 호출하고
.cjs번들을 생성했습니다. package.patterns가 기대대로 ZIP에 영향을 주기 시작했습니다.- 원하지 않는 파일들(WASM, Prisma 엔진, TypeScript)이 제외되었습니다.
- 번들 크기가 예측 가능하고 작아졌습니다.
왜 이런 일이 발생하는가
serverless‑esbuild는 설정을 올바른 경로에서 찾을 때만 실행됩니다. 플러그인이 설정을 못 찾으면:
- esbuild가 전혀 실행되지 않는다.
- Serverless가 원본 소스와
node_modules를 그대로 ZIP한다. - 모든
package.patterns가 “깨진” 것처럼 보이며, 잘못된 파일 구조에 적용된다. - ZIP 크기가 절대 변하지 않는다.
설정 경로를 올바르게 지정하면 전체 패키징 파이프라인이 정상화됩니다.
요점
Serverless 번들이
- 너무 크다,
- 제외 규칙을 무시한다,
- Prisma 엔진, WASM, TypeScript 등을 계속 포함한다,
- 혹은 어떤 조치를 취해도 변하지 않는다,
먼저 esbuild: 블록이 올바른 위치에 있는지 확인하십시오(custom.esbuild 아래이든 최상위이든). 한 줄만 잘못 배치돼도 전체 패키징 프로세스가 실패할 수 있습니다.