2026년 가장 빠른 Node.js 패키지 관리자, Aube란 무엇일까요?

수년간 Node 설치는 느렸습니다. `npm install`을 실행하고 커피 머신으로 걸어갔다가 돌아오면, CI는 여전히 `@types/node`를 해결 중입니다. Aube가 이 상황을 바꿉니다. 실제 1,400개 패키지 프로젝트의 웜 CI 설치를 139밀리초 만에 완료하며, 이는 동일한 환경에서 pnpm보다 약 7.3배, Bun보다 3배 빠릅니다. 정말 흥미로운 점은 기존 록 파일을 읽고 쓴다는 것입니다. 따라서 아무에게도 마이그레이션을 요청할 필요 없이 월요일부터 바로 사용해 볼 수 있습니다.

이 가이드에서는 Aube가 무엇인지, 어떻게 이러한 수치를 달성하는지, 설치 방법, pnpm, npm, yarn, Bun과의 비교, 그리고 Apidog와 같은 도구로 매일 API를 구축하는 경우 Aube가 어떻게 활용될 수 있는지 다룹니다.

버튼

Aube는 무엇인가요?

Aube는 en.dev가 구축하고 MIT 라이선스 하에 출시한 빠른 Node.js 패키지 관리자입니다. 이 이름은 프랑스어로 '새벽'을 뜻하며 '오브'로 발음됩니다. 이 프로젝트는 베타 버전(작성 시점 기준 v1.0.0-beta.10)이며, pnpm v11과의 호환성을 목표로 합니다.

핵심은 간단합니다. Aube는 pnpm과 동일한 온디스크 모델(전역 콘텐츠 주소 지정 저장소와 격리된 심링크 레이아웃)을 사용하지만, 설치 파이프라인은 JavaScript 대신 네이티브 스레드 언어로 작성되었습니다. 동일한 레이아웃, 더 빠른 엔진. 이 단일 설계 선택 덕분에 여러 벤치마크 시나리오에서 Bun보다 우위를 점하면서도 `pnpm-lock.yaml`을 제자리에 다시 쓸 수 있습니다.

패키지 관리자 간 마이그레이션을 한 번이라도 해봤다면, 실제 비용은 도구가 아니라 팀원 모두가 `install`을 실행하는 방식을 변경해야 하는 사회적 비용이라는 것을 알 것입니다. Aube는 `pnpm-lock.yaml`, `package-lock.json`, `npm-shrinkwrap.json`, `yarn.lock`, `bun.lock`을 직접 읽어 이러한 문제를 우회합니다. CI가 여전히 pnpm을 사용하는 동안 로컬에서 Aube를 실행할 수 있으며, 팀원들에게는 아무것도 바뀌지 않습니다.

Aube 벤치마크: "가장 빠르다"는 얼마나 빠른가요?

벤치마크 환경은 hyperfine으로 측정된 약 1,400개 패키지의 실제 프로젝트입니다. 모든 시나리오는 커밋된 록 파일을 가정합니다. 변화하는 축은 캐시의 '따뜻함'입니다: 웜(warm)은 `node_modules`를 지우지만 전역 저장소와 패키지 문서 캐시를 유지하고, 콜드(cold)는 모든 것을 지웁니다.

공식 벤치마크(aube 1.0.0-beta.3, bun 1.3.12, pnpm 10.33.0, npm 11.12.1, yarn 1.22.22, node 24.15.0)의 수치입니다:

시나리오	aube	bun	pnpm	yarn	npm
CI 설치 (웜 캐시, node_modules 없음)	139ms	416ms	1.01s	2.43s	2.78s
CI 설치 (콜드 캐시, node_modules 없음)	1.12s	935ms	1.57s	6.60s	4.21s
`install && run test` (이미 설치됨)	21ms	42ms	453ms	351ms	615ms
의존성 추가 (`add is-odd`)	209ms	414ms	1.33s	2.55s	2.89s

몇 가지 눈에 띄는 점이 있습니다. 웜 CI 설치는 실제 파이프라인에서 가장 흔한 경우(러너가 캐시를 복원하고 전역 저장소에 모든 tarball이 해시되어 있는 경우)를 반영하기 때문에 핵심 수치입니다. 이 시나리오에서 Aube는 pnpm보다 약 7.3배, Bun보다 3배 빠릅니다.

