Telegram, Discord, Slack, WhatsApp를 한 번에 설정하지 마세요. 가장 인기 있어 보이는 서비스가 아니라, bot, app, workspace, server 또는 전화번호를 누가 관리하는지 분명한 채널 하나를 먼저 고르세요. DM 발신자 한 명만 승인하고, 그 사람이 보낸 메시지의 답장이 같은 대화에 실제로 돌아오는 것까지 확인한 뒤에 그룹이나 추가 기능으로 넓히는 것이 안전합니다.
| 처음 해결할 일 | 먼저 고를 채널 | 첫 테스트에서 닫아 둘 범위 |
|---|---|---|
| 개인용 bot으로 빠르게 시작 | Telegram | DM 한 명만 페어링하고 그룹은 아직 추가하지 않음 |
| 관리 가능한 비공개 server에서 사용 | Discord | server, channel, user를 하나씩만 허용하고 멘션을 요구 |
| 팀 workspace에 app으로 배치 | Slack | Socket 또는 HTTP를 먼저 정하고 DM 하나나 channel 하나만 허용 |
| 전화번호가 사용자 입구가 됨 | QR session 하나와 발신자 한 명만 승인하고 그룹은 닫음 |
2026년 7월 13일에 확인한 OpenClaw 공식 채널 설정에 따르면 Telegram과 iMessage는 core에 포함되고, Discord, Slack, WhatsApp를 비롯한 다른 공식 채널은 개별 plugin으로 설치됩니다. 이 구분은 채널 순위가 아닙니다. plugin source, platform permission 이름, command, default policy는 바뀔 수 있으므로 실제 설치 시점에는 현재 공식 문서와 로컬 CLI 출력을 다시 확인해야 합니다.
첫 접근 범위는 닫힌 상태로 유지하세요. DM은 pairing, 그룹은 allowlist, 공유 channel은 requireMention을 기본 경계로 사용합니다. 테스트가 통과하지 않는다는 이유로 DM policy를 open으로 바꾸고 allowFrom: ["*"]를 추가하면, 연결 확인이 아니라 공개 운영 모델로 전환하는 것입니다.
token을 저장했거나 bot이 online이라고 표시되거나 QR을 읽었다고 해서 채널이 준비된 것은 아닙니다. 예상한 account가 해석되고, 의도한 발신자의 메시지가 Gateway에 들어오고, agent 또는 model이 작업을 완료하고, 답장이 원래 대화에 보일 때까지 확인해야 합니다.
여기서 멈출 기준: 이 한 번의 왕복이 통과하기 전에는 optional scope, group, user, public access, 두 번째 account, 두 번째 channel을 추가하지 마세요.
채널을 추가하기 전에 Gateway와 모델부터 확인하세요
새 채널의 문제를 불안정한 OpenClaw runtime 위에서 조사하면 원인이 섞입니다. Telegram token은 model provider 인증 실패를 고칠 수 없고, Slack scope는 중단된 Gateway를 살릴 수 없습니다. 새 채널과 같은 installation, service, config를 사용하는 기존 local 또는 web 경로에서 일반적인 한 번의 model turn이 완료되는지 먼저 확인하세요.
처음에는 상태를 바꾸지 않는 읽기 중심 명령을 사용합니다.
hljs bashopenclaw status openclaw gateway probe openclaw doctor openclaw channels list --all openclaw channels status --probe
각 명령은 서로 다른 질문에 답합니다.
openclaw status는 현재 보고 있는 installation과 전반적인 runtime 상태를 확인합니다.openclaw gateway probe는 CLI에서 Gateway까지 도달할 수 있는지 확인합니다.- 옵션 없는
openclaw doctor는 config와 migration 문제를 관찰합니다.doctor --fix를 채널 설정의 보편적인 첫 명령으로 사용하지 않습니다. openclaw channels list --all은 채널이 installed, configured, enabled, installable 중 어디에 속하는지 구분합니다.openclaw channels status --probe는 Gateway가 도달 가능한 경우 live account와 transport 상태를 확인합니다. Gateway가 내려가 있어 config 요약으로 fallback한 결과는 provider 연결 증거가 아닙니다.
다음 조건이 갖춰지면 채널 작업을 시작할 수 있습니다. 의도한 OpenClaw binary와 version이 실제 service가 실행하는 것과 같고, Gateway probe가 성공하고, 이미 작동하는 표면에서 model 응답이 완료되며, 선택한 채널이 core, installed 또는 installable로 나타나야 합니다. CLI, service, model route가 여기서 실패한다면 token이나 채널 permission을 건드리지 말고 먼저 그 하위 runtime을 복구하세요.
첫 채널은 설정 시간이 아니라 관리 책임으로 고르세요
“어느 채널이 최고인가”라는 질문만으로는 선택하기 어렵습니다. 네 플랫폼은 각각 다른 identity, credential, transport, 관리자, 복구 절차를 요구합니다. 연결이 끊겼을 때 누가 token을 교체하고, 누가 app을 다시 승인하며, 누가 QR session을 다시 연결하는지 답할 수 있는 채널이 좋은 첫 선택입니다.
| 선택 | 첫 사용에 잘 맞는 상황 | 직접 관리해야 하는 항목 | 처음에 피해야 하는 상황 |
|---|---|---|---|
| Telegram | 한 명 또는 소규모가 쓰는 전용 bot | BotFather identity, bot token, user/group ID, privacy와 mention 동작 | 실제 요구가 workspace app, server role, phone identity인 경우 |
| Discord | 비공개 server 또는 관리 가능한 커뮤니티 | Developer application, bot, privileged intents, invite permission, guild/channel ID | server 관리자 권한이 없고 유효 permission을 검토할 수 없는 경우 |
| Slack | app을 설치할 수 있는 팀 workspace | Slack app, Socket/HTTP 배치, token 또는 signing secret, scope와 event | app 설치 권한이나 필요한 network 형태가 없는 경우 |
| 전화번호가 필수 사용자 입구 | linked device, QR session, 번호 소유권, phone allowlist, session 보관 host | linked session을 비공개로 안정적으로 유지할 수 없는 경우 |
core와 plugin의 차이도 선택에 포함하세요. 현재 CLI는 installable catalog channel이라면 다음 형태로 현재 source를 해석하고 필요한 설치를 진행할 수 있습니다.
hljs bashopenclaw channels add --channel <name>
오래된 튜토리얼에서 package spec을 복사해 추측하는 대신, openclaw channels add --help와 openclaw channels list --all을 보고 현재 지원되는 경로를 사용하세요. platform뿐 아니라 account도 하나만 고르는 것이 중요합니다. Telegram bot 두 개, Slack workspace 두 개, 개인용과 업무용 WhatsApp 번호를 동시에 설정하면 어떤 credential과 route가 응답했는지 알기 어려워집니다.
연결 전에 다섯 가지를 한 줄씩 적으세요
credential 하나가 저장되었다고 전체 채널이 준비되는 것은 아닙니다. 설정을 시작하기 전에 다음 다섯 항목의 담당과 증거를 짧게 적어 두세요.
| 항목 | 설정 전에 답할 질문 | 비밀을 제외하고 남길 증거 |
|---|---|---|
| 보이는 계정 | 사용자가 볼 bot, app, workspace, server, 전화번호는 무엇이며 누가 관리하는가 | account label과 stable ID |
| 연결 방식 | core인가 plugin인가. polling, Discord Gateway, Socket, HTTP, QR linked session 중 무엇인가 | installed channel과 선택한 mode |
| 비밀 또는 session | token, app token, signing secret, linked-device state를 어디에서 읽는가 | protected environment/file/SecretRef 위치만 기록 |
| 접근 범위 | 어느 sender, DM, group, channel, guild, mention, command를 허용하는가 | pairing approval과 ID 기반 allowlist |
| 완료 증거 | 어떤 한 문장으로 inbound, model, outbound, visible reply를 확인하는가 | 시간, probe, 필요한 log, 같은 대화의 답장 |
이 다섯 줄은 책임 공백을 일찍 드러냅니다. “Slack을 쓴다”는 말만으로는 Socket Mode와 HTTP Request URLs 중 어느 transport를 운영할지 정해지지 않았습니다. “WhatsApp을 연결한다”는 말만으로는 어느 번호와 어느 host가 session을 소유할지 알 수 없습니다. “Discord bot이 online이다”는 말만으로는 허용된 user가 메시지를 보내고 같은 channel에 답장을 받았는지 증명되지 않습니다.
token과 session을 작업 대화에 붙이지 마세요
공개 가능한 config 예시는 secret의 값이 아니라 참조 방식만 보여 줘야 합니다. Gateway host의 protected environment, file 또는 현재 지원되는 SecretRef를 사용하세요. 예를 들어 Discord token은 다음과 같이 environment 변수 이름으로 참조할 수 있습니다.
hljs json5{ channels: { discord: { enabled: true, token: { source: "env", provider: "default", id: "DISCORD_BOT_TOKEN" } } } }
DISCORD_BOT_TOKEN의 실제 값은 protected service environment에 있어야 합니다. config, chat prompt, terminal screenshot, issue, support bundle, Git repository에 값을 넣지 마세요. Telegram bot token, Slack bot token과 app token, Slack signing secret, WhatsApp authentication directory와 QR data도 같은 수준의 credential입니다.
Telegram은 BotFather와 DM 한 명부터 시작하세요
Telegram은 전용 bot을 사용하는 core 채널입니다. 현재 OpenClaw Telegram 가이드는 정확한 @BotFather 계정에서 bot을 만들고 token을 설정하도록 안내합니다. 기본 transport는 long polling이고 webhook은 선택 사항입니다. Telegram은 openclaw channels login telegram으로 로그인하는 채널이 아닙니다.
1. bot identity를 만들고 token을 Gateway host에 보관하세요
Telegram에서 정확한 @BotFather를 열고 /newbot을 실행한 뒤 bot 이름과 username을 만드세요. 반환된 token은 default account라면 TELEGRAM_BOT_TOKEN environment fallback으로, named account라면 해당 account의 botToken 또는 tokenFile로 보호할 수 있습니다. shell history에 실제 값을 넣는 방법은 피하세요.
hljs bashopenclaw channels add --channel telegram --use-env openclaw gateway
2. group보다 먼저 DM 발신자 한 명을 승인하세요
bot에 DM을 하나 보냅니다. 기본 dmPolicy: "pairing"에서는 아직 승인되지 않은 sender에게 일회성 code가 표시됩니다. 방금 자신이 만든 요청인지 확인한 뒤 그 code만 승인하세요.
hljs bashopenclaw pairing list telegram openclaw pairing approve telegram <CODE>
현재 pairing code는 한 시간 후 만료됩니다. 이 승인은 해당 DM identity의 접근을 허용하는 것이지, 모든 group과 group command, owner command, tool approval을 자동으로 허용하는 것이 아닙니다.
3. user ID와 group chat ID를 서로 바꾸지 마세요
Telegram에서는 양수 numeric user ID와 흔히 -100으로 시작하는 음수 group 또는 supergroup chat ID가 다른 역할을 합니다.
- 양수 user ID는
allowFrom또는groupAllowFrom에서 누가 보낼 수 있는지 결정합니다. - 음수 group chat ID는
channels.telegram.groups아래에서 어느 공유 대상을 사용할지 결정합니다.
음수 group ID를 groupAllowFrom에 넣으면 그 group의 sender를 허용한 것이 아닙니다. 통제된 test message를 보내면서 openclaw logs --follow에서 ID를 확인하고, 첫 group에서는 requireMention: true를 유지하세요. Telegram Privacy Mode도 어떤 group message가 bot에 도달하는지 바꿉니다. mention과 allowlist 동작을 이해하지 못한 상태에서 Privacy Mode를 끄거나 bot에 administrator 권한을 주지 마세요.
Telegram 첫 합격 조건: probe가 예상 bot을 해석하고, 승인된 DM이 Gateway에 들어오며, model 처리 뒤 같은 DM에 답장이 보여야 합니다. 그 다음에 group ID 하나만 추가하고 명시적인 @botusername mention으로 같은 경로를 다시 확인하세요.
Discord는 비공개 server와 최소 권한으로 시작하세요
Discord는 application과 bot을 만들고 Discord 공식 Gateway에 연결하는 plugin 채널입니다. bot의 online 표시는 transport 일부가 작동했다는 신호일 뿐입니다. message content가 전달되는지, 대상 user가 허용되었는지, 원래 channel에 답장할 수 있는지는 별도로 확인해야 합니다.
1. 첫 text route에 필요한 intent만 켜세요
OpenClaw Discord 가이드에 따라 Discord Developer Portal에서 application과 bot을 만드세요. intent는 용도를 구분해서 선택합니다.
- Message Content Intent: 일반적인 text message 내용을 처리하는 데 필요합니다.
- Server Members Intent: 권장됩니다. role allowlist, name-to-ID matching, channel audience access group이 member data를 사용할 때는 필요합니다.
- Presence Intent: presence update가 실제 업무에 포함될 때만 선택합니다.
invite에는 bot과 applications.commands scope를 사용합니다. 첫 text channel test에서는 View Channels, Send Messages, Read Message History, Embed Links, Attach Files를 기준으로 삼으세요. Add Reactions는 선택이고, Send Messages in Threads는 처음부터 thread를 사용할 때만 필요합니다. voice, moderation, role management, broad administrator permission은 나중에 별도 기능으로 추가합니다.
2. DM 또는 private server channel 하나만 허용하세요
Gateway host에 DISCORD_BOT_TOKEN을 설정하고 현재 channel add 경로를 사용합니다.
hljs bashopenclaw channels add --channel discord --use-env openclaw channels status --channel discord --probe
Discord privacy 설정상 DM을 사용할 수 있다면 먼저 한 명을 pairing하세요.
hljs bashopenclaw pairing list discord openclaw pairing approve discord <CODE>
server test에서는 직접 관리하는 private server와 channel 하나만 선택하세요. groupPolicy: "allowlist"를 유지하고 numeric server ID와 user ID를 적으며 mention을 요구합니다.
hljs json5{ channels: { discord: { groupPolicy: "allowlist", guilds: { "YOUR_SERVER_ID": { requireMention: true, users: ["YOUR_USER_ID"] } } } } }
Discord 첫 합격 조건: probe가 올바른 bot identity와 필요한 intents를 확인하고, 의도한 user가 DM 또는 allowlist된 channel에서 message를 하나 보낸 뒤 같은 위치에서 답장을 봐야 합니다. bot이 online인데 server text가 들어오지 않는다면 Message Content Intent, guild/channel allowlist, user restriction, mention 순서로 확인하세요. 해결을 위해 모든 permission을 한꺼번에 부여하지 마세요.
Slack은 scope 목록보다 배치 방식을 먼저 고르세요
Slack 설정은 어떤 scope를 붙일지보다 network와 deployment를 먼저 정하는 작업입니다. 공식 plugin을 설치한 뒤 현재 OpenClaw Slack 가이드에 따라 Socket Mode 또는 HTTP Request URLs를 선택합니다.
hljs bashopenclaw plugins install @openclaw/slack
| 배치 조건 | Socket Mode | HTTP Request URLs |
|---|---|---|
| 공개 inbound Gateway URL | 필요 없음 | DNS, TLS, 외부에서 도달 가능한 event path 필요 |
| 연결 방향 | Gateway에서 Slack으로 outbound WebSocket | Slack에서 Gateway로 signed HTTPS request |
| credential | bot token + connections:write App-Level Token | bot token + signing secret |
| 자연스러운 첫 환경 | 단일 Gateway, 개발 host, firewall 안쪽 | 여러 Gateway 또는 기존 public webhook 환경 |
두 mode는 messaging과 interaction 기능 수준이 같으므로 network와 scaling 책임을 기준으로 고릅니다. 두 credential 세트를 failover처럼 동시에 설정하지 마세요. Socket app token과 bot token은 같은 Slack app과 workspace에 속해야 합니다. HTTP mode는 같은 app의 signing secret으로 각 request를 검증해야 합니다.
가장 작은 manifest로 DM 하나나 mention 하나를 통과시키세요
현재 Slack 공식 channel page의 minimal manifest를 출발점으로 사용하세요. 첫 DM 또는 mention에 필요하지 않은 file, reaction, history, App Home, slash command, interactive scope를 모두 추가하지 마세요. 다음 실제 기능이 필요할 때 scope와 event를 하나씩 늘리고, 그 기능 test뿐 아니라 원래 text reply도 다시 확인합니다.
Slack DM은 기본적으로 pairing을 사용합니다.
hljs bashopenclaw pairing list slack openclaw pairing approve slack <CODE>
공유 channel은 화면에 보이는 #channel-name이 아니라 C... 형태의 stable channel ID로 allowlist하세요. allowlist policy 아래에서는 name-based key가 무시되어 app은 연결되었지만 침묵하는 것처럼 보일 수 있습니다. channel message는 기본적으로 mention gate가 적용되므로 첫 test에서는 그대로 유지하세요.
Slack 첫 합격 조건: probe가 같은 app/workspace에 속한 credential과 선택한 transport를 해석하고, pairing된 DM 또는 allowlist channel의 mention이 들어오며, 답장이 같은 DM이나 thread에 보여야 합니다. configured_unavailable, token 조합 불일치, missing scope, signature failure는 credential 또는 transport 문제입니다. allowlist를 넓혀서 해결할 문제가 아닙니다.
WhatsApp은 번호와 QR session의 소유자를 먼저 정하세요
WhatsApp는 전화번호를 WhatsApp Web/Baileys를 통해 Gateway-owned session에 연결하는 plugin 채널입니다. 현재 OpenClaw WhatsApp 가이드가 설명하는 것은 별도의 Twilio WhatsApp channel이 아니라 QR로 인증한 linked-device session입니다.
interactive channel 경로는 plugin이 없을 때 설치를 제안할 수 있습니다. 현재 문서의 manual source는 다음과 같습니다.
hljs bashopenclaw plugins install clawhub:@openclaw/whatsapp
1. 어느 번호가 OpenClaw identity가 될지 결정하세요
전용 번호는 사용자에게 보이는 identity와 allowlist를 명확하게 만들기 때문에 권장됩니다. 개인 번호와 self-chat을 쓰는 구성도 지원되지만, sender와 linked account가 같은 사람이 되는 경계가 생깁니다. QR을 읽기 전에 번호 소유자, device를 unlink 또는 relink할 담당자, authentication directory를 보관할 host를 정하세요.
문서와 config에는 E.164 형태의 placeholder만 넣고 첫 group policy는 닫아 둡니다.
hljs json5{ channels: { whatsapp: { dmPolicy: "pairing", allowFrom: ["<YOUR_NUMBER_E164>"], groupPolicy: "allowlist", groupAllowFrom: ["<YOUR_NUMBER_E164>"] } } }
2. phone이 읽을 수 있는 live QR로 연결하세요
hljs bashopenclaw channels login --channel whatsapp
login은 QR-only입니다. phone 카메라가 바로 읽을 수 있는 live QR을 terminal에 표시하세요. screenshot이나 chat attachment로 전달하는 동안 QR이 만료될 수 있습니다. 연결 후 만들어지는 authentication directory는 token과 같은 credential입니다. Gateway가 socket과 reconnect loop를 소유하므로, 명확한 account migration 계획 없이 directory를 여러 host에 복사하면 session owner가 경쟁할 수 있습니다.
첫 sender가 pairing을 시작하면 자신이 만든 code만 승인하고 live 상태를 probe하세요.
hljs bashopenclaw pairing list whatsapp openclaw pairing approve whatsapp <CODE> openclaw channels status --channel whatsapp --probe
WhatsApp 첫 합격 조건: 예상한 linked account가 live이고, 승인된 번호의 message가 Gateway에 들어오며, 답장이 같은 chat에 보여야 합니다. 이 증거가 안정되기 전에는 group, 추가 전화번호, 두 번째 linked account를 넣지 마세요.
한 문장이 같은 대화로 돌아오는 전 과정을 확인하세요
이제 config가 저장되었는지가 아니라 실제 message 경로를 확인합니다. token이 유효해도 sender가 차단될 수 있고, socket이 connected여도 event가 허용되지 않을 수 있으며, model이 완료되어도 원래 thread로 답장을 보내지 못할 수 있습니다.
test message를 보내기 전에 관찰할 표면을 엽니다.
hljs bashopenclaw channels status --probe --json openclaw channels logs --channel all openclaw logs --follow
의도한 sender가 다른 message와 구별되는 짧은 문장을 하나 보냅니다. 예를 들어 Reply exactly: CHANNEL-OK-714를 사용할 수 있습니다. 보낸 시각과 사용한 DM, group, server channel, workspace channel 또는 WhatsApp chat을 함께 기록하세요.
| 확인 지점 | 통과 증거 | 여기서 처음 실패할 때 볼 범위 |
|---|---|---|
| 계정 | probe가 예상 bot, app, workspace 또는 linked number를 해석 | 잘못된 account, credential, unresolved secret, stale session |
| 연결 | core/plugin runtime과 provider connection이 healthy | plugin install, Gateway network, Socket/HTTP, Discord Gateway, Telegram polling, WhatsApp session |
| 접근 | sender와 destination이 pairing/allowlist에 일치 | pairing, sender ID, group/channel ID, guild/workspace, mention, command authorization |
| 수신 | unique message가 지정한 시간의 log에 나타남 | platform event, intent, subscription, privacy mode, routing |
| 모델 | 선택한 agent/model이 해당 turn을 완료 | provider auth, model availability, rate, timeout, agent route |
| 전송 | 원래 route와 destination으로 delivery attempt가 보임 | platform permission, signing/session state, thread target, send failure |
| 보이는 답장 | 승인 sender가 같은 위치에서 정확한 답장을 확인 | destination/thread 불일치, client visibility, outbound delivery |
일곱 지점이 모두 통과해야 첫 채널이 준비되었다고 판단할 수 있습니다. account label, 비밀이 아닌 destination ID 또는 hash, probe 결과, timestamp, 관련 error line, 보이는 답장을 redacted 기록으로 남기세요. token 값, signing secret, session file, QR data, private message 전문, 무관한 log는 제거합니다.
접근 범위는 한 번에 한 항목만 넓히세요
첫 답장이 성공한 뒤에도 여러 경계를 동시에 넓히지 않습니다. private sender에서 시작해 authorization 또는 운영 복잡성을 한 단계씩 증가시켜야 어느 변화가 문제를 만들었는지 알 수 있습니다.
| 다음 확장 | 바뀌는 경계 | 다음 단계 전에 다시 할 test |
|---|---|---|
| DM 한 명 pairing | private sender 한 명이 bot에 도달 | 같은 sender의 inbound, model completion, visible reply |
| 명시 allowlist 한 명 추가 | 임시 pairing에서 durable identity로 이동 | probe와 같은 DM test |
| group/channel 하나 추가 | 공유 destination과 stable ID가 범위에 포함 | 승인 user의 mention message와 같은 위치의 답장 |
| optional feature 하나 추가 | scope, event, intent, media, file, command 또는 interaction 증가 | feature 동작과 원래 text reply를 모두 확인 |
| user 추가 | route를 호출할 수 있는 사람이 증가 | 허용된 sender와 허용되지 않은 sender를 각각 test |
| 두 번째 account/channel 추가 | identity, secret, transport, routing, 복구 담당이 새로 생김 | 새 route에서 일곱 지점 전체를 다시 확인 |
open은 pairing 다음의 편리한 단계가 아니라 완전히 다른 운영 모델입니다. open DM policy는 명시적 wildcard를 요구하며, bot을 찾을 수 있는 모든 account가 접근할 수 있습니다. 의도적으로 public bot을 운영하고, tool을 제한하고, abuse control을 갖추고, 노출을 책임질 owner가 있을 때만 선택하세요.
command authorization도 별도 경계입니다. DM sender를 pairing했다고 해서 모든 group에서 privileged command와 tool을 사용할 수 있는 것은 아닙니다. commands.ownerAllowFrom, channel allowlist, group sender rule, tool approval을 실제 operator와 맞춰 검토하세요.
첫 번째로 증거가 끊긴 지점만 수리하세요
acceptance test가 실패해도 설정 전체를 다시 만들 필요는 없습니다. 처음으로 통과 증거가 사라진 지점을 수리 담당으로 정하세요.
| 증상 | 가능성이 높은 담당 | 다음의 작은 조치 |
|---|---|---|
channels list --all에 채널이 없음 | catalog, plugin, installation | 현재 channel page와 channels add --channel <name>을 확인하고 임의 config key를 만들지 않음 |
| Gateway probe 실패 | OpenClaw runtime/service | 채널 작업을 멈추고 installation 또는 Gateway를 먼저 복구 |
| credential이 invalid/unavailable | secret resolution, platform identity | 선택 account를 확인하고 필요한 credential 하나만 rotate |
| connected지만 inbound 없음 | pairing, allowlist, mention, event, intent, platform privacy | sender와 destination을 선택한 채널 규칙에 맞춰 비교 |
| inbound는 있으나 model 완료 없음 | agent/model/provider route | model route를 독립 test하고 channel permission을 넓히지 않음 |
| model 완료 후 visible reply 없음 | outbound permission, destination/thread, session, platform send | outbound log와 실제 목적지를 확인 |
| setup 뒤 bot이 online이지만 침묵 | 연결된 route의 runtime | OpenClaw 응답 없음 진단에서 처음 사라진 증거를 찾음 |
| secret 또는 linked session 노출 | platform credential와 incident response | 해당 credential만 revoke/rotate하고 필요하면 session을 unlink한 뒤 재검증 |
plugin reinstall, 모든 token rotation, Gateway restart, group policy 변경, model 변경을 한 번의 시도에 넣지 마세요. 어떤 변화가 영향을 주었는지 알 수 없습니다. 한 번에 하나만 바꾸고, 실패했던 정확한 message를 원래 destination에서 다시 보내 visible reply까지 확인하세요.
자주 묻는 질문
OpenClaw에서 Telegram, Discord, Slack, WhatsApp 중 무엇을 먼저 연결해야 하나요?
직접 관리할 수 있는 identity와 deployment로 고르세요. 개인용 전용 bot은 Telegram, 관리 가능한 private server는 Discord, app 설치 권한이 있는 workspace는 Slack, 전화번호가 입구인 흐름은 WhatsApp가 자연스럽습니다. 모든 사람에게 같은 최고 채널은 없습니다.
channel 또는 plugin unavailable 메시지는 왜 나오나요?
openclaw channels list --all을 실행해 core, installed, configured, enabled, installable을 구분하세요. Telegram은 현재 core이고 Discord, Slack, WhatsApp는 plugin입니다. 오래된 package spec을 추측하지 말고 현재 공식 설치 명령이나 openclaw channels add --channel <name>이 catalog source를 해석하도록 하세요.
Telegram도 openclaw channels login telegram으로 연결하나요?
아닙니다. 정확한 @BotFather에서 bot을 만들고, token을 protected config 또는 environment에 넣고 Gateway를 시작합니다. interactive channel login은 WhatsApp처럼 QR 또는 linked session을 사용하는 채널에 해당합니다.
DM pairing을 승인하면 group에서도 바로 사용할 수 있나요?
아닙니다. DM pairing은 해당 sender identity의 private access를 승인합니다. group, guild, workspace, channel, group sender, mention, command는 별도 규칙입니다. destination ID 하나만 추가하고 승인 user의 mention으로 다시 test하세요.
Discord의 첫 text test에 필요한 최소 권한은 무엇인가요?
Message Content Intent를 켜고, bot과 applications.commands scope로 invite하세요. 대상 channel에 View Channels, Send Messages, Read Message History, Embed Links, Attach Files를 기준으로 부여합니다. Server Members Intent는 권장되며 role 또는 audience control에 member data가 필요하면 필수입니다. reaction, thread, voice, moderation, presence는 나중 단계입니다.
Slack은 Socket Mode와 HTTP Request URLs 중 무엇을 선택해야 하나요?
단일 Gateway 또는 public inbound URL을 받을 수 없는 host라면 Socket Mode가 적합합니다. 여러 Gateway나 이미 public webhook 환경이 있다면 HTTP Request URLs가 자연스럽습니다. Socket은 bot token과 App-Level Token을, HTTP는 bot token과 signing secret을 사용합니다.
channel token과 WhatsApp session은 어디에 보관해야 하나요?
Gateway host의 protected environment, file 또는 현재 SecretRef에 보관하세요. token 값, Slack signing secret, WhatsApp auth directory, QR data, pairing code를 chat, screenshot, issue, repository에 넣지 마세요.
bot이 online인데 답장이 없으면 무엇부터 보나요?
openclaw channels status --probe와 제한된 시간의 log를 열고 unique message를 하나 보냅니다. 계정, 연결, 접근, 수신, 모델, 전송, 보이는 답장 중 첫 번째로 증거가 없는 지점에서 멈추세요. online 표시만 보고 permission을 추가하지 마세요.
두 번째 채널은 언제 추가할 수 있나요?
첫 route가 한 sender로 일곱 지점을 모두 통과하고, group 또는 feature 한 항목을 확장한 뒤에도 원래 text reply가 안정적으로 돌아올 때입니다. 두 번째 채널은 새 identity, plugin/transport, credential, policy, routing, failure owner를 만들므로 새 acceptance 기록이 필요합니다.
WhatsApp 전용 번호가 반드시 필요한가요?
필수는 아니지만 권장됩니다. 전용 번호는 사용자에게 보이는 identity와 allowlist를 명확하게 만듭니다. 개인 번호/self-chat을 쓰더라도 번호와 linked session 소유자, 보관 host, unlink/relink 담당자를 정하고 한 chat의 답장을 확인한 후 group을 추가하세요.
첫 목표는 연결된 채널 수가 아닙니다. 보호된 route 하나에서 누가 보냈고, 어느 경로를 거쳤고, 어디에 답장이 돌아왔는지 설명할 수 있어야 합니다. 다음에 넓힐 범위, 그 범위를 관리할 사람, 같은 경로를 다시 증명할 message를 말할 수 있을 때 다음 한 항목으로 진행하세요.
