서론

Claude를 확장하는 방법으로 최근 자주 거론되는 것이 「Skills」와 「MCP (Model Context Protocol)」입니다. 둘 다 「Claude가 할 수 있는 일을 늘리기」 위한 메커니즘이지만, 그 정체는 완전히 다릅니다.

한마디로 말하자면, Skills는 레시피이며, MCP는 주방입니다.

이 기사에서는 이 두 가지의 차이점을, 실제로 Skill을 몇 가지 시도해 본 경험과 MCP 서버 구축 경험을 바탕으로 정리합니다.

Skills란 무엇인가

Skills는 지시·스크립트·참고 자료를 모아둔 폴더로, Claude가 대화 내용에 따라 동적으로 읽어들이는 것입니다. 내용은 SKILL.md라는 Markdown 파일이 중심이며, 「이런 의뢰가 오면, 이런 절차로 대응한다」라는 절차서가 작성되어 있습니다.

중요한 점은, Skills는 Claude에게 새로운 능력을 추가하는 것이 아니라는 점입니다. Claude가 원래 가지고 있는 능력인

• 파일을 읽기
• 코드를 실행하기
• 웹을 검색하기
• 파일을 생성하기

등의 「사용 방식의 스타일」을 가르쳐줄 뿐입니다. 새로운 연결이나 외부 시스템과의 통신 수단이 늘어나는 것은 아닙니다.

예를 들어, 독자적인 포맷으로 슬라이드를 생성하는 Skill을 생각해 봅시다. 「단일 HTML 파일에 JSON 형식으로 슬라이드를 삽입한다」라는 독자적인 포맷의 취급법을 가르치는 Skill이 있다고 가정합니다. 그 내용을 읽어보면, 최신 템플릿을 어디에서 다운로드할지, JSON의 어느 부분을 어떻게 편집할지, 생성 후에 브라우저에서 무엇을 확인해야 할지 등의 절차가 상세히 적혀 있을 것입니다. 하지만 이것들은 전부 Claude가 원래 가지고 있는 「파일을 다운로드한다」, 「파일을 편집한다」, 「브라우저에서 확인한다」라는 능력의 조합에 불과합니다.

Progressive Disclosure (단계적 개시)라는 설계

Skills가 뛰어난 점은 필요할 때만 읽혀진다는 설계입니다. 이는 3단계로 구성되어 있습니다.

• 상시: Skill의 이름과 한 줄 설명 (description)만이, 말하자면 목차로서 항상 곁에 있습니다.
• 발동 시: 대화 내용이 해당 설명과 일치한다고 판단되면, SKILL.md 본체가 그 자리에서 읽혀집니다.
• 필요할 때만: 본체 안에서 추가로 참조되는 상세 파일이나 스크립트는, 정말로 필요해진 순간에만 읽혀집니다.

이를 통해 사용하지 않는 Skill은 대화의 컨텍스트 (Context)를 거의 소비하지 않습니다. 일반적인 시스템 프롬프트 (System Prompt)처럼 「상시 존재하며 자리를 차지하는」 것이 아니라, 「필요할 때만 끼워 넣는, 사용법 매뉴얼의 추가 페이지」라는 이미지가 가깝습니다.

Skills 만드는 법 (최소 구성)

frontmatter에 필수적인 것은 name과 description 두 가지뿐입니다.

---
name: pdf-processing
description: Extracts text and tables from PDF files, fills forms, and merges documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.
...

description은 3인칭·구체적인 키워드를 포함하는 형태로 쓰는 것이 요령이며, 이 설명문만 보고 Claude가 「지금 이 Skill을 사용해야 하는가」를 판단합니다. 규모가 커지면 scripts/ (실행용 스크립트)나 reference/ (상세 문서)와 같은 하위 폴더로 분할해 나갑니다.

Skills 입수·등록 방법

까다로운 점은, 똑같은 「Skill 설치」라도 사용하는 장소에 따라 올바른 방법이 다르다는 점입니다.

