Claude Code에서 MCP·subagents·skills를 한꺼번에 붙이면 왜 느려질까 2026 — 자동화 팀 구성 전 분리 기준

2026년 4월 18일 기준으로 Claude Code의 MCP, subagents, skills, slash commands는 모두 자동화를 강하게 만드는 장치다. 그런데 운영 판단은 반대에서 출발해야 한다. 한꺼번에 붙이면 자동화 팀이 빨라지는 게 아니라, 먼저 느려질 가능성이 크다.

도구가 많아져서 느린 것이 아니다.

역할 경계가 흐려져서 느리다.

권한 경계가 섞여서 느리다.

컨텍스트가 예상보다 오래 남아서 느리다.

디버깅할 때 “누가 무엇을 호출했는지” 추적할 표식이 부족해서 느리다.

Claude Code 자동화 팀을 만들 때 가장 흔한 착각은 이거다.

“MCP도 붙이고, subagent도 만들고, skill도 넣고, slash command도 만들면 거의 팀처럼 돌아가겠지?”

겉보기에는 맞다.

하지만 실제 운영에서는 질문이 바뀐다.

“이 작업은 외부 시스템 연결 문제인가?”

“별도 컨텍스트로 분리해야 하는 문제인가?”

“반복 절차를 표준화해야 하는 문제인가?”

“한 줄 명령으로 자주 부르는 문제인가?”

이 네 질문을 구분하지 않으면 자동화 팀은 금방 무거워진다.

오늘 글은 유튜브 요약형으로 “MCP 핵심 정리”를 반복하지 않는다.

대신 Claude Code에서 MCP, subagents, skills, slash commands를 동시에 붙이기 전에 써먹을 수 있는 운영 분기표로 재가공한다.

자동화 팀 구성 전 기준표다.

말하자면 “붙이기 전에 멈추는 기술”이다.

꽤 멋없어 보이지만, 운영에서는 이쪽이 돈을 아낀다.

핵심 판단

Claude Code에서 자동화가 느려지는 가장 큰 이유는 기능 부족이 아니다.

기능을 같은 층위로 취급하는 것이다.

MCP는 외부 도구, 데이터베이스, API를 Claude Code에 연결하는 통로다.

subagent는 특정 목적을 가진 별도 작업자다.

skill은 반복 절차와 참고 자료를 묶어 Claude가 필요할 때 꺼내 쓰는 실행 지침이다.

slash command는 사람이 명시적으로 호출하기 쉬운 짧은 명령 인터페이스다.

이 네 가지는 비슷해 보여도 서로 다른 질문에 답한다.

MCP의 질문은 “어디에 연결할까?”다.

subagent의 질문은 “누가 분리해서 처리할까?”다.

skill의 질문은 “어떤 절차를 재사용할까?”다.

slash command의 질문은 “어떤 호출을 짧게 만들까?”다.

이 질문을 섞으면 설계가 무거워진다.

예를 들어 Notion, GitHub, Sentry, PostgreSQL MCP를 모두 붙이고, 코드리뷰 subagent와 리서치 subagent를 만들고, 블로그 skill과 배포 skill을 얹고, /review, /deploy, /content-plan 같은 명령을 동시에 등록했다고 하자.

처음에는 멋있다.

하지만 어느 순간부터 Claude Code는 매번 더 많은 선택지를 훑는다.

어떤 MCP 도구를 써야 하는지 판단해야 한다.

어떤 subagent로 위임할지 판단해야 한다.

어떤 skill을 불러야 하는지 판단해야 한다.

어떤 slash command가 호출 가능한지 문맥에 올라올 수 있다.

권한도 따라온다.

OAuth도 따라온다.

.mcp.json 승인도 따라온다.

MCP 출력량 경고도 따라온다.

결론은 단순하다.

자동화 팀은 “많이 붙이기”가 아니라 “분리 기준을 먼저 세우기”에서 시작해야 한다.

4개 구성요소를 같은 말로 부르면 망한다

Claude Code 자동화를 설명할 때 MCP, subagents, skills, slash commands가 한 문장에 묶이는 경우가 많다.

그 자체가 문제는 아니다.

문제는 네 요소를 모두 “에이전트 기능”으로 뭉뚱그리는 순간 생긴다.

운영 관점에서는 각 요소의 비용 구조가 다르다.

구성요소	본질	늘어나는 비용	적합한 사용처
MCP	외부 시스템 연결	권한, 인증, 출력량, 서버 상태	DB 조회, 이슈 트래커, 모니터링, SaaS 액션
subagent	별도 컨텍스트 작업자	시작 지연, 요약 손실, 위임 추적	긴 조사, 로그 분석, 병렬 리서치, 권한 제한 작업
skill	재사용 절차	컨텍스트 잔류, 자동 호출 오탐, 관리 문서화	반복 워크플로우, 검증 체크리스트, 스크립트 포함 작업
slash command	명시 호출 인터페이스	명령 목록, 설명 예산, 권한 규칙	자주 쓰는 짧은 프롬프트, 수동 트리거, 운영 루틴

이 표 하나만 놓고 봐도 답이 나온다.

외부 데이터를 읽어야 하면 MCP다.

