1. 왜 문제가 brew 줄에서 특히 두드러지나

Homebrew는 사용자가 입력한 패키지 이름 하나만 보여도 그 뒤에는 버전 확인·리비전 선택·Checksum 검증·실제 파일 전송이 서로 다른 HTTP 세션으로 이어집니다. 브라우저에서 릴리스 페이지가 빠르게 열렸다고 해서 같은 순간의 CLI 전송 줄도 같은 노드를 타는 것은 아닙니다. 특히 큰 파일 전송은 GitHub가 노출하는 스토리지 호스트 이름으로 분산되어 TLS 세션과 리전 선택이 바뀌고, 회사 방화벽이 특정 접미사만 지연시키는 패턴과 만나면 진행 로그 한 줄에서 멈춘 것처럼 보입니다.

brew update는 원격 Git 참조와 병렬적으로 여러 포뮬러 저장소 메타를 받습니다. 여기서 한 줄만 오래 걸려도 나머지 단계가 대기 상태로 묶여 사용자에게는 전체가 멈춘 인상을 줍니다. 따라서 증상을 재현할 때는 가능하면 brew install -v처럼 자세한 출력을 켠 채 마지막으로 출력된 URL 문자열을 메모하는 습관이 중요합니다.

2. 터미널은 브라우저와 같은 프록시 표를 쓰지 않는다

macOS에서 Clash Verge Rev 같은 클라이언트가 시스템 프록시만 토글하는 구성이라면 Safari와 Chromium 계열 탭은 그 표를 따르는 경우가 많습니다. 반면 새로 연 터미널 세션에는 기본적으로 http_proxy 같은 변수가 비어 있는 경우가 많아 Ruby 프로세스가 직접 나가려 합니다. 이때 브라우저에서는 문서와 작은 자산 요청만 빠르게 보이고 brew 줄만 글로벌 직결에서 걸리면 사용자는 「프록시가 안 된다」기보다 「brew 서버가 불안정하다」로 오인하기 쉽습니다.

팁: 빠르게 확인하려면 같은 터미널에서 curl -I https://github.com와 curl -x http://127.0.0.1:포트 -I https://github.com를 나란히 실행해 보세요. 후자만 즉시 응답한다면 변수 없는 첫 번째 경로가 회선 병목인지 프록시 우회인지부터 분리할 수 있습니다. 포트 번호는 본인 프로필의 mixed-port로 교체합니다.

3. 로그에서 함께 보는 호스트 묶음

아래 이름들은 「항상 필요한 고정 목록」이 아니라 연결 패널에서 실제로 같은 세션에 등장했을 때 한 정책 그룹으로 묶어볼 후보입니다. 배포 방식이 바뀌면 새 접미사가 추가되므로 문자열 전체를 인터넷 예제에서 통째 복사하기보다 본인 로그 우선주의가 안전합니다.

축예시 패턴메모
Git 웹·APIgithub.com메타 요청과 리디렉션 전 단계에서 자주 등장합니다.
릴리스 파일objects.githubusercontent.com큰 tarball 줄에서 특히 비중이 큽니다.
포뮬러 웹formulae.brew.sh인덱스·JSON 계층 요청과 연결됩니다.
컨테이너ghcr.io탭이나 설치 소스가 컨테이너 레지스트리를 참조할 때 필요합니다.

추가로 Homebrew 프로젝트 자체 문서나 미러 설정을 바꾼 경우에는 호스트 집합이 달라집니다. 미러를 섞어 쓰면 규칙을 미러 접미사로 옮겨야 하므로 변경 이력도 함께 적어 두세요.

4. 환경 변수와 시스템 프록시를 동시에 생각하기

많은 매뉴얼이 export https_proxy=http://127.0.0.1:7890 같은 예시를 보여 주지만 이것만으로는 충분하지 않은 경우가 있습니다. 첫째로 포트 번호가 프로필마다 다르고 둘째로 회사 PAC 파일과 충돌하면 변수가 무시되는 듯 보입니다. 환경 변수는 CLI 프로세스 트리에 내려가야 하므로 셸 초기화 파일에 넣었다면 새 탭을 연 뒤 다시 확인해야 합니다.

