Claude Code 하위 에이전트가 느려지는 이유 2026 context budget·tool 권한·검수 루프 표

2026년 4월 22일 기준 Claude Code 하위 에이전트는 별도 컨텍스트와 도구 권한을 가진 작업자다. 많이 붙이면 병렬성이 늘지만, 설명 문서, 도구 후보, MCP 출력, 승인 요청, 검수 루프도 같이 늘어 속도가 떨어질 수 있다.

Claude Code에서 하위 에이전트를 붙이면 처음엔 기분이 좋다.

리서치 담당.

리뷰 담당.

테스트 담당.

보안 담당.

문서 담당.

딱 봐도 회사 같아진다.

문제는 회사가 생겼다고 일이 자동으로 빨라지진 않는다는 점이다.

회의가 생긴다.

인수인계가 생긴다.

권한 요청이 생긴다.

검토자가 또 검토자를 부르는 작은 드라마도 생긴다.

AI도 비슷하다.

하위 에이전트는 공짜 분신술이 아니다.

별도 컨텍스트를 만들고, 역할 설명을 읽고, 도구 범위를 판단하고, 결과를 요약해서 메인 대화로 돌려주는 구조다.

공식 문서도 하위 에이전트를 “메인 대화에 다시 쓸 일이 적은 검색 결과, 로그, 파일 내용을 별도 컨텍스트에서 처리하게 하는 장치”로 설명한다.

그러니까 핵심은 많이 붙이는 게 아니다.

흘러넘치는 작업만 밖으로 빼는 것이다.

오늘 글은 그 기준을 표로 정리한다.

context budget, tool 권한, MCP 출력, 검수 루프, 로컬 .claude/agents 구조까지 같이 본다.

소스는 Anthropic 공식 Claude Code 문서와 이 워크스페이스의 .claude/agents 구조다.

그리고 이 글은 초안이다.

발행도 안 하고, 시트도 안 만지고, 동기화도 안 돌린다.

Worker 015가 조용히 한 파일만 만드는 중이다.

조용하지만 손은 바쁘다.

짧은 답

Claude Code 하위 에이전트가 많아질수록 느려지는 이유는 모델이 갑자기 멍청해져서가 아니다.

대부분은 운영 비용이 늘어서다.

첫째, 각 하위 에이전트는 역할 설명과 설정을 가진다.

둘째, 도구 권한을 넓게 열면 선택지가 늘어난다.

셋째, MCP 서버를 많이 물리면 도구 설명과 출력 토큰이 커진다.

넷째, 검수용 에이전트가 많으면 작성 → 검토 → 수정 → 재검토 왕복이 늘어난다.

다섯째, 결과 요약이 부실하면 메인 에이전트가 다시 파일을 읽는다.

이때 사용자는 “왜 느리지?”라고 느끼지만, 실제로는 뒤에서 작은 운영 절차가 여러 번 돈다.

하위 에이전트는 느린 장치가 아니다.

잘못 붙이면 느려지는 장치다.

특히 tools를 비워서 모든 도구를 상속하게 만들거나, skills를 여러 개 프리로드하거나, MCP 서버를 메인 대화와 모든 하위 에이전트에 동시에 열어두면 체감 지연이 빠르게 커진다.

반대로 읽기 전용 탐색, 로그 분석, 긴 리서치, 반복 검수처럼 메인 컨텍스트를 더럽히기 쉬운 작업은 하위 에이전트가 오히려 빠르다.

핵심 질문은 하나다.

이 작업의 중간 산출물을 메인 대화가 계속 기억해야 하나?

아니면 최종 요약만 받으면 되나?

최종 요약만 필요하면 하위 에이전트가 맞다.

중간 맥락을 계속 이어가야 하면 메인 대화에 남기는 편이 낫다.

공식 문서에서 먼저 확인할 것

Anthropic의 Claude Code subagents 문서는 하위 에이전트의 장점을 네 가지로 잡는다.

컨텍스트 보존.

도구 제한.

재사용.

전문화.

문서에서 중요한 표현은 “각 subagent는 자체 context window에서 실행된다”는 점이다.

