Claude 블로그 되짚어보기 #105 — Subagents, AI의 브라우저 탭 (2026)

panicdev·5일 전
AIAnthropicClaudeLLMSubagentsagentArchitectureclaudecode블로그리뷰

원문 정보

글의 요지

Subagents — 자체 컨텍스트 윈도 가진 격리 Claude 인스턴스. 메인 세션에서 "side task" 분리. "브라우저 탭" 처럼 사용. Built-in: General-purpose, Plan, Explore. 각자 다른 권한 가능. 자동 위임 + 명시 지시. "무엇이고 언제, 어떻게 쓰지 말아야 하는가" 가이드.

핵심 정의

본문 인용:

"A subagent is an isolated Claude instance with its own context window. It takes a task, does the work, and returns only the result. Think of subagents as the browser tabs of a Claude Code session: a place to chase a tangent without losing the main thread."

브라우저 탭 비유:

  • 메인 thread = 현재 페이지
  • subagent = 새 탭 (탐색)
  • 결과 = 메인으로 (탭 닫으면)

작동 — Context Isolation

본문 강조:

"Each subagent starts fresh, unburdened by the history of the conversation or invoked skills. Multiple subagents can run in parallel, and each can have different permissions: a research subagent might have read-only access, while an implementation subagent gets full editing capabilities."

특징:

  • Fresh start (대화 history 없음)
  • 병렬 실행 가능
  • Permission 차별화 (read-only vs editing)

Built-in Subagent 종류

1) General-purpose

  • 복잡 multi-step task
  • 탐색 + 수정 둘 다
  • 가장 광범위

2) Plan

  • plan mode에서 사용
  • codebase 리서치
  • 계획 수립용
  • "가장 깊은 계획 mode"

3) Explore

  • read-only 검색·분석
  • 파일 발견
  • 빠른 lookup
  • 3 단계 thoroughness:
    • Quick: 타깃 lookup
    • Medium: 균형
    • Very thorough: 종합 분석

언제 사용

본문 권장 시그널:
1. 컨텍스트 모음 시 수십 파일 읽기 필요 → Explore subagent
2. 복잡 다단계 task with 다른 권한 → General-purpose
3. plan 단계 codebase 이해 필요 → Plan
4. side task가 메인 컨텍스트 채울 것 → 모든 subagent

Subagent vs Agent Teams

본문 외 (builder.io):
| 차이 | Subagent | Agent Teams |
|---|---|---|
| 세션 | 단일 세션 안 | 별도 세션 간 |
| 통신 | 부모 ↔ 자식 | 피어 ↔ 피어 |
| 토큰 | 일반 | ~7× plan-heavy |
| 적합 | 격리 task | 협업 task |

권장:

  • Subagents 먼저 (단순)
  • Agent Teams 후속 (복잡 협업)

1000-2000 Token 압축

본문 외 (engineering blog):

"Each subagent might explore extensively, using tens of thousands of tokens or more, but returns only a condensed, distilled summary of its work (often 1,000-2,000 tokens)."

(각 subagent = 수만 token 사용. 그러나 1,000-2,000 token 요약만 반환)

이게 "context efficiency" 의 정확한 측정:

  • Subagent 작업 = 50K tokens
  • 메인 컨텍스트 비용 = 1.5K tokens
  • 30× 절약

언제 사용 X

본문이 식별한 anti-pattern:

  • 작은 편집 (수정 1-2 줄)
  • 밀접 결합 작업 (같은 파일 변경)
  • constant back-and-forth 필요
  • tightly-coupled multi-layer task

이유:

  • handoff overhead
  • fresh start (컨텍스트 없음)
  • 분단된 mental model

2026년에 다시 읽으며 — 내가 본 것

1. "Browser Tabs" 비유의 깊이

이 글의 가장 우아한 비유 — 브라우저 탭:

  • 메인 작업 유지
  • side 탐색 분리
  • 결과만 가져옴
  • 닫음

이게 "인지 부하 관리" 의 정확한 패턴:

  • 인간 인지: working memory 7±2
  • AI 컨텍스트: ~200K tokens
  • 둘 다 한계 있음

