에이전트 스킬 vs MCP 서버: 의사결정 프레임워크

에이전트 스킬과 MCP 서버는 종종 AI 에이전트를 확장하는 경쟁적인 방식들로 제시됩니다. 그러나 이 프레임은 틀렸습니다: 스킬은 에이전트가 어떻게 작업해야 하는지를 가르치고, MCP 서버는 라이브 기능에 대한 거버넌스된 접근을 제공합니다.

유용한 질문은 “어떤 표준이 이기느냐?“가 아니라 “이 책임은 어디에 있어야 하는가?“입니다. 이 가이드는 컨텍스트 크기, 장기 실행 연결, 자격 증명, 운영 안전성이 깔끔한 데모보다 더 중요한 Hermes Agent와 OpenClaw 같은 호스팅된 어시스턴트에 대해 이를 답변합니다.

이것은 학술적인 비교가 아닙니다. 이것은 두 메커니즘 모두에 대한 실제 배포 경험에서 구축된 실용적인 의사결정 프레임워크이며, 에이전트가 프로덕션에서 실행되기 시작할 때만 보이는 컨텍스트 비용 트레이드오프를 포함합니다. 멀티 에이전트 시스템을 구축 중이라면 같은 문제 공간의 다른 축을 다루는 A2A vs MCP 프로토콜 비교도 읽어보실 것을 권장합니다.

에이전트 스킬 vs MCP 서버: 한눈에 보기

절차, 판단, 재사용 가능한 운영 지식에는 스킬을 사용하세요. 권위 있는 상태, 보호된 작업, 안정적인 기능 계약에는 MCP 서버를 사용하세요.

제 기본값은 의도적으로 보수적입니다: 작업이 로컬이고 읽기 중심이며 절차적일 때 스킬로 시작하세요. 에이전트가 신뢰 경계를 넘거나 변경되는 외부 상태를 만지거나, 모델이 혼란스러워도 정확해야 하는 작업이 필요할 때 MCP 서버를 추가하세요.

핵심 차이: 절차 vs 기능

에이전트 스킬은 SKILL.md를 중심으로 한 디렉토리로, 선택적 스크립트, 참조, 에셋을 포함합니다. Agent Skills 사양은 필수 메타데이터와 점진적 노출 모델을 정의합니다: 호스트는 먼저 작은 이름과 설명을 발견하고, 관련 있을 때 전체 지침을 로드하며, 필요할 때만 지원 파일을 가져올 수 있습니다.

이것은 스킬을 인시던트 기준, 릴리스 체크리스트, 연구 방법, 또는 기존 명령줄 도구 사용 지침의 강력한 집으로 만듭니다. 그 핵심 가치는 인코딩된 절차입니다: 시퀀스, 판단, 제약, 예시, 좋은 결과의 정의. 프론트매터 구조와 조건부 활성화가 포함된 Hermes 전용 작성 세부사항은 Hermes Agent 스킬 작성을 참조하세요.

MCP는 다른 문제를 해결합니다. Model Context Protocol 사양은 도구, 리소스, 프롬프트를 포함한 기능에 대해 클라이언트와 서버에게 JSON-RPC 기반 계약을 제공하며, 표준 전송 및 발견 동작을 포함합니다. Python MCP 서버와 Go MCP 서버에 대한 실용적인 구현 가이드는 프로토콜이 중대한 작업을 처리하면 통합 레이어가 얼마나 간단할 수 있는지 보여줍니다.

따라서 MCP 서버는 티켓 시스템, 클라우드 제어 평면, 신뢰의 원천 데이터베이스, 내부 검색 서비스에 대한 좋은 경계입니다. 그것은 그 시스템에 도달하는 메커니즘을 소유하고, 모델의 산문 지침 외부에서 검증, 인가, 타임아웃, 속도 제한, 감사 동작을 강제할 수 있습니다.

더 정확한 규칙

책임을 모델이 지침을 기억하지 않아도 정확해야 하는지 물어보세요. 만약 대답이 예라면, 그것은 SKILL.md에만 있는 것이 아니라 결정론적 코드나 서버 정책에 속합니다.

