Next.js에서 패키지 import를 최적화한 방법

Next.js에서 barrel 파일(단일 진입점에서 수천 개의 모듈을 re-export하는 파일)이 개발 서버 부팅 시간과 서버리스 콜드 스타트에 미치는 성능 문제를 해결한 과정을 다룬다. tree-shaking이 왜 이 문제를 해결하지 못하는지, 그리고 Next.js 13.5에서 도입된 optimizePackageImports가 어떻게 200~800ms 이상의 지연을 제거하는지 설명한다.

핵심 포인트

아이콘/컴포넌트 라이브러리의 barrel 파일은 최대 10,000개의 re-export를 담아, 단 하나의 컴포넌트를 import해도 JavaScript 런타임이 불필요한 의존성을 모두 로드한다.
tree-shaking은 번들러 레벨 최적화로, 외부 의존성 내부는 처리할 수 없어 이 문제를 해결하지 못한다.
1차 해결책 modularizeImports는 barrel import를 직접 경로로 변환하지만 각 라이브러리마다 수동 설정이 필요했다.
최종 해결책 optimizePackageImports(Next.js 13.5~)는 barrel 파일을 자동 분석해 수동 설정 없이 동작한다.
로컬 개발 부팅 15~70% 단축(@material-ui/icons: 10.2s에서 2.9s), 프로덕션 빌드 28% 단축, 서버리스 콜드 스타트 40% 개선.

상세 정리

문제의 본질: import { icon } from 'library' 로 가져올 때, JavaScript 런타임은 barrel 파일의 10,000개 모듈을 모두 평가한다. 개발자는 하나만 쓰지만 런타임은 전체를 로드한다.
tree-shaking이 안 되는 이유: tree-shaking은 번들러가 코드를 직접 처리할 때 작동한다. 라이브러리를 external로 설정하면 번들러가 내부를 최적화할 수 없고, 번들링하면 모듈 그래프 분석으로 빌드 시간이 급증한다.
1차 시도 (modularizeImports): import A from 'lib'를 import A from 'lib/A'로 컴파일러 수준에서 변환한다. 효과는 있지만 npm의 수백만 패키지마다 내부 구조를 수동으로 설정해야 했다.
최종 해결 (optimizePackageImports): 번들러가 barrel 파일을 자동으로 단일 패스 스캔해 import 맵을 생성한다. 중첩 barrel과 wildcard export도 처리한다. lucide-react, @headlessui/react 등 인기 라이브러리가 기본 설정으로 제공된다.
재귀 barrel 문제: 10,000개 모듈을 가진 재귀 barrel 패키지의 경우 처리 시간이 30초에서 7초로 단축됐다.
실제 측정값: @material-ui/icons 기준 로컬 개발 부팅이 10.2s에서 2.9s로 71% 단축됐고, 서버리스 함수 콜드 스타트가 40% 개선됐다.
라이브러리를 번들링하지 않는 이유: 번들링으로 tree-shaking을 활성화할 수 있지만, 모듈 그래프 분석 오버헤드로 빌드 시간이 급증해 실용적이지 않다.

왜 읽나- @material-ui, lucide-react 같은 대형 라이브러리를 사용하는 Next.js 프로젝트에서 개발 서버 부팅이 느리거나 서버리스 콜드 스타트가 긴 문제를 겪는 개발자에게 원인과 즉시 적용 가능한 해결책을 제공한다.

Vercel Blog 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

Next.js에서 패키지 import를 최적화한 방법

이 글과 비슷한

Chat SDK의 Discord Components V2 지원 추가

Flags SDK, 플래그 평가 속도 10배 개선

AI로 웹 엔지니어 없이 LINE 앱 안에서 그룹 영상 통화 서비스 만들기