모두가 Claude Code 내부에 AI "전문가" 군단을 구축하고 있습니다. 하지만 그들 중 대부분은 실행되지 않거나, 서로 충돌하며, 보호하려 했던 바로 그 컨텍스트 윈도우(Context Window)를 조용히 팽창시킬 뿐입니다. 저는 공식 내장 에이전트, 대규모 커뮤니티 컬렉션, 그리고 제가 직접 만든 것들을 포함하여 100개의 서브에이전트(Subagents)를 구축하고 스트레스 테스트를 진행하여, 진정으로 제 역할을 다하는 소수의 에이전트를 찾아냈습니다. 제가 실제로 업무를 위임하는 12개, 삭제한 것들, 그리고 서브에이전트의 진정한 용도에 대한 불편한 진실을 공개합니다.

내가 이 토끼굴에 빠진 이유

이런 일을 스스로에게 저지른 것이 벌써 세 번째입니다. 첫 번째는 100개의 Claude 기술(Skills)이었고, 그다음은 100개의 MCP 서버(MCP servers)였습니다. 이제는 서브에이전트(Subagents) 차례입니다. 이들은 Claude Code 스택의 세 가지 기둥을 형성합니다. 기술(Skills)은 에이전트에게 _역량(Competence)_을 부여하고, MCP 서버는 _기능(Capability)_을 부여하며, 서브에이전트는 _위임(Delegation)_을 가능하게 합니다. 저는 이미 두 가지를 다루었습니다. 이 삼부작을 완성하기 위해 세 번째가 필요했습니다.

그리고 현재 서브에이전트(Subagents)는 가장 열기가 뜨거운 분야입니다. GitHub를 열어보면 수백 개의 에이전트가 모인 컬렉션들을 볼 수 있습니다. VoltAgent의 awesome-claude-code-subagents는 10개 카테고리에 걸쳐 154개 이상의 에이전트를 제공하며 **22.9k개의 스타(Stars)**를 보유하고 있고, wshobson의 마켓플레이스는 **194개의 에이전트, 158개의 기술, 16개의 오케스트레이터(Orchestrators)**를 묶어 37.5k개의 스타를 기록하고 있습니다. 그 제안은 매우 매혹적입니다. security-auditor(보안 감사관), react-specialist(React 전문가), kubernetes-specialist(Kubernetes 전문가), quant-analyst(퀀트 분석가)와 같은 AI 전문가 _팀_을 구성하고, Claude Code가 모든 작업에 적합한 전문가를 파견하게 만드는 것입니다.

그래서 저는 당연한 선택을 했습니다. 저는 100개의 서브에이전트를 설치하고 연결하여 코드 리뷰, 디버깅, 테스트 실행, 보안 감사, 데이터베이스 분석, 장애 대응(Incident Triage)과 같은 실제 업무에 직접 _사용_해 보았습니다. 저는 Claude가 실제로 어떤 에이전트에게 업무를 위임하는지, 어떤 에이전트가 아무런 역할 없이 가만히 있는지, 그리고 어떤 에이전트가 저의 메인 대화 품질을 조용히 _악화_시키는지 지켜보았습니다.

대부분 삭제되었습니다. 코드가 잘못 작성되어서가 아니라 — 많은 것들이 훌륭했습니다 — 서브에이전트 (subagent)의 목적을 근본적으로 오해했기 때문입니다. 그 오해가 이 글의 핵심이며, 목록을 공개하기 전에 그 점을 먼저 짚고 넘어가겠습니다.

이것이 살아남은 최종 후보 명단입니다. 12개의 서브에이전트. 100개 중에서 말이죠.

요약 (TL;DR)

