서브에이전트 vs MCP 서버 vs 스킬: 각 Claude Code 확장을 언제 만들어야 하는가 (2026)

Claude Code에는 세 가지 확장 지점 — 스킬, 서브에이전트, MCP 서버 — 이 있으며, 각각 서로 다른 문제를 해결한다. 실제 시나리오와 시간을 낭비하게 만드는 안티패턴을 곁들여, 올바른 확장을 선택하기 위한 의사결정 프레임워크를 제시한다.

  • Claude Code
  • Agent SDK
  • MCP
  • CLI
  • Proprietary
  • 업데이트 2026-05-29

들어가며 #

2026년이 되면서 Claude Code에는 세 가지 뚜렷한 확장 방식 — 스킬, 서브에이전트, MCP 서버 — 이 생겼고, 우리가 가장 자주 받는 질문 하나는 “어느 걸 만들어야 하나요?“다. 혼란은 이해할 만하다: 셋 다 “Claude가 더 많은 일을 하게 만드는 방법"이고, 마케팅이 이들을 한데 뭉뚱그린다. 하지만 셋은 완전히 다른 세 개의 축 위에 놓여 있으며, 잘못된 것을 고르면 과도한 엔지니어링(마크다운 파일이면 될 일에 서버 한 대)에 빠지거나, 벽에 부딪힌다(데이터베이스에 실제로 닿지 못하는 스킬).

이 글은 의사결정 프레임워크를 제공한다. 각 확장 지점을 한 줄로 정의하고, 각각이 움직이는 축을 짚으며, 실제 시나리오 세 가지를 처음부터 끝까지 돌려 보고, 주말을 통째로 날리게 만드는 안티패턴을 지적한다. 커스텀 에이전트 작성MCP 서버 2026 랭킹을 이미 읽었다면, 이 글이 그것들을 하나로 엮어 주는 조각이다.

세 가지 확장 지점, 각 한 줄 #

  • 스킬 — Claude에게 어떤 일을 어떻게 하는지 가르친다. 패키지화된 지침, 플레이북, 체크리스트로, 관련 있을 때만 컨텍스트에 로드된다.
  • 서브에이전트 — 그 일을 누가 하는가. 자체 컨텍스트 윈도우를 가진 위임된 작업자로, 부모 대화를 가볍게 유지하기 위해 생성된다(서브에이전트 패턴 참고).
  • MCP 서버무엇에 닿을 수 있는가. 외부 시스템으로의 연결: 데이터베이스, API, SaaS 도구, 데이터 소스.

한 문장으로 말하면 혼란이 풀린다: 스킬은 행동을 바꾸고, 서브에이전트는 컨텍스트를 보호하며, MCP 서버는 역량을 더한다. 이들은 한 질문에 대한 세 가지 답이 아니다. 서로 다른 세 질문에 대한 답이다.

각각이 움직이는 축 #

스킬은 “지식” 축을 움직인다 #

스킬은 *“Claude가 우리의 특정 절차를 모른다”*에 대한 답이다. 당신의 릴리스 프로세스, 당신의 코드 리뷰 평가 기준, 당신의 인시던트 대응 런북 — 상황 의존적인 지식이다. 이걸 CLAUDE.md에 두고 싶지는 않을 것이다(그건 모든 상호작용마다 로드되어 기본 컨텍스트를 부풀린다); 작업이 요구할 때만 로드되기를 원할 것이다. 스킬은 트리거 설명이 달린 마크다운 파일이다; 작업이 매칭되면 상세 지침이 대화에 들어오고, 그렇지 않으면 비켜서 있는다.

서브에이전트는 “컨텍스트” 축을 움직인다 #

서브에이전트는 *“이 작업은 내 컨텍스트 윈도우를 터뜨릴 것이다”*에 대한 답이다. 지식은 이미 거기 있을 수도 있다; 문제는 그 작업을 인라인으로 하는 것 — 파일 30개를 읽고, 긴 탐색을 돌리는 것 — 이 당신이 정작 신경 쓰는 추론을 밀어내 버린다는 점이다. 서브에이전트는 그걸 별도 컨텍스트에서 실행하고 결론만 돌려준다. 역량에 관해서는 아무것도 바뀌지 않는다; 바뀌는 것은 누구의 작업 기억이 그 탐색의 비용을 치르느냐다.

