토큰 낭비 없이 굴리는 Agent Teams: 권한(Permissions) 격리와 읽기 전용 리뷰어 설계

1. Agent Teams 토큰 곱연산(Multiplication) 위험과 컨텍스트 최적화 아키텍처

독립 컨텍스트 확산에 따른 토큰 4배 폭증 위험

에이전트 기반 협업 아키텍처에서 Agent Teams를 구성할 때 가장 주의해야 할 요소는 컨텍스트의 곱연산(Multiplication) 구조입니다.
단일 세션 환경에서는 1개의 컨텍스트 창만 유지되며 토큰이 선형적으로 소비되지만, 4명 에이전트 팀을 가동하는 환경에서는 각 에이전트가 개별적인 독립 컨텍스트를 각각 로드하게 됩니다.
이로 인해 팀이 구동되는 초기화 단계부터 기본 토큰 소모량이 단일 세션 대비 4배로 급증하는 곱연산 현상이 발생합니다.

이러한 아키텍처 구조를 세밀하게 제어하지 않고 방치할 경우, 단순하고 사소한 리팩토링 작업을 수행하는 과정에서도 수백만 토큰이 순식간에 소진되는 비용 폭증 위험에 직면하게 됩니다.
개별 에이전트가 독립된 환경에서 질의와 응답을 주고받을 때마다 중복된 프로젝트 메타데이터와 대화 이력이 복제 로드되기 때문에, 토큰 낭비를 원천 차단하는 정교한 컨텍스트 최적화 아키텍처 설계가 필수적입니다.

서브에이전트 설명(description) 15,000 토큰 한도 관리 및 경량 모델 배정

Claude 공식 문서(code.claude.com/docs/en/sub-agents.md) 지침에 따르면, 내장 서브에이전트를 제외한 서브에이전트들의 설명(description) 총합이 15,000 토큰을 초과할 경우 시스템 시작 시 경고가 발생합니다.
이 경고 기준은 메인 오케스트레이터의 기본 컨텍스트 창이 서브에이전트 메타데이터로 과도하게 잠식되는 것을 방지하기 위해 설정된 제한선입니다.
따라서 각 서브에이전트의 description 필드는 오케스트레이터가 적절한 역할을 판단할 수 있는 라우팅용 요약 정보로 짧게 유지해야 합니다.

실제 에이전트가 수행해야 할 상세한 작업 규칙과 세부 지침은 서브에이전트가 호출되어 실행되는 시점에만 로드되는 시스템 프롬프트 본문으로 완전히 분리하여 이동시켜야 합니다.
이러한 분리 설계를 적용하면 메인 세션의 기본 베이스라인 컨텍스트를 대폭 절약할 수 있으며, 불필요한 메타데이터 전파를 원천적으로 차단할 수 있습니다.

또한 독립 컨텍스트 확산으로 인한 비용을 통제하기 위해, 코드 변경 권한이 없는 리뷰어 및 탐색 전용 에이전트에는 경량 모델(Sonnet/Haiku)을 배정하는 전략이 유효합니다.
전체 팀원에게 고비용 플래그십 모델을 일괄 적용하는 대신, 역할에 맞추어 모델 티어를 격리하고 에이전트의 권한과 역할을 엄격히 제한함으로써 전체 토큰 소비를 대폭 줄일 수 있습니다.

최적화 항목	기존 방식 (위험 요인)	최적화 아키텍처 설계	적용 효과 및 제한 기준
컨텍스트 로드 구조	4인 팀 구동 시 개별 독립 컨텍스트 중복 로드	에이전트 역할 엄격 제한 및 컨텍스트 격리	초기화 토큰 4배 폭증 및 수백만 토큰 낭비 방지
서브에이전트 설명 필드	description에 세부 지침 및 규칙 전체 기술	description은 라우팅용으로 축소, 세부 지침은 시스템 프롬프트 본문 이동	설명 총합 15,000 토큰 초과 시작 경고 방지 및 기본 컨텍스트 절약
모델 티어 배정	모든 에이전트에 동일한 고비용 모델 일괄 할당	리뷰어 및 탐색 에이전트에 경량 모델(Sonnet/Haiku) 배정	불필요한 토큰 소진 방지 및 연산 비용 제어

2. 도구 제한(Tool Restrictions)을 통한 구조적 읽기 전용(Read-only) 리뷰어 구현

최소 권한 원칙 기반의 물리적 쓰기 권한 차단