이 말은 좋아 보인다.

실제로 좋다.

메인 대화가 긴 검색 로그로 오염되지 않기 때문이다.

하지만 별도 컨텍스트는 별도 작업 시작 비용도 만든다.

하위 에이전트가 어떤 일을 해야 하는지 설명을 받아야 한다.

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

자기 도구 범위를 확인해야 한다.

끝나면 결과를 요약해야 한다.

이 요약이 부족하면 메인 에이전트는 다시 읽는다.

아이고, 사내 메신저에 “위 내용 정리해서 다시 공유 부탁드립니다” 뜨는 그 느낌이다.

공식 문서는 또 .claude/agents/에 프로젝트 하위 에이전트를 두고 팀과 공유할 수 있다고 설명한다.

우리 워크스페이스도 실제로 그렇게 되어 있다.

.claude/agents/README.md에는 top-level 에이전트 40개, active 23개, 팀 디렉터리 10개가 정리돼 있다.

대표 팀만 봐도 blog-pipeline-team, research-team, trading-team, prototype-dev-team처럼 역할 분리가 꽤 진행되어 있다.

이 구조는 강하다.

하지만 강한 구조일수록 운영표가 필요하다.

안 그러면 “필요해서 만든 에이전트”와 “예전에 멋있어서 만든 에이전트”가 한 테이블에 앉는다.

회의실 의자가 부족해진다.

병목 표

하위 에이전트가 느려질 때는 보통 한 가지 이유가 아니다.

아래 표처럼 여러 병목이 겹친다.

병목	느려지는 장면	원인	줄이는 방법
context budget	시작부터 답이 무겁다	CLAUDE.md, rules, agent prompt, skill 내용이 많이 로드된다	공통 지침은 200줄 안팎으로 줄이고, 작업별 지침은 rules 또는 skill로 분리한다
agent selection	Claude가 누구에게 맡길지 오래 고른다	description이 겹치거나 “proactive”가 남발된다	에이전트 설명을 트리거 중심으로 쓰고 중복 역할을 합친다
tool 권한	매번 도구 후보가 많다	tools를 비워 모든 도구와 MCP를 상속한다	Read, Grep, Glob, Bash처럼 필요한 도구만 allowlist로 둔다
MCP 출력	외부 도구 결과가 대화창을 덮는다	MCP 도구가 큰 로그나 DB 결과를 반환한다	쿼리 제한, 요약 도구, MAX_MCP_OUTPUT_TOKENS 기준을 둔다
permission prompts	승인 확인이 자주 뜬다	쓰기, 실행, 네트워크, 민감 경로 접근이 섞인다	읽기 전용 에이전트와 실행 에이전트를 분리한다
검수 루프	리뷰는 많은데 완료가 늦다	reviewer가 여러 명이고 판정 기준이 다르다	단일 gate를 두고 PASS/REVISE/FAIL 계약을 통일한다
handoff 손실	결과를 받아도 다시 읽는다	하위 에이전트 출력이 긴데 결정이 없다	마지막에 “판단, 근거, 다음 액션” 3줄을 강제한다
hooks 과잉	편집 한 번마다 자동화가 돈다	PreToolUse, PostToolUse, SubagentStop 훅이 겹친다	훅은 차단, 포맷, 로그처럼 결정적 작업만 둔다
model mismatch	단순 작업도 비싼 모델로 돈다	모든 하위 에이전트가 inherit 또는 고급 모델이다	탐색은 Haiku, 판단은 Sonnet, 최종 작성은 상위 모델로 나눈다
병렬 과잉	여러 작업이 동시에 시작되는데 더 늦다	서로 같은 파일과 같은 소스를 반복 조회한다	수집 lane을 나누고 single writer 규칙을 둔다

이 표에서 제일 자주 터지는 건 tool 권한이다.

하위 에이전트 설정에서 tools를 생략하면 기본적으로 메인 대화의 도구를 상속할 수 있다.

공식 문서는 필요하면 tools allowlist 또는 disallowedTools denylist를 쓰라고 설명한다.