MCP 서버는 “역량” 축을 움직인다 #

MCP 서버는 *“Claude가 이 시스템에 말 그대로 닿을 수 없다”*에 대한 답이다. 당신의 Postgres 데이터베이스, 당신의 내부 메트릭 API, 당신의 Stripe 계정, 당신의 Linear 보드. 아무리 스킬을 작성하거나 서브에이전트를 생성해도 데이터베이스 연결이 불려 나오지는 않는다 — 그건 진짜 새로운 역량이며, 역량은 MCP 서버에서 온다. 이것은 또한 셋 중 가장 무겁다: 배포, 인증, 버전 관리를 직접 떠안아야 하는 별도 프로세스다.

의사결정 프레임워크 #

다음을 순서대로 물어보라:

  1. “Claude가 지금은 닿을 수 없는 시스템에 닿아야 하는가?”MCP 서버. (데이터베이스, API, SaaS, 외부 데이터.)
  2. “Claude가 이미 그 역량은 있지만, 그 작업이 내 컨텍스트를 부풀릴까?”서브에이전트. (대규모 탐색, 병렬 리서치, 격리된 실험.)
  3. “Claude가 역량과 컨텍스트는 있지만, 우리만의 특정 방식을 모르는가?”스킬. (플레이북, 체크리스트, 절차.)
문제가 …라면만들 것:이유
시스템에 닿을 수 없음MCP 서버새로운 역량
컨텍스트가 폭발할 것서브에이전트작업 기억 보호
우리 절차를 모름스킬상황 의존적 지식
표준이 결코 강제되지 않음서브에이전트(커스텀 에이전트)실행 가능하고 버전 관리되는 리뷰

당신의 문제를 푸는 가장 저렴한 선택지가 거의 언제나 정답이다. 마크다운 파일(스킬 또는 서브에이전트)은 일을 해낼 수 있는 한, 배포된 서비스(MCP 서버)를 이긴다.

실제 시나리오 1: “우리 코드베이스를 SQL 인젝션에 대해 감사하라” #

  • 역량? 코드 읽기 — Claude는 이미 갖고 있다. MCP 서버 불필요.
  • 컨텍스트? 코드베이스 전체를 감사하려면 수십 개 파일을 읽어야 한다. 그건 부모를 부풀릴 것이다. → 서브에이전트.
  • 절차? 감사가 OWASP의 특정 체크리스트를 따르기를 원한다. → 스킬(또는 체크리스트를 security-auditor 커스텀 에이전트의 시스템 프롬프트에 구워 넣기).

답: 체크리스트를 시스템 프롬프트에 인코딩한 security-auditor 서브에이전트. 하나의 아티팩트, 두 개의 축 커버. 서버 없음.

실제 시나리오 2: “지난달에 어떤 고객이 이탈했는지 보여달라” #

  • 역량? 그 데이터는 당신의 웨어하우스에 있다. Claude는 닿을 수 없다. → MCP 서버(웨어하우스/SQL MCP).
  • 컨텍스트? 큰 결과 집합은 노이즈가 될 수 있다. → 요약만 돌려주는 서브에이전트 안에서 쿼리를 실행.
  • 절차? “이탈(churn)“은 당신 회사에서 특정한 정의를 가진다. → 이탈 쿼리 로직을 문서화한 스킬.

답: 셋 다, 조합해서. MCP 서버가 연결하고, 스킬이 “이탈"을 정의하며, 서브에이전트가 깔끔하게 실행한다. 이것이 전형적인 풀스택 사례다.

실제 시나리오 3: “모든 릴리스가 우리 체크리스트를 따르도록 보장하라” #

  • 역량? Git, 파일 읽기 — 이미 있다. 서버 없음.
  • 컨텍스트? 가볍다. 보호를 위해 엄밀히 서브에이전트가 필요하지는 않다.
  • 절차? 전적으로 이게 핵심 — 당신 팀의 릴리스 단계들. → 스킬, 또는 강제하고 보고서를 만들기를 원한다면 커스텀 에이전트.