에이전트 기반 협업 환경에서 코드 리뷰어 서브에이전트에게 단순히 "코드를 수정하지 말라"는 식의 프롬프트 텍스트 지시만 내리는 것은 완벽한 안전을 담보하기 어렵습니다.
LLM 기반 에이전트 시스템에서는 프롬프트 수준의 통제를 넘어 설정 단계에서부터 접근 권한을 제어하는 최소 권한 원칙을 물리적으로 적용해야 합니다.
에이전트 설정 파일의 Frontmatter 메타데이터 내 tools 목록에서 Edit, Write, Bash와 같은 쓰기 및 실행 권한을 완전히 배제하고 오직 Read, Grep, Glob 도구만 선언적으로 부여하는 방식이 권장됩니다.
이러한 도구 격리를 구현하면 에이전트가 파일 시스템에 접근하여 디스크에 새로운 데이터를 기록하거나 기존 소스코드를 임의로 덮어쓰는 행위가 물리적인 인터페이스 레벨에서 디스크 쓰기 차단 상태로 유지됩니다.

코드 리뷰어 설정 파일(.claude/agents/code-reviewer.md) 작성 예시

(1) 목적
소스코드의 결함 및 보안 취약점을 탐지하면서도 원본 파일에 대한 수정 권한을 원천 배제하여 안전한 분석을 수행하는 읽기 전용 코드 리뷰어를 정의하기 위한 설정입니다.

(2) 설정 스니펫

---
name: code-reviewer
description: 코드베이스를 분석하고 보안 결함 및 버그를 지적하는 읽기 전용 리뷰어
# 구조적 권한 격리: Read, Grep, Glob만 허용 (Edit, Write, Bash 삭제는 원천 차단)
tools:
  - Read
  - Grep
  - Glob
---

당신은 엄격한 시니어 코드 리뷰어입니다.
절대로 코드를 직접 수정할 수 없으며, 발견된 문제점은 파일 경로, 라인 번호, 개선 제안 diff 형태로만 작성하여 메인 팀 리드에게 피드백하십시오.

(3) 도구 격리 해설
설정 파일 상단의 Frontmatter 영역에 정의된 tools 파라미터는 에이전트가 호출할 수 있는 도구 범위를 구조적 권한 격리 상태로 한정합니다.
코드베이스 내 파일 구조를 탐색하는 Glob, 특정 키워드나 패턴을 검색하는 Grep, 파일 본문을 열람하는 Read만 등록되어 있으며, 파일 수정 및 명령어를 실행할 수 있는 도구는 제공 목록에서 완전히 삭제되었습니다.
시스템 프롬프트 영역에서는 발견된 문제점을 보고할 때 직접적인 파일 수정 대신 diff 피드백 방식을 채택하도록 명시하여 파일 경로, 라인 번호, 개선 제안 형태의 텍스트 출력만을 생성하도록 유도합니다.

(4) 실행 후 확인할 것
서브에이전트가 태스크를 완료한 후 반환하는 최종 메시지에 개선 제안 diff가 정상적으로 포함되어 있는지 확인해야 합니다.
또한 리뷰어가 지적한 위치의 원본 파일이 디스크 상에서 수정되지 않고 보존되었는지, 쓰기 권한이 없는 상태에서 피드백 리포트만 메인 팀 리드에게 정상 전달되었는지 검증해야 합니다.

도구 격리의 안전성 보장과 도구 제한 시 유의사항

도구 제한(Tool Restrictions) 방식은 에이전트 아키텍처의 구조적 안전 보장을 실현하는 핵심적인 방어선 역할을 수행합니다.
Developer's Digest의 서브에이전트 도구 제한 가이드에 따르면, 이와 같은 하드웨어/API 레벨의 도구 통제는 모델의 탈옥(Jailbreak) 시도나 예상치 못한 환각(Hallucination) 현상이 발생하더라도 무단 파일 수정 도구 호출을 원천 차단합니다.
프롬프트 주입 공격을 통해 에이전트의 역할 정의가 오염되더라도 실행 가능한 쓰기 도구 자체가 런타임에 바인딩되어 있지 않으므로 디스크 훼손 위험을 근본적으로 제거할 수 있습니다.

다만 도구 제한 아키텍처를 도입할 때는 몇 가지 기술적 한계와 주의점을 함께 고려해야 합니다.
도구 제한은 호출 가능한 도구 인터페이스만 제한하는 메커니즘이므로 파일 읽기 자체를 차단하거나 민감 정보에 대한 접근을 선별적으로 통제하는 것은 아닙니다.
또한 탐색 및 분석에 필수적인 도구까지 과도하게 제한할 경우 에이전트가 필요한 콘텍스트를 확보하지 못해 태스크 수행 실패가 비정상적으로 발생할 수 있으므로, 최소한의 읽기 및 탐색 도구(Read, Grep, Glob)는 균형 있게 보장해야 합니다.

