본 글은 GitHub에서 공개된 오픈소스 프로젝트 openclaw/openclaw의 README를 1차 출처로, 한국 백엔드·플랫폼 개발자가 도입을 검토할 때 점검할 항목을 정리합니다.

대상 독자는 사내 메신저·채팅 채널에서 동작하는 개인용 AI 어시스턴트를 직접 운영해 보고 싶은 개발자입니다. 2026년 5월 기준 GitHub README와 공식 문서를 인용하며, 실행 환경은 Node 24(권장) 또는 Node 22.19+를 가정합니다.
1. OpenClaw — 개인용 AI 어시스턴트 게이트웨이
OpenClaw 공식 README에 따르면 OpenClaw는 사용자의 디바이스에서 직접 실행되는 단일 사용자(single-user) AI 어시스턴트입니다. 핵심 컴포넌트는 Gateway로 불리며, 세션·채널·툴·이벤트를 관리하는 컨트롤 플레인 역할을 합니다.
같은 README는 macOS와 iOS/Android에서 음성으로 듣고 말할 수 있고, Live Canvas라는 시각 워크스페이스를 에이전트가 직접 렌더링한다고 정리합니다. 즉 게이트웨이는 제어 평면이고, 실제 사용자가 체감하는 가치는 어시스턴트 동작 자체에 있다고 명시되어 있습니다.
2. 지원 채널과 통합 범위
OpenClaw README 기준 지원 채널은 매우 광범위합니다. WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage, IRC, Microsoft Teams, Matrix, Feishu, LINE, Mattermost, Nextcloud Talk, Nostr, Synology Chat, Tlon, Twitch, Zalo, Zalo Personal, WeChat, QQ, WebChat을 동일 README에서 명시하고 있습니다.
한국 개발팀 입장에서 주목할 채널은 사내에서 흔히 쓰는 Slack, Microsoft Teams, Mattermost, Discord입니다. 그 외 한국 사용자가 많은 LINE도 공식 채널 목록에 포함됩니다. 다만 카카오톡은 README 채널 목록에 등장하지 않으므로 도입 시점에 따로 확인이 필요합니다.
3. 설치 절차 (Node 24 기준)

OpenClaw README의 “Install (recommended)” 섹션은 Node 24(권장) 또는 Node 22.19+를 명시합니다. 전역 설치 후 onboard 커맨드로 게이트웨이 데몬을 등록하는 흐름입니다.
npm install -g openclaw@latest
openclaw onboard --install-daemon
openclaw gateway --port 18789 --verbose
onboard 명령은 macOS의 launchd 또는 Linux의 systemd user 서비스로 게이트웨이를 등록한다고 같은 README가 설명합니다. Windows의 경우 WSL2 사용이 강력히 권장됩니다. pnpm·bun도 동일하게 지원됩니다.
4. 보안 기본값 — DM 정책과 페어링
OpenClaw README의 “Security defaults (DM access)” 섹션은 인바운드 DM을 신뢰할 수 없는 입력(untrusted input)으로 간주합니다. 기본 동작은 Telegram·WhatsApp·Signal·iMessage·Microsoft Teams·Discord·Google Chat·Slack에서 동일하게 적용된다고 명시되어 있습니다.
4-1. dmPolicy=”pairing” 기본 동작
같은 README에 따르면 알 수 없는 발신자에게는 짧은 페어링 코드가 발급되고 메시지 자체는 봇이 처리하지 않습니다. 운영자가 openclaw pairing approve <channel> <code> 명령으로 승인해야 로컬 allowlist에 추가됩니다.
4-2. dmPolicy=”open” — 공개 DM 허용
공개 인바운드 DM은 명시적 옵트인이 필요합니다. README는 dmPolicy="open" 설정과 함께 allowFrom에 "*" 와일드카드를 넣어야 한다고 못 박고 있습니다. 운영자가 의도하지 않고는 외부 메시지가 처리되지 않도록 막는 구조입니다.
4-3. 그룹·채널 샌드박싱
OpenClaw README “Security model (important)” 섹션은 그룹·채널 안전을 위해 agents.defaults.sandbox.mode: "non-main" 설정을 권장합니다. 기본 백엔드는 Docker이며 SSH와 OpenShell 백엔드도 선택할 수 있다고 같은 문서가 설명합니다.
5. 도구·세션 모델
OpenClaw README의 “First-class tools” 항목은 browser, canvas, nodes, cron, sessions와 Discord/Slack actions를 1급 도구로 분류합니다. 같은 README “Operator quick refs”의 세션 도구로는 sessions_list, sessions_history, sessions_send가 명시됩니다.
운영 관점에서 중요한 부분은 채팅 명령입니다. /status, /new, /reset, /compact, /think <level>, /verbose on|off, /trace on|off, /usage off|tokens|full, /restart, /activation mention|always가 README에 직접 나열되어 있어, 별도 관리 UI 없이도 운영 액션이 가능합니다.
6. 도입 판단 가이드

OpenClaw는 단일 사용자 어시스턴트라는 점이 가장 중요한 제약입니다. README가 강조하는 “single-user” 정체성을 무시하고 팀 전체용으로 확장하려 한다면 보안 모델과 자원 사용 모델이 맞지 않을 가능성이 높습니다. 다음 체크리스트가 판단에 도움이 됩니다.
- 도입 목적이 개인 생산성인가, 팀 공동 어시스턴트인가 (후자라면 부적합)
- 운영할 채널에서 인바운드 DM이 외부 사용자에게 노출되는가 (노출 시 pairing 정책 필수)
- 그룹·공용 채널에서도 동작시키려는가 (sandbox 비-main 모드 적용 가능 여부)
- 호스트 OS에 Docker 또는 SSH 백엔드를 운영 가능한 자원이 있는가
- 모델 자격증명을 어디에 저장할지, 회사 보안 정책과 충돌하지 않는지 확인했는가
위 항목 중 2개 이상에서 부적합 신호가 나오면 사내 도입은 미루고 개인 환경 PoC로 한정하는 편이 안전합니다. 공식 README 또한 원격 노출 전에 Security, Sandboxing, Configuration 문서를 먼저 읽도록 권고합니다.
7. 관련 글
본 글의 보안·도입 판단 맥락을 확장해서 읽기 좋은 기존 글을 정리합니다.
- BitLocker YellowKey 익스플로잇 — 백도어 의혹과 디스크 암호화 운영 점검 — 메신저 인바운드를 신뢰할 수 없는 입력으로 다루는 OpenClaw의 기본 모델과 같은 결의 보안 운영 사례입니다.
- AI 의존 시대, 시니어 개발자가 잃지 말아야 할 5가지 역량 — 개인 AI 어시스턴트 도입이 개인 역량에 어떤 영향을 미치는지를 함께 고민해 볼 글입니다.
- Erlang/OTP 29.0 메이저 릴리즈 — 한국 백엔드 팀 도입 체크리스트 — 새 도구 도입 시 운영 책임자·EOL 조건을 정리하는 체크리스트 패턴이 본 글과 동일합니다.
📌 함께 보시면 좋은 글
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요