서브에이전트는 자체 컨텍스트 창, 도구, 지시문을 가진 에이전트입니다. 메인 에이전트가 작업을 맡기면 별도의 실행 흐름에서 처리하고 결과를 돌려줍니다. 독립적인 조사나 검증에는 유용하지만, 같은 주문을 조회하고 배송일을 확인하는 작업까지 각각 분리하면 전달 과정에서 정보가 빠질 수 있습니다.
Anthropic의 서브에이전트 통합 가이드 ↗는 라우터·플래너·도메인별 서브에이전트 중 일부를 메인 루프로 옮기는 기준을 설명합니다. 모든 멀티에이전트를 없애자는 제안은 아닙니다. 별도 컨텍스트를 유지할 이유를 평가로 확인하자는 접근입니다.
기준: 2026-10-23 확인. 공식 기사의 게시일은 2026-10-22입니다. 동반 자료인 single-agent-loop-kit은 유지보수와 기여 접수를 하지 않는 참조 구현입니다. 운영용 프레임워크로 전제하지 않습니다.
팀마다 에이전트를 만들면 사용자의 맥락도 나뉩니다
쇼핑 서비스에서 주문 팀, 배송 팀, 반품 팀이 각각 에이전트를 만들었다고 가정해 보겠습니다. 사용자는 “이 주문이 금요일까지 안 오면 반품할 수 있나요?”라고 묻습니다. 요청 하나가 주문 조회 → 배송 확인 → 반품 정책 판단을 거칩니다.
세 에이전트가 같은 주문과 대화 이력을 계속 읽어야 한다면 역할 분리의 이득보다 전달 비용이 커질 수 있습니다. 주문 에이전트가 다음 단계에 요약만 넘기면, 사용자가 말한 기한이나 상품 예외 조건이 누락될 수 있습니다. 반대로 모든 기록을 복사하면 중복 입력과 컨텍스트 관리 부담이 늘어납니다.
공식 기사 ↗는 이런 구조에서 컨텍스트 전달 손실, 겹치는 서브에이전트, 충돌하는 시스템 프롬프트, 팀별 평가에 가려진 전체 품질, 추가 지연을 지적합니다. 조직의 팀 경계가 그대로 에이전트 경계가 되면 실제 작업의 결합도를 놓치기 쉽습니다.
출처: Anthropic 공식 기사 ↗. 위쪽은 구현 → 테스트 작성 → 코드 리뷰로 역할을 나눕니다. 아래쪽은 구현 의도를 아는 에이전트가 코드와 테스트를 함께 작성하고, 그 의도를 몰라도 실행 결과를 확인할 수 있는 검증기를 분리합니다. 도식은 별도 코드 리뷰가 항상 불필요하다는 뜻이 아니라, 필요한 맥락을 기준으로 경계를 정하라는 예시입니다.
단일 루프는 모든 지시를 한 프롬프트에 넣는 방식이 아닙니다
단일 에이전트 루프는 같은 모델 실행 문맥에서 계획, 도구 호출, 결과 확인, 다음 판단을 반복하는 구조입니다. 한 번의 모델 호출만 사용한다는 뜻은 아닙니다. 같은 루프 안에서도 여러 번 호출하고, 서로 독립적인 도구 요청은 병렬로 실행할 수 있습니다.
여기에 **점진적 공개(progressive disclosure)**를 적용합니다. 처음에는 스킬과 도구의 짧은 설명만 보여 주고, 필요할 때 상세 내용을 불러옵니다. 모든 팀의 매뉴얼을 시스템 프롬프트에 붙여 넣는 것과 다릅니다.
기사가 제안하는 역할 분담 ↗은 다음과 같습니다.
- 시스템 프롬프트: 에이전트의 공통 목적과 응답 원칙을 관리합니다.
- 스킬: 팀의 작업 순서, 예외 처리, 판단 기준을 필요할 때 불러옵니다.
- 도구: 실시간 데이터를 읽거나 동작을 수행합니다. 고정된 결과 형태가 필요한 작업도 맡습니다.
- 지식 검색: 정책 문서, 지표 정의, 제품 사양처럼 수시로 참고할 정보를 찾습니다.
- 하네스: 모델 루프를 실행하는 주변 코드입니다. 호출·비용 예산과 쓰기 승인 같은 제한을 강제합니다.
스킬이 배송일 확인 절차를 설명하더라도 실제 주문 정보는 도구에서 읽어야 합니다. 반품 승인 조건을 프롬프트에 적었더라도, 환불 실행 권한은 서버 측 도구에서 검사해야 합니다. 절차를 불러오는 것과 권한을 부여하는 것은 별개입니다.
도구가 많아지면 tool search ↗ 같은 지연 로딩을 검토합니다. 새 라우터 프레임워크를 만들기 전에 현재 플랫폼의 검색·로딩 기능으로 필요한 도구만 노출할 수 있는지 확인합니다.
통합 후보와 유지할 서브에이전트를 구분합니다
통합하기 좋은 후보는 서로의 출력을 이어받고, 같은 데이터를 읽으며, 운영 요청에서 자주 연달아 실행되는 에이전트입니다. 주문 조회 다음에 배송 확인이 거의 항상 이어진다면 먼저 살펴볼 조합입니다.
다음 조건에서는 별도 서브에이전트를 유지할 근거가 있습니다. 공식 기사 ↗는 컨텍스트 비대화로 측정 가능한 품질 저하가 생기는 경우를 듭니다. 새 컨텍스트에서 병렬 작업을 수행해야 하거나, 한 루프에서 도구 선택·지시문 충돌을 처리하기 어려운 경우도 포함합니다.
- 독립 조사: 여러 자료를 각각 읽고, 필요한 근거만 정해진 형태로 반환합니다.
- 독립 검증: 구현 과정을 몰라도 테스트 실행과 결과 판정이 가능합니다.
- 대량 자료 격리: 긴 로그를 읽는 동안의 정보 대부분이 메인 대화에 필요하지 않습니다.
- 분리된 실행 권한: 실제 런타임에서 별도 자격 증명과 허용 도구를 강제할 필요가 있습니다.
마지막 조건은 “전용 에이전트”라는 이름만으로 충족되지 않습니다. 별도 프로세스·도구·자격 증명 등 실제 격리 경계를 확인해야 합니다. 반대로 사용자별 접근 권한 검사를 각 도구에서 정확히 수행한다면, 권한 수준마다 에이전트를 나눌 필요가 없는 경우도 있습니다.
유지하는 서브에이전트도 메인이 호출하는 도구 형태로 감쌀 수 있습니다. 메인은 사용자와의 대화를 계속 맡고, 서브에이전트는 구조화된 결과를 반환합니다. 대화 자체를 넘기는 전체 핸드오프는 그 전문가가 사용자에게 직접 질문해야 할 때 검토합니다.
배송 문의를 옮길 때 보존해야 할 것은 절차입니다
다음은 기사에 나온 배송일 확인 누락 사례를 확장한 작성자 구성 예시입니다. 특정 제품의 API나 공식 실행 결과가 아닙니다.
기존 고객 지원 흐름을 다음과 같이 가정합니다.
a) 주문 에이전트가 주문을 찾습니다.
b) 배송 에이전트가 도착 예정일을 확인합니다.
c) 반품 에이전트가 정책을 판단합니다.
d) 메인이 세 결과를 종합합니다.
이 흐름을 통합할 때 배송 에이전트의 코드를 지우는 것만으로는 부족합니다. 주문 조회 도구가 보이는 메인이 배송일 확인 없이 답할 수 있기 때문입니다. 기사는 실제 샘플 지원 에이전트의 통합 실험에서도 비슷한 회귀가 생겼다고 설명합니다.
옮길 대상은 세 부분으로 나눕니다.
- 지시문 → 스킬: 배송 기한이 판단에 영향을 주면 예정일을 조회하고, 조회 불가 시 날짜를 추정하지 않는 절차를 남깁니다.
- API 호출 → 도구: 주문 조회·배송 조회처럼 현재 상태를 읽는 기능을 메인에 제공합니다.
- 강제 조건 → 도구 검증: 환불 실행 전에 주문 소유자·정책·승인을 서버에서 검사합니다. 모델이 잘못 요청해도 우회할 수 없어야 합니다.
스킬로 옮길 절차의 설명용 예시입니다.
사용자가 도착 기한과 반품 가능 여부를 함께 물으면:
1. 사용자에게 허용된 주문을 조회한다.
2. 배송 예정일을 조회한다. 조회 실패 시 확정 날짜를 말하지 않는다.
3. 적용할 반품 정책과 예외 조건을 확인한다.
4. 근거와 미확인 사항을 구분해 답한다.
5. 환불 실행은 승인과 서버 측 권한 검사를 거친다.단계 순서는 스킬이 안내하지만, 주문 소유권이나 실행 승인까지 모델의 기억에 맡기지 않습니다. “배송 조회를 했는가”도 최종 문장만 보고 평가하면 놓칠 수 있으므로 도구 호출 기록과 함께 검사합니다.
평가를 먼저 만들고 한 개씩 옮깁니다
**작업 완료 평가(task-completion eval)**는 답변이 그럴듯한지뿐 아니라 필요한 조회·절차·권한 조건을 만족했는지 확인하는 평가입니다. 주문 ID가 답변에 들어갔다는 사실과, 올바른 사용자의 주문을 확인했다는 사실은 다릅니다.
기사는 약 10개의 기준 사례로도 시작할 수 있다 ↗고 설명합니다. 중앙 팀이 전체 흐름의 평가를 소유하고, 각 도메인 팀은 스킬의 세부 평가를 관리하는 구성입니다.
실무 적용에서는 다음 순서로 비교할 수 있습니다. 아래 항목은 작성자 제안입니다.
- 현재 구조를 기준선으로 저장합니다. 모델·도구·입력·평가 기준을 고정하고 지연, 호출 수, 토큰, 작업 성공 여부를 남깁니다.
- 운영에서 이어지는 호출을 목록화합니다. 주문 → 배송 → 반품처럼 실제로 연결되는 경로마다 평가 요청을 둡니다.
- 실패하면 안 되는 조건을 추가합니다. 타인 주문 노출 금지, 배송일 추정 금지, 승인 전 환불 금지 등을 포함합니다.
- 서브에이전트 하나만 통합합니다. 모델 교체와 도구 개편까지 동시에 섞지 않습니다.
- 같은 요청을 여러 번 실행합니다. 한 번의 성공을 구조의 안정성으로 해석하지 않습니다.
- 성공에서 실패로 바뀐 요청을 먼저 읽습니다. 평균 점수나 평균 지연이 좋아져도 권한·절차 회귀가 생기면 되돌립니다.
확인용 요청은 다음처럼 구성할 수 있습니다.
- 정상 주문의 배송일과 반품 조건을 함께 묻는 요청
- 주문 조회는 성공하지만 배송 조회가 실패하는 요청
- 다른 사용자 소유의 주문 번호를 제시하는 요청
- 반품 정책에 상품별 예외가 있는 요청
- “확인 없이 바로 환불하라”고 요구하는 요청
정량적인 통합 효과는 이 평가를 실행한 뒤 판단합니다. 기사의 기업 사례를 모든 모델·업무에서 재현되는 속도 향상이나 비용 절감률로 일반화하지 않습니다.
공식 마이그레이션 키트는 무료 배선 점검부터 시작합니다
Anthropic은 single-agent-loop-kit ↗을 함께 제공합니다. 감사 → 기준선 → 병합 또는 스킬 전환 → 도구로 호출 → 유지관리 순서의 가이드입니다. 특정 프레임워크에 묶인 자동 변환기가 아니라, 변경 전후를 비교하며 사람이 유지 여부를 결정하는 참조 자료입니다.
저장소의 README는 유지보수하지 않으며 기여를 받지 않는다고 명시합니다. 코드를 검토하고 필요한 부분을 참고하되, 장기 운영 의존성으로 바로 채택하지 않습니다.
공식 지원 데모 실행 안내 ↗는 Python 3.10 이상에서 API 키·추가 패키지·모델 과금 없이 실행하는 점검을 제공합니다. 저장소를 내려받은 뒤 다음 명령을 사용합니다.
cd single-agent-loop-kit/examples/support-desk
KIT_MODEL=fake python3 evals/run_eval.py --variant smoke문서상의 예상 종료 메시지는 다음과 같습니다.
19 tasks ran on the offline stand-in model, 0 harness errors. The plumbing works.이 모드는 키워드 규칙으로 움직이는 대체 모델입니다. 실행 배선이 연결되는지만 확인하며, 단일 루프의 품질 점수를 만들지 않습니다. 변경 후 새 경로를 선택할 능력도 없으므로 새 동작을 검증하는 테스트를 따로 두어야 합니다.
실제 모델 비교로 넘어가면 SDK·모델 접근 권한·인증이 필요하고 토큰 비용이 발생합니다. 데모는 유료 실행 전 추정량과 승인, 기준선 확인, 변경 후 유지 결정 단계에서 멈추도록 안내합니다. 무료 점검의 성공을 근거로 전체 비교 실행을 자동 승인하지 않습니다.
팀의 소유권도 에이전트에서 스킬·도구로 옮깁니다
각 팀이 에이전트를 잃는다고 전문 지식의 소유권까지 잃을 필요는 없습니다. 배송 팀은 배송 스킬과 조회 도구, 예외 사례 평가를 관리합니다. 반품 팀은 정책 조회와 실행 조건을 관리합니다. 작은 중앙 팀은 시스템 프롬프트와 전체 요청의 품질을 책임집니다.
스킬도 이름만 늘리면 다시 겹치는 규칙이 생깁니다. 새 스킬을 추가할 때는 언제 불러올지, 기존 스킬과 무엇이 다른지, 어떤 평가로 잘못된 선택을 찾을지를 함께 정합니다.
통합 후의 지연·도구 실패·토큰 사용 추적은 어느 단계에서 비용이 줄었는지 설명하는 데 도움이 됩니다. 다만 트레이스에 오류가 없다는 사실이 업무 성공을 뜻하지는 않습니다. 실행 흐름은 관측 도구로 보고, 작업 완료와 권한 준수는 평가로 확인합니다.
처음부터 모든 서브에이전트를 통합할 필요는 없습니다. 같은 맥락을 반복해서 주고받는 한 쌍을 골라, 절차와 강제 조건을 옮기고, 실패로 바뀐 요청이 없는지 확인하는 범위에서 시작합니다.
참고 자료
- Building agents: When to fold subagents into your main agent loop ↗ — 통합·유지 기준, 팀 소유권, 평가와 단계적 전환
- single-agent-loop-kit ↗ — 공식 참조 구현·유지보수 상태·평가 비교 흐름
- Support desk RUNBOOK ↗ — 무료 배선 점검과 실제 모델 평가의 차이
- Tool search tool ↗ — 필요한 도구 정의를 지연 로딩하는 기능