책에 포함된 노트오픈클로 OpenClaw: 메신저 안에서 일하는 나만의 AI 에이전트

4부·15장 ClawHub과 커뮤니티 스킬 활용

2026-04-29Views 9약 8분생성형 AI 활용

4부·15장 ClawHub과 커뮤니티 스킬 활용

스킬을 고르는 순간, 에이전트의 직무가 바뀐다

OpenClaw를 처음 켜면 똑똑한 대화 상대처럼 느껴진다. 그런데 스킬을 붙이기 시작하면 분위기가 달라진다. 그때부터는 "답변하는 AI"가 아니라 "특정 일을 해내는 AI"가 된다. 메일을 읽고, 캘린더를 정리하고, 깃허브를 훑고, 노션에 결과를 남기는 식이다. 결국 OpenClaw의 실전 생산성은 모델 성능만이 아니라 어떤 스킬 묶음을 선택했는가에 크게 좌우된다.

ClawHub는 바로 그 스킬을 찾고, 설치하고, 업데이트하고, 공개하는 공개 레지스트리다. 단순한 파일 창고가 아니라 버전 기록, 태그, 검색, 사용 신호를 함께 제공하는 스킬 시장에 가깝다. 검색도 단순 키워드만이 아니라 임베딩 기반으로 동작하고, 각 스킬은 semver 버전과 변경 이력을 남길 수 있다.¹

여기서 중요한 사실이 하나 있다. 좋은 스킬은 시간을 벌어 주고, 나쁜 스킬은 시간을 잡아먹는다. 더 무서운 건, 악성 스킬은 시간을 넘어 비밀번호와 토큰, 작업물까지 건드릴 수 있다는 점이다. 그래서 이 장의 핵심은 "많이 설치하는 법"이 아니라 "제대로 고르는 법"이다.

`openclaw`와 `clawhub`는 역할이 다르다

초보자가 가장 먼저 헷갈리는 지점이 이것이다. 스킬을 다루는 명령이 둘처럼 보이기 때문이다. 사실은 역할 분담이 분명하다.

일상적인 검색, 설치, 업데이트는 보통 openclaw 기본 명령으로 충분하다. 이 방식은 현재 활성 워크스페이스에 스킬을 설치하고, 나중에 업데이트할 때도 출처 메타데이터를 유지한다.¹ 반면 clawhub CLI는 로그인, 게시, 동기화처럼 레지스트리 인증이 필요한 작업에 더 적합하다.¹

가장 자주 쓰는 흐름은 아래 정도면 충분하다.

openclaw skills search "calendar"
openclaw skills install <skill-slug>
openclaw skills update --all

직접 만든 스킬을 올리거나 여러 개를 한꺼번에 동기화하고 싶다면 그때 clawhub를 설치한다.

npm i -g clawhub
clawhub login
clawhub search "notion"
clawhub install <skill-slug>
clawhub sync --all

설치 위치도 감각적으로 알아두면 좋다. OpenClaw는 스킬을 여러 곳에서 읽지만, 우선순위는 워크스페이스 스킬이 가장 높다. 즉, 같은 이름의 스킬이 번들에 있어도 내 워크스페이스에 같은 이름으로 넣어두면 내가 넣은 버전이 이긴다. 그리고 스킬 변경 사항은 보통 새 세션에서 반영된다.²

이걸 한 문장으로 줄이면 이렇다. 평소에는 openclaw, 배포할 때는 clawhub. 이 구분만 머리에 들어오면 스킬 관리가 갑자기 단순해진다.

탐색은 "도구 이름"이 아니라 "업무 문장"으로 시작하자

ClawHub를 잘 쓰는 사람은 검색창에 제품명을 먼저 넣지 않는다. 먼저 자기 일을 문장으로 쓴다. 예를 들면 이런 식이다.

"아침마다 Gmail과 Calendar를 묶어서 브리핑해 주는 스킬이 필요하다"
"텔레그램으로 받은 할 일을 Trello와 Notion에 정리하고 싶다"
"깃허브 PR과 이슈를 요약해 슬랙에 보내고 싶다"

