2026 OpenClaw를 Mac 클라우드에서 Docker Compose로 24/7: 헬스체크, 리소스 한도, compose pull 업그레이드와 롤백
컨테이너가 떠 있다고 게이트웨이가 일주일을 견딘다는 뜻은 아닙니다. healthcheck와 리소스 제한이 없는 Compose는 자정에 컨테이너가 재시작되거나, 빌드 시 OOM이 나거나, 업그레이드 뒤 토큰 불일치처럼 보이는 문제로 나타납니다. 공식 OpenClaw 이미지를 Mac 클라우드·자가 macOS 노드에서 쓰는 팀을 위해 (1) 세 가지 운영 오해 (2) 임시 단일 컨테이너 vs 프로덕션 Compose (3) 일곱 단계 런북 (4) 수치 앵커 (5) FAQ (6) Mac 평면으로의 수렴을 정리합니다. Exit 137, 볼륨 권한, DNS 글과 프로덕션 하드닝: 노출, 토큰, 샌드박스와 역할을 나눕니다.
목차
1. 오해 세 가지: compose up -d를 끝으로 봄
빠른 시작 가이드는 첫날 터미널이 녹색인 것에 초점을 둡니다. Mac 클라우드의 프로덕션은 SSH 세션이 끊긴 뒤에도 기계가 돌아갈 때만 드러나는 반복 가능한 실패 모드를 걱정합니다. 2026년 인시던트 노트에서 반복되는 패턴은 세 가지입니다.
- 컨테이너 상태만 보며 준비(ready)는 무시:
running이어도18789에 리스너가 없거나 작업 공간 쓰기가 불가능하면, 오케스트레이터·리버스 프록시가 스택을 너무 일찍 healthy로 찍고 채널 재연결만 도배합니다. - 노트북 메모리 숫자를 클라우드 스펙에 복붙: 이미지 리빌드, 의존성 설치, 일회성
pnpm작업은 대화 정상 상태보다 스파이크가 큽니다. 메모리limit이 게이트웨이 유휴 RSS에만 맞으면, 첫compose pull로 리빌이 트리거될 때 OOM이 납니다. Exit 137 가이드와 같은 뿌리이나 첫 부팅이 아니라 업그레이드 단계에서 터집니다. - 타이핑을 줄이려
latest만 씀: 무인 호스트에서 떠다니는 태그는 편의가 아니라 기록되지 않은 구성 이전(migration)입니다. 설정 트리 tar과 고정 digest 없이는 롤백이 감(感)에 의존합니다.
빌드, 콜드 스타트, 안정 프록시 트래픽에 시간창을 나누세요. Compose는 서비스마다 리소스 봉투와 재시작 정책을 다르게 둘 수 있어, 모든 것이 docker run 히스토리 한 덩이일 때는 문서화가 어렵습니다.
2. 판단 표: Mac 클라우드에서 임시 컨테이너 vs Compose
이 표는 이해관계자에게 실제로 갖게 된 운영 기능이 무엇인지 맞춥니다. CPU가 아니라 토큰·네트워크 노출이면 하드닝 문서로 점프할 위치도 보여 줍니다.
| 필요 | 단일 임시 컨테이너 | Compose + Mac 클라우드 | 비고 |
|---|---|---|---|
| 문서화된 준비(ready) 확인 | 수동 curl과 기도 | healthcheck와 정렬된 depends_on | 프로브는 bare TCP가 아니라 애플리케이션 준비를 봐야 함 |
| 빌드 vs 런타임 메모리 분리 | 한 limit에 몰빵 | 프로필이나 별도 서비스로 빌드 상한 확대 | 업그레이드 시 Exit 137 감소 |
| 감사 가능한 업그레이드 | 떠다니는 latest | 불변 tag@digest와 변경 로그 | 롤백은 태그 스왑 + tar 복원 |
| 보안 면 | 바인드 마운트·bridge 범위를 잊기 쉬움 | 네트워크·read-only가 Git에 있음 | 토큰·샌드박스 하드닝과 쌍 |
3. 일곱 단계 런북: 기준선에서 롤백까지
- 기준선 동결: Docker Engine·Compose 마이너, RAM 여유, 레이어가 루트 볼륨 대비 어디 쌓이는지 기록하고 내부 위키 부록에
df -h를 넣습니다. - 최소
compose.yaml:restart정책, 볼륨에 명시적 호스트 경로, uid를 맞춰 게이트웨이 유저가Permission denied와 끊임없이 싸우지 않게 합니다. - 헬스 작성: 프로브는 TCP만이 아니라 게이트웨이가 초기화를 끝냈는지 봅니다.
interval은 콜드 스타트 P95를 넘어야 하고, 새 메이저 이미지는start_period를 처음 한 번 측정해 넉넉히 둡니다. - 리소스 막대: 서비스별 CPU·메모리 limit을 두고, 장기 게이트웨이 cgroup과 먹이를 같이 쓰면 안 되는 빌드·마이그레이션 job은 별 limit이나 프로필을 씁니다.
- 업그레이드 전 백업: env, 마운트된 설정 디렉터리를
tar로 묶고 같은 티켓에docker image ls --digests를 붙입니다. 자동이 사람의 기억을 이깁니다. - 업그레이드 경로:
docker compose pull후 티켓 열린 채up -d— 스모크가 깨지면 이전 불변 태그로 한 변경에 되돌리고 tar을 복원합니다.docker compose ps옆에18789에 대한 curl·CLI 프로브를 같이 둡니다. - 롤백 후 검증: 채널 스모크, 모델 리스트, JSONL·구조적 로그에서 재연결 루프를 보고, 하드닝 문서에 남은 토큰 범위·샌드박스 항목을 체크합니다.
4. 참고 수치: 메모리, 재시도, 이미지 태그
아래는 리뷰 대화의 출발점일 뿐, 이미지·Mac 클라우드 플랜으로 항상 재측정하십시오. 첫째, Apple 실리콘급 클라우드에 장기 게이트웨이만 둔다면 플랜 상한 아래 2~4GB 정도의 완충(swapable margin)을 남기고, 측정한 정상 RSS의 약 1.2~1.5배를 메모리 limit의 출발선으로 잡을 수 있습니다. 둘째, healthcheck.start_period는 그 디스크·CPU에서 잰 콜드 스타트 P90의 1.2~1.5배 이상, interval은 대략 20~45초, retries는 온콜 가이드가 허용하는 편집(블립) 길이에 맞춥니다. 셋째, 감사를 위해 현재·이전 릴리스는 불변 태그나 digest로 두고, CI가 IMAGE_TAG에 변경 링크를 박습니다. 넷째, 18789를 SSH 터널로 쓰면 루프백·터널·라이브 채널을 한 번에 봅니다. 다섯째, 설정 트리 백업은 기본 브랜치에 gateway 설정이 합쳐질 때마다, 이미지만 롤백하고 시크릿은 안 맞는 상황을 피합니다. 여섯, 수치 기준선 없는 팀은 예산 선도 없고, Docker 복잡도는 조용한 인력 세금이 됩니다.
5. 자주 묻는 질문
TCP로 18789를 보면 헬스로 충분한가요?
의도적으로 false positive를 받는 경우가 아니라면, 초기화가 끝났음을 보이는 HTTP나 CLI 점검을 쓰는 것이 낫습니다.
업그레이드 뒤 게이트웨이는 뜨는데 채널이 전부 빨강인가요?
토큰 파일·채널 설정을 먼저 diff하고, 상위 모델 API를 탓하기 전에 하드닝 문서의 샌드박스·노출 체크리스트를 걷습니다.
헬스 없이 restart: always만이면?
프로세스는 다시 띄우지만 명확성은 안 줍니다. 업타임만 보고 건강하다고 착각해 무한 크래시 루프를 막지 못합니다.
6. Docker 추상화에서 제어 가능한 Mac 평면으로
컨테이너는 패키징에는 훌륭하지만, 24/7 Mac 클라우드에서는 볼륨·브리지·이미지 태그라는 노트북 데모엔 없던 표면이 추가됩니다. 추상화마다 Git으로 버전 관리·한도·백업이 없다면 야간 pager 한 줄씩 늘어납니다. 임시 docker 명령이 빨라 보여도, 실행한 사람이 오프라인일 때 호스트는 여전히 SLA를 지어야 합니다. 집에 둔 노트북급 머신은 데이터센터 전원·상행·격리가 없어 Docker로 운영 계약을 대체하기 어렵습니다. 리더십이 서명할 수 있는 형태로 OpenClaw·채널이 필요하다면, 고정 게이트웨이·빌드 평면을 위해 VPSMAC M4 Mac 클라우드 용량을 쓰는 쪽이, 약한 개인 하드웨어 위에 컨테이너를 쌓는 것보다 대개 예측 가능합니다. SSH는 그대로, 모델·감사 추적은 유지되며, 하드닝·관측·Exit 137 런북이 사이트에 이미 있는 것과 일렬로 맞고, docker ps 발굴에 갇히지 않습니다.