3. 에이전트 역할별 권한 매트릭스와 60% 토큰 절감 효과

역할별 권한 및 모델 배정 매트릭스

다중 에이전트 환경에서 각 에이전트에게 무제한 권한을 부여하면 불필요한 파일 수정과 컨텍스트 오염으로 인해 심각한 리소스 낭비가 발생합니다.
이러한 문제를 해결하기 위해 시스템 아키텍처는 Team Lead, Coder Agent, Read-Only Reviewer, Test Runner 등 4가지 핵심 역할로 권한을 엄격히 격리합니다.
각 역할의 목적과 작업 범위에 맞춰 도구 할당 및 모델 티어를 세분화함으로써 실행 안정성과 비용 효율성을 동시에 확보합니다.

에이전트 역할	할당 도구 (Permissions)	권장 모델 티어	역할 정의 및 격리 기준
Team Lead	전체 도구, Task*, SendMessage	Claude Opus / High	조율 중심의 파일 수정 가능, 불필요한 서브태스크 직접 실행 방지
Coder Agent	Read, Edit, Write, Bash	Claude Sonnet / Medium	코드 작성 허용, 단일 파일 단위 스코프 한정
Read-Only Reviewer	Read, Grep, Glob	Claude Sonnet / High	파일 수정 원천 차단, 읽기 전용 검증 수행
Test Runner	Read, Bash(pytest)	Claude Haiku / Low	파일 수정 불가, 테스트 실행 전용 최저 비용 자동 검증

Team Lead는 전체 프로젝트의 워크플로를 지휘하며 Task* 및 SendMessage를 포함한 전체 도구를 활용합니다.
최상위 추론 성능을 가진 Claude Opus(High 티어)를 배정하여 하위 작업의 직접 실행을 방지하고, 에이전트 간 오케스트레이션과 조율에 집중하도록 설계합니다.
반면 실제 구현을 담당하는 Coder Agent에는 Read, Edit, Write, Bash 권한을 부여하며 작업 단위를 단일 파일 단위 스코프로 엄격히 한정하여 Claude Sonnet(Medium 티어) 수준에서 안정적인 코드 작성을 수행하도록 구성합니다.

검증 단계에서는 권한 분할의 이점이 더욱 극대화됩니다.
코드 검토를 전담하는 Read-Only Reviewer에는 탐색 및 조회 도구인 Read, Grep, Glob만을 부여하여 파일 수정을 원천적으로 차단하며, 심층 분석을 위해 Claude Sonnet(High 티어)을 배치합니다.
마지막으로 테스트 실행을 맡는 Test Runner는 Read와 Bash(pytest)만 할당받아 파일 수정 없이 단위 테스트를 실행하며, 가장 경제적인 Claude Haiku(Low 티어)를 통해 최저 비용으로 자동 검증을 완수합니다.

불필요한 코드 재작성 루프 차단과 60% 토큰 절감

기존의 단일 에이전트 방식이나 권한 격리가 없는 구조에서는 검토자가 코드를 직접 수정하면서 의도치 않은 사이드 이펙트와 끝없는 코드 재작성 루프가 빈번하게 일어납니다.
리뷰어가 임의로 코드를 덮어쓰고 다시 테스트가 실패하는 악순환은 불필요한 컨텍스트 누적과 과도한 토큰 소모를 유발하는 주된 원인이었습니다.
Target A 자료에 따르면, 수정 권한이 배제된 Read-Only Reviewer 설계를 적용했을 때 이러한 불필요한 코드 재작성 루프를 원천 차단하여 전체 토큰 소모량을 60% 절감하는 성과를 달성했습니다.

권한 격리를 통해 리뷰어는 순수하게 정적 분석과 로직 검토 결과만을 피드백 형태로 전달하며, 실제 코드 변경은 지정된 Coder Agent만이 제한된 스코프 내에서 수행합니다.
이러한 파이프라인 분리는 에이전트 간의 역할 충돌을 방지하고 불필요한 재생성 연산을 줄여 토큰 효율성을 극대화합니다.
결과적으로 고성능 모델의 낭비를 막고 각 작업에 최적화된 모델과 권한만을 결합함으로써 대규모 에이전트 팀 운영 비용을 대폭 절감할 수 있습니다.

