---
id: sub-agent-architecture
title: "Sub-agent Architecture"
category: "AI_and_ML"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["Sub-agent", "서브 에이전트 아키텍처", "Multi-agent architecture", "하위 에이전트", "Subagent orchestration"]
duplicate_of: ""
source_trust_level: "A"
confidence_score: 0.95
created_at: 2026-07-11
updated_at: 2026-07-11
review_reason: ""
merge_history: []
tags: ["research", "context 이해 규칙"]
raw_sources: ["Effective context engineering for AI agents - Anthropic", "Prompting best practices - Claude Platform Docs"]
applied_in: []
github_commit: ""
---

# [[Sub-agent Architecture]]

## 🎯 한 줄 통찰 (One-line insight)
서브 에이전트 아키텍처는 주 에이전트가 전체 계획과 분석을 총괄하고 특화된 하위 에이전트가 격리된 컨텍스트 환경에서 세부 탐색을 병렬 수행하여, 컨텍스트 한계를 극복하고 복잡한 장기(long-horizon) 작업을 완수하는 오케스트레이션 설계 패턴이다.

## 🧠 핵심 개념 (Core concepts)
* **관심사의 분리 (Separation of Concerns)**: 주 에이전트(Lead agent)는 결과의 종합과 분석에 집중하고, 하위 에이전트(Sub-agents)는 독립적이고 깨끗한(clean) 컨텍스트 윈도우 내에서 심층 기술 작업이나 정보 검색을 전담한다.
* **컨텍스트 증류 (Context Distillation)**: 하위 에이전트는 광범위한 탐색 과정에서 수만 개의 토큰을 사용할 수 있지만, 주 에이전트에게는 1,000~2,000 토큰 분량의 정제되고 요약된 결과만을 반환하여 전체 컨텍스트 오염을 방지한다.
* **네이티브 오케스트레이션 (Native Orchestration)**: 최신 모델은 작업을 특화된 하위 에이전트에게 위임하는 것이 유리한 상황을 스스로 인지하고, 명시적 지시 없이도 자발적으로 하위 에이전트를 생성 및 조율한다.

## 🧩 추출된 패턴 (Extracted patterns)
* **병렬 탐색 패턴 (Parallel Exploration)**: 복잡한 연구 및 분석 과제에서, 단일 에이전트가 순차적으로 작업하는 대신 여러 하위 에이전트가 동시에 다양한 독립적인 정보 브랜치를 탐색하도록 위임하는 전략이다.
* **하위 에이전트 남용 방지 프롬프팅 (Overuse Guardrailing)**: 모델이 단순한 직접 도구 호출(예: 단일 파일 검색이나 직접 grep 호출)이 더 효율적인 상황에서도 불필요하게 하위 에이전트를 생성하는 현상을 억제하기 위해, 특정 조건에서만 하위 에이전트를 사용하도록 가이드라인을 명시하는 패턴이다.

## ⚖️ 비교 및 선택 기준 (Comparison & decision criteria)
LLM의 컨텍스트 윈도우 한계를 극복하기 위한 장기 작업(Long-horizon tasks) 컨텍스트 엔지니어링 기법 비교 [S1]

| 항목 (Option) | 장점 | 단점 | 언제 선택 |
|---|---|---|---|
| **Compaction (압축)** | 이전 이력을 고해상도로 압축하여 지속적인 대화 흐름(conversational flow)을 유지함 | 지나치게 공격적인 압축 시, 추후 중요해질 수 있는 미묘한 컨텍스트가 유실될 위험이 있음 | 광범위한 상호작용(back-and-forth)이 지속적으로 요구되는 작업 시 |
| **Structured note-taking (에이전트 메모리)** | 컨텍스트 윈도우 외부에 진행 상황과 종속성을 기록하여 최소한의 오버헤드로 영구적 기억을 제공함 | 외부 파일 기반 시스템이나 메모리 도구를 유지하고 구조화해야 하는 별도 관리 필요 | 명확한 마일스톤이 존재하며 반복적으로 진행되는 개발 작업 시 |
| **Sub-agent Architecture (서브 에이전트)** | 세부 검색의 컨텍스트를 하위 에이전트에 격리하여, 주 에이전트의 컨텍스트 오염을 막고 병렬 탐색 효율을 극대화함 | 최신 모델의 경우 단순 작업에도 불필요하게 하위 에이전트를 남용(overuse)하여 컴퓨팅/토큰 비용을 증가시킬 위험이 있음 | 병렬 탐색(parallel exploration)이 이점을 제공하는 복잡한 연구 및 분석 과제 시 |