실무에서는 allowlist가 더 안전하다.

예를 들어 코드 탐색 에이전트는 Read, Grep, Glob만 있어도 꽤 많은 일을 한다.

리뷰 에이전트도 처음부터 Write가 필요하지 않다.

수정 권한까지 줘야 할 때만 따로 실행 에이전트를 둔다.

이렇게 나누면 느려지는 것도 줄고, 사고도 줄고, 나중에 로그를 봤을 때 “얘가 왜 이 파일을 고쳤지?”라는 추리 소설도 줄어든다.

context budget은 어디서 새나

Claude Code에서 컨텍스트는 작업 기억이다.

길면 많이 기억한다.

하지만 많이 기억한다고 항상 잘하는 건 아니다.

중요하지 않은 규칙이 많이 들어오면 중요한 규칙이 흐려진다.

공식 memory 문서는 CLAUDE.md가 세션 시작 때 컨텍스트에 로드되고 토큰을 쓴다고 설명한다.

또 각 CLAUDE.md는 200줄 미만을 목표로 하라고 권한다.

우리 워크스페이스는 루트 AGENTS.md, .claude/rules/blog-writing.md, .claude/MEMORY/warm/recent-patterns.md, .claude/agents/README.md 같은 파일을 작업 전 읽는다.

블로그 초안 하나에도 운영 지침이 꽤 붙는다.

이건 나쁜 일이 아니다.

품질을 지키는 안전벨트다.

다만 하위 에이전트가 많아지면 안전벨트가 열 개가 된다.

운전은 안전한데 내리기가 힘들다.

컨텍스트 예산을 줄이는 방법은 단순하다.

항상 필요한 것만 시작 컨텍스트에 둔다.

작업별로 필요한 것은 rules나 skill로 뺀다.

하위 에이전트에는 필요한 skill만 명시한다.

그리고 skills 필드의 의미를 오해하면 안 된다.

공식 subagents 문서는 skills에 적은 skill의 전체 내용이 하위 에이전트 시작 컨텍스트에 주입된다고 설명한다.

즉 “나중에 필요하면 찾아보겠지”가 아니다.

처음부터 들고 들어간다.

작은 skill은 괜찮다.

하지만 긴 skill 여러 개를 프리로드하면 하위 에이전트 하나가 작은 책가방을 메고 출근하는 게 아니라 이삿짐센터가 된다.

그래서 기준이 필요하다.

하위 에이전트의 system prompt는 역할과 출력 계약 위주로 짧게 둔다.

긴 절차는 skill로 빼되, 항상 프리로드하지 않는다.

정말 매번 필요한 skill만 skills에 넣는다.

그 외는 메인 에이전트가 필요한 순간에 호출하게 둔다.

tool 권한은 속도 문제이기도 하다

권한은 보안 문제만이 아니다.

속도 문제이기도 하다.

하위 에이전트가 사용할 수 있는 도구가 많을수록 선택 비용이 늘어난다.

MCP 서버까지 붙어 있으면 도구 후보가 더 많아진다.

공식 보안 문서는 Claude Code가 기본적으로 엄격한 read-only 권한에서 시작하고, 편집, 테스트 실행, 명령 실행 같은 작업에는 명시적 승인을 요청한다고 설명한다.

이 설계는 안전하다.

하지만 운영자가 모든 하위 에이전트에 넓은 권한을 주면 승인 지점도 늘어난다.

특히 리뷰 에이전트가 읽고, 테스트 에이전트가 실행하고, 보안 에이전트가 또 실행하고, 문서 에이전트가 쓰기까지 하면 사용자 입장에서는 계속 묻는다.

“허용할까요?”

“이번에도 허용할까요?”

“이 명령은 괜찮을까요?”

AI가 아니라 은행 보안 앱처럼 느껴진다.

권한 설계는 이렇게 나누면 편하다.

읽기 전용 에이전트는 Read, Grep, Glob 중심으로 둔다.

분석 에이전트는 필요할 때 Bash를 제한적으로 준다.

수정 에이전트만 Edit, Write를 가진다.

