Transcript
00:00:00몇 달 전 바로 이 채널에서 Homebrew를
00:00:05Nix에 훨씬 못 미치는 구시대의 유물처럼 다룬 영상을 올린 적이 있었죠.
00:00:12그러니 이제 다시 이 이야기를 꺼내는 게 도리겠네요. 우리가 구시대 유물이라 부르던 그 툴이
00:00:17몇 년 만에 첫 주요 버전인 Homebrew 6.0을 출시했습니다. 그리고 여기서 핵심은 새로운 기능의 추가가 아닙니다.
00:00:23보안 체계를 전면 개편했다는 점이죠. Homebrew가 드디어 제대로 진화했습니다.
00:00:30그럼 단지 버전 숫자만 올라간 것보다 훨씬 재미있는 실제 변경 사항을 설명해 드릴게요.
00:00:38사실상 Homebrew가 존재해 온 지금까지, 서드파티 tap, 즉 타인의 패키지 저장소를 추가하면
00:00:45Homebrew는 그 안의 Ruby 코드를 그냥 실행했습니다. 무조건 그 코드를 실행했죠. 어떤 tap이든
00:00:51아무런 확인도 없이 임의의 코드를 실행했던 겁니다. 우리가 살고 있는 지금 세상을 한번 생각해 보세요.
00:00:56패키지 매니저는 현재 공급망 공격의 첫 번째 표적입니다. NPM을 비롯한 모든 패키지 매니저가
00:01:01계속해서 공격받고 있죠. 저장소가 주는 코드가 무엇이든 그냥 실행하는 건 위협적인 기본값입니다.
00:01:08Homebrew 6.0의 신기능은 바로 그걸 차단하기 위해 존재합니다. 'Tap Trust'라는 기능인데요. 이런 코딩 팁과 트릭이 마음에 드신다면
00:01:15구독하는 걸 잊지 마세요. 새로운 영상이 계속 업로드됩니다. 그럼 매일 체감할 수 있는
00:01:19부분부터 시작해 보죠. brew version. 네, 6.0입니다. 이제 몇 가지 의존성을 끌어오는
00:01:25패키지를 설치할 때 무슨 일이 일어나는지 보세요. 조용히 알아서 처리하는 대신, Brew는 설치하려는
00:01:31모든 항목의 요약을 보여주고 사용자의 승인을 기다립니다. 이것이 바로 새로운 'Ask' 모드이며,
00:01:38개발자 환경에서는 기본으로 활성화됩니다. 사소한 변화지만, Brew가 시스템을 변경하기 전에
00:01:44항상 계획을 확인할 수 있습니다. 이제 가장 중요한 'Tap Trust'를 볼까요. 서드파티 tap을 추가할 때를 보세요.
00:01:50Homebrew가 단칼에 차단합니다. 이 tap은 아직 신뢰할 수 없다고 나오며, 사용자가 직접 허용하기 전까지는
00:01:56단 한 줄의 코드도 실행하지 않습니다. 'brew trust' 명령어로 직접 신뢰 설정을 해줘야만 비로소
00:02:03실행이 됩니다. 공식 Homebrew tap은 기본적으로 신뢰 상태로 제공되므로, 일상적인 Brew 설치 환경은
00:02:09완전히 동일합니다. 하지만 GitHub에서 누군가의 리드미를 보고 발견한 출처 불명의 tap은
00:02:16이제 잠긴 문과 같습니다. 사용자가 직접 승인해야 하죠. 사실 솔직히 말해
00:02:20지금 시점에서는 아주 훌륭한 결정입니다. 게다가 변경 사항이 이것뿐만이 아닙니다.
00:02:25내부 메타데이터 시스템이 기본값으로 지정되어, 수십 번씩 네트워크를 오가는 대신
00:02:30모든 패키지 정보를 단 한 번에 깔끔하게 다운로드합니다. 덕분에 'brew update'가 훨씬 빨라졌죠. 그리고
00:02:37새로운 명령어인 'brew execute'가 도입되었는데, 쉽게 말해 Homebrew용 npx입니다. 툴을 시스템에 영구적으로
00:02:45설치하지 않고 일회성으로 실행할 수 있죠. 또한 이미 설치된 패키지를 알려진 보안 취약점 및
00:02:51권고 사항과 비교 검사하는 'brew vulns'도 추가되었습니다. 게다가 6.0에서는 Mac 설치 패키지를 통해 root 권한으로
00:02:58코드를 실행할 수 있었던 결함을 포함해 3가지 보안 허점을 조용히 패치했습니다. 아주 내실 있는 업데이트죠. 하지만 여기서
00:03:04주의해야 할 점이 있습니다. 누군가에게는 큰 문제가 될 수 있으니 확실히 짚고 넘어갈게요.
00:03:09Tap trust는 기존 방식을 깨뜨리는 변경 사항입니다. 서드파티 tap에 의존하는 CI 파이프라인이 있다면,
00:03:14'brew doctor'는 신뢰하지 않는 tap을 발견하는 즉시 에러를 발생시킵니다. 그런데 많은 표준 GitHub Actions가
00:03:20가장 첫 단계로 'brew doctor'를 실행하죠. 그래서 업데이트 후 빌드가 그냥 실패하기 시작한 겁니다.
00:03:28해결책은 해당 tap을 설정에서 신뢰 상태로 표시하는 것이지만, 사용자가 직접 작업해야 합니다.
00:03:35아무도 대신해 주지 않죠. Ask 모드도 마찬가지입니다. 프롬프트 없이 자동으로
00:03:41Brew가 설치될 것이라 전제한 스크립트가 있다면, 새 프롬프트 때문에 무한 대기에 빠질 수 있습니다. 전체적인 구성 관점에서도
00:03:46일상적으로 앱을 설치하는 일반 사용자라면 체감되는 변화는 거의 없을 겁니다.
00:03:51겉모습만 바꾼 게 아니라 보안과 아키텍처 중심의 릴리즈이기 때문이죠. 여기서 짚고 넘어가야 할 오해도 하나 있습니다.
00:03:58많은 것들이 Rust로 재작성되고 있지만, Homebrew는 Rust로 재작성되지 않습니다.
00:04:04적어도 지금은 아닙니다. 그건 실험적인 시도였을 뿐, 핵심은 언제나 그랬듯 다시 Ruby 코드베이스에 집중되어 있습니다.
00:04:10그렇다면 Homebrew 6.0으로 업데이트해야 할까요? 대부분에게 답은 당연히 'YES'입니다.
00:04:163가지 보안 패치를 받을 수 있고, 사실 'brew update'가 의도했든 아니든
00:04:22자연스럽게 6.0으로 안내할 것입니다. 신중할 필요가 있는 분들은
00:04:27서드파티 tap을 사용하는 CI를 돌리거나 무소음 설치를 기대하는 자동화를 운용하는 분들입니다. 해당 부분을 먼저 수정하면
00:04:33문제없습니다. 그리고 여전히 Intel Mac을 사용 중이시라면 주의하세요. 6.0은 향후 몇 년간에 걸쳐
00:04:40Intel 지원을 종료할 로드맵을 밝히고 있습니다. 최신 컴퓨터인 Apple Silicon 사용자분들은
00:04:46전혀 문제없습니다. 심지어 새로운 M5 칩에 대한 지원도 추가되었죠. 결론은 이렇습니다.
00:04:53수년간 Homebrew는 Mac에 소프트웨어를 가장 빠르게 설치하는 편의 도구에 불과했습니다.
00:04:59하지만 6.0에 이르러, 기기에 설치되는 코드가 신뢰할 수 있는지 마침내 검증받는
00:05:05체크포인트에 가까워졌습니다. 이는 큰 진전입니다. 패키지 매니저가
00:05:10우리 모두가 수년간 노출되어 있던 위협 모델을 드디어 따라잡은 것이죠. 이것이야말로 진정한 핵심입니다.
00:05:156.0이니 6.1이니 하는 버전 숫자가 아니라 그 안에서 이루어진 변화가 중요한 것이죠. 이런 코딩 팁과 트릭이
00:05:21유익하셨다면 BetterStack 채널 구독 부탁드립니다. 다음 영상에서 뵙겠습니다.