Agent Skill과 MCP 관리 도구

한 줄 요약

에이전트에 설치한 skill과 MCP가 많아지면 문제는 단순한 설치/삭제가 아니라, 출처 추적, 버전 고정, 프로젝트별 활성화, context 사용량, 팀 배포, 보안 검토까지 포함한 agent dependency management로 바뀐다.

먼저 읽을 결론

2026년 7월 1일 기준으로, skill과 MCP를 관리하려는 GitHub 저장소, CLI, MCP, 패키지 매니저는 이미 여러 갈래로 나와 있다. 다만 아직 하나의 표준 도구가 시장을 장악했다기보다는, 다음 네 층으로 나뉘어 발전하는 중이다.

필요	먼저 볼 후보	판단
skill을 찾고 설치하고 업데이트하기	`gh skill`, `npx skills`, `skills-cli`, `skills-manager`	개인이나 소규모 팀은 여기서 시작해도 된다. GitHub/Copilot 중심이면 `gh skill`, 여러 agent를 오가면 `npx skills`나 GUI형 `skills-manager`가 편하다.
skill, MCP, prompt, hook, agent 설정을 한꺼번에 관리하기	Microsoft `apm`, `sx`	팀 단위 재현성과 lockfile이 필요하면 이 계층이 더 맞다. 현재 공개 문서와 구조가 가장 뚜렷한 후보는 `apm`이다.
MCP 서버 설치와 client별 설정을 줄이기	`mcpm.sh`, `mcp-get`, `mcpman`, `mcp-installer`	MCP 서버 수가 적을 때는 client 내장 기능으로도 충분하지만, 여러 client를 오가면 package manager가 유용해진다.
MCP가 너무 많아 context와 tool selection이 망가지는 문제 줄이기	`Switchboard`, `hypertool-mcp`, `mcp-switchboard`, MCP gateway/proxy	설치 관리보다 활성 tool set, profile, on-demand routing, gateway filtering이 중요해지는 단계다.
skill/MCP 보안 검토	Snyk `agent-scan`, OWASP MCP Tool Poisoning guidance	skill과 MCP는 prompt 조각이 아니라 실행 권한을 가진 supply chain으로 봐야 한다.

실무적으로는 "skill manager 하나"를 찾는 것보다, 개인용은 gh skill/npx skills로 시작하고, 팀용은 manifest와 lockfile이 있는 apm 같은 접근을 검토하며, MCP가 많아지면 package manager보다 gateway/profile 계층을 먼저 고민하는 편이 낫다.

왜 저장했나

AI agent를 오래 쓰다 보면 skill, MCP server, slash command, prompt, hook, local script가 계속 늘어난다. 처음에는 생산성이 올라가지만, 어느 순간부터는 어떤 skill이 어디서 왔는지, 지금 프로젝트에 실제로 필요한 MCP가 무엇인지, 업데이트가 안전한지, context를 얼마나 잡아먹는지 알기 어려워진다.

이 노트는 그 문제를 "많아서 지저분하다" 수준으로 보지 않고, 다음 운영 문제로 나누어 보기 위해 저장했다.

발견: 쓸 만한 skill이나 MCP를 어떻게 찾을 것인가.
설치: 여러 agent와 editor에 어떻게 배포할 것인가.
고정: repo, commit, version, lockfile을 어떻게 추적할 것인가.
범위: global, user, project, team scope를 어떻게 나눌 것인가.
context: 필요 없는 tool description이 model context를 얼마나 차지하는가.
보안: skill과 MCP가 실행 권한, credential, filesystem, network에 닿을 때 어떻게 검토할 것인가.

정리한 질문

에이전트에 설치한 skill이나 MCP가 너무 많아져 관리가 어려울 때, 이를 관리하는 skill, CLI, MCP, GitHub repository, package manager가 있는가? 또 이 문제를 실제로 필요로 하는 커뮤니티 논의, 문서, 블로그, 사용기, 논문, 보안 자료는 무엇을 말하고 있는가?

기본 전제

Agent Skill은 대체로 SKILL.md를 중심으로 한 폴더다. Claude Code와 OpenAI Codex 모두 skill을 지침, reference, script, asset을 묶어 필요한 순간에 로드하는 단위로 설명한다. 중요한 점은 skill이 많아질수록 "발견 목록" 자체도 context 예산을 쓴다는 것이다.