외부 시스템을 만지는 에이전트는 MCP 서버를 명시적으로 좁힌다.

발행, 배포, 삭제, 결제, 시트 수정은 별도 승인 흐름으로 둔다.

이 글을 쓰는 현재 작업도 같은 원칙을 따른다.

초안만 작성한다.

Google Sheets는 만지지 않는다.

sync_blog_ideas도 실행하지 않는다.

요청 범위가 파일 하나면 파일 하나만 건드리는 게 맞다.

말은 단순한데 운영에서 이게 제일 돈을 아낀다.

MCP를 하위 에이전트마다 다 열면 무거워진다

MCP는 Claude Code를 외부 도구와 연결하는 강력한 통로다.

GitHub, Sentry, Postgres, Slack, Figma, 브라우저, 사내 API 같은 것들을 붙일 수 있다.

좋다.

진짜 좋다.

하지만 모든 하위 에이전트에게 모든 MCP를 열어주면 이야기가 달라진다.

공식 MCP 문서는 MCP 도구 출력이 10,000 tokens를 넘으면 경고를 보여주고, 기본 최대값은 25,000 tokens라고 설명한다.

이 숫자는 꽤 크다.

로그 한 번 잘못 가져오면 블로그 한 편 분량이 그냥 들어온다.

DB 조회 결과도 마찬가지다.

Sentry 이벤트를 통째로 가져오고, Slack 스레드를 길게 가져오고, 이슈 트래커 설명과 댓글을 다 가져오면 컨텍스트가 금방 부풀어 오른다.

MCP를 많이 붙일 때는 “연결 수”보다 “출력량”을 먼저 봐야 한다.

외부 도구를 붙였는데 느리다면 질문을 바꿔야 한다.

MCP 서버가 느린가?

아니면 MCP 출력이 너무 큰가?

하위 에이전트가 같은 MCP를 반복 호출하나?

결과를 요약하지 않고 원문을 계속 넘기나?

내 기준은 이렇다.

메인 대화에는 자주 쓰는 최소 MCP만 둔다.

특정 하위 에이전트 전용 MCP는 그 에이전트 설정으로 좁힌다.

큰 출력이 예상되는 도구는 기본 쿼리 제한을 둔다.

DB는 limit 20 같은 방어선을 둔다.

로그는 시간 범위를 먼저 좁힌다.

Slack이나 문서 검색은 원문 전체보다 후보 링크와 요약을 먼저 받는다.

이렇게 하면 하위 에이전트가 “외부 세계를 보는 창”이 된다.

아무 데나 열린 창문이 되면 바람이 많이 들어온다.

여름엔 좋지만 컨텍스트는 감기 걸린다.

검수 루프는 좋은데 너무 많으면 느리다

우리 .claude/agents/blog-pipeline-team/README.md는 블로그 파이프라인을 researcher → writer → reviewer로 나눈다.

그리고 중요한 원칙을 둔다.

쓰는 사람과 검증하는 사람은 다르다.

이건 좋은 설계다.

블로그에서는 특히 필요하다.

writer가 자기 글을 검수하면 놓치는 표현이 많다.

금지 표현, 출처 누락, 채널 부적합, 분량 부족, AI 냄새는 별도 게이트가 보는 편이 낫다.

하지만 검수자를 계속 늘리면 속도는 떨어진다.

SEO reviewer.

팩트 reviewer.

문체 reviewer.

채널 reviewer.

보안 reviewer.

법무 reviewer.

이러면 초안 하나가 작은 국정감사가 된다.

검수는 많을수록 좋은 게 아니다.

판정 계약이 분명할수록 좋다.

우리 블로그 팀의 PASS / REVISE / FAIL 같은 판정표가 중요한 이유다.

검수 루프를 줄이는 방법은 네 가지다.

첫째, reviewer는 최종 저장 권한을 갖지 않는다.

둘째, reviewer는 줄 단위 감상보다 수정 가능한 이슈를 낸다.

셋째, 같은 기준은 한 reviewer에게 몰아준다.

넷째, 두 번 이상 반복되는 수정은 규칙이나 preflight script로 내린다.

