캐나다 리전 Mac mini M4 클라우드에 OpenClaw를 올릴 때 추상적인 ‘최고 설치기’보다 중요한 것은 재부팅·이미지 갱신·SSH/VNC 인수인계 뒤에도 운영자가 같은 절차로 되풀이할 수 있는 경로입니다. 대표적으로 업스트림 install.sh 부트스트랩, Apple Silicon에서 /opt/homebrew/bin/openclaw에 두기 좋은 Homebrew, 이미 Node 표준을 쓰는 조직에 맞는 npm 세 가지가 있습니다. 각각 바이너리 위치, launchd 아래 PATH, 업그레이드 리스크를 바꾸고 Gateway는 계속 TCP 18789를 씁니다. 여기서는 경로별 차이, M4 자원 계획, 증상→조치만 짧게 정리합니다. 설치 이후 openclaw onboard·doctor·LaunchDaemon 운영은 팀 위키에 절차와 로그 키워드를 함께 적어 두는 편이 안전합니다.
install.sh, Homebrew, npm: 실제로 무엇이 다른가
install.sh(또는 문서의 원라이너)는 새 호스트에 검증된 스택을 빨리 깔 때 유리합니다. 번들 Node, CLI 배치, openclaw onboard 다음 단계 출력까지 한 번에 처리하기 쉽습니다. 대신 드리프트 관리가 필요합니다. curl-to-bash와 같이 스크립트 URL·체크섬 정책을 기록하고, 프로덕션 확정 뒤에는 내부 위키에 버전을 고정하세요.
Homebrew는 Apple Silicon 클라우드 Mac에서 formula/cask가 예측 가능한 prefix에 깔리고, 업그레이드가 brew upgrade openclaw(이름은 예시)처럼 단순하며, /opt/homebrew 감사에 익숙한 팀에 맞습니다. Gateway 옆 다른 CLI와도 잘 짝지어집니다. 날카로운 부분은 Brew 공통입니다. launchd 작업은 대화형 ~/.zprofile을 읽지 않으므로 plist에는 openclaw 절대 경로를 쓰거나 PATH=/opt/homebrew/bin:...를 명시해야 합니다.
npm(전역 또는 버전 관리자 하 per-user)은 같은 호스트에 다른 Node 서비스를 두는 경우 매력적입니다. JS 팀이 이미 아는 semver·락파일을 그대로 씁니다. 대신 Node 메모리 패턴을 물려받습니다. 전역 바이너리가 사용자별 트리에 있을 수 있고, 한 대에 Node 메이저가 여러 개면 ‘내 셸에서는 됨’ 회귀가 sudo 없는 정책 변경 뒤에 터지기 쉽습니다.
| 경로 | 적합한 경우 | 원격 Mac에서 주의 |
|---|---|---|
install.sh |
빠른 부트스트랩, 그린필드 호스트 | URL·버전 문서화; OS 업그레이드 후 재실행 정책 |
| Homebrew | Brew에 익숙한 운영, 바이너리 경로 명확 | plist PATH vs 로그인 셸; 런북에 formula 리비전 고정 |
| npm / pnpm global | Node 비중 높은 플릿, 공통 Node 정책 | 사용자 vs 전역 prefix; Node 메이저 엇갈림; 설치 시 RAM 스파이크 |
어떤 경로든 같은 운영 점검으로 수렴합니다. openclaw --version, openclaw doctor, 그다음 헤드리스 SSH로는 불가능한 프롬프트가 있을 수 있으니 GUI 가능한 맥락에서 openclaw onboard를 의도적으로 한 번 돌립니다. CLI가 디스크에 올라간 뒤 gateway.remote.token, 터널, 직접 노출이 어떻게 맞물리는지는 OpenClaw 2026 캐나다 원격 Mac M4: SSH 터널 vs 직접 Gateway? gateway.remote.token, 포트 18789, PATH, launchd를 참고하세요.
Gateway 18789와 캐나다 M4 자원 계획
지리가 Gateway 바인딩 방식 자체를 바꾸지는 않지만, 캐나다 노드는 북미 지연과 주요 모델 API로의 피어링 때문에 자주 선택되므로, CPU·RAM 작업이 전부 로컬에서 일어난다고 가정하고 사이징하는 편이 안전합니다. Node(게이트웨이 런타임), 로그 증가, 에이전트가 내장 Chromium을 쓰면 간헐 브라우저 자동화까지 여유를 둡니다. 단일 중간 부하 에이전트라면 중간 티어 M4에 통합 메모리를 넉넉히 두어 Node·OS 페이지 캐시·npm/Brew 업그레이드 스파이크가 한꺼번에 경쟁하지 않게 합니다. 같은 호스트에서 긴 컴파일, 아티팩트 동기화, 병렬 테스트 샤드를 돌리면 RAM만큼 디스크·동시성도 1급 제약입니다. 티어 정렬은 2026 원격 Mac 장주기 개발·테스트: 디스크·동시성 병목, 캐나다 노드로 북미 협업·아티팩트 동기화, M4 확장·병렬 의사결정 매트릭스(아태 FAQ)를 보세요.
lsof -iTCP:18789).zshrc만으로는 부족방화벽과 바인드 모드를 함께 설계하세요. 루프백만 열고 SSH 포트포워드는 추론이 단순합니다. 직접 접속으로 넓히려면 TLS나 공급자 엣지 규칙 뒤에서 토큰 인증까지 검증한 구성이어야 합니다. 업그레이드마다 포트 소유 프로세스가 하나인지 확인하세요. 중복 LaunchAgent는 헬스체크 들쭉날쭉의 흔한 원인입니다.
설치 후 흔한 오류: 빠른 분류
command not found: 대개 SSH 세션과 Gateway 데몬의 PATH 불일치입니다. plist에 절대 경로 ProgramArguments 또는 인라인 PATH= 접두를 넣고 작업을 다시 부트스트랩하세요.
18789에서 EADDRINUSE: 남은 gateway 또는 설치기 중복 실행입니다. 서비스를 깨끗이 중지하고 중복 plist를 제거한 뒤, 고아 리스너가 의심되면 한 번 재부팅하고 openclaw gateway status로 재확인합니다.
원격 클라이언트 401·토큰 오류: UI에서 토큰을 바꿨는데 launchd가 읽는 설정에는 반영되지 않은 경우입니다. 데몬을 실행하는 사용자 맥락과 gateway.remote.token을 맞추고, 대화형 셸의 export 한 줄에만 두지 마세요.
npm 특유: 내 계정으로 전역 설치는 됐는데 데몬은 다른 계정이거나, CLI 재설치 없이 Node만 올라간 경우입니다. 사용자·Node 메이저·전역 prefix를 정렬하고, 소유권이 자주 바뀌면 Homebrew나 문서화된 단일 스크립트 경로를 선호하세요.
launchd와 비슷한 최소 환경의 비로그인 래퍼에서 openclaw doctor를 돌린 다음 Gateway를 정상이라고 선언하세요.
openclaw에 명시적 PATH(사용자·plist 스타일은 환경에 맞게 조정)
PATH=/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin /opt/homebrew/bin/openclaw gateway status
요약
속도가 필요하면 install.sh, Apple Silicon에서 경로 예측과 운영 친숙도는 Homebrew, 플릿이 이미 Node로 표준화돼 있으면 npm — 그다음 지루한 부분을 엄격히: launchd용 절대 바이너리 경로, TCP 18789 단일 소유자, 데몬 사용자에게 보이는 토큰, 문서화된 업그레이드 절차입니다. 캐나다 M4 미니를 클라우드에서 쓸 때는 벤치마크 승자보다 이 규율이 더 중요합니다. 재부팅과 인력 교대는 계획 여부와 관계없이 일어나기 때문입니다.