CUBE.ai

개념정리

스킬 수집가가 되지 마세요: AI 코딩 에이전트의 스킬·MCP, 적게 깔고 말로 부리는 법

2026.10.18

전체 지도

요즘 숏폼 피드를 넘기다 보면 "개발자라면 꼭 깔아야 할 Claude Code 스킬 10가지", "이 스킬 모르면 손해" 같은 영상이 하루에도 몇 개씩 지나갑니다. 보고 나면 왠지 나만 뒤처진 것 같아서 일단 다 받아 두게 되죠. 그런데 수업에서 훈련생들 화면을 들여다보면 공통점이 하나 있습니다. 스킬은 수십 개 깔려 있는데, 실제로 쓰는 건 서너 개뿐이에요. 오늘은 바로 이 장면에서 출발합니다. "스킬 명령어를 전부 외워야 할까? 많이 깔수록 좋은 걸까?"

오늘 수업은 세 덩어리로 진행하겠습니다. 먼저 스킬과 MCP가 각각 무엇인지 짧게 정리하고, 설치만 해 둔 것들이 보이지 않는 곳에서 어떤 비용을 치르는지 확인합니다. 이어서 비슷한 MCP를 겹쳐 깔았을 때의 혼란과, 출처 모를 스킬을 받았을 때의 보안 위험을 살펴봅니다. 마지막으로 명령어를 외우는 대신 "말로 시키는" 방법과, 작업환경을 주기적으로 가볍게 유지하는 점검 루틴으로 마무리합니다.

결론을 살짝 먼저 말씀드리면, 스킬은 외워서 쓰는 단축키가 아니라 에이전트가 알아서 꺼내 쓰는 도구에 가깝습니다. 그래서 중요한 건 "얼마나 많이 아느냐"가 아니라 "무엇을 남겨 두느냐"예요. 정말 그런지는 하나씩 확인해 보겠습니다. 자, 우선 스킬과 MCP가 정확히 무엇인지부터 짚고 가볼까요?

1. 스킬과 MCP는 각각 무엇을 해 줄까?

지도에서 가장 먼저 놓인 출발점입니다. 수집 이야기를 하려면, 우리가 무엇을 수집하고 있는지부터 분명히 해야겠죠.

스킬과 MCP는 각각 무엇을 해 줄까?

스킬(Skill)은 SKILL.md라는 마크다운 파일 하나가 들어 있는 폴더입니다. 파일 맨 위에는 이름과 "언제 쓰는지"를 적은 설명(description)이 있고, 그 아래에 실제 작업 절차가 적혀 있어요. 필요하면 스크립트나 참고 문서를 같은 폴더에 함께 넣을 수 있습니다. Claude Code와 OpenAI Codex 모두 이 형식을 쓰고 있고, 두 도구 모두 agentskills.io의 공개 표준을 따르기 때문에 한쪽에서 만든 스킬을 다른 쪽에서 거의 그대로 쓸 수 있습니다.

MCP(Model Context Protocol)는 성격이 다릅니다. 에이전트를 Notion, GitHub, Figma 같은 바깥 서비스와 연결해 주는 표준 연결 규격이에요.

비유로 정리해 볼게요. 에이전트를 새로 들어온 신입 요리사라고 해 봅시다. 스킬은 주방 벽에 꽂힌 레시피 카드입니다. "김치찌개는 이 순서로 끓인다"처럼 어떻게 하는지를 알려 주죠. MCP는 주방 벽의 콘센트와 배관입니다. 냉장고, 오븐, 가스레인지처럼 무엇을 쓸 수 있는지를 연결해 줘요. 레시피 카드가 아무리 많아도 오븐이 연결돼 있지 않으면 굽지 못하고, 콘센트가 아무리 많아도 레시피가 없으면 무엇을 만들지 모릅니다.

여기서 꼭 기억해 둘 설계 원리가 하나 있습니다. 점진적 공개(progressive disclosure)라는 건데요, 세션이 시작될 때 에이전트는 스킬의 이름과 설명만 읽고, 본문은 실제로 필요해졌을 때 펼쳐 봅니다. 레시피 카드의 제목만 벽에 붙여 두고, 주문이 들어오면 그때 카드를 꺼내 읽는 식이죠. 덕분에 스킬은 "깔아 두기만 해도 공짜"처럼 느껴집니다. 그런데 정말 공짜일까요? 바로 다음 이야기입니다.

참고 자료(3)

2. 설치만 해 둔 스킬도 비용이 들까?

이제 지도의 두 번째 칸, "보이지 않는 비용" 구역으로 들어갑니다. 앞에서 스킬은 제목만 붙여 둔다고 했죠. 그 제목들이 붙는 벽에도 넓이가 있다는 게 오늘의 핵심입니다.