`install && run test` 시나리오는 개발자의 일상적인 반복 작업을 측정합니다. 모든 도구는 "먼저 설치한 다음 스크립트를 실행해야 하는가?"를 결정해야 합니다. Aube는 설치 상태 파일이 최신 상태일 때 설치 작업을 완전히 건너뛸 수 있으므로, 전체 `install && test` 루프가 21ms만에 완료됩니다. 다른 도구들은 스크립트를 실행하기 전에 록 파일을 다시 검증하는데, 여기서 400ms-600ms의 오버헤드가 발생합니다.

콜드 캐시에서는 Bun이 Aube를 약간 앞섭니다(935ms vs 1.12s). Bun의 tarball 가져오기 경로가 매우 잘 최적화되어 있고, 콜드 설치는 I/O에 의해 좌우되기 때문입니다. 웜 시나리오는 일반적인 개발팀에서 하루에 수천 번 실행되는 반면, 콜드 시나리오는 러너를 완전히 지울 때 한 달에 한 번 실행됩니다.

전체 테스트 세트에서 문서에 따르면 시나리오에 따라 pnpm보다 최대 22배, Bun보다 최대 3배 빠른 최고 성능을 보입니다. Aube 저장소에서 `mise run bench`를 사용하여 이 모든 것을 로컬에서 재현할 수 있습니다.

Aube가 pnpm과 Bun보다 빠른 이유

세 가지 설계 선택이 핵심적인 역할을 합니다.

네이티브 스레드 설치 파이프라인. npm, pnpm, yarn은 모두 Node.js에서 설치 엔진을 실행합니다. 이는 모든 해시, 모든 tarball 추출, 모든 심링크 호출이 JavaScript 디스패치 비용을 지불해야 한다는 것을 의미합니다. Aube는 핫 패스(hot path)를 V8에서 네이티브 컴파일된 네이티브 스레드 런타임으로 옮깁니다. Bun도 유사하게 동작하지만, 패키지 관리자와 함께 전체 JavaScript 런타임을 제공합니다. Aube는 설치 경로에 특화되어 구축되었으며, 이것이 웜 설치에서 Bun을 능가하는 이유 중 하나입니다.
전역 가상 저장소가 기본값입니다. pnpm v11은 `enableGlobalVirtualStore`를 추가했지만, 프로젝트 설치의 기본값은 아닙니다. Aube는 전역 가상 저장소를 기본값으로 사용하므로, 중복되는 의존성을 가진 반복 프로젝트들은 대부분 디스크에 이미 존재하는 패키지 트리에 링크됩니다. 모두 React, Vite, TypeScript, Playwright를 사용하는 세 개의 서비스가 있다면, 무거운 파일들은 한 곳에 저장되고 모든 프로젝트가 그곳으로 심링크됩니다. 문서에 따르면 일반적인 모노레포 설정에서 npm보다 약 90% 적은 디스크 공간을 사용합니다.
최신 상태 파일로 설치 단축(short-circuiting). `aube run test`는 먼저 압축된 설치 상태 파일을 확인합니다. `package.json`과 록 파일 해시가 상태 파일과 일치하면, 설치 단계는 단일 stat 호출로 끝나고 테스트가 즉시 실행됩니다. 이것이 `install && test` 시간을 21ms로 단축시키는 요인입니다.

이 모든 것이 마법은 아닙니다. 이것은 pnpm 레이아웃을 가져와 JavaScript 부트스트랩을 제거하고, 99%의 설치가 "실제로 변경된 것이 없음"이라는 가정을 중심으로 CLI를 설계할 때 얻을 수 있는 결과입니다.

Aube 설치 방법

권장되는 방법은 다국어 도구 관리자인 mise입니다.

mise use -g aube

`PATH`에 잘 설치되었는지 확인합니다:

aube --version

npm을 선호하는 경우:

npm install -g @endevco/aube

Homebrew를 사용하는 macOS 또는 Linux에서는 Endev 탭에 있습니다:

brew install endevco/tap/aube

