2026 OpenClaw 채널 구성
Slack·Discord·Telegram 권한, OAuth 및 「연결됐지만 묵묵함」 트리아지

약 21분 읽기 · MACCOME

이미 Gateway를 운용하는 팀은 Slack·Discord·Telegram을 설치하지 못해서 실패하는 경우는 드뭅니다. 관리 콘솔에는 채널이 연결된 것으로 보이나 대화는 블랙홀처럼 느껴지고, 메시지가 도착하지 않거나 한 방향으로만 흐르는 상황에서 막힙니다. 본문은 《설치 후 doctor 트러블슈팅》《Docker 네트워크 트리아지》《프로바이더 페일오버》와 짝을 이룹니다. 먼저 Gateway와 모델 상태를 확인한 뒤, 플랫폼별 OAuth 범위·봇 권한·이벤트 구독·Telegram 프라이버시 모드를 순서대로 점검합니다. 당번에 쓸 여섯 가지 증상 태그, 삼층 트리아지 매트릭스, 복사해 실행할 진단 블록, 여섯 단계 런북, Grafana에 올릴 만한 채널 KPI 세 가지를 제시합니다.

연결된 것처럼 보이나 반응이 없을 때 여섯 가지 채널 증상

채널 이슈는 종종 「모델이 고장 났다」 또는 「compose 네트워크 문제다」로 잘못 분류됩니다. 이미지나 network_mode를 바꾸기 전에 아래 목록으로 동작을 라벨링하고 Docker 네트워크 트리아지 표와 대조하여, 두 갈래 변경이 동시에 이루어져 근본 원인을 지워 버리지 않도록 합니다.

  1. 인바운드 이벤트 누락: 관리 UI에는 온라인으로 보이나 새 채널 메시지가 Gateway 로그 줄을 만들지 않는 경우가 많습니다. Slack 이벤트 구독이 꺼져 있거나, Discord Gateway Intent가 부족하거나, Telegram 프라이버시 모드가 그룹을 막는 경우입니다.
  2. DM만 되고 채널은 안 됨: OAuth 범위나 봇 참여 정책이 DM만 덮어 채널 메시지가 조용히 버려집니다. 채널 목록과 봇 멤버십을 확인합니다.
  3. 명령은 파싱하나 응답 없음: 인바운드 로그는 있는데 응답이 groupPolicy·스레드 규칙·멘션 전용 정책에 막히거나, 빈 에이전트로 라우팅되거나 권한 거부가 납니다.
  4. 간헐적 OAuth·토큰 만료: 콘솔은 한동안 모두 녹색이었다가 몇 시간 뒤 적색으로 바뀝니다. 리프레시 토큰이 시크릿 저장소에 다시 쓰이지 않거나, 동일한 .env 마운트 없이 컨테이너가 재시작된 경우가 많습니다.
  5. 워크스페이스·길드 교차 배선: 한 프로세스가 여러 Slack 워크스페이스나 Discord 서버에 묶이고, 병합된 설정이 콜백을 잘못된 URL로 보냅니다.
  6. 모델 층 오진: 채널은 정상인데 업스트림 429·5xx로 사용자는 봇이 죽었다고 느낍니다. Gateway 대 프로바이더 로그 비율을 보고 프로바이더 페일오버 글로 돌아갑니다.

이 여섯 클래스를 최근 allowedOrigins 수정과 같은 변경 티켓의 이미지 롤아웃과 함께 기록하면 당번이 오 분 안에 분기를 고를 수 있습니다.

표 1: 삼층 트리아지—Gateway, 채널, 모델 중 무엇을 먼저 볼까

이 매트릭스는 어느 층을 먼저 살필지 정하는 것이며 배타적이지 않습니다. 각 행은 구체적인 다음 명령이나 로그 키워드에 매핑되어야 합니다. 종이에 세 열을 그립니다. 사용자에게 보이는 증상, Gateway 로그에서 가장 먼저 보이는 이상, 업스트림 모델 HTTP 코드입니다. 가운데 열이 비어 있으면 프로바이더를 건드리기 전에 멈춥니다. 오른쪽 열에 429가 먼저이면 OAuth를 열 번 재인증해도 과금 문제는 해결되지 않습니다.

Docker 네트워크 글과 함께 읽을 때 컨테이너 안에서 채널 프로브가 실패하는 경우제0층으로 둡니다. 동일 compose 네트워크에서 CLI가 Gateway에 닿는지 먼저 확인한 뒤 이 표를 씁니다. 그렇지 않으면 Slack 웹훅 콘솔은 건강해 보이는데 호스트에는 타임아웃만 보일 수 있습니다.

