개념·비교 실습 예시

구체적 상황을 놓고 MCP(연결)와 Skill(절차)을 가려내고, 둘을 조합해 설계하는 사고 훈련  |  ← 레퍼런스 문서로 돌아가기

대상 버전·범위Claude Docs · Claude Code 2026-06 기준 (MCP 스펙 2025-11-25 / 프로토콜 2025-06-18)
이 파일의 목적개념 레퍼런스에서 정리한 정의·비교 기준을 실제 판단 상황에 적용하는 연습
레퍼런스 문서concepts_Manual.html — 각 시나리오에서 링크로 연결됩니다
작성일2026년 6월 27일
● 초급 Getting Started 하나의 작업을 "연결"과 "절차"로 쪼개어, 어디까지가 MCP이고 어디부터가 Skill인지 감을 잡는다
G-1 초급 내 작업은 MCP감일까 Skill감일까
팀에 갓 합류한 개발자가 "사내 Notion 워크스페이스의 이번 주 회의록을 가져와 주간 리포트를 작성"하는 일을 Claude로 자동화하고 싶다. MCP와 Skill이라는 두 단어는 들었지만, 이 작업을 어느 쪽으로 풀어야 하는지 막막하다. 정답은 "둘 다"이며, 핵심은 한 작업을 연결 부분과 절차 부분으로 분리해 보는 사고 습관이다.
단계별 실행
  1. 작업을 한 문장으로 적고 동사를 표시한다

    먼저 하려는 일을 동사 중심으로 풀어 쓴다. 동사마다 "외부에서 데이터를 가져오는가" 아니면 "정해진 규칙대로 가공/작성하는가"를 표시하면 경계가 드러난다.

    작업: Notion 회의록을 [가져와서] 주간 리포트를 [작성한다]
      - 가져온다  → 외부 SaaS(Notion)에 실시간 접근  → 연결 문제
      - 작성한다  → 회사 리포트 형식·말투·섹션 규칙 적용 → 절차 문제
  2. "연결" 부분은 MCP로 분류한다

    Notion처럼 Claude 바깥에 있는 시스템에서 데이터를 실시간으로 읽어 오는 일은 표준 연결 프로토콜인 MCP의 몫이다. Notion MCP 서버가 tools/call로 페이지를 조회해 그 내용을 컨텍스트로 넘겨준다. 외부 인증(OAuth 등)과 API 호출이 끼면 거의 항상 MCP다.

    # Notion 연동은 MCP 서버를 등록해 처리
    claude mcp add --transport http notion https://mcp.notion.com/mcp
  3. "절차·규칙" 부분은 Skill로 분류한다

    가져온 회의록을 "우리 회사 주간 리포트는 이런 섹션 순서, 이런 말투, 이런 길이"라는 조직 고유의 규칙으로 다듬는 일은 외부 연결이 필요 없다. 이렇게 반복되는 절차와 전문성은 SKILL.md 한 폴더에 담아 두는 Skill로 푼다.

    .claude/skills/weekly-report/SKILL.md
      ├─ frontmatter: name, description("주간 리포트를 작성할 때 사용")
      └─ 본문: 섹션 순서 · 말투 · 분량 · 예시 템플릿
