1. 문제 정리: 모델 이전에 「채널 계약」을 맞출 것
(1) Discord: Intent와 채널 권한. Message Content Intent가 꺼져 있으면 일반 사용자 메시지가 봇에 도달하지 않을 수 있습니다. 전송·임베드·첨부 권한이 부족하면 이벤트는 남지만 채널에는 답이 나가지 않습니다. 이는 모델 품질 문제가 아니라 봇이 말할 권한이 없는 상태입니다.
(2) WhatsApp: 페어링과 정책은 별개. QR 로그인 후에도 dmPolicy, allowFrom이 실제 발신자(E.164, 그룹 JID)와 어긋나면 연결은 성공했어도 메시지가 정책 계층에서 조용히 폐기됩니다.
(3) Gateway 수명 주기. Discord와 WhatsApp은 모두 장수명 컨슈머에 의존합니다. 노트북 절전, 중복 실행된 openclaw gateway, 포트 충돌은 두 채널을 동시에 「무작위 무응답」처럼 보이게 만듭니다.
2. 대조표: Discord 봇 vs WhatsApp 채널(OpenClaw 관점)
| 관점 | Discord | |
|---|---|---|
| 신원·자격 증명 | 봇 토큰, Application ID, OAuth 설치 범위 | 전화 로그인·페어링; 명시적 허용 목록 |
| 대표 디버그 경로 | Developer Portal → Bot → Privileged Gateway Intents | openclaw channels login --channel whatsapp와 정책 블록 일치 여부 |
| 리스크·컴플라이언스 | 서버 초대·역할 경계; 감사 로그 | 개인 번호·업무 번호 분리; 미지 번호 개방 금지 |
| Gateway 관계 | 이벤트는 Gateway로 분배; 장수명 연결 전제 | 세션·재연결도 Gateway 의존; 단절은 관측 가능해야 함 |
2b. channels.* 최소 노출
openclaw.json(또는 단일 진실 설정)에서 Discord는 서버·채널 단위로, WhatsApp은 allowFrom 등으로 발신자를 좁힙니다. 「일단 전부 개방」은 몇 분을 아껴 주지만, 초대 링크나 번호가 유출되는 순간 에이전트가 감사되지 않은 대화에 닿습니다.
3. 재현 가능한 다섯 단계 롤아웃
- 범위 고정. Discord만, WhatsApp만, 또는 병행. 병행 시 기본 모델 경로와 도구 집약 프로파일을 누가 우선하는지 정해 피크 시간 경쟁을 줄입니다.
- Discord 최소 권한. 포털에서 필요한 Privileged Intent만 켜고, 실제 사용 채널에 맞는 봇 권한을 부여합니다. 토큰은 환경 변수·시크릿에만—저장소나 스크린샷에 남기지 않습니다.
- WhatsApp 정책 정렬. 페어링 직후
dmPolicy와 허용 목록을 실제 트래픽 번호 형식으로 대조합니다. 정책 변경 후에는 Gateway를 재시작해 실행 중인 프로세스가 오래된 계약을 쥐지 않게 합니다. - 검증 후 상시 실행. 한 번 포그라운드로 올려 포트 충돌·설정 오류를 제거한 뒤 launchd 등으로 상시화하고, 인시던트 때 tail 할 로그 경로를 고정합니다.
- 일주일 실트래픽. 작은 테스트 채널·번호로 보내 「무응답」이 특정 채널·번호에 몰리면 Intent·정책을 먼저 의심하고 모델 교체는 뒤로 미룹니다.
4. 계획·리뷰에 인용할 임계값
사후 분석에서 인용할 수 있는 기준:
- OS와 기타 상주 프로세스를 포함해 Gateway·모델·도구 전에 최소 4GB 여유 메모리를 확보합니다. 메모리 압박은 「AI가 약하다」가 아니라 프로세스 정지 증상을 냅니다.
- 피크 시간에 세 번 연속 무응답이 재연결·속도 제한 로그와 겹치면 API 한도와 단일 인스턴스 병렬도를 먼저 보고 모델 확장은 나중입니다.
- 7×24를 약속한다면 매일 뚜껑을 닫는 노트북을 본격 토폴로지로 두기 어렵고, 상시 전원 노드(고정 이미지 원격 Mac 등)를 검토합니다.
5. 언제 원격 Mac에 올릴까
| 신호 | 권장 |
|---|---|
| 커뮤니티와 DM을 모두 감사 가능하게 운영해야 함 | Gateway 전용 노드; 개발 PC는 설정·카나리만 |
| 절전·전원 관리로 매일 끊김 | 상시 전원 원격 Mac 또는 DC 노드로 이전 |
| 팀이 동일 봇 신원 공유 | 고정 이미지·환경 변수로 노트북마다 설정 드리프트 방지 |
6. FAQ
Discord에 이벤트는 있는데 답이 없다. 먼저 봇이 채널을 보고 말할 수 있는지, Intent와 전송 권한을 확인한 뒤 모델을 의심합니다. WhatsApp은 연결됐는데 무반응. 번호 형식과 allowFrom을 우선하고, Gateway가 단일 인스턴스인지 확인합니다. 다채널 병행은? 가능하지만 병렬도와 도구 예산을 문서화하지 않으면 타임아웃이 「모델 불안정」처럼 보입니다.
7. 심층: 커뮤니티 자동화는 운영 문제다
2026년 에이전트 프레임워크는 채팅 입구를 매우 얇게 만들지만, 운영에서 차이를 만드는 것은 모델 스펙보다 채널 계약—권한, 정책, 재연결, 로그의 일관성입니다. 개인 노트북에서만 Gateway를 돌리는 구성은 3개월 뒤 「어젯밤은 됐는데 재현 불가」 티켓을 양산합니다. 모델 신비가 아니라 프로세스·네트워크 수명 주기 문제입니다.
데모는 수동 재시작으로 되지만 야간 운용·절전·중복 실행이 겹치면 로그에 재연결이 쌓이고 API 탓으로 오진하기 쉽습니다. SLO·구조화 로그·설정 변경 시각 대조가 필요하며, Gateway를 고정 노드로 옮기는 것은 재현성을 위한 결정입니다.
8. 마무리: 범용 호스트 한계·원격 Mac·MACGPU
(1) 범용 Linux VM과 개인 노트의 한계. Linux에서 Gateway 자체는 돌아가지만 macOS 전용 툴·미디어 경로에 의존하는 크리에이티브 팀에는 마찰이 큽니다. 개인 노트북은 절전, VPN, OS 업데이트 후 설정 드리프트를 안고 커뮤니티 대면 봇 본선에는 부적합합니다.
(2) 원격 Apple Silicon이 맞는 이유. 통합 메모리는 모델 추론과 Gateway 공존에 유리하고, launchd와 로그 위치는 많은 디자인·영상 팀 자동화와 맞물립니다.
(3) MACGPU. 가동률과 고정 이미지가 필요할 때 여러 노트북을 수동으로 묶는 것보다 시간제 원격 Mac을 빌려 비용과 신뢰성을 맞추는 편이 빠른 경우가 많습니다. MACGPU는 로그인 없이 공개 요금을 확인할 수 있으며 아래 CTA로 이어집니다.