• 서브에이전트는 인격체가 아닙니다. 그것은 컨텍스트 방화벽 (context firewall)입니다. 각 에이전트는 자신만의 격리된 컨텍스트 창 (context window)에서 실행되며, 메인 스레드에는 요약본만을 반환합니다. 실제 가치는 '전문가 페르소나'가 아니라 바로 그 '격리'에 있습니다.
• 서브에이전트가 많을수록 더 나빠집니다. description 필드가 중복되면 Claude가 잘못된 에이전트에게 작업을 위임하거나(또는 아무에게도 위임하지 않거나) 합니다. 100개의 에이전트가 모인 동물원보다는 정예화된 10개의 에이전트가 더 신뢰성 있게 작동합니다.
• 서브에이전트의 세 가지 진짜 역할: (1) 장황한 출력물 격리, (2) 도구/권한 제한 강제, (3) 행동 특화 — 선택적으로 영구 메모리 (persistent memory) 활용.
• 모델 라우팅 (Model routing)은 비용 조절 레버입니다. 저렴한 작업은 Haiku로, 깊은 추론이 필요한 작업은 Opus로 (또는 가장 긴 호흡의 작업은 Fable로) 라우팅하세요. 잘 구성된 에이전트 군단은 모든 작업을 메인 모델에서 실행하는 것보다 훨씬 저렴합니다.
• 아래 소개할 저의 12개 핵심 에이전트는 리뷰, 디버깅, 테스트, 보안, 아키텍처, 성능, 데이터, 문서화, 그리고 오케스트레이션 (orchestration) — 즉, 실제 엔지니어링 작업의 중추를 다룹니다.
• 이것으로 3부작이 완성됩니다: MCP = 능력 (capability), Skills = 역량 (competence), Subagents = 위임 (delegation). 이 세 가지 모두를 관통하는 메타 기술은 동일합니다: 무자비하게 큐레이션하라 (curate ruthlessly).

30초 요약: 서브에이전트란 무엇인가?

서브에이전트는 Claude Code가 작업을 넘겨줄 수 있는 특화된 조수입니다. 구조적으로는 YAML 프론트매터 (frontmatter)가 포함된 마크다운 (Markdown) 파일입니다:

---
name: code-reviewer
description: 전문 코드 리뷰 전문가. 코드를 작성하거나 수정 직후에 즉시 사용하십시오.
...

이 작은 파일이 강력한 힘을 발휘하는 네 가지 요소가 있으며, 이는 위에서 언급한 세 가지 역할과 정확히 일치합니다:

1. 자체 컨텍스트 윈도우 (Context window). 이것이 핵심입니다. 서브에이전트는 사용자의 대화 기록, 이미 읽은 파일, 또는 이미 로드된 기술(skills)을 보지 못합니다. 서브에이전트는 완전히 새로운 상태에서 시작하여 격리된 상태로 작업을 수행하고, 오직 요약본만을 반환합니다. 덕분에 사용자의 메인 컨텍스트는 깨끗하게 유지됩니다.
2. 범위가 지정된 도구 (Scoped tools). tools 필드는 허용 목록 (allowlist)이며, disallowedTools는 차단 목록 (denylist)입니다. 예를 들어, 리뷰어(reviewer)에게는 Read, Grep, Glob 권한이 부여되며, 물리적으로 파일을 편집할 수 없습니다. 이는 단순한 권장 사항이 아니라 보안 경계 (security boundary)입니다.
3. 자체 모델 (Its own model). model 필드를 통해 서브에이전트를 sonnet, opus, haiku, fable, 전체 모델 ID, 또는 inherit로 라우팅할 수 있습니다. 이는 비용을 조절하는 다이얼 역할을 합니다.
4. 집중된 시스템 프롬프트 (Focused system prompt). 마크다운(Markdown) 본문이 서브에이전트의 전체 시스템 프롬프트가 됩니다. Claude Code의 기본 프롬프트에 추가되는 방식이 아니라, 그것이 유일한 프롬프트가 됩니다. 좁은 전문성을 갖추며 주의가 분산되지 않습니다.

이들이 존재하는 위치

위치	범위	우선순위
관리 설정 (Managed settings)	조직 전체 (Organization-wide)	가장 높음
...

프로젝트 서브에이전트는 버전 관리 시스템(version control)에 포함되어야 팀 전체가 동일한 리뷰어에게 작업을 위임할 수 있습니다. 또한, 이를 처음부터 직접 작성할 필요는 없습니다. Claude Code에게 작성을 요청하면 됩니다 (최근 버전에서는 /agents 명령어가 정확히 그 작업을 수행하도록 안내합니다). 그 후 프론트매터(frontmatter)를 다듬기만 하면 됩니다.

이미 갖춰져 있는 내장 에이전트

