curl | bash 설치만으로 끝이 아니며 업그레이드를 게이트웨이 릴리스로 보는 팀은 stable·beta·dev가 npm과 git 두 축에 어떻게 대응되는지, openclaw update가 재시작 전후에 무엇을 기본으로 하는지, 채널이 모두 끊긴 느낌일 때 pin과 gateway 재시작 순서로 어떻게 관측 가능한 상태를 되찾을지를 명확히 합니다. 글은 사고 패턴부터 채널 대조·명령 뼈대·6단계 변경 창·클라우드 Mac 상주 호스트 순으로 이어지며 사이트 Lobster 설치글과 Linux VPS 대 클라우드 Mac 진단 글과 서로 링크합니다.
업그레이드를 릴리스처럼 다루지 않을 때 나타나는 다섯 신호
첫째는 바이너리와 설정 불일치입니다.openclaw --version만 새 semver인데 사용자 레벨 systemd·launchd가 옛 경로를 가리면doctor가 매번 서비스 엔트리를 다시 쓰라고 합니다.둘째는 플러그인과 채널 혼선으로 dev 워킹디렉터리와 npm 글로벌을 섞어 스킬이 반쯤 뜨고 ClawHub에 ENOENT가 납니다.
셋째는 새 빌드에서 엄격해진 게이트웨이 포트·토큰입니다.gateway.mode와 루프백 바깥 bind에 토큰이 먼저 필요하면 릴리스 노트를 건너뛴 채 로그만 보고 방화벽 탓하기 쉽습니다.넷째는 자동 재시작과 사람이 읽는 순서 충돌로 드라이런을 보고 싶었는데 앞 단계 작업이 이미openclaw gateway restart를 끝낸 상태에서 채널 가짜 오프라인을 모델 정책 탓으로 돌립니다.다섯째는 순수 채널 정책 문제로 프로세스가 살아 있으면 연결됐는데 무응답 가이드를 따라야 합니다.
doctor는 업데이트가 있는데 셸 semver가 다르다:Node 경로가 여러 개이거나 글로벌 prefix가 얽혔습니다.
설정 마이그레이션을 건너뛴 뒤 재시작:토큰과 정책이 죽은 경로에 남습니다.
Git 전용 설치에 npm 채널만 얹었다:install 종류부터 공식 절차로 통일해야 합니다.
자동 업데이트 지터가 릴리스 주와 겹침:stable도 롤아웃이 늦을 수 있어 CDN 장애로 단정하지 마세요.
클라우드 Mac에서 launchd와 사용자 세션 정의가 이중:스크립트가 두 번 돌며 plist가 중복됩니다 헬프 절차와 대조합니다.
다섯 가지를 주간 회고에 풀로 쓰면 「게이트웨이 괜찮아」 같은 모호함보다 낫습니다.리전 간 계획에도 같은 틀이 통합니다 사무실이든 전용 장비든 규칙은 같습니다.
stable·beta·dev와 두 종류 설치 배경 정렬하기
npm에서는 latest 후보안정이며 베타 미러가 느리면 latest 경로로 안내됩니다.
| 축 | stable | beta | dev |
|---|---|---|---|
| npm 의미 | dist-tag latest | beta가 latest로 떨어질 수 있음 | 먼저 git checkout |
| 리스크 | 적어도 doctor 필요 | 중간 기능 시험 | main 속도 높음 위험 최대 |
| 플러그인 | npm 플러그인이 CLI와 일치 | stable과 비슷한 복귀 | 번들은 checkout에 종속 |
| 7×24 게이트웨이 | 기본 채택 | 카나리 또는 스테이징 | 단기 실험이나 저부하만 |
최신과 안정 양쪽에 동시 베팅하려면 최소 두 장비 모델이 필요합니다 dev 채널 맥박으로 고객 SLA 시계를 맞추지 마세요.
플러그인 열을 아키텍처 다이어그램에 붙이면 누가 누구를 버티는지 한눈에 드러납니다 「느낌」보다 운영에 유리합니다.
openclaw update·--dry-run와 수동 pin 롤백 뼈대
적용 전에 변경 창에서 드라이런을 실행합니다.--no-restart면 산출물과 doctor부터 보고 게이트웨이 재시작을 손으로 둡니다.채널이 업그레이드 중 무너지면 버전 고정 후 서비스 재시작 다음 doctor 순이 짧으며 순서를 뒤집으면 셸이 옛 파일 핸들을 들고 있습니다.
openclaw update --dry-run --channel stable openclaw update --channel beta npm i -g [email protected] openclaw gateway restart openclaw doctor openclaw gateway status openclaw logs --channels --tail 120
알림:openclaw update는 성공 시 게이트웨이 재시작을 포함하는 경우가 많습니다 병렬 CI면 재시작을 직렬화하세요 같은 상태 디렉터리를 두 에이전트가 두지 않게 합니다.
LaunchAgent 보조작업과 크론이 함께 있으면 누가 게이트웨이를 띄우는지 한 가지 근본만 허용하세요 사이트의 Linux VPS 대 클라우드 Mac 글에 있는 호스트 모델을 티켓에 넣어두면 순서 합의가 빠릅니다.
여섯 단계로 검토 가능한 게이트웨이 업그레이드 창을 만든다
현 채널과 flavor 확인:openclaw doctor·openclaw update status 스크린샷을 남긴다.
드라이런과 diff 저장:바뀌는 파일 목록과 rebuild 발생 여부를 적는다.
유지관리 창에 진입:채널은 읽기 전용 브리핑 또는 자동 작업을 미룬다.
실제 적용과 순차 재시작:리스닝·systemd·LaunchAgent 상태를 확인한다.
약 2분 콜드스타트 뒤 탐색:문맥이 짧은 채널 ping을 튼다.
실패하면 pin:버전 되돌리고 재시작하고 최소한의 초록 확인과 이미지를 변경 기록에 붙인다.
세 줄 하드 리스크에서 전환으로 이어진다
「업그레이드 완료」에는 doctor와 gateway와 채널 한 건의 종단 테스트가 함께 있어야 티켓을 닫는다.
자동 업데이트 지터 사용 시 허용 지연 시간을 문서화해 사람과 로봇이 같은 시계와 싸우지 않도록 한다.
롤백 후 왜 업그레이드 전에 보지 못했는지 한 줄을 남겨 pin이 상시 상태가 되지 않게 한다.
주의:명령과 플레이스홀더는 현장 오케스트레이터·패키지 규약과 같아야 합니다 인터넷 스크린샷으로 현지 상태를 바꿔 끼우지 마세요.
공유 PC 글로벌npm 반복보다 회계 가능한 클라우드 맥 미니 한 대에 게이트웨이·브라우저 업무 같은 창을 합치는 편이 낫습니다.MESHLAUNCH 클라우드 Mac Mini 대여가 변수를 줄입니다.
패키지 관리자로 CLI만 올렸다면 게이트웨이를 재시작해 새 바이너리를 읽고 이어 콜드 스타트 뒤 doctor와 채널을 돌립니다. 설치 프로그램이 서비스 진입점 수정을 먼저 요구하면 그 순서를 따릅니다. 실무 순서는 OpenClaw Lobster 클라우드 Mac 워크플로 가이드의 데몬 절과 맞출 수 있습니다.
권하지 않습니다. 생산 게이트웨이는 stable로 두고 dev는 단명 인스턴스로 빼는 편이 안전합니다. 호스트 차이는 Linux VPS와 클라우드 Mac 진단글을 보면 실험 트래픽 위치 정하기가 쉬워집니다.
먼저 리스닝 포트와 토큰을 게이트웨이 층에서 확인하고 채널 계층 점검 글로 이어가세요. 오래 두어야 할 노드면 지역과 기간을 Mac Mini M4 대여 가격 페이지에서 고르고 Mac Mini 고객 센터의 정리 절차도 함께 봅니다.