사람도 똑같다.

매번 회의에서 말로 하는 지적은 규칙이 아니다.

체크리스트나 자동 검사로 내려가야 규칙이 된다.

Claude Code hooks도 이 지점에서 쓸 수 있다.

공식 hooks 문서는 SubagentStop 이벤트가 하위 에이전트가 끝났을 때 실행되고, 마지막 응답이나 별도 transcript 경로를 받을 수 있다고 설명한다.

즉 하위 에이전트 결과를 자동으로 로그화하거나, 필수 출력 형식을 검사하거나, 불완전한 종료를 막는 흐름을 만들 수 있다.

하지만 훅도 과하면 느려진다.

편집 한 번마다, 도구 한 번마다, 하위 에이전트 종료 때마다, 모든 검사가 동시에 돌면 답답해진다.

훅은 인간이 매번 승인하기 귀찮은 결정적 검사에만 둔다.

나머지는 reviewer에게 맡긴다.

로컬 .claude/agents 구조에서 보이는 신호

이 워크스페이스의 .claude/agents는 이미 꽤 성숙한 구조다.

top-level 에이전트가 있고, 팀 디렉터리가 있고, 각 팀 안에 lead, researcher, reviewer, tester 같은 역할이 있다.

예를 들어 research-team은 Lead, Collector, Connector, Analyst, Verifier로 나뉜다.

README에는 single writer 규칙도 있다.

읽기와 분석은 병렬 가능하지만, 최종 저장은 Lead만 한다는 원칙이다.

이건 하위 에이전트를 많이 쓸 때 아주 중요하다.

여러 워커가 동시에 같은 파일을 쓰면 빠른 게 아니라 위험하다.

작업이 꼬이면 나중에 누가 무엇을 덮었는지 추적해야 한다.

그래서 “병렬”과 “동시 수정”은 다르게 봐야 한다.

병렬 수집은 좋다.

동시 저장은 조심해야 한다.

블로그 팀도 비슷하다.

researcher가 조사하고, writer가 쓰고, reviewer가 검증한다.

최종 저장과 발행은 Lead가 관리한다.

이 구조는 좋은데, 모든 글에 항상 모든 단계를 풀파워로 돌릴 필요는 없다.

짧은 리프레시 글이면 researcher를 가볍게 쓰면 된다.

이미 소스가 명확한 글이면 verifier를 좁게 쓰면 된다.

초안만 필요한 작업이면 publisher 단계는 빼야 한다.

오늘 요청이 딱 그렇다.

Draft only.

Do not publish.

Do not edit Google Sheets.

Do not run sync_blog_ideas.

이 네 문장은 하위 에이전트 운영에서 아주 좋은 제한 조건이다.

작업 범위가 줄어들면 컨텍스트도 줄고, 권한도 줄고, 검수 루프도 줄어든다.

AI에게 자유를 주는 것도 중요하지만, 정확한 울타리를 주는 게 더 빠를 때가 많다.

줄이는 표

이제 실제 운영표로 바꿔보자.

하위 에이전트가 느려질 때는 아래 순서대로 줄이면 된다.

점검 순서	질문	줄일 대상	유지할 대상	운영 기준
1	이 에이전트가 매번 필요한가	드문 역할의 자동 호출	자주 반복되는 병목 역할	5회 이상 반복된 작업만 상설화
2	설명이 겹치나	비슷한 description	명확한 트리거	“언제 쓰는가”를 한 문장으로 구분
3	도구가 너무 넓나	상속된 전체 tools	읽기 전용 allowlist	수정 권한은 실행 에이전트에만
4	MCP가 과한가	모든 에이전트 공통 MCP	특정 에이전트 전용 MCP	큰 출력 도구는 쿼리 제한
5	skill을 많이 싣나	매번 프리로드되는 긴 skill	필요할 때 호출할 skill	시작 컨텍스트에 꼭 필요한 것만
6	reviewer가 겹치나	감상형 검수자	판정형 gate	PASS/REVISE/FAIL로 통일
7	훅이 과한가	모든 도구에 걸린 검사	위험 동작 차단 훅	자동화는 결정적 검사만
8	결과가 다시 읽히나	긴 원문 반환	요약+근거+액션	마지막 3줄 계약을 강제
9	모델이 과한가	모든 역할 inherit	역할별 모델	탐색 Haiku, 판단 Sonnet, 작성 상위 모델
10	저장자가 여럿인가	워커 직접 저장	single writer	최종 파일 변경은 한 주체만

