내가 결국 Serverless + esbuild + Prisma 패키징 악몽을 해결한 방법

발행: (2026년 1월 15일 오후 07:23 GMT+9)
3 min read
원문: Dev.to

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는 설정을 올바른 경로에서 찾을 때만 실행됩니다. 플러그인이 설정을 못 찾으면:

  1. esbuild가 전혀 실행되지 않는다.
  2. Serverless가 원본 소스와 node_modules를 그대로 ZIP한다.
  3. 모든 package.patterns가 “깨진” 것처럼 보이며, 잘못된 파일 구조에 적용된다.
  4. ZIP 크기가 절대 변하지 않는다.

설정 경로를 올바르게 지정하면 전체 패키징 파이프라인이 정상화됩니다.

요점

Serverless 번들이

  • 너무 크다,
  • 제외 규칙을 무시한다,
  • Prisma 엔진, WASM, TypeScript 등을 계속 포함한다,
  • 혹은 어떤 조치를 취해도 변하지 않는다,

먼저 esbuild: 블록이 올바른 위치에 있는지 확인하십시오(custom.esbuild 아래이든 최상위이든). 한 줄만 잘못 배치돼도 전체 패키징 프로세스가 실패할 수 있습니다.

Back to Blog

관련 글

더 보기 »

기술은 구원자가 아니라 촉진자다

왜 사고의 명확성이 사용하는 도구보다 더 중요한가? Technology는 종종 마법 스위치처럼 취급된다—켜기만 하면 모든 것이 개선된다. 새로운 software, ...

에이전틱 코딩에 입문하기

Copilot Agent와의 경험 나는 주로 GitHub Copilot을 사용해 인라인 편집과 PR 리뷰를 수행했으며, 대부분의 사고는 내 머리로 했습니다. 최근 나는 t...