대화창을 더럽히지 말아야 하면 subagent다.

반복 절차를 표준화해야 하면 skill이다.

내가 직접 자주 치는 명령이면 slash command다.

반대로 말하면 이렇다.

외부 연결이 필요 없는 작업에 MCP를 붙이면 관리 포인트만 늘어난다.

짧은 수정 작업에 subagent를 붙이면 시작 비용이 더 커진다.

한 번 쓸 프롬프트를 skill로 만들면 문서만 늘어난다.

복잡한 다단계 워크플로우를 slash command 하나로 우겨 넣으면 유지보수가 어려워진다.

자동화 설계에서 중요한 건 “가능하냐”가 아니다.

“이 복잡도를 매일 갚을 의향이 있냐”다.

MCP는 연결 비용이다

MCP는 Claude Code에 외부 도구와 데이터 소스를 연결하는 표준이다.

Anthropic 문서 기준으로 Claude Code는 MCP를 통해 이슈 트래커, 모니터링 대시보드, 데이터베이스, API 같은 외부 시스템을 직접 읽고 다룰 수 있다.

즉 MCP는 똑똑한 프롬프트가 아니다.

연결면이다.

연결면은 편하지만, 운영 비용이 따라온다.

첫째, 스코프가 있다.

Claude Code MCP 서버는 local, project, user 범위로 구성할 수 있다.

local은 현재 프로젝트에서만 쓰며 개인 설정에 가깝다.

project는 프로젝트 루트의 .mcp.json에 저장되어 팀과 공유된다.

user는 여러 프로젝트에서 개인적으로 쓴다.

이 스코프 선택은 자동화 팀 설계에서 꽤 중요하다.

개인 실험용 MCP를 project scope로 올리면 팀 전체 승인과 보안 검토 문제가 된다.

반대로 팀 공통 도구를 user scope로만 쓰면 재현성이 떨어진다.

둘째, project scope는 승인 흐름이 있다.

공식 문서에 따르면 .mcp.json에 들어간 project-scoped 서버는 보안상 사용 전 승인을 요구한다.

이건 귀찮은 절차가 아니다.

팀원이 같은 도구를 쓰게 만드는 대신, 누가 어떤 외부 연결을 신뢰할지 확인하는 문턱이다.

셋째, OAuth가 있다.

원격 MCP 서버가 인증을 요구하면 /mcp에서 OAuth 흐름을 진행할 수 있다.

이때 토큰, 권한 범위, 콜백, 조직 정책이 운영 이슈가 된다.

넷째, 출력량 제한이 있다.

Claude Code MCP 문서에는 MCP 도구 출력이 10,000 토큰을 넘으면 경고를 표시하고, 기본 최대 출력은 25,000 토큰이라고 안내된다.

이 수치는 단순한 옵션이 아니다.

MCP가 느려지는 순간을 알려주는 운영 신호다.

DB에서 너무 많이 가져오거나, 모니터링 로그를 그대로 밀어 넣거나, 이슈 목록을 과하게 반환하면 MCP는 “연결”이 아니라 “컨텍스트 폭탄”이 된다.

다섯째, 서버 상태가 있다.

HTTP나 SSE 서버는 연결이 끊기면 재연결 로직이 작동할 수 있지만, local stdio 서버는 로컬 프로세스 운영 이슈가 된다.

서버가 죽었는지, 인증이 끊겼는지, 출력이 너무 큰지, 프롬프트가 잘못됐는지 구분해야 한다.

여기서 운영 판단이 나온다.

MCP는 “외부 시스템에 붙어야만 가치가 생기는 작업”에만 붙인다.

파일 몇 개 읽고 정리하는 작업이라면 MCP가 아니라 기본 파일 도구, skill, subagent로 충분한 경우가 많다.

subagent는 분리 비용이다

subagent는 작은 비서 이름표가 아니다.

공식 문서 기준으로 subagent는 특정 유형의 작업을 처리하는 전문 AI assistant이며, 자체 context window, custom system prompt, 특정 tool access, 독립 permission으로 동작한다.

이 구조는 강력하다.

긴 검색 결과, 로그, 파일 내용처럼 메인 대화에 남길 필요가 없는 작업을 별도 컨텍스트에서 처리하고 요약만 돌려받을 수 있다.

그래서 subagent는 컨텍스트 절약 장치다.

동시에 지연 장치이기도 하다.

왜냐하면 subagent는 새로 시작한다.

메인 대화가 이미 알고 있는 미묘한 맥락을 그대로 들고 가지 않는다.

필요한 파일을 다시 찾아야 한다.

작업 범위를 다시 해석해야 한다.

결과는 요약으로 돌아온다.

이 요약 과정에서 유용한 디테일이 사라질 수 있다.

Anthropic 문서도 main conversation을 써야 하는 경우를 따로 제시한다.

자주 왕복해야 하는 작업, 계획에서 구현과 테스트까지 이어지는 작업, 빠른 타깃 수정, 지연이 중요한 작업은 메인 대화가 낫다.

이 말은 꽤 현실적이다.

짧은 버그 수정에 subagent를 붙이면 “직원이 늘어서 빨라지는” 게 아니라 “회의가 하나 더 생기는” 느낌이 된다.

