
자바스크립트 개발을 하다 보면 한 번쯤은 마주치는 질문이죠.
"CommonJS랑 ES Modules 중에 뭘 써야 하지?" 사실 저도 이런 질문을 받으면
"음... 둘 다 알아야 하는데..."라고 애매하게 답했던 적이 많습니다.
하지만 2025년 현재 상황을 보면, 답은 이미 정해져 있습니다.
ES Modules가 승리했어요. 다만 현실은 그렇게 단순하지 않죠.
답은 정해졌지만 현실은 복잡해
결론부터 말하면:
- 새 프로젝트는 ES Modules로 시작하세요
- 기존 프로젝트는 마이그레이션 계획을 세우세요
- 하지만 당분간은 둘 다 알아야 합니다
현재 상황: ES Modules가 압도적 우세
🏆 ES Modules의 승리 요인들
프레임워크와 도구들의 선택
- React, Vue, Angular, Svelte 모두 ES Modules 우선 지원
- Vite, esbuild 같은 모던 빌드 도구들은 ESM 기본
- 브라우저 지원률 94-96% (이제 걱정 없음)
Node.js의 적극적 지원
- Node.js 14부터 안정적인 ES Modules 지원
- Node.js 22에서는 require(esm) 실험적 지원 추가
- 공식 문서도 ES Modules 위주로 변경
현실의 벽
npm 패키지 3백만 개 중에서 ES Modules를 지원하는 건 고작 21%뿐입니다.
나머지 79%는 여전히 CommonJS 전용이거나 아예 모듈 시스템을 명시하지 않아요.
이게 바로 "답은 정해졌지만 현실은 복잡하다"는 이유입니다.
기술적으로 왜 ES Modules가 더 나을까?
✨ ES Modules의 장점
1. Tree Shaking & 번들 최적화
// 필요한 것만 가져오기 (정적 분석 가능)
import { debounce } from 'lodash-es';
2. 동적 import로 코드 스플리팅
// 필요할 때만 로드
const module = await import('./heavy-module.js');
🐌 CommonJS의 한계
동기적 로딩: 메인 스레드를 블록할 수 있어요
정적 분석 불가: 번들 최적화에 불리해요
Top-level await 미지원: 비동기 초기화가 번거로워요
개발자 커뮤니티 반응
재미있게도, 개발자들이 "또 모듈 시스템 얘기야?"라며 피로감을 느끼는 게 아니라
적극적으로 마이그레이션을 논의하고 있습니다.
신규 개발자들: ES Modules부터 배우는 경우가 많음
경험 많은 개발자들: 익숙함 때문에 CommonJS 선호하지만 ESM 필요성 인정
라이브러리 개발자들: Dual publishing (둘 다 지원) 전략 채택
실무에서는 어떻게 해야 할까?
// package.json
{
"type": "module",
"exports": {
".": {
"import": "./dist/index.js",
"require": "./dist/index.cjs"
}
}
}
ES Modules로 시작하되, 필요하면 CommonJS도 지원하는 전략이 현실적입니다.
기존 프로젝트 마이그레이션
단계적 접근이 좋습니다:
- package.json 설정 변경
- import/export 구문 변경
- 파일 확장자 처리 (.js, .mjs)
- 의존성 패키지 호환성 확인
// ES Module에서 CommonJS 사용하기
import { createRequire } from 'module';
const require = createRequire(import.meta.url);
const oldModule = require('./old-commonjs-module');
미래 전망: ESM 중심의 생태계
웹 표준 발전: Import Maps로 빌드 도구 없이도 ESM 사용 가능
새로운 런타임: Deno, Bun 등은 ESM 네이티브 지원
JSR(JavaScript Registry): 크로스 런타임 호환 패키지 레지스트리
결론: 비교는 여전히 의미 있지만 방향은 정해졌다
2025년에도 이 비교가 의미 있는 이유:
- 79%의 npm 패키지가 아직 ESM 미지원
- 기존 프로젝트 마이그레이션 계획 필요
- 팀의 기술적 제약사항 고려
하지만 방향은 명확합니다:
- ES Modules = 미래
- CommonJS = 레거시 (하지만 당분간 필요)
- 실무에서는 둘 다 이해해야 함
실용적인 조언
지금 당장 할 일
- 새 프로젝트: ES Modules로 시작
- 기존 프로젝트: 마이그레이션 일정 계획
- 라이브러리: Dual publishing 고려
- 학습: 두 시스템 모두 이해하되 ESM에 더 집중
🤔 언제까지 이 고민을 해야 할까?
npm 생태계의 79%가 마이그레이션하거나 사라질 때까지는 계속 관련 이슈가 있을 겁니다.
아마 2020년대 후반까지는 지속될 것 같아요.
결국 "이 둘을 비교하는 게 맞나?"라는 질문에 대한 답은 "네, 아직은 맞습니다"입니다.
다만 이제는 "어느 게 더 좋나?"가 아니라
"언제, 어떻게 ES Modules로 전환할 것인가?"를 논의해야 할 때인 것 같네요.
'Front > JavaScript' 카테고리의 다른 글
| VanilaJS로 SPA 개발해보기 (No Framework) (1) | 2022.02.15 |
|---|---|
| 트리 쉐이킹 (Tree Shaking) 이란 무엇인가 (0) | 2022.01.12 |
| 이벤트 루프 (Event Loop) 정확히 알기 (2) (0) | 2021.10.17 |
| 이벤트 루프 (Event Loop) 정확히 알기 (1) (0) | 2021.10.15 |
| [Javascript] 호이스팅(Hoisting)에 대해 정리 (0) | 2021.10.07 |
댓글