안녕하세요. 서비스에 필요한 AI 모델과 솔루션을 개발하는 AI Lab 팀의 한길로입니다. 저는 최근에 LY Corporation에서 사내 행사로 진행한 Orchestration Development Workshop에서 ‘MCP와 에이전트 스킬의 이해’라는 주제로 강사로 활동했습니다. 이번 글에서는 해당 워크숍 내용을 예제를 조금 더 보충해 공유하려고 합니다.
들어가며
요즘 AI 에이전트 개발 현장을 둘러보면, MCP(model context protocol) 서버 구축에서 에이전트 스킬 기반으로 개발 방향을 선회하는 추세입니다. 실제로 에이전트 스킬을 적용해 보면 확실히 구현이 간편하고, 아키텍처도 훨씬 간단하다는 것을 체감할 수 있죠. 이런 장점을 인지한 많은 사용자가 이미 스킬을 적극적으로 활용하고 있습니다.
인터넷에 '에이전트 스킬’을 검색해 보면 기본 개념을 설명하는 내용이나 거창하게 만들어 놓은 GitHub 예제들을 쉽게 찾을 수 있습니다. 하지만 ‘그래서 이걸 내 일상이나 실무에서 어떻게 써야 하지?’라는 의문을 지워줄 만한 실용적이고 친절한 가이드는 잘 보이지 않더군요.
그래서 이번 포스팅에서는 스킬을 자세히 모르는 분들도 실생활에 바로 써먹을 수 있는 예제를 같이 만들어 보며 스킬 활용법을 배워보려고 합니다. 이번 글에서 스킬의 개념 설명 및 자세한 사용법은 다루지 않으니 참고해 주시기 바랍니다.
예제: Git 스마트 릴리스 자동화 스킬 구축하기
제가 준비한 예제는 개발자 실무에 실제로 도움이 될만한 ‘Git 스마트 릴리스 자동화’ 스킬입니다. 이 스킬을 함께 만들어 보려고 합니다.
이 작업을 처음부터 하나하나 코딩하려면 꽤나 번거롭습니다. 그래서 저는 Anthropic에서 공식 제공하는 skill-creator 스킬을 적극 활용할 생각입니다. 말 그대로 '스킬을 만들어주는 스킬'을 이용해 릴리스 자동화 스킬을 손쉽게 찍어내는 구조입니다.
먼저 제가 에이전트에게 구현을 요청하면서 전달할 요구 사항을 정리해 보겠습니다. 이 내용을 그대로 skill-creator에게 프롬프트로 던질 예정입니다.
Git 스마트 릴리스 자동화 스킬 요구 사항 명세
[목표] skill-creator를 사용하여 현재 디렉토리의 Git 프로젝트를 자동으로 릴리스하는 스킬을 구축해 줘.
[기능 요구 사항]
Git 로그 분석: 현재 폴더에서 git log를 읽어 가장 최근 태그(예: v0.1.0) 이후의 변경 사항을 가져옴.
Changelog 업데이트: 추출한 변경 사항을 요약하여 CHANGELOG.md 파일 최상단에 추가함(파일이 존재하지 않으면 새로 생성할 것).
버전 범프(Version Bump): pyproject.toml 파일 내 version = "..." 부분을 탐색해 버전을 patch 단계로 한 단계 올림 (예: 0.1.0 -> 0.1.1).
Commit & Tagging: 변경된 파일들(CHANGELOG.md, pyproject.toml)을 git add 처리하고, chore: release v[새 버전] 메시지로 커밋한 뒤, 마지막으로 git tag v[새 버전]을 생성함.
[핵심 제약 조건]
이 스킬은 반드시 현재 터미널의 실행 경로(pwd)를 기반으로 작동하는 로컬 파이썬 스크립트 형태로 구성해야 함.
위와 같이 핵심 조건과 워크플로를 명확하게 잡아둬야 에이전트가 엉뚱한 디렉터리를 건드리거 나 불필요하게 복잡한 계획을 세우는 것을 원천 차단할 수 있습니다.
그럼 이 프롬프트를 입력했을 때 스킬이 어떻게 완성되고 실제로 어떻게 작동하는지 구체적으로 파헤쳐 보겠습니다. 진행은 Claude Code로 합니다.
Git 스마트 릴리스 자동화 Skill 요구 사항 명세
[목표] skill-creator를 사용하여 현재 디렉토리의 Git 프로젝트를 자동으로 릴리스하는 스킬을 구축해 줘.
[기능 요구 사항]
Git 로그 분석: 현재 폴더에서 git log를 읽어 가장 최근 태그(예: v0.1.0) 이후의 변경 사항을 가져옴.
Changelog 업데이트: 추출한 변경 사항을 요약하여 CHANGELOG.md 파일 최상단에 추가함(파일이 존재하지 않으면 새로 생성할 것).
버전 범프(Version Bump): pyproject.toml 파일 내 version = "..." 부분을 탐색해 버전을 patch 단계로 한 단계 올림 (예: 0.1.0 -> 0.1.1).
Commit & Tagging: 변경된 파일들(CHANGELOG.md, pyproject.toml)을 git add 처리하고, chore: release v[새 버전] 메시지로 커밋한 뒤, 마지막으로 git tag v[새 버전]을 생성함.
[핵심 제약 조건]
이 스킬은 반드시 현재 터미널의 실행 경로(pwd)를 기반으로 작동하는 로컬 파이썬 스크립트 형태로 구성해야 함.
⏺ Git 스마트 릴리스 자동화 Skill을 만들어드리겠습니다. skill-creator를 사용하겠습니다.
⏺ Skill(skill-creator)
⎿ Successfully loaded skill
⏺ git-smart-release Skill 생성을 도와드릴게요! 이 Skill이 원하시는 대로 정확하게 작동하는지 확인하기 위해 몇 가지 내용을 먼저 명확히 짚고 넘어가겠습니다.
요구사항 이해
알려주신 사양을 바탕으로 다음 내용을 확인했습니다:
✅ 마지막 태그(예: v0.1.0) 이후의 git log 분석
✅ CHANGELOG.md 최상단 업데이트 또는 생성
✅ pyproject.toml의 패치(patch) 버전 올리기
✅ "chore: release v[version]" 메시지로 변경사항 커밋
✅ git 태그 생성
✅ 현재 디렉토리(pwd)에서 작동 필수
만약 요구 사항이 명확하지 않으면 LLM의 질문을 통해 요구 사항을 더 명확하게 요청합시다.
몇 가지 질문이 있습니다:
1.버전 관리의 유연성: 항상 패치 버전만 올려야 하나요(0.1.0 → 0.1.1), 아니면 마이너/메이저 버전업도 지원해야 하나요? (예를 들어, 사용자가 "마이너 릴리스해 줘"라고 요청하면 0.1.0 → 0.2.0으로 변경되도록 할까요?)
2.초기 릴리스: 이전 태그가 없는 경우(최초 릴리스) 어떻게 처리할까요? 기본값을 v0.1.0으로 할까요, 아니면 v1.0.0으로 할까요?
3.CHANGELOG 형식: 체인지로그 항목은 어떤 형식을 선호하시나요? 다음과 같은 형식은 어떠신가요?
[0.1.1] - 2026-03-15
feat: Added new feature X
fix: Fixed bug Y
docs: Updated documentation
4.Git 푸시: 이 Skill이 커밋과 태그를 원격 저장소(remote)에 푸시까지 진행해야 하나요, 아니면 로컬에서 생성만 하면 될까요?
5.예외 처리: 먼저 커밋되지 않은 변경 사항이 있는지 확인하고, 작업 디렉토리가 정리되지 않은 상태(dirty)라면 경고를 띄우거나 작업을 취소(fail)하도록 할까요?
1. 모든 버전업에 대해 지원해줘
2. v0.1.0으로 시작해줘
3. 그대로 해줘
4. 원격 저장소까지 해줘
5. 작업을 취소 하고 설명을 곁들여줘
요구 사항이 명확해지면 이제 스킬을 만듭니다.
⏺ 완벽합니다! 요구사항을 정리하면:
1. ✅ Patch/Minor/Major 모두 지원
2. ✅ 첫 릴리스는 v0.1.0
3. ✅ CHANGELOG 형식 유지
4. ✅ 원격 저장소까지 push
5. ✅ Dirty working directory 체크 → 중단 + 설명
이제 Skill을 만들겠습니다!
⏺ 좋습니다! git-smart-release Skill 생성을 완료했습니다. 제가 구성한 내용은 다음과 같습니다:
📦 Skill 구조
git-smart-release/
├── SKILL.md # Skill 정의 및 안내
├── scripts/
│ └── smart_release.py # Python 자동화 스크립트
└── evals/
└── evals.json # 테스트 케이스
✨ 구현된 기능
이 Skill은 이제 다음 기능들을 지원합니다:
✅ 모든 버전 유형 지원: 패치(patch), 마이너(minor), 메이저(major) (사용자가 선택)
✅ 최초 릴리스: v0.1.0으로 시작
✅ CHANGELOG.md: 'Keep a Changelog' 표준 형식으로 자동 생성 및 업데이트
✅ 작업 디렉토리 검사 (Dirty check): 커밋되지 않은 변경사항이 있으면 중단하고 이유를 설명
✅ 원격 푸시 (Remote push): 커밋과 태그를 원격 저장소까지 자동으로 푸시
✅ 스마트 커밋 분류: feat, fix, docs 등으로 자동 분류
제작된 스킬을 실행해 보기 전에 가볍게 한 번 둘러보겠습니다. Git-smart-release 폴더로 가서 SKILL.md 파일을 열어봅니다.
# SKILL.md
이 파일은 크게 ‘프런트매터’와 ‘마크다운 본문’으로 나눌 수 있습니다.
- 프런트매터(frontmatter): YAML 형식의 메타데이터. 에이전트가 이 스킬을 언제, 왜 꺼내 써야 하는지 판단하기 위해 항상 간단하게(약 100 토큰) 메모리에 올려두는 스킬의 핵심 명함이자 검색 지표입니다(스킬 2.0부터는 여러 새로운 기능을 이 프런트매터에 정의할 수 있습니다).
- 마크다운 본문(Markdown body): 에이전트가 프런트매터를 보고 스킬을 사용하기로 결정한 경우에만 읽습니다. ‘어떻게’ 작업해야 하는지 구체적인 절차를 지시하는 '실행 매뉴얼(절차 및 워크플로)'입니다.
다음으로 scripts 폴더로 가 smart_release.py 파일을 열어보겠습니다.
# scripts / smart_release.py
이 파일은 로컬 환경에서 복잡한 연산(Git 제어, 파일 수정)을 다이렉트로 처리해 주는 '행동 대장(실행 스크립트)'입니다. LLM이 직접 데이터를 읽고 쓰며 토큰을 낭비하지 않게 해줍니다.
저희가 만든 Git 스마트 릴리스 스킬은 이제 SKILL.md에 써있는 지침대로 사용자의 요청을 수행하면서 필요할 때 smart_release.py 스크립트를 활용할 것입니다.
시나리오: Python 계산기 프로젝트
저희가 만든 스킬을 테스트할 아주 간단한 Python 계산기 프로젝트를 하나 세팅해 보았습니다. 프로젝트 구조는 다음과 같습니다.
프로젝트 스펙과 현재 상태는 테스트의 목적에 맞게 아주 단순하게 구성했습니다.
- 핵심 로직(
calculator.py): 오직 더하기(add)와 빼기(subtract) 기능만 구현한 초간단 Python 모듈입니다. - 패키지 설정(
pyproject.toml): 프로젝트의 메타데이터가 들어있으며 현재 버전은 ‘version = "0.1.0"’ 형식으로 명시합니다. - 현재 Git 상태: 이 프로젝트는 초기 세팅 후 ‘
v0.1.0’으로 태깅해 커밋 및 푸시까지 완료된 상태입니다. 즉, 기준점이 되는 과거의 릴리스 내역이 이미 존재하는 셈이죠.
이제 지금까지 설정하고 구성한 게 잘 작동하는지 검증해 보겠습니다. 검증 시나리오는 이렇습니다. calculator.py에 간단한 곱하기(multiply) 기능을 추가하고 작업을 마칠 예정입니다. 그런 다음 에이전트가 앞서 세팅한 'Git 스마트 릴리스 스킬'을 호출하도록 만들 것입니다. 에이전트가 아래 과정을 잘 수행하는지 함께 확인해 보겠습니다.
v0.1.0이후의 변경 사항('곱하기 추가')을 정확히 찾아내기CHANGELOG.md를 작성하기pyproject.toml의 버전을0.2.0(의도적으로 마이너 버전으로 올림)로 올리고 커밋/태깅하기
곱하기 기능을 추가하기 전 calculator.py는 다음과 같습니다.
# calculator.py
def add(a, b):
return a + b
def subtract(a, b):
return a - b
if __name__ == "__main__":
print(f"2 + 3 = {add(2, 3)}")
여기에 다음과 같이 '곱셈' 기능을 추가합니다.
def add(a, b):
return a + b
def subtract(a, b):
return a - b
def multiply(a, b):
return a * b
if __name__ == "__main__":
print(f"2 + 3 = {add(2, 3)}")
추가 후 커밋하겠습니다.
python-calculator % git commit -m "feat: 곱하기 기능 추가"
[main f8148cb] feat: 곱하기 기능 추가
1 file changed, 3 insertions(+)
이제 배포하겠습니다. Claude Code에서 "현재 프로젝트의 새 버전 배포를 진행해줘."라고 요청합니다. 다음은 제가 실행했을 때 받은 실행 결과입니다.
⏺ 🎉 릴리스 v0.2.0 완료!
git-smart-release Skill이 다음 작업들을 자동으로 수행했습니다:
📋 실행된 프로세스
1. 사전 검증
- Working directory가 깨끗한지 확인
- 현재 버전 확인 (v0.1.0)
2. CHANGELOG.md 생성 ✨
- 마지막 태그(v0.1.0) 이후의 커밋 분석:
- feat: 곱하기 기능 추가
- chore: add .gitignore for Python project
- 커밋을 기반으로 자동으로 변경 로그 작성
- Features와 Chores 섹션으로 구분
3. pyproject.toml 버전 업데이트
- version = "0.1.0" → version = "0.2.0" (minor 버전 업)
4. Git 커밋 생성
- 커밋 메시지: chore: release v0.2.0
- 변경된 파일: CHANGELOG.md, pyproject.toml
5. Git 태그 생성
- 새 태그: v0.2.0
6. 원격 저장소 동기화
- 원격 변경사항 rebase (3개 커밋 처리)
- 커밋과 태그를 원격 저장소에 푸시
📊 최종 상태
태그 목록:
- v0.1.0 (초기 릴리스)
- v0.2.0 (현재 릴리스) ← NEW!
커밋 히스토리:
312a774 (HEAD → main, tag: v0.2.0) chore: release v0.2.0
ba3525c chore: add .gitignore for Python project
58710a5 feat: 곱하기 기능 추가
b74ac36 Create README.md
299bf56 (tag: v0.1.0) feat: 초기 계산기 구현 (더하기, 빼기)
모든 변경사항이 원격 저장소에 푸시되었습니다! 🚀
모든 과정을 훌륭하게 진행했다고 하는데 과연 요구 사항대로 처리했는지 CHANGELOG.md와 project.toml을 확인해 보겠습니다.
# CHANGELOG.md
Changelog
All notable changes to this project will be documented in this file.
[0.2.0] - 2026-03-15
Features
곱하기 기능 추가
Chores
add .gitignore for Python project
# pyproject.toml
[project]
name = "python-calculator"
version = "0.2.0"
description = "A simple calculator for testing release automation"
확인 결과 잘 처리해 놓았습니다. 앞서 만들어 놓은 'Git 스마트 릴리스 스킬' 덕분에 번거로운 배포를 자동화해서 한 사이클을 성공적으로 마칠 수 있었습니다. 에이전트는 앞서 정의해 놓은 절차를 정확하게 밟아나갔습니다.
- Git 로그 분석: 현재 폴더에서 최근 태그 이후의 커밋 내역을 로딩
- Changelog 업데이트: 추출한 변경 사항을 요약해
CHANGELOG.md최상단에 알아서 추가 - 버전 범프:
pyproject.toml을 읽어 major/minor/patch 버전을 한 단계(0.1.0->0.2.0) 올림 - 커밋과 태깅: 변경된 파일을
git add하고,chore: release v[새 버전]커밋과 태깅 마무리
여기서 주목할 만한 점은, 에이전트가 단순히 기계적으로 스크립트만 실행하고 끝낸 것이 아니라는 것입니다. AI는 정해진 워크플로를 수행하는 도중 추가 조치나 예외 처리가 필요하다고 판단하면 우리에게 다음 행동을 제안하기까지 합니다. LLM의 유연함과 스크립트의 엄격함이 결합해 최고의 시너지를 냅니다.
물론, 누군가는 이렇게 반문할 수 있습니다.
"사실 굳이 스킬을 안 만들고 이 모든 과정을 그냥 긴 프롬프트를 만들어서 채팅창에 그때그때 입력해 시켜도 되는 것 아닌가요?”
네, 맞습니다. 단순히 결과만 놓고 본다면 충분히 가능합니다. 다만 같은 작업을 실제 운영 환경에서 여러 번 반복해야 하는 실무 관점에서 생각해 볼 필요가 있습니다. 여러 단계의 복잡한 절차를 거쳐야 하는 작업의 경우 작업자가 매번 프롬프트 내용을 잊거나 빼먹지 않고 완벽하게 입력할 것이라 기대하는 것 자체가 리스크이자 비효율입니다.
팀 단위로 반드시 지켜야 하는 엄격한 룰이나 반복 워크플로가 있다면, 이를 '스킬'이라는 표준화 모듈로 만들어 배포해서, 작업자의 컨디션이나 프롬프트 작성 역량에 의존하지 않고 누가 언제 실행하든 항상 일관적으로 좋은 품질의 결과물을 보장할 수 있습니다.
비교 분석: MCP로 동일한 작업을 수행해 본다면?
자, 이제 똑같은 과정을 MCP 환경에서 다시 수행해 보겠습니다. 이번에는 계산기 프로젝트에 나누기(divide)와 모드(mod) 기능을 추가한 뒤 미리 구축해 놓은 git-release-mcp 서버를 호출해 새 버전 배포를 요청해 보겠습니다(mcp-builder를 통해 서버를 구축하는 상세 과정은 생략합니다).
먼저 다음과 같이 나누기와 모드 기능을 추가합니다.
# calculator.py
def add(a, b):
return a + b
def subtract(a, b):
return a - b
def multiply(a, b):
return a * b
def divide(a, b):
return a / b
def mod(a, b):
return a % b
if __name__ == "__main__":
print(f"2 + 3 = {add(2, 3)}")
추가후 다음과 같이 커밋합니다.
python-calculator % git add calculator.py
python-calculator % git commit -m "feat: 나누기, 모드 기능 추가"
[main 96e32f8] feat: 나누기, 모드 기능 추가
1 file changed, 3 insertions(+)
다시 배포해 보겠습니다.
git-release-mcp 서버를 이용해서 현재 프로젝트의 새 버전 배포를 진행해줘.
⏺ git-release-mcp 서버를 이용해서 새 버전 배포를 진행하겠습니다. 먼저 마지막 릴리스 이후의 변경사항을 분석해보겠습니다.
⏺ git-release - Analyze Git Commits Since Last Tag (MCP)(params: {})
⎿ {
"result": "# Git Commit Analysis\n\n**Current Tag:** v0.2.0\n**Total Commits:** 1\n\n**Suggested Version Bump:** minor (new
features added)\n\n---\n\n## Features\n\n- feat: 나누기, 모드 기능 추가\n"
}
⏺ 📊 커밋 분석 결과
좋은 소식입니다! 마지막 릴리스 이후 새로운 변경사항이 있습니다.
- 현재 Git 태그: v0.2.0
- 마지막 태그 이후 커밋: 1개
- 권장 버전 타입: minor (새 기능 추가)
변경사항:
- Features (기능 추가) 🎉
- 나누기, 모드 기능 추가
---
⏺ Read 1 file (ctrl+o to expand)
⏺ 현재 버전은 0.2.0입니다. 새로운 기능이 추가되었으므로 **minor 버전(0.3.0)**으로 릴리스를 진행하겠습니다.
⏺ git-release - Create Git Release with Version Bump (MCP)(params: {"version_type":"minor","working_directory":"/Users/kilro.han/works
pace/python-calculator"})
⎿ {
"result": "# 🎉 Release Successful!\n\n**Version:** v0.2.0 → v0.3.0\n**Version Type:** minor\n\n## Files Modified\n\n- ✓ CH
ANGELOG.md (updated with new entries)\n- ✓ pyproject.toml (version bumped to 0.3.0)\n\n## Git Operations\n\n- ✓ Created commi
… +3 lines (ctrl+o to expand)
⏺ 🎉 릴리스 성공!
git-release-mcp 서버를 통해 v0.2.0 버전이 성공적으로 생성되었습니다!
📊 릴리스 요약
┌─────────────┬──────────────────────┐
│ 항목 │ 내용 │
├─────────────┼──────────────────────┤
│ 이전 버전 │ v0.2.0 │
├─────────────┼──────────────────────┤
│ 새 버전 │ v0.3.0 │
├─────────────┼──────────────────────┤
│ 버전 타입 │ minor (새 기능 추가) │
├─────────────┼──────────────────────┤
│ 릴리스 날짜 │ 2026-03-16 │
└─────────────┴──────────────────────┘
✅ 자동으로 수행된 작업들
1. ✓ pyproject.toml 업데이트
- 버전: 0.2.0 → 0.3.0
2. ✓ CHANGELOG.md 업데이트
- 새로운 섹션 추가: [0.3.0] - 2026-03-16
- 변경사항 자동 분류 및 기록
3. ✓ Git 커밋 생성
- 커밋 메시지: chore: release v0.3.0
4. ✓ Git 태그 생성
- 태그: v0.3.0
📝 이번 릴리스의 변경사항
Features (새 기능)
- ✨ 나누기, 모드 기능 추가
위와 같이 MCP 서버를 이용하는 방식으로도 아주 잘 배포됐습니다. 하지만 로그를 꼼꼼히 뜯어보면 스킬을 이용한 방식과 결정적으로 다른 점이 보입니다. 로그 곳곳에 나타난 ‘⏺ git-release - ‘라는 항목은 LLM이 MCP 서버와 직접 요청과 응답을 주고받는 과정입니다. 즉 LLM이 'Git 로그 분석 → Changelog 업데이트 → 버전 범프 → 커밋/태깅'이라는 4단계 절차를 수행하기 위해 매 단계마다 MCP 서버를 호출하고 결과를 받아 스스로 다음 행동을 판단하고 있는 것입니다. 반면 앞서 살펴본 스킬을 이용한 방식에서는 이를 로컬 스크립트를 이용해 직접 처리합니다.
MCP 서버 방식에는 매 단계마다 LLM 판단이 개입하는 방식은 잠재적인 위험과 단점이 있습니다.
- 과도한 권한(over-privileged): LLM이 매번 툴을 자율적으로 조합하다 보니 원치 않게 위험하게 작동하거나 접근하면 안 되는 데이터에 접근할 위험이 있습니다.
- 중간 결과의 이중 통과(double pass): 대용량의 중간 결과물(예: 전체 커밋 로그)이 계속해서 LLM과 MCP 서버 사이를 오가야 하므로 불필요하게 토큰 비용이 늘어납니다.
스킬은 절차 관련 지식을 내재화해 이러한 권한 남용과 이중 통과 문제를 아주 간단하고 우아하게 해결해 줍니다.
그렇다면 모든 것을 스킬로 만들어야 할까?
여기까지 오면 이런 생각이 들 수 있습니다.
"아, 그럼 MCP 대신 전부 다 스킬로 만들어 쓰면 완벽하겠네?"
결론부터 말씀드리면 꼭 그렇지는 않습니다. 제 경험에 비춰봐도 그렇고 많은 전문가 또한 입을 모아 ‘MCP와 스킬은 경쟁 관계가 아니라 상호 보완 관계’라고 말합니다. 모든 기능을 하나의 스킬 내부에 하드코딩해 서 욱여넣으면 끔찍한 유지 보수 지옥에 빠집니다. 새로운 플랫폼을 연동할 때마다 스크립트를 뜯어고쳐야 하기 때문이죠. 이는 MCP가 제공하는 훌륭한 '확장성'을 스스로 버리는 꼴입니다.
가장 이상적인 아키텍처는 이 둘의 역할을 다음과 같이 명확히 구분하는 것입니다.
- MCP: 외부 시스템(데이터베이스, API, 파일 등)과의 연결을 담당하는 인프라로, LLM을 외부 시스템과 쉽고 유연하게 연결할 수 있게 만드는 역할
- 스킬: 복잡한 작업 단계를 정의하고 비즈니스 로직을 적용하는 워크플로로, 여러 작업을 자동화하거나 오케스트레이션할 수 있도록 만드는 역할
한 줄로 요약하자면, MCP는 데이터가 달릴 수 있는 '튼튼한 고속도로'를 까는 것이고, 스킬은 그 도로 위에서 목적지까지 안전하고 효율적으로 달리는 '똑똑한 자율 주행 트럭 소프트웨어'라고 할 수 있습니다.
마지막으로 실무 도입 전 반드시 알아야 할 주의 사항
마지막으로 현재 시점에서 실무에 스킬을 도입하고자 할 때 반드시 알고 있어야 할 주의 사항을 말씀드리겠습니다.
앞으로 Anthropic이나 오픈소스 진영에서 이 아키텍처를 어떻게 더 개선하고 발전시킬지 지켜봐야 하겠지만, 현재 에이전트 스킬 생태계는 Claude Code와 같은 'CLI 기반 코딩 에이전트' 나 'Claude Desktop' 같은 앱에서 최적으로 작동하도록 설계돼 있습니다. 따라서 현재로서는 스킬을 무리하게 MCP 서버처럼 범용 서버 환경에서 구현하려고 하면 반쪽짜리 구현에 머물 확률이 높습니다.
또한 현재 스킬 기능을 공식 지원하는 SDK는 Anthropic SDK가 유일하며, 이마저도 사용자가 로컬에 만든 스킬 파일 전체를 묶어서 클라우드 로 전송한 뒤 가상 공간을 생성해 실행하는 방식입니다. 즉, 의도치 않게 막대한 토큰을 낭비할 수 있는 구조입니다.
이 글에서 공유한 특성과 장단점을 정확히 이해하고 여러분의 업무에 맞는 스킬을 잘 구축하면 분명 눈에 띄게 생산성이 향상되는 것을 경험할 수 있을 것입니다. 더욱 많은 분들이 이와 같은 경험을 하기를 바라며 이만 마치겠습니다.