OpenAI Codex 문서는 초기 skill 목록이 model context를 과도하게 차지하지 않도록 최대 2% 또는 8,000자 예산을 둔다고 설명한다. skill이 많으면 설명을 줄이거나 일부 skill을 생략할 수 있다는 점도 명시되어 있다. Claude Code 문서도 SKILL.md에 들어간 모든 line은 recurring token cost가 되므로 본문을 짧게 유지하고, 긴 자료는 supporting file로 분리하라고 권한다.

MCP는 또 다른 문제를 만든다. MCP server는 agent가 외부 tool과 data source에 접근하는 통로지만, server가 늘어나면 tool description이 context에 쌓이고, client마다 설정 위치와 형식도 달라진다. 그래서 MCP 관리는 "설치 수"가 아니라 "현재 agent에게 보여줄 tool set"을 관리하는 문제에 가깝다.

Skill 관리 도구

도구	성격	쓸 만한 상황	주의할 점
`gh skill`	GitHub CLI 공식 command	GitHub Copilot, GitHub repository, 조직 내 skill 배포가 중심일 때	GitHub Docs 기준 public preview이며 GitHub CLI 2.90.0 이상이 필요하다.
`npx skills`	Vercel Labs의 open agent skills tool	여러 agent target에 skill을 설치하고, project/global scope를 나누고 싶을 때	community skill은 출처와 code review를 별도로 봐야 한다.
`kcchien/skills-cli`	Claude Code/Desktop 중심 CLI	private Git repo에 skill을 모아두고 Claude Code와 Desktop에 배포할 때	repo 규모는 아직 작다. source repo, commit hash, install time 추적은 장점이다.
`xingkongliang/skills-manager`	GUI desktop manager	Cursor, Claude Code, Codex, Copilot 등 여러 coding tool의 skill을 눈으로 정리하고 싶을 때	개인용 GUI에는 좋아 보이지만, team governance와 CI audit은 별도 체계가 필요하다.
`mode-io/skill-manager`, `find-skills`, `skill-of-skills`류	skill을 찾거나 추천하는 meta skill/discovery 도구	어떤 skill이 있는지 탐색할 때	탐색 도구와 운영 도구를 구분해야 한다. 발견했다고 바로 설치하는 것은 위험하다.

개인 사용자는 gh skill이나 npx skills만으로도 충분히 시작할 수 있다. 다만 skill이 10개, 20개를 넘어가면 "설치되어 있음"과 "이 프로젝트에서 필요함"을 분리해야 한다. project scope, allowlist, 사용 빈도 기반 pruning이 필요해지는 지점이다.

Skill과 MCP를 함께 관리하는 package manager

Microsoft apm은 현재 가장 팀 운영에 가까운 후보로 보인다. 공식 문서는 apm을 AI agent의 dependency manager, 즉 agent context를 위한 npm 같은 도구로 설명한다. apm.yml에 skills, prompts, instructions, plugins, MCP servers를 선언하고, apm install로 GitHub Copilot, Claude Code, Cursor, OpenCode, Codex, Gemini, Windsurf, Kiro 같은 여러 harness에 같은 agent context를 배포하는 구조다.

특히 apm.lock.yaml이 중요하다. lockfile은 resolved dependency tree와 content hash를 고정하므로, 팀에서 "누가 어떤 skill/MCP 버전을 쓰고 있는가"를 추적할 수 있다. 문서상 hidden Unicode scan, transitive MCP 제한 같은 정책도 포함되어 있어 단순 설치 도구보다 운영 도구에 가깝다.

sx도 비슷한 문제의식에서 나온 것으로 보인다. Hacker News 논의에서 maintainer는 skills, MCP configs, slash commands, agents, hooks, rule files를 versioned package로 다루고, lockfile과 org/team/repo/individual scope를 지원한다고 설명했다. 다만 이 정보는 커뮤니티 논의 성격이 강하므로, 실제 도입 전에는 repository 상태와 유지보수성을 따로 확인해야 한다.

팀에서 쓸 때의 기본 기준은 다음처럼 잡는 편이 좋다.

global 설치를 최소화하고 project/repo scope를 기본값으로 둔다.
skill과 MCP의 source, version, commit을 lockfile로 고정한다.
transitive MCP나 자동 설치는 기본적으로 막고, 명시적 승인만 허용한다.
CI에서 skill/MCP diff와 보안 scan을 돌린다.
agent별 설정 파일을 직접 손으로 맞추지 말고 manifest에서 생성한다.

MCP 관리와 gateway 계층

MCP server가 몇 개 안 될 때는 Claude Code, VS Code, GitHub Copilot CLI 같은 client 내장 기능으로도 충분하다. Claude Code는 claude mcp add와 local/user/project scope를 제공하고, project scope의 .mcp.json을 version control에 넣을 수 있다. VS Code는 user/workspace mcp.json, gallery install, 특정 server나 tool enable/disable을 지원한다. GitHub Copilot CLI는 /mcp search로 GitHub MCP Registry에서 server를 찾는 흐름을 제공한다.

