2025년 5월 16일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

## Backend — Node.js 24 출시

Node.js가 **25년 5월 6일 Node.js 24**를 Current 버전으로 공개했습니다.

이번 버전에는 **V8 13.6, npm 11**이 포함됐고, Web API인 `URLPattern`을 Node.js에서도 Global API로 사용할 수 있게 됐습니다.

Node.js는 최근 여러 버전에 걸쳐 `fetch`, WebSocket, Web Streams 같은 브라우저 표준 API를 Runtime 내부에 지속적으로 추가하고 있었는데, Node.js 24에서도 이런 흐름이 이어졌습니다.

다만 출시 당시 Node.js 24는 **Current Release**였으며 Production 장기 운영 기준으로는 Node.js 22 LTS를 유지하면서 24의 Compatibility를 검증하는 전략이 현실적이었습니다.

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

---

### Node.js는 단순한 JavaScript 실행기가 아니다

Node.js가 처음 등장했을 때 핵심 역할은 Browser 밖에서 JavaScript를 실행하는 것이었습니다.

```text
JavaScript
    ↓
Node.js
    ↓
Server
```

이를 통해 JavaScript로 Backend Application을 만들 수 있게 됐습니다.

```text
Client
  ↓
Node.js
  ↓
Database
```

이후 Express, NestJS, Fastify 같은 Framework가 등장하면서 Node.js는 대표적인 Backend Runtime 중 하나로 자리 잡았습니다.

---

### Browser와 Node.js는 같은 JavaScript지만 API가 달랐다

언어 자체는 JavaScript지만 Browser와 Node.js에서 사용할 수 있는 API는 오랫동안 상당히 달랐습니다.

```text
Browser

├─ fetch
├─ WebSocket
├─ FormData
├─ URL
└─ Web Streams
```

반면 과거 Node.js에서는 같은 기능을 사용하기 위해 별도의 Library를 설치하는 경우가 많았습니다.

```text
Node.js

├─ HTTP Client Library
├─ WebSocket Library
├─ Stream API
└─ Node-specific API
```

즉 같은 JavaScript를 사용해도 Runtime에 따라 개발 방식이 달랐습니다.

---

### Node.js가 Web API를 흡수하기 시작했다

최근 Node.js는 Browser와 호환되는 Web Standard API를 계속 Runtime에 추가하고 있습니다.

```text
Browser Web API
       ↕
Node.js Web API
```

대표적으로 다음과 같은 기능들이 있습니다.

```text
fetch

Request

Response

Headers

FormData

Blob

URL

AbortController

Web Streams

WebSocket
```

Node.js 24에서는 여기에 `URLPattern`도 Global API로 사용할 수 있게 됐습니다.

---

### URLPattern

`URLPattern`은 URL을 일정한 Pattern으로 정의하고 Matching할 수 있도록 만들어진 Web API입니다.

예를 들어 다음과 같은 URL이 있다고 가정할 수 있습니다.

```text
/users/10

/users/20

/users/100
```

이를 다음과 같은 Pattern으로 표현할 수 있습니다.

```javascript
const pattern = new URLPattern({
  pathname: '/users/:id'
});
```

URL을 Matching하면 Path Parameter도 확인할 수 있습니다.

```javascript
const result = pattern.exec(
  'https://example.com/users/100'
);

console.log(result.pathname.groups.id);
```

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

```text
/users/100
    ↓
/users/:id
    ↓
id = 100
```

Routing이나 URL Matching Logic을 만들 때 활용할 수 있습니다.

---

### Framework Router와는 다르다

`URLPattern`이 추가됐다고 Express나 NestJS의 Router가 필요 없어지는 것은 아닙니다.

Framework Router는 훨씬 많은 기능을 담당합니다.

```text
NestJS / Express Router

├─ HTTP Method
├─ Middleware
├─ Controller
├─ Validation
├─ Guard
├─ Authentication
└─ Error Handling
```

반면 `URLPattern`은 URL Pattern을 Matching하는 비교적 Low-level API입니다.

