Zerobrew: Homebrew보다 최대 20배 빠른 패키지 매니저

Homebrew를 쓰면서 느린 속도 때문에 답답했던 적 있으신가요? brew install 하나 실행했을 뿐인데 몇십 초씩 걸리고, brew update는 아예 커피 한 잔 타올 시간을 주기도 하죠. Homebrew는 macOS 개발 환경의 사실상 표준이지만 Ruby로 작성된 태생적 한계 때문에 성능은 늘 아쉬웠습니다.

Zerobrew는 바로 이 문제를 풀려고 나온 프로젝트입니다. Rust로 작성했고 Homebrew의 패키지 생태계를 그대로 쓰면서도 설치 속도를 5배에서 최대 20배까지 끌어올렸는데요. Python 생태계에서 pip을 대체한 uv가 떠오른다면 맞습니다. Zerobrew는 uv의 접근 방식을 macOS 패키지 관리에 가져온 도구라고 보면 돼요.

이번 글에서는 Zerobrew의 아키텍처부터 살펴보고 실제 설치와 사용법까지 다뤄보겠습니다.

Homebrew의 어디가 느린 걸까?

Zerobrew를 이해하려면 먼저 Homebrew가 왜 느린지 알아야 합니다.

Homebrew는 패키지를 설치할 때 /usr/local/Cellar(또는 Apple Silicon에서는 /opt/homebrew/Cellar)에 버전별 디렉토리를 만들어 저장합니다. 같은 패키지를 삭제했다가 다시 설치하면 이미 다운로드한 적이 있더라도 CDN에서 다시 받아오는 경우가 많고요. 패키지 하나를 설치할 때도 formula 파싱 → 의존성 해석 → 다운로드 → 압축 해제 → 링크까지 모든 과정이 순차적으로 돌아갑니다. Ruby 기반이라 각 단계의 오버헤드도 무시할 수 없고요.

여러 패키지를 한꺼번에 설치할 때는 상황이 더 심각해집니다. 각 패키지를 하나씩 순서대로 처리하니까 시간이 선형으로 늘어나거든요. CI/CD 환경에서 brew bundle로 개발 환경을 셋업할 때면 이 병목이 피부로 느껴집니다.

Zerobrew가 빠른 이유

Zerobrew가 이렇게 빠를 수 있는 건 아키텍처가 근본적으로 다르기 때문입니다.

가장 큰 차이는 Content-Addressable Store(CAS)입니다. Homebrew가 버전별 디렉토리에 패키지를 저장하는 것과 달리 Zerobrew는 /opt/zerobrew/store에 SHA-256 해시 기반으로 패키지를 저장합니다. 한 번 다운로드한 패키지는 해시값으로 식별되기 때문에 삭제 후 재설치할 때 다운로드를 완전히 건너뛸 수 있어요. 해시가 이미 store에 있는지 O(1)으로 확인만 하면 되니까요. Git이 객체를 SHA-1 해시로 관리하는 것과 같은 원리입니다.

여기에 APFS Clonefile이 더해집니다. macOS의 APFS 파일 시스템은 copy-on-write를 지원하는데 Zerobrew는 이걸 잘 활용합니다. 패키지를 store에서 설치 경로로 “복사”할 때 실제 데이터를 복사하지 않고 파일 시스템 레벨에서 참조만 만드는 거예요. 1GB짜리 바이너리도 마이크로초 단위로 처리되고 추가 디스크 공간도 안 잡아먹습니다.

마지막으로 병렬 처리도 빼놓을 수 없습니다. Zerobrew는 Rust의 tokio 비동기 런타임으로 다운로드와 해시 계산, 압축 해제를 동시에 수행해요. Homebrew가 패키지를 하나씩 순차 처리하는 것과 대조적이죠. 네트워크 대역폭과 CPU를 함께 쓰니 여러 패키지를 한꺼번에 설치할 때 차이가 확 벌어집니다.

벤치마크로 보는 성능 차이

말로만 빠르다고 하면 와닿지 않으니 숫자로 확인해 보겠습니다. M3 Max MacBook Pro에서 측정한 결과입니다.