설치만 해 둔 스킬도 비용이 들까?

Claude Code는 세션을 시작할 때 설치된 스킬의 이름과 설명을 모은 목록(skill listing)을 컨텍스트에 넣습니다. 공식 문서에 따르면 이 목록에 배정된 공간은 모델 컨텍스트 창의 약 1%입니다. 스킬이 많아져서 이 공간을 넘치면 어떻게 될까요? 이름은 남기되, 덜 쓰는 스킬부터 설명을 잘라 냅니다. 설명이 잘린 스킬은 에이전트 입장에서 "이름만 있고 언제 쓰는지 모르는 카드"가 돼서, 정작 필요한 순간에 선택되지 않을 수 있어요.

Codex도 사정이 비슷합니다. 공식 문서에 "스킬이 많이 설치되면 설명부터 짧게 줄인다"고 적혀 있고, GitHub 이슈에는 설명이 잘리는 바람에 스킬을 찾지 못한다는 사용자 보고가 올라와 있습니다.

비유하자면 식당의 메뉴판입니다. 메뉴가 열 개일 때는 메뉴마다 "매콤한 국물, 2인 추천" 같은 설명이 붙어 있어요. 그런데 메뉴를 백 개로 늘리면 메뉴판 크기는 그대로라서 설명이 사라지고 이름만 빼곡해집니다. 손님(에이전트)은 "그래서 이게 뭔데?"를 모른 채 익숙한 메뉴만 시키게 되죠. 스킬을 많이 깔수록 오히려 각 스킬이 발견될 확률이 떨어지는 역설이 여기서 생깁니다.

한 번 불려 나온 스킬도 대가가 있습니다. Claude Code 문서는 스킬 본문이 일단 로드되면 이후 대화 내내 컨텍스트에 남아 있으니, 본문의 한 줄 한 줄이 반복되는 비용이라고 설명해요. 그러니 "혹시 몰라서" 깔아 두는 스킬은 메뉴판 자리를 차지하고, 길게 쓴 스킬은 테이블 자리를 차지하는 셈입니다.

참고 자료(3)

3. 비슷한 MCP를 여러 개 깔면 무슨 일이 생길까?

스킬의 비용을 봤으니, 이번엔 지도에서 바로 옆 칸인 MCP로 넘어가 보죠. 스킬이 레시피 카드였다면, MCP는 콘센트였습니다. 콘센트는 많을수록 좋을 것 같지만 말이죠.

비슷한 MCP를 여러 개 깔면 무슨 일이 생길까?

MCP 서버를 연결하면 그 서버가 제공하는 도구 정의(도구 이름, 설명, 입력 형식)가 모델에게 전달됩니다. 문제는 이게 도구를 쓰든 안 쓰든 매번 실린다는 점이에요. 한 개발자는 MCP 서버를 몇 개 연결했더니 첫 메시지를 입력하기도 전에 도구 정의만으로 약 8만 토큰이 차 있었다는 사례를 공유했습니다. 3천 개가 넘는 MCP 서버를 측정한 한 조사에서는 서버 하나당 도구 정의가 중간값 기준 약 1,900토큰이었고요.

다행히 Claude Code는 이 문제를 MCP Tool Search로 완화했습니다. 지금은 기본적으로 MCP 도구의 전체 정의를 미리 싣지 않고, 도구 이름과 서버 안내문만 올려 둔 뒤 필요할 때 검색해서 꺼내 씁니다. 스킬의 점진적 공개와 같은 발상이죠. 그래서 "토큰이 부족하다"는 문제는 예전보다 훨씬 덜해졌어요.

하지만 토큰보다 더 고치기 어려운 문제가 남습니다. 비슷한 일을 하는 도구가 겹치는 것입니다. 거실 탁자에 TV 리모컨이 세 개 있다고 생각해 보세요. 셋 다 "전원" 버튼이 있고, 하나는 셋톱박스용, 하나는 사운드바용, 하나는 예전 TV용입니다. 전원을 끄라는 말을 들은 사람은 어떤 리모컨을 집을지 망설이고, 가끔은 엉뚱한 기계를 끕니다. 에이전트도 똑같아요. GitHub 연동 MCP가 두 개, 브라우저 제어 도구가 세 개 있으면 매번 "어느 쪽을 써야 하지?"를 고민하게 되고, 같은 작업이 날마다 다른 경로로 처리됩니다. 결과가 들쭉날쭉해지는 거죠.

그래서 MCP를 추가하기 전에는 "이미 같은 일을 하는 연결이 있는가?"를 먼저 확인해야 합니다. 같은 서비스라면 공식 서버 하나만 남기는 것이 원칙입니다.