```text
URL
 ↓
Pattern Matching
```

따라서 Framework를 대체한다기보다 **Node.js Core에서 활용할 수 있는 기본 Building Block이 하나 더 생긴 것**에 가깝습니다.

---

### 외부 Dependency 없이 해결할 수 있는 영역이 늘어난다

과거 Node.js 개발에서는 간단한 기능도 npm Package를 추가하는 경우가 많았습니다.

```text
Need Feature
    ↓
npm install package
```

하지만 Node Core가 제공하는 기능이 많아지면서 일부 작업은 외부 Dependency 없이 해결할 수 있습니다.

예를 들어 HTTP Request의 경우 과거에는 다음과 같은 Library가 많이 사용됐습니다.

```text
axios

node-fetch
```

현재는 Node.js의 Global `fetch()`를 사용할 수 있습니다.

```javascript
const response = await fetch(
  'https://api.example.com/users'
);

const users = await response.json();
```

---

### WebSocket도 같은 흐름

Node.js 22에서는 WebSocket Client API가 Stable로 승격됐습니다.

```javascript
const socket = new WebSocket(
  'wss://example.com/socket'
);
```

과거에는 `ws` 같은 Library를 사용하는 경우가 많았습니다.

```text
기존

Node.js
   ↓
ws Package
   ↓
WebSocket


최근

Node.js
   ↓
WebSocket
```

Node.js 24의 `URLPattern` 역시 이런 **Web Platform API 통합 흐름의 연장선**에서 볼 수 있습니다.

---

### Node.js가 Web Platform에 가까워진다

전체 흐름을 보면 다음과 같습니다.

```text
과거

Browser API
     │
     │ 차이 큼
     │
Node.js API
```

점점

```text
        Web Standards
          ↙     ↘
     Browser   Node.js
```

형태로 바뀌고 있습니다.

JavaScript 개발자가 Runtime마다 완전히 다른 API를 학습해야 하는 영역이 조금씩 줄어드는 것입니다.

---

### Full Stack JavaScript에서도 의미가 있다

Frontend와 Backend 모두 JavaScript 또는 TypeScript를 사용하는 환경에서는 이런 변화가 특히 의미가 있습니다.

```text
Frontend

React / Next.js
      ↓
JavaScript Web API


Backend

Node.js
      ↓
JavaScript Web API
```

Client와 Server에서 비슷한 API를 사용할 수 있는 영역이 증가합니다.

예를 들어 다음 기능들은 양쪽 환경에서 비슷한 Programming Model을 사용할 수 있습니다.

```text
fetch

URL

Request

Response

Headers

AbortController

Streams
```

Runtime 간 Mental Model 차이가 줄어드는 것입니다.

---

### NestJS에서도 영향을 받는다

NestJS는 Node.js Runtime 위에서 동작합니다.

```text
NestJS
  ↓
Node.js
  ↓
Operating System
```

NestJS 자체는 Controller, Dependency Injection, Guard, Pipe 같은 Application Architecture를 제공합니다.

```text
NestJS

├─ Controller
├─ Service
├─ DI
├─ Guard
├─ Pipe
└─ Middleware
```

하지만 그 아래에서는 Node.js API를 사용합니다.

Node Core 기능이 발전하면 Application 내부 Utility나 Infrastructure Code에서 외부 Library 없이 처리할 수 있는 영역도 늘어납니다.

---

### Express와 Fastify도 마찬가지

Express나 Fastify 역시 Node Runtime 위에서 실행됩니다.

```text
Express / Fastify
       ↓
Node.js
       ↓
Runtime API
```

Framework가 HTTP Application 구조를 담당한다면 Node.js는 그 아래의 Runtime Capability를 제공합니다.

```text
Framework

Routing
Middleware
Validation


Node.js

HTTP
Web API
Streams
Runtime
File System
Network
```

Node.js Core가 강해질수록 Framework 개발자와 Library Author가 활용할 수 있는 기본 기능도 많아집니다.

---

### V8 13.6

Node.js 24에는 **V8 13.6**이 포함됐습니다.