4. Claude Code 내장 서브에이전트 규격 변화와 Explore 오버라이드 메커니즘

v2.1.198 서브에이전트 규격 변경과 단일화된 설정 경로

Claude Code 도구 생태계에서 서브에이전트 동작 규격은 v2.1.198 버전을 기점으로 대대적인 개편이 이루어졌습니다.
기존에 제공되던 터미널 인터랙티브 마법사 명령어인 /agents가 공식적으로 제거되었으며, 설정 방식이 .claude/agents/ 디렉토리 내에 설정 파일을 직접 생성하는 단일화 경로로 통합되었습니다.
이러한 인터페이스 단일화는 개발자가 에이전트 구성을 코드베이스 기반으로 명확하게 관리할 수 있도록 설계된 변화입니다.

더불어 모델 상속 정책에서도 중대한 아키텍처 수정이 적용되었습니다.
과거 기본 탐색을 전담하던 내장 Explore 에이전트는 Haiku 모델로 고정 동작했으나, v2.1.198부터는 메인 세션에서 구동 중인 모델을 그대로 상속받는 정책으로 전환되었습니다.
이때 Claude API 환경을 기준으로는 Opus 캡(Cap)이 적용되어 과도한 모델 할당을 제어하도록 구성되어 있습니다.

Explore/Plan 에이전트의 일회성 동작과 컨텍스트 최적화

내장 Explore 및 Plan 서브에이전트는 코드베이스를 빠르게 훑고 실행 계획을 세우는 데 특화된 내부 경량화 프로세스를 가집니다.
이들 서브에이전트는 작업 호출 시 프로젝트의 기본 가이드라인인 CLAUDE.md 파일 로딩과 git status 확인 과정을 건너뜁니다.
불필요한 컨텍스트 주입을 사전에 차단함으로써 파일 구조 탐색 속도를 극대화하고 토큰 소비 비용을 최적화하도록 설계되었습니다.

반면, 이러한 탐색 및 기획 에이전트는 상태 유지가 필요 없는 일회성(one-shot) 구조로 동작합니다.
실행 완료 후 별도의 Agent ID를 반환하지 않기 때문에 이전 탐색 세션을 다시 불러와 대화를 재개하는 것은 불가능합니다.
따라서 탐색이 완료되면 그 결과 요약만을 부모 세션에 전달하고 서브에이전트 컨텍스트는 즉시 소멸하는 방식을 취합니다.

구분	Explore / Plan 서브에이전트 규격	기본 세션 및 일반 에이전트
설정 경로	.claude/agents/ 디렉토리 직접 생성 단일화	.claude/agents/ 디렉토리 직접 생성 단일화
기본 모델 정책	메인 세션 모델 상속 (Claude API 기준 Opus 캡 적용)	사용자 지정 세션 모델 유지
초기 컨텍스트 로딩	CLAUDE.md 및 git status 로딩 건너뜀	프로젝트 설정 및 Git 상태 로딩 수행
세션 지속성	일회성(One-shot) 동작 / Agent ID 미반환(재개 불가)	세션 컨텍스트 유지 및 지속적 상호작용

Haiku 오버라이드 설정 및 환경변수 제어

Explore 에이전트가 메인 모델을 상속하게 되면서 고성능 모델 사용 시 단순 탐색 작업에서 토큰 비용이 상승할 수 있습니다.
이를 방지하고 이전처럼 저비용 모델로 탐색을 고정하려면 .claude/agents/ 디렉토리 내에 서브에이전트 설정을 정의하여 기본값을 오버라이드해야 합니다.

(1) 목적: 내장 Explore 서브에이전트의 모델을 메인 세션 상속 대신 저비용 Haiku 모델로 강제 고정하여 탐색 토큰 비용을 절감합니다.
(2) 코드/명령:

model: haiku

(3) 의미: .claude/agents/ 경로에 Explore 서브에이전트 설정 파일을 배치하고 model: haiku를 명시함으로써, 내장 상속 규칙을 무효화하고 지정된 Haiku 모델로 강제 전환합니다.
(4) 결과: 파일 탐색 명령 수행 시 고비용 메인 모델 대신 Haiku 모델로 Explore 에이전트가 호출되는 동작을 실행 로그나 사용량 명세에서 확인할 수 있습니다.

(1) 목적: 서브에이전트 위임 자체를 비활성화하고 메인 세션이 직접 파일 구조를 조회하도록 강제합니다.
(2) 코드/명령:

