2024년 10월 25일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/2a3741f8-626e-4237-b985-d52de10bb444_thumbnail_1.png)

## Backend — Node.js 23, `require(esm)` 기본 활성화

Node.js가 **10월 16일 Node.js 23**을 Current 버전으로 공개했습니다.

이번 버전에서 눈에 띄는 변화 중 하나는 **CommonJS의 `require()`를 통해 ES Module을 불러오는 `require(esm)` 기능이 기본 활성화됐다는 점**입니다.

또한 `node --run` 명령도 Stable로 승격되면서 Node.js 자체 Tooling도 계속 강화됐습니다.

[Node.js - Node.js v23.0.0](https://nodejs.org/en/blog/release/v23.0.0)

---

### 오랫동안 이어진 CommonJS와 ESM 문제

Node.js 생태계에서는 오랫동안 두 가지 Module System이 함께 사용돼 왔습니다.

```text
CommonJS
   vs
ES Modules
```

CommonJS에서는 다음과 같이 Module을 불러옵니다.

```javascript
const fs = require('node:fs');
```

반면 ES Modules에서는 `import`를 사용합니다.

```javascript
import fs from 'node:fs';
```

문제는 두 방식이 단순히 Syntax만 다른 것이 아니라 **Module Loading 방식과 Package 설정까지 서로 다르다는 점**입니다.

---

### CommonJS

Node.js 초창기부터 사용해온 Module System입니다.

```javascript
const module = require('./module');

module.exports = {
  hello
};
```

오랫동안 Node.js Package 생태계의 기본 방식이었기 때문에 수많은 Library가 CommonJS 기반으로 만들어졌습니다.

```text
Node.js
   ↓
CommonJS
   ↓
npm Package 생태계
```

---

### ES Modules

JavaScript 표준 Module System이 등장하면서 Node.js 역시 ESM을 지원하기 시작했습니다.

```javascript
import { hello } from './module.js';

export {
  hello
};
```

Browser와 Node.js 모두 같은 Module Syntax를 사용할 수 있다는 장점이 있습니다.

```text
Browser
   ↓
ES Modules

Node.js
   ↓
ES Modules
```

하지만 Node.js에는 이미 거대한 CommonJS 생태계가 존재했기 때문에 두 Module System이 오랫동안 함께 사용됐습니다.

---

### 문제는 두 생태계의 충돌

실제 프로젝트에서는 다음과 같은 상황이 자주 발생했습니다.

```text
Application

CommonJS
   ↓
Dependency
   ↓
ESM Only
```

CommonJS Project에서 ESM 전용 Package를 불러오면 문제가 발생할 수 있었습니다.

대표적으로 다음과 같은 Error를 경험한 개발자도 많았습니다.

```text
ERR_REQUIRE_ESM
```

즉 기존 코드에서 단순히

```javascript
const library = require('library');
```

를 사용할 수 없는 상황이 발생할 수 있었습니다.

---

### 기존 해결 방법

이런 문제를 해결하기 위해 Dynamic Import를 사용하는 경우가 있었습니다.

```javascript
const library = await import('library');
```

또는 Project 전체를 ESM으로 변경하기도 했습니다.

```json
{
  "type": "module"
}
```

하지만 기존 CommonJS Project를 ESM으로 Migration하면 또 다른 Compatibility 문제가 발생할 수 있습니다.

```text
CommonJS Project
      ↓
ESM Migration
      ↓
Dependency Compatibility
      ↓
Build Tool 설정
      ↓
Test 환경 수정
```

단순히 Module Syntax 하나를 변경하는 문제가 아니었던 것입니다.

---

### Node.js 23의 `require(esm)`

Node.js 23에서는 CommonJS에서 ES Module을 `require()`로 불러오는 기능이 기본 활성화됐습니다.

개념적으로는 다음과 같습니다.

```text
CommonJS Application

require()
   ↓
ES Module
```

기존에는

```text
CommonJS
   ✕
ESM
```

처럼 두 Module System 사이에 강한 경계가 있었다면,

Node.js는 점점 다음과 같은 방향으로 이동하고 있습니다.

```text
CommonJS
    ↕
ES Modules
```

두 생태계 사이의 Interoperability를 높이는 방향입니다.

---

### 왜 중요한가

JavaScript 자체는 이미 ES Modules를 표준 Module System으로 사용하고 있습니다.

하지만 Node.js에는 여전히 수많은 CommonJS Application과 Library가 존재합니다.

```text
Legacy Node.js

CommonJS
   ↓
수많은 기존 Application


Modern JavaScript

ES Modules
   ↓
새로운 Package
```

따라서 Node.js가 ESM으로 이동하려면 기존 CommonJS 생태계를 무시할 수 없습니다.

`require(esm)`은 이 두 생태계 사이의 Migration Cost를 줄이는 역할을 할 수 있습니다.

---

### Package 개발에서도 중요하다

Node.js Library를 만들 때 개발자가 자주 고민하는 문제 중 하나가 Module Format입니다.

```text
Library

CommonJS로 배포?
      or
ESM으로 배포?
      or
둘 다 지원?
```

둘 다 지원하려면 Package 설정도 복잡해질 수 있습니다.

```json
{
  "exports": {
    "import": "./dist/index.js",
    "require": "./dist/index.cjs"
  }
}
```

이런 방식을 흔히 Dual Package 형태로 운영합니다.

```text
Package

├─ ESM Build
└─ CommonJS Build
```

하지만 두 Build를 동시에 관리하면 Build Pipeline과 Test Complexity도 증가합니다.

---

### ESM 전용 Package의 증가

최근 JavaScript 생태계에서는 ESM 전용 Package도 계속 증가하고 있습니다.

```text
New JavaScript Library
        ↓
      ESM Only
```

문제는 기존 Node.js Application 상당수가 여전히 CommonJS를 사용하는 경우가 있다는 점입니다.

```text
Legacy Application
CommonJS
     ↓
New Package
ESM
```

`require(esm)`은 이런 상황에서 두 생태계를 연결하는 Compatibility Layer 역할을 할 수 있습니다.

---

### NestJS에서도 발생하는 문제

NestJS 역시 Node.js 위에서 동작하기 때문에 ESM과 CommonJS 문제에서 완전히 자유롭지는 않습니다.

예를 들어 Application은 CommonJS 방식으로 Build되고 있는데 사용하는 Dependency가 ESM Only라면 문제가 발생할 수 있습니다.

```text
NestJS
  ↓
CommonJS Build
  ↓
ESM-only Dependency
  ↓
Compatibility Problem
```

이 경우 개발자는

- Dynamic Import
- tsconfig 변경
- Package 설정 변경
- Build Target 변경
- Dependency Version 변경

등을 검토해야 했습니다.

Node.js 자체의 ESM / CommonJS Interoperability가 좋아질수록 이런 환경에서 발생하는 마찰도 점차 줄어드는 방향으로 갈 수 있습니다.

---

### `node --run` Stable

Node.js 23에서는 `node --run`도 Stable 단계로 승격됐습니다.

`package.json`에 다음과 같은 Script가 있다고 가정할 수 있습니다.

```json
{
  "scripts": {
    "dev": "node server.js",
    "test": "node --test"
  }
}
```

일반적으로 npm을 사용하면 다음처럼 실행합니다.

```bash
npm run dev
```

Node.js에서는 자체적으로 다음과 같이 실행할 수도 있습니다.

```bash
node --run dev
```

즉 Node.js Runtime 자체에서 `package.json` Script 실행 기능을 제공하는 것입니다.

---

### Node.js 자체 Toolchain 강화

최근 Node.js의 흐름을 보면 Runtime만 제공하는 것이 아니라 개발에 필요한 기본 기능을 점점 직접 제공하고 있습니다.

```text
Node.js

├─ fetch
├─ WebSocket
├─ Test Runner
├─ Watch Mode
├─ Env File
└─ node --run
```

과거에는 많은 기능을 외부 Package에 의존해야 했다면 Node.js Core가 점점 더 많은 기능을 제공하고 있습니다.

```text
기존

Node.js
   +
npm Packages
   +
External Tooling


최근

Node.js Core
   ↓
더 많은 기본 기능 제공
```

---

### Backend 관점에서의 변화

Node.js Backend 개발에서는 Dependency Compatibility가 꽤 중요한 문제입니다.

특히 다음 조합에서 문제가 발생할 수 있습니다.

```text
Node.js
+
TypeScript
+
NestJS / Express / Fastify
+
npm Dependencies
+
Build Tool
```

이 중 하나라도 Module System을 다르게 사용하면 Build 또는 Runtime Error가 발생할 수 있습니다.

```text
ESM
 ↕
CommonJS
 ↕
TypeScript
 ↕
Bundler
```

따라서 Node.js 자체에서 두 Module System 사이의 Compatibility를 높이는 것은 단순한 Syntax 개선보다 실무적인 의미가 큽니다.

---

### Node.js가 향하는 방향

Node.js는 CommonJS를 갑자기 제거하고 ESM으로 완전히 전환하기보다는 **기존 생태계와 새로운 JavaScript 표준 사이의 경계를 점진적으로 줄이는 방향**을 선택하고 있습니다.

```text
기존

CommonJS
   vs
ES Modules


변화

CommonJS
   ↕
ES Modules


장기적 방향

JavaScript Standard
+
Node.js Compatibility
```

이미 존재하는 수많은 Node.js Application을 유지하면서 새로운 ESM 생태계로 자연스럽게 이동할 수 있도록 만드는 것입니다.

---

### 실무 영향

Node.js 23의 변화는 특히 오래된 CommonJS Project와 새로운 ESM Package를 함께 사용해야 하는 개발자에게 의미가 있습니다.

기존에는

```text
ESM Dependency
      ↓
CommonJS Project
      ↓
Dynamic Import
      ↓
Build 설정 수정
```

같은 추가 작업이 필요했다면,

Node.js 자체의 Interoperability가 개선되면서 점점

```text
CommonJS
   ↓
require()
   ↓
ES Module
```

처럼 단순한 형태로 접근할 수 있는 영역이 늘어날 수 있습니다.

Library 개발에서도 장기적으로는 ESM과 CommonJS를 동시에 지원하기 위한 복잡한 Build 구성이 줄어들 가능성이 있습니다.

결국 Node.js 23의 `require(esm)` 기본 활성화는,

> **수년 동안 Node.js 생태계의 대표적인 호환성 문제였던 CommonJS와 ES Modules의 경계를 줄이기 위한 중요한 변화**

라고 볼 수 있습니다.

Node.js가 Web API를 Runtime 내부로 흡수하는 동시에 Module System과 Toolchain까지 개선하면서 **JavaScript 표준과 기존 Node.js 생태계를 연결하는 방향으로 계속 발전하고 있음을 보여주는 Release**였습니다.

2024년 10월 18일(금) 주간 개발트렌드

독자의 메모