문제는 client가 늘어날 때다. 같은 MCP server라도 Claude, VS Code, Cursor, Codex, Gemini CLI가 각자 다른 설정 파일과 schema를 쓸 수 있다. 이때 mcpm.sh, mcp-get, mcpman, mcp-installer 같은 도구가 MCP server의 검색, 설치, 삭제, 상태 확인, client별 config 반영을 줄여준다.

하지만 MCP가 정말 많아지면 package manager만으로는 부족하다. community에서는 이를 context tax 또는 tool sprawl로 부른다. 한 Reddit 사용자는 /clear 직후 MCP tools가 83.3k tokens, 전체 context의 41.6%를 차지했다고 보고했다. 이는 anecdotal evidence지만, 사용하지 않는 tool description까지 model context에 들어가면 비용과 선택 오류가 커진다는 문제의식은 연구와도 맞닿아 있다.

이 단계에서는 다음 계층이 필요하다.

계층	역할	후보
Profile	프로젝트별로 켤 MCP server set을 다르게 둔다.	client 내장 project scope, `mcpm.sh` profile
Gateway/proxy	여러 MCP server를 한 endpoint 뒤에 두고 필요한 것만 노출한다.	`mcp-switchboard`, `semistrict/mcpman`, MCP gateway류
On-demand routing	요청에 맞는 tool 설명만 찾아 model에게 보여준다.	`Switchboard`, `hypertool-mcp`, retrieval 기반 MCP 연구
Audit/policy	어떤 tool이 호출되었고 어떤 권한을 썼는지 남긴다.	`mcp-switchboard`, enterprise gateway, CI scan

연구와 커뮤니티 근거

연구 쪽에서도 "tool을 많이 보여주면 agent가 더 똑똑해진다"는 단순한 가정은 지지되지 않는다.

RAG-MCP 논문은 MCP tool 수가 많아질수록 prompt bloat와 tool selection complexity가 커진다고 보고, 관련 tool description만 retrieval로 넣는 방식을 제안한다. 초록 기준으로 prompt token을 50% 이상 줄이고, tool selection accuracy를 43.13%로 개선했다고 보고한다. 비교 baseline은 13.62%다.

How Many Tools Should an LLM Agent See?는 tool registry가 20개에서 3,251개까지 커지는 상황을 다룬다. 논문은 tool 하나가 약 200 tokens라면 100개 후보만으로도 20K tokens가 소모된다고 지적한다. 또 올바른 tool이 후보에 제시되었는지, model이 그것을 골랐는지, 실제 실행이 성공했는지를 분리해서 평가해야 한다고 주장한다.

MetaTool benchmark는 21,127개 user query로 tool 사용 여부와 tool selection 능력을 평가한다. 이 계열의 연구는 "도구가 많을수록 좋다"가 아니라, 필요한 tool을 적절히 선별해 보여주는 구조가 필요하다는 쪽에 가깝다.

커뮤니티 논의도 비슷하다. Hacker News의 mcpman 논의는 MCP 설치가 여전히 JSON 수동 편집, client별 config 차이, version pinning 부재, health check 부재에 묶여 있다고 지적했다. sx 논의는 skill, MCP config, command, hook, rule file을 하나의 package management 대상으로 봐야 한다는 방향을 보여준다.

보안 관점

Skill과 MCP는 단순한 prompt snippet이 아니다. script 실행, filesystem 접근, credential 사용, network 호출, browser automation과 결합될 수 있다. 따라서 관리 도구를 고를 때는 설치 편의성만 보면 안 된다.

Snyk agent-scan은 agent component, MCP server, skill을 scan하는 도구다. Claude, Cursor, Windsurf, Gemini CLI, OpenCode, Codex 등 여러 agent 설정을 자동 발견하고, prompt injection, tool poisoning, toxic flow, skill vulnerability를 검사한다고 설명한다. 단, MCP config scan은 정의된 command를 실행할 수 있으므로 consent와 sandbox가 필요하다는 경고도 중요하다.

Snyk의 ToxicSkills 연구는 2026년 2월 5일 기준 ClawHub/skills.sh에서 3,984개 skill을 scan했고, 534개(13.4%)에서 critical issue, 1,467개(36.82%)에서 어떤 형태든 security issue를 찾았으며, 76개 confirmed malicious payload를 확인했다고 보고했다. vendor security research이므로 수치를 그대로 일반화하면 안 되지만, skill marketplace와 community skill을 supply chain으로 봐야 한다는 경고로는 충분히 중요하다.