참고 자료(3)

4. 남이 만든 스킬, 그냥 받아도 괜찮을까?

지금까지는 "무거워진다", "헷갈린다" 수준의 문제였습니다. 지도의 이 칸은 분위기가 조금 다릅니다. 여기서는 "위험하다"를 이야기해야 하거든요.

남이 만든 스킬, 그냥 받아도 괜찮을까?

스킬은 그냥 문서처럼 보이지만, 그 안의 스크립트는 여러분 컴퓨터에서, 여러분 권한으로 실행됩니다. 그런데 GitHub나 커뮤니티 마켓플레이스에 올라온 스킬 대부분은 누구의 검수도 거치지 않았어요.

숫자로 보면 더 실감이 납니다. 보안 회사 Snyk는 2026년 2월, 공개 마켓플레이스의 스킬 약 4천 개를 검사해서 13%가 넘는 스킬에서 치명적 수준의 보안 문제를, 76개에서 실제 악성 코드를 확인했다고 발표했습니다. 같은 시기 학계에서는 약 9만 8천 개의 스킬을 실제로 실행해 검증한 결과 157개를 악성으로 확인한 논문이 나왔고요. 연초에는 한 마켓플레이스에서 정상 스킬처럼 위장한 악성 스킬 수백 개가 발견되기도 했습니다.

비유는 간단합니다. 길에서 주운 USB예요. 겉에는 "유용한 업무 자동화"라고 적혀 있지만, 꽂는 순간 무슨 일이 일어날지는 열어 보기 전까지 모릅니다. 숏폼 영상에서 "이거 깔면 좋아요"라는 말만 듣고 설치하는 건, USB를 주워서 회사 PC에 꽂는 것과 크게 다르지 않습니다.

Claude Code 문서도 비슷한 주의를 줍니다. 스킬의 allowed-tools 항목은 그 스킬이 실행될 때 특정 도구를 승인 없이 쓰게 해 주는데, 이 설정은 저장소를 신뢰하는지 여부와 관계없이 적용되므로 저장소에 들어 있는 스킬은 실행 전에 직접 검토하라고 안내하고 있어요.

설치 전 최소한의 점검은 세 가지면 됩니다.

  1. 출처: 공식 저장소(anthropics/skills, openai/skills)이거나 신뢰할 수 있는 조직의 것인가?
  2. 내용: SKILL.md와 scripts/ 폴더를 열어 봤는가? 외부로 데이터를 보내거나 무언가를 내려받는 명령이 있는가?
  3. 권한: allowed-tools에 필요 이상으로 넓은 권한(예: 모든 셸 명령)이 들어 있지 않은가?
참고 자료(4)

5. 스킬 명령어를 외우지 않아도 될까?

여기서부터 지도의 마지막 구역, "실전" 칸입니다. 앞에서 많이 까는 것의 비용과 위험을 봤으니, 이제 반대로 "적게 알고도 잘 쓰는 법"을 이야기할 차례예요.

스킬 명령어를 외우지 않아도 될까?

결론부터 말하면, 대부분은 외우지 않아도 됩니다. 1번 섹션에서 본 점진적 공개를 떠올려 보세요. 에이전트는 이미 모든 스킬의 이름과 설명을 알고 있고, 여러분의 요청이 그 설명과 맞으면 알아서 꺼내 씁니다. 슬래시 명령어(/skill-name)는 "이 스킬을 지금 당장 써"라고 못 박고 싶을 때 쓰는 지름길일 뿐이에요.

비유하면 잘 운영되는 식당의 단골 손님과 웨이터 관계입니다. 단골은 메뉴 번호를 외우지 않아요. "오늘은 얼큰한 거 먹고 싶어요"라고 말하면 웨이터가 맞는 메뉴를 골라 줍니다. 메뉴 번호를 외워야 하는 건 웨이터가 없는 자판기 식당뿐이죠.

그래서 실전에서는 명령어 목록 대신 요청 문장 몇 개를 손에 익혀 두면 충분합니다.

  • 작업 전 점검: "지금 설치된 스킬 중에 이 작업에 맞는 게 있는지 확인하고, 있으면 그걸로 진행해 줘."
  • 없을 때 추천만: "맞는 스킬이 없으면 검색해서 후보 2~3개를 추천만 해 줘. 출처와 권한 범위도 같이 알려 주고, 설치는 내가 결정할게."
  • 반복 작업 저장: "이 과정은 앞으로 반복할 것 같아. 방금 한 절차를 스킬로 저장해 줘."