프로젝트 내에서 Aube 버전을 로컬로 고정할 수 있습니다:

mise use aube

이것은 `mise.toml`에 `aube`를 도구로 작성하며, 이는 프로젝트 폴더에 진입하는 모든 셸이 동일한 버전을 사용한다는 것을 의미합니다. 더 이상 "작년에 pnpm 10을 설치했기 때문에 내 컴퓨터에서는 작동해요"라는 말은 없어집니다. 설치 문서에는 tarball 및 OS별 옵션도 포함되어 있습니다.

실제로 사용하게 될 일상 명령어

명령어 인터페이스는 pnpm과 매우 유사하므로, 기존의 근육 기억을 그대로 활용할 수 있습니다:

aube install              # 의존성 설치
aube add react            # 의존성 추가
aube add -D vitest        # 개발 의존성 추가
aube remove react         # 의존성 제거
aube update               # package.json 범위 내에서 업데이트
aube run build            # package.json 스크립트 실행
aube test                 # 테스트 스크립트 실행, 오래되었다면 먼저 설치
aube exec vitest          # 로컬 바이너리 실행
aube dlx cowsay hi        # 일회성 환경에서 패키지 실행
aube ci                   # CI를 위한 클린, 고정 설치

대부분의 명령어를 단축할 수 있습니다. 스크립트가 `package.json`에 존재한다면, `aube dev`는 `aube run dev`와 동일합니다. 또한 동일한 바이너리에 두 개의 멀티콜 심(shim)이 포함되어 있습니다:

aubr build       # aube run build
aubx cowsay hi   # aube dlx cowsay hi

파이프라인에서 `aube ci`를 사용하세요. 이것은 `node_modules`를 제거하고, 현재 `package.json`에 대해 록 파일이 최신 상태인지 확인한 다음 설치를 수행합니다. 록 파일이 변경되었다면, CI에서 원하는 대로 명확하게 실패합니다.

록 파일 호환성

이것이 Aube를 위험 부담이 적은 도입으로 만드는 기능입니다. 팀 전체를 전환해야 할 필요가 없습니다.

록 파일	읽기	제자리 쓰기
`aube-lock.yaml`	예	예
`pnpm-lock.yaml` v9	예	예
`package-lock.json` v2/v3	예	예
`npm-shrinkwrap.json`	예	예
`yarn.lock` (v1 classic + v2+ berry)	예	예
`bun.lock`	예	예

실용적인 패턴은 다음과 같습니다. 당신의 팀은 pnpm을 사용합니다. CI는 여전히 `pnpm install --frozen-lockfile`을 실행합니다. 당신은 자신의 컴퓨터에서 로컬로 `aube install`을 실행합니다. Aube는 `pnpm-lock.yaml`을 읽고, 동일한 `node_modules` 레이아웃을 생성하며, 모든 해결 업데이트를 동일한 `pnpm-lock.yaml`에 다시 씁니다. 팀원이 당신의 브랜치를 풀하고 `pnpm install`을 실행해도 아무런 문제가 없습니다. 시간이 지남에 따라 Aube가 유용함이 입증되면 CI를 마이그레이션합니다. 그렇지 않다면, Aube를 제거해도 하위 시스템에서는 아무것도 알 수 없습니다.

두 가지 주의사항. 오래된 pnpm v5 또는 v6 록 파일은 먼저 pnpm으로 업그레이드해야 합니다. 그리고 Yarn PnP 프로젝트(`.pnp.cjs` 스타일)는 Aube를 시도하기 전에 `nodeLinker: node-modules` 모드로 다시 전환해야 합니다. Aube는 PnP 아티팩트가 아닌 `node_modules`를 작성하기 때문입니다.

기본 보안 설정은 생각보다 중요합니다

지난 18개월 동안 JavaScript 코드베이스 주변에 있었다면, 공급망 사고가 누적되는 것을 보셨을 것입니다. npm 공급망 보안 가이드는 이러한 패턴을 다루고 있으며, Axios npm 침해 사건은 단 하나의 인기 있는 의존성이 수천 대의 개발자 컴퓨터에 크로스 플랫폼 RAT를 배포할 수 있음을 보여준 가장 명확한 실제 사례 중 하나였습니다.

