나만의 Claude 스킬 만들기 — skill-creator와 mcp-builder 입문

반복하는 작업을 Claude 스킬로 묶는 법. 공식 skill-creator로 스킬을 만들고, mcp-builder로 외부 도구를 연결하는 개념 입문.

FileKeeps2026-07-27 · 6분 읽기

매번 Claude에게 같은 업무 절차를 설명하고 있다면, 이제 그 설명을 하나의 Skill로 만들어볼 때일지도 모릅니다. AI를 업무에 사용하다 보면 어느 순간 비슷한 지시를 계속 반복하게 됩니다. 예를 들어 보고서를 작성할 때마다 이런 말을 붙여 넣습니다.

먼저 핵심 내용을 5줄 이내로 요약해줘.
그다음 중요한 수치를 표로 정리하고,
문제점과 다음 액션을 따로 구분해줘.
문장은 너무 길게 쓰지 마.

다음 주에도 똑같이 입력합니다. 그다음 주에도 또 입력합니다. 이 정도면 사실 프롬프트라기보다 업무 매뉴얼에 가깝습니다. Claude Skills는 이렇게 반복해서 사용하는 업무 방식과 규칙을 하나의 재사용 가능한 형태로 묶어두는 기능입니다. Anthropic의 공식 Skills 저장소에서도 Skill을 특정 작업을 반복적으로 수행하도록 Claude에게 가르치는 지침, 스크립트, 리소스가 들어 있는 폴더로 설명합니다. 각 Skill에는 SKILL.md가 필요하고, 여기에 이름과 설명, 실제 작업 지침을 작성할 수 있습니다. (GitHub)

Skill은 생각보다 단순하다

처음 Claude Skill이라는 말을 들으면 뭔가 복잡한 플러그인이나 별도의 AI 모델을 만들어야 할 것처럼 느껴질 수 있습니다. 실제로 기본 구조는 훨씬 단순합니다. 하나의 폴더가 하나의 Skill이 됩니다. 예를 들어 주간 보고서를 작성하는 Skill을 만든다면 이런 구조가 될 수 있습니다.

weekly-report/
├── SKILL.md
├── references/
│   └── report-style.md
└── scripts/
    └── calculate_growth.py

여기서 반드시 필요한 핵심 파일은 SKILL.md입니다. 추가 자료가 필요하다면 references에 문서를 넣을 수 있고, 반복적으로 실행해야 하는 계산이나 변환 작업이 있다면 scripts를 함께 둘 수도 있습니다. Anthropic의 현재 Skill 작성 가이드 역시 SKILL.md를 필수 요소로 두고 scripts, references, assets 같은 리소스를 선택적으로 추가하는 구조를 사용합니다. (GitHub) 쉽게 표현하면 다음과 같습니다. SKILL.md는 업무 매뉴얼이고, references는 참고자료이며, scripts는 반복 작업을 처리하는 도구입니다.

가장 중요한 파일, SKILL.md

간단한 Skill이라면 SKILL.md 하나만으로도 시작할 수 있습니다. 예를 들어 블로그 초안을 일정한 형식으로 작성하는 Skill을 만들어보겠습니다.

---
name: seo-blog-writer
description: SEO를 고려한 한국어 블로그 글을 작성한다. 사용자가 블로그 글, 검색 노출용 콘텐츠, SEO 콘텐츠, 제품 관련 정보성 글을 작성하거나 수정해달라고 요청할 때 사용한다.
---

# SEO Blog Writer

블로그 글을 작성할 때 다음 원칙을 따른다.

- 제목에 핵심 검색어를 자연스럽게 포함한다.
- 첫 부분에서 독자가 궁금해할 문제를 먼저 제시한다.
- H2와 H3 제목을 사용해 내용을 구분한다.
- 키워드를 억지로 반복하지 않는다.
- 전문 용어가 나오면 처음 한 번은 쉽게 설명한다.
- 가능하면 실제 사용 사례를 포함한다.
- 광고 문구보다는 정보 전달을 우선한다.
- 문장은 사람이 직접 작성한 것처럼 자연스럽게 쓴다.

## 기본 구조

1. 문제 제기
2. 개념 설명
3. 실제 사례
4. 장점과 한계
5. 정리

이 정도만 만들어도 하나의 작은 Skill이 됩니다. 여기서 특히 중요한 부분이 있습니다. 바로 description입니다.

Skill에서 description이 중요한 이유