실제 실행에서는 Skill이 먼저 트리거되어 "주간 리포트 작성 절차"를 Claude의 작업 지침으로 불러오고, 그 절차 안에서 "원본 데이터가 필요하다"는 대목에 이르면 Notion MCP 서버의 tool을 호출해 회의록을 끌어온다. 즉 Skill이 무엇을·어떻게의 흐름을 잡고, MCP가 외부 데이터를 공급하는 분업이다. 둘은 경쟁 관계가 아니라 보완재다.
헷갈릴 때는 "Claude를 인터넷에서 떼어 놓아도 이 부분이 되는가?"를 물어보라. 떼어 놓으면 안 되는(외부 데이터·API가 필요한) 부분은 MCP, 떼어 놓아도 되는(지식·규칙·절차) 부분은 Skill이다.
● 중급 Daily Workflow 현장에서 마주치는 요구사항을 MCP / Skill / 둘 다 중 하나로 빠르게 판정하는 기준 잡기
D-1 중급 시나리오 5개를 빠르게 판정
실무에서는 "이거 MCP로 해요, Skill로 해요?"라는 질문이 끝없이 들어온다. 매번 처음부터 고민하지 않으려면 판정 기준을 손에 익혀야 한다. 아래 다섯 가지 전형적 요구사항을 하나씩 판정하며 그 기준을 체화한다. 각 항목의 결론보다 왜 그렇게 갈리는지가 중요하다.
단계별 실행
  1. 외부 SaaS 연결 → MCP

    "Jira에서 이번 스프린트 이슈를 가져와 줘" 같이 Claude 외부의 SaaS·DB·API에 실시간 접근해야 하는 일. 인증과 네트워크 호출이 필수이므로 표준 연결 프로토콜인 MCP가 정답이다. 외부 의존이 있는 순간 Skill 단독으로는 풀 수 없다.

    판정: MCP
    근거: 외부 시스템 실시간 조회 + 인증 필요 → 연결 계층
  2. 사내 문서작성 규칙 → Skill

    "우리 회사 보도자료는 항상 이 구조, 이 톤으로 써 줘" 같이 조직 고유의 절차·전문성을 주입하는 일. 외부 데이터가 필요 없고 마크다운 지침으로 자기완결되므로 Skill이 정답이다. description에 "보도자료를 작성할 때"라는 트리거를 명시하는 게 핵심.

    판정: Skill
    근거: 외부 연결 없음 + 반복되는 작성 규칙·전문성 패키징 → 절차 계층
  3. 다중 클라이언트 재사용 → MCP

    "이 사내 데이터 연동을 Claude Code뿐 아니라 Cursor, VS Code에서도 똑같이 쓰고 싶다"는 요구. MCP는 오픈 표준이라 여러 클라이언트가 같은 서버를 공유할 수 있다. 반면 Skill은 Anthropic 제품 전용이라 여러 클라이언트 간 재사용이 불가능하다 — 이 점이 결정적 분기점이다.

    판정: MCP
    근거: 여러 클라이언트가 동일 서버 재사용 → 표준화·이식성은 MCP만 가능
  4. 파이썬 스크립트 번들 → Skill

    "검증된 데이터 정리용 파이썬 스크립트를 묶어 두고 정해진 순서로 돌리게 하고 싶다"는 요구. 스크립트·리소스를 한 폴더에 번들하고 점진 공개로 필요할 때만 읽게 하는 것은 Skill의 전형이다. 스크립트는 코드 전체가 아니라 실행 출력만 컨텍스트로 들어와 토큰도 아낀다.

    판정: Skill
    근거: 자기완결 스크립트·리소스 번들 + 외부 의존 없음 → 절차 계층
  5. 데이터 조회 + 정형 생성 → 둘 다

    "Salesforce에서 고객 데이터를 뽑아 회사 표준 PPTX 보고서로 만들어 줘"처럼 외부 조회와 정형 산출물 생성이 함께 있는 일. 조회는 MCP, 형식·규칙은 Skill이 맡아 조합하는 것이 가장 깔끔하다. 한쪽으로 무리하게 욱여넣지 않는 게 요령이다.

    판정: MCP + Skill
    근거: 외부 조회(MCP) + 조직 형식 적용·문서 생성(Skill) → 책임 분리