예를 들어, “에스컬레이션 전에 세 가지 지원 신호 수집하기"는 유용한 스킬 지침입니다. “호출자가 인시던트 매니저 스코프가 없으면 상태 변경 거부하기"는 스킬이 규칙을 반복하더라도 서비스 또는 MCP 서버에 의해 강제되어야 합니다.

이것이 중요한 경계입니다:

• 스킬은 에이전트에게 행동이 적절한 때를 알려줄 수 있습니다.
• MCP 도구는 타입화된 인터페이스를 통해 행동을 사용할 수 있게 만들 수 있습니다.
• 백킹 서비스는 행동이 실제로 허용되는지 결정해야 합니다.

MCP 서버는 프롬프트도 노출할 수 있으므로, 표준은 가장자리에서 겹칩니다. 그러나 거대한 도구 설명에 전체 운영 절차를 넣는 것은 일반적으로 취약한 기능 카탈로그를 생성하며, 스킬 내부에 숨겨진 셸 스크립트에 특권 API 클라이언트를 넣는 것은 일반적으로 피할 수 있는 보안 문제를 생성합니다.

SKILL.md가 충분한 경우

에이전트가 이미 필요한 모든 것에 안전한 접근을 가지고 있고 누락된 요소가 노하우일 때 스킬은 충분합니다. 이것은 저장소 분석, 문서 변환, 보고서 생성, 또는 성숙한 CLI 명령 위에 구축된 로컬 워크플로우에 일반적입니다.

데이터가 로컬이거나 사용자에게 제공되는 경우

예를 들어 에이전트가 체크아웃된 저장소를 검사하고 읽기 전용 린터를 실행하고 구성 파일을 비교하며 마이그레이션 보고서를 생성해야 한다고 가정해 보세요. 파일은 이미 작업 환경에 있고 호스트는 이미 파일시스템 및 프로세스 도구를 노출하므로, 다른 네트워크 서비스는 거의 가치를 추가하지 않습니다.

스킬은 어떤 파일을 검사할지, 명령 순서, 실패 처리, 필요한 증거를 설명할 수 있습니다. 번들된 스크립트는 출력을 정규화할 수 있지만, 호스트의 기존 샌드박스와 명령 권한이 실제 실행 경계로 남아있습니다.

워크플로우가 판단에 의존하는 경우

스킬은 여러 기술적으로 유효한 행동이 존재하지만 조직이 하나의 운영 방법을 선호할 때 특히 유용합니다. 코드 리뷰 스킬은 어떤 위험이 차단 코멘트를 받을 자격이 있는지, 언제 재현을 요청해야 하는지, 정확성 문제를 취향과 어떻게 분리해야 하는지 설명할 수 있습니다.

그 규칙들은 팀들이 배우면서 변경됩니다. 그것들을 버전 관리된 산문과 작은 참조로 유지하는 것은 종종 모든 편집 조정마다 서버를 다시 컴파일하거나 재배포하는 것보다 더 명확합니다.

중앙 제어보다 휴대성이 더 중요한 경우

오픈 Agent Skills 형식은 원격 런타임이 아니라 휴대 가능한 폴더로 설계되었습니다. 잘 스코프된 스킬은 지침, 예시, 지원 에셋과 함께 호환되는 호스트 간에 이동할 수 있지만, 도구 이름과 샌드박스 동작은 여전히 호스트별 테스트가 필요합니다.

이 휴대성은 같은 배포를 반드시 공유하지는 않지만 방법을 공유하는 Hermes Agent와 OpenClaw 워크플로우에 유용합니다. 첫 번째 차이에서 핵심 절차를 포크하는 대신 호스트별 노트를 짧은 참조에 유지하세요. OpenClaw 스킬 생태계 가이드는 어떤 스킬을 설치할 가치가 있는지와 에이전트 역할별로 어떻게 안전하게 게이트할지를 다룹니다.

기존 CLI가 이미 기능을 제공하는 경우