관측우선 의심할 층다음 단계(요약)
헬스 체크는 녹색, 인바운드 로그는 없음채널 인그레스플랫폼별 재인증, 이벤트 구독 URL·Socket Mode·Intent 확인, Telegram 프라이버시와 @멘션
인바운드는 있으나 라우팅에 빈 에이전트 또는 정책 거부라우팅·정책groupPolicy·채널 바인딩·멘션 규칙을 검사하고 OpenClaw 에이전트 매핑을 맞춥니다
인바운드와 라우팅은 정상, 응답 단계에서 실패모델·쿼터429·5xx·타임아웃을 보고 프로바이더 페일오버 글에 따라 키나 모델을 전환합니다
컨테이너만 실패, 호스트 CLI는 성공네트워크·시크릿 마운트Docker 네트워크 트리아지로 돌아가 compose 환경과 볼륨을 확인합니다

대시보드에 올릴 만한 채널 KPI 세 가지

이 지표는 「봇이 멈춘 것 같다」를 알림 가능한 숫자로 바꿉니다. 필드 이름은 Gateway 로깅과 맞춥니다. 초 단위 잡음보다 시간 단위 버킷을 선호하여 야간 호출이 의미를 잃지 않게 합니다.

  1. 인바운드 이벤트율(IER): 채널에서 확인된 이벤트를 같은 창의 비즈니스 측 발송 수로 나눈 값입니다. 지속적으로 0.9 미만이면 GPU가 아니라 OAuth와 구독을 의심합니다.
  2. 라우팅 적중률(RHR): 인바운드 트래픽 중 의도한 에이전트에 묶인 비율입니다. IER은 괜찮은데 RHR이 떨어지면 정책이나 채널 맵이 썩었습니다.
  3. 응답 완료율(RCR): 인바운드부터 모델 HTTP 200까지의 종단 성공 비율입니다. IER과 RHR이 높은데 RCR이 낮으면 모델 층을 우선합니다.

2026년 커뮤니티 문서도 여전히 openclaw channels status --probe를 강조합니다. 프로브 결과를 위 세 비율 옆에 그려 「재연결하고 기도」류의 재현 불가 수정을 피합니다. Gateway 헬스 체크 글에서 HTTP 프로브를 이미 썼다면, 프로브 URL이 실제 채널 콜백과 동일한 리버스 프록시 경로를 따르는지 확인합니다. 루프백만 두르고 공개 콜백은 다른 인증서 체인을 쓰면 「모니터는 전부 녹색, 사용자는 전부 적색」이 됩니다.

수동 대조 습관을 더합니다. 매주 사용자 메시지 열 건을 샘플링하여 플랫폼 메시지 ID·Gateway 요청 ID·모델 트레이스 ID가 로그 전반에 나타나는지 확인합니다. 링크가 빠지면 구조화 로깅이 깨진 것이므로 확장 전에 필드를 고칩니다.

bash
# 예시 순서(환경에 맞게 sudo / docker exec 접두어 추가)
openclaw gateway status
openclaw channels status --probe
openclaw logs --follow | rg -i "slack|discord|telegram|429|oauth|deny"

# Telegram: BotFather 프라이버시 모드와 그룹에서 @멘션 필요 여부
# Discord: Developer Portal 특권 Intent(Message Content 등)
info

참고:세 플랫폼 설치 가이드》로 동일 머신에서 최소 대화를 재현하지 못했다면 채널과 compose를 병렬로 바꾸지 않는 것이 좋습니다. 병렬 수정은 근본 원인을 가립니다.

여섯 단계 런북: 프로브부터 되돌릴 수 있는 OAuth 변경까지

  1. 영향 범위 동결: 이미지 태그·환경 해시·최근 compose 변경 세 건을 캡처합니다. 채널 퇴보는 롤링 릴리스와 함께 나오는 경우가 많습니다. 같은 날 allowedOrigins나 TLS 인증서가 바뀌었다면 이전 인증서 지문으로 롤백하는 방법을 문서화하여 OAuth 콜백과 CORS가 동시에 깨지지 않게 합니다.
  2. Gateway 기준선 확립: 호스트 또는 컨테이너 안에서 gateway status가 doctor 글과 일치하는지 확인합니다. systemd나 launchd를 쓰면 재시작 정책을 검증합니다. 빈번한 재시작은 채널 WebSocket에 플랫폼 측 속도 제한을 걸 수 있습니다.
  3. 플랫폼별 인증: Slack은 OAuth와 범위를 다시 실행하고, Discord는 Intent를 켜고 봇을 다시 초대하고, Telegram은 BotFather 프라이버시를 조정하거나 그룹에서 @봇을 요구하게 합니다. 인증 후 플랫폼 캐시 TTL(흔히 5~15분)을 기다립니다. 재인증을 열 번 연속으로 누르지 않습니다.
  4. 최소 대화 증명: 채널 하나, 에이전트 하나, 추가 정책 없이 핑퐁 테스트를 한 뒤 groupPolicy를 다시 켭니다. 테스트 메시지에 접두어를 붙여 로그에서 grep하기 쉽게 하고 공개 채널을 시끄럽게 하지 않습니다.
  5. 모델 층과 대조: 핑퐁이 여전히 실패하면 30초 로그에서 429 비중을 샘플링한 뒤 프로바이더를 바꿉니다. 429가 한 키에 몰리면 소비자 등급 키와 종량제 키를 섞었는지 확인합니다.
  6. 런북을 되씁니다: 토큰 로테이션과 시크릿 경로를 Docker 네트워크 메모와 같은 저장소에 두어 한 대의 노트북만 릴리스할 수 있게 하지 않습니다. 협업자에게는 최소 읽기 전용 범위만 주고 마스터 키는 KMS나 sealed secret에 둡니다.