패키지	Homebrew	Zerobrew (Cold)	Zerobrew (Warm)	속도 향상
Top 100 평균	452s	226s	59s	2.0x ~ 7.6x
tesseract	18.9s	5.5s	643ms	최대 29.5x
libsodium	2.3s	392ms	130ms	최대 18.1x
sqlite	2.8s	625ms	159ms	최대 18.1x
python@3.14	10.6s	5.4s	1.5s	최대 6.9x
ffmpeg	3.0s	3.4s	688ms	최대 4.4x

여기서 “Cold”는 store에 캐시가 없는 첫 설치, “Warm”은 이미 한 번 설치한 적 있는 재설치를 의미합니다.

Cold 설치에서도 2배 정도 빠르지만, 진짜 차이가 나는 건 Warm 설치입니다. CAS에 이미 해시가 존재하면 다운로드를 건너뛰고 APFS Clonefile로 즉시 링크하기 때문인데요. tesseract처럼 의존성이 많은 패키지는 29.5배나 빨라집니다.

CI/CD 환경에서 생각해보면 Top 100 패키지 기준 452초가 59초로 줄어드는 건 빌드 파이프라인에서 거의 7분을 아끼는 셈이에요.

설치

Zerobrew 설치는 한 줄이면 끝납니다.

curl -fsSL https://zerobrew.rs/install | bash

이미 Homebrew를 쓰고 있다면 Homebrew를 통해서도 설치할 수 있습니다.

brew tap lucasgelfond/zerobrew && brew install zerobrew

macOS에서는 /opt/zerobrew에, Linux에서는 ~/.local/share/zerobrew에 설치됩니다. 설치가 끝나면 터미널에 표시되는 export 명령어를 실행하거나 터미널을 재시작하면 zb 명령어를 사용할 수 있습니다.

기존 Homebrew 설치를 건드리지 않으니 안심하고 나란히 사용할 수 있습니다. 처음엔 두 가지를 병행하면서 점차 익숙해지는 걸 추천드립니다.

기본 사용법

Zerobrew의 명령어 체계는 Homebrew와 거의 동일합니다. brew 대신 zb를 쓰면 됩니다.

패키지 하나를 설치하려면 이렇게 합니다.

zb install jq

여러 패키지를 한꺼번에 설치할 수도 있습니다.

zb install wget git curl

패키지를 삭제할 때는 uninstall을 씁니다.

zb uninstall jq

설치된 패키지 목록 확인, 업데이트 확인, 업그레이드도 Homebrew와 같은 패턴입니다.

zb list          # 설치된 패키지 목록
zb outdated      # 업데이트 가능한 패키지 확인
zb update        # 패키지 정보 갱신
zb upgrade       # 모든 패키지 업그레이드

출력 형식도 조절할 수 있는데요. --quiet으로 최소한의 출력만 보거나 --verbose로 상세 로그를 확인할 수 있고, --json은 JSON 형식으로 결과를 내보냅니다. 스크립트에서 파싱할 때는 --json이 특히 유용하죠.

Brewfile과 Bundle 관리

Homebrew의 Brewfile을 이미 쓰고 있다면 좋은 소식입니다. Zerobrew는 Brewfile 형식을 그대로 지원합니다.

프로젝트 루트에 Brewfile이 있다면 이 명령어 하나로 모든 패키지를 설치할 수 있습니다.

zb bundle

다른 경로의 파일을 쓰고 싶으면 -f 옵션을 지정합니다.

zb bundle install -f myfile

반대로 현재 설치된 패키지를 Brewfile로 내보낼 수도 있습니다.

zb bundle dump                # Brewfile 생성
zb bundle dump -f out --force # 지정 파일에 덮어쓰기

CI/CD 파이프라인에서 zb bundle을 쓰면 Homebrew 대비 빌드 시간이 크게 줄어듭니다. CAS 캐시를 CI 캐시와 조합하면 Warm 설치 수준의 속도를 얻을 수도 있고요.

일회성 실행과 가비지 컬렉션

패키지를 시스템에 설치하지 않고 한 번만 실행하고 싶을 때가 있습니다. npx나 bunx처럼요. Zerobrew에서는 zbx 명령어로 이걸 할 수 있습니다.

zbx jq --version

