OpenClaw 플러그인 — 생태계 가이드와 실용적인 선택

이 기사는 OpenClaw 플러그인에 대해 다룹니다. OpenClaw 플러그인은 채널, 모델 제공자, 도구, 음성, 메모리, 미디어, 웹 검색 및 기타 런타임 표면을 추가하는 네이티브 게이트웨이 패키지입니다.

이 글의 나머지 부분에서는 발견, 패키징, CLI 생명주기, 성숙도, 보안, 그리고 구체적인 플러그인 선택에 대해 다룹니다.

OpenClaw 스킬은 탐색과 안전에 중요합니다. ClawHub 와 공지 텍스트는 종종 설치 가능한 에이전트 팩과 워크플로우를 의미할 때 “스킬"이라고 표기합니다. 이러한 스킬은 플러그인을 사용하는 것과 동일한 레지스트리와 관련이 있지만, 검증된 openclaw.plugin.json 패키지와는 메커니즘이 다릅니다. 아래 용어집은 어휘를 명확히 유지하며, OpenClaw 스킬 가이드 에서는 작성, 중재, 사용 패턴, 역할별 스택에 대해 더 깊이 다룹니다.

동시에 공개 플러그인 생태계는 불균형합니다. 가장 강력한 부분은 여전히 번들된 1 차 표면과 유지 관리 및 사용량이 명확한 소수의 커뮤니티 플러그인입니다. 약한 부분은 데모에서는 인상적이지만 아직 공개적으로 채택된 신호가 얇은 비즈니스 자동화의 경계 사례이며, 성숙한 네이티브 플러그인이 아닌 스킬 지향적인 저장소도 이에 포함됩니다.

요약된 버전을 먼저 원하신다면 이것이 그 내용입니다. 현재 OpenClaw 에서 “실제로 유용한” 플러그인 레이어는 대부분 지루하지만 확실한 승리들입니다: 브라우저 접근, 웹 추출, 메모리, 제공자 라우팅, 음성, 채널, 관찰성, 그리고 워크플로우 트리거입니다. 가장 기업 친화적으로 들리는 카테고리 — CRM, 리드 생성, 인박스 자동화, 캘린더 오케스트레이션 — 도 공개적으로 존재하지만, 검증된 네이티브 플러그인 표면은 여전히 스택의 나머지 부분보다 훨씬 얇고 검증되지 않았습니다. 이는 비판이라기보다는 성숙도 신호입니다.

용어집 (플러그인, 확장, 스킬)

• OpenClaw 플러그인 — openclaw plugins …로 설치되고 openclaw.plugin.json 을 통해 검증되며, 게이트웨이 프로세스 내부에서 채널, 제공자, 도구, 메모리 백엔드 및 기타 후크를 등록할 수 있는 네이티브 게이트웨이 패키지입니다.
• OpenClaw 확장 — OpenClaw 가 번들된 기본값보다 먼저 플러그인 루트로 스캔하는 워크스페이스 및 글로벌 디렉터리입니다 (워크스페이스 하위의 확장 경로, 이후 ~/.openclaw). 이는 레이아웃 및 발견 아이디어입니다. 플러그인과 다른 종류의 아티팩트는 아니며, 플러그인 패키지가 로드되는 곳입니다.
• OpenClaw 스킬 — OpenClaw 스타일의 에이전트를 위해 자주 게시되며 패키지와 함께 ClawHub 에 나열되는 에이전트 지향 팩 및 워크플로우입니다. 보안 및 중재 메시지는 종종 “스킬"을 언급하는데, 이는 해당 레이어가 자체적인 채택 및 악용 역사를 가지고 있기 때문입니다. 스킬은 목록이 실제로 매니페스트가 있는 플러그인 패키지인 경우를 제외하고는 “네이티브 플러그인"의 동의어가 아닌 관련 설치 표면으로 취급해야 합니다.

OpenClaw 가 Codex, Claude, 또는 Cursor 생태계에서 콘텐츠를 가져올 때, 업스트림 문서는 종종 이를 번들이라고 부르지 네이티브 플러그인이라고 부르지 않습니다. 번들은 선택적 기능과 전체 플러그인보다 좁은 신뢰 경계로 매핑됩니다. 그 구별 없이 번들, 스킬 마케팅, 그리고 네이티브 OpenClaw 플러그인을 혼용하면 생태계가 실제로보다 더 넓어 보입니다.

