Claude Code Agent Skills · 공식 가이드

8가지 팁
에이전트 스킬(Skill)
마스터하는 방법

스킬은 에이전트에서 가장 많이 사용되는 확장 포인트 중 하나입니다.
유연하고 만들기도 쉬우며, 배포하기도 간편한 스킬을 제대로 활용하세요.

8
핵심 팁
2
스킬 유형
3
레이어
50%
성능 향상 기대
목차

8가지 실전 팁 한눈에 보기

각 팁을 클릭하면 해당 섹션으로 바로 이동합니다.

1
스킬의 본질을 이해하세요
2
설명을 명확히 작성하세요
3
에세이가 아닌 '지시 사항'을 쓰세요
4
가볍게(Lean) 유지하세요
5
적절한 수준의 자유도를 부여하세요
6
부정적인 케이스를 잊지 마세요
7
배포하기 전에 테스트하세요
8
스킬을 폐기할 시점을 파악하세요
1
Foundation

스킬의 본질을 이해하세요

스킬은 SKILL.md 파일과 (선택 사항인) 몇 가지 보조 파일들이 담긴 폴더입니다. 에이전트에서 가장 많이 사용되는 확장 포인트 중 하나로, 유연하고 만들기도 쉬우며 배포하기도 간편합니다.

스킬 폴더 구조
my-skill/ ├── SKILL.md ← 필수 파일 ├── scripts/ ← 에이전트가 실행할 수 있는 재사용 코드 ├── references/ ← 에이전트가 필요할 때 읽는 문서 └── assets/ ← 출력물에 사용되는 템플릿, 이미지, 파일들
스킬의 3개 레이어
항상
이름 및 설명
(Frontmatter) — 모든 프롬프트에 포함
트리거
SKILL.md 본문
마크다운 형식의 지침 (500행 이하 권장)
필요시
에셋
scripts/, references/, assets/ 폴더
스킬의 두 가지 유형
A
역량(Capability) 스킬 — 기본 모델이 일관되게 수행하지 못하는 작업(예: PDF 양식 채우기)을 돕습니다. 모델이 발전함에 따라 불필요해질 수 있으며, 평가(Eval)를 통해 삭제 시점을 판단합니다.
B
선호도(Preference) 스킬 — 팀의 코드 리뷰 단계와 같이 특정 워크플로우를 규정합니다. 지속적으로 활용되지만, 실제 프로세스와 동기화 상태를 유지해야 합니다.
2
Description Design

설명을 명확히 작성하세요

SKILL.md의 설명(Description)은 스킬을 작동시키는 '트리거'입니다. 설명이 모호하면 에이전트가 언제 스킬을 활성화해야 할지 알 수 없고, 너무 광범위하면 모든 요청에 스킬이 실행되어 버립니다.

설명만 개선해도 성능이 50% 향상되는 경우를 자주 보았습니다.
스킬이 무엇을(What) 하는지, 그리고 언제(When) 사용해야 하는지 구체적으로 명시하세요.
나쁜 예시 vs 좋은 예시
✗ 너무 모호함
"문서 작업을 도와줌"
✓ 구체적이고 실행 가능
".docx 파일을 생성, 편집 및 분석합니다. 변경 내용 추적, 메모, 서식 지정 또는 텍스트 추출 시 사용하세요."
✗ 너무 모호함
"API 도우미"
✓ 명확한 트리거
"텍스트 생성, 멀티턴 채팅, 이미지 생성 또는 스트리밍을 위해 Gemini API를 호출하는 코드를 작성할 때 사용하세요."
핵심 원칙
스킬 본문은 스킬이 트리거된 '이후'에만 로드된다는 점을 명심하세요. 설명이 정확해야 스킬이 올바른 상황에 발동됩니다.
3
Content Style

에세이가 아닌 '지시 사항'을 쓰세요

에이전트는 똑똑합니다. 여러분의 역할은 에이전트가 '아직 모르는 것'을 알려주는 것입니다. 연구에 따르면 문맥이 너무 많은 길고 포괄적인 지침은 오히려 성능을 저하시킵니다.