이 명령어는 jq를 시스템에 링크하지 않고 store에서 직접 실행합니다. 일시적으로 도구가 필요할 때 편리합니다.

한편 CAS에 패키지가 쌓이다 보면 안 쓰는 항목도 생기겠죠. gc 명령어로 참조되지 않는 store 항목을 정리할 수 있습니다.

zb gc

Git의 git gc와 비슷한 개념입니다. 주기적으로 실행해주면 디스크 공간을 절약할 수 있습니다.

Homebrew에서 마이그레이션

이미 Homebrew로 많은 패키지를 관리하고 있다면 어떻게 옮길 수 있을까요?

zb migrate 명령어를 사용하면 Homebrew에 설치된 패키지를 Zerobrew로 이전할 수 있습니다. v0.2.0부터는 배치 처리도 지원해서 한꺼번에 여러 패키지를 옮길 수 있고요.

다만 공식 문서에서도 강조하는 부분인데 Homebrew를 완전히 삭제하는 건 권장하지 않습니다. 아직 실험적인 프로젝트이고 모든 formula를 완벽하게 지원하지는 않거든요. 두 도구를 나란히 두고 자주 쓰는 패키지부터 Zerobrew로 옮겨가는 방식이 안전합니다.

호환성 문제가 생기면 GitHub Issues에 보고하면 되고, 그동안은 그 패키지만 Homebrew로 계속 관리하면 됩니다.

모든 패키지를 초기화해야 할 때

Zerobrew로 설치한 모든 패키지를 한꺼번에 제거해야 할 때는 reset 명령어를 쓰면 됩니다.

zb reset

깨끗한 상태에서 다시 시작하고 싶을 때 유용합니다. Brewfile을 관리하고 있다면 zb reset 후 zb bundle로 빠르게 복구할 수 있고요.

Linux에서도 쓸 수 있을까?

Zerobrew는 Linux도 지원합니다. 다만 APFS Clonefile은 macOS 전용이기 때문에 Linux에서는 이 최적화가 적용되지 않습니다. 그래도 CAS와 병렬 다운로드는 동일하게 동작하니 Homebrew보다는 여전히 빠릅니다.

Linux에서의 설치 경로는 ~/.local/share/zerobrew이고, 설치 방법은 macOS와 동일합니다. Arch Linux 사용자라면 AUR에서 zerobrew 패키지를 직접 설치할 수도 있습니다.

현재 프로젝트 상태

Zerobrew는 아직 실험적(experimental) 상태입니다. 자주 쓰는 formula는 문제없이 동작하지만 모든 경우를 커버하지는 못해요.

개발 과정도 눈에 띕니다. 초기에는 LLM을 활용한 “vibe coding”으로 프로토타입을 빠르게 만들었는데 2026년 들어서는 엄격한 엔지니어링 거버넌스 모델로 전환했습니다. AI가 생성한 PR은 거절하고 패키지 치환이나 경로 탐색 공격에 대한 보안 위협 모델도 갖추었고요. 패키지 매니저처럼 보안이 중요한 도구에서 이런 방향 전환은 괜찮은 신호라고 봅니다.

라이선스는 Apache 2.0과 MIT 듀얼이고 Discord 커뮤니티에서 활발하게 소통이 이뤄지고 있습니다.

마치며

Zerobrew는 “Homebrew가 느리다”는 오래된 불만에 꽤 설득력 있는 답을 내놓았습니다. CAS로 중복 다운로드를 없애고 APFS Clonefile로 파일 복사 비용을 거의 0으로 만든 데다가 병렬 처리까지 더했으니 빠를 수밖에 없겠죠. CI/CD 환경에서 빌드 시간을 줄이고 싶은 팀이라면 한번 써볼 만합니다.

아직 실험적인 프로젝트라 당장 Homebrew를 버리기보다는 나란히 설치해서 점차 비중을 옮겨가는 게 현실적이에요. Python 생태계에서 pip → uv 전환이 빠르게 이뤄진 것처럼 macOS 패키지 관리도 비슷한 흐름을 탈 수 있을지 지켜보면 재미있을 것 같습니다.

더 자세한 사용법은 Zerobrew GitHub 저장소를 참고하세요.