서브에이전트는 왜 ‘AI를 여러 명 붙이기’가 아니라 컨텍스트 격리 계약일까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 에이전트 작업을 여러 전문 에이전트로 나눌 때, 언제 성능이 좋아지고 언제 비용과 혼란만 늘어날까?
• 핵심 출처:
  • Subagents in the SDK - Claude Code Docs - 게시일 미표기, 확인일 2026-06-26
  • How and when to use subagents in Claude Code - 2026-04-07, 확인일 2026-06-26
  • Orchestration and handoffs - OpenAI API - 게시일 미표기, 확인일 2026-06-26
  • Subgraphs - LangGraph Docs - 게시일 미표기, 확인일 2026-06-26

1. 왜 지금 봐야 하나

최근 에이전트 SDK와 코딩 에이전트 문서를 보면 공통적으로 “하나의 만능 에이전트”보다 “작은 전문 단위로 나뉜 에이전트”를 강조한다. Claude Agent SDK는 subagent를 별도 agent instance로 실행해 컨텍스트를 격리하고, 병렬 분석과 제한된 도구 권한을 적용할 수 있다고 설명한다. OpenAI Agents 문서는 handoff와 agents-as-tools를 구분하며, 전문 에이전트를 추가할지 말지는 “누가 최종 응답을 소유하는가”와 “계약이 달라지는가”로 판단하라고 한다. LangGraph는 subgraph를 부모 graph 안의 node로 다루면서, 부모와 자식 graph의 상태 schema가 어떻게 연결되는지를 먼저 정하라고 한다.

이 흐름에서 중요한 점은 “에이전트를 여러 개 띄우면 더 똑똑해진다”가 아니다. 오히려 무작정 나누면 프롬프트 수, trace, 승인 지점, 비용, 디버깅 면적이 늘어난다. 서브에이전트의 핵심 가치는 지능 증가가 아니라 컨텍스트·권한·상태·책임을 작은 계약으로 격리하는 것이다.

2. 핵심 개념

서브에이전트는 메인 에이전트가 특정 하위 작업을 맡기는 별도 실행 단위다. 여기서 “별도”라는 말에는 네 가지 의미가 있다.

첫째, 컨텍스트 격리다. Claude 문서는 subagent가 fresh conversation에서 동작하고, 중간 tool call과 탐색 결과는 subagent 안에 남으며, 부모에게는 최종 결과만 돌아간다고 설명한다. 긴 코드베이스 탐색, 로그 분석, 문서 검색처럼 많은 중간 자료가 필요한 작업에서는 이것이 큰 차이를 만든다. 모든 파일 내용과 시행착오를 메인 대화에 넣지 않아도 되기 때문이다.

둘째, 전문 지시문 분리다. 코드 리뷰어, 테스트 러너, 보안 스캐너, 리서처는 서로 다른 판단 기준을 가진다. 하나의 시스템 프롬프트에 모든 역할을 욱여넣으면 지시문이 길어지고 우선순위가 충돌한다. 서브에이전트는 “이 작업에는 이 기준만 적용한다”는 좁은 지시문을 줄 수 있다.

셋째, 도구 권한 분리다. 예를 들어 문서 리뷰 subagent는 읽기 도구만, 테스트 runner는 명령 실행 도구만, 배포 agent는 별도 승인 없이는 쓰기 도구를 못 쓰게 만들 수 있다. 같은 LLM이더라도 어떤 tool surface를 보여주느냐에 따라 위험도가 달라진다.

넷째, 상태 schema 분리다. LangGraph의 subgraph 문서가 특히 이 부분을 잘 보여준다. 부모 graph와 subgraph가 같은 state key를 공유하면 subgraph를 node처럼 붙일 수 있지만, 서로 다른 state schema를 쓰면 wrapper function으로 parent state를 subgraph input으로 변환하고, 결과를 다시 parent state로 변환해야 한다. 즉 “에이전트 분리”는 코드 수준에서는 상태 변환 계약이다.

3. 최신 이슈와 연결

Claude Code의 subagents 글은 subagent를 “브라우저 탭”에 비유한다. 옆길로 새서 많은 파일을 읽고 탐색하되, 메인 작업 흐름은 깨끗하게 유지한다는 뜻이다. 문서는 특히 세 가지 신호를 제시한다. 많은 파일을 읽어야 하는 리서치, 서로 의존하지 않는 독립 작업, 커밋 전 fresh perspective가 필요한 검증이다.

OpenAI Agents 문서는 비슷한 문제를 다른 언어로 표현한다. 여러 agent를 붙일 때는 먼저 orchestration pattern을 고르라고 한다. specialist가 사용자-facing 응답을 이어받아야 하면 handoff, manager가 최종 답변을 합성해야 하면 agents as tools가 맞다. 그리고 “specialist는 계약이 달라질 때만 추가하라”고 경고한다. 기능이 조금 다르다는 이유만으로 agent를 쪼개면 routing surface와 trace만 복잡해질 수 있다.

LangGraph는 subgraph를 통해 더 구현적인 질문을 던진다. 부모와 자식이 state를 공유할 것인가, 아니면 private state를 둘 것인가? per-invocation persistence로 독립 호출을 유지할 것인가, per-thread persistence로 subagent가 장기 기억을 갖게 할 것인가? 이 선택은 단순 프롬프트 문제가 아니라 장애 재현, 병렬 실행, 사용자별 상태 오염에 직접 영향을 준다.