이런 요구를 영어 제품명으로 번역하려 애쓰기보다, 먼저 넓게 검색한 뒤 점점 좁히는 편이 낫다. ClawHub는 자연어 검색을 지원하므로, 처음에는 문제 중심 검색이 잘 먹힌다.¹

실전 흐름은 보통 이렇다.

가장 큰 업무 단위를 검색한다. 예를 들어 calendar, gmail, notion, github처럼 넓게 시작한다.
검색 결과에서 설명을 읽고, 어떤 외부 서비스와 연결되는지 확인한다.
설치 전에는 반드시 SKILL.md와 요구 조건을 읽는다.
비슷한 스킬이 많으면 "누가 만들었는지, 얼마나 관리되는지, 어떤 조합에 잘 맞는지"를 비교한다.

무엇을 검색해야 할지 막막하다면 커뮤니티 큐레이션 목록을 먼저 훑는 것도 좋다. awesome-openclaw-skills 같은 저장소는 깃허브, 생산성, 커뮤니케이션, 캘린더, 노트, 검색 같은 카테고리별로 스킬을 묶어 보여 준다.³ 마트에 들어가서 배고픈 상태로 아무거나 집는 대신, 진열대 지도를 먼저 보는 셈이다.

설치한 뒤에는 10분만 검증하자

많은 사람이 여기서 실수한다. 스킬을 설치하고 끝낸다. 하지만 설치는 시작일 뿐이다. 제대로 된 흐름은 설치 → 새 세션 시작 → 가장 작은 실제 작업으로 검증이다.

예를 들어 노션 스킬을 설치했다면, 첫 요청은 거창할 필요가 없다. "노션에 테스트 페이지 하나 만들어 줘" 정도면 충분하다. 깃허브 스킬이라면 "내 오픈 PR 세 개만 요약해 줘", 캘린더 스킬이라면 "오늘 일정만 불러와 줘" 같은 식으로 아주 짧고 분명한 명령을 던진다.

이때 반드시 확인할 것이 있다. 스킬이 정말 로드되었는가 하는 점이다. OpenClaw는 스킬을 읽을 때 환경 변수, 바이너리 존재 여부, 설정 값 등을 보고 로드 가능 여부를 걸러낸다. 예를 들어 어떤 스킬이 GEMINI_API_KEY나 gh CLI를 요구하는데 내 환경에 없으면, 설치는 되어 있어도 실제 세션에는 안 보일 수 있다.²

즉, "설치는 성공했는데 왜 못 쓰지?"라는 질문의 절반은 보통 이 세 가지 중 하나다.

필요한 API 키가 없다
필요한 CLI 도구가 PATH에 없다
새 세션을 다시 열지 않았다

스킬 문제처럼 보여도 사실은 환경 문제인 경우가 많다. 그러니 첫 검증은 늘 작게, 빠르게, 눈에 보이게 해야 한다.

좋은 스킬을 고르는 7가지 기준

좋은 스킬을 고르는 눈은 생산성과 보안을 동시에 좌우한다. 아래 기준은 가볍게 보여도 꽤 강력하다.

설명과 요구 권한이 맞아야 한다. 캘린더 스킬이라면 캘린더 접근 정도가 자연스럽다. 그런데 갑자기 광범위한 셸 실행이나 불필요한 파일 접근을 요구한다면 한 번 더 의심해야 한다.⁴
외부로 나가는 통신 대상이 납득 가능해야 한다. 날씨 스킬이 날씨 API와 통신하는 것은 자연스럽다. 하지만 메모 정리 스킬이 생소한 도메인으로 데이터를 보내려 한다면 신호가 좋지 않다.⁴
자격 증명 처리 방식이 깔끔해야 한다. API 키를 하드코딩하거나 로그에 남기거나, 프롬프트 안에 직접 넣으라고 유도하는 스킬은 피하는 편이 좋다. 공식 문서도 서드파티 스킬은 신뢰하지 않은 코드처럼 다루라고 권한다.²
유지보수 신호가 보여야 한다. 최근 업데이트가 있는지, 버전이 정리돼 있는지, 변경 로그가 읽히는지 보자. 오래 방치된 스킬은 기능보다 운영이 더 불안하다.¹
작성자와 사용 신호를 본다. 별점, 다운로드 수, 댓글은 완벽한 기준은 아니지만 무시할 수도 없다. 전혀 알려지지 않은 작성자의 스킬이라면 더 꼼꼼히 읽어야 한다.¹
소스가 짧아도 수상한 흔적은 찾을 수 있다. base64로 감춘 명령, 낯선 URL, 하드코딩된 웹훅, 뜬금없는 실행 파일 다운로드, 워크스페이스 밖 파일 쓰기 같은 흔적은 강한 경고 신호다.⁴⁵
처음에는 격리된 환경에서 시험한다. 메인 노트북에 바로 넣지 말고, 테스트 워크스페이스나 Docker, 별도 VPS 같은 안전한 환경에서 먼저 돌려 본다.⁵