사람이 Skill 목록을 보고 필요한 것을 고르는 것과 달리, Claude는 사용자의 요청과 Skill 설명을 비교해 어떤 Skill이 필요한지 판단합니다. 그래서 다음처럼 작성하면 조금 애매합니다.

description: 블로그를 작성하는 Skill

어떤 상황에서 사용해야 하는지 알기 어렵기 때문입니다. 반면 이렇게 작성하면 훨씬 명확합니다.

description: SEO를 고려한 한국어 블로그 콘텐츠를 작성하거나 수정한다. 사용자가 블로그 글, SEO 콘텐츠, 검색 노출용 글 또는 제품 설명형 콘텐츠 작성을 요청할 때 사용한다.

무엇을 하는지뿐 아니라 언제 사용하는지까지 적어주는 것이 중요합니다. Anthropic의 skill-creator 가이드에서도 description을 Skill 호출 여부를 결정하는 핵심 메커니즘으로 설명하며, 무엇을 하는지와 언제 사용해야 하는지를 함께 작성하도록 권장하고 있습니다. (GitHub)

skill-creator — Skill을 만드는 Skill

여기서 재미있는 도구가 하나 등장합니다. 바로 skill-creator입니다. 이름 그대로,

Skill을 만드는 데 사용하는 Skill

입니다. 직접 처음부터 폴더 구조와 SKILL.md를 설계할 수도 있지만, Skill을 처음 만든다면 skill-creator를 이용해 시작하는 편이 훨씬 이해하기 쉽습니다. Anthropic의 공식 skill-creator는 새로운 Skill 생성뿐 아니라 기존 Skill 수정, 테스트, 성능 평가, 트리거 개선까지 지원하도록 설계되어 있습니다. 현재 공식 가이드에서는 초안을 만든 뒤 실제 테스트 프롬프트를 실행하고 결과를 평가한 다음 다시 Skill을 수정하는 반복 과정을 제안합니다. (GitHub) 예를 들어 이렇게 요청할 수 있습니다.

매주 작성하는 프로젝트 보고서용 Skill을 만들고 싶어.

보고서는 항상 다음 구조를 사용해야 해.

1. 이번 주 진행 상황
2. 완료된 작업
3. 현재 문제
4. 담당자별 할 일
5. 다음 주 계획

보고서는 Markdown으로 만들어줘.

그러면 단순히 프롬프트 하나를 만드는 것이 아니라,

Skill의 목적은 무엇인지
언제 실행해야 하는지
출력 형식은 무엇인지
어떤 예제를 넣는 것이 좋은지
별도 참고자료가 필요한지

같은 부분을 정리하면서 Skill 형태로 발전시킬 수 있습니다.

처음부터 거대한 Skill을 만들 필요는 없다

Skill을 처음 접하면 욕심이 생기기 쉽습니다. 예를 들어 이런 Skill을 만들고 싶어집니다.

회사 업무 전체를 처리하는 Skill

그 안에

보고서 작성
고객지원
번역
블로그
데이터 분석
이메일
코드 리뷰

를 전부 넣으려고 합니다. 하지만 이렇게 만들면 규칙이 복잡해지고, 어떤 상황에서 어떤 지침을 사용해야 하는지도 애매해집니다. 처음에는 작은 것부터 만드는 편이 좋습니다. 예를 들어 평소 다음 문장을 자주 사용한다면,

항상 첫 부분에 핵심 내용을 세 줄로 요약해줘.

이 규칙부터 하나의 작은 업무 흐름으로 발전시켜볼 수 있습니다. 또는

회의록은 항상 결정사항, 담당자, 마감일 순으로 정리해줘.

처럼 반복되는 작업 하나를 선택해도 좋습니다. 자주 복사해서 붙여 넣는 프롬프트가 있다면 그것이 가장 좋은 Skill 후보입니다.

실제 예제 — 회의록 Skill 만들어보기

예를 들어 회의 녹취 내용을 정리하는 일이 많다고 해보겠습니다. 폴더를 하나 만듭니다.

meeting-summary/
└── SKILL.md

그리고 SKILL.md를 작성합니다.

---
name: meeting-summary
description: 회의 내용이나 회의 녹취록을 정리한다. 사용자가 회의록, 미팅 내용, 회의 녹취 또는 회의 요약을 요청할 때 사용한다.
---

# Meeting Summary

회의 내용을 다음 순서로 정리한다.

## 회의 목적

회의가 열린 이유를 2~3문장으로 정리한다.

## 주요 논의