보다 안전한 패턴은 로컬 mixed 포트가 확실히 살아 있는지 확인한 다음 현재 세션에만 변수를 넣어 재현하고 성공하면 영구 반영 여부를 결정하는 것입니다. 세부 명령 예시와 함께 정리된 내용은 터미널 프록시 환경 변수 글을 참고하면 brew 실험과 같은 축으로 묶기 좋습니다.

5. 시스템 프록시만으로 빠져나가는 프로세스와 TUN

일부 네트워크 스택은 전역 프록시 표를 우회합니다. 이때는 TUN 모드로 시스템 전체 테이블을 맞추는 방법이 증상을 줄이는 경우가 많습니다. 다만 회사 단말 정책이 커널 확장이나 가상 어댑터 생성을 제한하면 TUN 자체가 허용되지 않을 수 있으므로 보안 정책 범위 안에서만 시도해야 합니다.

TUN을 켠 뒤에도 특정 줄만 오래 걸린다면 여전히 규칙 순서 문제일 가능성이 큽니다. 넓은 GEOIP 직결 규칙이 파일 호스트 줄을 삼켜 버리면 노드 설정과 무관하게 지연이 남습니다.

6. 규칙 순서와 GEOIP 충돌

공항형 구독 프로필에는 국내 트래픽을 바로 내보내는 줄이 포함되는 경우가 많습니다. 의도는 좋지만 글로벌 CDN 접미사 일부가 같은 조건에 걸리면 GitHub 파일 줄만 직결로 새고 다른 메타 줄만 노드를 타는 혼합 상태가 됩니다. 로컬 파일 최상단에 작은 덮어쓰기 블록을 두고 구독 갱신 후 순서가 밀렸는지 주기적으로 확인하는 편이 재발을 줄입니다.

# Example only — replace GH_DEV with your policy group; verify hostnames in YOUR session log
rules:
  - DOMAIN-SUFFIX,github.com,GH_DEV
  - DOMAIN-SUFFIX,githubusercontent.com,GH_DEV
  - DOMAIN-SUFFIX,ghcr.io,GH_DEV
  - DOMAIN-SUFFIX,brew.sh,GH_DEV

DOMAIN-KEYWORD로 매우 넓게 잡으면 무관한 하위 호스트까지 같은 노드로 몰려 조직 SSO나 다른 업무 트래픽과 충돌할 수 있으므로 로그에서 확인된 접미사부터 올리는 방식을 권합니다.

주의: 이 글은 소속 조직이 허용한 네트워크 범위 안에서 연결 일관성을 맞추는 기술 설명입니다. 보안 정책을 우회하거나 이용 약관을 위반하는 경로를 안내하지 않습니다.

7. brew 자체 진단 플래그로 줄 확인하기

설치 명령을 반복 테스트할 때는 캐시와 이전 부분 다운로드 파일이 결과를 흐리게 만들 수 있습니다. 문제 재현 후에는 Homebrew 문서에 따라 안전하게 캐시를 비우고 한 번 더 시도해 패턴이 같은지 확인하세요. 장문 로그를 붙여 저장할 때는 토큰이나 내부 미러 URL 같은 민감 문자열이 포함되지 않게 마스킹합니다.

네트워크 이전 단계에서 Ruby 스택 오류와 혼동하지 않도록 Xcode 커맨드라인 도구나 최소 빌드 의존성 경고도 같은 세션 출력에 함께 있는지 봅니다. 순수하게 TLS 타임아웃 문자열만 반복된다면 프록시 축을 우선 의심합니다.

8. DNS와 fake-ip가 설치 로그를 바꾸는 경우