다섯 판정을 관통하는 한 줄 기준은 이렇다 — "외부 세계와 실시간으로 연결되어야 하는가?"가 Yes면 MCP, "조직의 절차·규칙·전문성을 주입하는가?"가 Yes면 Skill, 둘 다 Yes면 둘 다. 무엇(프로토콜 vs 폴더)·목적(연결 vs 절차)·표준화(다중 클라이언트 vs Anthropic 전용)·외부 의존(있음 vs 거의 없음)이라는 네 축만 떠올리면 대부분 즉시 갈린다.
"Skill이 MCP의 경량판"이라거나 "Skill이 MCP를 대체한다"는 오해를 경계하라. 둘은 목적이 다른 보완재이며, 외부 시스템 연결은 여전히 MCP가 필수다. 반대로 단순 작성 규칙을 굳이 MCP 서버로 만들면 서버 호스팅·인증·tool 정의의 상시 토큰 비용만 떠안게 된다.
● 고급 Power User MCP와 Skill을 한 워크플로우 안에서 책임을 나눠 결합하고, 유지보수까지 고려해 설계하기
P-1 고급 MCP+Skill 조합 설계
영업팀을 위해 "Salesforce 고객 데이터를 조회해 회사 표준 분기 리포트 PPTX를 자동 생성"하는 워크플로우를 설계한다. 전제로 Salesforce MCP 서버 접근 권한과, 리포트 형식을 담은 사내 Skill, 그리고 Anthropic 기본 pptx 스킬을 쓸 수 있는 환경이 갖춰져 있다. 핵심 설계 원칙은 "무엇(데이터)은 MCP, 어떻게(형식·규칙)는 Skill"로 책임을 분리해 각각을 독립적으로 유지보수하는 것이다.
단계별 실행
  1. 연결 계층: Salesforce를 MCP 서버로 등록

    고객 데이터의 출처인 Salesforce는 외부 SaaS이므로 MCP로 연결한다. 원격 HTTP 트랜스포트와 OAuth 인증으로 등록하면 tools/call을 통해 실시간으로 분기 매출·계약 데이터를 조회할 수 있다. 데이터 스키마가 바뀌어도 이 서버만 손보면 된다.

    claude mcp add --transport http salesforce https://example-sf-mcp/mcp
    # 등록 확인
    claude mcp get salesforce
  2. 절차 계층: 리포트 규칙 Skill 작성

    "분기 리포트는 어떤 섹션을, 어떤 순서로, 어떤 차트와 함께"라는 회사 고유 형식을 Skill로 정의한다. 이 Skill의 본문은 PPTX 생성 절차를 안내하되, 실제 슬라이드 변환은 Anthropic 기본 pptx 스킬에 위임한다. 형식 정책이 바뀌면 이 폴더만 고치면 된다.

    .claude/skills/quarterly-report/SKILL.md
    ---
    name: quarterly-report
    description: 분기 영업 리포트를 PPTX로 만들 때 사용. 회사 표준 섹션·차트 규칙 적용.
    ---
    # 본문: 표지 → 요약 → 매출 추이 → 핵심 계약 → 리스크 순서, pptx 스킬로 렌더
  3. 조합 실행: 한 요청에서 둘을 엮는다

    사용자가 분기 리포트를 요청하면 description 트리거로 리포트 Skill이 켜지고, 그 절차가 "최신 데이터가 필요하다"는 지점에서 Salesforce MCP tool을 호출한다. 받아 온 데이터를 회사 형식 규칙으로 구성한 뒤 pptx 스킬이 최종 파일을 만든다.

    # 사용자 요청 한 줄로 전체 흐름이 작동
    "2026년 2분기 영업 리포트를 표준 양식으로 만들어 줘"
내부 흐름은 Skill(절차) → MCP(데이터) → Skill(형식·렌더)의 사이클이다. ① 리포트 Skill이 트리거되어 작성 절차를 컨텍스트로 로드(점진 공개로 메타→본문 순) → ② 절차 중 데이터가 필요한 대목에서 Salesforce MCP 서버가 tools/call로 분기 데이터를 스냅샷으로 반환 → ③ 그 데이터를 회사 섹션·차트 규칙에 맞춰 구성 → ④ Anthropic pptx 스킬이 실제 슬라이드로 렌더링. 데이터 출처(무엇)와 표현 규칙(어떻게)이 분리돼 있어, 한쪽이 바뀌어도 다른 쪽은 영향받지 않는다.
책임 분리의 유지보수 이점이 핵심이다. Salesforce 필드가 추가되면 MCP 서버만, 리포트 양식이 개편되면 Skill만 손대면 된다. 또한 Salesforce MCP 서버는 다른 클라이언트·다른 워크플로우에서도 재사용할 수 있고, 리포트 Skill은 git으로 팀에 배포해 누구나 같은 형식을 쓰게 만들 수 있다. 한 덩어리로 묶지 않은 덕에 둘 다 독립적으로 진화한다.

Claude Docs · Claude Code 2026-06 기준 (MCP 스펙 2025-11-25 / 프로토콜 2025-06-18) | 2026년 6월 27일 작성
← 개념·비교 레퍼런스