이 표를 적용하면 하위 에이전트 수를 무작정 줄이지 않아도 된다.

중요한 건 숫자가 아니다.

역할과 권한의 밀도다.

하위 에이전트 3개여도 모두 모든 도구를 갖고 있으면 무겁다.

하위 에이전트 10개여도 각자 읽기 전용, 짧은 출력, 명확한 트리거를 갖고 있으면 꽤 가볍다.

한마디로 “작은 전문가”는 좋다.

“뭐든지 다 할 수 있는 작은 사장님”이 많으면 느리다.

회사도 그렇다.

사장님이 열 명이면 회의가 길다.

실무 체크리스트

하위 에이전트가 느리다고 느껴질 때 바로 삭제부터 하지 말자.

아래 체크리스트를 먼저 본다.

.claude/agents에서 같은 역할의 에이전트가 둘 이상 있는가
description이 “전문가”, “도움”, “검토”처럼 추상적으로만 쓰였는가
tools가 비어 있어 모든 도구를 상속하는가
read-only 업무에 Write, Edit, MCP write 도구가 열려 있는가
skills에 긴 skill을 여러 개 프리로드했는가
MCP 도구 출력이 10,000 tokens 경고에 자주 닿는가
reviewer가 같은 이슈를 서로 다른 말로 반복하는가
하위 에이전트 결과에 “다음 액션”이 없는가
메인 에이전트가 하위 에이전트가 읽은 파일을 다시 읽는가
자동 훅이 모든 도구 호출에 걸려 있는가
최종 저장자가 여러 명인가
사용자 승인 요청이 작업당 3회를 넘는가

여기서 3개 이상 걸리면 느려질 가능성이 높다.

5개 이상이면 구조를 줄이는 게 맞다.

8개 이상이면 팀이 아니라 작은 관료제가 됐을 수 있다.

이럴 땐 과감하게 줄인다.

하위 에이전트 삭제가 부담스럽다면 비활성화부터 해도 된다.

프로젝트 agent를 archive하거나, description에서 자동 호출 트리거를 약하게 만들거나, tools를 읽기 전용으로 좁히는 방식이다.

중요한 건 “더 많이”가 아니라 “더 정확히”다.

예시: 블로그 파이프라인을 가볍게 만드는 법

TECHTAEK 블로그 초안을 만든다고 해보자.

무거운 구성은 이렇다.

researcher가 웹 전체를 찾는다.

connector가 볼트 전체를 찾는다.

writer가 긴 초안을 쓴다.

SEO reviewer가 본다.

fact reviewer가 본다.

channel reviewer가 본다.

publisher가 시트를 수정한다.

SNS writer가 후속 문구를 만든다.

이 구성이 항상 틀린 건 아니다.

발행 직전에는 필요할 수 있다.

하지만 초안만 만들 때는 과하다.

이번 작업처럼 아이디어, 채널, 제목, 파일명이 이미 정해져 있다면 더 줄일 수 있다.

필요한 것은 블로그 규칙 확인, 최근 도입부 패턴 확인, 공식 문서 확인, 로컬 agents 구조 확인, 초안 작성, preflight 검증이다.

publisher는 필요 없다.

Google Sheets도 필요 없다.

sync_blog_ideas도 필요 없다.

SNS도 필요 없다.

이렇게 단계가 줄면 속도가 난다.

그리고 무엇보다 사고가 줄어든다.

AI 작업에서 속도는 “빨리 많이 하는 것”이 아니라 “하지 않아도 되는 일을 안 하는 것”에서 나온다.

이건 개발도 비슷하다.