V8은 JavaScript를 실제로 실행하는 Engine입니다.

```text
JavaScript
    ↓
V8
    ↓
Machine Execution
```

Node.js Architecture를 단순화하면 다음과 같습니다.

```text
Application

JavaScript / TypeScript
        ↓
Node.js
        ↓
V8
        ↓
Operating System
```

따라서 V8 Upgrade는 JavaScript Language Feature와 Runtime Performance에도 영향을 줄 수 있습니다.

---

### Node.js와 V8의 관계

Node.js는 JavaScript Language 자체를 직접 실행하는 Engine이 아닙니다.

JavaScript Execution은 V8이 담당합니다.

```text
Node.js

├─ V8
├─ libuv
├─ File System
├─ Network
├─ Web APIs
└─ Node APIs
```

Node.js는 V8 위에 Server Application을 위한 다양한 Runtime API를 추가한 Platform이라고 볼 수 있습니다.

따라서 Node Version이 올라가면 함께 포함되는 V8 Version도 Backend Developer에게 영향을 줄 수 있습니다.

---

### npm 11

Node.js 24에는 **npm 11**도 함께 제공됐습니다.

Node.js Application에서는 Package Manager 역시 개발 환경의 핵심 부분입니다.

```text
Node.js
  ↓
npm
  ↓
Dependencies
```

Application 하나에서도 수백 개의 Dependency가 연결될 수 있습니다.

```text
Application

├─ NestJS
├─ TypeORM
├─ Prisma
├─ Zod
├─ Jest
└─ 기타 Packages
```

따라서 npm의 Version 변화 역시 Dependency Resolution, 설치 성능, CLI 동작 등에 영향을 줄 수 있습니다.

---

### Node Core Tooling도 계속 커지고 있다

최근 Node.js의 또 다른 흐름은 **Runtime 자체에서 제공하는 개발 도구가 많아지고 있다는 점**입니다.

과거에는 많은 기능을 외부 Tool에 의존했습니다.

```text
Node.js
+
External Package
+
External Tool
```

최근 Node에는 다음과 같은 기능들이 포함돼 있습니다.

```text
Node.js Core

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

Runtime과 Toolchain의 경계도 점점 넓어지고 있습니다.

---

### Dependency가 줄어드는 장점

외부 Dependency가 적다고 무조건 좋은 것은 아니지만 불필요한 Dependency를 줄이면 몇 가지 장점이 있습니다.

```text
Dependency 감소

↓
Update 대상 감소

↓
Security Surface 감소

↓
Compatibility 문제 감소
```

특히 Node.js 생태계는 작은 Package까지 Dependency로 사용하는 경우가 많기 때문에 Dependency Tree가 매우 커질 수 있습니다.

```text
Application
   ↓
Package A
   ↓
Package B
   ↓
Package C
```

Core API로 해결할 수 있는 기능이라면 외부 Package가 정말 필요한지 다시 판단할 수 있습니다.

---

### 그렇다고 Node Core만 사용해야 하는 것은 아니다

Node.js에 기능이 들어왔다고 기존 Library를 무조건 제거해야 하는 것은 아닙니다.

예를 들어 `fetch`보다 Axios가 필요한 경우도 있습니다.

```text
Axios

Interceptors

Request Configuration

Convenient Error Handling

기존 Project Integration
```

Framework와 Library는 Node Core보다 높은 수준의 Abstraction을 제공합니다.

따라서 중요한 것은

```text
Core에 기능이 있으니
Library를 무조건 제거한다
```

가 아니라

```text
우리 Application에
추가 Dependency가 실제로 필요한가?
```

를 판단하는 것입니다.

---

### Current와 LTS

Node.js를 Production에서 운영할 때 가장 중요한 개념 중 하나가 **Release Channel**입니다.

Node.js Version은 일반적으로 먼저 Current로 출시됩니다.

```text
New Version
    ↓
Current
```

이후 일정 기간이 지나면 짝수 Major Version이 LTS로 전환됩니다.

```text
Current
  ↓
LTS
  ↓