효과적인 지침 작성 4원칙
  • 명령조를 사용하세요: "Interactions API를 권장합니다"라고 쓰지 말고, interactions.create()를 사용하세요라고 하세요. 전자는 단순한 정보일 뿐이지만, 후자는 에이전트가 수행해야 할 지침입니다.
  • 예시를 먼저 제시하세요: 다섯 문단의 설명보다 다섯 줄의 코드 스니펫이 훨씬 효과적입니다.
  • 이유를 설명하세요: 규칙이 중요한 경우 이유를 덧붙이세요. "모델 X를 사용하세요. 모델 Y는 곧 중단될 예정이며 오류를 반환합니다"라고 하면 에이전트는 단순히 암기하는 것이 아니라 상황에 맞게 유연하게 대처할 수 있습니다.
  • 과적합(Overfitting)을 피하세요: 특정 프롬프트 세 개만 통과하기 위한 미세한 수정에 매몰되지 마세요. 수백만 번의 실행에도 작동할 수 있는 스킬을 작성해야 합니다.
💡
에이전트는 '왜'를 알면 '어떻게'를 스스로 판단합니다.
단순한 규칙 나열보다 맥락과 이유가 담긴 지침이 훨씬 강력합니다.
4
Architecture

가볍게(Lean) 유지하세요

모든 내용을 하나의 파일에 몰아넣지 마세요. 에이전트는 정보를 레이어별로 로드합니다. 3단계 로딩 구조를 활용해 컨텍스트 공간을 효율적으로 관리하세요.

3단계 로딩 전략
1
항상 로드됨
SKILL.md의 Frontmatter (이름 + 설명)
2
스킬 트리거 시
SKILL.md 본문 (500행 미만 권장)
3
필요할 때
참조 파일, 스크립트, 에셋
여러 주제 분리하기

만약 스킬이 여러 주제(예: AWS 배포와 GCP 배포)를 다룬다면, 이를 별도의 참조 파일로 분리하세요. 에이전트는 필요한 것만 읽게 되어, 실제 작업을 위한 컨텍스트 공간을 아낄 수 있습니다.

📌
팁: 참조 파일이 500행을 넘는다면 상단에 '행 번호 힌트'가 포함된 목차를 추가하여 에이전트가 필요한 내용을 빠리 찾을 수 있게 하세요.
5
Autonomy

적절한 수준의 자유도를 부여하세요

흔히 하는 실수는 스킬을 단계별 워크플로우로 만드는 것입니다. 모든 단계를 강요하면 에이전트가 스스로 적응하거나, 오류를 복구하거나, 더 나은 방법을 찾을 기회를 박탈하게 됩니다. 경로가 아니라 결과를 설명하세요.

목표를 제시하세요 (절차 ❌ → 조건 ✓)
✗ 과도한 절차 명시
"1단계: 설정 파일을 읽는다. 2단계: DB URL을 찾는다. 3단계: 포트 번호를 수정한다. 4단계: 파일을 저장한다."
✓ 목표(결과) 제시
"설정 파일의 데이터베이스 포트를 사용자가 지정한 값으로 업데이트하세요."
✗ 단계별 절차 강요
"1단계: 브랜치를 생성한다. 2단계: 수정한다. 3단계: 테스트를 돌린다. 4단계: PR을 연다."
✓ 제약 조건 제시
"PR을 열기 전에 항상 테스트를 실행하세요. main 브랜치에 직접 푸시하지 마세요."
핵심 원칙
만약 정확한 단계가 매우 중요하다면 '스크립트'를 작성하세요. 3단계 이전에 2단계를 안 해서 모든 게 망가지는 작업이라면, 그것은 스킬의 문제가 아니라 스크립팅의 문제입니다.
6
Negative Cases

부정적인 케이스(Negative Cases)를 잊지 마세요

스킬이 실행되지 말아야 할 때가 언제인지 생각하세요. "모든 코딩 작업에 사용"과 같은 설명은 모든 요청을 가로채 버릴 수 있습니다.