OWASP의 MCP Tool Poisoning 설명은 악성 MCP tool response가 LLM context에 hidden instruction을 주입하는 indirect prompt injection 문제를 정리한다. VS Code 문서도 local MCP server가 임의 코드를 실행할 수 있으므로 신뢰하는 server만 추가하라고 경고한다. 특히 sandboxing은 macOS/Linux에는 제공되지만 Windows에는 적용되지 않는다고 설명되어 있어 Windows 사용자는 더 보수적으로 접근해야 한다.

도입 체크리스트

현재 설치된 skill과 MCP를 agent별로 목록화한다.
global, user, project scope를 분리하고 global 설치를 최소화한다.
프로젝트별로 필요한 MCP만 켜는 profile을 만든다.
skill/MCP source, version, commit, install time을 기록한다.
사용 빈도가 낮거나 중복되는 skill은 제거한다.
MCP tool description이 context에 얼마나 들어가는지 확인한다.
team 사용이면 manifest와 lockfile을 도입한다.
update 전후 diff를 review한다.
보안 scan, approval, audit log를 운영 절차에 넣는다.

Caveats / Uncertainty

GitHub star 수와 README 설명은 maturity의 보조 지표일 뿐이다. 실제 도입 전에는 release 주기, issue 응답, license, install script, permission model을 확인해야 한다.
Reddit, Hacker News 논의는 실사용 pain point를 보여주지만, 정량 근거는 아니다. community signal로만 보아야 한다.
Snyk 수치는 vendor security research이므로 독립 재현 여부와 sample bias를 감안해야 한다.
MCP gateway와 on-demand routing 계층은 방향성이 강하지만, 표준화와 client 호환성은 아직 변동 가능성이 크다.
2026년 7월 1일 기준 조사이므로 gh skill, apm, MCP Registry, VS Code/GitHub Copilot MCP 기능은 preview 상태나 문서가 바뀔 수 있다.

검증이 필요한 주장

skills-manager, mcpm.sh, mcp-switchboard, Switchboard의 실제 안정성은 README와 GitHub metadata만으로 판단하기 어렵다. 샘플 프로젝트에서 설치, update, rollback, config conflict를 직접 검증해야 한다.
sx는 HN 설명상 방향성이 중요하지만, 운영 문서와 release maturity를 별도 확인해야 한다.
RAG-MCP와 tool retrieval 연구의 수치는 benchmark 환경의 결과다. 실제 coding agent 환경에서 같은 효과가 나는지는 별도 실험이 필요하다.
Snyk ToxicSkills 수치는 community skill marketplace의 위험 신호로는 유용하지만, 모든 skill 생태계에 그대로 일반화하면 안 된다.

Sources

Source Fidelity Notes

Preserved key numbers: Codex initial skill list budget 2% 또는 8,000자, GitHub CLI 2.90.0 이상, skills-manager의 15개 이상 coding tool 지원과 약 2.7k stars, skills-cli의 작은 규모, Reddit의 83.3k tokens/41.6% context 사례, RAG-MCP의 50% 이상 token 절감과 43.13% 대 13.62% selection accuracy, How Many Tools의 20~3,251 tool registry와 100 tools 약 20K tokens 추정, MetaTool의 21,127 query, Snyk ToxicSkills의 3,984개 scan/534개 critical/13.4%/1,467개 issue/36.82%/76개 malicious payload.
Preserved frameworks / models: skill manager, agent context package manager, MCP package manager, MCP gateway/router, security scanner라는 네 층 구분을 유지했다.
Preserved templates / checklists: 개인·팀·MCP 과다·보안 환경별 추천 조합과 도입 체크리스트를 남겼다.
Omitted or compressed: 원문의 긴 repository별 설명, 일부 낮은 maturity 후보, community thread 세부 댓글은 공개 페이지에서 압축했다.
Omission risk: 특정 도구의 최신 star 수, release 상태, preview 여부는 빠르게 바뀔 수 있다. 도입 직전에는 각 repository와 공식 문서를 다시 확인해야 한다.

My Take

지금 단계에서 핵심은 "많은 skill/MCP를 한 번에 설치하는 도구"가 아니다. 좋은 운영 기준은 반대에 가깝다. 적게 켜고, 출처를 고정하고, 프로젝트별로 나누고, context에 실제 필요한 tool만 보여주고, 실행 권한이 있는 구성요소는 보안 scan과 review를 거치는 것이다.