Aube는 설치를 편의성이 아닌 보안 경계로 취급하는 세 가지 독자적인 기본 설정을 제공합니다:

최소 릴리스 수명. 새로운 릴리스는 Aube가 설치하기 전에 구성 가능한 최소 수명 동안 기다립니다. 두 시간 만에 제거되는 새로 손상된 패키지는 `node_modules`에 결코 영향을 미치지 않습니다.
특이한 의존성 차단. Aube는 모양이 의심스러운 전이 의존성(비정상적인 URL, 패치와 유사한 항목, 일반적으로 semver를 사용하는 곳에 Git ref 등)을 차단합니다. 명시적으로 원하는 경우 승인할 수 있습니다.
라이프사이클 스크립트 승인. 의존성 `postinstall` 스크립트는 기본적으로 건너뜁니다. 특정 패키지(esbuild, node-sass, 로컬에서 실제로 빌드해야 하는 모든 것)를 허용하려면 `aube approve-builds`를 실행합니다. 스크립트가 건너뛴 패키지는 `aube ignored-builds`에 나타납니다.

이 세 가지 동작이 당신을 무적으로 만들지는 않지만, "그 패키지가 코드를 실행하는 줄도 몰랐다"는 것을 "내가 그 패키지가 코드를 실행하도록 선택했다"로 바꿉니다. 이것은 다음 프로덕션 사고 전에 원하는 보안 태세입니다.

Node 모듈 레이아웃

Aube는 격리된 `node_modules` 레이아웃을 사용합니다. 최상위 `node_modules/`에는 `package.json`에 선언된 의존성이 포함됩니다. 전이 의존성은 `node_modules/.aube/` 뒤에 위치합니다. 패키지 파일 자체는 `$XDG_DATA_HOME/aube/store/`에 한 번만 저장되며, 기본값은 `~/.local/share/aube/store/`입니다.

세 가지 결과:

중복되는 의존성을 가진 여러 프로젝트가 디스크에서 패키지 파일을 공유합니다. 더 이상 "내 모노레포와 사이드 프로젝트에 lodash가 12개 복사되어 있어"라고 말할 필요가 없습니다.
팬텀 의존성 문제는 더 어려워집니다. 패키지가 `package.json`에 없다면, `node_modules/`에 없기 때문에 최상위 레벨에서 `require`할 수 없습니다. 이것은 pnpm이 제공하는 것과 동일한 보장입니다.
반복 설치는 디스크에 이미 있는 파일을 재사용합니다. 남은 유일한 작업은 저장소에서 새 `node_modules/.aube/`로 하드 링크하는 것입니다.

이전에 플랫 `node_modules` 레이아웃(고전적인 npm 또는 yarn v1)을 사용했다면, 팬텀 임포트에 의존하여 깨진 패키지를 한두 개 발견할 수 있습니다. 해결책은 항상 "`package.json`에 추가하세요"입니다.

워크스페이스와 모노레포

Aube는 워크스페이스와 `workspace:` 프로토콜을 지원합니다:

aube install -r
aube run test -r
aube add zod --filter @acme/api

만약 당신의 저장소에 이미 `pnpm-workspace.yaml`이 있다면, Aube는 이를 읽고 씁니다. 새로운 Aube 우선 워크스페이스는 `aube-workspace.yaml`을 사용합니다. `-r` (재귀) 및 `--filter` 플래그는 pnpm에서 예상하는 것과 동일한 의미로 매핑되므로, turborepo 및 nx 설정은 변경 없이 계속 작동합니다.

API 모노레포의 경우, 웜 캐시 CI 수치가 가장 중요합니다. 파이프라인이 병합될 때마다 `install, build, test, publish contract`를 수행한다면, pnpm의 1초였던 `install` 시간을 Aube의 139밀리초로 10개 패키지에 걸쳐 단축하는 것은 하루에 실제 몇 분을 절약하는 결과를 가져옵니다.

API 개발 워크플로우에서 Aube의 역할

