Homebrew 6.0.0 릴리즈

 (brew.sh)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 모든 메타데이터를 단일 다운로드로 묶는 내부 JSON API가 기본값으로 전환되어, 업데이트 고속화 및 네트워크 통신 감소
    • 기존 HOMEBREW_USE_INTERNAL_API opt-in 변수는 deprecated 처리
  • Linux에 Bubblewrap 샌드박스 적용, build·test·postinstall 단계를 macOS와 동일하게 격리 실행
  • 사용자 설문 반영으로 ask 모드가 개발자 기본값으로 변경, brew install·brew upgrade 시 의존성 요약과 확인 프롬프트 표시
  • brew bundle에 병렬 formula 설치가 기본 자동 실행되며, npm·krew 확장 및 Windows winget 지원 추가
  • brew leaves 약 30% 고속화 등 시작·업그레이드 전반 성능 개선
  • macOS 27 (Golden Gate) 초기 지원 추가
    • Intel 지원 중단에 따라 2026년 9월 macOS Intel x86_64가 Tier 3로, 2027년 9월 완전 미지원 예정
  • 보안 권고 3건 공개 (HTTPS→HTTP 리다이렉트 우회, .pkg postinstall root 코드 실행, /var/tmp plist 소유권 탈취) 및 수정
  • npx 유사 신규 명령 brew exec, 설치된 패키지의 취약점 검사 brew vulns 등 신규 명령 추가
  • 공통 postinstall·flight 동작을 literal DSL 데이터로 JSON API에 노출하는 install steps framework 도입, 단순 작업 시 Ruby 파일 다운로드·평가 불필요
  • npm·PyPI 등 위험 생태계에 다운로드 cooldown 적용해 업스트림 공급측 보안 위험 완화

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • GitHub의 @bfontaine임. 2014~2016년쯤 Homebrew 유지보수를 도왔는데, Mike가 16년 넘게 계속 유지보수하면서 아직도 새 기능을 내는 걸 보면 늘 놀라움

    • 9월이면 17년이 됨. 그때 훌륭하게 기여해줘서 고마웠고, 잘 지내길 바람
    • Homebrew가 너무 좋아서 가능하면 Linux에서도 씀
      대부분의 Linux 패키지 관리자는 사용자가 설치한 패키지와 시스템 패키지를 분리하지 못해서, 워크스테이션 정리가 거의 불가능하고 뭘 지워도 되는지 판단하기 어렵다
      게다가 네이티브 패키지 관리자는 Homebrew보다 업데이트가 느려서 오래된 패키지만 받는 경우가 많음

  • 실험 삼아 Homebrew+pipx+npm에서 https://mise.jdx.dev/로 OS 수준 개발 환경을 전부 옮겼는데, 실제로 아주 잘 동작함
    많은 도구가 GitHub 릴리스나 대응되는 패키지 관리자(uv, pnpm, go get 등)에서 직접 설치돼서 재패키징용 접착 코드도 없고 버전 지연도 없음
    임의 버전이나 여러 버전을 동시에 설치할 수 있고, 작업 폴더별 또는 환경별로 활성 버전을 동적으로 바꿀 수 있음
    재미있게도 Mise는 의존성을 지원하지 않는데, 대체로 문제가 안 됐음. pnpm/uv가 처리하거나 정적 바이너리라 그냥 동작하기 때문임
    예전에 Python 앱을 Homebrew용으로 패키징하면서 의존성 50개를 resources로 가져오고, 전부 소스에서 빌드하거나 Homebrew에 있는지 수동 확인하고, 5개 언어의 빌드 툴체인을 의존성으로 선언하고, 업데이트마다 CI를 1시간 넘게 기다리다가, 업스트림 업데이트로 “빌드 시점 의존성 루프”가 생겨 Homebrew로는 풀 수 없게 된 적이 있음
    그래서 Mise가 “쉬운 길”을 택해 언어별 패키지 관리자에 직접 의존하는 이유를 완전히 이해함
    Brewfile에서 대체하지 못한 건 Colima와 통신하는 데 필요한 Docker CLI뿐이고, cask는 여전히 Homebrew를 씀. 개발 환경을 실험해보길 권함. 요즘 훌륭한 새 도구가 많음

    • Mise는 확실히 독자적인 급으로 보임. 다른 곳에서도 말했듯 aqua나 asdf 같은 레지스트리에 의존함
      Homebrew 패키지에 Mise를 쓰고 싶은 사람에게는 https://github.com/kennyg/mise-zerobrew가 있음
    • PHP 개발자로서는 Mise의 지원이 Shivam Mathur가 Homebrew용으로 해온 PHP 패키징보다 꽤 부족했음
      대부분 프로젝트는 어차피 Docker를 쓰고, 로컬 PHP는 정적 분석처럼 Docker가 필요 없는 용도임
      Nix를 쓰는 프로젝트도 몇 개 있는데, Nix는 다른 모든 걸 비웃을 정도지만 전체 사용자 경험은 git보다도 더 적대적임
    • 좋은 경험을 했다니 다행이지만, 개인적으로는 Mise에서 Brew로 다시 돌아왔음
      내 실력 문제였을 수도 있지만 Mise에서 문제가 생기는 패키지가 너무 많았음
    • Mise를 많이 좋아하지만 프로젝트별 도구 관리나 JDK 버전 같은 용도로만 씀
      시스템 전역 도구에도 써봤지만, Helix, NeoVim, RipGrep처럼 대충 최신이면 되고 정확한 버전은 신경 쓰지 않는 도구에는 잘 맞지 않았음
    • Mise도 의존성을 어느 정도 지원하지만, 다른 패키지 관리자에서 기대하는 방식은 아님
      Mise의 의존성은 자동이 아니고 모두 수동으로 정의해야 함. 병렬 설치 때문에 생기는 순서 문제를 피하려는 용도임. 예를 들어 pipx:black을 쓰면 Python 설치가 끝날 때까지 기다려야 함. 이것이 도구의 depends 옵션임
      이는 의도된 설계임. Mise는 Homebrew나 Nix처럼 완전한 부트스트랩 해법이 아니라, 기존 시스템 위에 얹는 오버레이로 설계됐음
      그래서 Python은 Brew로 관리하고 black은 Mise로 관리해도 별도 설정 없이 거의 그대로 동작함. 이 설계 결정은 크게 성공했다고 봄. 단점처럼 들리지만 결국 사용자가 Mise를 쉽게 느끼는 가장 큰 이유일 가능성이 큼

  • Homebrew는 불변 Linux 배포판에서 환경을 빠르게 부트스트랩하는 훌륭한 방법이었음
    사용자는 많지 않지만 https://formulae.brew.sh/analytics/os-version/365d/ 기준으로 Universal Blue의 Bazzite(1.28%), Bluefin(0.49%), Aurora(0.28%) 같은 운영체제는 기본으로 Homebrew를 묶어 제공함
    관련 저장소는 https://github.com/ublue-os/brew

    • 사용자 공간 패키지 관리자라는 개념은 Linux가 20년 전에 이미 해결했어야 할 일처럼 보임
      비루트 사용자의 일반적인 상황이 “XY는 설치할 수 없지만 소스에서 빌드하는 건 자유”인 건 우스움
      Homebrew, Mise, Nix가 지금 그 빈자리를 채우고 있음. Flatpak은 GUI 앱 쪽에 더 가깝고, Snap은… 존재하긴 함
    • Bazzite에서 home-manager와 함께 Nix를 쓰고 있음

  • 처음 설치하는 세 가지는 Sublime Text, Homebrew, 최신 Bash임. Zsh로 갈아탈 생각은 없음
    좋은 도구는 컴퓨팅을 즐겁게 만듦

    • Homebrew를 먼저 설치한 다음, 그걸로 Sublime과 Bash를 설치하면 됨

  • 최근 Nix에서 Homebrew로 다시 돌아왔고, 큰 이유는 세 가지임
    Brew는 보유한 패키지에 대한 지원이 Nix보다 좋아 보임. Nix는 일부 패키지가 잘 유지보수되지 않는 듯함
    Mac 지원도 더 좋음. 일부 Nix 패키지는 macOS에서 기능이 꺼져 있는데, 해당 패키지 유지보수자가 테스트용 Mac이 없어서 그런 것 같음
    사용자 경험도 더 나음
    물론 Nix 환경의 재현성과 특정 패키지를 담은 flake를 쉽게 만들 수 있는 능력은 그립지만, 종합적으로는 Brew가 나를 다시 데려왔음. 그래도 Nix는 여전히 좋아하고, 회사에서도 Nix를 씀

    • nix-darwin을 쓰고 Homebrew 패키지도 거기서 관리함. 한번 살펴볼 만함
      회사에서는 Nix를 어디에 쓰는지 궁금함. Nix가 맞아 보이는 곳이 몇 군데 있긴 한데, 정확히 짚기가 어려움
    • macOS 기능 설정과 구성을 자동화할 수 있을 것 같아서 Nix에 관심이 있었음
      하지만 보통은 defaults나 중간 도구를 실행하는 정도였음
      결국 Brew를 유지하고, bash_profile에 멱등적인 setupmac() 함수를 작성했음. Bash 5를 쓰고, ChatGPT가 멋진 defaults 명령들을 잘 알아서 도움을 받았음
      dotfiles에 유지하는 Brewfile과 함께 새 계정이나 Mac 설정 문제를 거의 해결했기 때문에, 그런 거창한 도구들은 필요하지 않음

  • Homebrew는 직원이 아니라 전적으로 자원봉사자가 운영하는 비영리 프로젝트임
    지속적 통합, 향후 개선에 필요한 소프트웨어, 하드웨어, 호스팅 비용을 내려면 자금이 필요함
    모든 기부금은 사용자에게 더 나은 Homebrew를 만드는 데 쓰인다고 하니 GitHub Sponsors, OpenCollective, Patreon을 통한 정기 후원을 고려해볼 만함
    혜택을 받는 오픈소스 프로젝트에는 많이 기부해왔지만 Homebrew는 깊이 생각해본 적이 없어서, 이제 후원해야겠음

    • Apple이나 적어도 Mac 중심의 주요 개발 회사들이 Homebrew를 후원하지 않는다는 게 놀라움

  • Homebrew에 일종의 쿨다운 메커니즘을 넣을 수 없을지 궁금함
    내 머신에 새 코드를 빠르게 배포하도록 신뢰하고 싶은 건 Apple과 브라우저뿐임. 브라우저는 그 어떤 것보다 신뢰할 수 없는 입력을 많이 처리하기 때문임
    그 외의 vscode와 확장, npm, homebrew, 자동 업데이트 앱들은 며칠 기다리는 쪽을 선호함
    일부 예외적인 0-day는 쿨다운 우회가 필요할 수 있지만, 지금도 사용자가 brew upgrade를 실행하기 전까지는 0-day에 취약한 상태임

    • https://docs.brew.sh/Supply-Chain-Security에 쿨다운을 어떻게 다루는지와 NPM 같은 것과 위험 프로필이 왜 크게 다른지가 정리돼 있음
      또한 NPM/PyPI/RubyGems에서 가져와 패키징하는 항목 중 이런 공격 대상이 되는 것들은, 패키징할 때와 새 버전 업데이트 PR을 만들 때 이미 쿨다운을 적용하고 있음
    • 여기서 말하는 건 공급망 공격 취약성을 줄이기 위한 --minimum-release-age나 minimumReleaseAge 같은 기능임
      이런 공격은 침해 후 며칠 안에 탐지되는 경우가 많음
      Bun의 예시는 https://bun.com/docs/pm/cli/install#minimum-release-age
    • 대부분은 릴리스 채널로 처리함. 예를 들면 brew set-channel stable/edge 같은 식임
      이번 주에 Elixir 1.20 발표 뒤 몇 분만 써볼 시간이 있었는데 Brew가 뒤처져 있어서 짜증났음
      erl과 elixir는 다른 방식으로도 설치할 수 있고 개인적으로는 자체 툴체인을 선호하지만, 그 순간에는 할 만한 가치가 없었음
      Brew에는 일부 레시피에 소스 옵션이 있거나 있었고, 눈을 가늘게 뜨고 보면 그것도 기본적으로 해결책이 됨
    • 전부 롤링 릴리스지만, Homebrew에서는 소프트웨어 작성자가 아니라 Homebrew 유지보수자가 버전을 올려야 함
      작성자가 Homebrew core에 PR을 넣거나 자체 Tap을 발행하는 경우는 예외임. Arch는 여기서 어떻게 하는지 궁금함
    • 이번 릴리스에 들어 있음. “Cooldowns, livecheck and bumping” 섹션을 보면 됨

  • Homebrew를 가능하게 만드는 모든 사람들에게 박수를 보냄. 프로젝트 후원을 고려해볼 만함: https://opencollective.com/homebrew

  • Intel 지원 중단은 공격적으로 느껴짐
    Mac을 서버로 쓰는 애호가들은 거의 모두 오래된 머신을 쓰고, 대부분 Intel임. Apple보다 1년 먼저 지원을 잃게 됨
    Intel 지원이 고된 일이고 선택의 문제라는 건 알지만, Homebrew가 가능한 오래 Intel 지원을 유지할 방법을 찾아야 한다는 쪽임

    • 오히려 Apple 애호가의 압도적 다수는 Apple Silicon에 완전히 올라탄 것 같음
      오래된 Mac을 서버로 쓰는 사람들은 반올림 오차 수준을 넘지 않을 것이라고 봄
    • Apple이 자원의 일부라도 Homebrew 같은 것을 유지보수하거나 그 일을 하는 사람들에게 지불하는 데 썼다면 상황이 달랐을 수 있음
    • 이 시점에서 해당 Intel Mac은 2018년 Mac mini 정도일 텐데, Sequoia까지만 실행 가능하고 Homebrew가 Intel 지원을 중단하는 시점에 같이 지원 종료됨
      Intel 지원이 필요하면 MacPorts는 Leopard까지도 여전히 돌아감
    • --no-quarantine 플래그 지원도 제거됐음
      요즘은 몇몇 cask에만 Homebrew를 쓰고 가능한 피하려고 함. CLI 도구는 Nix, Home-Manager, Nix-Darwin을 씀
    • 다행히 그런 머신들은 Linux 배포판용으로는 완벽함

  • 고정할 수 없는 강제 업그레이드에 너무 많이 당해서 개인적으로 Homebrew 사용을 중단했음
    지금은 Mise와 MacPorts 조합을 써서 예고 없는 깨짐과 강제 노후화를 피함
    게다가 Mise는 임의의 새 버전으로 올릴 수 있지만, Homebrew는 Tap이 언제 업그레이드할지 기다려야 함. llama.cpp Tap은 10개 릴리스마다 건너뛰기도 함

    • 맞는 워크플로를 찾았다니 진심으로 다행임
      아직 Homebrew를 쓰는 사람들을 위해, 꼭 필요할 때만 업그레이드하고 업그레이드 전에 사용자에게 보여주도록 많은 작업이 들어갔고 이번 릴리스에도 포함됐음
    • 나도 비슷한 경험을 한 사람이 있는지 물어보려 했음
      개발 도구 설치에는 몇 년간 MacPorts를 써왔는데, 훨씬 일관적이고 Python의 새 메이저 버전이 무작위로 튀어나와 놀라게 하지 않음
      Homebrew는 MacPorts에 없는 Firefox, Slack, Spotify 같은 애플리케이션 설치에만 씀
      물론 수년간 Python은 uv로, nodejs는 pnpm으로 옮기려고 노력해왔으니 이제는 내게 큰 문제가 아닐 수도 있음
    • Homebrew의 공격적인 지원 단계 폐기 일정 때문에 MacPorts로 옮겼음: https://docs.brew.sh/Support-Tiers
      매일 쓰는 iMac이 이제 Tier-3 “꺼져라” 버킷에 들어갔음
      쓸 수 있던 짧은 기간 동안 Homebrew를 정말 좋아했지만, 계속 쓰기 위해 하드웨어 업데이트 러닝머신에 올라탈 생각은 없음
    • 대부분을 Mise로 옮긴 단계인데, 남은 것들은 MacPorts를 살펴봐야겠음
    • Nix도 살펴볼 만함. Darwin 패키징이 좀 불안정하긴 해도, Mac과 Linux를 자주 오가야 할 때 플랫폼 간 개발 셸을 갖는 점이 정말 좋음
답변달기