신뢰할 수 있는 로컬 명령을 감싸기 위해 서버를 구축하지 마세요. 단일 사용자 어시스턴트가 이미 인증, 구조화된 출력, 에러를 처리하는 좁은 CLI를 호출할 수 있다면, 스킬이 더 작고 유지보수하기 쉬운 솔루션일 수 있습니다.

주의사항은 중요합니다: CLI가 로컬이기 때문에 자동으로 안전한 것은 아닙니다. 광범위한 셸 보간을 피하고, 구조화된 출력을 선호하고, 작성 가능한 타겟을 제한하며, 스킬의 제안된 도구 허용 목록을 완전한 인가 시스템으로 취급하지 마세요.

MCP 서버가 필요한 경우

문제가 단순히 무엇을 해야 하는지 기억하는 것이 아니라면 MCP를 선택하세요. MCP 서버는 에이전트가 변경되는 시스템에 대한 내구성 있는, 타입화된, 거버넌스 가능한 브릿지가 필요할 때 가치가 됩니다.

상태가 라이브이고 권위 있는 경우

고객 티켓, 배포 상태, 재고, 청구 기록, 프로덕션 메트릭은 두 모델 턴 사이에 변경될 수 있습니다. 그 상태를 스킬로 복사하면 구조적으로陳腐化되며, 모델에게 인터페이스를 스크랩하도록 요청하면 불안정한 계약을 생성합니다.

MCP 리소스나 도구는 실행 시 현재 기록을 검색할 수 있습니다. 서버는 업스트림 특이점을 정규화하고 모델에게 전체 벤더 응답을 노출하는 대신 간결한 결과를 반환할 수 있습니다.

자격 증명이나 사용자 정체성이 관여되는 경우

자격 증명은 SKILL.md, 예시, 번들된 헬퍼 스크립트에 있어서는 안 됩니다. 원격 HTTP 배포의 경우, MCP 인가 사양은 OAuth 기반 모델을 정의합니다; 로컬 stdio 서버의 경우, 자격 증명은 프로세스 환경이나 다른 호스트 제어 메커니즘을 통해 제공될 수 있습니다. 공식 MCP 인가 가이드를 참조하세요.

서버를 사용하는 더 깊은 이유는 비밀 저장뿐만 아니라 아닙니다. 서버는 정체성을 스코프에 매핑하고, 테넌트를 제한하고, 필드를 적출하고, 누가 변형을 요청했는지 기록할 수 있지만, 산문 지침은 모델에게 행동을 요청할 수 있을 뿐입니다.

쓰기가 트랜잭션 보장을 필요로 하는 경우

인보이스 생성, 티켓 상태 변경, 또는 배포 시작은 그럴듯한 JSON 객체보다 더 많은 것이 필요합니다. 그 작업은 멱등성 키, 낙관적 동시성, 서버 측 검증, 내구성 있는 감사 추적을 필요로 할 수 있습니다.

이러한 속성은 모델 아래에 속합니다. 스킬은 승인 정책을 정의할 수 있지만, MCP 서버는 유효하지 않은 전환을 거부하고 재시도된 요청을 안전하게 만들어야 합니다.

여러 에이전트가 같은 기능을 필요로 하는 경우

공유 MCP 서버는 여러 에이전트 호스트, 언어, 모델 제공자에게 하나의 계약을 제시할 수 있습니다. 이것은 플랫폼 팀에게 스키마를 개선하고, 업스트림 API 동작을 패치하고, 통합 로직을 모든 스킬에 복사하지 않고 접근 제어를 적용할 수 있는 중앙 장소를 제공합니다.

중앙화는 무료가 아닙니다. 서버는 버전 관리, 관찰성, 가용성, 인시던트 대응 의무가 있는 운영되는 의존성이 되므로, 그것은 건축적 열정보다는 실제 경계로 그 존재를 정당화해야 합니다.

컨텍스트 비용 문제