Maintenance
```

Node.js 24 역시 2025년 5월 출시 당시에는 Current였습니다.

---

### Current는 무엇인가

Current Release에서는 최신 Node.js 기능을 가장 빠르게 사용할 수 있습니다.

```text
Current

최신 Feature
최신 V8
새로운 API
```

하지만 기업 Production에서 필요한 장기 Support 관점에서는 LTS보다 안정성이 검증되는 기간이 짧습니다.

따라서 다음과 같은 용도로 활용할 수 있습니다.

```text
Development

Compatibility Test

Benchmark

PoC

Library Testing
```

---

### LTS는 무엇인가

LTS(Long-Term Support)는 Production Application에서 장기간 유지하기 위한 Channel입니다.

```text
Production
    ↓
Node.js LTS
```

Framework와 Library 생태계 역시 대체로 LTS Version을 중심으로 Compatibility를 관리합니다.

따라서 장기 운영 Backend에서는 LTS가 기본 선택인 경우가 많습니다.

---

### 당시 현실적인 선택

Node.js 24가 나온 2025년 5월 시점에는 Node.js 22가 LTS였습니다.

따라서 Production 전략은 다음과 같이 가져갈 수 있었습니다.

```text
Production

Node.js 22 LTS


Development / CI

Node.js 24 Test


향후

Node.js 24 LTS 전환 후 Migration
```

안정적인 운영 환경을 유지하면서 새로운 Version의 Compatibility를 미리 확인하는 방식입니다.

---

### 무조건 최신 Node.js가 좋은 것은 아니다

Backend Runtime은 Application 전체의 기반입니다.

```text
Application
    ↓
Framework
    ↓
Node.js
```

Node.js Version을 변경하면 많은 Dependency에 영향을 줄 수 있습니다.

```text
Node Upgrade

├─ NestJS
├─ Express
├─ Fastify
├─ Native Module
├─ ORM
├─ Build Tool
└─ Test Tool
```

따라서 Production에서는 최신 Version이라는 이유만으로 즉시 Upgrade하는 것보다 Compatibility를 확인하는 것이 중요합니다.

---

### Node.js Upgrade에서 확인할 것

실제 Backend Project에서는 다음 요소를 확인할 수 있습니다.

```text
Node Upgrade

├─ Framework Compatibility
├─ Package Compatibility
├─ Native Addon
├─ npm Version
├─ Build
├─ Test
├─ Container Image
└─ CI/CD
```

예를 들어 Native Addon을 사용하는 Dependency는 Node/V8 Version 변화에 영향을 받을 가능성이 있습니다.

따라서 Test Suite가 충분하다면 Upgrade 검증이 훨씬 쉬워집니다.

---

### CI에서 여러 Node Version을 검증할 수 있다

Library나 중요한 Backend Service라면 CI에서 여러 Node Version을 테스트할 수도 있습니다.

```text
CI

├─ Node 22
└─ Node 24
```

이를 통해 Production Migration 전에 Compatibility 문제를 찾을 수 있습니다.

```text
Node 24
  ↓
npm install
  ↓
Test
  ↓
Build
```

Runtime Upgrade 역시 자동화된 Test의 가치가 큰 영역입니다.

---

### Docker 환경에서도 Node Version이 중요하다

Container 기반 Backend에서는 Node Version이 Base Image에 포함되는 경우가 많습니다.

```dockerfile
FROM node:22
```

Node 24를 테스트하려면 다음처럼 변경할 수 있습니다.

```dockerfile
FROM node:24
```

하지만 Version만 바꾸는 것으로 끝내지 않고 Application Build와 Runtime 동작을 검증해야 합니다.

```text
Base Image 변경
      ↓
Install
      ↓
Build
      ↓
Test
      ↓
Runtime Test
```

---

### Node.js가 범용 Runtime으로 발전한다

Node.js의 역할 변화를 보면 방향이 명확합니다.

초기에는

```text
JavaScript
    ↓
Server Runtime
```

이었다면,

점점

```text
JavaScript Runtime