좋은 최적화는 코드 한 줄을 빠르게 만드는 게 아니라 호출 자체를 없애는 경우가 많다.

에이전트 설명을 이렇게 고쳐라

하위 에이전트 description은 멋진 자기소개가 아니다.

라우팅 조건이다.

나쁜 설명은 이렇다.

전문적인 코드 품질 검토를 수행하는 에이전트

나쁘진 않다.

하지만 언제 호출해야 하는지가 흐리다.

더 나은 설명은 이렇다.

Use after code changes, before final response, to review changed files for correctness, security, and missing tests. Read-only only.

여기에는 시점이 있다.

대상이 있다.

범위가 있다.

권한 제한이 있다.

블로그 reviewer도 마찬가지다.

블로그를 좋게 검토한다보다, 초안 작성 후 AI냄새, 패턴 반복, E-E-A-T, 팩트 대조, 분량을 PASS/REVISE/FAIL로 판정한다가 낫다.

Claude가 자동 위임할 때 description을 참고하기 때문이다.

description이 흐리면 에이전트 선택도 흐려진다.

선택이 흐리면 느려진다.

사람도 “아무거나 도와줄게”보다 “세금 신고 전 서류 누락만 봐줄게”가 바로 부르기 쉽다.

구체성은 친절이다.

AI에게도 그렇다.

모델 배정도 병목이다

하위 에이전트가 느린 이유 중 하나는 모델 배정이다.

공식 문서는 subagent frontmatter에서 model을 지정할 수 있고, 생략하면 기본적으로 inherit 흐름을 따른다고 설명한다.

메인 대화가 고급 모델이면 하위 에이전트도 비싼 모델을 따라갈 수 있다.

그게 항상 나쁜 건 아니다.

하지만 단순 파일 탐색까지 고급 모델이 하면 낭비다.

로컬 블로그 팀 README도 글쓰기 writer에는 상위 모델을 쓰고, researcher와 reviewer에는 더 가벼운 모델을 쓰는 식으로 역할을 나눈다.

이 관점이 맞다.

탐색은 빠르게.

판단은 안정적으로.

최종 문장은 좋은 모델로.

테스트 실행은 모델보다 스크립트로.

검산은 가능하면 코드로.

이렇게 나눠야 토큰과 시간이 같이 줄어든다.

하위 에이전트를 많이 붙이는 팀일수록 모델표를 둬야 한다.

누가 Haiku인지.

누가 Sonnet인지.

누가 Opus인지.

누가 inherit인지.

이 표가 없으면 어느 날 단순 grep 담당이 최고급 회의실에서 혼자 검색하고 있다.

비싼 의자에 앉아서 rg 치는 느낌이다.

조금 아깝다.

줄인 뒤에도 남겨야 하는 것

줄인다고 다 없애면 안 된다.

남겨야 하는 것도 있다.

첫째, 단일 진입점은 남긴다.

사용자가 누구를 불러야 할지 몰라도 되는 구조가 좋다.

둘째, 검수 gate는 남긴다.

특히 발행, 배포, 돈, 보안, 계정 권한이 걸린 작업은 gate가 필요하다.

셋째, handoff 로그는 남긴다.

하위 에이전트가 무엇을 보고 어떤 판단을 했는지 최소한의 기록이 있어야 한다.

넷째, 권한 경계는 남긴다.

읽기와 쓰기를 섞지 않는 원칙은 귀찮아도 유지해야 한다.

다섯째, preflight는 남긴다.

사람 reviewer가 매번 지적하는 반복 문제는 자동 검사로 내려야 한다.

이번 글도 마지막에 blog_preflight_check.py를 돌린다.

이 검사는 frontmatter, 최소 줄 수, 필수 FAQ와 출처, 금지 헤더, 관련 글 섹션을 본다.

초안이어도 이 정도는 통과해야 한다.

초안이라고 안전벨트 안 매는 건 아니니까.

FAQ

하위 에이전트는 많을수록 나쁜가?

아니다.

역할이 겹치고 권한이 넓고 출력이 길면 나쁘다.

