2026 MacLogin 클라우드 Mac OpenClaw Telegram·WhatsApp 채널: 페어링, dmPolicy, probe 트러블슈팅

MacLogin mini에서 openclaw onboard --install-daemon까지 마친 팀이 다음에 막히는 지점이 여기입니다. openclaw gateway status는 녹색이고 SSH 터널로 Control UI도 열리는데 Telegram DM은 무음이고 WhatsApp 그룹은 Agent를 깨우지 않습니다.2026년 5월 21일자 글에서는 Telegram botToken·dmPolicy 설정, WhatsApp QR 세션 재연결, openclaw channels status --probe와 로그 기반 진단(감으로 token만 바꾸지 않음)을 설명합니다. 정책 매트릭스, 채널별 절차, 증상 대조표, 홍콩·일본·한국·싱가포르·미국 노드용 프록시/DNS 기준을 얻을 수 있습니다. 먼저 onboard·데몬 설치, curl 헬스 모니터링을 읽고 probe 이상 시 stderr 진단을 참고하세요. 입구: 도움말, 요금, VNC.

렌탈 게이트웨이에 메시지 채널이 필요한 사람 — 「연결됐는데 무음」이란

독자는 OpenClaw를 7×24 Agent 접수에 씁니다: 알림은 Telegram, 영업은 WhatsApp 그룹 @, 엔지니어는 같은 Mac mini에 SSH. 실패는 눈에 잘 안 띕니다 — 설정에 채널은 있는데 응답이 없습니다. 페어링 대기열, 멘션 규칙, 오래된 webhook이 배달을 막는 경우가 많습니다.

• 페어링 지연:첫 DM은 openclaw pairing list 승인이 필요합니다. 미승인 시 정책이 조용히 거부합니다.
• Token 로드 경합:게이트웨이 기동 시 env가 준비되기 전 ${TELEGRAM_BOT_TOKEN}을 참조하면 getMe가 401입니다.
• WhatsApp QR 드리프트:Baileys 세션 만료. 「어제 스캔」을 「지금도 유효」로 착각합니다.
• 그룹 멘션:기본 requireMention에서 @ 없으면 계속 무음입니다.
• 플러그인/설정:실험적 plugins가 채널 초기화를 막으면 목록이 비어 doctor가 unset을 제안할 수 있습니다.

채널 정책 매트릭스: dmPolicy, 페어링, 그룹 멘션

환경마다 정책을 의도적으로 고릅니다. 한 게이트웨이에 prod 엄격함과 staging 완화를 섞으면 「Alice는 되고 Bob은 안 됨」 티켓이 납니다.

채널	제어	엄격(prod)	완화(staging)	흔한 실수
Telegram DM	dmPolicy + 페어링	페어링 필수; 발신자별 승인	테스트 채팅만 허용 목록	Token은 유효한데 페어링 미승인
Telegram 그룹	프라이버시 / 멘션	봇 @ 필수	랩에서는 BotFather로 프라이버시 해제 가능	@ 없이 응답 기대
WhatsApp DM	세션 + allowFrom	명시적 허용 목록	파일럿은 단일 운영 번호만	리스 이관 후 QR 만료
WhatsApp 그룹	requireMention	멘션 필수	데모에서 일시 OFF 가능	OFF 후 고트래픽 그룹 스팸

전제: 채널 token 전에 게이트웨이를 정상화

채널은 깨진 데몬의 지름길이 아닙니다. 확인:

• openclaw gateway status가 가동 중이고 RPC probe OK.
• loopback 18789가 onboard 글의 SSH 터널 절차와 일치.
• mini에서 api.telegram.org와 WhatsApp Web으로 HTTPS 도달 — 호스트에서 curl -I, 노트북만으로 측정하지 않음.
• CMDB에 Node 버전 고정(보통 22.14+, 신규 게이트웨이 24.x).

Telegram: 봇 token, webhook 삭제, 페어링 승인

@BotFather로 봇을 만들고 token을 복사합니다. env 주입 경합으로 기동 시 비면 디버깅 중 채널 설정에 평문으로 써도 됩니다. 다른 호스트에서 webhook을 쓰던 token이면 먼저 삭제:

curl "https://api.telegram.org/bot<TOKEN>/deleteWebhook"

게이트웨이 재시작 후 openclaw channels status --probe. 테스트 계정에서 /start. 페어링이 필요하면 openclaw pairing list telegram과 문서의 approve로 승인하고 이벤트 ID를 변경 티켓에 기록.

WhatsApp: QR 재연결, 프록시, 그룹 멘션 drill