중요한 논의를 주제별로 정리한다.

## 결정 사항

실제로 결정된 내용만 작성한다.

논의 중인 내용과 결정된 내용을 혼동하지 않는다.

## 담당자 및 마감일

| 작업 | 담당자 | 마감일 |
|---|---|---|

담당자나 날짜가 확인되지 않으면 추측하지 않고 `미정`으로 표시한다.

## 남은 문제

추가 논의가 필요한 내용을 작성한다.

## 다음 액션

다음 회의 전에 해야 할 작업을 정리한다.

이제 회의마다 긴 지시를 반복해서 작성할 필요가 줄어듭니다. 입력되는 회의 내용은 매번 달라도 정리하는 방식은 동일하게 유지하는 것이 이 Skill의 목적입니다.

그러면 mcp-builder는 무엇일까?

Skill을 이해했다면 다음으로 자주 등장하는 것이 **MCP(Model Context Protocol)**입니다. 처음에는 Skill과 MCP가 비슷해 보일 수도 있습니다. 하지만 역할은 상당히 다릅니다. 간단한 비유를 사용하면,

Skill은 '어떻게 일할 것인지'를 알려주는 업무 매뉴얼이고, MCP는 AI가 외부 시스템을 사용할 수 있도록 연결해주는 통로에 가깝습니다.

Skill만으로도 문서 정리나 글쓰기 같은 작업은 충분히 처리할 수 있습니다. 하지만 이런 요청은 이야기가 달라집니다.

우리 회사 API에서 이번 달 주문 내역을 가져와서
매출 보고서를 작성해줘.

Claude가 회사 API에 접근할 방법이 없다면 아무리 좋은 Skill을 만들어도 데이터를 가져올 수 없습니다. 이때 MCP가 필요합니다. 구조를 단순화하면 다음과 같습니다.

사용자
   ↓
Claude
   ↓
Skill
"매출 보고서는 이렇게 작성한다"
   ↓
MCP
"회사 시스템에서 필요한 데이터를 가져온다"
   ↓
사내 API / DB / 외부 서비스

즉, Skill은 작업 방법을 정의하고, MCP는 실제 도구와 데이터를 연결합니다.

mcp-builder — Claude와 외부 서비스를 연결하는 방법

Anthropic의 공식 Skills 저장소에는 mcp-builder라는 Skill도 포함되어 있습니다. mcp-builder는 MCP 서버를 설계하고 구현할 때 사용할 수 있는 개발 가이드입니다. 현재 공식 설명에서는 MCP 서버를 통해 LLM이 외부 API나 서비스와 상호작용할 수 있도록 도구를 만들도록 안내하고 있으며, Python과 TypeScript 기반 구현을 다루고 있습니다. (GitHub) 전체 흐름도 비교적 명확합니다.

조사와 설계
    ↓
구현
    ↓
검토와 테스트
    ↓
평가

공식 mcp-builder 역시 현재 크게 연구·계획 → 구현 → 검토·테스트 → 평가 단계로 MCP 서버 구축 과정을 설명합니다. (GitHub)

실제로 언제 MCP가 필요할까?

예를 들어 회사에서 사용하는 사내 프로젝트 관리 API가 있다고 해보겠습니다. API에는 이런 기능이 있습니다.

GET /projects
GET /projects/{id}
GET /tasks
POST /tasks

Claude에게 다음과 같이 요청하고 싶습니다.

현재 진행 중인 프로젝트를 확인하고
마감일이 일주일 이내인 작업만 정리해줘.

이때 MCP 서버가 사내 API를 Claude가 사용할 수 있는 도구 형태로 연결할 수 있습니다. 예를 들어 개념적으로는 다음과 같은 도구가 만들어질 수 있습니다.

list_projects
get_project
list_tasks
create_task

Claude는 필요한 상황에서 이 도구를 이용해 실제 데이터를 조회할 수 있습니다. 그리고 여기에 Skill을 함께 사용하면 한 단계 더 발전시킬 수 있습니다.

Skill과 MCP를 함께 사용하면

예를 들어 project-weekly-report라는 Skill이 있다고 해보겠습니다. Skill에는 이런 규칙이 들어 있습니다.

1. 진행 중인 프로젝트를 확인한다.
2. 이번 주 완료 작업을 정리한다.
3. 지연된 작업을 찾는다.
4. 마감일이 7일 이내인 작업을 표시한다.
5. 프로젝트별 위험 요소를 정리한다.
6. Markdown 보고서를 작성한다.

