Node.js 24가 LTS 단계에 진입했다. 타입스크립트 타입 스트리핑이 안정화돼 tsc 없이 .ts 파일을 직접 실행할 수 있고, 권한 모델(Permission Model)이 정식 출시됐다. Undici 7 WebSocketStream, V8 13.6, npm 11, URLPattern 전역 객체, .env 파일 네이티브 지원도 포함됐다. Node.js 22에서 24로 마이그레이션 시 주의해야 할 crypto.createCipher 제거, url.parse() 지원 중단, require/ESM 인터롭 변화와 실전 체크리스트를 정리한다.
한 줄 핵심: Node.js 24가 LTS(장기 지원) 단계에 진입했다. 타입스크립트 타입 스트리핑(TypeScript type stripping)이 안정화돼 트랜스파일러 없이 .ts 파일을 직접 실행할 수 있고, 권한 모델(Permission Model)이 정식 출시됐으며, Undici 7·V8 13.6·npm 11이 탑재됐다. Node.js 22에서 24로 마이그레이션할 때 주의해야 할 변경 사항과 실전 체크리스트를 정리한다.
이 글이 필요한 사람
Node.js 22 또는 20을 운영 중이며 24로 언제 올려야 할지 고민하는 개발자
타입스크립트 타입 스트리핑이 실제로 어떻게 동작하는지, ts-node를 대체할 수 있는지 알고 싶은 분
권한 모델로 Node.js 프로세스의 파일시스템·네트워크 접근을 제한하려는 분
※ 이 글은 Node.js 공식 릴리즈 블로그, nodejs.org/en/blog/migrations/v22-to-v24, LogRocket 블로그(2026년)를 참고했습니다.
왜 지금 Node.js 24 LTS로 올려야 하는가
Node.js 22 LTS는 2024년 10월 LTS로 지정됐고, 2027년 4월까지 지원이 지속된다. 서두를 필요가 없어 보이지만 두 가지 이유로 이미 24로 전환을 고려할 시점이다.
첫째, 신규 프로젝트는 24가 기본값이 됐다. 버셀(Vercel) 런타임 기본값도 Node.js 24로 바뀌었고, Docker 공식 이미지의 node:lts 태그도 24를 가리킨다. 새 프로젝트를 22로 시작하면 곧 역행이 된다.
둘째, 타입스크립트 네이티브 지원이 안정화됐다. 기존 22에서 --experimental-strip-types 플래그가 필요했던 기능이 24에서는 플래그 없이 안정적으로 동작한다. 빌드 파이프라인 단순화와 직결된다.
Node.js 20 LTS 사용자라면 이미 지원 종료 일정(2026년 4월)이 가까워졌으므로 24로의 직접 업그레이드를 권장한다.
ⓒ Node.js
타입스크립트 타입 스트리핑 안정화 — tsc 없이 .ts 파일 직접 실행
Node.js 24의 가장 실용적인 변화다. .ts 파일을 node로 직접 실행할 수 있다. 타입 정보(type annotations)를 런타임에서 단순 제거(strip)하는 방식이다 — 타입 검사는 하지 않는다.
Node.js 24 — .ts 파일 직접 실행
# Node.js 22: 플래그 필요
node --experimental-strip-types server.ts
# Node.js 24: 플래그 없이 안정
node server.ts
# 타입스크립트 예시 파일 (server.ts)
# function greet(name: string): string {
# return `안녕하세요, ${name}!`;
# }
# console.log(greet('개발자')); // 정상 실행
중요한 제약 사항이 있다.
타입 검사는 하지 않는다: 런타임에서 타입 정보를 그냥 지운다. tsc --noEmit으로 별도 타입 검사는 여전히 필요하다.
enum은 지원하지 않는다: enum 구문은 제거 방식으로 처리할 수 없어 오류가 발생한다. const enum이나 유니언 타입으로 대체해야 한다.
namespace는 지원하지 않는다: 타입스크립트 namespace도 마찬가지다. 모듈 기반 구조로 작성해야 한다.
클래스 데코레이터는 설정에 따라 동작: experimentalDecorators가 필요한 구형 데코레이터는 별도 처리가 필요하다.
ts-node나 tsx의 완전한 대체는 아직 아니다. 하지만 간단한 스크립트, CI 실행 파일, 소규모 서버에서는 빌드 단계를 없애는 데 실질적으로 유용하다. 특히 클로드 코드 같은 에이전틱 환경에서 빠르게 타입스크립트 스크립트를 실행해야 할 때 편리하다.
권한 모델 정식 출시 — 파일시스템·네트워크 접근을 화이트리스트로 제한
Node.js 24에서 권한 모델(Permission Model)이 안정화됐다. --permission 플래그를 주면 허용 목록 없이 모든 파일시스템·네트워크·자식 프로세스 접근이 차단된다. 필요한 것만 명시적으로 허용한다.
Node.js 24 권한 모델 — 최소 권한 실행 예시
# 모든 접근 차단 후 특정 경로만 허용
node --permission \
--allow-fs-read=/app/data \
--allow-fs-write=/app/logs \
--allow-net=api.example.com:443 \
server.js
# 권한 없이 접근 시도 시 오류
# Error [ERR_ACCESS_DENIED]: Access to FileSystem 'read' denied
지원하는 권한 플래그를 정리하면 다음과 같다.
--allow-fs-read=경로: 해당 경로 읽기 허용 (와일드카드 지원)
--allow-fs-write=경로: 해당 경로 쓰기 허용
--allow-net=호스트:포트: 특정 호스트 네트워크 허용
--allow-child-process: child_process 모듈 사용 허용
--allow-worker: 워커 스레드 허용
--allow-wasi: WASI 모듈 허용
--allow-addons: 네이티브 애드온 허용
어디에 유용한가? 서드파티 패키지를 많이 쓰는 환경에서 의도치 않은 파일 접근이나 네트워크 요청을 차단하는 데 쓸 수 있다. 공급망 공격(supply chain attack) 대응의 추가 레이어로 활용 가능하다. 컨테이너 환경에서는 seccomp 프로파일과 함께 적용하면 방어 계층이 두터워진다.
ⓒ Node.js
Undici 7 · URLPattern · .env 안정화 — 실무에서 달라지는 점
Undici 7 (내장 HTTP 클라이언트)
Node.js에 내장된 HTTP 클라이언트 라이브러리인 Undici가 버전 7로 업그레이드됐다. 가장 큰 변화는 WebSocketStream 지원이다. 기존 ws 패키지 없이 표준 Streams API를 통해 웹소켓을 처리할 수 있다.
Undici 7 WebSocketStream — 추가 패키지 없이 웹소켓
import { WebSocket } from 'node:net'; // Node.js 24 내장
// 또는 Undici WebSocketStream 사용
import { WebSocketStream } from 'undici';
const ws = new WebSocketStream('wss://echo.example.com');
const { readable, writable } = await ws.opened;
const writer = writable.getWriter();
await writer.write('안녕하세요');
for await (const chunk of readable) {
console.log('수신:', chunk);
}
URLPattern 전역 객체
URL 패턴 매칭을 위한 URLPattern이 전역 객체로 추가됐다. 기존에는 브라우저에서만 네이티브로 지원됐고 Node.js에서는 폴리필이 필요했다.
.env 파일 네이티브 지원 안정화
--env-file 플래그가 안정화됐다. dotenv 패키지 없이 환경변수를 로드할 수 있다. 다만 변수 보간(interpolation)이나 복잡한 기능은 지원하지 않으므로, 기존 dotenv를 쓰는 프로젝트는 기능 확인 후 전환 여부를 결정해야 한다.
V8 13.6 업그레이드
자바스크립트 엔진이 V8 13.6으로 올라갔다. Iterator 헬퍼 메서드(map, filter, take 등)가 네이티브 지원되고, 정규표현식 패턴 수정자((?i:...) 형태)가 추가됐다.
22 → 24 마이그레이션 시 주요 변경 사항 — 무엇이 깨질 수 있나
Node.js 22에서 24로 올릴 때 가장 많이 문제가 생기는 영역 네 가지를 정리한다.
1. require()와 ES 모듈 인터롭 변화
require()로 .mjs 파일이나 "type": "module"인 패키지를 가져오는 동작이 Node.js 23에서 실험적으로 허용됐고 24에서 안정화됐다. 이로 인해 CJS/ESM 경계에서의 동작이 이전 버전과 미묘하게 달라질 수 있다. 특히 dual-package 구조(CJS와 ESM을 함께 제공하는 패키지)를 쓸 때 어떤 엔트리포인트가 선택되는지 확인해야 한다.
2. crypto.createCipher / createDecipher 제거
오래전부터 지원 중단(deprecated)됐던 crypto.createCipher와 crypto.createDecipher가 Node.js 24에서 완전히 제거됐다. 이를 사용하는 코드는 crypto.createCipheriv와 crypto.createDecipheriv로 교체해야 한다. 교체 시 IV(초기화 벡터)를 명시적으로 관리해야 한다는 점에 주의한다.
3. url.parse() 하드 지원 중단
url.parse()가 런타임 경고를 발생시킨다. new URL()로 교체하면 된다. 두 API의 동작 차이(특히 상대 URL 처리, 유효하지 않은 URL 처리 방식)를 사전에 확인해야 한다.
4. 네이티브 애드온 재컴파일
V8 버전이 올라가면서 네이티브 C++ 애드온(.node 파일)이 Node.js 24용으로 재컴파일돼야 한다. bcrypt, sharp, canvas 등 네이티브 모듈을 쓰는 프로젝트는 해당 패키지가 Node.js 24를 지원하는지 확인해야 한다. 대부분의 주요 패키지는 이미 지원하지만, 오래된 패키지나 직접 작성한 네이티브 모듈은 확인이 필요하다.
Q. Node.js 24에서 타입스크립트를 플래그 없이 실행한다는 게 ts-node를 완전히 대체할 수 있다는 뜻인가요?
완전한 대체는 아닙니다. Node.js 24의 타입 스트리핑은 타입 정보를 제거만 하고 검사는 하지 않습니다. enum, namespace, 구형 데코레이터는 지원하지 않습니다. ts-node나 tsx가 제공하는 소스맵, 타입 검사, tsconfig 통합 등의 기능도 없습니다. 단순 스크립트나 소규모 서버에는 충분하지만, 복잡한 타입스크립트 프로젝트에는 여전히 별도 도구가 필요합니다.
Q. Node.js 20 LTS를 쓰고 있는데 22를 거쳐야 하나요, 24로 바로 올려야 하나요?
Node.js 20 LTS의 지원 종료(EOL)는 2026년 4월입니다. 이미 지났거나 임박했다면 22를 거치지 않고 24로 바로 올리는 것을 권장합니다. 20 → 24 직접 마이그레이션 시 변경 사항이 많지만, 두 번 올리는 것보다 한 번에 처리하는 것이 전체 작업량은 적습니다. 단, 변경 사항 목록은 Node.js 공식 마이그레이션 가이드에서 v20 → v22, v22 → v24를 모두 확인해야 합니다.
Q. npm 11로 업그레이드됐는데 기존 package-lock.json은 재생성해야 하나요?
반드시는 아니지만 권장합니다. npm 11은 lock 파일 형식을 일부 업데이트했습니다. node_modules를 삭제하고 npm install을 다시 실행하면 자동으로 최신 형식으로 재생성됩니다. 팀 프로젝트라면 같이 업데이트해 커밋하는 것이 좋고, 재생성 후 의존성 트리가 변경됐는지 git diff package-lock.json으로 확인하세요.
Q. 권한 모델(Permission Model)을 도커 컨테이너 환경에서도 써야 하나요?
도커는 이미 네임스페이스와 seccomp 프로파일로 격리를 제공하므로 중복처럼 보일 수 있습니다. 하지만 컨테이너 내부에서 여러 Node.js 프로세스가 동작하거나 서드파티 패키지가 예상치 못한 파일 접근을 하는 경우, Node.js 권한 모델은 추가 방어 계층이 됩니다. 특히 공급망 공격에서 악성 패키지가 환경변수나 설정 파일을 읽는 행위를 차단하는 데 효과적입니다.
Q. Vercel에서 Node.js 24로 자동 전환되나요?
버셀(Vercel)은 새 프로젝트에 Node.js 24를 기본값으로 적용합니다. 기존 프로젝트는 package.json의 engines.node 필드를 확인하거나, Vercel 대시보드의 Settings → General → Node.js Version에서 명시적으로 변경해야 합니다. 런타임 버전을 올린 후에는 반드시 프리뷰 배포에서 동작을 확인한 뒤 프로덕션에 반영하세요.
Q. URLPattern이 전역 객체로 추가됐다는데, 기존에 쓰던 urlpattern-polyfill 패키지를 제거해도 되나요?
Node.js 24 이상을 타깃으로 하는 프로젝트라면 제거해도 됩니다. 다만 더 낮은 버전의 Node.js나 구형 브라우저를 함께 지원해야 한다면 폴리필을 유지해야 합니다. 제거 전 URLPattern을 사용하는 모든 코드에서 동작을 테스트하세요 — 공식 명세와 폴리필 구현 사이에 미묘한 차이가 있을 수 있습니다.