OpenClaw 설치 가이드를 마쳤는데도 “CLI는 동작하는데 Gateway는 응답하지 않는다”, “모델 타임아웃”, “WSL2에서 데몬이 유지되지 않는다”와 같은 증상이 남아 있다면 설치 단계를 다시 붙여 넣기보다 설치 이후 검증과 증상 분류가 필요합니다. 본 글은 세 플랫폼 설치, Docker 프로덕션, Secrets·PDF 고급 가이드와 역할을 나누어 증상 매트릭스, 여섯 단계 런북, 운영 지표 세 가지만 전달하며, WSL2와 네이티브 Linux·macOS 차이를 함께 정리합니다.
장기 실행 Gateway, 모델 이그레스, 로컬 데몬이 함께 있는 환경은 “각각 단독으로는 괜찮아 보인다”는 식으로 깨지기 쉽습니다. 당번 대응 시에는 일회성 설정 오류와 간헐적인 네트워크·전원 정책 문제를 구분합니다. 표를 읽기 전 아래 다섯 가지에 먼저 맞춥니다.
당번용 표입니다. 정확한 CLI 이름은 설치한 OpenClaw 버전을 따릅니다. 깊은 조사 전에 doctor 또는 이에 상응하는 점검을 우선합니다.
| 보이는 현상 | 유력한 방향 | 우선 시도 |
|---|---|---|
| 프로세스가 즉시 종료됨 | Node 버전, 권한, 작업 디렉터리 | 공식 Node 기준선에 맞춤; doctor 실행; 설치 사용자와 데이터 디렉터리 권한 확인 |
| Gateway 포트가 조용함 | 바인드 주소, 포트 충돌, 방화벽 | 리스너 확인; 로컬에서 헬스에 curl; 호스트와 상위 보안 그룹 확인 |
| 모델 타임아웃 또는 스트림 끊김 | 이그레스, DNS, 프록시, 리전, 쿼터 | 최소 요청 테스트; 프록시 우회; 쿼터와 엔드포인트 리전 확인 |
| WSL2에서만, 베어 리눅스는 정상 | 파일시스템 성능, 가상 네트워킹, systemd 공백 | 저장소는 WSL ext4에 둠; 드라이브 간 거대한 트리는 피함; systemd·사용자 세션 전략 검증 |
| 절전·업데이트 후에만 실패 | 노트북 전원 정책과 데몬 복구 | 전원 설정; GUI 세션과 함께 데몬이 죽는지; 전용 호스트 필요 여부 |
# 설치 후 점검(CLI 이름은 환경에 맞을 수 있음)
openclaw doctor
curl -fsS "http://127.0.0.1:${OPENCLAW_GATEWAY_PORT:-PORT}/health" || true
WSL2: /mnt/c에서의 무거운 빌드나 파일 감시는 리눅스 파일시스템보다 느리고 이벤트를 놓칠 수 있습니다. 장기 실행 Gateway는 저장소와 데이터를 WSL 리눅스 볼륨에 두고, systemd·세션 수명 주기는 별도로 검증합니다.
아래 단계는 Docker 헬스 점검 습관을 베어메탈·하이브리드에도 적용한 것으로, 각 수용 기준은 반복 가능해야 합니다.
문서를 대체하지는 않지만 리뷰와 당번을 맞춥니다.
절전, 업데이트, 권한 대화상자가 장기 프로세스를 끊고, WSL2와 네이티브 Windows 네트워킹은 더욱 갈라집니다. OpenClaw Gateway를 팀이 의존해야 한다면 전용이고 관측 가능한 Apple Silicon 호스트가 끝없는 로컬 우회보다 낫습니다.
MACCOME은 안정적인 Gateway와 자동화에 맞는 멀티리전 베어메탈 원격 Mac을 제공합니다. 설치와 Docker 글을 거친 뒤에도 절전과 데몬 복구가 계속 아프면 고객 센터에서 시작해 요금과 리전을 맞춥니다.
단기 노트북 디버깅에는 본 여섯 단계 체크리스트와 헬스 스크립트를 마칩니다. CI나 24/7 에이전트가 필요해지면 로컬 패치를 쌓기보다 전용 원격 Mac으로 옮기는 방안을 검토합니다.
FAQ
설치 가이드에 이미 명령이 있는데 왜 이 글인가요?
세 플랫폼 설치 가이드는 설치 방법을 다루고, 본 글은 건강을 증명하고 증상을 분류하는 데 초점을 둡니다.
Docker 프로덕션 글과 중복되나요?
아닙니다. Docker 프로덕션 런북은 이미지와 Compose에 초점을 두고, 본 글은 설치 후 점검·프로브·WSL2·네이티브 간격을 다룹니다.