API를 구축하고 테스트한다면, 설치는 모든 리팩토링의 핫 패스에 있습니다. 요청 스키마를 변경하고, TypeScript 클라이언트를 재생성하고, 다시 설치하고, 목 서버에 대해 계약 테스트를 실행하는 과정을 반복합니다. 빠른 설치는 겉치레 지표가 아닙니다. 이는 "내가 이것을 변경했다"와 "문제가 발생했는지 알 수 있다" 사이의 간격입니다.

잘 작동하는 실용적인 루프:

Apidog에서 API를 설계하고 목업합니다. 다른 팀과 소통하는 모든 것에는 코드 우선보다 스키마 우선 방식이 좋습니다.
Node 프로젝트 내에서 타입이 지정된 클라이언트를 생성하거나(또는 Apidog 목업에 대해 계약 테스트를 실행합니다).
클라이언트를 반복 개발하는 동안 로컬에서 Aube를 사용하여 설치 시간을 밀리초 단위로 유지하세요.
동일한 테스트 스위트를 `aube ci`로 CI에 연결합니다.

지난 한 해 동안 Postman에서 벗어나 다른 도구로의 전환은 더 큰 패턴의 일부입니다. 개발자들은 빠르고, 로컬 우선이며, 기본적으로 보안이 강화된 도구를 원합니다. Aube는 설치 단계에 적용된 동일한 이야기입니다. 이미 VS Code 내에서 Apidog를 사용하고 있다면, 그 옆에 Aube를 추가하는 것은 `mise use` 한 줄의 비용으로 모든 핫 리로드에서 몇 초를 절약해 줍니다.

각 패키지 관리자로부터의 마이그레이션

npm에서. 프로젝트에서 `aube install`을 실행합니다. Aube는 `package-lock.json`을 읽고 다시 씁니다. 플랫 대신 격리된 `node_modules`를 얻게 되므로, 팬텀 임포트에 주의하세요. 문제가 발생하면, 누락된 패키지를 `package.json`에 추가하고 진행하세요. 전체 워크플로우는 npm 사용자 가이드를 참조하세요.

pnpm에서. 온디스크 레이아웃이 동일하기 때문에 마찰이 가장 적은 마이그레이션입니다. Aube는 `pnpm-lock.yaml` v9을 직접 읽습니다. `workspace:` 프로토콜이 작동합니다. 필터가 작동합니다. `pnpm 사용자` 페이지에는 다르게 작동하는 몇 가지 플래그가 나열되어 있습니다.

yarn에서. Aube는 v1 classic과 v2+ berry 록 파일 모두를 읽습니다. Yarn PnP 사용자는 Aube를 시도하기 전에 `nodeLinker: node-modules` 모드로 다시 전환해야 합니다. Aube는 `.pnp.cjs`가 아닌 `node_modules`를 작성하기 때문입니다.

Bun에서. Aube는 `bun.lock`을 읽습니다. 주요 차이점은 Bun의 패키지 관리자가 Bun의 JS 런타임과 밀접하게 연결되어 있다는 것입니다. Aube는 모든 Node.js 버전에서 실행되는 독립형 설치 도구입니다. 이미 Node 버전 관리를 위해 mise를 사용하고 있다면, Aube도 동일한 방식으로 적용됩니다.

실제 사용 시 고려사항

베타 상태. 2026년 4월 현재, Aube는 v1.0.0-beta.10입니다. 문서에서는 pnpm v11 호환성을 목표로 하지만 아직 많은 프로젝트에서 테스트되지 않았다고 명시하고 있습니다. 1.0 이전의 모든 도구처럼 다루세요. 먼저 로컬에서 실행하고, 기존 록 파일을 유지하며, 한 달 동안 작동하는 것을 확인하기 전까지는 프로덕션 릴리스 파이프라인에 의존하지 마세요.

범위 밖. Aube는 mise가 이미 수행하는 기능을 의도적으로 중복하지 않습니다. 런타임 관리(`env`, `runtime`, `setup`, `self-update`)는 mise에 속합니다. 일부 레지스트리 계정 도우미(`whoami`, `token`, `owner`, `search`, `pkg`, `set-script`)는 npm 명령을 가리키는 호환성 스텁입니다. CI 스크립트가 이러한 명령어를 호출한다면, npm을 대체 수단으로 유지하세요.

