검증된 크리에이터의 스킬 스택 공유
검증된 크리에이터만 스킬 스택에 글을 쓸 수 있습니다.
크리에이터 신청하기
Skills는 현재 Claude Code에서 가장 많이 활용되는 확장 포인트 중 하나가 되었습니다.
유연하고, 만들기 쉽고, 배포도 간단합니다.
하지만 바로 이 유연함 때문에 어려운 점도 있습니다.
어떤 종류의 스킬을 만들어야 할까요?
좋은 스킬을 작성하는 비결은 무엇일까요?
언제, 어떻게 다른 사람들과 공유해야 할까요?
Anthropic 내부에서는 Claude Code의 스킬을 광범위하게 활용하고 있으며, 현재 수백 개의 스킬이 실제로 운영되고 있다고 합니다. 이 글에서는 그들이 스킬을 통해 개발을 가속화하면서 배운 모든 교훈을 하나하나 풀어보겠습니다.
"어떤 스킬을 만들어야 할지 감이 안 잡힌다"는 분,
"만들긴 했는데 뭔가 어설프다"고 느끼시는 분,
"팀에 어떻게 공유하고 관리해야 할지 모르겠다"는 분 —
이 글에서 실질적인 답을 찾으실 수 있을 겁니다.
꽤 긴 글입니다. 하지만 그만큼 알차게 준비했으니, 끝까지 읽어주시면 감사하겠습니다.
30k 구독자를 가진 유튜버 에반입니다
자동으로 스킬만들어줘만 시키다가, 좋은 글 잘 읽고 갑니다.
스킬에 대해 가장 흔한 오해가 하나 있습니다.
"그냥 마크다운 파일 아닌가요?"
결론부터 말씀드리면, 아닙니다.
스킬은 폴더입니다.
마크다운 파일은 그 폴더 안에 있는 하나의 구성요소일 뿐입니다.
스킬 폴더 안에는 다양한 것들이 들어갈 수 있습니다:
- 스크립트: Python, Bash, Node.js 등 실행 가능한 코드
- 참조 코드 스니펫: Claude가 참고할 수 있는 예시 코드 모음
- 에셋 파일: 템플릿, 예시 출력물, 이미지 등
- 데이터 파일: JSON, SQLite, 로그 파일
- 설정 파일: config.json 등 사용자별 설정 저장
그리고 Claude Code에서는 한 가지 더 강력한 기능이 있습니다.
바로 다이나믹 훅(Dynamic Hooks) 등록입니다.
스킬이 호출될 때만 활성화되고, 세션이 유지되는 동안만 작동하는 훅을 스킬 안에 포함시킬 수 있습니다. 이 부분은 뒤에서 더 자세히 다루겠습니다.
핵심을 정리하면 이렇습니다.
스킬은 단순한 프롬프트 텍스트가 아니라, 에이전트에게 건네주는 도구 상자입니다.
도구 상자 안에 무엇을 넣느냐에 따라 에이전트의 능력이 근본적으로 달라집니다.
Anthropic 팀에서도 가장 흥미로운 스킬들은 이러한 설정 옵션과 폴더 구조를 창의적으로 활용한 스킬이었다고 합니다.
2. 9가지 스킬 유형: 우리 조직에 빠져 있는 것은 무엇인가
Anthropic이 내부에서 사용 중인 모든 스킬을 분류해본 결과, 9가지 반복되는 카테고리로 나뉘었다고 합니다.
좋은 스킬은 하나의 카테고리에 깔끔하게 들어갑니다.
반면 혼란을 주는 스킬은 여러 카테고리에 걸쳐 있었습니다.
이것이 확정적인 목록은 아니지만, 여러분의 조직에서 어떤 유형의 스킬이 빠져 있는지 점검하기에 아주 좋은 프레임워크입니다.
하나씩 살펴보겠습니다.
유형 1. 라이브러리 & API 레퍼런스
특정 라이브러리, CLI, SDK를 올바르게 사용하는 방법을 알려주는 스킬입니다.
내부 라이브러리일 수도 있고, 외부 라이브러리인데 Claude가 자주 실수하는 부분을 잡아주는 것일 수도 있습니다. 이런 스킬에는 보통 레퍼런스 코드 스니펫 폴더와 함께 Claude가 피해야 할 실수 목록(Gotchas)이 포함되어 있습니다.
실제 예시:
- billing-lib — 내부 결제 라이브러리의 엣지 케이스, 자주 발생하는 실수, 주의사항 정리
- internal-platform-cli — 내부 CLI 래퍼의 모든 서브커맨드와 각각 언제 사용해야 하는지에 대한 예시
- frontend-design — 조직의 디자인 시스템에 맞춰서 Claude가 더 좋은 UI 코드를 작성하도록 유도
이 카테고리가 중요한 이유는 명확합니다. Claude는 공개된 라이브러리에 대해서는 상당히 잘 알고 있지만, 내부 라이브러리는 당연히 알 수 없습니다. 그리고 공개 라이브러리라 하더라도 버전별로 API가 변경되면 혼란을 겪는 경우가 있습니다. 이런 부분을 스킬로 정확하게 잡아줄 수 있습니다.
유형 2. 프로덕트 검증 (Product Verification)
코드가 실제로 올바르게 작동하는지 테스트하고 검증하는 스킬입니다.
Playwright, tmux 같은 외부 도구와 결합하여 사용하는 경우가 많습니다.
그리고 이 카테고리는 Anthropic 내부에서 투자 대비 효과가 가장 높다고 평가받은 영역입니다.
Anthropic의 조언은 이렇습니다:
"엔지니어 한 명이 일주일을 투자해서 검증 스킬을 훌륭하게 만드는 것은 충분히 가치 있는 일입니다."
검증 스킬을 더 강력하게 만드는 기법들도 있습니다:
- Claude가 자신의 출력을 영상으로 녹화하게 하여, 정확히 무엇을 테스트했는지 사람이 확인할 수 있도록 하기
- 각 단계마다 프로그래밍적 어설션(programmatic assertions)을 실행하여 상태를 검증하기
- 스킬 폴더 안에 다양한 검증 스크립트를 포함시키기
실제 예시:
- signup-flow-driver — 회원가입 → 이메일 인증 → 온보딩 전체 흐름을 헤드리스 브라우저에서 실행하며, 각 단계마다 상태를 검증하는 훅이 포함되어 있음
- checkout-verifier — Stripe 테스트 카드로 결제 UI를 구동하고, 인보이스가 실제로 올바른 상태에 도달하는지까지 확인
- tmux-cli-driver — TTY가 필요한 인터랙티브 CLI 테스트용
유형 3. 데이터 가져오기 & 분석
조직의 데이터 및 모니터링 스택에 연결되는 스킬입니다.
데이터를 인증 정보와 함께 가져오는 라이브러리, 특정 대시보드 ID, 일반적인 워크플로우에 대한 안내 등이 포함될 수 있습니다.
실제 예시:
- funnel-query — "회원가입 → 활성화 → 유료 전환을 보려면 어떤 이벤트를 조인해야 하는지" + 실제 canonical user_id가 있는 테이블 정보
- cohort-compare — 두 코호트의 리텐션 또는 전환율을 비교하고, 통계적으로 유의미한 차이를 플래그하며, 세그먼트 정의 링크도 제공
- grafana — 데이터소스 UID, 클러스터 이름, "이런 문제가 생겼을 때 → 이 대시보드를 봐라" 매핑 테이블
이 유형의 스킬이 있으면 "어제 뭐가 있었어?"라는 질문 하나에 Claude가 데이터를 직접 조회해서 분석 결과를 내놓을 수 있게 됩니다.
유형 4. 비즈니스 프로세스 & 팀 자동화
반복적인 업무 워크플로우를 하나의 명령어로 자동화하는 스킬입니다.
보통 지시사항 자체는 비교적 단순하지만, 다른 스킬이나 MCP에 대한 의존성이 복잡할 수 있습니다. 이런 스킬에서는 이전 실행 결과를 로그 파일로 저장해두면, 모델이 일관성을 유지하고 이전 실행을 돌아보는 데 큰 도움이 됩니다.
실제 예시:
- standup-post — 티켓 트래커, GitHub 활동, 이전 Slack 메시지를 수집하여 포맷된 스탠드업을 생성하되, 변경된 부분(delta)만 포함
- create-<ticket-system>-ticket — 스키마를 강제(유효한 enum 값, 필수 필드)하고, 생성 후 워크플로우까지 처리(리뷰어에게 알림, Slack에 링크 공유)
- weekly-recap — 머지된 PR + 닫힌 티켓 + 배포 내역을 모아서 포맷된 주간 회고 포스트 생성
유형 5. 코드 스캐폴딩 & 템플릿
코드베이스 내 특정 기능에 대한 프레임워크 보일러플레이트를 생성하는 스킬입니다.
이런 스킬은 스크립트와 조합하여 사용할 수 있으며, 특히 자연어로 표현되는 요구사항이 코드만으로는 완전히 커버되지 않을 때 매우 유용합니다.
실제 예시:
- new-<framework>-workflow — 조직의 어노테이션이 포함된 새 서비스/워크플로우/핸들러를 스캐폴딩
- new-migration — 마이그레이션 파일 템플릿과 흔히 발생하는 실수 목록 포함
- create-app — 인증, 로깅, 배포 설정이 미리 연결된 새 내부 앱 생성
유형 6. 코드 품질 & 리뷰
조직 내 코드 품질을 강제하고 코드 리뷰를 돕는 스킬입니다.
최대한의 견고성을 위해 결정론적인(deterministic) 스크립트나 도구를 포함할 수 있습니다. 이런 스킬은 훅의 일부로 자동 실행하거나, GitHub Action 안에서 구동하는 것도 고려해볼 만합니다.
실제 예시:
- adversarial-review — 새로운 시각의 서브에이전트를 스폰하여 코드를 비판하고, 수정을 구현하고, 발견사항이 사소한 수준까지 떨어질 때까지 반복
- code-style — 코드 스타일을 강제하되, 특히 Claude가 기본적으로 잘 따르지 않는 스타일에 집중
- testing-practices — 테스트를 어떻게 작성하고 무엇을 테스트해야 하는지에 대한 지침
유형 7. CI/CD & 배포
코드를 가져오고, 푸시하고, 배포하는 것을 도와주는 스킬입니다.
다른 스킬을 참조하여 데이터를 수집하는 경우도 있습니다.
실제 예시:
- babysit-pr — PR을 모니터링 → flaky한 CI를 재시도 → 머지 충돌을 해결 → 자동 머지를 활성화
- deploy-<service> — 빌드 → 스모크 테스트 → 점진적 트래픽 전환(에러율 비교 포함) → 문제 발생 시 자동 롤백
- cherry-pick-prod — 격리된 워크트리에서 → 체리픽 → 충돌 해결 → 템플릿 기반 PR 생성
특히 babysit-pr 같은 스킬은 매우 실용적입니다. PR을 올려놓고 다른 일을 하면, CI가 실패해도 알아서 재시도하고, 머지 충돌도 처리하고, 문제가 없으면 자동으로 머지까지 해주는 거니까요.
유형 8. 런북 (Runbooks)
증상(Slack 스레드, 알림, 에러 시그니처 등)을 입력받아서, 여러 도구를 활용한 조사를 진행하고, 구조화된 보고서를 생성하는 스킬입니다.
실제 예시:
- <service>-debugging — 증상을 도구와 쿼리 패턴에 매핑하는 가이드 (가장 트래픽이 많은 서비스용)
- oncall-runner — 알림을 가져오고 → 일반적인 원인들을 점검하고 → 결과를 보고서 형태로 정리
- log-correlator — 요청 ID가 주어지면, 해당 요청이 거쳐간 모든 시스템에서 매칭되는 로그를 수집
온콜 엔지니어에게 이런 스킬이 있으면, 새벽 3시에 알림을 받아도 체계적으로 대응할 수 있습니다.
유형 9. 인프라 운영
정기적인 유지보수와 운영 절차를 수행하는 스킬입니다.
일부는 파괴적인 작업을 포함하기 때문에, 가드레일이 특히 중요합니다.
이런 스킬은 엔지니어가 위험한 작업에서도 모범 사례를 따르기 쉽게 만들어줍니다.
실제 예시:
- <resource>-orphans — 고아 상태의 pod/volume을 찾아서 → Slack에 포스트 → 일정 기간 대기 → 사용자 확인 후 → 단계적 정리 실행
- dependency-management — 조직의 의존성 승인 워크플로우
- cost-investigation — "왜 스토리지/이그레스 비용이 갑자기 올랐을까?"에 대한 조사를, 특정 버킷과 쿼리 패턴을 이용하여 수행
3. 좋은 스킬을 만드는 7가지 핵심 원칙
어떤 스킬을 만들지 결정했다면, 이제 어떻게 만들 것인가의 문제입니다.
Anthropic이 수백 개의 스킬을 운영하면서 찾아낸 실전 노하우를 공유합니다.
(참고로 Anthropic은 최근 Skill Creator라는 도구도 출시하여 스킬 제작을 더 쉽게 만들었습니다.)
원칙 1. 당연한 것을 말하지 마세요
Claude Code는 여러분의 코드베이스에 대해 이미 많은 것을 알고 있습니다.
그리고 Claude 자체도 코딩에 대해 다양한 기본 의견을 가지고 있습니다.
지식 전달이 주된 목적인 스킬을 만들 때는, Claude의 기본 사고방식에서 벗어나게 만드는 정보에 집중해야 합니다.
좋은 사례가 frontend-design 스킬입니다. 이 스킬은 Anthropic의 한 엔지니어가 고객들과 반복적으로 테스트하면서 만들었는데, Claude의 디자인 감각을 개선하는 데 초점을 맞췄습니다. 구체적으로는 Inter 폰트와 보라색 그라디언트 같은 Claude가 기본적으로 선호하는 패턴을 피하도록 유도하는 것이었습니다.
즉, "React에서 useState는 이렇게 씁니다" 같은 내용은 스킬에 넣을 필요가 없습니다. Claude가 이미 알고 있으니까요. 대신 "우리 조직에서는 상태 관리를 이런 특수한 방식으로 합니다"라는 내용이 스킬에 들어가야 합니다.
원칙 2. Gotchas(주의사항) 섹션을 반드시 만드세요
어떤 스킬이든 가장 높은 신호 가치(signal value)를 가진 콘텐츠는 Gotchas 섹션입니다.
이 섹션은 Claude가 해당 스킬을 사용할 때 자주 빠지는 실수 포인트를 모아놓은 것입니다.
처음부터 완벽하게 작성할 필요는 없습니다. 시간이 지나면서 Claude가 새로운 실수를 할 때마다 해당 실수를 추가하여 계속 업데이트하면 됩니다.
이렇게 쌓인 Gotchas는 마치 조직의 집단 기억과 같습니다.
"이 API를 호출할 때 타임존 변환을 빼먹으면 프로덕션에서 터집니다" 같은, 경험을 통해서만 얻을 수 있는 지식이 여기에 축적되는 것입니다.
원칙 3. 파일 시스템과 점진적 공개(Progressive Disclosure)를 활용하세요
앞서 강조했듯이, 스킬은 폴더입니다.
전체 파일 시스템 자체를 컨텍스트 엔지니어링과 점진적 공개의 수단으로 생각해야 합니다.
Claude에게 스킬 안에 어떤 파일들이 있는지 알려주면, 적절한 타이밍에 알아서 필요한 파일을 읽습니다.
점진적 공개의 가장 간단한 형태는 다른 마크다운 파일을 참조하는 것입니다. 예를 들어, 상세한 함수 시그니처와 사용 예시를 references/api.md로 분리할 수 있습니다. 메인 스킬 파일에는 핵심 지침만 두고, 세부사항은 필요할 때만 참조하도록 하는 것입니다.
또 다른 예시: 최종 출력물이 마크다운 파일이라면, assets/ 폴더에 템플릿 파일을 넣어두고 복사해서 사용하도록 안내할 수 있습니다.
활용 가능한 폴더 구조의 예:
my-skill/
├── SKILL.md # 핵심 지침
├── references/
│ ├── api.md # API 레퍼런스
│ └── examples.md # 코드 예시
├── scripts/
│ ├── validate.sh # 검증 스크립트
│ └── setup.py # 설정 스크립트
├── assets/
│ └── template.md # 출력 템플릿
└── config.json # 사용자 설정
이렇게 구성하면 Claude에게 주어지는 초기 컨텍스트는 최소화하면서도, 필요한 순간에 깊은 정보를 제공할 수 있습니다.
원칙 4. Claude를 지나치게 구속하지 마세요
Claude는 기본적으로 여러분이 준 지침을 충실히 따르려고 합니다.
그리고 스킬은 재사용성이 높기 때문에, 지침이 지나치게 구체적이면 오히려 문제가 됩니다.
Claude에게 필요한 정보는 주되, 상황에 적응할 유연성도 함께 주어야 합니다.
나쁜 예시:
"반드시 3개의 함수를 만들고, 첫 번째 함수는 정확히 이 시그니처를 사용하고..."
좋은 예시:
"이런 패턴을 따르되, 구체적인 구현은 상황에 맞게 조정하세요. 다만 이런 실수는 반드시 피하세요..."
스킬은 가드레일이어야 하지, 레일이 되어서는 안 됩니다.
원칙 5. 초기 설정(Setup)을 신중하게 설계하세요
일부 스킬은 사용자의 컨텍스트를 바탕으로 초기 설정이 필요합니다.
예를 들어, Slack에 스탠드업을 포스트하는 스킬이라면, 어떤 Slack 채널에 올릴지 사용자에게 물어봐야 합니다.
좋은 패턴은 설정 정보를 스킬 디렉토리 안의 config.json 파일에 저장하는 것입니다. 설정이 아직 완료되지 않은 상태라면, 에이전트가 자동으로 사용자에게 필요한 정보를 질문하도록 만들 수 있습니다.
구조화된 객관식 질문을 제시하고 싶다면, Claude에게 AskUserQuestion 도구를 사용하도록 지시할 수도 있습니다.
원칙 6. Description 필드는 모델을 위한 것입니다
이 점은 많은 분들이 간과하시는 부분입니다.
Claude Code가 세션을 시작하면, 사용 가능한 모든 스킬의 description을 수집하여 목록을 만듭니다. Claude는 이 목록을 스캔하여 "이 요청에 맞는 스킬이 있는가?"를 판단합니다.
따라서 description 필드는 요약이 아닙니다.
이 스킬이 언제 트리거되어야 하는지에 대한 설명입니다.
나쁜 description:
"프론트엔드 디자인 관련 스킬입니다."
좋은 description:
"UI 컴포넌트, 페이지, 랜딩 페이지를 만들거나 웹 인터페이스를 디자인/스타일링할 때 사용합니다. React, HTML/CSS, Tailwind 관련 작업에서 트리거됩니다."
원칙 7. 스크립트를 저장하고 코드를 생성하게 하세요
Claude에게 줄 수 있는 가장 강력한 도구 중 하나는 코드 그 자체입니다.
스킬 안에 스크립트와 라이브러리를 포함시키면, Claude는 보일러플레이트를 재구성하는 데 시간을 쓰는 대신 조합(composition)에 집중할 수 있습니다. 즉, "다음에 무엇을 해야 할까?"를 결정하는 데 더 많은 턴을 사용하게 됩니다.
예를 들어, 데이터 분석 스킬에 이벤트 소스에서 데이터를 가져오는 헬퍼 함수 라이브러리를 포함시킬 수 있습니다. 이런 헬퍼 함수가 준비되어 있으면, "화요일에 무슨 일이 있었어?"라는 질문에 대해 Claude가 즉석에서 이 함수들을 조합한 분석 스크립트를 생성하여 실행할 수 있습니다.
4. 고급 테크닉: 메모리, 훅, 데이터 저장
기본 원칙을 넘어, 스킬을 정말 강력하게 만들어주는 고급 기법들이 있습니다.
메모리 & 데이터 저장
일부 스킬은 데이터를 스킬 안에 저장하는 형태의 메모리를 포함할 수 있습니다.
저장 방식은 다양합니다:
- 단순한 추가 전용 텍스트 로그 파일
- JSON 파일
- 복잡하게는 SQLite 데이터베이스까지
구체적인 예시를 들어보겠습니다. standup-post 스킬이 standups.log를 유지한다고 가정합니다. 매번 스탠드업을 작성할 때마다 이 로그에 기록이 추가됩니다. 그러면 다음에 스킬을 실행할 때 Claude가 자신의 이전 기록을 읽고, 어제 이후 무엇이 변경되었는지 자동으로 파악할 수 있습니다.
중요한 주의사항: 스킬 디렉토리에 저장된 데이터는 스킬을 업그레이드할 때 삭제될 수 있습니다. 따라서 영구적인 데이터는 안정적인 폴더에 저장해야 합니다. 현재 Claude Code에서는 플러그인별로 안정적인 저장 폴더로 ${CLAUDE_PLUGIN_DATA}를 제공하고 있습니다.
온디맨드 훅 (On-Demand Hooks)
스킬은 호출될 때만 활성화되고, 세션 동안만 지속되는 훅을 포함할 수 있습니다.
이 기능은 항상 실행하기에는 너무 과한데, 특정 상황에서는 극도로 유용한 규칙을 적용할 때 사용합니다.
실제 예시:
- /careful — rm -rf, DROP TABLE, 강제 푸시, kubectl delete를 PreToolUse 매처를 통해 차단합니다. 프로덕션 환경을 다룰 때만 이 스킬을 켜면 됩니다. 항상 켜두면 개발이 불가능할 정도로 제약이 심하니까요.
- /freeze — 특정 디렉토리가 아닌 곳에 대한 Edit/Write를 모두 차단합니다. 디버깅할 때 유용합니다. "로그만 추가하고 싶은데 자꾸 관련 없는 코드를 수정해버리는" 상황을 방지할 수 있습니다.
이런 훅은 "필요할 때만 켜는 안전장치"로 생각하시면 됩니다. 매우 강력하지만 항상 켜두기엔 부담스러운 규칙들을 스킬화하는 것입니다.
5. 스킬 배포: 팀과 함께 쓰는 법
스킬의 가장 큰 장점 중 하나는 팀원들과 공유할 수 있다는 것입니다.
공유 방법은 크게 두 가지입니다.
방법 1. 레포지토리에 체크인
스킬을 레포의 ./.claude/skills 디렉토리에 직접 체크인하는 방법입니다.
장점:
- 설정이 간단합니다
- 별도의 인프라가 필요 없습니다
- 코드 리뷰와 동일한 프로세스로 관리됩니다
단점:
- 체크인된 모든 스킬이 모델의 컨텍스트에 조금씩 추가됩니다
- 레포가 많아지면 관리가 어려워질 수 있습니다
소규모 팀이 비교적 적은 수의 레포에서 작업할 때는 이 방법이 잘 작동합니다.
방법 2. 내부 플러그인 마켓플레이스
플러그인을 만들어서 내부 Claude Code Plugin 마켓플레이스에 등록하는 방법입니다.
장점:
- 팀원 각자가 필요한 스킬만 선택적으로 설치할 수 있습니다
- 컨텍스트 부하를 분산시킬 수 있습니다
- 조직 전체로 확장하기에 적합합니다
단점:
- 초기 설정에 더 많은 노력이 필요합니다
- 큐레이션 체계가 필요합니다
규모가 커질수록 마켓플레이스 방식이 더 효과적입니다.
마켓플레이스 운영 노하우
"어떤 스킬을 마켓플레이스에 올려야 하나요? 제출 절차는 어떻게 되나요?"
Anthropic의 접근 방식은 이렇습니다:
결정을 내리는 중앙 팀은 없습니다. 대신 가장 유용한 스킬을 유기적으로 발견하려고 합니다.
1. 다른 사람들이 써봤으면 하는 스킬이 있으면, GitHub의 샌드박스 폴더에 업로드합니다
2. Slack이나 기타 커뮤니케이션 채널에서 해당 스킬을 홍보합니다
3. 스킬이 충분한 견인력(traction)을 얻으면 (이 판단은 스킬 소유자에게 달려 있음), 마켓플레이스로 옮기는 PR을 제출합니다
경고: 나쁘거나 중복된 스킬을 만들기가 상당히 쉽습니다. 따라서 릴리스 전에 어떤 형태의 큐레이션이 반드시 이루어져야 합니다.
스킬 간 의존성 (Composing Skills)
서로 의존하는 스킬을 만들고 싶을 수 있습니다.
예를 들어, 파일을 업로드하는 스킬이 있고, CSV를 생성한 다음 업로드하는 스킬이 있을 수 있습니다.
이런 종류의 의존성 관리는 아직 마켓플레이스나 스킬에 기본 내장되어 있지 않습니다. 하지만 현재로서는 다른 스킬을 이름으로 참조하면, 해당 스킬이 설치되어 있는 경우 모델이 알아서 호출합니다.
스킬 사용량 측정
스킬이 잘 작동하고 있는지 어떻게 알 수 있을까요?
Anthropic에서는 PreToolUse 훅을 사용하여 회사 내 스킬 사용량을 로깅합니다.
이를 통해:
- 어떤 스킬이 인기 있는지 파악할 수 있습니다
- 기대 대비 트리거율이 낮은 스킬을 찾아낼 수 있습니다
- 스킬의 description을 개선할 근거를 확보할 수 있습니다
6. 정리하며
스킬은 에이전트를 위한 믿을 수 없을 정도로 강력하고 유연한 도구입니다.
하지만 아직 초기 단계이며, 최적의 활용법을 우리 모두가 함께 찾아가고 있는 중입니다.
이 글을 확정적인 가이드라기보다는, 실제로 효과가 있었던 팁들의 모음으로 봐주시면 좋겠습니다.
스킬을 이해하는 가장 좋은 방법은 직접 시작하고, 실험하고, 무엇이 효과적인지 확인하는 것입니다.
Anthropic 내부에서 사용되는 대부분의 스킬도 처음에는 몇 줄의 텍스트와 하나의 Gotcha로 시작했습니다. 그리고 Claude가 새로운 엣지 케이스에 부딪힐 때마다 사람들이 계속 추가하면서 점점 더 나아졌습니다.
핵심을 다시 한 번 요약하면:
1. 스킬은 폴더다 — 마크다운 파일이 아니라 도구 상자
2. 9가지 유형을 체크리스트로 활용하여 조직에 빠진 스킬을 찾으세요
3. Gotchas 섹션이 가장 가치 있는 콘텐츠입니다
4. 점진적 공개를 활용하여 컨텍스트를 효율적으로 관리하세요
5. Claude를 구속하지 말고 가드레일을 제공하세요
6. Description은 트리거 조건으로 작성하세요
7. 스크립트와 코드를 포함시켜서 Claude의 조합 능력을 극대화하세요
8. 메모리와 온디맨드 훅으로 고급 기능을 구현하세요
9. 유기적 큐레이션으로 마켓플레이스를 운영하세요
시작은 작게 하더라도 괜찮습니다.
한 가지 Gotcha, 한 가지 레퍼런스 파일만으로도 충분합니다.
중요한 것은 시작하고, 계속 개선해나가는 것입니다.