4. 개발자 관점 해석

실무에서 서브에이전트 설계는 다음 질문으로 시작하는 편이 안전하다.

“이 하위 작업의 중간 컨텍스트를 메인 에이전트가 계속 알아야 하는가?”

아니라면 subagent 후보가 된다. 예를 들어 “레포에서 인증 흐름을 조사해서 10줄로 요약해줘”는 subagent가 좋다. 중간에 읽은 파일 30개의 원문은 메인 에이전트에게 대부분 노이즈다. 반대로 “사용자와 계속 대화하며 요구사항을 조정해야 하는 상담 흐름”은 handoff나 단일 active agent가 나을 수 있다. 중간 대화 맥락 자체가 제품 경험이기 때문이다.

두 번째 질문은 **“최종 책임자가 누구인가?”**다. manager가 결과를 합성해야 하면 specialist를 tool처럼 호출한다. 이 경우 specialist의 출력은 구조화되어야 한다. 예를 들어 {risk_level, evidence, suggested_patch} 같은 schema가 있어야 manager가 비교·합성할 수 있다. 반대로 환불, 결제, 기술지원처럼 specialist가 다음 사용자 응답을 직접 맡는 흐름이라면 handoff가 자연스럽다.

세 번째 질문은 **“권한이 달라지는가?”**다. 권한이 같다면 agent를 나누는 이득이 줄어든다. 읽기 전용 보안 리뷰어, 명령 실행 가능한 테스트 러너, 쓰기 가능한 수정 agent처럼 tool 권한이 달라질 때 분리 효과가 커진다.

네 번째 질문은 **“상태를 공유하면 위험한가?”**다. subagent가 고객별 정보, 임시 검색 결과, 실패한 추론, 민감 로그를 다룬다면 private state가 필요하다. 반대로 여러 agent가 같은 task board나 shared messages를 갱신해야 한다면 공유 state가 필요하다. 이 구분이 없으면 “어느 agent가 어떤 근거로 결론을 바꿨는지”를 나중에 추적하기 어렵다.

5. 내 프로젝트에 적용할 체크포인트

• 하위 작업이 10개 이상의 파일, 문서, 로그를 읽어야 한다면 메인 컨텍스트에 직접 넣지 말고 subagent 요약으로 받는다.
• specialist를 만들 때는 description을 “언제 사용해야 하는지” 중심으로 쓴다. 이름보다 routing 설명이 중요하다.
• subagent 출력은 자유 텍스트보다 짧은 schema로 받는다. 예: findings, evidence_paths, confidence, next_action.
• manager-style이면 specialist는 tool처럼 호출하고, manager만 최종 사용자 답변을 만든다.
• handoff-style이면 사용자가 어느 specialist와 대화 중인지, 이전 agent의 요약이 어떻게 전달되는지 명확히 한다.
• 읽기 전용, 실행 가능, 쓰기 가능, 배포 가능 권한을 subagent별로 나눈다.
• 병렬 subagent를 쓸 때는 서로 같은 파일을 동시에 수정하지 않게 한다. 병렬화는 탐색과 검증에 먼저 적용하고, 쓰기 작업은 merge 지점을 둔다.
• trace에는 parent_run_id, subagent_name, input_summary, output_summary, tool_permissions를 남긴다.
• 실패 시 “LLM이 틀렸다”가 아니라 routing 오류, state 변환 오류, 권한 오류, 출력 schema 오류 중 어디인지 분류한다.

6. 오늘 10분 액션

내가 만들고 있는 AI 기능 하나를 골라 아래 표를 채워보자.

후보 작업	메인 컨텍스트에 중간 결과가 필요한가?	최종 답변 소유자	필요한 도구 권한	추천 구조
예: 레포 보안 리뷰	아니오. 파일 탐색 결과 요약만 필요	manager	read-only	subagent as tool
예: 결제 문의 응대	예. 사용자가 specialist와 이어서 대화	billing specialist	DB 조회, 환불 요청은 승인 필요	handoff
예: 테스트 실패 원인 찾기	일부만 필요. 로그 요약 필요	manager	test command 실행	subagent as tool

10분 안에 끝내려면 실제 구현 대신 “분리하지 않을 작업 1개”와 “분리할 작업 1개”만 정한다. 좋은 에이전트 설계는 많이 쪼개는 것이 아니라, 쪼갤 이유가 있는 경계를 찾는 일이다.

7. 더 볼 자료

• Subagents in the SDK - Claude Code Docs
• How and when to use subagents in Claude Code
• Orchestration and handoffs - OpenAI API
• Subgraphs - LangGraph Docs

중복 회피 메모

최근 ai_dev 글은 백그라운드 에이전트의 비동기 작업 큐, 장기 실행 에이전트의 memory/checkpoint 분리, 실시간 세션 상태 머신, LLM 라우터와 prefix cache, MCP Elicitation, guardrail checkpoint를 다뤘다. 이번 글은 특정 API의 background 실행이나 memory 저장이 아니라, 여러 전문 에이전트로 작업을 나눌 때 컨텍스트 격리, 권한 분리, handoff와 agents-as-tools 선택, subgraph state schema 계약을 어떻게 판단할지에 집중한다.