이 일곱 가지를 모두 암기할 필요는 없다. 딱 한 줄만 기억해도 된다. 스킬은 기능이 아니라 신뢰를 설치하는 행위다.

바로 써먹는 추천 조합

스킬은 하나씩도 좋지만, 실제로는 조합에서 힘이 나온다. 혼자 일하는 사람에게 특히 잘 맞는 조합 몇 가지를 소개하겠다.

운영 자동화 조합: Google Workspace + Notion + GitHub

이 조합은 솔로 창업가에게 거의 기본 세트다. Gmail과 Calendar로 입력을 받고, Notion에 결과를 남기고, GitHub로 제품 개발 상태를 추적한다. 아침에는 메일과 일정 브리핑을 받고, 낮에는 PR과 이슈를 요약받고, 밤에는 하루 결과를 노션 데이터베이스에 남기면 된다.

협업 정리 조합: Slack + Trello + Notion

PM이나 마케터에게 잘 맞는다. Slack에서 들어온 요청을 읽고, Trello 카드로 정리하고, 최종 문서나 회의 요약은 Notion에 쌓는다. 사람은 맥락 판단만 하고, 에이전트는 복붙과 정리 노동을 맡는다.

일정 중심 조합: CalDAV + Calendar + 알림 스킬

구글 생태계 밖에서 일하거나 여러 캘린더를 함께 쓰는 사용자에게 유용하다. CalDAV 계열 스킬은 일정 동기화에 강하고, 여기에 아침 브리핑이나 리마인더 스킬을 얹으면 "오늘 뭐 하지?"라는 질문이 크게 줄어든다.

개발자 실행 조합: GitHub + 검색/리서치 + 요약 스킬

개발자는 늘 코드만 보는 것 같지만 실제 시간은 맥락 수집에 많이 쓴다. 깃허브 상태, 관련 문서 검색, 긴 이슈와 PR 요약을 엮어 두면 텔레그램에서 한 줄 지시만 내려도 꽤 많은 정리 작업이 돌아간다.

처음부터 열 개를 깔 필요는 없다. 정말 잘 맞는 세 개만 골라도 체감이 크다. 휴대폰 홈 화면에 앱이 200개 있다고 삶이 바뀌지 않는 것과 같다. 자주 여는 앱 세 개가 더 중요하다.

내가 만든 스킬을 ClawHub에 올리는 법

커뮤니티 스킬을 쓰다 보면 언젠가 이런 순간이 온다. "이건 아무도 안 만들었네. 내가 만드는 게 더 빠르겠다." 바로 그때가 게시를 배울 타이밍이다.

ClawHub에 스킬을 올리려면 보통 clawhub CLI가 필요하다. 흐름은 어렵지 않다.

npm i -g clawhub
clawhub login
clawhub skill publish ./my-skill \
  --slug my-skill \
  --name "My Skill" \
  --version 1.0.0 \
  --tags latest

여기서 중요한 것은 세 가지다. 첫째, slug는 설치할 때 쓰는 이름이니 짧고 분명해야 한다. 둘째, 버전은 semver를 따르는 편이 좋다. 셋째, 다른 사람이 검색했을 때 한 줄 설명만 보고도 용도를 이해할 수 있어야 한다.¹