Slack·Discord·Telegram 빠른 점검을 한 페이지에

벤더 콘솔마다 아래 항목을 실행합니다. 오래된 스크린샷을 믿지 않습니다. 스테이징과 프로덕션 워크스페이스를 모두 쓴다면 콜백 호스트명 열을 따로 두어 스테이징 인증서가 프로덕션 DNS에 묶이지 않게 합니다.

  • Slack: 앱 수준과 봇 토큰이 모두 유효한지, 이벤트 구독 URL이 실제로 돌리는 공개 Gateway를 가리키는지, Socket Mode와 HTTP를 의도치 않게 섞지 않았는지 확인합니다. Enterprise Grid에서는 모든 워크스페이스 설치가 동일한 OAuth 클라이언트를 참조하는지 확인하지 않으면 일부 리전은 이벤트를 받지 못합니다.
  • Discord: Message Content Intent와 Server Members Intent가 실제 필요와 맞는지, 봇이 대상 채널에 보이는지, 채널 덮어쓰기가 전송을 거부하지 않는지 확인합니다. Discord의 권한 진단 도구를 쓰고 역할 이름만 읽지 않습니다.
  • Telegram: 웹훅과 long polling 중 하나만 선택합니다. 롤링 릴리스 뒤에 인증서와 콜백 URL이 어긋나지 않는지 확인합니다. 프라이버시 모드에서는 그룹에 명시적 멘션이 필요할 수 있습니다. 자체 서명 인증서라도 Telegram이 기대하는 포트와 TLS 버전을 노출해야 하며, 인증서 로테이션은 별도 변경 창에서 수행합니다.

세 플랫폼 모두 안정적인 이그레스 IP를 중시합니다. 가정용 회선이나 출구 노드가 바뀌는 VPN은 웹훅을 이상 트래픽처럼 보이게 할 수 있습니다. 멀티리전 클라우드 Mac 가이드의 고정 리전과 감사 가능한 이그레스와 맞습니다. 팀이 봇에 의존하기 전에 도달 가능성을 증명할 호스트로 제어 평면을 옮깁니다.

개인 노트북이 팀 규모 OpenClaw 채널을 감당하기 어려운 이유

절전·VPN·로컬 프록시는 이그레스 IP와 TLS 지문을 바꿔 OAuth 콜백과 벤더 허용 목록을 무작위로 실패시킵니다. 공유 노트북으로는 토큰 로테이션과 감사 필드를 한곳에 모을 수 없습니다. 당번이 볼 수 있고 이그레스가 안정적인 실행면에서 Gateway와 채널 워커를 돌립니다 팀 에이전트 정책과 맞춥니다.

상시 서비스·고정 콜백 도메인·예측 가능한 이그레스가 필요한 토폴로지에서는 MACCOME이 싱가포르·일본·한국·홍콩·미 동부·미 서부에 Mac Mini M4·M4 Pro 클라우드 호스트를 제공하며 Gateway와 Apple 도구를 함께 두기에 적합합니다. 채널 트리아지 후 《SSH 대 VNC 가이드》와 고객 센터를 보고 대여 요금과 리전 페이지로 임대 기간을 연장합니다.

파일럿 패턴: 전용 테스트 호스트에서 채널 하나로 24시간 IER과 RCR을 돌린 뒤 프로덕션 워크스페이스를 엽니다. 큰 커뮤니티를 한꺼번에 켜서 즉시 적색이 되는 상황을 피합니다.

자주 묻는 질문

Docker 네트워크 트리아지 글과 어떻게 다른가요?

네트워크 글은 CLI에서 Gateway까지의 도달성을 다룹니다. 본문은 메시지 플랫폼 인그레스와 인증을 다룹니다. compose를 의심하면 먼저 《Docker 네트워크 트리아지》를 읽습니다.

상위 OpenClaw FAQ도 읽어야 하나요?

읽습니다. 토큰과 Intent 목록을 상위 문서와 교차 확인합니다. 《세 플랫폼 설치 가이드》와 고객 센터의 접근 문구를 함께 봅니다.

클라우드 Mac의 리전과 임대 조건은 어디서 고르나요?

Gateway를 두기 전에 《멀티리전 대여 가이드》와 대여 요금을 읽습니다.