무엇을 설치하기 전에, Claude Code에는 이미 사용자를 대신해 작동하는 서브에이전트들이 포함되어 있습니다:

• Explore — 코드베이스를 검색하고 이해하기 위한 빠르고 읽기 전용(read-only)인 에이전트입니다. 비용을 낮게 유지하기 위해 의도적으로 사용자의 CLAUDE.md와 git status를 건너뛰며, 모든 검색 결과가 메인 컨텍스트에 포함되지 않도록 유지합니다.
• Plan — 계획 모드(plan mode)에서 계획을 제안하기 전 컨텍스트를 수집하는 데 사용되는 읽기 전용 연구 에이전트입니다.
• general-purpose — 탐색과 실행이 모두 필요한 복잡하고 다단계인 작업을 수행하는 만능 에이전트입니다.

만약 계획 모드를 사용해 보았거나 Claude가 "코드베이스를 탐색(explore the codebase)"하는 것을 본 적이 있다면, 당신은 이미 서브에이전트를 사용하고 있었던 것입니다. 그것이 서브에이전트의 본질을 보여주는 증거입니다.

잠시 벗어나기: 서브에이전트에 대한 불편한 진실

제가 언급했던 오해가 여기에 있습니다. 대부분의 사람들은 — 과거의 저를 포함해서도 — 서브에이전트를 '캐릭터'로 생각합니다. 즉, 개성과 직함을 가진 작은 AI 전문가 같은 것입니다. 이러한 정신적 모델 하에서는 에이전트가 많을수록 = 전문성이 높고 = 더 좋다고 여깁니다. 그래서 154개의 모음을 설치하고 마치 회사를 고용한 듯한 느낌을 받습니다.

하지만 그 모델은 틀렸으며, 이것이 바로 그러한 설치들이 실망스러운 이유입니다. 서브에이전트의 진정한 가치는 개성이 아니라 컨텍스트 격리(context isolation)입니다.

테스트 스위트를 실행하거나, API 문서를 세 페이지 가져오거나, 거대한 모노레포에서 grep을 수행할 때 실제로 무슨 일이 일어나는지 생각해 보세요. 이 모든 장황한 출력물이 메인 대화창을 범람시켜, 당신이 실제로 신경 쓰는 내용을 밀어내고 모델의 집중력을 저하시킵니다. 이를 서브에이전트에 위임하면 그 혼란은 그것의 컨텍스트 창 안에 머물러 있고 — 당신은 두 줄짜리 요약본만 얻게 됩니다. 서브에이전트가

서브에이전트(subagents)를 통해 실질적인 가치를 창출하는 팀은 가장 많은 인원을 보유한 팀이 아닙니다. 그들은 각각 날카로운 설명(description), 최소한의 도구(tools), 그리고 작업을 수행할 수 있는 가장 저렴한 모델(model)을 갖춘 소수의 '컨텍스트 방화벽(context firewalls)'을 구축한 팀입니다. 여기서 필요한 메타 기술(meta-skill)은 제 'Skills' 및 'MCP' 글에서 언급했던 것과 동일합니다. 바로 무자비하게 큐레이션(curate ruthlessly)하는 것입니다. 빼는 것이 게임의 전부입니다.

이러한 관점에서, 컨텍스트를 사용할 가치가 있는 12개를 소개합니다.

100개의 서브에이전트를 평가한 방법

각 서브에이전트는 다섯 가지 축을 기준으로 점수를 매겼습니다.

1. 트리거 정밀도 (Trigger precision) — Claude가 적절한 순간에 이를 위임하고, 그렇지 않을 때는 내버려 두는가? (이는 description에 의해 결정됩니다.)
2. 컨텍스트 경제성 (Context economy) — 장황한 작업을 격리함으로써 메인 스레드(main-thread)의 컨텍스트를 절약하는가, 아니면 거대한 보고서를 다시 쏟아내는가?
3. 도구 위생 (Tool hygiene) — 최소한으로 필요한 권한만 가지는가. 리뷰어(reviewer)가 Write 권한을 가질 이유는 없습니다.
4. 모델 적합성 (Model fit) — 작업을 잘 수행하면서도 가장 저렴한 모델로 라우팅되는가?
5. 실제 주간 업무 적합성 (Real weekly fit) — 직함의 이력서 같은 것이 아니라, 제가 실제로 수행하는 업무와 매칭되는가?

