서브에이전트 — 작업 분할과 컨텍스트 격리

큰 작업을 한 LLM 인스턴스 한 번에 맡기면 컨텍스트가 빠르게 차고 책임이 흐려집니다. 서브에이전트는 작업을 작은 단위로 잘라 별도 모델 인스턴스에 위임하는 패턴입니다. 컨텍스트 절약 · 병렬성 · 역할 분리가 동기이고, 디버깅 · 메시지 디자인이 비용입니다.

1. 서브에이전트에 대한 이야기

서브에이전트는 다음 의미로 쓰입니다:

• 상위 에이전트 (또는 호스트) 가 호출해 특정 작업을 수행하는 보조 에이전트.
• 자기만의 시스템 프롬프트·도구·세션을 가짐.
• 결과를 상위에게 돌려주는 모양 (보통 텍스트 또는 구조화 데이터).

상위 에이전트는 도구 호출처럼 서브에이전트를 호출. 호출 인자가 자연어 작업 지시일 수 있다는 점이 일반 함수 호출과 다른 자리.

2. 사용 도구의 예

• Claude Code 의 Agent tool — subagent_type 으로 종류를 지정해 호출. general-purpose · code-reviewer 같은 역할별.
• LangGraph 의 supervisor 패턴 — 상위 노드가 하위 노드를 라우팅.
• AutoGen 의 GroupChat / SwarmChat — 다중 에이전트 대화.
• CrewAI 의 Crew · Agent — 역할 기반 협업.
• Google ADK 의 Hierarchical Agent — 부모-자식 위임.

이름과 인터페이스는 도구마다 다르지만 핵심 아이디어는 비슷합니다.

3. 호출 흐름

[상위] 사용자 의도 분석
    ↓
   "코드 변경 사항을 검토해 줘" 같은 지시 + 컨텍스트 묶음
    ↓
[하위] 자기 시스템 프롬프트 + 받은 지시 + 도구 사용
    ↓
   결과 (요약 · 체크리스트 · 구조화 데이터)
    ↓
[상위] 결과 통합 · 다음 단계 결정

상위 에이전트는 하위의 내부 사고 과정을 다 보지 않습니다. 결과만 받아 다음 결정에 씁니다.

4. 컨텍스트 격리의 효과

• 하위 작업의 도구 결과·로그가 상위 컨텍스트에 누적되지 않음.
• 상위가 보는 메시지 수가 줄어 추론 안정성이 오름.
• 토큰 비용 일부가 줄어듭니다 (전체 비용은 상위·하위 합).

대신 결과가 요약 단계에서 손실될 수 있습니다.

5. 패턴별 비교

패턴	모양
Supervisor (라우터)	상위가 어느 하위로 보낼지 결정.
Pipeline	하위들이 순차로 작업 (검색 → 작성 → 검토).
Parallel	독립 하위들이 동시 실행 후 합치기.
Loop	종료 조건까지 반복.
Hierarchy	다층 트리 구조.

6. 멀티 vs 단일 에이전트

논쟁이 활발한 자리. Anthropic · Cognition 등 다수 글이 거론됩니다. 거칠게 정리:

멀티 이점:

• 컨텍스트 분담.
• 역할 단위 평가·교체.
• 병렬 처리.

멀티 비용:

• 메시지 패스 디자인의 부담.
• 책임 경계 모호함 (어디서 실패가 시작됐는가).
• 비용·지연 증가.
• 동일 정보 중복 처리.

작업이 충분히 큰지 · 서브 작업이 진짜로 독립적인지가 결정 요인.

7. 컨텍스트 절약의 다른 가닥

가닥	메모
도구 결과 요약 후 메모리 저장	외부 메모리 (벡터 · KV) 에 저장 후 컨텍스트에서 제거.
메시지 압축	옛 메시지를 모델로 요약해 한 줄로.
체크포인트 · resume	중간 상태를 저장해 다음 세션으로.
캐시 (prompt caching)	같은 시스템·도구 정의를 캐시해 비용·지연 줄이기.
컨텍스트 윈도가 큰 모델 사용	100k~1M 토큰 모델로 분할 자체를 줄임.

서브에이전트는 이들과 결합 가능합니다.

8. 코드 리뷰 보조의 예

[상위 에이전트]
 - 사용자 의도 파악
 - 도메인 지식 정리
 - 변경 사항 분류
 - [하위: 보안 리뷰] (변경 파일만 보고 잠재 위험 정리)
 - [하위: 테스트 리뷰] (테스트 누락·경계 케이스)
 - [하위: 문서 리뷰] (변경에 따른 문서 갱신 점검)
 - 결과 통합 → 사용자에게 단일 리포트

연구 보조:

[상위] 사용자 질문 분해 → 5 개 서브 질문
[하위 × 5 (병렬)] 각 서브 질문에 대한 검색·요약
[상위] 통합·중복 제거·최종 답변

긴 도구 출력 (웹 페이지·로그) 을 상위가 보지 않고 하위가 요약해서 돌려주면 상위 컨텍스트가 가벼워집니다. "원문은 외부 메모리, 핵심만 요약" 모양.

9. 종료 조건 디자인

서브에이전트가 무한 루프에 빠지지 않도록:

• 단계 한도 (예: 최대 도구 호출 N 회).
• 토큰·시간 한도.
• 명시적 종료 신호 ("최종 답변" 형식).
• 상위의 타임아웃·가로채기.

10. 자주 걸리는 자리

요약 손실 — 하위가 요약해서 돌려주면 상위가 세부를 못 봅니다. 중요 케이스는 raw 자료 일부도 함께 보존.

컨텍스트 중복 — 상위가 매번 큰 컨텍스트를 하위에게 함께 보내면 분할의 의미가 약해짐.

메시지 디자인 부담 — 상위·하위의 인터페이스 (입력 포맷·출력 포맷) 설계가 별도 일.

에러 전파 — 하위 한 명의 실수를 상위가 그대로 받아 다음 단계에 사용. 검증 단계 필요.

비용·지연 증가 — 멀티 호출의 합이 단일 호출보다 비싸질 수 있음.

디버깅의 어려움 — 어느 단계에서 어긋났는지 추적이 어려움. 트레이스·로그·세션 ID 일관성.

사용자 인지 차이 — 사용자가 "한 명에게 부탁한 일" 로 인식하는데 내부적으로는 다중 모델이 돌아 응답이 길어질 수 있음.

비결정성 누적 — 각 단계의 비결정성이 곱해져 출력 품질이 흔들립니다. 단계별 평가셋.

하고픈 말

서브에이전트는 컨텍스트가 폭주할 때 자연스러운 답이지만 작업이 진짜로 독립적이지 않으면 디자인 부담만 늘어납니다. Anthropic 의 "Building effective agents" 가 강조하는 단순함 우선 — 단일 에이전트 + 큰 컨텍스트 윈도 + 도구 결과 요약 메모리 조합으로 충분한 자리가 많습니다. 서브에이전트는 명확한 독립성·병렬성이 보일 때 도입.

Next

• hooks-settings
• claude-md-pattern

LangGraph Multi-agent · Anthropic Building Effective Agents · AutoGen Multi-agent · Claude Code Subagents · CrewAI · Google ADK Multi-agent · GAIA 를 참고합니다.