오픈클로를 설치하고 첫 대화까지 성공했다면, 이제 진짜 재미있는 단계가 남았다. 바로 스킬(Skill) 개발이다. 오픈클로의 기본 상태는 똑똑한 대화 상대에 가깝다. 질문하면 대답하고, 시키면 해준다. 그런데 스킬을 붙이는 순간, 성격이 완전히 달라진다. 매일 아침 9시에 이메일을 정리해서 텔레그램으로 보내주고, 특정 웹사이트의 가격 변동을 모니터링해서 조건에 맞으면 알림을 보내고, 깃허브 PR 상태를 주기적으로 점검해서 슬랙에 리포트를 올린다. 이 모든 게 스킬 하나로 가능하다.
나도 처음에는 “스킬이라면 뭔가 복잡한 플러그인 시스템이겠지”라고 생각했다. SDK를 설치하고, 빌드하고, 배포하고. 그런데 실제로 열어보니까 어이가 없을 정도로 단순했다. 폴더 하나 만들고, 마크다운 파일 하나 작성하면 끝이다. 컴파일도 없고, 런타임도 없다. 공식 깃허브 문서에서도 “SDK도 빌드 과정도 필요 없다. YAML 프론트매터와 마크다운 지시문이 전부다”라고 못 박고 있다.
그런데 이 단순함에 속으면 안 된다. 스킬의 진짜 위력은 크론잡, 하트비트, 브라우저 제어와 결합될 때 드러난다. 매일 아침 경쟁 블로그의 새 글을 크롤링해서 리포트를 텔레그램으로 받는다든지, 특정 웹사이트의 가격 변동을 실시간으로 감시한다든지. 이런 자동화가 마크다운 파일 몇 줄로 가능하다는 게 오픈클로 스킬의 핵심이다.
이 글에서는 스킬의 구조부터 직접 만드는 방법, 크론잡과 하트비트로 자동화하는 방법, 그리고 웹 크롤링 스킬까지 실전 위주로 다룬다. 깃허브 공식 문서와 커뮤니티 사례, 그리고 내가 직접 테스트해본 경험을 바탕으로 작성했다. 오픈클로 설치가 아직이라면 오픈클로 설치 방법 및 첫 대화 시작 방법을 먼저 읽고 오면 좋겠다.
오픈클로 스킬이란 정확히 뭔가
스킬의 정체를 한 문장으로 정리하면 이렇다. “AI 에이전트에게 특정 작업을 수행하는 방법을 가르치는 마크다운 설명서”다. 플러그인이나 확장 프로그램처럼 자체 실행 코드가 있는 게 아니다. 스킬은 에이전트에게 “이런 상황이 오면, 이 도구를 이렇게 써서, 이런 순서로 처리해라”라고 알려주는 플레이북에 가깝다.
기존 자동화 도구들과 비교하면 차이가 분명하다. Zapier나 IFTTT는 “이벤트가 발생하면 정해진 액션을 실행하는” 규칙 기반 자동화다. 반면 오픈클로 스킬은 LLM이 상황을 판단해서 유연하게 대응한다. “매출 보고서를 정리해줘”라고 지시하면, 스킬에 적힌 가이드라인을 참고하되, 실제 데이터의 형태나 예외 상황에 맞춰 에이전트가 스스로 판단한다. “if-this-then-that”이 아니라 “이 상황을 이해하고 적절히 대응해라”에 가까운 거다.
오픈클로가 스킬을 로드하는 구조도 알아두면 좋다. 스킬 폴더는 세 곳에서 읽어들이는데, 우선순위가 있다. 가장 높은 건 워크스페이스 안의 skills 폴더이고, 그다음이 ~/.openclaw/skills, 마지막이 번들 스킬이다. 같은 이름의 스킬이 여러 곳에 있으면 우선순위가 높은 쪽이 적용된다. 번들 스킬의 동작이 마음에 안 들면, 워크스페이스에 같은 이름으로 커스텀 버전을 넣어서 덮어쓸 수 있다는 뜻이다.
스킬이 시스템 프롬프트에 주입되는 비용도 무시할 수 없다. 공식 문서에 따르면 스킬 하나당 약 97자 + 이름과 설명의 길이만큼 시스템 프롬프트가 늘어난다. 스킬 20개를 활성화하면 토큰 소비가 꽤 올라간다. 불필요한 스킬은 비활성화해두는 습관이 API 비용 절감에 직결된다.
SKILL.md 파일 구조 뜯어보기
스킬의 전부는 SKILL.md라는 파일 하나에 담겨 있다. 이 파일은 YAML 프론트매터와 마크다운 본문으로 구성된다. 프론트매터에는 스킬의 메타데이터가 들어가고, 본문에는 에이전트가 따라야 할 구체적인 지시사항이 들어간다.
가장 기본적인 구조를 보자.
---
name: my-custom-skill
description: 사용자가 특정 웹사이트의 가격 변동을 확인해달라고 하면 이 스킬을 사용한다.
version: 1.0.0
---
# 가격 모니터링 스킬
## 사용 조건
사용자가 특정 URL의 가격 정보를 확인하거나 모니터링을 요청할 때 이 스킬을 사용한다.
## 실행 순서
1. 사용자에게 모니터링할 URL을 확인한다.
2. 브라우저 도구를 사용해 해당 페이지에 접속한다.
3. 가격 정보를 추출하고 이전 기록과 비교한다.
4. 변동 사항이 있으면 사용자에게 알린다.
## 규칙
- URL이 제공되지 않으면 반드시 먼저 물어본다.
- 가격 정보를 찾을 수 없는 경우 페이지 구조가 변경됐을 가능성을 안내한다.
- 이전 기록이 없는 첫 실행에서는 현재 가격만 저장하고 알림은 보내지 않는다.프론트매터에서 가장 중요한 항목은 description이다. 에이전트가 사용자의 요청을 받았을 때 어떤 스킬을 쓸지 결정하는 기준이 바로 이 설명문이다. 설명이 모호하면 엉뚱한 상황에서 스킬이 호출되거나, 정작 필요할 때 무시당한다. “웹사이트 관련 작업”처럼 넓게 쓰면 안 되고, “특정 웹사이트의 가격 변동을 확인해달라고 하면”처럼 구체적으로 써야 한다.
본문의 지시사항은 아주 리터럴하게 해석된다는 걸 명심해야 한다. LLM은 SKILL.md에 적힌 내용을 가이드라인으로 삼지만, 명시적으로 금지하지 않은 행동은 자의적으로 판단해서 실행할 수 있다. DataCamp의 한 튜토리얼에서 나온 사례가 인상적이었다. 이미지 생성 스킬에서 특정 모델만 쓰라고 했는데, Rules 섹션을 안 만들어뒀더니 에이전트가 해당 모델에서 에러가 나자 알아서 다른 모델로 전환해버렸다. 금지할 건 명확히 금지해야 한다.
커스텀 스킬 직접 만들어보기
이론은 충분하다. 실제로 만들어보자. 예제로는 “블로그 경쟁사 모니터링 스킬”을 만들어볼 건데, 특정 키워드로 구글 검색 결과를 크롤링해서 경쟁 블로그의 새 글을 체크하는 스킬이다. 오픈클로 크롤링 기능을 활용하는 실전 예제이기도 하다.
먼저 스킬 폴더를 만든다.
cd ~/.openclaw/workspace/skills
mkdir competitor-monitor
cd competitor-monitor
touch SKILL.mdSKILL.md를 열어서 아래 내용을 작성한다.
---
name: competitor-monitor
description: 사용자가 특정 키워드의 구글 검색 결과를 확인하거나, 경쟁 블로그의 새 글을 모니터링해달라고 요청할 때 사용한다. 웹 크롤링과 검색 결과 분석에 활용한다.
version: 1.0.0
metadata:
openclaw:
emoji: "🔍"
---
# 경쟁 블로그 모니터링 스킬
## 사용 조건
사용자가 특정 키워드의 검색 순위를 확인하거나, 경쟁 블로그의 신규 콘텐츠를 파악해달라고 요청할 때 이 스킬을 활성화한다.
## 실행 순서
1. 사용자에게 모니터링할 키워드와 경쟁 도메인 목록을 확인한다.
2. 브라우저 도구로 구글 검색을 수행한다.
3. 검색 결과에서 경쟁 도메인의 페이지를 식별한다.
4. 각 페이지의 제목, URL, 게시일을 추출한다.
5. 이전 모니터링 결과와 비교하여 신규 콘텐츠를 식별한다.
6. 결과를 workspace/monitor-logs/ 디렉토리에 날짜별로 저장한다.
7. 변동 사항을 사용자에게 요약 보고한다.
## 출력 형식
키워드: [검색 키워드]
검색일: [날짜]
신규 발견 콘텐츠:
- [도메인] | [제목] | [URL] | [추정 게시일]
순위 변동:
- [도메인] | 이전 [N]위 → 현재 [M]위
## 규칙
- 검색 시 반드시 키워드만으로 검색한다. site: 연산자를 임의로 추가하지 않는다.
- 검색 결과는 상위 20개까지만 분석한다.
- 모니터링 로그는 반드시 JSON 형식으로 저장한다.
- 크롤링 간격은 최소 3초 이상 유지한다.
- 로봇 차단이 감지되면 즉시 중단하고 사용자에게 알린다.이 파일을 저장한 뒤, 에이전트에게 “스킬 새로고침 해줘” 또는 게이트웨이를 재시작하면 오픈클로가 새 스킬을 인식한다. 그다음 텔레그램이나 대시보드에서 “오픈클로 사용법 키워드로 구글 검색 결과 상위 10개 분석해줘”라고 보내면 스킬이 작동한다.
스킬 폴더 안에는 SKILL.md 외에도 보조 파일을 넣을 수 있다. scripts 폴더에 파이썬이나 배시 스크립트를 넣어두면 에이전트가 필요할 때 실행한다. references 폴더에는 참고 문서를 넣어둘 수 있다. 구조는 이런 식이다.
competitor-monitor/
├── SKILL.md
├── scripts/
│ └── parse_results.py
└── references/
└── target_domains.md다만 스크립트를 포함하는 스킬은 보안 리스크가 커진다. 에이전트가 셸 명령을 실행할 수 있는 상태라면, 스킬에 적힌 스크립트도 실행할 수 있다는 뜻이니까. 샌드박스 환경에서 먼저 테스트하는 습관을 들이는 게 좋다.
테스트할 때 유용한 명령이 하나 있다. 스킬을 수동으로 호출해서 동작을 확인하는 방법이다.
openclaw agent --message "competitor-monitor 스킬로 '오픈클로 설치' 키워드 검색 결과 분석해줘"이 명령으로 단일 메시지를 보내서 스킬이 정상적으로 트리거되는지, 지시사항대로 동작하는지를 빠르게 확인할 수 있다. 스킬이 트리거되지 않으면 description이 사용자 요청의 의도와 매칭되지 않는 거다. 이 경우 description 문구를 더 구체적으로 수정해야 한다. 한 가지 자주 겪는 문제가, 비슷한 description을 가진 스킬이 여러 개 있으면 에이전트가 엉뚱한 스킬을 선택하는 경우다. 스킬 간의 역할 구분을 명확히 하는 게 중요하다.
크론잡과 하트비트로 자동화 만들기
스킬을 만들었으면 이제 이걸 자동으로 돌리고 싶어진다. 매번 “경쟁사 블로그 확인해줘”라고 타이핑하는 건 비서에게 매번 전화 거는 것과 다를 바 없으니까. 오픈클로에는 크론(Cron)과 하트비트(Heartbeat)라는 두 가지 자동화 메커니즘이 있다. 이 둘의 차이를 명확히 이해하는 게 핵심이다.
하트비트는 에이전트의 메인 세션에서 주기적으로(기본 30분) 실행되는 점검 루틴이다. 워크스페이스의 HEARTBEAT.md 파일에 체크리스트를 적어두면, 에이전트가 매번 그 목록을 훑어보고 뭔가 주의할 게 있는지 판단한다. 특별한 일이 없으면 HEARTBEAT_OK를 반환하고 조용히 넘어간다. 여러 가지 점검을 한꺼번에 묶어서 처리하기에 좋고, 메인 세션의 맥락을 공유하기 때문에 이전 대화 내용을 기억하면서 판단할 수 있다.
크론은 정확한 시각이나 주기로 작업을 실행한다. 유닉스 크론탭과 같은 5필드 표현식을 지원하고, 타임존도 설정할 수 있다. 하트비트와 가장 큰 차이는 격리 세션(isolated session)으로 실행할 수 있다는 점이다. 격리 세션은 메인 대화를 오염시키지 않으면서 독립적으로 작업을 수행한다.
구분하는 기준은 간단하다. “정확한 시간에 실행돼야 하나?” 그렇다면 크론이다. “주기적으로 상태를 점검하면서, 특이사항이 있을 때만 알려주면 되나?” 그렇다면 하트비트다.
실전 예제로, 매일 오전 8시에 경쟁사 모니터링 결과를 텔레그램으로 받아보는 크론잡을 만들어보자.
openclaw cron add \
--name "competitor-check" \
--cron "0 8 * * *" \
--tz "Asia/Seoul" \
--session isolated \
--message "competitor-monitor 스킬을 사용해서 다음 키워드의 구글 검색 결과를 분석해줘: 오픈클로 사용법, 오픈클로 설치. 어제 결과와 비교해서 변동사항만 정리해줘." \
--announce \
--channel telegram주요 옵션을 하나씩 보면, –cron “0 8 * * *”는 매일 오전 8시를 의미한다. –tz “Asia/Seoul”로 한국 시간 기준임을 명시한다. –session isolated는 메인 세션과 분리해서 실행한다는 뜻이다. –announce는 결과를 채팅 채널로 전달하라는 지시이고, –channel telegram은 텔레그램으로 보내라는 거다.
크론잡이 제대로 등록됐는지 확인하려면 이렇게 입력한다.
openclaw cron list --verbose등록된 잡 목록과 다음 실행 시간, 상태가 표시된다. 바로 테스트해보고 싶다면 아래 명령으로 강제 실행할 수 있다.
openclaw cron update competitor-check --next-run now하트비트를 활용하는 방법도 보자. HEARTBEAT.md 파일에 경쟁사 모니터링 체크를 추가하면 된다.
# 하트비트 체크리스트
1. 메일함에 긴급 메일이 있는지 확인한다.
2. 캘린더에서 2시간 내 일정이 있는지 확인한다.
3. workspace/monitor-logs/ 폴더의 최신 로그를 확인해서 경쟁사 블로그에 새 글이 올라왔는지 체크한다.
4. 위 항목 중 주의가 필요한 게 없으면 HEARTBEAT_OK를 반환한다.한 가지 실전 팁을 더 주자면, 크론잡이 실행됐는데 메시지가 오지 않는 경우가 꽤 흔하다. 대부분 deliver 설정이 빠져있거나, 채널이 로그인되지 않은 상태라서 그렇다. openclaw logs –follow로 실시간 로그를 확인하면 원인을 금방 찾을 수 있다.
웹 크롤링 스킬 심화 – 실전 활용 패턴
오픈클로의 브라우저 제어 기능은 생각보다 강력하다. 전용 크롬 인스턴스를 띄워서 웹 페이지를 탐색하고, 스크린샷을 찍고, 폼을 작성하고, 데이터를 추출할 수 있다. 이걸 스킬과 결합하면 상당히 정교한 크롤링 워크플로우가 가능해진다.
실제로 커뮤니티에서 많이 쓰이는 패턴 세 가지를 정리했다.
첫 번째는 SEO 분석 자동화다. 매주 특정 키워드의 검색 순위를 체크하고, 상위 페이지의 메타 디스크립션과 헤딩 구조를 분석해서 리포트를 생성하는 스킬이다. 오픈클로 쇼케이스에서도 “매주 자동 SEO 분석을 돌리고 있다”는 사례가 올라온 바 있다. 특히 경쟁사의 콘텐츠 구조 변화를 추적하는 데 유용하다.
두 번째는 가격 모니터링이다. 쇼핑몰이나 마켓플레이스의 특정 상품 가격을 주기적으로 수집해서, 가격이 특정 기준 이하로 떨어지면 알림을 보내는 방식이다. 크론잡과 결합하면 매일 아침 가격 변동 요약을 받아볼 수 있다.
세 번째는 뉴스/공시 모니터링이다. 특정 기업이나 정책 관련 뉴스를 수집해서, 핵심만 요약한 뒤 채널로 보내주는 패턴이다. RSS 피드가 없는 사이트도 브라우저 스킬로 직접 접근해서 처리할 수 있다. 정부 정책 사이트나 부동산 공시 같은 것들이 대표적인 예다. 이런 사이트들은 API를 제공하지 않는 경우가 많아서, 브라우저 제어 방식의 크롤링이 사실상 유일한 자동화 수단이다.
크롤링 스킬의 실제 성능은 AI 모델에 크게 좌우된다. 복잡한 자바스크립트 렌더링이 필요한 사이트에서는 페이지 로딩을 기다려야 하고, 에이전트가 DOM 구조를 분석해서 원하는 데이터를 추출해야 한다. 경험상 Claude Opus 계열이 이런 복잡한 페이지 분석에서 실수가 적었다. Haiku 같은 경량 모델로는 단순한 정적 페이지까지는 괜찮지만, 동적 렌더링 페이지에서는 데이터를 놓치는 경우가 종종 있었다.
크롤링 스킬을 만들 때 반드시 지켜야 할 원칙이 있다. 크롤링 간격을 충분히 두는 것, 로봇 차단에 대한 처리를 Rules 섹션에 명시하는 것, 그리고 수집한 데이터를 로컬에만 저장하도록 제한하는 것이다. 에이전트가 자의적으로 판단해서 차단을 우회하려고 시도하는 걸 방지하려면, “차단 감지 시 즉시 중단”을 명시적으로 적어둬야 한다.
SOUL.md로 에이전트의 기본 성격 설정하기
스킬이 “무엇을 할 수 있는가”를 정의한다면, SOUL.md는 “어떻게 행동하는가”를 정의한다. 워크스페이스 루트에 있는 이 파일은 모든 대화와 작업의 시작 전에 로드되는 기본 페르소나 설정이다.
스킬과의 관계를 비유하면, SOUL.md는 에이전트의 성격이고 스킬은 에이전트가 배운 기술이다. 아이폰으로 치면 SOUL.md는 iOS 설정이고 스킬은 앱이다.
실전에서 유용한 SOUL.md 설정 예시를 보자.
# 나의 AI 비서 설정
## 기본 원칙
- 한국어로 대화한다.
- 간결하게 핵심만 전달한다. 불필요한 인사말이나 부연 설명은 생략한다.
- 파일 삭제나 메일 발송 같은 되돌릴 수 없는 작업은 반드시 확인을 받고 실행한다.
- 에러가 발생하면 원인과 해결 방법을 함께 제시한다.
## 업무 맥락
- 나는 기술 블로그를 운영하는 개발자다.
- 주로 AI, 클라우드 인프라, 웹 개발 관련 글을 쓴다.
- SEO 최적화와 애드센스 수익이 중요한 지표다.
## 금지 사항
- 민감한 파일(.env, API 키 파일)을 외부로 전송하지 않는다.
- 검증되지 않은 외부 스크립트를 실행하지 않는다.
- 사용자 확인 없이 유료 API를 호출하지 않는다.이 설정이 있으면 에이전트가 매번 새 대화를 시작할 때마다 이 맥락을 이해한 상태에서 출발한다. 스킬에서 “사용자에게 보고한다”라고 적어두면, SOUL.md의 “간결하게 핵심만 전달한다”는 원칙에 따라 출력 스타일이 결정되는 식이다.
ClawHub 스킬 설치할 때 반드시 확인할 것
ClawHub는 오픈클로의 공개 스킬 레지스트리다. 2026년 초 기준으로 5,700개 이상의 스킬이 등록되어 있고, 캘린더, 슬랙, 깃허브, 스마트홈 등 웬만한 자동화 시나리오는 커버한다. 설치는 CLI로 간단하다.
clawhub install 스킬이름그런데 여기서 반드시 경고해야 할 게 있다. 2026년 1월에 보안 연구팀이 ClawHub에서 341개의 악성 스킬을 발견했다. 타이포스쿼팅(비슷한 이름으로 속이기)과 가짜 전제조건 설치 단계를 이용해서 정보 탈취 악성코드를 배포한 사건이었다. 2월 중순까지 신고된 악성 스킬은 824개 이상으로 늘어났다. 최근에 VirusTotal과 파트너십을 맺어 보안 검증을 강화하고 있지만, 아직 완벽하지 않다.
커뮤니티 스킬을 설치하기 전에 반드시 해야 할 일이 있다. SKILL.md를 직접 열어서 내용을 확인하는 거다. 코드 리뷰와 같은 맥락이다. 난독화된 셸 명령, base64 인코딩된 스크립트, “이 명령을 먼저 실행하세요”라는 전제조건 단계가 보인다면 설치하지 않는 게 좋다. 새 스킬은 일회용 환경이나 샌드박스에서 먼저 돌려보고, 실행 승인(exec approval) 기능을 켜둔 상태에서 테스트하는 게 안전하다.
직접 만든 스킬을 ClawHub에 배포하고 싶다면, 깃허브 인증 후 CLI로 퍼블리시할 수 있다.
clawhub publish ~/.openclaw/skills/my-skill \
--slug my-skill \
--name "My Custom Skill" \
--version 1.0.0–slug는 레지스트리 전체에서 유일해야 하니 겹치지 않는 이름을 골라야 한다.
멀티 에이전트 구성과 스킬 분리
오픈클로는 하나의 게이트웨이에서 여러 에이전트를 동시에 운영할 수 있다. 각 에이전트는 자체 워크스페이스를 갖고, 워크스페이스 안의 skills 폴더에 있는 스킬은 해당 에이전트만 사용한다. 반면 ~/.openclaw/skills에 있는 스킬은 모든 에이전트가 공유한다.
이 구조를 활용하면 역할별 에이전트를 분리해서 운영할 수 있다. 예를 들어 “개발 에이전트”에게는 깃허브, CI/CD 관련 스킬을 붙이고, “운영 에이전트”에게는 모니터링과 리포팅 스킬을 붙이는 식이다. 각 에이전트를 서로 다른 텔레그램 채널이나 디스코드 채널에 바인딩하면, 용도별로 깔끔하게 분리된다.
한 유저의 실제 사례가 있었다. 4개의 에이전트를 운영하면서, 메인 에이전트는 전략과 기획, 나머지 세 에이전트는 각각 코딩, 리서치, 운영을 담당하게 했다. 각 에이전트의 SOUL.md와 스킬 세트를 다르게 구성한 거다. 이 구조의 장점은 각 에이전트의 컨텍스트가 오염되지 않는다는 점이다. 코딩 에이전트의 대화 내용이 운영 에이전트에 섞이지 않고, 각자 자기 영역에 집중할 수 있다.
멀티 에이전트 환경에서 스킬을 효율적으로 관리하는 팁이 하나 있다. 모든 에이전트가 공통으로 쓰는 스킬(웹 검색, 파일 읽기 등)은 ~/.openclaw/skills에 두고, 에이전트별 전문 스킬은 각 워크스페이스의 skills 폴더에 둔다. 이렇게 하면 스킬 업데이트를 한 곳에서만 하면 되고, 에이전트별 특화 스킬은 독립적으로 관리할 수 있다. 오픈클로의 스킬 우선순위 규칙(워크스페이스 > 로컬 > 번들) 덕분에, 공유 스킬을 특정 에이전트에서만 다르게 동작시키는 것도 가능하다.
이런 멀티 에이전트 구조에서 크론잡을 설정할 때는 세션 타겟을 주의해야 한다. 바인딩된 에이전트에게 main 세션 크론잡을 설정하면 제대로 작동하지 않는 경우가 있어서, isolated 세션을 쓰는 게 안전하다.
마무리
오픈클로의 스킬 시스템은 놀라울 정도로 단순하다. 폴더 하나, 마크다운 파일 하나가 전부다. 하지만 그 단순함 위에 크론잡, 하트비트, 멀티 에이전트, 브라우저 제어가 결합되면 상당히 정교한 자동화 시스템이 만들어진다. Zapier에서 수십 개의 Zap을 관리하던 걸, 자연어로 적은 마크다운 파일 몇 개가 대체해버리는 셈이다.
핵심을 정리하면 이렇다. 스킬은 에이전트에게 “어떤 상황에서 무엇을 어떻게 할지” 가르치는 플레이북이다. description을 구체적으로 쓰고, Rules 섹션에서 금지할 행동을 명확히 적어야 에이전트가 의도대로 움직인다. 크론은 정확한 타이밍이 필요할 때, 하트비트는 주기적 상태 점검이 필요할 때 쓴다. 그리고 커뮤니티 스킬은 반드시 코드 리뷰를 한다. 이 원칙만 지키면, 오픈클로를 단순한 챗봇이 아닌 진짜 자동화 워크플로우 엔진으로 활용할 수 있다.