반대로 subagent가 빛나는 상황도 분명하다.

인증 모듈, DB 모듈, API 모듈을 병렬로 조사해야 한다.

로그가 너무 길어서 메인 대화를 오염시키고 싶지 않다.

코드 리뷰어는 읽기 전용 도구만 쓰게 하고 싶다.

데이터베이스 검증자는 조회만 가능하게 제한하고 싶다.

이런 경우 subagent는 좋다.

하지만 한 가지 더 봐야 한다.

subagent 여러 개가 자세한 결과를 한꺼번에 반환하면, 결국 메인 대화 컨텍스트를 다시 먹는다.

분리해도 요약이 길면 비용은 돌아온다.

따라서 subagent의 운영 원칙은 이거다.

작업을 분리할 때는 “돌아올 결과의 크기”까지 같이 설계한다.

skills는 절차 비용이다

skills는 Claude Code가 기능을 배우는 방식이다.

공식 문서 기준으로 SKILL.md에 instructions를 작성하면 Claude가 관련 상황에서 이를 toolkit으로 사용한다.

사용자가 /skill-name으로 직접 호출할 수도 있다.

중요한 장점은 skill 본문이 항상 통째로 들어가는 게 아니라, 사용될 때 로드된다는 점이다.

긴 참고 자료나 절차를 매번 대화에 붙여 넣지 않아도 된다.

하지만 skill도 공짜가 아니다.

skill을 호출하면 그 내용은 대화에 들어오고, 이후 세션 동안 남는다.

문서에 따르면 자동 압축 이후에도 최근 skill invocation 일부가 다시 붙을 수 있다.

또한 subagent의 skills 필드로 skill을 미리 넣으면, 전체 skill content가 시작 시 주입된다.

이건 정말 중요하다.

skill은 “필요할 때 꺼내 쓰는 절차”일 때 가볍다.

반대로 subagent마다 skill을 잔뜩 preloaded로 넣으면 시작부터 컨텍스트가 무거워진다.

자동화 팀을 만들 때 흔한 실수가 있다.

블로그 작성 skill, SEO skill, 이미지 skill, 발행 skill, QC skill을 모두 subagent에 넣는다.

그리고 그 subagent를 여러 개 만든다.

이러면 각 worker가 시작할 때부터 비슷한 참고 자료를 들고 출발한다.

겉으로는 전문성이 늘어난다.

실제로는 컨텍스트 기본요금이 오른다.

skill은 반복 절차가 명확할 때만 만든다.

예를 들어 “블로그 초안 작성”은 skill이 될 수 있다.

“배포 전 체크리스트”도 skill이 될 수 있다.

“PR 요약을 위해 GitHub CLI 결과를 동적으로 주입”하는 것도 skill 패턴에 맞는다.

하지만 “가끔 쓰는 프롬프트 조각”은 skill보다 slash command가 나을 수 있다.

또 “외부 DB에서 데이터를 가져온다”는 skill이 아니라 MCP가 맞을 수 있다.

skills의 분리 기준은 절차다.

같은 절차를 반복하고, 그 절차가 문서·스크립트·템플릿을 포함해야 한다면 skill로 만든다.

그 외에는 먼저 작게 둔다.

slash commands는 호출 비용이다

slash commands는 빠른 호출 인터페이스다.

Claude Code에는 /agents, /mcp, /permissions, /model, /compact 같은 built-in command가 있다.

/agents는 subagent 관리에 쓴다.

/mcp는 MCP 서버 연결 상태 확인, OAuth 인증, 토큰 관리, 도구와 prompt 확인에 쓴다.

custom command도 만들 수 있다.

최근 Claude Code 문서 흐름에서는 custom commands가 skills와 통합되어, .claude/commands/deploy.md와 .claude/skills/deploy/SKILL.md가 모두 /deploy 형태로 동작할 수 있다고 안내한다.

즉 예전식 command와 skill의 경계가 일부 합쳐졌다.

그렇다고 slash command를 전부 skill처럼 써야 한다는 뜻은 아니다.

slash command는 “명시적으로 내가 호출하는 짧은 루틴”에 잘 맞는다.

예를 들어 /review-this, /daily-note, /release-check 같은 명령은 좋다.

하지만 복잡한 운영 흐름을 slash command 하나에 계속 붙이면 어느 순간 내부 절차가 보이지 않는다.

또 하나의 비용은 명령 메타데이터다.

SlashCommand tool은 custom slash command의 metadata를 컨텍스트에 올릴 수 있고, 문서에는 character budget 제한이 언급된다.

명령이 많아지면 Claude가 볼 수 있는 명령 설명이 일부로 제한될 수 있다.

또 MCP prompt도 slash command처럼 나타날 수 있다.

MCP 서버가 prompt를 노출하면 /mcp__servername__promptname 형식으로 Claude Code에서 사용할 수 있다.

이건 편하다.

하지만 MCP prompt, custom command, skill invocation이 모두 / 아래 섞이면 사용자는 “명령 팔레트”를 운영해야 한다.

운영 팀이 커질수록 이름 규칙이 필요해진다.

마지막으로 MCP permission wildcard 주의가 있다.