왜 이 생태계가 중요한가

코드베이스와 CLI 내부에서 확장 이야기는 여전히 플러그인으로 표현됩니다. 발견은 명시적인 설정 경로를 먼저 걷고, 다음으로 확장 디렉터리, 그리고 번들 플러그인을 걷습니다. 동일한 기능 유형이지만 다른 루트입니다. 스킬은 ClawHub 를 탐색하거나 사고 보고서 (incident writeups) 를 읽을 때 그림에 등장하며, memory 또는 contextEngine 에 대한 슬롯 선택을 논할 때 등장하지는 않습니다.

플러그인 시스템 또한 유용한 방식으로 의견이 명확합니다. OpenClaw 는 플러그인을 장식적인 추가 레이어로 취급하지 않습니다. 채널, 모델 제공자, 도구, 메모리 백엔드, 컨텍스트 엔진, 음성, 실시간 음성, 미디어 이해, 이미지 생성, 비디오 생성, 웹 페치, 그리고 웹 검색과 같은 구체적인 런타임 소유권을 위해 사용합니다. 그 중 일부는 OpenClaw 내부에 번들되어 제공되며, 나머지는 npm 이나 ClawHub 에서 커뮤니티가 게시한 외부 패키지입니다.

그것이 플러그인 생태계가 처음엔 생각보다 더 중요한 이유입니다. 실무에서 플러그인 선택은 통합뿐만 아니라 어시스턴트가 검색, 기억, 호출, 라우팅, 페치, 추적, 그리고 장기 세션에서 생존하는 방식을 결정합니다. 기술 블로그로서 이것이 중요한 프레임입니다. “어떤 패키지가 멋져 보이는가"가 아니라 “어떤 패키지가 의미 있는 런타임 표면을 소유하는가"입니다.

플러그인 시스템이 실제로 작동하는 방식

내부적으로 OpenClaw 는 플러그인을 고정된 순서로 발견하며, 첫 번째 매칭이 우선합니다. 명시적인 설정 경로를 먼저 확인한 다음, 워크스페이스 확장 디렉터리, ~/.openclaw 하위의 글로벌 확장, 그리고 마지막으로 OpenClaw 와 함께 제공되는 번들 플러그인을 확인합니다. 워크스페이스 기원의 플러그인은 기본적으로 비활성화되며, 제한적인 허용 목록은 번들 플러그인조차 차단할 수 있고, 일부 기능 클래스는 memory 와 contextEngine 과 같이 독점적인 슬롯입니다.

그 슬롯 모델은 시스템에서 가장 화려하지는 않지만 가장 중요한 부분 중 하나입니다. 이는 플러그인이 단순히 추가적인 것이 아님을 의미합니다. 일부 카테고리에서는 선택기입니다. memory-core 가 활성 메모리 플러그인이 될 수 있고, memory-lancedb 가 이를 대체할 수 있으며, lossless-claw 와 같은 컨텍스트 엔진이 기본 레거시 컨텍스트 엔진을 대체할 수 있습니다. 이것이 메모리 플러그인이 UI 지향 플러그인보다 운영상 더 중요한 이유입니다. 그들은 메시지가 어디로 보내지는지뿐만 아니라 시간이 지남에 따라 어시스턴트가 어떻게 생각하는지를 변화시킵니다.

네이티브 플러그인 또한 상당히 엄격한 패키징 모델을 가집니다. 패키지는 package.json 을 통해 플러그인 엔트리 포인트와 설정 메타데이터를 광고하고, openclaw.plugin.json 은 OpenClaw 가 플러그인 코드를 실행하기 전에 플러그인 정체성과 설정을 검증하는 데 사용하는 매니페스트입니다. 그 매니페스트는 장식용이 아닙니다. 누락되거나 유효하지 않은 매니페스트는 플러그인 오류로 처리되어 설정 검증을 차단합니다. 플랫폼은 나중에 로드하고 희망하는 것보다 일찍 실패하려는 것을 분명히 시도하고 있습니다.