Negative Case 명시 예시
📄
좋은 설명 예시:
"PDF 파일 작업 시 사용하세요. 일반적인 문서 편집, 스프레드시트 또는 일반 텍스트 파일에는 사용하지 마세요."
양방향 테스트가 필수입니다

'트리거되어야 하는 경우'와 '트리거되지 말아야 하는 경우'를 모두 테스트하는 것이 필수적입니다. 그렇지 않으면 스킬이 한쪽으로만 치우치게 됩니다.

트리거 케이스: "이 상황에서는 반드시 스킬이 활성화되어야 한다"
비트리거 케이스: "이 상황에서는 스킬이 실행되면 안 된다"
⚠️
과도하게 넓은 설명은 스킬을 망칩니다.
스킬이 너무 자주 발동되면 에이전트의 다른 능력을 방해하고, 불필요한 컨텍스트를 소모합니다.
7
Quality Assurance

배포하기 전에 테스트하세요

평가(Evaluation) 없이 스킬을 배포하지 마세요. 에이전트는 실행할 때마다 다르게 동작할 수 있으므로 한 번의 확인으로는 부족합니다.

테스트 체크리스트
  • 수동 테스트: 다양한 프롬프트로 직접 실행해 보세요. 어디서 끊기는지, 필요한 종속성이 있다고 가정해버리는지, 단계를 건너뛰는지 관찰하세요.
  • 성공 기준 정의: 결과물이 컴파일되는가? 올바른 API를 사용했는가? 지침을 따랐는가? 과정이 아닌 '결과'를 평가하세요.
  • 10~20개의 테스트 프롬프트: 처리해야 할 프롬프트, 무시해야 할 프롬프트, 까다로운 엣지 케이스를 섞으세요.
  • 여러 번 반복: 에이전트의 출력은 비결정적입니다. 프롬프트당 3~5회 실행하여 성공/실패 분포를 확인하세요.
  • 실행 환경 격리: 각 테스트에 깨끗한 환경을 사용하세요. 이전 실행의 컨텍스트가 남아 있으면 실제 실패 원인을 가릴 수 있습니다.
  • 설명부터 수정: 대부분의 문제는 지침 본문이 아니라 '트리거(설명)'에 있습니다. 설명을 먼저 점검하세요.
🎯
과정이 아닌 결과를 평가하세요.
"3단계를 실행했는가?"가 아니라 "최종 결과물이 올바른가?"를 기준으로 테스트하세요.
8
Lifecycle

스킬을 폐기할 시점을 파악하세요

스킬 없이 평가를 진행해 보세요. 스킬 없이도 테스트를 통과한다면, 모델이 이미 그 스킬의 가치를 흡수한 것이므로 해당 스킬은 더 이상 필요하지 않습니다. 이제 폐기(Retire)하세요. 특히 모델이 발전함에 따라 역량(Capability) 스킬에서 이런 경우가 자주 발생합니다.

폐기 판단 기준
스킬 없이 테스트 실행 — 동일한 테스트 프롬프트 세트를 스킬 없이 돌려보세요.
성공률 비교 — 스킬 유무에 따른 성공률 차이가 미미하다면 폐기 신호입니다.
폐기 결정 — 스킬이 불필요하다면 과감히 제거하세요. 불필요한 스킬은 컨텍스트 공간을 낭비합니다.
♻️
스킬도 생명주기가 있습니다.
모델이 발전함에 따라 역량 스킬은 자연스럽게 불필요해집니다. 주기적으로 스킬을 재평가하고, 더 이상 가치를 추가하지 않는 스킬은 과감히 폐기하세요.
🎯

8가지 팁 요약

1. 스킬의 3레이어 구조와 2가지 유형을 이해하라
2. 설명(Description)을 명확히 — What + When
3. 에세이 ❌ → 명령조 지시사항 ✓
4. SKILL.md 500행 이하, 참조는 별도 파일로
5. 절차가 아닌 목표(결과)를 지정하라
6. Negative Case를 명시해 과도한 트리거를 막아라
7. 10~20개 프롬프트, 3~5회 반복 테스트 필수
8. 모델이 발전하면 주기적으로 폐기 여부를 평가하라