BlueByte
command not found: brewFixed

macOS: zsh: command not found: brew

작성 Haneul Seo2026년 8월 12일 업데이트4 min

안녕하세요, BlueByte입니다. 설치 직후 brew가 "command not found"라 해도 재설치하지 마세요 — Homebrew는 거기 있고, 셸이 어디를 볼지 모를 뿐입니다. Apple 실리콘에선 기본 PATH가 포함하지 않는 곳에 있습니다. 오늘은 그게 문제인지 확인하고 한 번에 영구히 추가하는 순서로 가보겠습니다.

이 오류가 뜻하는 것

Homebrew 설치 직후 실행이 실패합니다:

zsh: command not found: brew

Homebrew는 설치돼 있습니다 — 그 위치가 PATH에 없어 셸이 못 찾을 뿐입니다. 설치 관리자가 출력 끝에 필요한 두 줄을 찍는데, 그걸 놓치거나 그 줄을 실행 안 한 새 터미널을 열면 이렇게 됩니다.

셸이 brew를 못 찾는 이유

Apple 실리콘 Mac에서 Homebrew는 기본 PATH에 없는 /opt/homebrew에 설치됩니다. 구형 Intel Mac은 보통 PATH에 있는 /usr/local이라 — 같은 설치가 Intel에선 "그냥 되고" Apple 실리콘에선 깨진 듯 보입니다. 되던 설정이 깨지는 다른 이유: PATH 줄을 엉뚱한 파일(비대화식 맥락의 ~/.zshrc 등)에 넣었거나, bash에서 zsh로 바꾼 뒤 더는 안 쓰는 셸에 넣은 경우.

PATH 문제인지 확인하고, brew 위치 찾기

Homebrew가 실제로 설치됐고 어디인지 확인하고, 어떤 셸·아키텍처인지 봅니다:

ls /opt/homebrew/bin/brew /usr/local/bin/brew 2>/dev/null
echo $SHELL
uname -m

uname -m의 arm64는 Apple 실리콘(/opt/homebrew), x86_64는 Intel(/usr/local). $SHELL은 어느 프로필을 고칠지 알려줍니다. ls는 바이너리를 찾는데 셸이 못 찾으면 순전히 PATH 문제입니다.

Homebrew를 PATH에 영구히 추가

  1. 지금 이 셸에 Homebrew를 추가:
eval "$(/opt/homebrew/bin/brew shellenv)"

이 터미널에서 즉시 brew가 동작합니다.

  1. 모든 새 셸에 영구 적용하려면 같은 줄을 zsh 프로필에 추가:
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
  1. Intel Mac이면 /usr/local/bin/brew를 씁니다:
eval "$(/usr/local/bin/brew shellenv)"

실제 사례: 새 M-시리즈 MacBook

새 M-시리즈 MacBook에 Homebrew를 설치하고 설치 관리자의 터미널을 닫은 뒤 새 터미널을 여니 brew --version이 "command not found"라 합니다. ls /opt/homebrew/bin/brew가 바이너리 존재를 보이고 uname -m이 arm64라 PATH 문제일 뿐입니다. echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile을 실행하고 새 터미널을 여니 which brew가 /opt/homebrew/bin/brew를 반환합니다. 줄이 로그인 프로필에 있어 이후 모든 셸이 찾습니다.

새 터미널이 찾는지 확인

새 터미널을 열어 brew가 잡히고 PATH에 있는지 확인:

which brew        # /opt/homebrew/bin/brew
brew --version

새 터미널이 찾으면 — 방금 고친 그 터미널만이 아니라 — 프로필 변경이 이후 모든 세션에 적용된 것입니다.

다시 겪지 않으려면

설치 직후 shellenv 줄을 프로필에 한 번 추가하고 ~/.zprofile(최신 macOS는 zsh)에 두세요. 여러 기기에 dotfiles를 동기화하면 Intel과 Apple 실리콘이 각각 올바른 경로를 로드하도록 경로를 가드하세요.

진짜 brew 오류와의 구분

"command not found: brew"는 PATH 문제 — 프로그램은 있는데 셸이 못 찾음. brew가 찾아져 실행되지만 작업이 실패하는 "Permission denied"나 formula 설치 실패 같은 Homebrew 오류와 다릅니다. 셸이 brew를 아예 못 찾으면 그건 PATH 문제이니 shellenv 줄을 추가하세요.

관련 질문

Apple 실리콘인지 Intel인지 어떻게 아나요?

uname -m을 실행하세요. arm64는 Apple 실리콘(Homebrew가 /opt/homebrew), x86_64는 Intel(/usr/local)입니다.

한 터미널에선 되는데 새 터미널에선 안 됩니다.

현재 셸에서 eval만 실행하고 ~/.zprofile엔 안 넣은 것입니다. 거기에 추가해 모든 새 셸이 Homebrew PATH를 로드하게 하세요.

저는 zsh가 아니라 bash를 씁니다.

같은 eval 줄을 ~/.zprofile 대신 ~/.bash_profile에 넣으세요. 명령은 같고 프로필 파일만 다릅니다.

왜 ~/.zshrc가 아니라 ~/.zprofile인가요?

둘 다 되지만 .zprofile은 로그인 셸에 실행되고 Homebrew의 문서화된 선택으로, 터미널과 로그인 세션에서 PATH를 일관되게 유지합니다.

Intel Mac에서 넘어왔는데 brew가 여전히 /usr/local을 가리킵니다.