SDK 표면은 많은 블로그 게시물보다 더 광범위합니다. 플러그인 후크는 모델 해결, 에이전트 생명주기, 메시지 흐름, 도구 실행, 서브 에이전트 조정, 그리고 게이트웨이 생명주기를 가로챌 수 있으며, 문서에 따르면 SDK 는 28 개의 후크를 노출합니다. 이는 실제 런타임 제품을 구축하기에 충분한 권한이지만, 플러그인이 성숙하지 않다면 런타임 놀라움을 만들기에 충분한 권한이기도 합니다.

플러그인 구할 곳 및 생명주기 작동 방식

플러그인 설치는 항상 아래 openclaw plugins 명령을 통해 이루어집니다. ClawHub 는 네이티브 플러그인 패키지와 OpenClaw 스타일 스킬 항목을 모두 나열하므로, 매니페스트와 지원된 설치 경로를 위해 각 목록을 읽어야 합니다. 이 섹션은 플러그인 경로에 대해서만 다룹니다.

공개 레포지토리 레이어는 간단합니다. ClawHub 는 커뮤니티 플러그인과 많은 스킬 목록을 위한 정석 발견 표면이며, OpenClaw 는 ClawHub, npm, 로컬 경로, 로컬 아카이브, 그리고 지원되는 마켓플레이스에서 플러그인을 설치할 수 있습니다. 맨/package 이름의 경우, OpenClaw 는 먼저 ClawHub 를 확인하고 자동으로 npm 으로 폴백합니다. 이것만으로도 일반적인 생태계 질문 중 하나에 답합니다: 네, 공개 레포지토리 이야기가 있지만, 이는 공식 레지스트리 레이어와 npm 사이에 나뉩니다.

설치 및 제거 생명주기도 생태계 소문만큼 더 명확합니다. CLI 는 플러그인 나열, 검사, 활성화, 비활성화, 제거, 진단, 그리고 업데이트를 지원합니다. 설정 변경은 게이트웨이 재시작을 필요로 하지만, 기본 openclaw gateway 경로는 설정 쓰기 후 자동으로 재시작될 수 있습니다. 실무에서 임시 제거는 disable, 영구 제거는 uninstall이며, 검증 실패는 반쪽짜리 설치 상태를 남기지 않고 닫히도록 설계되었습니다.

실제로 필요한 명령은 간단합니다:

openclaw plugins list
openclaw plugins inspect <id>
openclaw plugins install <package>
openclaw plugins enable <id>
openclaw plugins disable <id>
openclaw plugins uninstall <id>
openclaw gateway restart

이 명령들은 안정적인 부분입니다. 흥미로운 부분은 그 주변의 안전 장치입니다. OpenClaw 는 플러그인 설치에 고정된 버전을 권장하고, npm 종속 설치에 --ignore-scripts 를 사용하며, 아카이브 설치 전에 pluginApi 와 minGatewayVersion 과 같은 호환성 메타데이터를 검증하고, --dangerously-force-unsafe-install 이라는 이름의 유리 깨기 오버라이드가 있는 내장 위험 코드 스캐너를 제공합니다. 이는 현재 많은 에이전트 생태계가 제공하는 것보다 더 심각한 보안 태세입니다.

하나의 미묘한 세부 사항을 지적할 가치가 있습니다. ClawHub 설치 수는 유용하지만 절대적인 생태계 인구 조사 숫자는 아닙니다. 문서에 따르면 설치 수는 로그인한 사용자가 clawhub sync 를 실행할 때 계산되며, 구식 루트는 120 일 후에 계산을 중단합니다. 이는 ClawHub 사용량 카운터를 방향적으로 유용하게 만들며, 특히 순위 매기기에 유용하지만, 실제 채택의 보편적 측정은 아닙니다.

성숙도, 지원, 보안 현실

성숙도 이야기는 둘로 나뉩니다. 1 차 번들 플러그인이 가장 안전한 기본값입니다. 그들은 메인 OpenClaw 릴리스 열 안에 거주하며, 동일한 호환성 모델을 공유하고, 매우 큰 공개 코어 레포지토리 footprint 에서 혜택을 받습니다. 크롤 시간에서 메인 openclaw/openclaw 레포지터리는 약 35 만 개의 GitHub 스타를 보여주었으며, 이는 이 생태계 어디서나 가장 강력한 공개 인기도 신호입니다. 커뮤니티 플러그인은 절대적으로 유용할 수 있지만, 모두 평등하지 않으며 자동으로 그 성숙도를 물려받지 않습니다.