해결:

  • 인간: 노트, 책갈피
  • AI: subagent
  • 같은 원리

2. "30× Token 절약" 의 ROI

데이터:

  • Subagent 사용: 50K tokens
  • 메인 returned: 1.5K tokens
  • 절약: 30× 컨텍스트 비용

이게 enterprise 비용 임팩트:

  • Opus 4.6: $5/MTok input
  • 50K tokens = $0.25
  • 1.5K tokens = $0.0075
  • $0.24 절약/subagent

100개 subagent/일 = $24/일 = $720/월 절약 (개인).
1000명 회사: $720K/년.

이게 "context engineering = 매출" 의 정확한 사례.

3. "Read-only vs Editing" 의 권한 차별

본문 강조:

  • Research subagent = read-only
  • Implementation = full edit
  • 다른 권한 = 다른 안전성

이게 "least privilege principle" 의 적용:

  • 보안 일반 원칙
  • AI agent 적용
  • 위험 ↓

비교 — IT 보안:

  • Service account = 제한 권한
  • Admin account = 전체
  • 직무별 다름

AI도 같음. 각 subagent = 직무별 권한.

4. "Plan Subagent + Plan Mode" 의 layered 디자인

Plan Mode (Claude Code):

  • Claude가 변경 X
  • 탐색만
  • plan 작성

Plan Subagent (이 글):

  • Plan Mode 안에서
  • codebase 리서치
  • 계획용 컨텍스트

이 layered 디자인:

  • 사용자 = high-level (plan mode)
  • AI = mid-level (plan subagent)
  • AI = low-level (file 읽기)

각 layer = 다른 abstraction.

5. "No Nested Subagents" 의 안전 디자인

본문 강조:

  • subagent = 다른 subagent spawn X
  • "infinite nesting 방지"

이게 "resource limit" 의 명확 디자인:

  • 1 main + 5 subagent = OK
  • 1 main + 5 subagent × 5 sub = 위험
  • 컨텍스트 폭발 방지

비교 — UNIX fork bomb:

  • 무한 process spawn
  • 시스템 다운
  • AI 시대 같은 위험

이 "하드 제한" 이 production 안정성.

6. "Tool 격리" 의 디자인

각 subagent:

  • 자체 system prompt
  • 자체 tool 목록
  • 자체 권한
  • 자체 hook

이게 "microservice 패턴" 의 정확한 적용:

  • 각 service = 단일 책임
  • 명확 인터페이스
  • 독립 배포

AI 시대:

  • 각 subagent = 단일 책임
  • 명확 input/output
  • 독립 실행

7. "Subagent vs Skill vs MCP" 의 stack 분류

antstack 인용한 5-layer:
1. Model: Claude (intelligence)
2. MCP: 외부 system 연결
3. Skill: 도메인 expertise
4. Subagent: task 격리
5. Agent Team: 협업

각 layer의 역할:

  • MCP = "무엇에 접근"
  • Skill = "어떻게 일해"
  • Subagent = "누가 해" (격리된 worker)
  • Agent Team = "팀이 협업"

이게 AI engineering의 새 stack:

  • 전통 SW: layer (DB, app, frontend)
  • AI: layer (model, tools, knowledge, workers, teams)

8. "Anti-pattern Education" 의 솔직 가이드

본문이 명확:

  • "subagent 모든 곳 X"
  • 작은 편집 = main session
  • tightly-coupled = main session