컨텍스트 비용은 종종 “스킬은 점진적이고, 도구는 항상 로드된다"는 슬로건으로 단순화됩니다. 실제 호스트는 더 미묘하며, 차이는 확장 형식에서 가정하기보다 직렬화된 모델 입력에서 측정되어야 합니다.

Agent Skills 문서는 스킬당 약 100 토큰의 발견 메타데이터를 설명하고, 활성화된 지침을 5,000 토큰 이하로 유지하는 것을 권장하며, 참조가 필요할 때 로드되도록 허용합니다. 간단한 계획 추정치는:

C_skill = discovery metadata + activated instructions + selected references

MCP 클라이언트는 서버에서 도구 정의를 발견하지만, 프로토콜은 모든 발견된 스키마가 모든 모델 호출에 나타나야 한다고 요구하지 않습니다. 호스트는 도구를 필터링하고, 지연시키고, 캐시하고, 라우팅할 수 있으므로, 실용적인 추정치는:

C_mcp = tool schemas exposed to this turn + tool results retained in context

MCP 도구 사양은 또한 안정적인 도구 순서가 프롬프트 캐시 동작을 개선할 수 있다고 언급합니다. 캐시는 반복 처리 비용을 줄일 수 있지만, 그것은 과대 카탈로그를 모델이 선택하기 더 쉽게 만들지는 않습니다.

예시 토큰 예산

20개의 설치된 스킬을 가진 호스팅된 어시스턴트를 고려해 보세요. Agent Skills 문서의 근사적 발견 비용으로, 컴팩트 스킬 인덱스는 약 2,000 토큰입니다; 초점화된 트리아지 스킬을 활성화하면 다른 1,200 토큰과 하나의 600 토큰 참조가 추가될 수 있습니다.

이제 두 MCP 설계를 비교해 보세요. 네 개의 간결한 스키마를 가진 얇은 티켓 서버는 500-800 토큰으로 직렬화될 수 있지만, 35개의 길게 설명된 도구를 가진 광범위한 엔터프라이즈 서버는 어떤 결과도 도착하기 전에 수천 토큰을 소비할 수 있습니다.

이것들은 예시적 계획 숫자이며, 프로토콜 보장이나 벤치마크가 아닙니다. 스키마 길어짐, 설명, 라우팅, 결과 유지, 토크나이저 선택이 총합을 상당히 이동시킬 수 있으므로 호스트가 생성한 정확한 프롬프트를 측정하세요.

실용적인 결론은 “스킬은 저렴하다"거나 “MCP는 비싸다"가 아닙니다. 그것은 점진적 노출과 기능 선택이 아키텍처 기능이라는 것입니다: 스킬 메타데이터를 판별적으로 유지하고, 관련 있는 지침만 활성화하고, 가장 작은 유용한 도구 세트를 노출하며, 원시 업스트림 페이로드 대신 프로젝션을 반환하세요.

얇은 서버 패턴: 아래는 MCP, 위는 스킬

가장 내구성 있는 설계는 종종 두 메커니즘을 결합합니다. MCP에 작은 기능 경계를 넣고, 그것을 호출하는 스킬에 운영 방법을 배치하세요.

Hermes Agent나 OpenClaw에서 모두 사용되는 지원 인시던트 워크플로우를 고려해 보세요. 에이전트는 티켓을 읽고, 증거를 수집하고, 심각성을 분류하고, 운영자 노트를 초안하고, 필요한 승인 후에만 상태를 변경해야 합니다.

MCP 서버가 소유하는 것

서버 인터페이스는 좁고 문자 그대로 유지하세요:

서버는 단락 길이 설명과 열두 개의 관련 없는 플래그를 가진 triage_everything이라는 도구를 포함해서는 안 됩니다. 네 개의 경계된 작업은 인가하기, 테스트하기, 관찰하기, 재사용하기 더 쉽습니다.

스킬이 소유하는 것

스킬은 시퀀스와 판단을 소유합니다. 컴팩트한 SKILL.md는 다음과 같을 수 있습니다:

---
name: incident-triage
description: Triage support incidents using ticket evidence and the severity rubric.
---