slash commands 문서 계열에서는 MCP 권한 설정에서 mcp__github__* 같은 wildcard 방식이 지원되지 않는다고 안내된다.

서버 전체를 승인하려면 mcp__github처럼 서버 이름을 쓰고, 특정 도구만 승인하려면 각 도구를 개별 지정하는 식이다.

이 부분은 실제 운영에서 자주 삐끗한다.

권한 규칙을 glob처럼 생각하면 기대와 다르게 동작할 수 있다.

slash command의 원칙은 간단하다.

사용자가 자주 직접 부르는 짧은 시작점이면 command로 둔다.

Claude가 상황에 맞게 자동으로 발견해야 하는 복잡 절차면 skill로 둔다.

외부 prompt가 MCP 서버에서 오는 경우에는 MCP prompt command로 받아들이되, 이름과 권한을 따로 관리한다.

자동화 팀 구성 전 운영 분기표

아래 표는 실제로 Claude Code 자동화 팀을 만들기 전에 쓰기 좋은 분기표다.

기능 이름보다 질문을 먼저 본다.

운영 질문	예	선택	붙이지 말아야 할 것
외부 시스템의 최신 데이터가 필요한가?	GitHub PR, Sentry 이슈, Notion DB, PostgreSQL 조회	MCP	단순 skill 문서화만으로 해결하려 하지 않기
작업 출력이 길고 메인 대화에 남길 필요가 없는가?	로그 5만 줄 분석, 코드베이스 조사, 모듈별 리서치	subagent	메인 대화에 전체 결과 붙이기
같은 절차를 반복하며 체크리스트·템플릿·스크립트가 필요한가?	블로그 QC, 배포 점검, PR 요약	skill	매번 긴 프롬프트 붙여넣기
사람이 명시적으로 자주 호출하는가?	/mcp, /agents, /publish-check, /daily-review	slash command	복잡한 다단계 지식 베이스를 command 하나에 밀어넣기
권한을 좁혀야 하는가?	읽기 전용 리뷰어, DB 조회 전용 검증자	subagent tool 제한 또는 permission	모든 worker에게 전체 도구 상속
팀과 동일 설정을 공유해야 하는가?	공통 GitHub MCP, 공통 배포 루틴	project scope .mcp.json, project skill	개인 user scope에만 숨겨두기
실험 단계인가?	새 MCP 서버, 임시 자동화	local scope, 개인 skill	바로 project scope로 공유
결과가 자주 10,000 토큰을 넘는가?	대량 로그, 대량 DB row, 긴 PR diff	쿼리 축소, 요약 subagent, 출력 제한	MCP를 그대로 넓게 호출
자동 호출이 자주 빗나가는가?	skill이 엉뚱한 때 발동	description 수정, manual invocation, disable-model-invocation	skill을 계속 추가
디버깅 경로가 불명확한가?	누가 어떤 도구를 호출했는지 모름	명령명·agent명·MCP명 규칙화	비슷한 이름의 command와 skill 양산

이 표에서 가장 중요한 줄은 “결과가 자주 10,000 토큰을 넘는가?”다.

MCP 문서의 output warning threshold는 좋은 운영 경계선이다.

10,000 토큰 경고가 반복되면 도구가 강한 게 아니라 쿼리가 넓은 것이다.

그때는 MCP 서버를 늘릴 게 아니라 질문을 줄여야 한다.

필터를 넣어야 한다.

날짜 범위를 줄여야 한다.

필드 수를 줄여야 한다.

필요하면 subagent에게 대량 조사 후 요약만 돌려보내게 해야 한다.

자동화는 많이 가져오는 능력이 아니라 적게 가져오는 능력에서 빨라진다.

지연이 생기는 6가지 경로

Claude Code 자동화 팀이 느려지는 경로는 대체로 여섯 가지다.

첫째, 연결 지연이다.

MCP 서버가 원격 HTTP라면 네트워크, 인증, 서버 응답 시간이 붙는다.

SSE는 문서상 deprecated 흐름으로 안내되므로 새 연결은 HTTP 우선으로 보는 편이 낫다.

local stdio 서버는 로컬 프로세스 시작과 환경변수 문제가 붙는다.

둘째, 인증 지연이다.

OAuth가 필요한 MCP 서버는 /mcp에서 인증해야 한다.

토큰이 만료되거나 권한 범위가 부족하면 작업이 멈춘다.

자동화 팀 입장에서는 “일을 못 하는 worker”가 아니라 “인증 대기 중인 연결”일 수 있다.

셋째, 선택 지연이다.

사용 가능한 MCP 도구, subagent, skill, slash command가 많아질수록 Claude는 어떤 도구를 쓸지 판단해야 한다.

설명이 애매하면 잘못 고르거나 추가 탐색을 한다.

넷째, 컨텍스트 지연이다.

skill description, command metadata, 호출된 skill 내용, subagent 결과 요약, MCP 출력이 모두 문맥 비용을 만든다.

특히 skill은 호출 후 대화에 남을 수 있고, subagent 결과도 결국 메인 대화로 돌아온다.

다섯째, 권한 지연이다.

project scope .mcp.json 승인, MCP OAuth, tool permission, subagent tool access, skill allowed-tools가 서로 다른 층위에서 작동한다.

