OpenClaw 튜토리얼 6편: Plugins, Hooks, Webhooks, Automation은 어떻게 확장되는가

개요

OpenClaw의 재미는 기본 기능만이 아니라 확장 구조에 있습니다.

공식 문서를 보면 OpenClaw는,

• plugins
• hooks
• webhooks
• cron/automation

을 통해 assistant를 점점 플랫폼처럼 확장할 수 있게 설계돼 있습니다.

이 문서는 그 구조를 운영 관점에서 정리합니다.

---

1. Plugin은 무엇을 의미하나

공식 plugins CLI 문서 기준 plugin은 Gateway에 in-process로 로드되는 extension입니다.

결국 plugin은 단순 테마가 아니라,

• 채널 추가
• 기능 추가
• 자동화 추가
• hook 번들 추가

같은 확장을 가능하게 합니다.

중요한 포인트

OpenClaw는 plugin manifest와 schema를 요구하고,

유효하지 않으면 로딩을 막습니다.

결국 확장도 꽤 엄격하게 관리합니다.

---

2. Hooks는 이벤트 기반 자동화다

공식 hooks 문서 기준 hooks는 agent 명령과 lifecycle 이벤트에 반응하는 자동화 구조입니다.

대표 이벤트를 보면

• `command:new`
• `command:reset`
• `command:stop`
• `session:compact:before`
• `session:compact:after`
• `agent:bootstrap`
• `gateway:startup`
• `message:received`
• `message:transcribed`
• `message:preprocessed`
• `message:sent`

결국 hooks는 “무언가 일어났을 때 자동 실행되는 작은 로직”입니다.

---

3. Hook이 왜 중요한가

이 구조 덕분에 OpenClaw는 코어를 안 바꾸고도,

• `/new` 때 memory snapshot 저장
• message logging
• startup bootstrap
• compact 전후 처리
• inbound message 전처리

같은 걸 붙일 수 있습니다.

결국 hooks는 assistant 운영 중간중간에 들어가는 자동 반응 레이어입니다.

---

4. Webhook은 외부 시스템이 OpenClaw를 깨우는 입구다

공식 webhook 문서 기준 Gateway는 HTTP webhook endpoint를 노출할 수 있습니다.

대표 endpoint,

• `POST /hooks/wake`
• `POST /hooks/agent`
• `POST /hooks/<name>` mapped hook

결국 외부 시스템이,

• system event를 main session에 넣거나
• isolated agent turn을 실행하거나
• 특정 agent로 라우팅된 작업을 던질 수 있습니다.

---

5. Hooks와 Webhooks의 차이

이건 헷갈리기 쉬운데, 공식 문서도 분리해서 설명합니다.

Hooks

• Gateway 내부 이벤트에 반응
• 내부 lifecycle 자동화

Webhooks

• 외부 HTTP 요청으로 OpenClaw를 트리거
• 외부 시스템과 연결하는 ingress

결국:

• hooks = 안에서 반응
• webhooks = 밖에서 깨움

입니다.

---

6. 실제로 어떤 구조가 가능해지나

패턴 A. 메시지 전처리

message:preprocessed hook을 활용하면 media/link understanding 이후 본문을 다듬거나 로그를 남길 수 있습니다.

패턴 B. 세션 관리 자동화

session:compact:before / after에서 기록/메모리 정리를 붙일 수 있습니다.

패턴 C. startup bootstrap

gateway:startup 시점에 필요한 초기 작업을 자동화할 수 있습니다.

패턴 D. 외부 시스템 연동

webhook으로 Gmail, GitHub, 외부 감시 시스템 등과 연동 가능합니다.

---

7. 왜 plugin 생태계가 중요하나

공식 문서에서 community plugin listing 기준도 따로 있습니다.

이건 OpenClaw가 단순 내부 실험용이 아니라,

바깥 확장 생태계를 의식하고 있다는 신호입니다.

결국 장기적으로 보면,

• core gateway
• plugin channels
• plugin hooks
• external integrations

구조가 커질 여지가 있습니다.

---

8. Security 관점에서 꼭 봐야 할 점

plugin/hook/webhook은 확장성이 강한 대신 위험도도 커집니다.

plugin

• 실행 코드 설치와 비슷하게 취급해야 함
• pinned version 선호

hook

• 이벤트마다 자동 실행되므로 side effect를 신중히 설계해야 함

webhook

• hook token 필수
• trusted reverse proxy/loopback/tailnet 뒤 운영 권장
• explicit sessionKey 허용은 신중해야 함

결국 확장 구조가 강해질수록 운영 경계와 인증이 더 중요해집니다.

---

9. 초반에 추천하는 확장 순서

1단계

• bundled hook 확인
• command logger / session memory 같은 안전한 기본 hook부터

2단계

• 작은 custom hook 작성
• `/new`, `message:received` 같은 이벤트부터 테스트

3단계

• webhook ingress 연결
• 외부 시스템과 isolated agent turn 연동

4단계

• plugin 채널/커뮤니티 plugin 검토

이 순서가 안전합니다.

---

10. 콘텐츠 관점에서 이 주제가 왜 좋은가

OpenClaw를 설치형 assistant로만 보면 생각보다 빨리 진부해질 수 있어요.

하지만 plugin / hook / webhook 구조를 보면,

OpenClaw는 assistant를 운영하고 확장하는 플랫폼처럼 보입니다.

결국 이 주제는 이런 메시지로 풀기 좋습니다.

• OpenClaw는 기능이 많은 게 아니라 확장점이 설계된 시스템이다
• Hooks는 내부 반응 레이어, Webhooks는 외부 ingress다
• Plugins는 OpenClaw를 하나의 플랫폼처럼 키우는 구조다

---

결론

OpenClaw의 확장 구조를 이해하면,

이 프로젝트가 단순 AI assistant를 넘어서 운영 가능한 assistant platform에 가깝다는 점이 더 잘 보입니다.

결국 plugin, hook, webhook은 부가기능이 아니라,

• 기능 확장
• 이벤트 자동화
• 외부 시스템 연결

을 담당하는 핵심 축입니다.

---

출처

• Plugins CLI: `/app/docs/cli/plugins.md`
• Community plugins: `/app/docs/plugins/community.md`
• Hooks: `/app/docs/automation/hooks.md`
• Webhooks: `/app/docs/automation/webhook.md`
• Cron jobs: `/app/docs/automation/cron-jobs.md`