세 번째 문장이 특히 중요합니다. Claude Code에는 skill-creator 플러그인이, Codex에는 $skill-creator가 기본으로 들어 있어서 대화 속 절차를 스킬 파일로 바꿔 줍니다. 남이 만든 범용 스킬을 받는 것보다, 내가 실제로 반복한 작업을 스킬로 굳히는 쪽이 훨씬 잘 맞고 안전하죠. Codex의 $skill-installer나 skills.sh 생태계의 find-skills처럼 "스킬을 찾아 주는 스킬"도 있으니, 탐색조차 말로 맡길 수 있습니다.

한 가지만 주의하세요. 두 번째 문장에 "설치는 내가 결정할게"를 붙인 이유는 4번 섹션 때문입니다. 찾는 건 에이전트에게 맡기되, 들이는 결정은 사람이 하는 게 원칙이에요.

그리고 "매번 반드시 지켜야 하는 규칙"은 스킬에 넣지 마세요. 스킬은 필요할 때만 꺼내 읽는 구조라서, 항상 지켜야 할 코드 스타일 같은 규칙은 CLAUDE.md나 훅(hook)에 두는 게 맞습니다. Claude Code 문서도 반드시 지켜져야 하는 규칙은 훅으로 옮기라고 권합니다.

참고 자료(3)

6. 내 작업환경을 가볍게 유지하려면 무엇을 점검할까?

드디어 지도의 마지막 칸입니다. 앞 섹션이 "새로 들이는 법"이었다면, 여기서는 "이미 들인 것을 정리하는 법"을 다룹니다.

내 작업환경을 가볍게 유지하려면 무엇을 점검할까?

비유는 공구함입니다. 처음 공구함을 사면 마트에 있는 공구를 다 담고 싶어지죠. 그런데 반년 쓰고 나면 손이 가는 건 드라이버, 줄자, 펜치 정도고, 나머지는 무게만 늘리면서 필요한 공구를 찾기 어렵게 만듭니다. 그래서 목수들은 주기적으로 공구함을 엎어서 "최근에 안 쓴 것"을 빼냅니다. 작업환경도 똑같이 하면 됩니다.

① 무엇이 깔려 있고 얼마를 쓰는지 확인하기

Claude Code에는 이 일을 해 주는 기본 기능이 있습니다. /doctor는 설치 상태를 점검하면서 안 쓰는 스킬·MCP 서버·플러그인을 컨텍스트 비용과 함께 보여 주고, /skill-doctor는 스킬마다 비용과 사용 횟수를 보여 주며 한 번도 호출되지 않은 스킬을 표시해 줍니다. /context로는 지금 컨텍스트를 무엇이 차지하는지 볼 수 있고요. 물론 이것도 외울 필요 없이 "지금 설치된 스킬이랑 MCP 중에 최근에 안 쓴 거 정리해 줘"라고 말하면 됩니다.

② 지우기 아까우면 끄기

바로 삭제가 부담스럽다면 단계적으로 줄이세요. Claude Code는 /skills 메뉴(설정의 skillOverrides)에서 스킬을 설명 없이 이름만, 내가 부를 때만, 완전히 끔 상태로 바꿀 수 있습니다. 직접 만든 스킬이라면 disable-model-invocation: true를 넣어 자동 호출 목록에서 빼는 방법도 있고요. Codex는 ~/.codex/config.toml의 [[skills.config]] 항목으로 삭제하지 않고 끌 수 있습니다. MCP 서버는 claude mcp remove <이름>으로 연결을 해제합니다.

③ 어디에 둘지 정하기

모든 프로젝트에 필요한 스킬만 개인 폴더(~/.claude/skills)에 두고, 특정 프로젝트용은 그 저장소의 .claude/skills에 두세요. 그러면 해당 프로젝트를 열 때만 로드되고, 팀원과도 자연스럽게 공유됩니다. 덧붙여 로컬과 클라우드의 차이도 알아 두면 좋습니다. 클라우드 세션은 내 컴퓨터의 개인 스킬 폴더를 읽지 않고, claude.ai 계정에 켜 둔 스킬과 저장소에 커밋된 스킬만 불러옵니다. "내 PC에선 되는데 클라우드에선 안 된다"는 혼란은 대부분 여기서 생겨요.

④ 주기 정하기

한 달에 한 번, 아래 세 질문으로 공구함을 엎어 보세요.

  • 지난 한 달 동안 한 번이라도 쓰였는가?
  • 같은 일을 하는 다른 스킬이나 MCP가 있는가?
  • 출처와 내용을 내가 설명할 수 있는가?

셋 중 하나라도 "아니요"라면 끄거나 지울 후보입니다.

참고 자료(3)

댓글

불러오는 중입니다…