이제 Claude Skill을 만들 때입니다
Claude를 잘 쓰는 사람과 Claude로 업무 시스템을 만드는 사람의 차이는
무엇일까요?
단순합니다.
Prompt는 한 번의 요청이고, Skill은 반복 가능한 업무 프로세스입니다.
매번 같은 프롬프트를 찾아서 복사하고, 자료를 다시 넣고,
출력 형식을 다시 설명한다면 아직 업무가 자동화된 것이 아닙니다.
Claude Skills의 핵심은 반복되는 업무를 하나의 재사용 가능한
Workflow로 만드는 것입니다.
01. Claude Skill이란 무엇인가?
Claude Skill은 특정 업무를 수행하기 위한 재사용 가능한
업무 패키지라고 이해하면 쉽습니다.
예를 들어 반복적으로 수행하는 업무가 있다면,
자료 조사 → /research
코드 리뷰 → /review
콘텐츠 재작성 → /rewrite
브랜드 문체 적용 → /brand-voice
문서 작성 → /document
반복 업무 자동화 → /automate
처럼 하나의 Skill로 분리할 수 있습니다.
여기서 가장 중요한 질문은 이것입니다.
“Claude가 언제 이 Skill을 사용해야 하는지 명확하게 판단할 수 있는가?”
Skill의 기능이 아무리 좋아도 사용 시점을 제대로 설명하지 못하면 활용성이 떨어집니다.
02. Skill은 작고 명확하게 설계하세요
기본 구조는 복잡할 필요가 없습니다.
my-skill/
├── SKILL.md
├── reference.md
├── examples.md
└── scripts/
각 파일의 역할을 분리합니다.
SKILL.md
→ 핵심 Workflow와 실행 지침
reference.md
→ 업무 수행에 필요한 참고지식과 기준
examples.md
→ 좋은 결과·나쁜 결과·Few-shot Example
scripts/
→ 검증·분석·자동화·보고서 생성 코드
중요한 원칙은 SKILL.md 하나에 모든 정보를 집어넣지 않는 것입니다.
핵심 지시는 짧게 유지하고, 무거운 정보는 지원 파일로 분리해야 유지보수도 쉬워집니다.
03. Skill의 성패는 Description에서 결정됩니다
Skill을 만들 때 이름보다 더 중요한 것이 Description입니다.
Description은 단순한 설명이 아닙니다.
Claude에게
“무엇을 하는 Skill이고, 어떤 상황에서 사용해야 하는가?”
를 알려주는 Trigger 역할을 합니다.
추천 구조는 다음과 같습니다.
Action + Task + Context + Trigger
나쁜 예:
PR 업무를 도와줍니다.
좋은 예:
Pull Request를 코드 리뷰용으로 요약합니다. 사용자가 PR 요약, 변경사항 분석, Release Notes 작성을 요청할 때 사용합니다.
차이는 명확합니다.
두 번째 설명에는
행동 + 대상 + 사용 상황 + Trigger 표현
이 들어 있습니다.
04. 하나의 Skill에는 하나의 Job만 넣으세요
처음 Skill을 만들면 욕심이 생깁니다.
예를 들어 하나의 Marketing Skill에
시장조사
→ 경쟁사 분석
→ 콘텐츠 작성
→ 이미지 생성
→ SEO
→ 게시
→ 성과분석
까지 모두 넣고 싶어집니다.
하지만 이렇게 거대하게 만들수록 Trigger와 실행 책임이 모호해집니다.
차라리 다음처럼 나누는 편이 관리하기 쉽습니다.
/market-research
/competitor-analysis
/content-write
/seo-review
/publish-check
즉,
One Skill = One Job
좁은 범위의 Skill 여러 개를 조합하면 더 큰 Workflow와 Agent System으로 확장하기도 쉽습니다.
05. Skill은 ‘설명문’이 아니라 ‘작업 절차서’처럼 작성하세요
Skill 안에서 Claude에게 추상적으로 말하면 결과도 추상적이 됩니다.
“전문적으로 분석해주세요.”
“최선을 다해주세요.”
“도움이 되는 결과를 작성해주세요.”
대신 실제 작업자가 따라야 할 SOP처럼 작성합니다.
Step 1
입력자료를 확인한다.
Step 2
필수정보 누락 여부를 검증한다.
Step 3
정해진 기준에 따라 분석한다.
Step 4
지정된 형식으로 결과를 생성한다.
Step 5
Acceptance Criteria를 기준으로 자체 검증한다.
그리고 반드시 정의하면 좋은 세 가지가 있습니다.
Input → Process → Output
여기에 실무 시스템에서는 하나를 더 추가하세요.
Verification
결국 좋은 Skill은 작은 SOP이면서 동시에 작은 실행 프로그램에 가깝습니다.
06. Templates · Examples · References를 적극 활용하세요
매번 Skill 안에서 모든 것을 설명할 필요가 없습니다.
Templates
검증된 보고서·이메일·분석표·문서 구조
Examples
좋은 결과와 좋지 않은 결과 사례
References
브랜드 가이드, 규격, API 문서, 내부 기준
이렇게 분리하면 핵심 Skill은 간결하게 유지하면서도 전문성을 높일 수 있습니다.
특히 좋은 예제와 나쁜 예제를 함께 제공하는 방식이 유용합니다.
Claude에게 무엇을 해야 하는지만 알려주는 것이 아니라,
“이런 결과는 통과, 이런 결과는 실패”
라는 판단 기준까지 제공하는 것입니다.
07. 반복적이고 정확해야 하는 작업은 Script로 넘기세요
모든 것을 언어모델에게 판단시키는 것이 좋은 설계는 아닙니다.
정확한 계산이나 기계적으로 검증할 수 있는 작업은 코드가 더 적합합니다.
예를 들어,
① Validation
JSON Schema, 입력값, 필수 필드 검증
② Automation
파일 처리, Bash/Python 실행, 반복 작업
③ Analysis
데이터 계산, 통계, 점수 산정
④ Reporting
Excel·CSV·HTML 등의 결과 생성
즉,
LLM이 잘하는 일은 LLM에게, 코드가 잘하는 일은 코드에게 맡깁니다.
이 원칙이 Agent 시스템의 신뢰성을 크게 높여줍니다.
08. 실행 방식도 Skill의 일부입니다
모든 Skill을 무조건 자동 실행시키는 것이 좋은 자동화는 아닙니다.
업무 위험도에 따라 실행 정책을 나누는 것이 좋습니다.
일반 업무
자동 또는 수동 호출
중요 업무
실행 전 사용자 확인
고위험 업무
삭제·배포·외부 전송·중요 데이터 변경 등은 명시적인 승인 절차 적용
특히 기업 환경에서는
Trigger → Permission → Execute → Verify → Log
구조를 만드는 것이 중요합니다.
자동화의 목표는 단순히 “사람을 없애는 것”이 아니라,
반복 업무는 자동화하면서 중요한 의사결정에는 사람을 남겨두는 것입니다.
09. 복잡한 업무는 Subagent로 분리하세요
Skill 하나가
20개 문서를 읽고,
데이터를 분석하고,
코드를 실행하고,
테스트하고,
여러 보고서를 생성해야 한다면
메인 Context에서 모든 것을 처리하기보다 역할을 분리하는 구조를 고려할 수 있습니다.
예를 들어,
Main Agent
↓
Planner
↓
Research Agent
↓
Executor
↓
Verifier
↓
Reporter
이 구조의 장점은 명확합니다.
역할 분리 → Context 오염 감소 → 검증 강화 → 유지보수 향상
Skill이 커지기 시작하면 Skill → Subagent → Multi-Agent Workflow로 확장할 수 있습니다.
10. Skill이 제대로 작동하지 않는다면 이것부터 확인하세요
대부분의 문제는 복잡한 곳에 있지 않습니다.
Description이 너무 추상적이지 않은가?
언제 실행해야 하는지 명확한가?
하나의 Skill에 너무 많은 책임을 넣지 않았는가?
Trigger가 실제 사용자의 표현과 맞는가?
핵심 지시가 지나치게 길지 않은가?
좋은 결과와 나쁜 결과 예제가 있는가?
출력 형식과 검증 기준이 정의되어 있는가?
Skill이 제대로 호출되지 않는다고 전체를 다시 만드는 것보다 Trigger와 Description부터 점검하는 것이 효율적입니다.
실무형 Claude Skill의 최종 공식
제가 실무 관점에서 조금 더 확장하면 다음과 같이 정리할 수 있습니다.
① Narrow Scope
하나의 Skill에는 하나의 명확한 책임
② Clear Trigger
언제 실행할 것인지 명확하게 정의
③ Lean Instructions
짧고 단계적인 실행 지침
④ Support Files
Template + Example + Reference 분리
⑤ Deterministic Scripts
정확성이 필요한 작업은 코드로 처리
⑥ Safe Execution
권한·승인·위험 작업 통제
⑦ Verification
결과 생성 후 품질 검증
⑧ Feedback Loop
실패 데이터를 다음 버전에 반영
따라서 진짜 중요한 공식은,
Trigger → Context → Execute → Verify → Improve
입니다.
그리고 여러 Skill이 연결되기 시작하면,
Prompt → Skill → Workflow → Agent → Multi-Agent System
으로 발전합니다.
가장 중요한 결론
Claude Skills의 핵심은 거대한 Prompt Library를 만드는 것이 아닙니다.
반복되는 업무를 작고 명확하며 검증 가능한 실행 단위로 바꾸는 것입니다.
프롬프트를 100개 저장하는 것보다,
정확하게 Trigger되고, 필요한 Context를 읽고, 정해진 절차를 실행하고, 결과를 검증하는 Skill 5개
가 실무에서는 훨씬 강력할 수 있습니다.
처음부터 거대한 자동화 시스템을 만들지 마세요.
가장 자주 반복하면서 가장 많은 시간을 빼앗는 업무 하나를 선택하세요.
그리고 그것을 첫 번째 Skill로 만드세요.
그 순간부터 Claude는 단순히 질문에 답하는 도구에서
업무를 실행하는 시스템으로 바뀌기 시작합니다.
핵심 공식
좁은 범위 + 명확한 Trigger + 간결한 지시 + 지원 파일 + 안전한 실행 + 결과 검증
= 실제로 작동하는 Claude Skill
프롬프트를 반복하지 말고, 반복 업무를 시스템으로 만드세요.
— 이춘곤(Mark) · ISC.studio · ISC출판 도서 안내
이 글은 저자의 Facebook에 처음 게시한 글입니다. Facebook 원문 보기
💬 댓글 (0)