스킬이 여러 개라면 clawhub sync --all이 편하다. 로컬 스킬 폴더를 스캔해서 새 스킬이나 업데이트된 스킬을 한꺼번에 게시할 수 있다.¹ 혼자 쓰는 사람에게도 이 명령은 꽤 유용하다. 공개 배포 수단인 동시에, 내 스킬 묶음을 버전 있는 백업처럼 관리할 수 있기 때문이다.

또 하나 기억할 점이 있다. ClawHub는 기본적으로 공개 레지스트리다. 게시하려면 깃허브 계정이 최소 일주일 이상 되어 있어야 하며, 게시할 때마다 새 버전이 만들어지고 버전 이력이 남는다.¹ 즉, 올리는 순간부터 그 스킬은 "내 로컬 파일"이 아니라 "감사 가능한 배포물"이 된다. 그래서 더더욱 설명과 변경 로그를 성실히 적어야 한다.

업데이트는 무조건 최신으로,가 아니라 읽고 나서

update --all은 편하다. 너무 편해서 문제다. 스킬은 앱스토어 앱이 아니라 에이전트의 행동 방식을 바꾸는 지시문이기도 하다. 그러니 업데이트는 기능 추가가 아니라 운영 변경으로 보는 편이 맞다.

실무 감각으로는 이렇게 접근하면 안전하다.

업무 핵심 스킬은 변경 로그를 먼저 읽고 올린다.
직접 수정한 로컬 스킬은 덮어쓰기 전에 차이를 확인한다.
중요한 자동화는 테스트 워크스페이스에서 먼저 돌려 본다.

ClawHub는 버전 기록과 태그를 유지하므로, 어떤 버전이 언제 올라왔는지 추적하기 쉽다.¹ 이 점이 그냥 GitHub 저장소를 복사해다 쓰는 방식보다 훨씬 낫다. "왜 어제 되던 게 오늘 안 되지?"라는 질문 앞에서, 버전 이력은 거의 타임머신 역할을 한다.

가장 흔한 함정 네 가지

마지막으로, 실제 사용자들이 자주 빠지는 함정을 정리해 보자.

첫째, 스킬 수집이 목표가 되는 경우다. 많이 설치해도 모델이 더 똑똑해지는 것은 아니다. 오히려 비슷한 역할의 스킬이 너무 많으면 어떤 것을 써야 할지 망설이며 응답이 흐려질 수 있다.

둘째, 중복 역할 스킬을 한꺼번에 넣는 경우다. 예를 들어 비슷한 웹 검색 스킬이 세 개 있으면 사람은 선택지를 얻었다고 느끼지만, 에이전트는 지시문이 늘어났다고 느낄 수 있다. 먼저 하나만 고정하고, 부족할 때만 교체하자.

셋째, 환경 요구 사항을 안 읽는 경우다. requires.env, requires.bins, requires.config 같은 항목은 장식이 아니다. 이것을 읽지 않으면 설치 성공 뒤에 곧바로 "왜 작동 안 해?"라는 벽을 만난다.²

넷째, 처음 보는 스킬을 일상용 머신에서 바로 돌리는 경우다. 이건 가장 비싼 실수다. 테스트 환경에서 먼저 돌리고, 로그를 보고, 이상한 네트워크 호출이 없는지 확인한 뒤 메인 워크플로에 넣어야 한다.⁴⁵

좋은 스킬을 찾는 감각은 결국 좋은 직원을 뽑는 감각과 닮아 있다. 이력서는 번듯한데 권한을 너무 많이 요구하면 불안하다. 말은 그럴듯한데 설명서가 엉성하면 유지보수가 걱정된다. 반대로 요구 사항이 분명하고, 역할이 명확하고, 작은 테스트에서 바로 가치를 보여 주는 스킬은 오래 간다.

ClawHub를 잘 쓰는 사람은 스킬을 "깔아 본다"고 말하지 않는다. 워크플로를 설계한다고 말한다. 그 차이가 결국, 메신저 안의 AI를 장난감에서 디지털 분신으로 바꾸는 지점이다.