├─ Server
├─ CLI
├─ Tooling
├─ Worker
├─ Web APIs
└─ Build Tools
```

형태로 확대되고 있습니다.

단순히 Express Server를 실행하기 위한 Runtime이라고 보기 어려워진 것입니다.

---

### Browser와 Server의 경계도 줄어든다

Web Standard API를 계속 지원하면서 Browser와 Node.js 사이의 개발 경험도 가까워지고 있습니다.

```text
Browser
   ↕
Web Standards
   ↕
Node.js
```

예를 들어 같은 `fetch()` API를 양쪽에서 사용할 수 있습니다.

```javascript
const response = await fetch('/api/users');
```

물론 Runtime 환경은 여전히 다릅니다.

```text
Browser

DOM
Window
User Interface


Node.js

File System
Process
Server
Network
```

하지만 공통으로 사용할 수 있는 기본 API 영역은 계속 확대되고 있습니다.

---

### Full Stack Framework에도 영향을 준다

Next.js 같은 Framework는 Browser와 Server 양쪽에서 Code가 실행됩니다.

```text
Next.js

├─ Client
└─ Server
```

Node.js가 Web Standard API를 더 많이 제공하면 Framework가 Client와 Server 사이에서 동일한 API를 사용하는 것도 쉬워집니다.

```text
Client
   ↓
Web API


Server
   ↓
Web API
```

Full Stack JavaScript Framework가 발전하기 좋은 기반이 되는 것입니다.

---

### Backend 개발자의 Mental Model도 단순해진다

과거에는 Runtime마다 별도의 API 사용법을 기억해야 했습니다.

```text
Browser

fetch()


Node.js

외부 HTTP Library
```

최근에는 다음처럼 공통적인 Programming Model을 사용할 수 있는 경우가 늘어납니다.

```text
JavaScript Developer
       ↓
Web Standard
       ↓
Browser / Server
```

특히 Frontend와 Backend를 모두 다루는 개발자에게는 의미가 큽니다.

---

### 왜 중요한가

Node.js 24의 중요성은 `URLPattern`이라는 API 하나가 추가됐다는 데만 있지 않습니다.

Node.js의 장기적인 방향이 계속 유지되고 있다는 점이 중요합니다.

```text
Node.js

과거

Server-specific Runtime


현재

Server Runtime
+
Web Standards
+
Developer Tooling
```

Browser JavaScript와 Node.js JavaScript 사이의 API 차이가 조금씩 줄어들면서 JavaScript Platform 전체가 점점 더 일관된 형태로 발전하고 있습니다.

---

### 실무 영향

NestJS, Express, Fastify, Next.js Backend 같은 Node Application에서는 Node Core에서 해결할 수 있는 영역이 계속 증가하고 있습니다.

```text
Node Core

fetch

WebSocket

URLPattern

Streams

Test Runner

Env File
```

따라서 새로운 Feature를 구현할 때 기존처럼 바로 npm Package를 찾기보다 **Node Runtime에서 이미 제공하는 기능인지 먼저 확인할 가치**가 커졌습니다.

Production에서는 당시 Node.js 24가 Current였기 때문에 다음과 같은 전략이 현실적이었습니다.

```text
Node.js 22 LTS

Production 유지
      ↓
Node.js 24

Development / CI 검증
      ↓
Framework / Dependency Compatibility 확인
      ↓
LTS 이후 Production Migration 검토
```

결국 Node.js 24는,

> **Node.js가 단순한 웹 서버용 JavaScript Runtime에서 Web Standard API와 자체 Tooling을 폭넓게 제공하는 범용 JavaScript Platform으로 계속 발전하고 있음을 보여주는 Release**

라고 볼 수 있습니다.

Backend 개발자 입장에서는 최신 Node API를 이해하는 것도 중요하지만 Production에서는 **LTS 정책과 Framework Compatibility를 함께 고려해 Runtime Upgrade를 관리하는 능력**이 더욱 중요해지고 있습니다.

2025년 5월 9일(금) 주간 개발트렌드

독자의 메모