## 📖 세부 내용 (Details)
* 서브 에이전트 아키텍처는 단일 에이전트가 전체 프로젝트의 방대한 상태를 모두 유지하려고 할 때 발생하는 LLM 컨텍스트 윈도우 크기의 한계와 컨텍스트 오염(Context pollution)을 극복하기 위한 전략이다 [S1].
* **동작 원리**: 주 에이전트는 고차원적인 계획(High-level plan)을 조율하고 서브 에이전트들이 반환한 결과를 종합/분석하는 데 집중한다 [S1]. 반면, 특화된 하위 에이전트들은 주 에이전트의 복잡한 이력과 분리된 완전히 깨끗한 컨텍스트 윈도우(Clean context windows)를 부여받아, 딥 기술 작업이나 방대한 도구 검색을 전담한다 [S1]. 
* **결과 증류**: 하위 에이전트는 탐색 과정에서 수만 토큰을 넘나드는 방대한 정보를 탐색하지만, 작업을 마친 뒤에는 가장 핵심만 담긴 1,000~2,000 토큰 분량의 정제된 요약본만을 주 에이전트로 반환하여 전체 컨텍스트의 밀도를 높게 유지한다 [S1]. 이러한 관심사 분리 접근법은 복잡한 연구 과제에서 단일 에이전트 시스템 대비 상당한 성능 향상을 이끌어낸다 [S1].
* **네이티브 오케스트레이션 및 한계 제어**: 최신 LLM(예: Claude Opus 4.6 등)은 하위 에이전트 도구가 정의되어 있기만 하면, 명시적인 지시 없이도 알아서 하위 에이전트를 오케스트레이션하는 네이티브 기능을 지닌다 [S2]. 
* 그러나 모델은 종종 지나치게 하위 에이전트에 의존하려는 편향을 보이며, 직접 `grep` 호출 등으로 간단하고 빠르게 해결할 수 있는 상황에서도 불필요하게 하위 에이전트를 파생(spawn)시키는 남용(Overuse) 문제를 일으킬 수 있다 [S2]. 이를 제어하기 위해 프롬프트를 통해 "여러 독립적인 정보 분기를 동시에 탐색해야 할 때만 하위 에이전트를 사용하라"는 식으로 명확한 제한을 설정해야 한다 [S2].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
* 소스 내에서 모순되는 정보는 발견되지 않음. 단, 기존에는 개발자가 명시적 파이프라인으로 서브 에이전트의 동작을 체인 형태로 지시해야 했으나, 최신 모델 업데이트(Claude Opus 4.6 등)로 인해 모델이 알아서(Natively) 하위 에이전트의 생성 시점을 파악하고 오케스트레이션하도록 진화하였음이 업데이트된 사실이다.

## 🛠️ 적용 사례 (Applied in summary)
* 소스에 구체적인 코드 파일 경로나 Git 커밋 해시는 포함되어 있지 않으나, Anthropic의 내부 연구 시스템인 다중 에이전트 리서치 시스템(Multi-agent research system) 구축 프로젝트에서 서브 에이전트 아키텍처가 도입되어, 단일 에이전트 대비 복잡한 연구 과제에서 상당한 성능 개선(substantial improvement)을 이룬 의사결정 사례가 서술되어 있다.

## 💻 코드 패턴 (Code patterns)
하위 에이전트의 무분별한 생성을 막고 적재적소에만 호출하게 유도하는 시스템 프롬프트 작성 패턴이다 [S2]. 
```xml
<subagent_guidance>
Use subagents ONLY for tasks that require exploring multiple independent branches of information simultaneously. For simple text search or single-file edits, use your direct tools instead.
</subagent_guidance>
```

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual
- **출처 신뢰도:** A
- **신뢰 점수:** 0.95
- **중복 검사 결과:** 신규 생성 (New discovery)