1. Read the ticket and its current version.
2. Collect at least two independent signals before assigning severity.
3. Separate observed facts from hypotheses in the note.
4. Ask for operator approval before any customer-visible note or status change.
5. Re-read the ticket before a write; stop if its version changed.
6. End with severity, evidence, uncertainty, and recommended next action.

그 파일은 읽기 쉽고, 검토할 수 있으며, 트리아지 정책이 변경될 때 쉽게 수정할 수 있습니다. 연결된 참조는 심각성 기준을 포함할 수 있지만, 주요 지침은 운영 핸드북을 모든 턴에 끌어들이지 않고 활성화하기에 충분히 짧게 유지됩니다.

Hermes Agent에서 어떻게 실행되는가

Hermes Agent의 네이티브 MCP 문서는 시작 발견, 지속적 연결, stdio와 Streamable HTTP 전송, 네임스페이스화된 MCP 도구를 설명합니다. 그 현재 구성은 또한 stdio 서버를 위해 환경을 필터링하고 명시적으로 구성된 변수만 전달하며, 이는 우발적인 비밀 상속을 방지하는 유용한 방어입니다.

이 설계에서, Hermes는 네 개의 티켓 도구를 발견하고, 인시던트 스킬은 관련 있는 요청에 대해서만 활성화됩니다. 모델은 스킬을 따르고, MCP 서버는 경계된 작업을 실행하며, 티켓 서비스는 최종 권위를 유지합니다.

OpenClaw에서 어떻게 실행되는가

OpenClaw의 스킬 문서는 Agent Skills 구조를 따르고 모델에게 자격 있는 스킬의 컴팩트한 목록을 구축합니다. 같은 인시던트 폴더는 핵심 절차를 운반할 수 있지만, 사용 가능한 티켓 도구 이름을 설명하는 짧은 호스트별 참조와 함께입니다.

공유 스킬에 티켓 토큰을 넣지 마세요. OpenClaw는 명시적으로 공유 스킬을 입력으로 취급하며 비밀 저장으로 취급하지 않으며, 서드파티 스킬은 활성화되기 전에 불신 코드로 검토되어야 합니다.

왜 분리가 변경을 견디는가

지원 팀이 심각성 기준을 수정하면, 스킬을 업데이트하세요. 티켓 벤더가 인증이나 페이지네이션을 변경하면, 운영 정책을 다시 작성하지 않고 MCP 서버를 업데이트하세요.

두 번째 에이전트 호스트가 도착하면, 같은 MCP 계약을 재사용하고 스킬의 작은 호스트별 레이어만 적응할 수 있습니다. 이 분리는 서비스 배포로 모든 절차적 편집을 변환하지 않고 중복된 통합 로직을 줄입니다.

5단계 의사결정 프레임워크

다음 시퀀스는 유행하는 확장 유형을 먼저 선택하는 것보다 더 신뢰할 수 있습니다.

1. 신뢰의 원천 식별하기

워크플로우가 만지는 모든 입력과 출력을 적어보세요. 정적 가이드, 저장소 파일, 사용자 제공 문서는 스킬로 기울고; 변경 가능한 원격 기록과 권위 있는 시스템은 MCP로 기울습니다.

모든 상태가 서버를 정당화하지는 않습니다. 로컬 빌드 아티팩트는 상태이지만, 기존 샌드박스된 CLI가 이미 충분한 경계를 제공할 수 있습니다.

2. 신뢰 경계 위치 파악하기

자격 증명, 테넌트 정체성, 특권 데이터, 또는 되돌릴 수 없는 행동이 나타나는 지점을 표시하세요. 만약 에이전트가 그 선을 넘으면, 결정론적 강제 지점을 도입하세요, 일반적으로 서비스 인가에 의해 백업된 MCP 서버입니다.

모델과 스킬을 요청 플래너로 취급하고, 정책 엔진으로 취급하지 마세요. 그들은 허용된 행동을 제안할 수 있지만, 자신의 지침을 변경하여 허가를 재정의해서는 안 됩니다.

