CommonJS와 ES Module, 지금 무엇이 다르고 언제 무엇을 써야 할까 빠른 답 새 Node.js 애플리케이션은 특별한 이유가 없으면 ESM을 기본값으로 두는 편이 자연스럽다. 차이는 문법보다 모듈 해석 방식, export 모델, 정적 분석 가능성에서 더 크게 드러난다. Node.js에서는 파일 확장자와 package.json의 type 값이 먼저 모듈 시스템을 결정한다. ESM과 CommonJS를 섞을 때는 interop 제약과 실제 오류 메시지를 함께 봐야 판단이 빨라진다. 현재 기준이 중요한 주제라서 Node 공식 문서와 스펙 링크부터 확인하고 있습니다. 오래된 설명에서 자주 섞이는 type , .mjs/.cjs , require(ESM) 동작, 오류 코드 변화를 먼저 검증한 뒤 본문을 정리하겠습니다.공식 문서 기준선은 확인됐습니다. 이제 본문은 현재 지원 버전 기준과 오래된 설명의 차이를 먼저 드러내고, live binding , default/named import , ERR_REQUIRE_ASYNC_MODULE 처럼 실제로 헷갈리는 지점을 출력 예시와 함께 정리하겠습니다.실행 예시는 로컬 node v24.14.0 으로 맞추고 있습니다. 글에는 명령만 두지 않고 실제 에러 첫 줄과 핵심 메시지가 함께 보이도록 정리하겠습니다. require(ESM) 의 현재 동작도 실제로 확인할 수 있는지 한번 더 보고 있습니다. 문서 설명만 둘지, 로컬 출력까지 넣을지 결정하려고 프로세스 치환으로 재현 가능한 범위를 확인하는 중입니다.상태 관찰 예시도 실제 출력으로 맞췄습니다. CommonJS에서 구조 분해한 값이 그대로 남는 경우와, ESM의 바인딩이 값 변경을 따라오는 경우를 출력 기준으로 대비할 수 있습니다.# CommonJS와 ES Module, 지금 무엇이 다르고 언제 무엇을 써야 할까 목차 한눈에 비교 왜 CommonJS와 ESM이 문법 차이 이상으로 헷갈리는가 오래된 설명의 함정과 현재 Node.js 기준 값과 상태가 다르게 보...