이제는 ESM으로 전환할 때입니다: Node.js 및 프론트엔드 생태계 변화

2015년 ESM(ECMAScript Modules)이 처음 도입된 이후, JavaScript 생태계는 점진적으로 CommonJS(CJS)에서 ESM으로 이동해 왔습니다. 2021년에는 npm 패키지의 7.8%만이 ESM을 지원했지만, 2024년 말에는 25.8%까지 증가하며 빠른 성장세를 보이고 있습니다.

특히 Vite, Nuxt, SvelteKit, Astro 같은 최신 프레임워크들은 ESM을 기본적으로 지원하며, ESLint, Vitest, tsx 같은 도구들도 적극적으로 ESM을 도입하고 있습니다.

이제는 ESM을 완전히 받아들이고 CJS를 벗어날 시점이 되었습니다. 이번 글에서는 왜 이제 ESM-only로 전환해야 하는지, 그리고 전환 과정에서 고려해야 할 사항에 대해 알아보겠습니다.

반응형

---

🔧 도구들은 이미 준비 완료!

1️⃣ 최신 개발 도구는 ESM 중심

현재 JavaScript 개발 도구들은 대부분 ESM을 우선적으로 지원합니다.

✅ 빌드 툴: Vite 기반의 Nuxt, SvelteKit, Astro, Remix 등
✅ 테스트 프레임워크: Vitest (ESM 전용)
✅ ESLint: v9.0에서 ESM을 공식 지원

특히 Vite는 빠른 개발 환경을 제공하며, 기본적으로 ESM을 활용합니다. 또한 tsx, jiti 같은 CLI 도구도 TypeScript와 ESM을 쉽게 실행할 수 있도록 지원합니다.

---

⬆️ ESM 도입 방식: Top-Down vs Bottom-Up

과거에는 일부 라이브러리들이 개별적으로 ESM-only로 전환하는 "Bottom-Up" 방식이 주를 이루었지만, 최근에는 프레임워크, 빌드 툴이 먼저 ESM을 지원하는 "Top-Down" 방식이 효과적으로 자리 잡고 있습니다.

✔️ 과거 (Bottom-Up): 개별 라이브러리(ex. find-up, execa)가 먼저 ESM-only로 전환 → 사용자들이 따라오기 힘들었음
✔️ 현재 (Top-Down): 프레임워크 & 툴들이 먼저 지원 → 개발자들이 자연스럽게 ESM-only 패키지를 사용

이제 대부분의 주요 프레임워크가 ESM을 지원하기 때문에 개별 라이브러리들도 부담 없이 ESM-only로 이동할 수 있는 환경이 마련되었습니다.

---

🔄 Node.js에서도 ESM 지원 확대

과거에는 Node.js에서 ESM을 require()로 직접 불러올 수 없었지만, Node.js v22에서 해당 기능이 정식 지원되면서, CJS 프로젝트에서도 ESM-only 패키지를 부담 없이 사용할 수 있는 길이 열렸습니다.

✅ Node.js v22 이상에서는 require()로 ESM 사용 가능
✅ ESM → CJS → ESM 구조도 원활하게 작동

이 기능 덕분에 이제는 ESM-only 패키지가 CJS 프로젝트에서도 쉽게 활용될 수 있어 전환이 더욱 쉬워졌습니다.

---

❌ 듀얼 포맷(CJS + ESM)의 문제점

그동안 많은 라이브러리들이 CJS와 ESM을 함께 제공하는 듀얼 포맷을 사용해 왔지만, 이는 여러 문제를 초래합니다.

1️⃣ 호환성 문제

CJS와 ESM은 기본적인 동작 방식이 다르므로, 두 포맷을 동시에 유지하면 여러 가지 불필요한 인터페이스 충돌이 발생합니다.

예를 들어:

• CJS는 module.exports 사용, ESM은 export default 및 named exports 사용 → 변환 과정에서 버그 발생 가능
• 타입스크립트에서는 .d.mts와 .d.cts 같은 추가적인 타입 선언 필요

2️⃣ 패키지 해석 문제

• CJS 패키지가 ESM-only 패키지를 가져올 때, 올바른 버전을 사용하지 않으면 버전 충돌 발생
• 싱글톤 패턴을 사용하는 라이브러리의 경우, 중복 인스턴스 생성 가능성 증가

3️⃣ 패키지 크기 증가

듀얼 포맷을 유지하면 두 가지 버전을 동시에 포함해야 하기 때문에 패키지 크기가 두 배 증가합니다.
👉 node_modules가 불필요하게 커지는 문제 발생

이러한 문제를 고려하면 이제 듀얼 포맷을 유지하는 것보다 ESM-only로 전환하는 것이 더 합리적인 선택이 됩니다.

---

📌 ESM-only로 전환할 시점은 언제일까?

✅ 새로운 패키지라면? → 무조건 ESM-only

이미 최신 개발 환경에서는 대부분 ESM을 지원하므로 신규 패키지는 ESM-only로 출시하는 것이 바람직합니다.

✅ 브라우저 타겟 패키지? → ESM-only 추천

브라우저용 패키지는 번들링 과정에서 ESM을 활용하면 트리 셰이킹이 가능하여 최적화된 코드가 생성됩니다.

✅ CLI 도구? → ESM-only 가능

CLI 도구는 내부적으로 어떻게 동작하는지가 중요하지 않기 때문에 ESM-only로 전환해도 문제 없음

✅ Node.js 지원 범위? → 최신 버전 지원 시 ESM-only 고려

Node.js v22 이상을 지원하는 패키지는 ESM-only로 가는 것이 점점 더 자연스러워지고 있습니다.

✅ 기존 사용자가 많다면? → 의존성 확인 후 전환

ESLint 플러그인처럼 특정 프로젝트 환경에서 사용되는 패키지는, 해당 프로젝트가 ESM을 지원하는지 확인한 후 전환하는 것이 좋습니다.

---

🔮 앞으로의 전망: ESM-only가 기본이 될 것인가?

이제 JavaScript 생태계는 점점 더 ESM-only로 이동하는 추세입니다.

✔ Vite, Vitest, Nuxt, Astro 등 주요 도구들이 이미 ESM-first
✔ Node.js v22에서 require(ESM) 지원으로 CJS 프로젝트에서도 문제없이 사용 가능
✔ 듀얼 포맷 유지의 부담(크기 증가, 호환성 문제) 해소

따라서 앞으로 출시되는 대부분의 패키지는 ESM-only가 기본이 될 가능성이 매우 큽니다.
👉 지금이야말로 ESM-only로 전환할 최적의 시점입니다! 🚀

---

728x90

✅ 최신 도구와 프레임워크는 이미 ESM을 기본으로 지원
✅ 듀얼 포맷(CJS + ESM)은 유지 비용이 크고 호환성 문제가 많음
✅ Node.js v22 이상에서는 require(ESM)이 지원되며, CJS 프로젝트에서도 부담 없이 사용 가능
✅ 새로운 패키지라면 반드시 ESM-only로 시작하는 것이 유리

https://antfu.me/posts/move-on-to-esm-only

Move on to ESM-only