OpenClaw 튜토리얼 5편: Channels, Group Mention, Pairing, Security를 어떻게 운영해야 하나
개요
OpenClaw 공식 문서를 보면 이 프로젝트는 기능보다도 운영 안전성을 매우 중시합니다.
특히 채널을 열고 그룹에 참여시키는 순간 중요한 개념이,
- DM policy
- groupPolicy
- allowlist
- pairing
- mention gating
- security posture
입니다.
이 문서는 공식 문서를 바탕으로 OpenClaw를 안전하게 채널에 붙이는 관점을 정리합니다.
---
1. OpenClaw 채널 운영의 기본 철학
관련 문서를 보면 OpenClaw는 초반부터 “열어두는 봇”보다 승인된 assistant 쪽에 가깝습니다.
결국 기본 질문은,
- 누가 이 assistant에게 말을 걸 수 있나?
- 그룹에서 언제 반응해야 하나?
- 어떤 디바이스가 붙을 수 있나?
입니다.
---
2. DM policy는 입구를 결정한다
공식 설정 문서 기준 DM access는 채널별 dmPolicy로 제어합니다.
대표 모드는 이렇습니다.
- `pairing`
- `allowlist`
- `open`
- `disabled`
추천 해석
- `pairing` = 처음에는 가장 안전한 기본값
- `allowlist` = 명시적으로 허용된 사용자만
- `open` = 아주 신중하게만
- `disabled` = DM 차단
결국 처음 운영할 때는 pairing 또는 allowlist가 사실상 기본입니다.
---
3. Pairing은 OpenClaw의 owner approval 구조다
공식 pairing 문서 기준 pairing은 두 가지에 쓰입니다.
1) DM pairing
누가 봇과 대화할 수 있는지 승인
2) Node pairing
어떤 디바이스/node가 gateway에 붙을 수 있는지 승인
이 구조는 중요합니다.
OpenClaw는 “메시지가 오면 다 처리”가 아니라,
승인 절차를 명시적으로 넣는 시스템입니다.
---
4. 그룹에서는 mention gating이 핵심이다
공식 groups 문서 기준 기본 흐름은 이렇습니다.
- groupPolicy로 그룹 허용 여부 결정
- allowlist로 그룹/발신자 허용 여부 결정
- mention gating으로 실제 reply 여부 결정
결국 그룹에서의 결국 핵심은 “읽을 수 있는가”보다 언제 말할 것인가입니다.
왜 중요하나
그룹에 assistant를 넣으면 가장 큰 문제는 과잉 반응입니다.
OpenClaw는 이를 mention gating으로 통제합니다.
---
5. groupPolicy를 어떻게 이해해야 하나
공식 문서 기준 대표 정책,
- `open`
- `disabled`
- `allowlist`
실전 해석
- `open` = 허용 폭이 넓음, 신중해야 함
- `disabled` = 그룹 차단
- `allowlist` = 특정 그룹/허용 대상만
처음에는 거의 항상 allowlist + requireMention 조합이 맞습니다.
---
6. Group mention gating은 왜 좋은가
공식 groups 문서는 기본적으로 그룹 replies에 mention 요구를 강하게 권장합니다.
예:
{
channels: {
telegram: {
groups: {
"*": { requireMention: true }
}
}
}
}
이 구조의 장점:
- assistant가 그룹 대화를 다 가로채지 않음
- 필요한 순간에만 참여
- 문맥은 보되, 발화는 절제
결국 “참여는 하지만 지배하지는 않는” assistant로 만들기 좋습니다.
---
7. 채널이 많아질수록 더 보수적으로 시작해야 한다
공식 channels 문서를 보면 OpenClaw는:
- WhatsApp
- Telegram
- Discord
- Slack
- Signal
- BlueBubbles
- WebChat
- 각종 plugin 채널
등을 지원합니다.
하지만 채널이 많아질수록 중요한 건 기능보다 운영 일관성입니다.
추천 원칙
- 채널 하나 먼저
- allowlist/pairing 먼저
- 그룹 mention gating 먼저
- 그다음 확장
---
8. Pairing과 allowlist의 실제 의미
공식 문서에 따르면 pairing state와 allowlist state는 자격을 게이트하는 민감한 정보입니다.
결국 이건 단순 사용자 편의 기능이 아니라,
assistant 접근 통제 정책입니다.
운영 관점에선:
- 누가 DM 가능한지
- 누가 node로 붙는지
- 어떤 채널/그룹이 허용되는지
를 명시적으로 관리해야 합니다.
---
9. Security를 왜 먼저 봐야 하나
OpenClaw는 에이전트가:
- 파일을 읽고 쓰고
- 명령을 실행하고
- 메시지를 보내고
- 디바이스 기능을 쓸 수 있는 구조
로 확장될 수 있습니다.
그래서 채널/그룹 접근을 허술하게 열어두면, assistant가 예상보다 넓은 공격면을 갖게 됩니다.
이렇게 보면 OpenClaw의 보안은 단지 API 키 숨기기가 아니라,
누가 assistant를 깨울 수 있나를 정하는 문제입니다.
---
10. 처음 세팅할 때 추천 구조
DM
- `dmPolicy: pairing` 또는 `allowlist`
Group
- `groupPolicy: allowlist`
- `requireMention: true`
Node
운영 원칙
- 처음에는 필요한 사람/그룹만 허용
- 점진적으로 확장
- noisy group은 mention gating 필수
---
11. 콘텐츠 관점에서 중요한 메시지
이 주제는 단순 설정 튜토리얼보다,
“왜 OpenClaw가 이렇게 보수적으로 설계됐는가”를 설명하는 쪽이 더 좋습니다.
핵심 메시지:
- OpenClaw는 열려 있는 봇이 아니라 승인된 assistant다
- pairing과 mention gating은 귀찮은 옵션이 아니라 운영 핵심이다
- assistant가 강력해질수록 입구를 더 좁혀야 한다
---
결론
OpenClaw의 채널/그룹/보안 구조를 이해하면,
이 프로젝트가 단순 통합 봇이 아니라 운영 가능한 assistant 시스템이라는 점이 더 잘 보입니다.
결국 처음에는 기능보다:
- DM policy
- groupPolicy
- pairing
- mention gating
을 먼저 설계해야 합니다.
---
출처
- Channels index: `/app/docs/channels/index.md`
- Groups: `/app/docs/channels/groups.md`
- Pairing: `/app/docs/channels/pairing.md`
- Configuration: `/app/docs/gateway/configuration.md`