하나라도 막히면 자동화가 “느린 것처럼” 보인다.

실제로는 허가 대기일 때가 많다.

여섯째, 디버깅 지연이다.

오류가 났을 때 원인이 MCP 서버인지, subagent prompt인지, skill 절차인지, slash command argument인지 찾아야 한다.

이름 규칙이 없으면 이 단계가 제일 오래 걸린다.

권한은 한 곳에서 끝나지 않는다

Claude Code 자동화 팀에서 권한은 단일 스위치가 아니다.

MCP에는 서버 연결과 인증이 있다.

project scope라면 .mcp.json 승인도 있다.

remote MCP라면 OAuth가 있다.

subagent에는 tool access와 permission mode가 있다.

skill에는 allowed-tools가 있다.

slash command에는 SlashCommand tool 권한과 command별 invocation 설정이 있다.

여기서 중요한 점은 “허용”과 “제한”을 구분하는 것이다.

skill의 allowed-tools는 해당 skill이 활성화될 때 특정 도구 사용을 pre-approve하는 성격이지, 전체 도구를 제한하는 장치가 아니다.

제한은 permission settings 쪽에서 설계해야 한다.

subagent의 tools 설정은 더 직접적이다.

읽기 전용 reviewer라면 Read, Glob, Grep 정도로 제한할 수 있다.

MCP 권한은 서버 전체 승인과 특정 tool 승인 사이에서 골라야 한다.

여기서 wildcard를 기대하면 위험하다.

mcp__github__*처럼 쓰면 된다고 생각하기 쉽지만, slash commands 문서 계열에서는 MCP permissions에서 wildcard 미지원이라고 안내한다.

서버 전체는 mcp__github, 특정 도구는 mcp__github__get_issue처럼 분리해서 생각하는 편이 안전하다.

운영팀 기준으로는 권한을 이렇게 나누면 된다.

개인 실험은 local scope다.

팀 공통 연결은 project scope다.

민감한 토큰은 user scope 또는 환경변수로 관리한다.

읽기 전용 worker는 subagent tool 제한으로 묶는다.

반복 절차의 편의 권한은 skill allowed-tools로 줄인다.

조직 차원의 금지는 permission deny 규칙으로 둔다.

권한을 기능 안에 숨기지 말자.

권한은 별도의 운영 설계다.

컨텍스트는 사라지지 않는다

Claude Code에서 컨텍스트 비용은 눈에 잘 안 보인다.

그래서 무섭다.

MCP 출력은 결과로 들어온다.

subagent 결과는 요약으로 돌아온다.

skill은 호출되면 대화에 들어오고 남을 수 있다.

slash command description과 metadata도 예산을 먹을 수 있다.

각각은 작아 보인다.

하지만 자동화 팀을 만들면 누적된다.

예를 들어 블로그 자동화 팀을 생각해보자.

리서치 MCP가 웹이나 DB에서 자료를 가져온다.

리서치 subagent가 요약한다.

작성 skill이 템플릿을 로드한다.

SEO skill이 제목 규칙을 로드한다.

QC skill이 채널 규칙을 로드한다.

발행 slash command가 마지막에 호출된다.

구조는 멋지다.

하지만 모든 단계가 결과를 충분히 줄이지 않으면 최종 worker는 앞선 모든 흔적을 들고 일한다.

그럼 느려진다.

컨텍스트는 “많이 기억하는 힘”이 아니라 “필요한 것만 남기는 설계”가 필요하다.

실전에서는 세 가지 규칙이면 충분하다.

첫째, MCP 결과는 원문 전체보다 필터된 필드로 받는다.

둘째, subagent 결과는 “결론, 근거, 파일/링크, 남은 리스크” 정도로 제한한다.

셋째, skill은 범용 지식 창고가 아니라 실행 절차로 쓴다.

이 세 가지만 지켜도 자동화 팀이 훨씬 가벼워진다.

디버깅은 이름에서 시작한다

자동화 팀에서 디버깅이 어려운 이유는 호출 경로가 길어지기 때문이다.

사용자는 /publish를 쳤다.

그 명령이 skill을 불렀다.

skill이 forked subagent를 만들었다.

subagent가 MCP tool을 호출했다.

MCP 서버가 OAuth 문제로 실패했다.

최종 화면에는 “작업 실패”처럼 보인다.

이런 일이 생기면 이름 규칙이 생명줄이다.

MCP 서버 이름은 시스템 기준으로 짧고 명확해야 한다.

예를 들어 github, notion, sentry, postgres_readonly처럼 역할이 드러나야 한다.

subagent 이름은 작업자 역할이어야 한다.

예를 들어 code-reviewer, research-summarizer, db-query-validator처럼 목적이 보여야 한다.

skill 이름은 절차여야 한다.

예를 들어 blog-qc, release-check, pr-summary처럼 동사나 워크플로우가 보여야 한다.

slash command는 사용자가 부르는 액션이어야 한다.

예를 들어 /review-pr, /draft-blog, /run-qc처럼 손에 붙어야 한다.

이름에 층위가 드러나면 로그를 읽을 때 편하다.