그리고 MCP에는 다음 도구가 연결되어 있습니다.

list_projects
list_tasks
get_task

사용자는 이제 이렇게만 요청할 수 있습니다.

이번 주 프로젝트 보고서 만들어줘.

그러면 개념적으로는 이런 흐름이 됩니다.

사용자 요청
      ↓
project-weekly-report Skill
      ↓
필요한 데이터 판단
      ↓
MCP 도구 호출
      ↓
사내 프로젝트 API
      ↓
데이터 반환
      ↓
Skill 규칙에 맞춰 보고서 작성

여기서 자동화가 훨씬 재미있어집니다. 단순히 AI에게 글을 작성시키는 단계에서 벗어나, AI가 필요한 데이터를 직접 가져오고, 정해진 업무 절차에 따라 처리하고, 결과까지 만들어주는 구조가 되기 때문입니다.

좋은 Skill에는 몇 가지 공통점이 있다

Skill을 만들다 보면 결국 몇 가지 원칙으로 돌아오게 됩니다.

트리거가 명확해야 한다

description에 언제 사용해야 하는지 분명하게 적어두는 것이 좋습니다.

description: 데이터를 처리한다.

보다는

description: CSV 매출 데이터를 분석하고 월별 매출 보고서를 작성한다. 사용자가 매출 CSV, 월별 매출 분석, 매출 보고서 또는 매출 추세 분석을 요청할 때 사용한다.

처럼 작성하는 편이 낫습니다.

결과가 일정해야 한다

Skill을 사용하는 가장 큰 이유 중 하나는 매번 결과 형식이 바뀌는 문제를 줄이는 것입니다. 표를 사용해야 한다면 표 구조를 정하고, 보고서 순서가 중요하다면 순서를 명시하는 것이 좋습니다.

특정 대화가 아니라 반복 업무를 대상으로 한다

7월 17일 김 과장에게 보낼 보고서 작성

처럼 한 번만 사용하는 업무보다는

주간 프로젝트 보고서 작성

처럼 반복해서 사용할 수 있는 업무가 Skill에 더 잘 맞습니다.

처음에는 작게 시작한다

처음부터 500줄짜리 SKILL.md를 만들 필요는 없습니다. 실제로 반복해서 사용하는 지시 하나를 Skill로 만들고, 사용하면서 필요한 규칙을 조금씩 추가하는 편이 관리하기 쉽습니다.

Skill을 만들었다면 실제로 테스트해보자

Skill 파일을 만들었다고 끝나는 것은 아닙니다. 실제로 비슷한 질문을 여러 번 넣어보는 것이 중요합니다. 예를 들어 회의록 Skill이라면 다음과 같은 테스트를 할 수 있습니다.

테스트 1:
오늘 개발팀 회의 내용을 정리해줘.

테스트 2:
아래 고객 미팅 녹취를 회의록으로 만들어줘.

테스트 3:
이 회의에서 결정된 내용과 담당자만 정리해줘.

확인할 것은 단순합니다.

Skill이 필요한 상황에서 제대로 사용되는가?
출력 구조가 일정한가?
정하지 않은 내용을 AI가 임의로 만들어내지는 않는가?
필요하지 않은 상황에서도 Skill이 실행되지는 않는가?

문제가 발견되면 다시 description이나 지침을 수정합니다. 이런 작성 → 테스트 → 수정 과정이 좋은 Skill을 만드는 데 꽤 중요합니다. 실제로 Anthropic의 현재 skill-creator도 테스트 프롬프트를 만들고, Skill을 적용한 결과와 그렇지 않은 결과를 비교한 뒤 반복적으로 개선하는 과정을 지원합니다. (GitHub)

개인정보는 Skill을 만들어도 따로 생각해야 한다

Skill이 반복 업무를 자동화해준다고 해서 데이터가 자동으로 안전해지는 것은 아닙니다. 특히 MCP를 사용한다면 더 주의해야 합니다. MCP가 외부 API나 서비스에 연결되어 있다면 작업 과정에서 데이터가 해당 시스템으로 전달될 수 있기 때문입니다. 따라서 다음 세 가지는 별도로 생각하는 것이 좋습니다. Skill

AI가 어떤 방식으로 일할 것인가?

MCP

AI가 어떤 외부 시스템에 접근할 수 있는가?

데이터 처리 위치

내 파일과 데이터가 실제로 어디에서 처리되는가?