• Claude Code (CLI): ~/.claude/skills/

와 같은 로컬 폴더에 파일을 직접 두는 것만으로 인식됩니다. -
Claude.ai / Claude Desktop (채팅·Cowork): 로컬 폴더에 두어도 인식되지 않습니다. zip 파일을 다운로드하여 설정 화면의 Settings → Skills에서 업로드해야 합니다. 이를 통해 계정(조직) 단위의 Skills 카탈로그에 등록되며, 채팅이든 Cowork이든 어디서나 호출할 수 있게 됩니다.

이 차이를 인지하지 못하고 Claude Code용 절차를 Claude Desktop에 사용했다가, 한동안 작동하지 않아 시행착오를 겪은 실제 경험이 있습니다.

MCP란 무엇인가

**외부 도구(Tool)나 데이터 소스(Data Source)에 연결하기 위한 공통 프로토콜 (Common Protocol)**입니다. 인증, 연결 유지, 구조화된 통신 주고받기를 표준화하는 메커니즘으로, 말하자면 Claude에게 새로운 "손과 발"을 부여하는 것입니다.

생성형 AI 계열의 OSS 플랫폼에서 Bedrock을 경유한 도구 호출(Tool Calling)이나 DB 연결을 구축해 본 경험이 있는 분이라면, 이 계층의 감각은 이미 익숙할 것입니다. MCP 서버는 Salesforce와 같은 복잡한 외부 시스템과의 통합, OAuth 2.0이나 SAML, 엔터프라이즈 SSO와 같은 복잡한 인증, 빈번한 호출이 필요한 성능 중시 상황에서 진가를 발휘합니다.

중요한 점은, MCP가 반드시 "클라우드 상의 먼 API"일 필요는 없다는 것입니다. 로컬 PC 상에서 stdio를 경유하는 작은 MCP 서버를 띄워 그곳에 접속하는 케이스도 있습니다. 핵심은 "네트워크를 거치느냐 아니냐"가 아니라, Claude 스스로 내부에 정보를 보유하느냐, 매번 별도의 시스템에 문의하느냐의 차이입니다.

목록으로 비교하기

조합해서 사용하기

Skills는 아무것도 실행하지 않습니다. 따라서 복잡한 처리가 필요한 상황에서는 Skill 내부에서 "이 부분은 MCP 도구를 사용해"라고 지시하는 것이 자연스러운 조합 방식입니다. 이미지로 표현하자면, Skills는 절차를 가르쳐주는 담당, 셸 액세스(Shell Access)는 근처의 작업을 수행하는 담당, MCP 서버는 본격적인 처리를 담당하는 역할 분담입니다.

예를 들어 앞서 언급한 슬라이드 생성과 같은 Skill을 더 대규모인 사내 인프라에 편입시키고 싶다면, LLM 호출이나 스토리지 저장 등을 MCP/백엔드 실행 계층에 맡기고, "어떤 JSON 스키마로 슬라이드를 작성할 것인가"라는 노하우 부분만 Skill로 갖게 하는 설계가 합리적입니다.

요약

Skills는 "Claude가 원래 가진 능력의 사용 매뉴얼"이며, 새로운 시스템 프롬프트(System Prompt) 조각이 필요할 때만 삽입되는 것과 같습니다. MCP는 "Claude 외부에 있는 다른 시스템으로의 살아있는 연결"이며, 새로운 손과 발 그 자체를 부여하는 것입니다.

어느 한쪽을 선택하기보다는, 사내 규칙이나 포맷에 대한 지식은 Skills에, DB 연결이나 복잡한 외부 시스템과의 통합은 MCP에 맡기는 식으로 역할을 나누어 조합하는 것이 실무적입니다. 그리고 두 기능 모두 이제 Claude 전용의 고립된 기능이 아니라, 에이전트형 AI 전반에서 사용되는 공통 언어가 되어가고 있습니다.

Discussion