답: 스킬(또는 릴리스 게이트 커스텀 에이전트). 여기서 MCP 서버를 만드는 것은 순전한 과도 엔지니어링이다.

안티패턴 #

  • 모든 것을 MCP 서버로 만드는 함정. 문서화 문제를 풀자고 서비스를 출시하는 것. 외부 시스템에 연결하는 게 아니라면, 아마 서버는 필요 없다. (진짜로 서버가 정당화되는 경우가 무엇인지 보려면 MCP 서버 레지스트리를 둘러보라.)
  • 비대해진 CLAUDE.md. 모든 절차를 상시 작동 컨텍스트에 쑤셔 넣는 것. 상황 의존적 플레이북은 스킬로 옮겨 기본 컨텍스트를 날카롭게 유지하라.
  • 거대 서브에이전트. “모든 걸 하는” 서브에이전트는 기억력만 더 나쁜 부모일 뿐이다. 관심사별로 쪼개라.
  • 역량이 필요했던 스킬. Claude가 메트릭에 닿을 수 없는데 “우리 메트릭을 분석하라"를 위한 아름다운 스킬을 작성하는 것. 어떤 지침도 빠져 있는 MCP 연결을 대체하지 못한다.

원칙 #

세 가지 확장 지점은 세 가지 리소스에 대응한다: 지식(스킬), 컨텍스트(서브에이전트), 역량(MCP 서버). 당신이 실제로 부족한 리소스가 무엇인지 진단하면, 선택은 저절로 정해진다. 대부분의 팀은 MCP 서버가 강력하게 들린다는 이유로 그쪽으로 과하게 손을 뻗지만, 마크다운 파일이면 점심 전에 똑같은 결과를 출시했을 것이다. 당신이 막혀 있는 축을 움직이는 가장 가벼운 것을 만들어라.

프로덕션 준비된 Claude Code 구축하기 #

세 계층 모두를 — 특히 MCP 서버를 — 규모 있게 돌리려면 안정적인 인프라가 필요하다:

  1. MCP 서버와 CI를 위한 신뢰할 수 있는 호스트. MCP 서버는 장시간 실행되는 프로세스다; 계속 떠 있는 머신이 필요하다. HTStack — 저지연 중국 본토 접속과 안정적인 BGP를 갖춘 홍콩 VPS. dibi8.com을 호스팅하는 바로 그 IDC로, 우리가 직접 MCP 서버와 에이전트 파이프라인을 돌리는 곳이다. 월 $5-12 가성비 티어.

  2. 병렬 계층을 위한 클라우드 여유 공간. 서브에이전트가 펼쳐지고 MCP 서버가 나란히 돌아갈 때, 여유 CPU가 필요하다. DigitalOcean — 14개 이상의 리전에서 60일간 $200 무료 크레딧.

  3. 스킬 번들. 스킬/서브에이전트/서버 구분을 가장 빠르게 체득하는 방법은 동작하는 예제를 연구하는 것이다. 우리는 실전 검증된 스킬 다섯 개를 Gumroad에서 $19 번들로 패키지했다 — 화면 구석의 떠 있는 CTA를 보라 — 커스텀 에이전트 정의와 세 계층을 모두 조합하는 오케스트레이터 프롬프트가 포함된다.

함께 읽기 #

결론 #

“스킬이냐, 서브에이전트냐, MCP 서버냐?“를 마치 경쟁하는 것처럼 묻는 걸 멈춰라. 대신 이렇게 물어라: 나는 지식이 부족한가, 컨텍스트가 부족한가, 역량이 부족한가? 지식 → 스킬. 컨텍스트 → 서브에이전트. 역량 → MCP 서버. 풀스택 사례는 셋 모두를 계층으로 쌓아 쓴다. 그리고 의심스러울 때는, 당신의 축을 움직이는 가장 저렴한 아티팩트를 만들어라 — 마크다운 파일은 가능한 한 언제나 배포된 서비스를 이긴다.

💬 댓글 토론