github에서 실패했는지, pr-summary skill에서 실패했는지, code-reviewer subagent에서 실패했는지 바로 갈라진다.

이름이 예쁘지 않아도 된다.

운영에서는 예쁜 이름보다 찾기 쉬운 이름이 이긴다.

실전 예시: 블로그 자동화 팀을 분리한다면

이 글의 출발점은 “MCP 핵심 정리”식 유튜브 요약형 글감이었다.

하지만 TECHTAEK 관점에서는 단순 요약보다 운영 판단이 더 중요하다.

블로그 자동화 팀을 Claude Code에 만든다고 가정해보자.

나쁜 구성은 이렇다.

MCP로 Notion, Google Docs, WordPress, Search Console, GitHub, Slack을 모두 붙인다.

subagent로 researcher, writer, editor, publisher, seo, thumbnail을 모두 만든다.

각 subagent에 blog skill, SEO skill, channel skill, publishing skill을 모두 preloaded로 넣는다.

slash command는 /blog 하나로 모든 걸 실행한다.

겉으로는 원클릭 자동화다.

하지만 실패하면 어디서 터졌는지 찾기 어렵다.

좋은 구성은 더 소박하다.

1단계는 파일 기반 초안 작성이다.

이때는 MCP가 필요 없다.

로컬 원문과 공식 문서 링크를 읽고, 작성 skill 또는 기본 프롬프트로 초안을 만든다.

2단계는 리서치 분리다.

공식 문서 확인이 길어지면 read-only research subagent를 쓴다.

결과는 핵심 근거와 링크만 반환하게 한다.

3단계는 QC 절차화다.

채널 적합도, 금지 헤더, 출처 품질, SEO 요소처럼 반복되는 검사는 skill로 만든다.

4단계는 외부 발행 연결이다.

WordPress나 Notion에 실제로 쓰거나 읽어야 할 때만 MCP를 붙인다.

5단계는 명시 호출이다.

사람이 자주 쓰는 /draft-blog, /qc-blog, /publish-blog 정도만 command로 둔다.

이렇게 나누면 각 단계의 실패 원인이 보인다.

초안이 약하면 writer 문제다.

근거가 약하면 research 문제다.

채널이 안 맞으면 QC skill 문제다.

발행이 안 되면 MCP 인증 또는 API 문제다.

이게 자동화 팀의 핵심이다.

팀처럼 보이는 것이 아니라, 실패를 팀 단위로 분리할 수 있어야 한다.

언제 하나로 두고, 언제 나눌까

자동화 팀 설계의 가장 실용적인 기준은 “왕복 횟수”다.

작업 중간에 사람이 계속 판단해야 하면 메인 대화에 둔다.

작업이 독립적이고 결과만 받으면 되면 subagent로 나눈다.

외부 시스템이 필요하면 MCP를 붙인다.

같은 절차가 세 번 이상 반복되면 skill 후보로 올린다.

매일 직접 치는 명령이면 slash command 후보로 올린다.

이 기준을 조금 더 날카롭게 쓰면 다음과 같다.

메인 대화에 남길 작업

빠른 파일 수정.

요구사항이 계속 바뀌는 작업.

사용자 판단이 필요한 글의 톤 조정.

계획에서 구현, 테스트까지 한 흐름으로 이어지는 작업.

지연이 민감한 작업.

subagent로 뺄 작업

긴 로그 분석.

대량 코드 검색.

서로 독립적인 모듈 조사.

읽기 전용 검토.

결과 요약만 있으면 충분한 조사.

MCP로 붙일 작업

GitHub PR이나 issue를 직접 읽어야 하는 작업.

Sentry 같은 모니터링 데이터를 봐야 하는 작업.

Notion, Jira, Slack 등 외부 업무 도구와 연결해야 하는 작업.

PostgreSQL 같은 DB에서 최신 데이터를 조회해야 하는 작업.

발행 API나 SaaS 액션을 실행해야 하는 작업.

skill로 만들 작업

매번 같은 순서로 하는 블로그 QC.

배포 전 체크리스트.

PR 요약 템플릿.

데이터 분석 리포트 생성 절차.

스크립트와 템플릿이 함께 필요한 작업.

slash command로 만들 작업

짧은 prompt snippet.

명시적으로 자주 실행하는 루틴.

사람이 호출 타이밍을 통제해야 하는 작업.

한 파일로 충분한 지시문.

팀이 자주 쓰는 운영 시작 버튼.

붙이기 전 체크리스트

아래 체크리스트에서 3개 이상 “아니오”가 나오면 아직 자동화 팀으로 묶지 않는 편이 낫다.

1. 이 작업은 외부 시스템 연결이 꼭 필요한가?

2. 외부 연결이 필요하다면 MCP scope가 정해졌는가?

3. project scope라면 .mcp.json 승인 흐름을 팀이 이해하는가?

4. OAuth가 필요한 서버라면 토큰 관리자가 정해졌는가?

5. MCP 출력이 10,000 토큰을 넘지 않도록 필터가 있는가?

6. subagent로 보낼 작업이 독립적인가?

7. subagent가 반환할 결과 형식이 짧게 정의되어 있는가?

8. subagent tool 권한이 최소화되어 있는가?

9. skill은 반복 절차인가, 그냥 긴 메모인가?