OpenClaw 의 자체 커뮤니티 플러그인 페이지는 품질 기준에 대해 상쾌하게 단호합니다. 프로젝트는 공개 GitHub 레포지터리, openclaw plugins install 을 통한 작동 설치, 설정 및 사용 문서, 그리고 활성 유지 관리를 요구합니다. 노력 적은 래퍼, 불명확한 소유권, 또는 유지되지 않는 패키지는 거절될 수 있습니다. 이는 팀이 이미 생태계 실패를 본 곳임을 많이 알려줍니다.

보안은 의견이 허세를 대체해야 하는 부분입니다. 문서 자체는 OpenClaw 플러그인 설치를 코드 실행처럼 취급하라고 말합니다. ClawHub 는 중재 후크, 스타, 댓글, 그리고 사용 신호를 노출하며, 더 넓은 OpenClaw 보안 대응은 더 강력한 패키지 감시로 이동했습니다. 팀은 모든 ClawHub 스킬에 대한 VirusTotal 스캔을 발표했으며, 독립 보안 연구는 2026 년 초에 악의적인 ClawHub 캠페인과 대규모 보안되지 않은 자격 증명 처리를 문서화했습니다. 이러한 사고는 OpenClaw 스킬과 스킬 스타일 목록에 집중되었지만 모든 네이티브 플러그인 경로는 아니었음에도 불구하고, 전체 설치 가능한 생태계를 평가하는 올바른 배경입니다. 교훈은 간단합니다: 확장 주변 — 설정, OpenClaw 확장 디렉터리, 그리고 레지스트리에서 설치하는 모든 것 — 은 이제 공격 표면의 일부가 되었습니다.

두 번째, 더 미묘한 보안 포인트는 더 안전한 생태계조차도 오탐을 생성한다는 것입니다. OpenClaw 의 위험 코드 스캐너는 휴리스틱이며, 공개 플러그인 유지 관리자는 이미 스캐너 경고와 설치 마찰에 대응해야 했습니다. 이는 스캐너가 존재해서는 안 된다는 표시가 아닙니다. 이는 “스캐너 클린"과 “안전"이 동일한 개념이 아니며, 비자명한 플러그인의 경우 인간 검토가 여전히 중요하다는 표시입니다.

현재 추적할 가치가 있는 유용한 플러그인

다음은 최대 목록이 아닌 실용적인 목록입니다. 독립적인 레포지터리가 없는 번들 1 차 플러그인의 경우, 아래 인기도 지표는 OpenClaw 코어 레포지터리 스타 수를 프록시로 사용합니다. 커뮤니티 플러그인의 경우, 인기도 지표는 크롤 시간에서 보이는 정석 공개 GitHub 레포지터리 스타 수를 사용합니다.

도구 및 웹 접근

• browser
  URL: https://docs.openclaw.ai/tools/browser
  이는 에이전트에게 관리되는 격리된 브라우저 프로파일과 로그인한 인간 세션이 중요한 경우 사용자 브라우저에 연결되는 모드를 제공하기 때문에 기본 심각한 도구 플러그인입니다. 이는 또 다른 일반적인 웹 검색 래퍼보다 더 유용합니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

• firecrawl
  URL: https://docs.openclaw.ai/tools/firecrawl
  Firecrawl 은 web_search 제공자 역할을 할 수 있고, 명시적인 firecrawl_search 와 firecrawl_scrape 도구를 노출하며, JS 가 많거나 반봇 페이지에 대해 web_fetch 폴백으로 작동할 수 있기 때문에 유용합니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

• tavily
  URL: https://docs.openclaw.ai/tools/tavily
  Tavily 는 검색과 추출을 모두 노출하고 LLM 소비를 위해 명시적으로 최적화되어 있기 때문에 여전히 가장 깔끔한 구조화된 검색 옵션 중 하나입니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

• exa
  URL: https://docs.openclaw.ai/tools/exa-search
  Exa 는 하이브리드 검색 모드와 추출을 하나의 제공자에서 원할 때 가장 적합하며, 즉시 브라우저 자동화로 넘어가지 않습니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

통합 및 협업

