2026 OpenClaw 채널 측 트러블슈팅: 단체 채팅 @mention, pairing 승인, Slack/Discord 봇 권한 체크리스트(연결됐는데 무응답)
5분 급속 배포와 18789 5단계는 통과했는데 DM은 되고 단체만 무음이거나 채널은 초록인데 답이 없다면, 모델보다 IM 정책과 봇 권한일 가능성이 큽니다. heartbeat/무응답, Matrix 글과 역할을 나누고, requireMention·pairing·신규 발신 승인·Slack/Discord 최소 권한에 집중합니다. 대조표, 6단계 명령, Runbook용 매개변수로 채널 측 문제와 재설치 오판을 줄입니다.
목차
1. 세 가지 유형: 연결은 있는데 무응답
로그에는 처리됐는데 사용자 화면은 비어 있음—대개 채널 정책입니다. API 키를 먼저 갈아끼우기 전에 「플랫폼이 봇에 넘겼는지」와 「게이트웨이가 모델에 넘겼는지」를 분리합니다.
사용자가 메시지를 보낸 직후 Slack Event Delivery나 Discord 쪽에 원시 페이로드가 찍히는지부터 보세요. 안 보이는 단계에서 npm ci나 프롬프트만 만지면 재현성이 없습니다. 대시보드 초록 불은 TLS 핸드셰이크나 단발 헬스일 뿐, 모든 워크스페이스·길드로의 전달을 보장하지 않습니다.
- @mention·requireMention:
@Bot을 요구하면 일반 메시지는 정책에서 버려집니다. DM은 예외. 테스트 채널에서 끄거나 허용 목록을 쓰고, 문서에 공개 채널 규칙을 명시합니다. 채널마다 다르면 방 단위 덮어쓰기를 확인합니다. - pairing·신규 승인:
pairing approve전에는 모델로 전달되지 않습니다. 기존 사용자만 되고 신규만 안 되면 대기열을 의심합니다. 프로덕션 하드닝과 함께 정책 차단과 인증 실패를 구분합니다. - Slack/Discord 권한·intents:
chat:write누락, 채널 미초대, DiscordMessage Content Intent미설정 등으로 입구는 보이고 출구만 실패할 수 있습니다. Webhook과 Socket 모드의 스코프는 다릅니다. Slack 다중 워크스페이스에서는 실제 사용 WS에 앱 설치와 이벤트 URL이 운영 게이트웨이를 가리키는지 확인합니다.
다음 절 표로 가설을 하나로 좁힌 뒤 모델을 건드립니다. 여러 사람이 설정을 고치면 메인 브랜치 병합 직후 requireMention만 예전 값으로 돌아가는 경우가 있으니, 배포 전 git diff로 정책 줄을 반드시 리뷰하세요.
Runbook은 채널 측(probe·pairing·mention·ACL·콜백)과 세션/모델 측으로 나눕니다. Matrix는 되고 IM만 안 되면 IM 정책을 먼저 봅니다. 변경은 한 번에 한 변수만, 전후에 [OC-PROBE] 메시지를 남깁니다.
2. 증상 대조표
| 증상 | 우선 의심 | 검증 | 나중에 |
|---|---|---|---|
| 단체만 무음, DM 정상 | requireMention·방 정책 | @ 포함 짧은 문장 | 전역 모델 키 |
| 신규만 무음 | pairing 대기 | pairing list | 18789 포트 |
| 전 채널 무음·doctor 경고 | 토큰·핸드셰이크 | channels status --probe | CPU 포화 |
| Discord DM만 됨 | intents·역할·가시성 | 개발자 포털·권한 표 | temperature |
| Slack 스레드만 | 이벤트 구독·설치 범위 | 재인가·URL 정합 | 불안정 핑계 |
18789가 진짜 막혔다면 DM도 보통 같이 죽습니다. temperature는 문체일 뿐 이벤트 전달과 무관합니다.
3. 여섯 단계: probe·pairing·doctor·logs
바깥에서 안으로, 한 단계에 한 가설. 세 군데를 동시에 고치면 무엇이 효과였는지 온콜 지식으로 남지 않습니다.
- probe:
openclaw channels status --probe로 채널별 OK/지연 기록. 간헐 실패는 리버스 프록시 타임아웃·TLS 체인·443 헬스 경로가 실제 웹훅 경로와 다름 등을 먼저 의심합니다. - pairing:
openclaw pairing list --channel <name>로 백로그 해소 후 단체 재검증. 초대 링크가 하룻밤에 퍼지면 pending이 전원 쌓이는 패턴이 흔합니다. - mention:
requireMention토글 후 @ 유무 비교. 일반 사용자 계정으로 검증. - doctor:
openclaw doctor. Docker는 컨테이너/호스트 설정 일치. - logs:
openclaw logs --follow에서 policy 키워드. 프로브에[OC-PROBE]. - 영속성: launchd의 작업 디렉터리와
openclaw.json. launchd 환경 글과 동일 계열.
4. 인용 가능한 매개변수·운영 지표
① Discord: 프로덕션에서는 대개 Message Content Intent 필요. 멤버 목록·프레즌스가 필요할 때만 Server Members Intent 등을 추가하고 최소 권한을 유지합니다. ② Slack: Event API와 Socket Mode에 맞춰 스코프 최소화, 채널에 /invite 없으면 message.channels류 이벤트 자체가 오지 않을 수 있습니다.
③ 콜백 URL은 HTTPS로 공개 게이트웨이 호스트와 일치. 리버스 프록시가 경로 접두사를 제거하면 앱 basePath와 맞춥니다. ④ 정책 변경·재인가 후 캐시로 수분 지연. ⑤ 사용자 문서에 「공개 채널에서는 @봇」을 명시하면 티켓이 줄어듭니다. ⑥ pairing 대량 승인은 티켓·실행자 기록(하드닝의 토큰 로테이션과 동일).
거친 기준으로, 정상 부하에서 「사용자 전송→게이트웨이 첫 로그 줄」이 보통 2~3초 안이면 병목은 LLM보다 앞단 큐·정책일 가능성이 큽니다. probe는 성공하는데 로그에 policy drop만 늘면 mention/pairing 설정을 우선 보세요.
5. 토큰 교체에서 안정적인 Mac 클라우드로
무응답마다 봇 토큰만 바꾸면 mention/pairing 본질이 가려지고 감사도 어렵습니다. probe→pairing→doctor→logs 순서를 Runbook에 고정하고, 키 교체는 별 승인 흐름으로 분리하는 편이 재현성에 낫습니다.
노트북 절전·로컬 방화벽은 이벤트 재현을 흐리게 해 오늘은 되고 내일은 안 되는 것처럼 보이게 합니다. 상시 가동 Mac 클라우드는 Slack/Discord 재연결·지수 백오프 추적에 유리합니다.
Windows·범용 Linux에만 게이트웨이를 두고 Xcode·서명은 다른 팀이 Mac에서 돌리는 구성은 설명 비용이 큽니다. VPSMAC M4 Mac 클라우드에 게이트웨이와 launchd 작업을 두면 운영에 가깝게 재현됩니다. 뼈대는 5분 배포부터.
6. FAQ
DM만 되고 단체는?
먼저 requireMention과 방 단위 덮어쓰기. 동일 문장을 @Bot 유/무로 비교해 보세요. @로 바로 살아나면 운영 문서에 규칙을 박거나, 내부 채널만 예외(보안 검토 후)를 검토합니다.
pairing 비어 있는데 무음?
channels status --probe로 되돌아가 봇 스코프 표와 openclaw logs의 policy 줄을 확인합니다. 스테이징 워크스페이스 토큰을 운영 게이트웨이에 얹어 놓은 경우가 흔합니다.
heartbeat와 차이?
heartbeat·thinking은 Cron·빈 출력·스케줄 쪽에 가깝습니다. 단체만 망가지고 mention과 강하게 엮이면 채널 측을 우선합니다. DM까지 전 채널이 죽었으면 heartbeat 글을 병행하세요.
Discord intent 켰는데 길드 무음?
채널 보기·히스토리 읽기, 비공개 채널 역할. 개발자 포털 저장 후 몇 분 기다렸다가 재시도—캐시 때문에 「고쳤는데 안 됨」처럼 보일 수 있습니다.
Slack 온라인인데 트리거 없음?
이벤트 요청 URL, 재인가 완료, 워크스페이스별 설치 누락. Slack 배달 로그와 게이트웨이 access 로그를 초 단위로 맞추고 404·서명 오류를 먼저 제거합니다.