30. OpenClaw 채널은 연결됐는데 답이 없을 때 해결

채널 연결은 살아 있는데 OpenClaw가 아무 말도 안 하면, 많은 사람이 바로 재설치부터 생각한다. 그런데 공식 문서 기준으로는 이 증상이 꽤 자주 연결 문제가 아니라 라우팅·권한·멘션 규칙 문제다. 특히 DM pairing이 아직 승인되지 않았거나, 그룹에서 mention gating이 켜져 있거나, allowlist가 맞지 않으면 채널은 정상이어도 답장은 안 나간다.

공식 Gateway troubleshooting 문서도 No replies 섹션에서 먼저 openclaw status, openclaw channels status --probe, openclaw pairing list, openclaw config get channels, openclaw logs --follow 순서로 보라고 안내한다. 핵심은 하나다. 연결 상태와 응답 조건은 다르다. 채널이 살아 있어도, 누가 어떤 방식으로 말을 걸었는지 조건이 안 맞으면 OpenClaw는 조용할 수 있다.

flowchart TD
A[채널 연결은 정상] --> B{DM 인가 그룹인가?}
B -->|DM| C{pairing 승인됨?}
C -->|아니오| D[openclaw pairing list 확인]
C -->|예| E[allowFrom/계정 범위 확인]
B -->|그룹| F{mention 필요?}
F -->|예| G[@멘션 또는 activation 규칙 확인]
F -->|아니오| H[group allowlist 확인]
D --> I[logs와 status 재확인]
E --> I
G --> I
H --> I
I --> J[응답 조건 충족 후 재테스트]

칠판 치트시트

채널 연결됨 ≠ 답장 가능 상태

DM은 pairing 승인부터 본다

그룹은 mention gating과 allowlist를 먼저 본다

재연결보다 status → channels status --probe → pairing → config → logs 순서가 빠르다

같은 증상이어도 DM 문제와 그룹 문제는 원인이 다르다

이런 증상이면 이 문서가 바로 맞다

openclaw status는 정상처럼 보이는데 답장이 안 온다.
채널 연결 테스트는 통과했는데, 실제 메시지에는 반응이 없다.
DM에서는 조용하고, pairing 코드만 오거나 아예 처리되지 않는다.
그룹에서는 읽는 것 같은데 답장하지 않는다.
최근 설정 변경 뒤부터 특정 사람/특정 방에서만 반응이 없다.

왜 이런 일이 생기는가

공식 문서 구조를 보면 OpenClaw는 단순히 “채널이 붙었는가”만으로 답장하지 않는다. DM은 Pairing 정책으로 발신자 승인을 먼저 볼 수 있고, 그룹은 Groups 문서에 나온 것처럼 groupPolicy, groups, groupAllowFrom, requireMention 같은 규칙을 함께 본다.

즉, 증상을 더 정확히 말하면 “메시지를 못 받는다”보다 메시지는 들어오는데, 응답 트리거 조건을 통과하지 못한다에 더 가깝다. 그래서 재설치, 재로그인, 재연결보다 먼저 누가 어떤 채널에서 어떤 형태로 말했는지를 따져야 한다.

가장 빠른 5분 복구 순서

1) 먼저 연결 문제인지 정책 문제인지 갈라본다

공식 문서의 첫 사다리는 아래 순서다.

openclaw status
openclaw channels status --probe
openclaw pairing list --channel <channel> [--account <id>]
openclaw config get channels
openclaw logs --follow

이 순서를 쓰는 이유는 단순하다. status와 channels status --probe가 정상이면, 그다음부터는 채널 자체보다 정책/권한 조건을 보는 편이 빠르기 때문이다.

실무 감각으로는 이렇게 보면 된다.

status도 비정상 → 연결/런타임 문제 가능성 큼
status는 정상, probe도 정상 → pairing·allowlist·mention 규칙 쪽 가능성 큼
특정 사람/특정 방만 문제 → 전역 장애보다 정책 범위 문제 가능성 큼

2) DM이면 pairing부터 확인한다

Pairing 문서에 따르면 DM 정책이 pairing이면, 모르는 발신자는 승인되기 전까지 메시지가 처리되지 않는다. 이때는 짧은 코드가 발급되고, 그 코드가 승인되기 전까지는 “채널은 살아 있는데 답이 없는 상태”처럼 보일 수 있다.

공식 문서 핵심 포인트는 이렇다.

pairing 코드는 8자, 대문자, 1시간 만료
pending DM pairing request는 채널당 기본 3건 제한
승인 전에는 메시지가 처리되지 않음

즉 DM에서 조용하면, 먼저 발신자가 이미 승인된 사람인지 봐야 한다. 여기서 자주 헷갈리는 건 DM 승인과 그룹 권한은 별개라는 점이다. DM에서 승인됐다고 그룹까지 자동 허용되는 건 아니다.

3) 그룹이면 mention gating을 먼저 본다

Groups 문서 기준으로 그룹은 기본적으로 더 제한적이다. 특히 groupPolicy: "allowlist"와 requireMention: true 조합이면, 허용된 그룹이어도 멘션이 없으면 답장을 안 할 수 있다.