• matrix
  URL: https://docs.openclaw.ai/channels/matrix
  Matrix 는 이미 DM, 방, 스레드, 미디어, 반응, 투표, 위치, 그리고 matrix-js-sdk 를 통한 E2EE 를 지원하기 때문에 더 완전한 번들 협업 플러그인 중 하나입니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

• msteams
  URL: https://docs.openclaw.ai/channels/msteams
  Teams 는 Azure Bot 설정, 테넌트 자격 증명, 기본 웹후크 형태, 그리고 그룹 채팅 정책 제어를 포함하는 몇 안 되는 실제 1 차 경로를 가진 기업 채널 중 하나이기 때문에 중요합니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

• wecom
  URL: https://github.com/WecomTeam/wecom-openclaw-plugin
  WeCom 은 Tencent WeCom 팀에서 공식적으로 유지 관리하고 직접 메시지, 그룹 채팅, 스트리밍 응답, 능동적 메시징, 그리고 Bot 및 Agent 운영 모드를 모두 지원하기 때문에 더 강력한 커뮤니티 채널 플러그인 중 하나입니다. 인기도: 약 365 개의 GitHub 스타.

• openclaw-discourse
  URL: https://github.com/pranciskus/discourse-openclaw
  Discourse 는 작지만 유용한 플러그인의 좋은 예입니다. 검색, 읽기, 필터링, 미답변 주제 찾기, 그리고 선택적으로 포럼으로 다시 작성에 집중하며, 이는 지원 및 커뮤니티 워크플로우가 정확히 필요한 것입니다. 인기도: 약 10 개의 GitHub 스타.

여기에서 한 가지 부연 설명은 Slack 이 많은 사람들이 기대하는 것보다 플러그인 기사에서 덜 흥미롭다는 것입니다. Slack 은 이미 현재 OpenClaw 문서와 마케팅 자료에서 내장 채널 표면으로 취급되기 때문입니다. Teams 와 WeCom 은 외부 또는 번들 채널 소유권이 여전히 눈에 띄게 중요한 곳을 보여주기 때문에 더 공개적인 플러그인 선택입니다.

메모리 및 컨텍스트

• memory-lancedb
  URL: https://docs.openclaw.ai/tools/plugin
  이는 번들 세트에서 실용적인 장기 세션 메모리 선택입니다. OpenClaw 는 이를 plugins.slots.memory 를 통해 선택되는 자동 회상 및 캡처 기능을 갖춘 설치 온디맨드 장기 메모리 플러그인으로 설명합니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

• memory-wiki
  URL: https://docs.openclaw.ai/plugins/memory-wiki
memory-wiki 는 교체 메모리 백엔드가 아닙니다. 이는 내레이티브, 모순, 대시보드, 그리고 위키 네이티브 검색 및 적용 도구를 갖춘 탐색 가능한 위키로 내구성 있는 메모리를 컴파일하는 동반 플러그인입니다. 이는 원시 회상보다 지식 유지에 더 유용하게 만듭니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

• lossless-claw
  URL: https://github.com/Martian-Engineering/lossless-claw
  이는 현재 아마도 가장 중요한 커뮤니티 메모리 컨텍스트 플러그인일 것입니다. 이는 슬라이딩 윈도우 압축을 DAG 기반 요약으로 대체하여 토큰 제한 내에서 활성 컨텍스트를 유지하면서 전체 대화 기록을 보존합니다. 인기도: 약 4,300 개의 GitHub 스타.

• memos-cloud
  URL: https://github.com/MemTensor/MemOS-Cloud-OpenClaw-Plugin
  MemOS Cloud 는 메모리를 생명주기 플러그인으로 취급하여 실행 전에 컨텍스트를 회상하고 각 실행 후 결과를 저장하기 때문에 주목할 만합니다. 이는 메모 저장소보다 영구 메모리 인프라에 더 가깝게 만듭니다. 인기도: 약 339 개의 GitHub 스타.

모델 제공자 및 하니스