CLAUDE_CODE_DISABLE_EXPLORE_PLAN_AGENTS=1

(3) 의미: 시스템 환경변수에 CLAUDE_CODE_DISABLE_EXPLORE_PLAN_AGENTS=1을 할당하여 Explore 및 Plan 서브에이전트로의 작업 분기를 원천 차단합니다.
(4) 결과: 환경변수 적용 후 세션 실행 시 서브에이전트 호출 단계 없이 메인 세션이 직접 파일을 조회하는 방식으로 전환되어 작동합니다.

5. 서브에이전트 스코프 우선순위 계층과 Frontmatter 설정 규격

5단계 스코프 우선순위 계층 및 디렉토리 충돌 해결 규칙

서브에이전트를 활용해 팀 단위 작업을 분기할 때, 시스템이 어떤 경로의 설정을 먼저 참조하는지 명확히 이해해야 의도치 않은 권한 상승이나 잘못된 모델 호출을 방지할 수 있습니다.
Claude Code 공식 문서에 명시된 서브에이전트 스코프의 우선순위 계층은 5단계로 정밀하게 분기됩니다.
가장 높은 우선권을 갖는 1순위는 조직 차원에서 일괄 제어되는 Managed settings이며, 그 뒤를 이어 2순위인 --agents CLI 플래그로 전달된 설정이 적용됩니다.
그다음으로 3순위인 프로젝트 로컬 레벨의 .claude/agents/ 디렉토리, 4순위인 사용자 전역 레벨의 ~/.claude/agents/ 디렉토리, 마지막 5순위로 Plugin agents/ 순서로 우선순위가 결정됩니다.
이러한 계층 구조를 기반으로 상위 스코프에 동일한 명칭의 서브에이전트가 존재할 경우 하위 스코프의 설정을 자연스럽게 덮어쓰도록 동작합니다.

모노레포나 복합 프로젝트 구조에서 발생하기 쉬운 중첩 디렉토리 명칭 충돌 문제 역시 명문화된 규칙에 따라 처리됩니다.
v2.1.178 릴리스부터는 중첩된 프로젝트 디렉토리 내에서 동일한 에이전트 이름이 충돌할 경우, 현재 작업 디렉토리에 가장 가까운 정의가 우선 적용되는 규칙이 도입되었습니다.
이를 통해 하위 모듈 단위로 별도 정의된 .claude/agents/ 설정이 상위 디렉토리의 기본 설정을 정교하게 오버라이드할 수 있습니다.
다만 시스템 운영 시 주의해야 할 점으로, 기존에 존재하지 않던 agents/ 디렉토리를 신규 생성한 환경에서는 내부 파일 감시자가 이를 즉각 감지하지 못하므로 반드시 Claude Code 재시작을 수행해야만 새로운 에이전트 정의가 정상 로드됩니다.

Frontmatter 필수·지원 필드 규격과 worktree 격리 설정

서브에이전트의 작동 방식과 제어 범위는 마크다운 파일 상단의 Frontmatter 설정 규격을 통해 선언됩니다.
에이전트 파일 구성 시 누락되어서는 안 되는 필수 필드는 에이전트의 고유 식별자인 name과 호출 목적 및 역할을 정의하는 description 등 2개로 한정됩니다.
이 두 가지 필수 항목 외에도 권한 통제와 토큰 절감을 위한 다양한 지원 필드가 제공됩니다.
도구 사용 범위를 통제하는 tools 및 disallowedTools, 할당 모델을 지정하는 model, 권한 승인 방식을 결정하는 permissionMode가 대표적입니다.
추가로 skills, mcpServers, hooks, memory, isolation 등 다양한 제어 필드를 결합하여 에이전트의 구동 환경을 엄격히 통제할 수 있습니다.

코드베이스 수정을 동반하는 고위험 작업이나 독립적인 분석을 수행할 때는 isolation: worktree 설정을 적용할 수 있습니다.
해당 필드가 활성화된 서브에이전트는 메인 작업 트리를 직접 건드리지 않고, 임시 git worktree 내부에서 독립적으로 격리 실행됩니다.
작업 과정에서 발생하는 파일 변경 사항이 격리된 공간 내에서만 처리되므로 메인 워킹 디렉토리의 오염을 원천 차단하며 안전한 검증 환경을 보장합니다.