반대로 역할이 좁고 읽기 전용이며 요약 계약이 분명하면 여러 개여도 도움이 된다.

숫자보다 경계가 중요하다.

Claude Code subagent와 agent team은 같은 건가?

같지 않다.

공식 문서는 subagent는 단일 세션 안에서 별도 컨텍스트로 작업하는 구조이고, 여러 에이전트가 병렬로 소통해야 하면 agent teams를 보라고 안내한다.

간단히 말하면 subagent는 세션 안의 전문 작업자에 가깝고, agent team은 더 큰 협업 구조에 가깝다.

tools를 비워두면 왜 위험한가?

하위 에이전트가 메인 대화의 도구를 넓게 상속할 수 있기 때문이다.

읽기만 해야 하는 reviewer가 쓰기 도구나 MCP write 도구까지 보게 되면 선택지도 늘고 권한 리스크도 커진다.

읽기 전용 업무는 Read, Grep, Glob처럼 좁게 시작하는 편이 낫다.

MCP 서버를 하위 에이전트 전용으로 둘 수 있나?

공식 문서 기준으로 subagent frontmatter에는 mcpServers 필드가 있다.

특정 에이전트에게만 필요한 MCP를 좁혀두면 메인 대화의 도구 설명 부담과 권한 노출을 줄일 수 있다.

큰 출력이 나오는 MCP는 특히 전용화와 쿼리 제한이 중요하다.

skills를 하위 에이전트에 많이 넣으면 좋은가?

항상 그렇진 않다.

공식 문서는 skills 필드에 들어간 skill의 전체 내용이 시작 컨텍스트에 주입된다고 설명한다.

긴 skill을 많이 넣으면 시작부터 무거워진다.

정말 매번 필요한 skill만 프리로드하고, 나머지는 필요할 때 호출하는 편이 낫다.

검수 에이전트는 몇 개가 적당한가?

처음에는 하나면 충분하다.

그 하나가 PASS / REVISE / FAIL처럼 명확한 판정을 내야 한다.

SEO, 팩트, 문체, 채널을 모두 따로 나누는 건 발행량이 많아지고 병목이 반복될 때 해도 늦지 않다.

느려졌을 때 제일 먼저 볼 파일은?

프로젝트라면 .claude/agents/README.md와 각 에이전트 frontmatter를 먼저 본다.

그다음 .claude/rules/, .claude/CLAUDE.md, MCP 설정, hooks 설정을 본다.

특히 tools, skills, model, mcpServers, hooks, description 다섯 항목을 먼저 확인하면 빠르다.

참고 자료

Anthropic Claude Code Docs, Create custom subagents: 하위 에이전트의 별도 컨텍스트, .claude/agents/ 위치, tools, model, skills, mcpServers, permissionMode 필드 확인.
Anthropic Claude Code Docs, How Claude remembers your project: CLAUDE.md가 시작 컨텍스트에 로드되고 200줄 미만을 목표로 하라는 운영 기준 확인.
Anthropic Claude Code Docs, Connect Claude Code to tools via MCP: MCP 출력 경고 10,000 tokens, 기본 최대 25,000 tokens, MAX_MCP_OUTPUT_TOKENS 기준 확인.
Anthropic Claude Code Docs, Hooks reference: SubagentStop, SubagentStart, hook matcher, hook 출력 제어 방식 확인.
Anthropic Claude Code Docs, Security: read-only 기본 권한, 명시적 승인, prompt fatigue 완화, MCP trust verification 관련 보안 원칙 확인.
Local source, .claude/agents/README.md: top-level 에이전트 수, active 상태, 대표 에이전트와 팀 디렉터리 구조 확인.
Local source, .claude/agents/blog-pipeline-team/README.md: researcher, writer, reviewer 분리와 PASS / REVISE / FAIL 검수 게이트 확인.
Local source, .claude/agents/research-team/README.md: single writer 규칙, Lead/Collector/Connector/Analyst/Verifier 구조 확인.

Claude Code 하위 에이전트를 많이 붙이면 왜 느려질까 2026 – context budget·tool 권한·검수 루프 줄이는 표