• openai
  URL: https://docs.openclaw.ai/providers/openai
  OpenAI 제공자는 OpenClaw 가 openai/* 를 통한 직접 API 접근을 ChatGPT 또는 Codex OAuth 인 openai-codex/* 와 분리하여 청구 및 런타임 경로에 대한 많은 혼란을 피하기 때문에 여전히 유용합니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

• anthropic
  URL: https://docs.openclaw.ai/providers/anthropic
  Anthropic 은 OpenClaw 가 API 키와 Claude CLI 재사용을 모두 지원하면서도 API 키를 가장 명확한 장기 게이트웨이 경로로 문서화하기 때문에 유용합니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

• onpenrouter
  URL: https://docs.openclaw.ai/providers/openrouter
  OpenRouter 는 실용적인 집계 플러그인입니다. 여러 모델에 대해 단일 엔드포인트와 API 키를 제공하며, openrouter/auto 로 기본 온보딩하여 가장 의견이 명확한 경로는 아니더라도 운영상 편리하게 만듭니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

• google
  URL: https://docs.openclaw.ai/providers/google
  Google 은 OpenClaw 에서 또 다른 텍스트 제공자 이상입니다. 플러그인은 Gemini Grounding 을 통한 이미지 생성, 미디어 이해, 그리고 웹 검색을 가져옵니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

• codex
  URL: https://docs.openclaw.ai/plugins/codex-harness
  번들 Codex 하니스는 Codex 앱 서버가 저수준 세션, 스레드 재개, 압축, 그리고 실행 경로를 소유하도록 하고 싶을 때 유용하며, OpenClaw 는 여전히 채널과 가시적인_TRANSCRIPT 를 소유합니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

개발 워크플로우 및 관찰성

• openclaw-codex-app-server
  URL: https://github.com/pwrdrvr/openclaw-codex-app-server
  이는 가장 명확한 커뮤니티 개발 워크플로우 승리 중 하나입니다. 이는 채팅을 Codex App Server 스레드에 바인딩하고 재개, 계획, 검토, 모델 선택, 그리고 압축을 위한 채팅 네이티브 제어를 노출합니다. 인기도: 약 193 개의 GitHub 스타.

• @opik/opik-openclaw
  URL: https://github.com/comet-ml/opik-openclaw
  Opik 은 깔끔한 관찰성 플러그인 선택입니다. 이는 LLM 스패닝, 도구 스패닝, 서브 에이전트 스패닝, 사용량, 그리고 비용 메타데이터를 Opik 으로 내보내며, 가시적인 릴리스 주기와 공개 문서를 가지고 있습니다. 인기도: 약 453~459 개의 GitHub 스타.

• manifest
  URL: https://github.com/mnfst/manifest/tree/main/packages/openclaw-plugin
  Manifest 는 모델 라우팅과 관찰성을 하나의 플러그인으로 결합하여 요청을 점수 매기고 라우팅하는 동안 비용과 타이밍을 기록하기 때문에 중요합니다. 이는 생태계에서 더 큰 공개 프로젝트 중 하나이지만, 스캐너 경고와 온보딩 잡음에 대한 공개적 마찰도 있었습니다. 인기도: 약 4,300 개의 GitHub 스타.

음성 에이전트 및 다단계 워크플로우

• voice-call
  URL: https://docs.openclaw.ai/plugins/voice-call
  이는 화려한 것이 아니라 유용한 음성 플러그인입니다. 이는 아웃바운드 통화, 다턴 대화, 인바운드 통화 정책, 그리고 Twilio, Telnyx, Plivo 및 모크 전송을 포함한 현재 제공자를 지원합니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

• webhooks
  URL: https://docs.openclaw.ai/plugins/webhooks
  Webhooks 플러그인은 Zapier, n8n, CI 작업, 또는 내부 서비스와 같은 신뢰할 수 있는 시스템이 인증된 HTTP 경로를 통해 TaskFlows 를 생성하고 구동할 수 있게 해주기 때문에 가장 과소평가된 워크플로우 플러그인입니다. 이는 AI 오케스트레이션 마케팅보다 훨씬 덜 화려하지만, 팀이 실제로 작업을 자동화하는 방식에 훨씬 더 가깝습니다. 인기도: 번들 1 차 플러그인, 프록시 지표 35 만 개 코어 레포지터리 스타.

리드 생성, CRM, 그리고 이메일-캘린더 자동화

이는 억제력이 건강한 생태계의 부분입니다. 검증할 수 있는 공개 패키지와 레포지터리 기반에서, OpenClaw 는 Google Workspace 와 Google Calendar 에 대해 유망한 네이티브 플러그인 실험을 가지고 있으며, 더 넓은 생태계에서 초기 CRM 지향 패키지가 있지만, 공개 인기도 신호는 여전히 매우 작습니다. tensorfold/openclaw-google-workspace 는 Gmail, Calendar, Drive, Contacts, Tasks, 그리고 Sheets 를 포함한 일체형 플러그인을 제시했지만 0 개의 GitHub 스타를 보였습니다. alefsolutions/openclaw-google-calendar 도 0 개의 GitHub 스타를 보였습니다. crm-skills-openclaw 는 HubSpot 과 Salesforce 방향으로 공개적으로 존재했지만, 성숙한 네이티브 플러그인이 아닌 스킬 지향적인 레포지터리였으며 약 1 개의 GitHub 스타를 보였습니다. 이는 이러한 프로젝트가 쓸모없다는 것을 의미하지 않습니다. 이는 그들이 초기 단계임을 의미합니다.

또한 흥미로운 소셜 및 성장 플러그인 방향이 있습니다. SendIt 는 OpenClaw 플러그인과 번들 스킬 팩을 통해 게시, 분석, 캠페인, 인박스, CRM, 그리고 워크플로우 도구를 노출합니다. 공개적으로는, 레포지터리가 크롤 시간에서 여전히 0 개의 GitHub 스타를 보였습니다. 정직한 해석은 이 카테고리는 유망하지만 성숙하다고 부르기에는 아직 충분히 인기가 없다는 것입니다.

따라서 리드 생성과 비즈니스 자동화에 대한 실용적인 결론은 약간 비낭만적입니다. OpenClaw 의 가장 강력한 플러그인 네이티브 승리는 여전히 웹 접근, 메모리, 라우팅, 채널, 음성, 그리고 관찰성입니다. CRM 중심 또는 인박스 중심 워크플로우에 대해, 실제 경로는 여전히 Webhooks, 제공자 또는 브라우저 플러그인, 그리고 스킬 또는 API 브리지의 혼합이며 하나의 우세한 플러그인 패키지가 아닙니다. 그 패턴은 공개 생태계 자체에서 가시적이며, OpenClaw 프로덕션 설정 가이드 에 설명된 플러그인과 스택 스택으로 직접 매핑됩니다.

결론

현재 유용한 OpenClaw 플러그인 생태계는 신기함보다 운영적 레버리지에 더 관련이 있습니다. 지루한 선택들이 여전히 올바른 선택입니다: browser, firecrawl, tavily, memory-lancedb, memory-wiki, voice-call, webhooks, 그리고 OpenAI, Anthropic, Google, OpenRouter, 그리고 Codex 를 위한 번들 제공자 플러그인입니다. 커뮤니티 측면에서, lossless-claw, @opik/opik-openclaw, openclaw-codex-app-server, manifest, 그리고 wecom 은 가시적인 유틸리티와 공개적 견인을 가진 가장 명확한 공개 패키지입니다.

나중에 동일한 레지스트리에서 OpenClaw 스킬을 평가할 때, 플러그인과 동일한 위생 (버전 고정, 매니페스트 읽기, 스캔을 방향적으로 취급) 을 사용하십시오. 역할별 스택과 보안 체크리스트를 위해 OpenClaw 스킬 가이드 를 참조하십시오. 확장 디렉터리에 대해, 워크스페이스 플러그인 루트를 의도적으로 유지하고 디스크의 모든 경로를 신뢰할 수 없을 때 허용 목록을 사용하십시오.

의견이 명확한 해석은 이것입니다. OpenClaw 는 이미 심각한 네이티브 플러그인 플랫폼을 가지고 있으며, 확장 디렉터리는 그 코드를 단정할 예측 가능한 장소를 제공합니다. 스킬은 항상 전체 플러그인 권한으로 실행되는 것을 넓히지 않고 게시할 수 있는 것을 넓힙니다. 지금 신뢰할 가치가 있는 부분은 여전히 비즈니스 오퍼레이션 데모의 긴 꼬리가 아닌 네이티브 플러그인을 위한 런타임 배관 레이어입니다. 이상적인 것이 아니라 유용한 기준을 원한다면, 그것이 지킬 선입니다.

이 플러그인 선택이 실제 사용자 유형과 프로덕션 워크플로우에 어떻게 매핑되는지 보려면 OpenClaw 프로덕션 설정 패턴 을 참조하십시오.