모든 macOS 개발자는 이 의식을 알고 있다. 새 컴퓨터에서 터미널을 열고, Homebrew 설치 스크립트를 붙여넣고, 기다린다. 그다음 첫 번째 패키지를 brew install로 설치하려 하면, 또 기다린다. Homebrew는 뭔가 유용한 일을 하기 전에 먼저 자기 자신을 업데이트한다. 의존성을 확인한다. 어딘가에 접속한다. 당신은 핸드폰을 본다. 커피를 내린다. 돌아온다. 아직도 돌아가고 있다.
10년이 넘도록 아무도 이걸 진지하게 도전하지 않았다. 지금까지는.
2009년, 2023년: Homebrew는 어떻게 아무도 의심하지 않는 인프라가 되었나
Max Howell은 2009년에 MacPorts와 Fink에 대한 반발로 Homebrew를 만들었다. 이 두 도구는 Mac을 쓰는 것에 대한 벌칙처럼 느껴졌다. Homebrew는 훨씬 친절했다. /usr/local에 설치되고, Ruby를 사용했으며, 패키지 기여를 놀랍도록 쉽게 만드는 formula 시스템을 갖추고 있었다.
2012년이 되자 "macOS에서 X를 어떻게 설치하죠"라는 질문에 대한 기본 답변이 됐다. 2015년에는 너무 보편화되어 회사 온보딩 문서가 Homebrew가 설치돼 있다고 그냥 가정할 정도였다. 2020년에 이르러 Homebrew는 Apple Silicon을 위해 /opt/homebrew로 이전하고, 대규모 아키텍처 전환을 견뎌냈으며, 자신의 입지를 더욱 확고히 했다.
하지만 아무도 대놓고 말하지 않던 것이 있다: Homebrew가 느려졌다는 것. 정말 느려졌다. "시간을 재면 알 수 있는" 정도가 아니라 "점심을 해먹고 올 수 있는" 수준으로 느려졌다. 흔한 패키지에 대한 간단한 brew install이 다운로드를 시작하기도 전에 업데이트 확인에만 30초를 잡아먹을 수 있었다. 의존성이 몇 개 있는 패키지를 월요일 아침에 설치하면, 눈앞에서 인생의 소중한 몇 분이 증발하는 걸 지켜봐야 한다.
물론 개발자들은 불만을 쏟아냈다. GitHub 이슈가 쌓였다. 그런데 어쩌겠는가? MacPorts로 갈아타겠는가? 2003년처럼 모든 걸 소스에서 컴파일하겠는가? Homebrew는 사실상 대체 불가능한 네트워크 효과를 가지고 있었다. 모든 튜토리얼, 모든 README, 모든 CI/CD 파이프라인이 brew를 전제했다.
관성이 실력인 척하는 것이었다.
2026년 초: Nanobrew, 기만적으로 단순한 제안을 들고 등장하다
Nanobrew는 2026년 초, Nick Milo가 만들어 GitHub에 공개했다. 제안은 기만적으로 단순했다: Homebrew의 formula 생태계와 완벽하게 호환되면서 극적으로 빠른 macOS 패키지 매니저.
프로젝트의 GitHub 저장소에 따르면, Nanobrew는 Homebrew를 느리게 만드는 핵심 작업들을 근본적으로 재설계하여 이를 달성한다. 매번 명령을 실행할 때마다 자동 자기 업데이트를 하지 않는다. 의존성 해결을 병렬로 처리한다. 모든 작업에 Ruby의 오버헤드를 끌고 다니지 않는 경량 런타임을 사용한다. 저장소에 게시된 벤치마크에 따르면, 결과적으로 설치 시간이 동일한 Homebrew 작업 대비 5배에서 10배까지 빨라지는 경우가 많다.
흥미로운 부분은 호환성 주장이다. Nanobrew는 Homebrew 생태계를 버리라고 요구하지 않는다. Homebrew formula를 읽는다. 같은 prefix 디렉토리에 설치한다. 기존 Homebrew 설치와 공존할 수도 있고, 완전히 대체할 수도 있다. brew install nginx에 대한 근육 기억이 그대로 작동한다. 더 빨라질 뿐.
2026년 3월: Hacker News가 불붙다
이 프로젝트가 "Nanobrew: brew와 호환되는 가장 빠른 macOS 패키지 매니저"라는 제목으로 Hacker News 첫 페이지에 올라 수백 개의 댓글을 끌어모았다. 토론 스레드는 한가한 호기심이 아닌 진정한 개발자 관심을 보여주는 수준의 참여도를 보였다.
스레드는 예상 가능한 진영으로 나뉘었다.
열광론자들은 즉각적이었다. 속도 향상과 완전히 새로운 생태계를 구축하기보다 Homebrew 호환성을 유지한 결정을 칭찬하는 댓글이 이어졌다. 여러 사용자가 자기 워크플로에서 직접 테스트해보고 일반적인 패키지에 대해 속도 주장이 사실임을 확인했다고 보고했다.
회의론자들도 타당한 지적을 했다. Homebrew가 스펙을 발전시켜 나갈 때 장기적으로 formula 호환성을 어떻게 유지할 것인가? formula가 Nanobrew에 구현되지 않은 Homebrew 전용 Ruby 훅에 의존하면 어떻게 되는가? 제작자가 떠나면 누가 유지보수하는가? 이런 우려는 가설이 아니다. macOS 패키지 관리의 묘지에는 유지보수 부담을 감당하지 못한 유망한 대안들이 가득하다.
그리고 세 번째 진영이 있었는데, 개인적으로 가장 흥미로웠다. 몇몇 댓글 작성자들은 Homebrew의 느림이 버그가 아니라 안전성과 정확성을 우선시한 설계 결정의 결과라고 주장했다. 자동 업데이트는 오래된 formula에 대해 설치하는 일이 없도록 보장한다. 순차적 의존성 해결은 경쟁 조건을 방지한다. Ruby 런타임은 정말로 강력한 formula DSL을 가능하게 한다.
속도와 안전성은 상충한다. 새로운 관찰은 아니다. 하지만 이는 Nanobrew의 속도 향상이 면밀한 검토를 받을 필요가 있다는 뜻이기도 하다. 정확히 무엇을 건너뛰고 있는 걸까?
기다림의 숨겨진 비용
어쩔 수 없이 이런 생각을 하게 된다.
개발자 시간에 대해 계산을 해보자. 활발한 개발 기준으로 보수적으로 잡아 하루에 brew install 또는 brew upgrade를 세 번 실행한다고 가정하자. Homebrew의 오버헤드 때문에 각 작업이 필요 이상으로 45초씩 걸린다. 하루 2.25분이다. 1년 근무일(약 250일) 동안이면 562분. 터미널을 멍하니 쳐다보는 데 9시간이 넘게 소모된다.
개발자 한 명 기준이다.
이걸 엔지니어 50명 팀으로 확장하면 연간 468시간이 된다. 엔지니어링 시간의 혼합 비용을 시간당 75달러(복리후생 포함)로 잡으면, 연간 35,100달러다. 패키지 매니저 오버헤드만으로.
이제 CI/CD로 확장해보자. 여기서부터 심각해진다. GitHub Actions나 Jenkins 파이프라인이 macOS 빌드의 일부로 brew install을 실행한다면, 오버헤드의 매 초가 과금되는 컴퓨팅 시간이다. GitHub Actions는 macOS 러너에 대해 분당 0.08달러를 부과한다. brew 작업당 30초의 오버헤드가 하루 200번의 CI 실행에 걸쳐 누적되면 연간 73,000달러가 낭비되는 CI 비용이다.
Nanobrew가 이 모든 걸 없앤다는 말은 아니다. 하지만 5~10배 속도 주장이 사실이라면, 그 낭비의 80~90%를 회수할 수 있다. macOS를 개발과 CI 전반에 걸쳐 사용하는 대규모 엔지니어링 조직이라면, 패키지 매니저를 교체하는 것만으로 연간 6자릿수 절감이 가능하다는 얘기다.
반올림 오차가 아니다. 인건비 한 명분이다.
더 큰 패턴: 개발자 도구의 리라이트 시대
Nanobrew는 고립된 현상이 아니다. 2022년부터 가속화된 패턴에 들어맞는다.
uv는 pip를 대체하며 속도를 중시하는 팀들의 기본 Python 패키지 설치 도구가 됐다. Bun은 기동 시간과 설치 속도에서 Node.js에 도전장을 내밀었다. Ruff는 Python 린팅을 Rust로 재작성해 flake8가 계산기 위에서 돌아가는 것처럼 보이게 만들었다. OXC는 JavaScript 도구에 같은 일을 하고 있다.
패턴은 일관적이다: 사랑받지만 느린 도구를 가져다가, 핫패스를 더 빠른 언어나 근본적으로 다른 아키텍처로 재작성하고, 마이그레이션 비용이 제로에 수렴하도록 생태계 호환성을 유지한 다음, 기존 도구가 민망해지는 벤치마크를 내놓는다.
이것이 통하는 이유는 개발자 도구들이 서서히 느려졌기 때문이다. 각각의 기능 추가, 각각의 안전 검사, 각각의 텔레메트리 핑은 개별적으로는 타당했다. 이것들이 10년 동안 복리로 쌓이면 당신과 싸우는 것 같은 느낌의 도구가 된다.
문제는 더 빠른 대안이 나타날 것이냐가 아니다—모든 것에 대해 나타날 것이다. 문제는 원조가 대응할 수 있느냐다. Homebrew는 자원봉사자가 유지하는 프로젝트다. 리라이트에 전력 질주할 수 있는 회사가 뒤에 없다. 메인테이너들은 아무 보상 없이 감사받지 못하는 일을 하고 있다. Nanobrew의 존재는 찬사이자 위협이다.
주목해야 할 세 가지, 그리고 오늘 결정하는 법
첫째, 장기적 formula 호환성. Homebrew의 formula 스펙은 고정되어 있지 않다. 계속 진화한다. Nanobrew가 호환성에서 뒤처지면 전체 가치 제안이 무너진다. 이 프로젝트에는 견고한 자동화된 호환성 테스트 파이프라인이 필요하거나, 문제를 빠르게 발견할 수 있을 만큼 큰 커뮤니티가 필요하다.
둘째, 기업 도입 시그널. 주요 기업이 CI/CD를 공개적으로 Nanobrew로 전환하면, 그것이 티핑 포인트다. Fortune 500 기업의 마이그레이션 사례 하나가 Hacker News 첫 페이지에 올라가면 갑자기 모든 플랫폼 엔지니어링 팀이 평가를 시작하게 된다.
셋째, Homebrew의 대응. Homebrew 메인테이너들은 똑똑한 사람들이다. uv가 pip의 밥그릇을 빼앗는 걸 지켜봤다. 속도가 중요하다는 걸 안다. 하위 호환성을 깨지 않으면서 성능을 유의미하게 개선할 수 있느냐가 열린 질문이다. 할 수 있다면 Nanobrew는 각주가 된다. 할 수 없다면 Nanobrew가 새로운 기본값이 된다.
오늘 시도해볼지 결정하는 방법은 이렇다: 개인 머신을 쓰는 1인 개발자라면 리스크가 낮다—Homebrew와 나란히 설치하고, 자주 쓰는 패키지를 테스트하고, 시간을 비교해보라. CI/CD에서 사용하려면, 최소 6개월의 활발한 유지보수 이력과 봇이 아닌 계정의 GitHub 스타가 수백 개 이상 될 때까지 기다려라. 팀 도입을 검토 중이라면, 기존 Homebrew 설정과 병행하여 2주간 섀도우 배포를 운영한 후 결정하라.
Homebrew의 지배력은 실재했다. 하지만 "더 나은 게 없어서" 위에 세워진 지배력은 가장 취약한 종류다. Nanobrew가 마침내 Homebrew를 끌어내리는 패키지 매니저가 아닐 수도 있다. 하지만 누군가가 드디어 올바른 질문을 던지고 있다는 증거다: 우리는 왜 아직도 기다리고 있는가?