플랫폼 지원. 권장 설치 프로그램은 macOS, Linux, WSL을 통한 Windows를 지원하는 mise입니다. tarball을 통한 네이티브 Windows 지원은 존재하지만 초기 단계입니다. 현재 지원 매트릭스는 설치 페이지를 확인하세요.

커뮤니티. 이 프로젝트는 디스코드 채널(홈페이지에 링크됨)을 가지고 있으며, 작성 시점 기준 GitHub에서 325개의 스타를 받았습니다. 작지만 활발합니다. Buildkite는 프로젝트의 CI를 제공하며, 이는 저장소 루트에서 확인할 수 있습니다.

자주 묻는 질문

"aube"는 무슨 뜻인가요?프랑스어로 새벽입니다. '오브'라고 발음합니다. 프로젝트의 슬로건은 "Node 설치의 새로운 새벽"입니다.

Aube는 pnpm의 완벽한 대체품인가요?거의 그렇습니다. pnpm v11 호환성을 목표로 하며 pnpm의 록 파일 형식을 읽습니다. 대부분의 pnpm 방식 워크플로우는 변경 없이 전환됩니다. 일부 pnpm 명령어(런타임 관리, 몇몇 레지스트리 도우미)는 다른 도구에 속하기 때문에 의도적으로 범위에서 제외되었습니다.

로컬에서 pnpm을 사용하면서 CI에서 Aube를 사용할 수 있나요?네, 양방향 모두 가능합니다. Aube는 `pnpm-lock.yaml`을 제자리에서 읽고 쓰므로, 두 도구가 록 파일을 공유할 수 있습니다. 팀들은 보통 반대 방향으로 시작합니다: 로컬에서 Aube, CI에서 pnpm을 사용하다가 모든 팀원이 익숙해지면 전환합니다.

Aube는 Bun과 어떻게 비교되나요?웜 설치에서 Aube는 Bun보다 약 3배 빠릅니다. Bun이 설치 전에 더 많은 상태를 재검증하기 때문입니다. 콜드 설치에서는 Bun의 가져오기 경로가 매우 잘 최적화되어 있어 Bun이 약간 앞섭니다. Bun은 JS 런타임을 제공하는 반면, Aube는 설치 전용입니다. 이미 Node를 사용하고 있다면, Aube를 사용하기 위해 Bun의 런타임이 필요하지 않습니다. pnpm 스타일의 격리된 레이아웃 비교는 레이아웃 선택이 중요한 이유에 대한 맥락을 제공합니다.

Aube는 Windows에서 작동하나요?WSL을 통해 작동합니다, 네. 네이티브 Windows도 작동하지만 초기 단계입니다. mise는 세 가지 OS 모두에서 설치 및 업데이트하는 가장 쉬운 방법입니다.

Aube는 오픈 소스인가요?네, MIT 라이선스이며, 소스는 GitHub에 있습니다.

기존 `pnpm-lock.yaml`은 어떻게 되나요?Aube는 이를 읽고 설치를 수행하며, 모든 해결 변경 사항을 포함하여 동일한 파일을 다시 씁니다. pnpm을 실행하는 팀원들은 일반적인 록 파일 차이점을 보게 될 것입니다.

결론

2026년 대부분의 Node 프로젝트에서 설치 단계는 필요 이상으로 느립니다. Aube는 실제 개발 워크플로우를 지배하는 웜 설치 및 반복 명령어 경로에서 가장 빠른 Node.js 패키지 관리자입니다: 1,400개 패키지 CI 설치에 139ms, 변경 사항이 없을 때 `install && test`에 21ms, 여러 프로젝트를 가진 컴퓨터에서 디스크 공간을 90% 덜 사용합니다. Aube는 기존 록 파일을 읽고, 보안 기본 설정을 진지하게 다루며, `mise use aube` 한 번으로 시도해 볼 수 있습니다.

이미 Apidog와 같이 빠르고 로컬 우선인 클라이언트로 API를 테스트하고 있다면, Aube는 설치 측면에서 완벽한 짝입니다. 아직 Apidog를 다운로드하지 않았다면, 다음 Node 서비스에 Aube와 함께 사용해 보세요. 얼마나 피드백 루프가 더 단단해지는지 확인할 수 있을 것입니다.

버튼