WhatsApp은 게이트웨이에 묶인 Web 세션입니다. SSH 터널 또는 VNC 가이드로 Control UI를 열고 60초 안에 QR 스캔. 로그인 408이면 mini 리전에 도달 가능한 HTTPS_PROXY 설정. NO_PROXY 예외는 보안 승인 시만.

연결 후 DM 카나리, requireMention이 켜진 그룹에서 봇 @. 끊김 루프면 openclaw gateway restart, probe가 여전히 실패하면 재스캔.

9단계: 제로에서 검증 가능한 응답까지

1. 20분 변경 창을 확보하고 HK/JP/KR/SG/US를 커버하는 채널에 공지.
2. status + curl 절차로 게이트웨이 검증 — UI 감각만 믿지 않음.
3. Telegram token 기록; 재시작 전 openclaw doctor.
4. 다른 호스트에서 이전 시 오래된 Telegram webhook 삭제.
5. launchd kickstart 또는 승인된 reload로 게이트웨이 재시작.
6. channels status --probe 실행 후 JSON을 티켓에 저장.
7. 첫 DM 발신자 페어링 승인; 감사용 정책 화면 캡처.
8. WhatsApp QR 연결; CMDB에 세션 경로와 리스 ID.
9. 그룹·DM 카나리; 성공 선언 전 10분 로그 tail.

probe 진단표: 상태는 정상인데 사용자에게 응답 없음

증상	probe / 로그	추정 원인	첫 조치
openclaw status에 채널 행 없음	telegram/whatsapp 행 없음	플러그인 또는 설정 미로드	openclaw config unset plugins 후 재시작
Telegram 기동 시 401	getMe returned 401	잘못된 token 또는 env 경합	평문 token; BotFather로 재생성
DM 무시	페어링 목록 pending	dmPolicy	발신자 승인 또는 staging 정책 완화
그룹 무음	로그에 mention 이벤트 없음	requireMention	봇 @ 또는 일시 정책 변경
응답 수 분 지연	doctor에 오래된 TUI 클라이언트	클라이언트 적체	openclaw doctor --fix
WhatsApp 끊김 루프	probe 연결/끊김 반복	프록시 또는 세션 손상	프록시 수정; QR 재스캔; 게이트웨이 재시작

MacLogin 리전: 프록시·DNS 기준

게이트웨이는 사용자와 메시징 API 모두에 가깝게 둡니다. 아래는 라우팅이 좋은 기업망 기준 참고 RTT(반드시 직접 측정):

MacLogin 리전	전형적 용도	주의
홍콩 (HK)	광대만권 오퍼레이션 봇	국경 프록시가 WhatsApp Web에 영향
일본 (JP)	도쿄 주간 지원	IPv6 우선 — curl -4로 확인
한국 (KR)	서울 엔지니어링 알림	기업 MITM 인증서 교체 — 핀 고정 신중히
싱가포르 (SG)	ASEAN 허브 그룹	RTT는 낮지만 egress 허용 목록 엄격
미국 (US)	미주 고객	사용자가 APAC에 있으면 태평양 경로가 김

채널이 프록시에 의존하면 리스 기록에 HTTPS_PROXY, HTTP_PROXY, NO_PROXY를 명시하세요.

FAQ: 채널 vs webhook, 다중 게이트웨이, 보안

채널이 webhook과 같나요?관련 있지만 별개 — 채널은 메신저 전송을 유지하고 HTTP webhook은 별도 인입입니다. 둘 다 가능; 디버깅 중 의도 없이 하나만 끄지 마세요.

mini 한 대에 게이트웨이 2개?포트 18789 충돌을 피하세요. 리스 2개 또는 별도 loopback과 명시적 SSH 맵이 낫습니다.

설정에 botToken을 쓰는 것이 안전한가요?mini를 비밀 호스트로 취급: SSH 제한, offboarding 시 token 로테이션; env 경합 해소 후 vault 주입.

VNC가 도움이 되나요?QR 스캔 UX에 유효; 페어링은 CLI/UI 명령으로 합니다.

상시 메시징 게이트웨이에 MacLogin Mac mini M4가 맞는 이유

채널에는 안정적인 Node 프로세스, 영구 세션, 아웃바운드 HTTPS가 필요합니다 — 잠드는 노트북이 아닙니다. Apple Silicon M4는 폴링 부하에서도 열이 안정적이고 MacLogin HK/JP/KR/SG/US로 사용자와 API 사이에 둘 수 있습니다. 렌탈이면 「채널 전용」mini를 분리해 WhatsApp 세션을 개발자 일상 기기와 격리할 수 있습니다.

코어 수와 리전은 요금 페이지에서 비교하세요. 메신저 연결 시 도움말의 SSH/VNC 절차를 곁에 두세요.