1. 문제 분해
(1) 경로 분열: 홈의 전역 설정, 컨테이너 볼륨, 저장소의 openclaw.json이 엇갈리면 reload가 안 된 것처럼 보입니다. (2) Node 22는 팀 전체 계약입니다. (3) 업그레이드 순서: 이미지만 바꾸고 볼륨 스키마를 두면 반쯤 마이그레이션 상태가 됩니다. (4) 관측·권한 드리프트: sudo로 깐 전역 패키지와 사용자 npm prefix가 섞이거나 launchd 실행 계정과 상태 디렉터리 소유자가 다르면「프로세스는 살아 있는데 상태를 못 쓴다」는 가짜 정상이 납니다. runbook에 실행 사용자·작업 디렉터리·umask를 고정하세요.
2. 세 경로 매트릭스
| 축 | npm 전역 | Docker Compose | pnpm 소스 |
|---|---|---|---|
| 속도 | 가장 빠른 시험 | 중간 | 느림, 감사 적합 |
| 격리 | 약함 | 강함 | 중간 |
| 영속성 | 홈 문서화 | 볼륨 필수 | 실행 방식 의존 |
| 업그레이드 | npm i -g | 태그+pull | git+pnpm+build |
| 롤백 | 버전 고정 | 태그+스냅샷 | git 태그 |
3. 다섯 단계
- 런타임 고정: Node 22+ 또는 README가 밝힌 LTS 대역을 전 환경에 통일하고「미지원 구간」을 문서화합니다. Docker는 compose 파일명·이미지 참조(태그 vs digest)·베이스 이미지 변경 권한까지 동결합니다.
- 네 가지 디렉터리 지도: 설정·비밀·세션/스킬 상태·로그를 그림으로 남기고, compose 주석에 호스트 바인드 경로를 적어 인시던트 때 컨테이너 내부 경로만 쫓지 않게 합니다.
- 골든 패스: onboard→최소 채널 스모크→포그라운드 Gateway→launchd/데몬까지 기대 로그와 정상 판정을 runbook에 명령 단위로 적습니다.
- 업그레이드 SOP: 변경 티켓→볼륨/디렉터리 백업 또는 스토리지 스냅샷→업그레이드→doctor→channels probe. 백업 생략은 체크리스트에서 차단합니다.
- 롤백 SOP: 패키지/이미지와 데이터를 세트로 되돌린 뒤 무대응 런북의 status/doctor를 다시 돌리고 복구를 선언합니다.
4. 수치
- 두 형태를 14일+ 문서 없이 병행하면 주당 2~4시간 손실.
- 프로덕션은 한 번 이상 복구 가능한 스냅샷과 함께.
- 원격 Mac은 launchd WorkingDirectory를 CLI와 맞출 것.
5. 원격 Mac
| 신호 | 조치 |
|---|---|
| 7×24 필요·노트북 수면 | VPS 또는 원격 Mac+launchd |
| DNS/NTP 불일치 | 단일 토폴로지 |
| Apple 크리에이티브 동일 SLA | 원격 Apple Silicon |
변경 규율: 티켓이나 구성 관리에「설치 형태·볼륨 ID·온콜 담당」삼총사를 묶습니다. 없으면 사후 분석은「어딘가에서 돌았다」로 끝납니다. 원격 Mac에선 SSH 점프·화면 공유·Gateway 헬스 알림 경로를 나눠 노이즈에 진짜 장애가 묻히지 않게 하세요. 분기마다「스냅샷 복원 + channels smoke」훈련을 하면 실제 장애 시 야근 비용이 크게 줄어듭니다.
6. FAQ
전역 CLI로 컨테이너 Gateway를 다룰 때 URL·토큰·경로를 한 표에 모으지 않으면「CLI는 A, 데몬은 B」가 됩니다. rootless Docker는 UID 매핑과 compose user 명시가 핵심입니다.
pnpm CI는 pnpm i --frozen-lockfile 고정, 테스트 Gateway 상태 경로를 프로덕션과 분리합니다. 업그레이드 후 채널 침묵은 세 번 재설치하기 전에 doctor·pairing부터 — 진단 사다리.
compose healthcheck? Gateway에 최소 생존 신호(HTTP/TCP 등)를 두고 restart와 백오프 상한을 변경 티켓에 적어 반쯤 기동 상태의 재시작 폭풍을 막습니다. dev/stage/prod 스냅샷 절차 공유? 절차만 공유하고 비밀·토큰은 공유하지 마세요. 환경별로 복원 연습을 따로 합니다.
7. 심층
2026년엔 기능보다 단일 소스가 병목입니다. npm은 속도, Docker는 격리·볼륨 규율, pnpm 소스는 감사 가능성과 빌드 책임의 트레이드오프입니다.
Docker 운영에선 이미지 태그 정책(실험만 latest, 프로덕션은 불변 태그·digest), 백업 시간대(채널 한산 시간), compose 프로젝트 이름 규칙을 한 페이지에 모아「누가 어떤 스택을 고쳤는지」를 감사 가능하게 합니다. pnpm은 corepack·.npmrc·사설 레지스트리 미러를 코드 리뷰 대상에 넣지 않으면 야간 빌드에서 의존성 트리가 흔들립니다.
CS/운영 자동화에선 예측 가능한 롤백과 재현 가능한 환경이「항상 최신」보다 우선입니다. 스냅샷 없는 실패 업그레이드는 며칠 단위 손실로 이어지고 SLA에선 전용 원격 Mac 월 비용보다 비쌀 수 있습니다. 설치 형태를 운영 반경으로 보면 반경이 넓을수록 병렬 변경·교대·외주 인수인계를 견딥니다.
장시간 Gateway와 무거운 툴 호출은 전용 원격 Mac으로 빼고 노트북은 가벼운 CLI·디버그에 두는 패턴이 늘고 있습니다. Final Cut·Xcode와 통합 메모리를 싸우지 않게 하며 Docker/npm을 부정하는 게 아니라 대화형과 서버형을 물리적으로 분리합니다. 프로덕션은 고정 토폴로지(베어 메탈 launchd 또는 단일 compose 스택), 노트는 채널 페어링·스킬 검증에 집중해 뚜껑 닫으면 자동화가 죽는 사고를 설계로 제거합니다.
출시 전 체크리스트 추가: 전역 설치는 PATH에 openclaw 바이너리가 하나만 잡히는지 확인합니다. Compose는 .env와 시크릿 저장소(Vault 등) 정책이 맞는지, 프로덕 토큰이 노트 동기화 폴더에 남지 않는지 봅니다. pnpm 소스는 CI와 배포기의 registry·스토어 정책이 같아야 하며, 그렇지 않으면 lockfile이 같아도 트리가 달라지는 유령 의존성이 생깁니다. 스튜디오·크리에이티브 팀은 인코딩·썸네일 배치와 Gateway를 한 기기에 얹을 때 발열·스로틀링으로 지연이 튀는 경우가 많아, 임대 전용 Apple Silicon 노드로 상주 부하를 빼는 편이 SLA 측면에서 더 예측 가능합니다.
감사·협업 보강: 런타임 버전을 바꿀 수 있는 담당자 명단을 위키나 저장소에 남기고, Docker는 compose 파일을 코드 리뷰·IaC 파이프라인에 포함해 이미지 태그 변경이 추적되게 하세요. pnpm은 package.json의 engines와 CI 이미지 Node 버전을 분기마다 대조합니다. 클라우드 동기화 도구가 openclaw.json에 충돌 사본을 만들면 reload가 된 것처럼 보이지만 실제로는 옛 설정을 읽는 상황이 생기므로, 동기화 제외 경로를 배포 가이드에 명시하세요. 다국적 팀은 타임존·채널 운영 시간이 어긋날 때 장애 알림이 한 언어/한 지역에만 쏠리지 않게 에스컬레이션 경로를 이중화하는 것이 안전합니다.
노트북 하나에 인코딩·썸네일 배치와 Gateway를 동시에 올리면 열 설계 때문에 CPU·GPU가 번갈아 스로틀되며 채널 지연이 꼬리가 두꺼워집니다. 전용 임대 Apple Silicon 노드에 Gateway만 상주시키면 지연 분포가 좁아져 실시간 응답형 봇에 체감이 큽니다. 여기서 비교 대상은 스펙 시트의 클럭이 아니라 관측 가능한 p95·p99 지연과 야근 시간입니다.
8. MACGPU
(1) 각 경로의 한계: 전역은 시스템 Node·권한·엔드포인트 보안/MDM과 충돌하기 쉽습니다. Docker는 볼륨·이미지 규율이 필요하고 DNS/NTP 드리프트가 있으면 디버깅 비용이 기하급수로 늘어납니다. 소스는 lockfile·CI 규율이 없으면「빌드는 되는데 Gateway만 불안정」이 됩니다. 문서 없이 혼용하면 설정 드리프트가 폭발합니다.
(2) 원격 Mac: Apple Silicon·통합 메모리·크리에이티브/자동화 스택이 맞물려 24/7 Gateway에 유리합니다. launchd를 대화형 세션과 분리하면 채널 지터·GUI 방해가 줄고 운영 경계가 선명해집니다.
(3) MACGPU: 낮은 진입장벽으로「단일 경로+launchd 상주」를 검증하려면 전용 원격 Mac 임대로 대규모 CAPEX 전에 실측하세요. CTA는 로그인 없이 공개 플랜으로 연결합니다.