10. skill이 호출 후 컨텍스트에 남아도 괜찮은가?

11. subagent에 preload할 skill이 정말 필요한가?

12. slash command는 사람이 직접 자주 부르는가?

13. command 이름과 skill 이름이 충돌하지 않는가?

14. MCP prompt command와 custom command 이름이 구분되는가?

15. 실패했을 때 MCP, subagent, skill, command 중 어디 문제인지 추적 가능한가?

이 체크리스트는 일부러 보수적이다.

자동화는 붙일 때보다 뗄 때 더 비싸다.

처음부터 너무 많이 붙이면 나중에 “이거 왜 필요한 거였지?”를 추적해야 한다.

그 시간이 진짜 비용이다.

운영 분기표: 한 문장 버전

바쁘면 이 부분만 봐도 된다.

외부 시스템 연결이면 MCP.

긴 조사와 컨텍스트 분리면 subagent.

반복 절차와 템플릿이면 skill.

짧은 명시 호출이면 slash command.

권한을 좁혀야 하면 subagent tools와 permissions를 먼저 본다.

팀 공유가 필요하면 project scope와 .mcp.json을 검토한다.

개인 실험이면 local scope로 시작한다.

출력이 10,000 토큰을 넘기 시작하면 자동화 확장이 아니라 입력 축소를 한다.

skill을 많이 넣고 싶어지면 “이 절차가 세 번 반복됐나?”를 묻는다.

subagent를 만들고 싶어지면 “결과 요약만 받아도 되나?”를 묻는다.

MCP를 붙이고 싶어지면 “이 데이터는 지금 외부에서 읽어야만 하나?”를 묻는다.

slash command를 만들고 싶어지면 “내가 이걸 손으로 자주 칠 건가?”를 묻는다.

실수 TOP 7

1. MCP를 만능 플러그인처럼 붙인다

MCP는 외부 시스템 연결이다.

연결할 시스템이 없으면 먼저 붙일 이유가 약하다.

파일 기반 작업, 로컬 노트 정리, 단순 초안 작성은 MCP 없이도 충분할 때가 많다.

2. project scope를 너무 빨리 쓴다

.mcp.json은 팀 공유에 좋다.

하지만 실험용 서버를 project scope로 올리면 팀 전체에 승인과 보안 검토 비용이 생긴다.

처음에는 local scope로 검증하고, 팀 표준이 되면 project scope로 올리는 순서가 낫다.

3. subagent마다 모든 tool을 상속한다

subagent의 장점 중 하나는 tool access를 제한할 수 있다는 점이다.

읽기 전용 reviewer에게 Write/Edit 권한이 필요 없다면 빼야 한다.

권한 제한이 없는 subagent는 그냥 새 대화창일 뿐이다.

4. skill을 지식 창고로 만든다

skill은 실행 절차에 강하다.

모든 참고 문서를 skill에 넣으면 호출 후 컨텍스트 비용이 커진다.

지식은 필요할 때 참조하고, skill은 절차 중심으로 유지하는 편이 좋다.

5. slash command 하나에 모든 자동화를 몰아넣는다

/blog 하나로 조사, 작성, 검수, 발행을 모두 하게 만들 수는 있다.

하지만 실패 지점이 안 보인다.

처음에는 /draft-blog, /qc-blog, /publish-blog처럼 나누는 편이 디버깅에 좋다.

6. MCP 출력량을 방치한다

10,000 토큰 경고는 그냥 경고가 아니다.

운영 설계가 넓다는 신호다.

쿼리 조건, 기간, 필드, row 수를 줄여야 한다.

7. 이름 규칙 없이 늘린다

review, reviewer, code-review, review-code, pr-review가 섞이면 운영자가 먼저 헷갈린다.

MCP는 시스템명, subagent는 역할명, skill은 절차명, command는 액션명으로 나누자.

이름만 정리해도 디버깅 시간이 줄어든다.

작은 팀으로 시작하는 3단계

Claude Code 자동화 팀을 처음 만들 때는 크게 시작하지 않는 편이 좋다.

1단계: command 하나와 skill 하나

먼저 사람이 직접 부르는 command 하나를 만든다.

예를 들어 /draft-blog다.

그리고 반복 절차가 있는 skill 하나만 만든다.

예를 들어 blog-qc다.

이 단계에서는 MCP를 붙이지 않는다.

외부 발행도 하지 않는다.

목표는 초안 생성과 검수 흐름이 안정적인지 보는 것이다.

2단계: read-only subagent 하나

다음은 research나 review처럼 읽기 전용 subagent를 하나 둔다.

도구는 Read, Glob, Grep 정도로 제한한다.

반환 형식도 고정한다.

예를 들어 “핵심 발견 5개, 파일/링크, 리스크 3개” 정도다.

여기서 subagent가 정말 시간을 줄이는지 본다.

짧은 작업에도 매번 느리다면 빼는 게 맞다.

3단계: MCP 하나

마지막으로 외부 시스템 하나만 붙인다.

GitHub든 Notion이든 Sentry든 하나만 고른다.

scope를 local로 시작한다.

출력량을 제한한다.

OAuth가 필요한지 확인한다.

