# Homebrew 6.0.0 릴리즈

> Clean Markdown view of GeekNews topic #30413. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30413](https://news.hada.io/topic?id=30413)
- GeekNews Markdown: [https://news.hada.io/topic/30413.md](https://news.hada.io/topic/30413.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-12T09:43:21+09:00
- Updated: 2026-06-12T09:43:21+09:00
- Original source: [brew.sh](https://brew.sh/2026/06/11/homebrew-6.0.0/)
- Points: 3
- Comments: 2

## Topic Body

- 모든 메타데이터를 단일 다운로드로 묶는 **내부 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** 적용해 업스트림 공급측 보안 위험 완화

## Comments



### Comment 59472

- Author: lamanus
- Created: 2026-06-12T13:22:36+09:00
- Points: 1

인텔 맥까지 지원하기엔 리소스도 부족하고, github actions도 더 이상 이미지를 제공하지 않을 예정이므로 homebrew도 여기에 맞춰서 진행할 수밖에 없습니다.

### Comment 59451

- Author: neo
- Created: 2026-06-12T09:43:22+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48490024) 
- GitHub의 @bfontaine임. 2014~2016년쯤 **Homebrew 유지보수**를 도왔는데, Mike가 16년 넘게 계속 유지보수하면서 아직도 새 기능을 내는 걸 보면 늘 놀라움
  - 9월이면 17년이 됨. 그때 훌륭하게 기여해줘서 고마웠고, 잘 지내길 바람
  - **Homebrew**가 너무 좋아서 가능하면 Linux에서도 씀  
    대부분의 Linux 패키지 관리자는 사용자가 설치한 패키지와 시스템 패키지를 분리하지 못해서, 워크스테이션 정리가 거의 불가능하고 뭘 지워도 되는지 판단하기 어렵다  
    게다가 네이티브 패키지 관리자는 Homebrew보다 업데이트가 느려서 오래된 패키지만 받는 경우가 많음

- 실험 삼아 Homebrew+pipx+npm에서 [https://mise.jdx.dev/](<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](<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/](<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](<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](<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](<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](<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](<https://docs.brew.sh/Support-Tiers>)  
    매일 쓰는 iMac이 이제 Tier-3 “꺼져라” 버킷에 들어갔음  
    쓸 수 있던 짧은 기간 동안 Homebrew를 정말 좋아했지만, 계속 쓰기 위해 하드웨어 업데이트 러닝머신에 올라탈 생각은 없음
  - 대부분을 Mise로 옮긴 단계인데, 남은 것들은 MacPorts를 살펴봐야겠음
  - **Nix**도 살펴볼 만함. Darwin 패키징이 좀 불안정하긴 해도, Mac과 Linux를 자주 오가야 할 때 플랫폼 간 개발 셸을 갖는 점이 정말 좋음