인기 npm 패키지들을 대체하는 최신 Node.js 내장 기능들

• 최근 Node.js는 기존에 npm 패키지로만 가능했던 기능들을 런타임에 내장하며 빠르게 발전 중임
• 이를 통해 공급망 보안 리스크 감소, 코드 이식성 향상, 의존성 축소, 유지보수 간소화가 가능하게 하고, 프로덕션 환경에서 성능과 안정성을 확보하는 데 기여
• fetch(), WebSocket, node:test 등 글로벌 API가 추가되어 node-fetch, ws, mocha 같은 유명 패키지 없이도 개발 가능
• 파일 시스템 기능 확장으로 glob, rimraf, mkdirp 등을 대체하는 fs.glob(), fs.rm(), fs.mkdir() 옵션 제공
• 유틸리티 및 암호화 API에서 crypto.randomUUID(), util.styleText(), atob/btoa 등이 표준으로 포함되어 uuid, chalk 같은 패키지 불필요
• 일부 기능(node:sqlite, URLPattern, --env-file, TypeScript 실행 등)은 아직 실험적 단계에 머물러 있음
• Node.js의 자체 진화로 인해 기본 런타임만으로도 현대적 애플리케이션 개발이 가능해진다는 점이 중요함

---

Node.js의 내장 기능으로 대체된 주요 npm 패키지

• Node.js는 그동안 HTTP 유틸리티, 파일 시스템 헬퍼 등 다양한 npm 패키지에 의존해왔음
• 그러나 최근 버전(v18~v22)에서 이러한 기능을 점차 런타임에 직접 통합하는 흐름이 강화됨
• 이로 인해 패키지 관리의 복잡성과 보안 노출 위험이 줄어드는 효과가 있음

1. node-fetch → Global fetch()

• Node.js 18부터 브라우저와 동일한 fetch() 가 전역 함수로 제공됨
• node-fetch 없이도 HTTP 요청 처리 가능
• v17.5.0에서 실험적으로 도입되어 v18.0.0에서 안정화
• 단, 18 이전 버전에서는 여전히 node-fetch 필요

2. ws → Global WebSocket

• Node.js 21부터 글로벌 WebSocket 클래스로 클라이언트 측 WebSocket 연결 지원
  • v21.0.0에서 실험적으로 추가, 현재까지 실험 단계
• 서버 측 WebSocket 구현에는 여전히 ws 패키지나 관련 라이브러리 사용 필요

3. 테스트 프레임워크 → node:test

• Node.js 18부터 mocha, jest 등을 대체하는 내장 테스트 러너 node:test 제공
  • v18.0.0에서 실험적으로 도입, v20.0.0에서 안정화
  • 기본적인 단위 테스트 작성 및 실행 지원
• 스냅샷, 모킹, 풍부한 플러그인 등이 필요한 경우 서드파티 프레임워크가 여전히 유용
  • 모듈 수준 테스트에는 충분하나, 풀스택 애플리케이션 개발에는 기존 프레임워크 장점 존재

4. sqlite3 / better-sqlite3 → node:sqlite

• Node.js에서 SQLite 접근을 위한 실험적 node:sqlite 모듈 도입 중
  • 기존 네이티브 바인딩 패키지의 컴파일 문제 및 업그레이드 시 오류 해결
  • 메모리 내 데이터베이스 생성, 테이블 생성 등 기본 작업 지원
• 아직 실험 단계이므로, 고급 성능 튜닝이나 추가 기능이 필요하면 커뮤니티 패키지 사용 권장

5. chalk / kleur → util.styleText()

• Node.js 20.12.0부터 util.styleText()로 콘솔 텍스트 스타일링 가능
  • v22.17.0에서 안정화
  • 색상, 굵게, 밑줄 등 기본적인 텍스트 스타일 적용
• 복잡한 테마, 체이닝 문법, 하위 호환성이 필요하면 chalk등을 계속 사용 가능

6. strip-ansi → util.stripVTControlCharacters()

• ANSI 이스케이프 코드 제거 기능을 Node.js 내장 함수로 제공
  • 로그에서 제어 문자를 안전하게 제거
• 대부분의 사용 사례를 네이티브로 커버하여 서드파티 패키지 불필요

7. glob → fs.glob()