이게 "hype 반대" 패턴 (#94 글과 같은):

  • 모든 곳 X
  • 적절한 곳에만

비교 — 다른 회사:

  • "우리 도구 모든 곳 사용!"
  • 매출 ↑
  • 사용자 좌절

Anthropic:

  • "신중하게"
  • 신뢰 ↑
  • 장기 채택

9. "Resources PDF" 의 자산 패턴

본문 후속:

  • "Claude Code Advanced Patterns: Subagents, MCP, and Scaling to Real Codebases" PDF
  • 무료 다운로드
  • 표준 정의

이게 "표준 정복" 패턴 반복:

  • #83 (Skills 32-page)
  • #90 (Code Modernization)
  • #93 (skill-creator)
  • 이 글 (Subagents PDF)

각 무료 가이드 = 산업 표준.

10. "Same File, Different Roles" 의 흥미로운 통찰

antstack 인용:

"The file format for an agent and a subagent is identical; both are Markdown files with YAML frontmatter in .claude/agents/. There is no syntactic difference between them. The distinction is entirely behavioural."

(agent와 subagent = 같은 파일. 차이는 행동 — 누가 invoke 하는가)

이게 "role = behavioral" 의 깊은 통찰:

  • 같은 파일
  • 다른 컨텍스트에서 다른 역할
  • "agent는 top-level invoke, subagent는 spawned"

비교 — 인간 직무:

  • 매니저가 자기 매니저 만남 = peer
  • 매니저가 자기 직원 만남 = boss
  • 같은 사람, 다른 role

AI도 같음. role = 컨텍스트 의존.

11. "Anthropic 5-Layer Stack" 의 종합

이 글까지 Anthropic이 정의한 stack:

  • #41: MCP (외부 도구)
  • #74-#75: Skills (도메인)
  • 이 글 (#105): Subagents (격리)
  • #85 (Opus 4.6): Agent Teams (협업)

각 발표가 stack의 한 layer.
종합: AI engineering의 표준 stack.

비교 — 클라우드 stack:

  • AWS EC2 (compute)
  • AWS S3 (storage)
  • AWS Lambda (serverless)
  • AWS API Gateway (orchestration)

각 service = 독립 + 결합 가능.

Anthropic stack 동일:

  • 각자 독립 사용
  • 또는 결합
  • "choose your level"

12. "Just-in-time + Subagent" 의 컨텍스트 경제

engineering blog 인용:

"Rather than pre-processing all relevant data up front, agents built with the 'just in time' approach maintain lightweight identifiers (file paths, stored queries, web links, etc.) and use these references to dynamically load data into context at runtime."

("just in time" — 미리 데이터 처리 X, lightweight identifier 유지, 런타임에 동적 로드)

Subagent + just-in-time:

  • 메인 = identifier
  • Subagent = 실제 처리
  • 결과만 메인 컨텍스트
  • 메모리 효율 극대화

비교 — 인간 인지:

  • 모든 정보 기억 X
  • 책갈피, 노트, 검색
  • 외부 indexing system

AI도 같음. AI = "external memory" 사용.

마무리

이 글은 "subagent 사용 가이드" 같지만, 실제로는 AI engineering의 새 stack 정의의 한 layer다.

  • Browser Tabs 비유: 인지 부하
  • 30× Token 절약: ROI
  • Read-only vs Editing: 권한 차별
  • Plan Mode + Subagent: layered
  • No Nested: 안전 디자인
  • Microservice 패턴: AI 적용
  • 5-Layer Stack: 종합
  • Anti-pattern: 솔직 가이드
  • PDF 자산: 표준 정복
  • Same File, Different Roles: 컨텍스트
  • Cloud-like Stack: 비교
  • Just-in-time + External Memory: 인지 모방

2026년 4월 시점은 "AI = 단일 인스턴스" 시대가 끝난 시점이다. AI = 격리 + 협업하는 multi-instance의 정착.

흥미로운 건 이 글이 #94 (Workflow Patterns), #104 (Harnessing Intelligence) 의 직접 계승이라는 점이다:

  • #94: 6 패턴 (Lego)
  • #104: 활용 원칙
  • #105 (이 글): subagent 패턴 (구체)

각 글이 AI engineering 교과서의 한 챕터.

향후 챕터 (예측):

  • Agent Teams 깊이 (#106?)
  • MCP server 빌드 (#107?)
  • Production 배포 (#108?)

각 layer가 "개발자 → AI engineer" 변환의 가이드.

다음 글 (#106): CSV #12 — 다음 발표. Anthropic의 4월 launch 가속의 한 부분. stack 진화의 다음 layer가 보인다.

profile
panicdev
이전 포스트

Claude 블로그 되짚어보기 #104 — Harnessing Claude, AI는 grown 아닌 built (2026)

다음 포스트

Claude 블로그 되짚어보기 #106 — Carta Healthcare, Hybrid Intelligence (2026)

0개의 댓글