3. 기능과 정책 분리하기

타입화된 입력을 가진 좁은 동사로 기능을 명명하세요: 티켓 가져오기, 노트 추가하기, 또는 상태 변경하기. 그 동사를 선택하는 조건, 증거 기준, 선호 시퀀스를 스킬에 배치하세요.

일부 정책은 다른 이유로 두 레이어 모두에 존재해야 합니다. “배포 전에 사용자에게 물어보기"는 상호작용 품질을 위해 스킬에 속하지만, “승인 토큰 없이 배포 거부하기"는 강제를 위해 코드에 속합니다.

4. 컨텍스트와 운영 비용 추정하기

실제 프롬프트 추적을 캡처하고 스킬 메타데이터, 활성화된 지침, 도구 정의, 반환된 데이터를 세어보세요. 그리고 MCP 서비스의 토큰이 아닌 비용을 추가하세요: 배포, 인증, 모니터링, 버전 관리, 온콜 소유권.

30개 도구 카탈로그가 하나의 워크플로우를 지원한다면, 작업 특정 하위 세트를 노출하거나 일관된 기능 도메인별로 서버를 분할하세요. 스킬이 반복적으로 200페이지 참조를 로드한다면, 점진적 노출을 자축하는 대신 검색 단계나 더 작은 참조를 생성하세요.

5. 먼저 경계 테스트, 다음 행동 테스트하기

MCP 서버를 소프트웨어로 테스트하고 스킬을 에이전트 행동으로 테스트하세요. 그들은 다르게 실패하며, 단일 해피패스 채팅 기록은 두 종류의 결함을 모두 숨깁니다.

도구 안전성에 대해, MCP 사양은 입력 검증, 접근 제어, 속도 제한, 출력 세제이션, 타임아웃, 민감한 작업에 대한 확인, 감사 로깅을 권장합니다. 도구 주석은 힌트이며, 작업이 읽기 전용이거나 무해하다는 신뢰할 수 있는 증거가 아닙니다. A2A와 MCP 에이전트 보안 가이드는 프롬프트 인젝션과 도구 독살을 포함한 더 넓은 위협 모델을 다룹니다.

슬로건에 맞지 않는 보안 규칙

스킬은 일부 서버의 필요성을 줄이지만, 위험을 제거하지는 않습니다. 스킬은 스크립트를 포함할 수 있고 에이전트가 강력한 호스트 도구를 호출하도록 설득할 수 있으므로, 지침과 실행 파일을 코드로 검토하고, 신뢰할 수 있는 버전을 고정하고, 세션에 사용 가능한 호스트 도구를 제한하세요.

MCP는 또 다른 경계를 추가합니다: 자체 의존성, 입력, 출력, 자격 증명을 가진 로컬 서브프로세스 또는 원격 서비스. 최소 권한을 적용하고, 원격 인가를 위해 리소스 오디언스를 검증하고, HTTPS를 사용하고, 불신 콘텐츠를 세제이션하고, 결과적인 쓰기에 대한 승인을 가시적으로 유지하세요.

가장 중요하게, 발견 가능성을 권위와 혼동하지 마세요. 도구가 모델의 카탈로그에 나타나는 것은 현재 사용자가 그것이 설명하는 모든 작업을 실행해야 한다고 의미하지 않습니다.

일반적인 안티패턴

스킬에 원격 API 클라이언트 숨기기

정적 베어러 토큰을 읽고 프로덕션 API를 호출하는 셸 스크립트는 데모에서 작동할 수 있습니다. 그러나 그것은 절차, 자격 증명, 네트워크 동작, 인가를 에이전트 호스트가 복사하고 읽도록 설계된 패키지로 혼합합니다.

보호된 통합을 좁은 서버나 기존 승인된 CLI 뒤로 이동하세요. 스킬에는 워크플로우와 호출 가이드만 유지하세요.

도구 설명에 워크플로우 인코딩하기

