# Nub - Node.js용 Bun 유사 올인원 툴킷

> Clean Markdown view of GeekNews topic #30832. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30832](https://news.hada.io/topic?id=30832)
- GeekNews Markdown: [https://news.hada.io/topic/30832.md](https://news.hada.io/topic/30832.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-26T08:33:34+09:00
- Updated: 2026-06-26T08:33:34+09:00
- Original source: [github.com/nubjs](https://github.com/nubjs/nub)
- Points: 2
- Comments: 1

## Topic Body

- **Node.js를 대체하지 않고 보강**하는 올인원 툴킷으로, Rust로 작성되어 표준 `node` 위에서 Bun과 유사한 개발 경험 제공  
- 파일·스크립트 실행, 의존성 설치, Node 버전 관리를 **단일 도구**로 통합, 새로운 런타임·벤더 종속 API·lock-in 없음  
- **File runner** `nub <file>` — `.ts`, `.tsx` 등을 빌드 단계 없이 실행, `node`와 flag-for-flag·var-for-var 호환, `tsx` 대비 2.9× 빠른 startup  
  - Full TypeScript 지원(`enum`, `namespace`), JSX/TSX, Decorators, `.env*` 자동 로딩, `.yaml`·`.toml`·`.json5` 등 내장 loader  
  - 프로젝트가 기대하는 **Node 버전 자동 감지·설치**(`.node-version`, `.nvmrc`, `package.json#engines` 등 참조)  
- **Script runner** `nub run` — `npm/pnpm run`의 drop-in, 자체 JS startup 없는 Rust 바이너리로 `pnpm run` 대비 약 **24× 빠른 dispatch**(14.7ms vs 442.7ms)  
  - `pre`/`post` hook, pnpm workspace `--filter`·`--parallel` 등 전체 지원  
- **Package runner** `nubx` — `npx`·`pnpm dlx`의 drop-in, double-Node-spawn 패널티 제거로 `npx` 대비 약 **19× 빠른 실행**(11ms vs 226ms)  
- **Package manager** `nub install` — Aube 엔진 기반, `pnpm`과 flag 호환, `pnpm` 대비 2.5×·`npm` 대비 3.7× 빠름  
  - **기본 보안 정책** 내장 — postinstall 차단, osv.dev 악성 패키지 검사, provenance downgrade 거부, 24시간 `minimumReleaseAge`  
  - npm/pnpm/Yarn/Bun lockfile·설정을 자동 감지하는 **compat-mode** 동작  
- **Node version manager** `nub node` — 버전 install·ls·uninstall·pin 등 수동 관리 명령 제공  
- **Package meta-manager** `nub pm` — Corepack 역할을 native Rust로 수행, `npm`·`yarn`·`pnpm` 글로벌 shim 등록  
- MIT 라이선스

## Comments



### Comment 60327

- Author: neo
- Created: 2026-06-26T08:33:35+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48660267) 
- 아이디어가 아주 좋고 말이 됨. Bun은 **DB 드라이버** 같은 걸 더 제공하지만, 개발자 경험도 매력의 큰 부분인 건 확실함  
  참고로 Nub의 주 저자는 Zod를 만든 Colin McDonnell이고, 한때 Bun에서도 일했음
  - 맞음. Nub은 의도적으로 **Nub 전용 API**를 전혀 넣지 않음: Nub 전역 객체도, `nub:` 접두사 내장 모듈도, Nub 이름의 설정 파일/잠금 파일도, `package.json`의 `nub` 필드도, `NUB_` 환경 변수도 없음  
    Bun이 추가한 것들 대부분은 제대로 된 의존성으로 두는 편이 더 낫다고 봄

- `--import`가 아니라 **`--require` 훅**을 쓰는 게 의외임. 비슷한 기능을 만들려고 살펴보던 때와 뭔가 크게 달라졌을 수도 있지만, Nub의 ESM 지원에 미묘한 부분이 있지 않을까 싶음  
  당시에는 Node의 `--import`가 아주 초기였고, 흔한 ESM-to-CJS 접근에서 처리하고 싶었던 예외가 여럿 있었음. 대부분은 매우 틈새 사례였겠지만, 최상위 await는 의미 있는 일부 사용자에게 영향을 줄 거라고 봄
  - 이건 순전히 **성능** 때문에 프리로드 등록에 사용함. 이 경우와 다른 많은 경우에서 CommonJS가 여전히 ESM보다 빠름. `--require`는 약 0.5ms 오버헤드인데, `--import`는 M1 Macbook Pro 기준 4.6ms 정도임  
    관련해서 Node.js는 최근 2025년에 예전 비동기 `module.register()` API보다 성능을 높이려고 resolver 훅 등록 API의 동기 버전인 `module.registerHooks()`를 도입했음. Nub에는 큰 장애물 해소였음. 관심 있는 사람을 위해 덧붙이면, 비동기 API는 고정 등록 오버헤드 19ms에 import마다 약 130us의 추가 오버헤드를 더했음  
    여기서 Nub이 어떤 플래그를 쓰는지는 사용자 코드에는 전혀 영향이 없고, 최상위 await는 Node.js 자체가 지원하는 곳에서는 지원됨

- 우리 전체 **모노레포를 nub으로 마이그레이션**하는 PR을 막 머지했음  
  문제 0개였고, 말도 안 되게 빠름
  - 이게 올라온 지 한 시간 안에 공유 모노레포를 이걸로 마이그레이션하는 PR을 머지한 거임?

- Node는 몇 버전 전부터 TypeScript를 실행할 수 있지 않았나? 왜 변환기가 필요한 거지?
  - Node의 내장 TypeScript 지원은 **타입 제거**만 함. TypeScript 문법의 아주 많은 부분에는 통하지만 전부는 아님. 타입을 실제로 검사하지도 않고, 실행되도록 제거만 함. `tsconfig` 같은 것도 잃게 됨  
    이건 내장 제거 방식과 실제 TypeScript 처리를 둘 다 지원하는 것으로 보임
  - Node.js 팀이 Node.js v26에서 `--experimental-transform-types`를 제거했음. 이러면 네이티브 **완전 TypeScript 지원**은 불가능해짐  
    [https://github.com/nodejs/typescript/issues/51#issuecomment-...](<https://github.com/nodejs/typescript/issues/51#issuecomment-4421528927>)
  - `Worker`, `Temporal` 같은 API에 필요하면 **폴리필을 주입**한다고 되어 있음

- README에는 WebSocket 지원이 Node 22부터 네이티브라고 되어 있는데, Node에는 네이티브 WebSocket 라이브러리가 없음. WebSocket 표준 링크는 MDN으로 가는데, 거기는 WHATWG 사용자 인터페이스만 설명하고 프로토콜이나 WebSocket 동작 방식은 설명하지 않음  
  뭔가 빠졌거나, 보조로 **비네이티브 라이브러리**를 쓰는 것처럼 느껴짐
  - Node는 22부터 내장 **WebSocket 클라이언트**를 지원하지만 서버는 지원하지 않음

- 기존 기술을 받아들이고 더 나쁜 버전을 다시 만들지 않는 점은 존중할 만함. 대안 만들기에 들어간 모든 노력이 Node에 갔다면, 적절한 리더십 아래 지금 어디까지 왔을지 궁금함
  - 2014년 Node.js의 **io.js 포크**를 기억할 수도 있음. Node가 정체되자 여러 사람이 io.js로 포크했고, 결국 다시 Node에 병합되어 Node를 제 궤도에 올려놨음. 더 거슬러 올라가면 JS의 “포크”였던 CoffeeScript도 최고의 아이디어들이 ES5로 흡수됐음  
    작고 기민한 팀은 실패가 치명적인 위험이 아니기 때문에 좋은 아이디어를 입증할 수 있음. 짧게 말하면 포크는 건강한 생태계의 일부임
  - 근본적으로 이런 접근으로는 고칠 수 없는 게 많음  
    간단한 예로, Node는 내가 아는 진지한 오픈소스 소프트웨어 중 **설정 파일 안에 설정을 문서화할 방법이 없는** 유일한 것임. 말도 안 됨. Node 쪽은 별생각 없이 JSON을 채택했고, 이후에는 “주석 있는 JSON”조차 포함해 어떤 대안도 검토하길 거부했음  
    조직이 나쁜 결정에 고착되면, 고치는 유일한 방법은 새로 시작하는 것임. 모두가 Node 위에 계속 쌓는 한 JS 생태계 전체는 설정에 문서를 남길 수 없을 것임  
    Node 생태계에는 이런 문제가 여럿 있고, 설정을 문서화할 수 없다는 완전한 부조리는 그냥 내 개인적인 불만 포인트임

- Nub와 마스코트 nubnub의 팬임. 진지하게 말하면 훌륭한 프로젝트고, 꽤 흥미로워서 지난주부터, 적어도 공개된 이후로 계속 써보고 있음

- 똑똑함. 이미 **Rust로 작성**되어 있으면 Rust로 마이그레이션을 바이브 코딩하다가 고객을 전부 잃을 일은 없으니까 ;)
  - OpenAI에 인수된 다음 프로젝트를 Zig로 바꿀 듯
  - 이 프로젝트는 이미 **바이브 코딩** 비중이 큼. 저장소의 두 번째 기여자가 Claude임
  - “이미 Rust로 바이브 코딩되어 있다면”이 더 나을 듯. Nub에서는 전반적으로 그런 냄새가 꽤 남. 괜찮긴 한데 Bun과 비교하니 웃김  
    덧붙이면 Bun의 반 AI 히스테리는 매우 슬프고, 가끔은 조직적인 캠페인처럼 느껴질 때도 있음
  - 애초에 이미 바이브 코딩되어 있고 고객도 없다면 더 도움이 됨
  - 맞음. 여기서 “Rust로 작성”이 뭘 더해주는지는 잘 모르겠음. 같은 기능은 셸 스크립트 몇 개와 `package.json`으로도 가능할 거라고 봤음