정말 팀 공통이 되어야 할 때 project scope로 올린다.

이 순서가 느려 보일 수 있다.

하지만 자동화 운영에서는 이게 빠르다.

한 번에 다 붙이면 며칠 뒤에 원인 모를 지연을 추적하느라 더 오래 걸린다.

FAQ

MCP를 많이 붙이면 Claude Code가 무조건 느려지나?

무조건은 아니다.

하지만 MCP는 외부 서버 연결, 인증, 출력량, 권한 관리가 붙는다.

사용하지 않는 MCP까지 많이 켜두면 선택지와 관리 포인트가 늘어난다.

핵심은 필요한 연결만 유지하는 것이다.

subagent는 컨텍스트를 아껴주는데 왜 느려질 수 있나?

subagent는 자체 context window에서 시작한다.

그래서 메인 대화를 깨끗하게 유지하는 장점이 있다.

대신 필요한 맥락을 다시 모으고, 결과를 요약해 돌아와야 한다.

짧은 작업이나 왕복이 많은 작업에서는 이 비용이 더 클 수 있다.

skill과 slash command는 뭐가 다른가?

skill은 반복 절차와 참고 자료, 스크립트, 템플릿을 묶는 데 좋다.

slash command는 사용자가 명시적으로 자주 부르는 짧은 호출에 좋다.

최근 Claude Code에서는 custom command가 skills와 통합되는 흐름이 있지만, 운영 판단은 여전히 다르다.

복잡한 capability는 skill, 짧은 시작 버튼은 command로 보는 편이 쉽다.

MCP prompt slash command는 언제 쓰나?

MCP 서버가 prompt를 제공하면 /mcp__servername__promptname 형식으로 나타날 수 있다.

외부 시스템에 붙은 prompt를 직접 실행할 때 유용하다.

다만 custom command와 이름·권한이 섞이지 않도록 규칙을 정해야 한다.

MCP permission에서 wildcard를 써도 되나?

slash commands 문서 계열에서는 MCP permissions에서 wildcard가 지원되지 않는다고 안내한다.

서버 전체 승인은 mcp__servername 형태로, 특정 도구 승인은 도구명을 개별 지정하는 방식으로 보는 게 안전하다.

권한 규칙은 실제 문서 기준으로 다시 확인하고 적용해야 한다.

.mcp.json은 언제 커밋해야 하나?

팀 전체가 같은 MCP 서버를 써야 하고, 보안 검토와 승인 흐름을 감당할 준비가 됐을 때 커밋하는 편이 좋다.

개인 실험이나 민감한 토큰이 들어가는 연결은 local 또는 user scope에서 먼저 검증한다.

output warning threshold 10,000 tokens는 어떻게 해석해야 하나?

MCP 도구 출력이 10,000 토큰을 넘을 때 경고가 뜬다는 것은 결과가 너무 넓을 수 있다는 신호다.

무조건 한도를 올리기보다 먼저 쿼리 범위, 반환 필드, 기간, row 수를 줄이는 편이 좋다.

기본 최대 출력 25,000 토큰도 “넉넉하니 괜찮다”가 아니라 “여기까지 가면 설계를 다시 보자”에 가깝다.

자동화 팀을 만들 때 가장 먼저 만들 것은?

대부분은 MCP가 아니라 command 하나와 skill 하나다.

사람이 자주 부르는 시작점과 반복 검수 절차부터 안정화한다.

그 다음 read-only subagent를 붙이고, 마지막에 꼭 필요한 외부 시스템만 MCP로 연결하는 순서가 운영상 안전하다.

관련 글

• Claude Opus 4.7 vs Opus 4.6 실무 비교 2026 — 코딩 에이전트·비용·마이그레이션 판단표
• Claude Code Routines는 언제 쓰고 언제 과한가 2026
• OpenAI Agents SDK 시작점은 어디서 갈리나 2026

공식 출처

• Anthropic Claude Code MCP docs
• Anthropic Claude Code subagents docs
• Anthropic Claude Code slash commands docs

결론

Claude Code 자동화 팀을 만들 때 빠른 길은 기능을 한꺼번에 붙이는 게 아니다.

MCP, subagents, skills, slash commands를 서로 다른 층위로 나누는 것이다.

MCP는 연결이다.

subagent는 분리다.

skill은 절차다.

slash command는 호출이다.

이 네 단어만 지켜도 설계가 꽤 맑아진다.

외부 시스템이 필요할 때만 MCP를 붙인다.

긴 조사와 권한 분리가 필요할 때만 subagent를 쓴다.

반복 절차가 검증됐을 때만 skill로 만든다.

사람이 자주 직접 실행할 때만 slash command로 꺼낸다.

자동화 팀은 “많은 기능의 묶음”이 아니라 “실패를 빠르게 찾을 수 있는 구조”다.

느린 자동화는 대개 모델이 약해서가 아니라 경계가 흐려서 생긴다.

2026년에 Claude Code로 팀형 자동화를 만든다면, 첫 번째 작업은 새 도구 설치가 아니라 분리 기준표 작성이어야 한다.

그 기준표가 있어야 팀이 빨라진다.

그리고 무엇보다, 나중에 내가 나를 덜 원망한다.