## 🔗 관련 문서 링크 (Related document links)

### 상위/유사 개념
- [[Context Engineering]] — 연결 이유: AI 에이전트가 가진 토큰과 주의력 예산(Attention budget)의 한계를 관리하기 위한 상위 전략 범주.
- [[Agentic Workflow]] — 연결 이유: 도구 사용과 반복적인 실행 루프를 통한 자율적 문제 해결이라는 기반 메커니즘을 공유함.
- [[In-context Learning]] — 연결 이유: 사전 학습된 가중치 변경 없이 프롬프트상의 예시와 맥락만으로 새로운 작업을 수행하게 만드는 핵심 구동 원리.

### 심층 후속 질문 (Deeper Research Questions)
- 주 에이전트와 하위 에이전트 간의 데이터 통신 프로토콜 및 도구 정의(Tool definitions)는 어떤 형식으로 구성해야 가장 효과적인가?
- 하위 에이전트가 수만 토큰을 분석한 후 1,000~2,000 토큰으로 압축할 때 발생하는 정보 손실(환각 현상 등)을 완화하는 검증 로직은 무엇인가?
- 단일 에이전트 대비 서브 에이전트 아키텍처를 도입했을 때 발생하는 토큰 소모량과 추론 비용(Latency)의 증가율은 어느 정도인가?
- 모델의 네이티브 오케스트레이션이 오작동하여 하위 에이전트들이 무한 루프나 교착 상태(Deadlock)에 빠질 때 이를 강제 차단할 수 있는 시스템 가드레일 설계는 어떻게 해야 하는가?
- Compaction, 에이전트 메모리(Structured note-taking), 서브 에이전트를 모두 결합한 하이브리드 컨텍스트 관리 아키텍처의 설계 사례가 존재하는가?

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** 대규모 코드베이스 분석 및 리팩토링, 포괄적인 시장 조사 보고서 작성 등 여러 문서와 지식 소스를 병렬로 뒤져야 하는 AI 서비스 구축.
- **System Design:** 다중 에이전트 시스템(Multi-agent system) 설계 시, 단일 에이전트 프롬프트에 모든 도구를 몰아넣는 대신 하위 에이전트 단위로 도구를 분리하고 주 에이전트가 이를 호출하는 계층형 구조(Hierarchical Structure) 수립.
- **Operation / Maintenance:** 모델이 불필요하게 하위 에이전트를 호출하여 인프라 자원을 낭비하는지 모니터링 로그를 추적하고, `<subagent_guidance>` 프롬프트를 주기적으로 튜닝.
- **Learning Path:** LLM 프롬프트 엔지니어링 -> 컨텍스트 오염(Context Rot)의 이해 -> 다중 에이전트 협업 및 라우팅 설계 학습.

### 인접 주변 주제 (Adjacent Topics)
- [[Adaptive Thinking]] — 확장 방향: 에이전트가 질문의 복잡도에 따라 사고(추론)에 투입할 컴퓨팅 자원과 토큰 크기를 동적으로 조절하는 방식.
- [[Model Context Protocol (MCP)]] — 확장 방향: 하위 에이전트가 외부 데이터 저장소 및 도구에 접근하기 위해 사용하는 표준화된 프로토콜 생태계.

## 🔗 지식 그래프 (Knowledge Graph)
- **상위/루트:** [[context 이해 규칙]]
- **관련 개념:** [[Context Engineering]], [[Multi-Agent Collaboration]]
- **참조 맥락:** 한정된 토큰 환경 내에서 컨텍스트 오염을 막고 긴 맥락(Long-horizon)을 요구하는 대규모 리서치 에이전트 시스템을 분산/계층 설계할 때 핵심 판단 기준으로 참조됨.

## 📚 출처 (Sources)
- [S1] "Effective context engineering for AI agents - Anthropic"
- [S2] "Prompting best practices - Claude Platform Docs"

## 📝 변경 이력 (Change history)
- 2026-07-11: Initial draft generated via Datacollector_MAC P-Reinforce engine.