이 세 가지는 서로 다른 문제입니다. 예를 들어 공개된 블로그 초안이나 일반 문서는 클라우드 AI와 Skills를 활용해 처리하고, 회사 계약서나 의료 문서처럼 외부 전송이 부담스러운 파일은 가능한 경우 브라우저나 PC 안에서 처리하는 방식으로 업무를 나눌 수도 있습니다. 중요한 것은 Skill을 사용한다는 이유만으로 개인정보 보호가 해결된다고 생각하지 않는 것입니다.

Skill과 MCP, 어떻게 구분하면 될까?

처음에는 아래처럼 생각하면 가장 쉽습니다.

하고 싶은 일	적합한 방법
항상 같은 형식으로 보고서 작성	Skill
같은 기준으로 문서 검토	Skill
회사 문체로 콘텐츠 작성	Skill
반복적인 코드 리뷰 기준 적용	Skill
사내 API에서 데이터 조회	MCP
외부 서비스에 작업 생성	MCP
DB에서 데이터를 가져와 보고서 작성	MCP + Skill
프로젝트 데이터를 조회하고 정해진 형식으로 주간 보고서 작성	MCP + Skill

한 문장으로 정리하면,

Skill은 Claude에게 '일하는 방법'을 가르치고, MCP는 Claude에게 '사용할 수 있는 도구'를 연결합니다.

가장 좋은 시작 방법

처음부터 MCP 서버를 만들고 복잡한 자동화 시스템을 설계할 필요는 없습니다. 오히려 평소 AI를 사용할 때 자신이 반복해서 입력하는 문장을 찾아보는 것이 먼저입니다. 예를 들어 이런 문장이 있을 수 있습니다.

항상 Markdown으로 작성해줘.

회의록에서는 결정사항과 논의사항을 구분해줘.

C# 코드를 리뷰할 때 async/await와 IDisposable부터 확인해줘.

블로그 글은 너무 광고처럼 쓰지 말고 실제 사례를 넣어줘.

이 중 하나만 골라 작은 Skill을 만들어보세요. 사용하다 보면 자연스럽게 규칙이 추가됩니다. 그리고 언젠가 이런 요구가 생길 수 있습니다.

"이제 우리 회사 시스템에서 데이터도 직접 가져오게 하고 싶은데?"

그때 MCP를 연결하면 됩니다. 순서는 그 정도면 충분합니다.

반복 프롬프트 발견
        ↓
작은 Skill 만들기
        ↓
몇 번 사용해보기
        ↓
규칙 개선
        ↓
필요하면 MCP 연결
        ↓
실제 업무 자동화

결국 시작점은 '반복되는 설명'이다

Claude Skills를 거창한 AI 개발 기술로 생각할 필요는 없습니다. 출발점은 아주 단순합니다. "내가 AI에게 계속 똑같은 설명을 하고 있지는 않은가?" 그렇다면 이미 Skill로 만들 수 있는 재료를 가지고 있는 셈입니다. 반복하던 지시를 SKILL.md에 정리하고, 필요한 참고자료를 붙이고, 반복적인 계산이 있다면 스크립트를 추가합니다. 그리고 외부 시스템의 실제 데이터나 기능이 필요해지는 순간 MCP를 연결할 수 있습니다. Skill은 AI에게 우리의 일하는 방식을 알려주고, MCP는 AI에게 실제로 일을 수행할 도구를 제공합니다. 두 가지를 함께 사용하면 AI는 단순히 질문에 답하는 도구에서 조금씩 벗어나, 정해진 업무 절차를 따라 실제 작업을 수행하는 도구에 가까워집니다. 다만 처음부터 큰 자동화를 만들 필요는 없습니다. 오늘 Claude에게 세 번째로 복사해서 붙여 넣은 문장이 있다면, 그 문장부터 첫 번째 Skill로 만들어보는 것이 가장 좋은 시작일 수 있습니다. 위 글은 Anthropic의 현재 공식 anthropics/skills 저장소와 skill-creator, mcp-builder 내용을 확인한 뒤, 원문의 일부 표현도 현재 구조에 맞게 보정했습니다. (GitHub) 스킬이 반복 작업을 자동화하듯, 민감한 파일은 온디바이스로 처리하는 것도 습관으로 만드세요. 공개 텍스트 작업은 클라우드 AI+스킬로, 민감한 문서는 브라우저에서.

FileKeeps의 AI 파일 분석은 문서를 서버로 보내지 않고 브라우저에서 처리합니다 — 민감한 문서의 기본값으로 삼으세요.