• Node.js 22부터 파일 패턴 검색을 위한 내장 fs.glob() 기능 추가
  • v22.0.0에서 추가, v22.17.0 LTS에서 안정화
  • **/*.js 같은 glob 패턴으로 파일 검색
• 구버전 Node.js 호환성이 필요한 경우 glob 패키지 사용

8. rimraf → fs.rm({ recursive: true })

• 디렉토리 재귀 삭제를 Node.js 네이티브 API로 지원
  • fs.rm()의 recursive, force 옵션으로 구현
  • v12.10.0경부터 사용 가능, 현재 모든 LTS 버전에서 안정화
• rimraf 패키지 없이도 안전한 디렉토리 삭제 가능

9. mkdirp → fs.mkdir({ recursive: true })

• 디렉토리 재귀 생성을 fs.mkdir()의 recursive 옵션으로 제공
  • v10.12.0부터 추가되어 오랜 기간 안정화
• 별도 패키지 없이 중첩 디렉토리 생성 가능

10. uuid → crypto.randomUUID()

• Node.js 14.17.0부터 UUID 생성 함수 crypto.randomUUID() 제공
  • 암호화 모듈의 안정적인 기능으로 포함
• uuid 패키지 없이 안전한 랜덤 ID 생성 가능

11. base64-js / atob → atob, btoa

• Node.js 20부터 atob, btoa 글로벌 함수 제공
  • 브라우저와 동일한 Base64 인코딩/디코딩 API
  • 기존 Buffer 외에 추가 옵션 제공
• 폴리필 없이 Base64 처리 가능

12. url-pattern → URLPattern

• Node.js 20부터 글로벌 URLPattern API 실험적으로 제공
  • 라우트 매칭, 경로 파라미터 추출 등 지원
  • 아직 실험 단계로 안정화 필요
• URL 패턴 매칭을 표준 Web API로 처리 가능

13. dotenv → --env-file 플래그

• Node.js 20.10.0부터 --env-file 플래그로 환경 변수 로딩 지원
  • 실행 시 .env 파일을 직접 로드
  • 아직 실험 단계
• 변수 확장, 다중 env 파일 등 고급 기능은 dotenv 패키지 필요

14. event-target-shim → EventTarget

• Node.js 15.0.0부터 Web 표준 EventTarget 이벤트 시스템을 글로벌로 제공
  • v15.4.0에서 안정화
  • 브라우저와 동일한 이벤트 처리 모델 지원
• EventEmitter 대안으로 사용 가능

15. tsc → Node.js TypeScript 실행

• Node.js 21부터 --experimental-strip-types 플래그로 .ts 파일 직접 실행 가능
  • 타입 제거만 수행, 전체 타입 체킹은 미지원
  • 아직 실험 단계
• 프로덕션 빌드, 정적 타입 검사, 선언 파일 생성, 완전한 타입 체킹에는 여전히 tsc 필요

결론

• Node.js의 발전 방향은 외부 패키지 의존도를 줄이고 플랫폼 자체 완성도를 높이는 것
• 최신 LTS 버전(v22)에서는 이미 많은 npm 패키지가 불필요해졌으며,
  이는 보안·성능·유지보수성 측면에서 큰 개선을 의미함
• 기업용 운영 환경에서는 이러한 변화를 실시간으로 모니터링하기 위해 N|Solid 같은 솔루션이 활용되고 있음
  • 내장 기능(fetch, node:test, crypto.randomUUID() 등)의 실제 워크로드 성능 분석
  • N|Sentinel AI 에이전트가 사용량 모니터링 및 코드 수준 최적화 권장 사항 제공

[nemorize]

런타임이 제공하는 API가 점점 더 늘어난다..
특히 그게 네트워크 api, url, b64등 문자열 처리 api 등등이다...

이거 완전... PH..

[carnoxen]

Uuid v7은 아직 시기상조인가 보군요

[click]

db driver는 다른 기본 라이브러리에 들어가야할 기능들과는 다른 관점에서 봐야한다고 생각하는데 bun도 그렇고 sqlite 드라이버를 런타임에 내장하려고 하는 이유가 뭘까요?
python이 내장하고 있어서일까요?

sqlite 기능을 내장할 게 아니라 db driver 인터페이스 표준을 만드는 게 더 중요하다고 생각해요
드라이버별로 인터페이스가 달라서 다기종 db 지원하려면 orm 안쓰고서는 어려운 게 문제지 않나요

[aer0700]

개인 블로그 정도의 소규모 서비스는 그냥 sqlite로 충분한 경우가 많아서 넣은 게 아닌가 싶네요. 있으면 편하죠.

[tujuc]

제 생각은 sqlite가 인터페이스가 가장 간단하고 참고하기 좋은 레퍼런스가 되는거라 생각해서 넣은거같아요.

그리고 말씀하신 DB Driver 인터페이스 표준을 왜 만들어줘야하는지는 모르겠네요. 비슷한건 PHP에서 본거같은 기억이 있긴합니다.

ORM에서 처리할 수 없는 복잡한 쿼리들은 아직도 RAW 쿼리를 사용하고 있어서...
다기종 DB를 쓰실일이 많으신가보군요... 라이브러리를 만들어보시는건 어떠세요? :)

[click]

python, java, c#, go 등등 런타임이 db driver 인터페이스 표준을 만들어주는 경우는 꽤 보편적입니다.
하지만 node는 당장 동일한 sqlite 대상 드라이버끼리도 statement 실행이 execute() 혹은 exec()으로 달라서 드라이버만 갈아끼우는데도 어느정도 수정해야하죠.

자주 있는 일은 아니지만 db 변경하는 경우도 불편하긴 해요.
mysql 쓰다가 오라클이 하는 게 마음에 안든다던지 아님 postgresql 확장 중에 꼭 필요한게 있다던지 해서 postgresql로 넘어간다고 가정했을 때
jdbc같이 표준 인터페이스 있는 경우는 sql만 검증하면 되는데 node진영은 db 호출 로직을 다 갈아엎어야하는 부작용이 있습니다.

+라이브러리를 만들어보라고 추천해주셨는데 공통 인터페이스 표준이 있어야 라이브러리 만들 때 편하더라고요.
회사는 java 쓰는데 사내 자체 프레임워크에서 mysql, db2, oracle, mssql 지원해야해서 db별 어댑터 유지보수 할 때 jdbc 표준의 덕을 많이 봤어요