문서의 빠른 흐름을 말로 옮기면 이렇다.

groupPolicy가 disabled면 그냥 드롭
allowlist인데 그룹이 허용되지 않으면 드롭
mention이 필요한데 멘션이 없으면 문맥용으로만 보고 답하지 않을 수 있음
그 조건을 모두 통과해야 실제 답장

그래서 그룹에서 답이 없으면 “읽었는데 왜 답 안 하지?”보다 멘션 조건을 만족했는가를 먼저 봐야 한다.

4) allowlist와 account 범위를 같이 본다

공식 Pairing 문서에는 allowlist 저장 위치가 기본 계정과 비기본 계정에서 다르게 관리된다고 나온다. 즉 같은 채널이라도 어느 accountId 기준으로 보고 있는지가 다르면, 승인했는데도 다른 계정 쪽에서는 허용되지 않은 것처럼 보일 수 있다.

이 지점에서 자주 생기는 실수는 아래와 같다.

기본 계정에서 승인했다고 생각했는데 실제 대화는 비기본 accountId로 들어옴
그룹 allowlist는 열었는데 groupAllowFrom에 해당 사용자가 없음
특정 그룹만 허용해야 하는데 groups 매핑이 비어 있음

즉 “설정은 했는데 왜 안 되지?”가 나오면, 값의 존재보다 적용 범위를 함께 봐야 한다.

5) 마지막은 logs에서 드롭 이유를 찾는다

공식 troubleshooting 문서의 No replies 섹션은 로그에서 이런 시그니처를 보라고 정리한다.

pairing request
drop guild message (mention required
blocked
allowlist

이런 문자열이 보이면, 연결이 아니라 정책에 의해 막힌 것이다. 이 단계가 중요한 이유는 추측을 멈추게 해주기 때문이다. 재로그인, 재배포, 서비스 재시작보다 왜 드롭됐는지 로그로 확인하는 편이 훨씬 빠르다.

현장 미니 사례 3개

사례 A) DM에서 코드만 오고 계속 조용함

상황: 새 사용자가 DM을 보냈는데 답장 대신 pairing 코드만 봄
원인: DM pairing 승인 전
복구: pairing list에서 pending 확인 후 승인
검증: 같은 발신자가 다시 보냈을 때 실제 처리되는지 확인

사례 B) 그룹방에서는 읽는 것 같은데 답 안 함

상황: 채널 연결 정상, 다른 곳에선 동작, 특정 그룹만 조용함
원인: requireMention 또는 group allowlist 미통과
복구: 실제 멘션 방식 확인 + 그룹 허용 범위 재확인
검증: 멘션 포함 메시지와 일반 메시지를 나눠 테스트

사례 C) 승인했는데도 특정 계정에서만 무반응

상황: 승인했다고 기억하는데 일부 계정/세션에서만 답 없음
원인: account 범위 또는 allowlist 저장 위치가 다름
복구: accountId 포함 상태와 allowlist 파일 범위를 다시 점검
검증: 어떤 account로 유입되는지 로그와 상태를 같이 봄

운영자가 바로 판단하는 기준

상황	먼저 볼 것	이유
DM만 무반응	pairing	승인 전이면 애초에 처리 안 됨
그룹만 무반응	requireMention / groupPolicy	그룹은 기본적으로 더 제한적
일부 사람만 무반응	allowlist / groupAllowFrom	연결보다 권한 범위 문제 가능성 큼
상태는 정상인데 실제 답 없음	logs 드롭 시그니처	정책 차단 원인을 가장 빨리 확인 가능
여러 계정 중 하나만 이상	accountId 범위	승인·allowlist 저장 범위가 다를 수 있음

검색형 FAQ

Q1. 채널 상태가 정상이면 답장도 정상이어야 하지 않나요?

아니다. 공식 문서 기준으로 연결 상태와 응답 조건은 별개다. 연결은 살아 있어도 pairing, allowlist, mention 조건이 안 맞으면 답이 없을 수 있다.

Q2. DM에서 pairing 승인했는데 그룹도 바로 되나요?

아니다. Pairing 문서에도 DM access와 group authorization은 별개라고 적혀 있다.

Q3. 그룹에서 멘션 없으면 무조건 무시되나요?

설정에 따라 다르지만, requireMention: true면 답장을 안 하는 구성이 흔하다. 이때는 문맥만 저장하고 조용할 수 있다.

Q4. 재로그인이나 재설치가 먼저인가요?

대개 아니다. 공식 runbook 순서대로 status → probe → pairing → config → logs를 먼저 보는 편이 훨씬 빠르다.

다음 읽기

한 줄 결론

채널이 연결돼 있다고 해서 답장 조건까지 충족된 건 아니다.
OpenClaw가 조용할 때는 재설치보다 먼저 pairing, mention gating, allowlist, account 범위를 보면 훨씬 빨리 풀린다.

※ 이 문서는 생성형 AI를 활용해 작성되었습니다.

일하는 ai

탐색기