필드명	필수 여부	지원 및 동작 설명
name	필수	서브에이전트를 호출하고 식별하기 위한 고유 이름 정의
description	필수	에이전트의 역할, 목적 및 작업 위임 기준 설명
tools	선택	에이전트가 호출 가능한 도구 목록을 명시적으로 제한
disallowedTools	선택	에이전트의 실행 환경에서 사용을 강제 차단할 도구 목록 지정
model	선택	서브에이전트 구동에 사용할 특정 LLM 모델 지정
permissionMode	선택	도구 실행 및 파일 접근에 대한 권한 승인 모드 제어
isolation	선택	worktree 설정 시 임시 git worktree 내에서 독립 격리 실행
기타 확장 필드	선택	skills, mcpServers, hooks, memory 설정 지원

6. Agent Teams 오케스트레이션 차이와 SubagentStop 훅 기반 사후 검증

Subagents 단방향 보고 vs Agent Teams 공유 태스크 통신

다중 에이전트 환경에서 작업 부하를 분산하고 협업을 구성하는 방식은 구조적 설계에 따라 오케스트레이션 아키텍처가 크게 달라집니다.
전통적인 Subagents 구조는 메인 에이전트가 하위 작업 단위로 생성한 서브에이전트로부터 단방향 결과 요약만 취합하여 보고받는 계층적 형태를 취합니다.
반면 Agent Teams 모델은 중앙화된 단방향 보고에 머무르지 않고 공유 태스크 목록을 기반으로 에이전트 간 직접 통신을 수행하도록 동작합니다.
이를 통해 에이전트 상호 간의 유기적인 피드백 교환과 실시간 상태 동기화가 가능해집니다.

구분	Subagents 오케스트레이션	Agent Teams 오케스트레이션
통신 방식	메인 에이전트로의 단방향 결과 요약 보고	공유 태스크 목록 기반 에이전트 간 직접 상호 통신
작업 격리 및 병렬화	순차적 또는 기본 샌드박스 위임	Git Worktree 연동 디렉토리별 독립 브랜치 격리
완료 검증 체계	LLM 자체 요약 평가 의존	SubagentStop 훅 매처 기반 결정론적 스크립트 실행

Git Worktree 기반 독립 병렬 실행

여러 에이전트가 동시에 코드베이스를 수정하거나 기능을 개발할 때 발생할 수 있는 충돌을 방지하기 위해 Git Worktree 연동 병렬화가 적용됩니다.
독립적인 작업 환경을 물리적으로 격리함으로써 에이전트 간의 파일 덮어쓰기나 변경 사항 간섭 문제를 원천 차단합니다.

(1) 목적: 디렉토리별로 독립된 브랜치 작업 환경을 격리하여 생성하고 태스크 완료 후 자동으로 리소스를 정리하기 위해 실행합니다.
(2) 명령어:

claude --worktree <branch>

(3) 의미: 지정한 <branch> 이름을 기반으로 별도의 작업 디렉토리를 자동 구성하여 에이전트 작업 공간을 완전히 격리하며, 작업 종료 시 해당 Worktree 환경을 안전하게 자동 정리합니다.
(4) 결과: 명령어 실행 후 대상 브랜치로 격리된 독립 작업 공간이 생성되며, 서브에이전트 세션 종료 시 디렉토리와 브랜치 상태가 자동으로 정리되었는지 작업 트리를 통해 확인할 수 있습니다.

SubagentStop 훅을 활용한 결정론적 사후 검증

서브에이전트가 작업을 완료했다고 보고할 때 생성 모델의 자체적인 판단에만 의존하면 작업 완료 여부의 신뢰성이 저하될 위험이 있습니다.
이를 보완하기 위해 서브에이전트 종료 시점에 트리거되는 SubagentStop 훅을 연동하여 사후 검증을 수행합니다.
훅에 지정된 매처(matcher)를 통해 서브에이전트 종료 신호가 감지되면 사전 정의된 스크립트를 자동 실행하여 결과물을 결정론적으로 검증합니다.
이러한 결정론적 스크립트 검증을 통과해야만 후속 워크플로우로 상태가 전이되도록 통제할 수 있습니다.

그러나 무분별한 에이전트 분할은 오히려 시스템의 비효율을 초래합니다.
10개 이상의 서브에이전트 연쇄 위임과 같은 과도한 오케스트레이션이 발생할 경우, 컨텍스트 절약 효과는 사라지고 중간 보고 누적에 따른 컨텍스트 세탁 현상이 발생합니다.
또한 단계별 통신 오버헤드로 인해 응답 지연 시간이 급격히 증가하므로, 공유 태스크 기반의 팀 설계와 명확한 훅 검증을 결합한 적정 수준의 위임 전략이 필수적입니다.