Homebrew가 느려서 답답했다면, Nanobrew를 한번 살펴보세요

macOS 패키지 관리의 고질적인 문제, 느린 속도

macOS에서 개발하시는 분들이라면 Homebrew를 안 쓰는 분이 거의 없을 거예요. brew install로 거의 모든 개발 도구를 설치할 수 있으니까요. 그런데 Homebrew에는 오래된 불만이 하나 있어요. 느리다는 거예요. brew update만 해도 체감상 한참 걸리고, brew install 할 때도 의존성 해석하는 데 시간이 꽤 들거든요. 특히 새 맥을 세팅하면서 패키지를 수십 개 설치할 때면 정말 답답하죠. 이 문제를 정면으로 해결하겠다고 나온 프로젝트가 바로 Nanobrew예요.

Nanobrew가 뭔가요?

Nanobrew는 Homebrew와 호환되는 macOS 패키지 매니저인데, 핵심 목표가 "속도"예요. 기존 Homebrew의 formula(패키지 레시피)를 그대로 사용할 수 있으면서, 설치 과정이 훨씬 빠르다고 해요.

Homebrew가 느린 이유를 먼저 이해하면 Nanobrew의 접근이 왜 의미 있는지 알 수 있어요. Homebrew는 Ruby로 작성되어 있고, 패키지 정보가 담긴 거대한 Git 저장소(homebrew-core)를 로컬에 클론해서 관리해요. brew update를 하면 이 저장소를 git pull 하는 건데, 이 저장소에 수천 개의 formula가 있다 보니 업데이트 자체가 무거워요. 또 의존성 해석도 Ruby 런타임 위에서 돌아가니까 네이티브 도구에 비하면 오버헤드가 있고요.

Nanobrew는 이런 병목들을 다른 방식으로 풀어요. 패키지 메타데이터를 더 효율적으로 가져오고, 의존성 해석을 최적화해서 설치 시간을 줄이는 방향이에요. Homebrew의 bottle(미리 빌드된 바이너리 패키지) 시스템과도 호환되기 때문에, 소스에서 빌드하는 것 대신 미리 컴파일된 패키지를 바로 다운받아 쓸 수 있어요.

기존 Homebrew와 뭐가 다른가요?

가장 큰 차이는 아키텍처 설계에 있어요. Homebrew는 역사가 오래된 만큼 레거시가 많이 쌓여 있거든요. 처음 만들어진 게 2009년이니까, 그때의 설계 결정들이 지금까지 이어지고 있는 부분이 있어요. 반면 Nanobrew는 2020년대의 관점에서 처음부터 새로 설계할 수 있었기 때문에, 현대적인 최적화 기법들을 적극적으로 적용할 수 있었어요.

호환성 측면에서는, brew install로 설치할 수 있는 대부분의 패키지를 Nanobrew로도 설치할 수 있다고 해요. 기존에 Homebrew로 관리하던 환경에서 전환하는 것도 어렵지 않도록 설계했다고 하고요. 다만 Homebrew의 모든 기능을 100% 지원하는 건 아닐 수 있어요. 특히 tap(서드파티 저장소)이나 cask(GUI 앱 설치) 같은 확장 기능은 지원 범위를 확인해볼 필요가 있어요.

비슷한 시도들은 없었나?

사실 Homebrew의 속도 문제를 해결하려는 시도가 이번이 처음은 아니에요. 과거에도 여러 대안이 나왔거든요.

Nix는 macOS에서도 사용할 수 있는 강력한 패키지 매니저인데, 재현 가능한 빌드(reproducible build)에 초점을 맞추고 있어요. 성능도 좋지만 학습 곡선이 상당히 가파르다는 게 단점이에요. Nix 언어 자체를 배워야 하니까요.

MacPorts는 Homebrew 이전부터 있던 macOS 패키지 매니저예요. 안정성은 좋지만 Homebrew만큼의 패키지 생태계는 없고, 속도 면에서도 특별히 빠르진 않아요.

최근에는 pkgx(Tea의 후속)같은 프로젝트도 있는데, 이쪽은 아예 패키지 관리의 패러다임 자체를 바꾸려는 접근이에요.

Nanobrew의 포지셔닝은 이들과 좀 달라요. "Homebrew의 생태계를 그대로 쓰면서 속도만 빠르게"라는 실용적인 접근이거든요. 새로운 개념을 배울 필요 없이, 기존 워크플로우를 유지하면서 속도 이점만 가져갈 수 있다는 게 핵심 가치예요.

한국 개발자에게 주는 시사점

솔직히 Nanobrew는 아직 초기 단계의 프로젝트예요. 프로덕션 환경의 CI/CD 파이프라인에 바로 적용하기보다는, 개인 개발 머신에서 먼저 테스트해보는 게 좋을 거예요. 새 맥을 세팅하거나 사이드 프로젝트용 머신에서 한번 써보면서 실제로 얼마나 빠른지 체감해보시는 걸 추천해요.

특히 CI/CD에서 macOS 러너를 사용하시는 분들에게는 잠재적으로 의미 있는 도구가 될 수 있어요. GitHub Actions의 macOS 러너에서 brew install이 빌드 시간의 상당 부분을 차지하는 경우가 있거든요. 이 부분의 속도가 개선된다면 CI 비용 절감으로 직결될 수 있어요.

다만 주의할 점도 있어요. 새로운 패키지 매니저는 보안 측면에서도 검증이 필요해요. Homebrew는 수천 명의 기여자와 오랜 기간의 검증을 거쳤지만, 새 프로젝트는 아직 그런 신뢰가 쌓이지 않았으니까요. 소스 코드를 살펴보고, 패키지 무결성 검증이 제대로 이루어지는지 확인해보는 게 좋겠어요.