두 개 이상의 축에서 5점 만점에 3점 미만을 받은 것은 모두 제외되었습니다. 이 과정에서 제가 시도했던 것의 약 80%가 탈락했습니다. 여기에는 실제로는 메인 모델이 이미 충분히 잘 처리하고 있는 거의 모든 '초특화 언어 전문가(hyper-specific language specialist)'들이 포함되었습니다.

유지할 가치가 있는 12개의 Claude Code 서브에이전트 (순위별)

1. code-reviewer — 매일 그 가치를 증명하는 에이전트

읽기 전용(Read-only) · Sonnet · 모든 변경 사항 이후 실행

가장 전형적인 서브에이전트이며, 모든 진지한 컬렉션이 그만한 이유가 있어 포함하는 에이전트입니다. 이 에이전트는 git diff를 실행하고, 수정된 파일에 집중하며, 우선순위(critical / warnings / suggestions)별로 정리된 피드백을 반환합니다. 결정적으로 이 에이전트는 **읽기 전용(read-only)**입니다. 즉, Read, Grep, Glob, Bash 권한만 가지며 Write나 Edit 권한은 없습니다. 따라서 리뷰 도중에

사용 시점: 의미 있는 변경을 거친 후, PR(Pull Request)을 열기 전에 사용하세요. 제가 가장 먼저 설치할 서브에이전트입니다.

2. debugger — 증상이 아닌 근본 원인 파악

Read + Edit · 상속 · 실패 및 스택 트레이스 분석용

리뷰어가 읽기 전용(read-only)일 때, 디버거는 버그를 수정하는 과정이 코드 변경을 의미하기 때문에 Edit 권한을 가집니다. 이 서브에전트의 프롬프트는 실제 워크플로우를 인코딩합니다: 오류와 스택 트레이스를 캡처하고, 실패 지점을 격리하며, 가설을 세우고 테스트하고, 최소한의 수정 사항을 구현하며, 검증하는 것입니다. 이 서브에전트의 가치는 그 자체의 규율(discipline)에 있습니다. 단순히 증상에 패치를 붙이는 대신 근본적인 원인을 추적하며, 모든 잡다한 로그 분석 과정(log-spelunking)을 자신만의 컨텍스트 내에 유지합니다.

사용 시점: 테스트가 실패하거나, 예외가 급증하거나, 동작이 엉뚱해져서 단순히 임시방편이 아닌 _원인_을 알고 싶을 때.

3. test-runner — 가장 순수한 컨텍스트 방화벽

Bash + Read · Haiku 또는 Sonnet · 장황한 출력 격리

이 서브에전트는 전체 논문(thesis)의 주제를 가장 잘 구현합니다. 테스트 스위트(test suite)를 실행하면 메인 스레드에서 원하지 않는 엄청난 양의 출력이 발생하는데, 사용자가 원하는 것은 _

사용 시점: 인증(auth) 검토, 신뢰할 수 없는 입력(untrusted input) 처리, 보안 민감 사항을 배포하기 전.

5. architect-reviewer — 중대한 결정을 위한 가드레일(Guardrails)

읽기 전용(Read-only) · Opus · 설계 및 구조(design and structure)

코드 라인 단위의 스타일이 아니라, 경계(boundaries), 결합도(coupling), 기존 패턴과의 일관성(consistency) 등 아키텍처 원칙에 따라 변경 사항을 평가하는 특화된 리뷰어입니다. 잘못된 구조적 결정을 조기에 발견하는 것은 토큰(tokens)을 쓸 가치가 있기 때문에 이 역시 Opus로 라우팅됩니다. 저는 대규모 리팩터링(refactor)을 수행하기 전이나, 변경 사항이 모듈 경계 전반에 영향을 미칠 때 이 에이전트를 사용합니다.

사용 시점: 대규모 리팩터링, 새로운 서브시스템(subsystems), "이것이 우리의 아키텍처에 부합하는가?"라는 의문이 드는 순간.

6. Explore (내장형) — 이미 보유하고 있는 도구

읽기 전용(Read-only) · 모델 상속 (Opus로 제한) · 코드베이스 검색(codebase search)