본문 바로가기
Front/JavaScript

2025년, 아직도 CommonJS vs ES Modules를 비교해야 할까?

by Awesome-SH 2025. 8. 5.

 

자바스크립트 개발을 하다 보면 한 번쯤은 마주치는 질문이죠.

"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도 지원하는 전략이 현실적입니다.

 

기존 프로젝트 마이그레이션

단계적 접근이 좋습니다:

  1. package.json 설정 변경
  2. import/export 구문 변경
  3. 파일 확장자 처리 (.js, .mjs)
  4. 의존성 패키지 호환성 확인
// 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 = 레거시 (하지만 당분간 필요)
  • 실무에서는 둘 다 이해해야 함

 

실용적인 조언

지금 당장 할 일

  1. 새 프로젝트: ES Modules로 시작
  2. 기존 프로젝트: 마이그레이션 일정 계획
  3. 라이브러리: Dual publishing 고려
  4. 학습: 두 시스템 모두 이해하되 ESM에 더 집중

🤔 언제까지 이 고민을 해야 할까?

npm 생태계의 79%가 마이그레이션하거나 사라질 때까지는 계속 관련 이슈가 있을 겁니다.

아마 2020년대 후반까지는 지속될 것 같아요.


결국 "이 둘을 비교하는 게 맞나?"라는 질문에 대한 답은 "네, 아직은 맞습니다"입니다.

다만 이제는 "어느 게 더 좋나?"가 아니라

"언제, 어떻게 ES Modules로 전환할 것인가?"를 논의해야 할 때인 것 같네요.

댓글