fake-ip 모드는 체감 지연을 줄이지만 해석 결과와 실제 엣지 리전이 어긋나면 같은 호스트 문자열이라도 재시도가 길어집니다. 규칙을 수정했다면 터미널과 brew 프로세스를 완전히 닫았다가 다시 열어 캐시된 이름 결과가 남았는지 확인하는 편이 재현성이 높습니다.

여러 프로필을 오가며 테스트한다면 각 프로마다 DNS 설정과 도메인 규칙 파일 경로가 다를 수 있으니 노드만 바꾸고 같은 이름으로 여러 버전을 섞어 쓰지 않도록 메모해 두세요.

9. Clash Verge Rev에서 로그 모으기

GUI 클라이언트는 문자열 필터로 특정 접미사만 보기 좋습니다. 설치 명령을 실행하기 직전에 연결 패널을 열고 시간 순으로 새 행만 적습니다. 정책 열에서 DIRECT와 선택한 노드 그룹이 섞여 있으면 우선 같은 그룹으로 맞춘 다음 필요하면 세분화합니다.

처음 설치하는 사용자는 Clash Verge Rev 입문 가이드로 프로필 적용과 시스템 프록시 토글을 익힌 뒤 이 글의 분류 단계로 넘어오면 부담이 적습니다. Apple 실리콘 환경 전용 설치 흐름은 Apple Silicon 설치 글과 연결해 참고할 수 있습니다.

프록시와 무관하게 회선 자체가 RST를 반복하거나 회사 중간 검사 장비가 대용량 바이너리만 느리게 하는 경우도 있습니다. 이때는 같은 시간대에 브라우저 개발자 도구로 리소스 타이밍을 병렬 확인하면 원인 분리가 빨라집니다. Clash 자체 동작 문제는 일반 트러블슈팅 가이드의 구독·포트 확인 순서와 연계하면 좋습니다.

11. 짧은 FAQ

Q. Apple 실리콘(M1 등)과 Intel 맥 차이가 있나요?
A. 네트워크 스택 관점에서는 동일한 패턴이 많습니다. 차이는 주로 로제타 전환 여부와 보안 확장 알림 빈도입니다.

Q. Docker 안에서 brew를 돌리나요?
A. 일반 사용자는 호스트 맥에서 brew를 쓰는 경우가 많습니다. 컨테이너 내부 별도 brew를 쓴다면 호스트 프록시와 다른 이름 공간 문제가 추가되므로 Docker 호스트 프록시 글 축을 따로 보세요.

12. 정리

brew install과 brew update가 한 줄에서 오래 걸릴 때는 단일 호스트 장애만 의심하지 말고 GitHub Release 파일 줄과 formulae.brew.sh 같은 메타 줄이 서로 다른 출구를 타는지부터 확인하는 편이 진단 속도가 빠릅니다. 터미널에서 환경 변수가 비어 있으면 브라우저와 다른 표를 보므로 시스템 프록시·변수·TUN을 같은 실험 번호로 묶어 기록하세요. 규칙은 로그에서 검증된 접미사부터 로컬 상단 블록에 올리고 넓은 GEOIP 줄과의 충돌을 주기적으로 점검하면 재발을 줄입니다.

단순히 「연결 버튼 한 번」 중심인 일반 VPN 앱은 어떤 호스트 줄이 어느 정책을 탔는지 보여 주기 어렵고 규칙 편집도 분리되어 있어 개발자 트래픽처럼 호스트가 많은 상황에서 같은 증상을 반복하기 쉽습니다. 반면 Mihomo 계열 Clash 생태계는 연결 로그와 YAML 규칙을 같은 화면에서 다룰 수 있어 brew처럼 여러 단계 HTTP가 얽힌 CLI 도구를 진단하기에 유리합니다. 프로필 전환 실험도 노드 변경만 하는 것보다 재현 메모와 함께 남기기 좋습니다. → 즉시 무료로 Clash를 다운로드하고 brew 세션 로그에서 GitHub와 brew CDN 줄이 같은 정책으로 묶였는지 확인해 보세요