프로필에 Intel 경로가 있습니다. Apple 실리콘용 /opt/homebrew/bin/brew로 shellenv 줄을 갱신하고, 새로 설치가 아니라 이전된 거라면 Homebrew를 재설치하세요.

참고 자료

Haneul Seo

Infrastructure engineer · 10+ years running Linux fleets

같은 카테고리 다른 글

Start request repeated too quicklyFixed

systemd: Start request repeated too quickly

systemd는 StartLimitIntervalSec(기본 10초) 안에 StartLimitBurst(기본 5회)보다 많이 시작된 유닛의 시작을 거부하며, Restart=도 이 제한에 포함됩니다. 기본 RestartSec 100ms로는 크래시하는 서비스가 1초도 안 되어 다섯 번을 소진합니다. 저널에서 진짜 크래시를 찾아 고치고, reset-failed를 실행한 뒤, RestartSec로 재시작에 여유를 주세요.

systemd
Too many authentication failuresFixed

SSH: Received disconnect ... Too many authentication failures

agent가 서버가 허용하는 것보다 많은 키를 내밀고 있습니다. sshd가 들여다보는 공개키 하나하나가 MaxAuthTries 시도를 한 번씩 소모하고 — 기본 6회, 하드닝된 호스트에서는 3회인 경우가 많습니다 — 정작 맞는 키는 차례가 오기 전에 연결이 끊깁니다. IdentitiesOnly=yes와 명시적 IdentityFile로 키 하나를 고정하면 시도 횟수가 1로 떨어집니다.

OpenSSH
1722Fixed

Active Directory: 복제가 error 1722(The RPC server is unavailable)로 실패

RPC는 하위 계층이 연결에 실패했을 때 1722(0x6ba, RPC_S_SERVER_UNAVAILABLE)를 보고합니다. 따라서 진짜 원인은 RPC 자신이 아니라 DNS, 차단된 포트, 두 도메인 컨트롤러 중 한쪽의 호스트 설정입니다. repadmin이 어느 파트너가 실패하는지 알려주고, dcdiag /test:dns가 이름 해석을 배제하며, Test-NetConnection과 동적 포트 범위가 방화벽 문제를 가릅니다. 가장 흔한 실수는 TCP 135만 허용하고 49152–65535는 막아 둔 규칙입니다.

Windows Server Active Directory
Windows Server RDSFixed

Windows Server RDS: The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license

120일 RD Licensing 유예 기간이 끝났는데 세션 호스트가 쓸 수 있는 라이선스 서버가 없어 세션을 거부하는 상황입니다. GetGracePeriodDays 의 DaysLeft 가 0 이고 SpecifiedLSList 가 비어 있으면 몇 초 만에 확인됩니다. 해결은 활성화된 라이선스 서버와, 호스트 버전을 감당할 만큼 새 CAL 입니다. 2019 CAL 은 2022 세션 호스트를 서비스하지 못합니다. 여기에 배포 또는 Licensing 정책 설정과 두 서버 사이의 RPC 포트 개방이 따라옵니다.

Windows Server RDS
0x80070035 / Event ID 31017Workaround

Windows 11: NAS 공유 폴더를 열 때 "조직의 보안 정책이 인증되지 않은 게스트 액세스를 차단" (0x80070035)

Windows 10 Enterprise/Education/Pro for Workstations, Windows 11 Pro, Windows Server 2019 이후의 SMB 클라이언트는 기본적으로 게스트 로그온을 거부하고, Windows 11 24H2 Enterprise/Pro/Education 은 게스트 세션이 할 수 없는 SMB 서명까지 요구합니다. 그래서 게스트 접근만 제공하는 NAS 공유는 'block unauthenticated guest access' 대화상자, Error code 0x80070035, 또는 System error 3227320323 으로 실패하고, SmbClient/Security 로그에 Event ID 31017 'Rejected an insecure guest logon' 이 남습니다. Microsoft 가 권하는 해결은 NAS 에 실제 계정을 만들고 펌웨어에서 서명을 지원하게 하는 것입니다. Set-SmbClientConfiguration -EnableInsecureGuestLogons $true(24H2 는 -RequireSecuritySignature $false 까지)는 비상구이며, 그 클라이언트의 서명과 암호화를 포기하는 대가가 있습니다.

Windows (SMB client)
E: Could not get lock /var/lib/dpkg/lock-frontendFixed

Ubuntu/Debian: E: Could not get lock /var/lib/dpkg/lock-frontend — 누가 쥐고 있고 어떻게 기다리는지

다른 패키지 관리자, 대개 부팅 때 persistent systemd 타이머로 발화한 Ubuntu 의 unattended-upgrades 가 여러분의 apt-get 이 도는 동안 dpkg 프런트엔드 락을 쥐고 있는 것입니다. Ubuntu 는 apt 바이너리에만 binary::apt::DPkg::Lock::Timeout "120" 을 실어 두어서 apt-get 은 즉시 포기하고 apt 는 기다립니다. 메시지의 PID 를 읽고, 실행이 끝나게 두거나 apt-get 에 -o DPkg::Lock::Timeout=<초> 를 주고, dpkg --configure -a 는 실제로 중단된 실행 뒤에만 쓰고, 락 파일은 절대 지우지 마세요. 보유자가 종료하면 커널이 푸는 fcntl 락입니다.

APT (Ubuntu/Debian)