도구 설명은 모델이 기능을 선택하고 스키마를 채우는 것을 돕기 위해 있어야 합니다. 그것들은 예시, 예외, 에스컬레이션 규칙, 출력 관례가 있는 멀티스텝 운영 절차의 나쁜 대체물입니다.

긴 설명은 도구가 노출되는 모든 턴을 팽창시키고 서비스 계약을 재사용하기 더 어렵게 만듭니다. 절차를 스킬에 배치하고 도구 의미를 정밀하게 유지하세요.

execute_anything 도구 구축하기

일반적인 셸, SQL, HTTP 프록시는 많은 권한을 감사하기 어려운 하나의 기능으로 붕괴시킵니다. 그것은 검증을 모델로 이동시키고 최소 권한을 대부분 허구적으로 만듭니다.

실제 비즈니스 행동과 정렬된 작업을 노출하세요. 전문가 운영자가 정말로 탈출구를 필요로 한다면, 그것을 분리하고, 제한하고, 더 강한 승인 및 로깅을 요구하세요.

키친 싱크 MCP 서버 게시하기

수십 개의 관련 없는 도구가 있는 서버는 선택, 스키마 컨텍스트, 권한, 유지보수를 부담시킵니다. 일관된 도메인별로 분할하거나 호스트가 현재 작업에 대한 관련 하위 세트를 노출하도록 하세요.

Hermes Agent의 FastMCP 가이드는 합리적인 시작 권장사항을 제공합니다: 1-3개의 고가치 엔드포인트로 시작하고 명확한 이름과 스키마를 가진 얇은 서버를 선호하세요. 공식 FastMCP 스킬 문서를 참조하세요.

도구 힌트를 보안 정책으로 취급하기

실험적 allowed-tools 필드나 도구의 읽기 전용 주석은 호스트 동작을 개선할 수 있지만, 그것은 샌드박싱과 서버 측 인가를 대체하지 않습니다. 메타데이터는 오래되었거나, 잘못 구성되었거나, 불신 구성 요소에 의해 제공되었을 수 있습니다.

인터페이스를 개선하기 위해 힌트를 사용하세요. 경계를 강제하기 위해 코드와 인프라를 사용하세요.

정적 지식에 MCP 사용하기

절차나 참조가 저장소와만 변경된다면, 원격 라운드 트립은 정보를 더 권위 있게 만들지 않고 배포 및 가용성 비용을 추가합니다. 간결한 자료를 스킬과 함께 패키징하고 워크플로우와 함께 버전 관리하세요.

코퍼스 크기가 크거나, 접근 제어되거나, 독립적으로 업데이트되거나, 정말로 검색이 필요할 때만 검색 서비스를 도입하세요. 아키텍처는 약어를 따르기보다 데이터 라이프사이클을 따라야 합니다.

최종 의사결정: 스킬, MCP 서버, 또는 양쪽?

어려운 부분이 무엇을 해야 하는지 아는 것이라면 에이전트 스킬을 선택하세요. 어려운 부분이 변경되는 것, 다른 신뢰 도메인에 속하는 것, 또는 계약을 강제해야 하는 것에 안전하게 도달하는 것이라면 MCP 서버를 선택하세요.

실제 워크플로우가 보호된 기능 위에 판단을 필요로 한다면 양쪽을 선택하세요. 그것은 중복이 아닙니다: 스킬은 에이전트를 유용하게 만들고, 서버는 통합을 거버넌스 가능하게 만들며, 백킹 시스템은 최종 결정을 권위 있게 만듭니다.

대부분의 호스팅된 어시스턴트에 대해, 최고의 첫 아키텍처는 겸손합니다: 하나의 초점화된 스킬, 라이브 접근이 요구하는 곳에만 작은 MCP 표면, 컨텍스트 비용을 검증하기 위한 캡처된 프롬프트 추적. 경계가 명확한 후에 복잡성을 추가하고, 그 전에 추가하지 마세요.

참조 자료

• Agent Skills specification
• Model Context Protocol specification
• MCP authorization guidance
• Hermes Agent native MCP documentation
• OpenClaw skills documentation
• FastMCP skill documentation