Building agents: When to fold subagents into your main agent loop

3줄 요약

1. Anthropic Applied AI 팀의 다이앤 사키스(Diane Sarkis)가 2026년 10월 22일 아키텍처 가이드를 발표했다. 이 가이드는 여러 서브에이전트로 구성된 기업용 에이전트 시스템을 언제 단일 메인 에이전트 루프로 통합해야 하는지 설명한다.
2. 여러 기업의 실제 배포 사례에서는 라우터와 플래너, 도메인 서브에이전트를 단일 루프로 통합하고, 스킬과 도구 검색으로 필요한 맥락을 점진적으로 제공했다. 이 설계는 만능 단일 프롬프트나 멀티에이전트 구조보다 응답 품질이 높았으며 비용과 지연 시간도 낮았다.
3. 조직도를 그대로 본뜬 서브에이전트 구조는 맥락 유실과 프롬프트 지침 충돌을 불러온다. 과제 완수 평가셋(eval)을 먼저 마련하고, 긴밀하게 연동되는 에이전트를 병합한 뒤 서브에이전트를 도구로 호출하고 스킬과 MCP 도구로 전환하는 각 단계를 검증해야 한다.

왜 서브에이전트를 메인 루프로 통합하는가

서브에이전트(subagent)는 고유한 컨텍스트 윈도우와 도구, 시스템 지침을 갖춘 채 조율자(coordinator) 에이전트의 호출을 받아 동작하는 구성 요소다. 결과 검증이나 독립적인 병렬 처리, 권한 분리에는 여전히 효과적이며 Anthropic의 멀티에이전트 리서치 시스템에서도 핵심 역할을 맡고 있다.¹

하지만 최근 Anthropic Applied AI 팀이 여러 엔터프라이즈 에이전트 배포 사례를 비교한 결과, 라우터와 플래너, 도메인별 서브에이전트를 메인 에이전트 루프 하나로 통합했을 때 성능이 크게 개선되는 사례가 반복해서 확인됐다. 스킬(skills)을 갖춘 단일 에이전트는 모든 지침을 프롬프트 하나에 몰아넣은 설계나 다중 서브에이전트 설계보다 높은 응답 품질을 기록했고, 과제당 비용과 지연 시간도 낮았다. 예를 들어 한 기업은 고객 응대 에이전트 내부에 전문 서브에이전트를 십여 개 두었더니 브랜드 어조를 일관되게 유지하기 어려웠고 지연 시간이 길어져 사용자 경험이 저하됐다.

현장에서 자주 제안되는 에이전트 아키텍처는 대개 비슷한 5단계 구성을 따른다. 의도 분류기(intent classifier)가 요청을 분류한 뒤, 고정된 다단계 추론 파이프라인이 요청을 처리한다. 이어 사용자를 세그먼트별로 분류하고 추천 분기를 선택하며, 최상위 멀티에이전트 오케스트레이터가 전체 과정을 조율한다. 이전 세대 모델이 스스로 처리하지 못하던 추론 단계를 외부 파이프라인으로 메우려던 설계였으나, 요즘 모델은 이런 부가 구조가 맡던 일을 자체 추론으로 해낸다. 명확한 시스템 프롬프트 하나와 가벼운 데이터 조회 도구 4~5개, 분명한 출력 가드레일만 준비하면 동일한 유스케이스 대부분을 충분히 처리할 수 있는 이유다.

대규모 조직에서 멀티에이전트 설계가 실패하는 5가지 양상

대규모 기업은 흔히 여러 제품과 기능을 단일 고객 인터페이스로 통합한 에이전트를 만들려 한다. 이때 기능마다 담당 팀이 다르다 보니 각 팀이 자기 에이전트를 개발하기 쉽다. 중앙 플랫폼 팀은 이 에이전트들을 조율하는 오케스트레이터를 구성하게 된다. 에이전트 아키텍처가 기업의 조직도를 그대로 복제한 형태가 되는 셈인데, 이는 시스템 구조가 조직의 의사소통 구조를 닮는다는 콘웨이의 법칙(Conway’s law)이 에이전트 설계에 그대로 나타난 결과다.

가장 단순한 협업 방식처럼 보이지만, 운영에 들어가면 곧바로 다섯 가지 문제가 나타난다.

• 컨텍스트 관리 손실: 에이전트 사이에 어떤 맥락을 전달할지 매번 결정해야 하며, 여러 에이전트가 정보를 주고받는 과정에서 세부 맥락이 유실된다.
• 서브에이전트 난립(Subagent sprawl): 팀마다 독자적인 서브에이전트를 배포하면서 공통 표준이나 전담 책임자가 없는 중복 서브에이전트가 수백 개까지 늘어난다.
• 프랑켄프롬프트(The Frankenprompt): 모든 팀이 시스템 프롬프트에 자기 팀의 규칙을 조금씩 추가한 결과, 규칙끼리 충돌하고 일관된 화자 목소리가 사라진다.
• 검증되지 않은 국소 평가(Unvetted, overly localized evals): 각 팀은 자신이 담당하는 하위 과제에만 최적화한 평가를 따로 추가한다. 전체 평가 세트를 관리하는 주체가 없어, 경영진은 전체 성능을 제대로 반영하지 못하고 일부 과제에 치우친 점수에 의존해 의사결정을 하게 된다.
• 지연 시간(Latency) 증가: 다중 에이전트 구조의 복잡성 때문에 응답 지연 시간이 길어진다. 기존 멀티에이전트 하네스를 단일 에이전트 루프와 비교 측정한 한 고객사에서는 단일 루프의 실행 속도가 약 2배 빠르게 나타났다.

점진적 공개를 결합한 단일 에이전트 루프

여러 팀이 만든 전문 기능을 조율할 때는 오케스트레이터와 서브에이전트 대신 스킬을 통한 맥락의 점진적 공개(progressive disclosure)와 도구 검색(tool search)을 통한 도구의 점진적 공개로 단일 루프를 구성할 수 있다. 스킬과 도구의 짧은 요약 설명만 먼저 제시하고, 작업에 필요한 순간에만 전체 지침과 도구 정의를 불러오는 방식이다.

이 설계가 유리한 이유는 세 가지다.

첫째, 공유된 컨텍스트가 더 풍부한 답변을 만든다. 장시간 실행되는 에이전트는 여러 선행 작업의 결과를 메인 컨텍스트 윈도우에서 함께 참조할 수 있어야 한다. 그래야 각 단계의 결과를 종합해 더 깊이 분석할 수 있다. 서브에이전트들이 요약본만 반환하는 구조에 비해 컨텍스트 윈도우 개수가 줄고 핸드오프 과정의 정보 손실도 줄어든다.

둘째, 점진적 공개가 컨텍스트 비대화를 방지한다. 모든 맥락을 긴 시스템 프롬프트 하나에 즉시 불러올 필요가 없으므로, 과거에 팀들이 작업을 여러 서브에이전트로 분리해야 했던 주된 이유가 사라진다. 고성능 모델용 Claude Code 시스템 프롬프트 분량을 80% 이상 줄일 수 있었던 것도 스킬과 도구의 점진적 공개를 적용한 덕분이었다.

셋째, 모델 자체의 수행 능력이 크게 향상됐다. Opus 4.5 이후 모델들은 대부분의 팀이 예상했던 것보다 훨씬 많은 작업을 단일 루프에서 처리할 수 있게 됐다. Opus 5.5와 Fable 5.1에서는 사고(thinking) 기능을 끌 수 없다. 최신 모델은 작업 도중 스스로 진행 상황을 설명하고 중간 결과를 점검한다. 이에 따라 기존 하네스가 제공하던 보조 기능 상당수가 불필요해졌다. 새 모델이 출시되면 하네스가 맡던 의사결정 로직을 모델 내부로 이관할 수 있고, 루프가 단순한 덕분에 차세대 모델로 이전하기도 쉽다.²

단일 에이전트 루프를 안정적으로 운영하려면 소수의 중앙 팀이 엔드투엔드 품질과 시스템 프롬프트를 전담해 관리해야 한다. 새로 배포할 모든 도구와 평가도 이 팀이 사전에 검수해야 한다. 소규모 전담 팀이 중심을 잡아야 대규모 조직의 조율 비용을 줄이면서 빠른 반복 개선을 이어갈 수 있다.

문제 유형별로 에이전트를 분리하면 핸드오프마다 맥락이 유실되지만, 컨텍스트 기준으로 분리하면 구현 맥락이 필요 없는 검증기만 별도로 분리할 수 있다. 출처: Anthropic

멀티에이전트 구조를 유지해야 하는 상황이라면 생성기와 검증기(generator-verifier) 같은 가장 단순한 패턴부터 시작해야 한다. 이때 에이전트 간 역할은 문제 유형 대신 컨텍스트 기준으로 구분해야 한다. 시스템의 다른 부분과 공유할 맥락이 거의 없고 간결한 결과만 반환하면 되는 독립 조사 경로, 인터페이스가 명확한 개별 컴포넌트, 혹은 블랙박스 검증기가 적합한 후보다. 문제 유형을 기준으로 삼아 기능 작성, 테스트 작성, 코드 리뷰 에이전트를 각각 분리하면 핸드오프가 일어날 때마다 원래 맥락이 깎이는 전언 게임(telephone game)이 벌어진다. 테스트 작성 에이전트는 기능 작성 에이전트가 왜 그런 구현 결정을 내렸는지 알지 못한 채 테스트를 작성하게 된다.

서브에이전트를 메인 루프로 통합하는 단계별 방법

이미 오케스트레이터와 다수의 전문 서브에이전트를 프로덕션에서 운영 중인 팀이라면 다음과 같은 단일 루프 구조를 목표로 삼을 수 있다.

• 하나의 모델이 하나의 컨텍스트 윈도우를 사용해 개방형 도구 루프를 실행한다. 하네스는 턴 수와 비용 예산의 한도를 관리하고, 쓰기 작업에 승인이 필요한지 확인한다.
• 매 턴마다 모델이 도구 호출 배치를 생성하면 하네스가 이를 병렬로 실행한 뒤 가공하지 않은 원본 결과를 동일한 모델에 돌려준다. 모델은 그 결과를 보고 추가 도구 호출, 사용자 질문, 최종 답변 중 다음 단계를 스스로 결정한다.
• 모델이 답변을 완료하거나 예산을 모두 사용하면 루프가 종료된다. 답변 직후에는 목표를 달성했는지 확인하거나 검증기를 실행하도록 선택할 수 있다.
• 모델은 첫 번째 턴에 컨텍스트 내부에 계획을 작성하고 실행 결과가 도착할 때마다 계획을 수정한다. 계획을 세운 모델이 실행까지 직접 수행하므로, 오케스트레이터와 전문 서브에이전트를 분리했을 때와 달리 턴 도중에도 중간 결과에 맞춰 계획을 즉시 수정할 수 있다.
• 맥락 적재와 관리는 에이전트가 직접 수행하므로, 규칙 카탈로그를 읽어 계획을 새로 짜는 코드 단계를 따로 둘 필요가 없다. 작업 순서와 도메인 절차는 스킬로 구현한다. 검증과 승인 게이트처럼 반드시 지켜야 하는 제한은 도구로 구현하고, 메모리 조회처럼 대화 도중 필요한 작업도 도구로 처리한다. 엔티티 해석처럼 비용이 낮고 거의 항상 필요한 전처리나 페이로드 생성, 스트림 파싱, 추가 질문 재개 같은 기계적 처리만 도구가 호출하는 코드 내부에 남긴다.

서로 긴밀하게 연동되는 서브에이전트를 먼저 병합한다. 이어 서브에이전트를 도구로 호출해 기준 성능을 측정한 뒤, 프롬프트는 스킬로 전환하고 API 호출은 도구로 전환한다. 출처: Anthropic

멀티에이전트 시스템에서 단일 에이전트 루프로 전환할 때는 한 번에 전체를 바꾸기보다 네 단계를 거쳐 점진적으로 진행하는 편이 안전하다.

1단계: 과제 완수 평가(Task-completion evals) 마련

서브에이전트 통합 여부를 판단하려면 먼저 평가셋을 갖춰야 한다. 중앙 팀이 소유하는 엔드투엔드 공통 평가셋 하나와 각 팀이 자기 스킬과 함께 배포하는 소규모 평가셋을 결합한 구조가 효과적이며, 처음에는 골든 예제 10개만으로도 시작할 수 있다.

초기에는 루브릭(채점 기준표)을 바탕으로 에이전트의 최종 응답 품질을 채점한다. 오케스트레이터를 사용하는 동안에는 올바른 서브에이전트를 선택했는지도 확인해 라우팅 정확도를 함께 측정한다. 서브에이전트를 통합한 뒤에는 에이전트가 적절한 스킬을 불러왔는지, 올바른 도구를 호출했는지를 대신 확인한다. 사내 시스템을 재현하거나 사용자 상호작용을 시뮬레이션하기 까다로운 환경에서는 주요 이벤트에 타임스탬프를 기록해 두었다가 나중에 재생(replay)하여 표적 평가로 활용하는 방법이 유효하다.

2단계: 도메인 에이전트 병합

첫 번째 병합을 진행하기 전에 소규모 엔드투엔드 평가를 마련한 뒤, 사용 빈도가 가장 높은 서브에이전트부터 공유 컨텍스트를 기준으로 병합한다. 앞선 에이전트의 출력을 바로 처리하거나 동일한 데이터를 다루는 에이전트 쌍부터 병합한다. 실제 운영 중에 연속으로 함께 호출되는 비중이 높은 에이전트 쌍도 우선 병합 대상이다.

3단계: 서브에이전트를 도구로 호출

서브에이전트를 유지해야 하더라도 대화 전체를 제어하는 권한까지 위임하는 완전 핸드오프(full handoff)는 피하는 편이 좋다. 서브에이전트가 사용자와 직접 대화해야 하는 경우는 예외다. 그 밖의 상황에서는 메인 에이전트가 사용자와의 대화를 계속 유지하면서 서브에이전트를 도구 형태로 호출하게 만든다.

이렇게 구성하면 서브에이전트들의 공통 응답 스키마를 정의할 수 있고, 메인 에이전트가 실제 데이터와 대조해 결론을 검증하거나 최종 답변 합성 단계에 전달할 입력 분량을 줄일 수 있다. 기존 서브에이전트를 새로 작성할 필요가 없고, 본격적인 통합 전에 과제 완수 평가의 기준선(baseline)을 확보할 수 있다는 점도 장점이다.³

4단계: 스킬과 도구로 전환해 메인 루프에 통합

서브에이전트가 수행하던 기능을 한 번에 하나씩 메인 에이전트에 통합한다. 각 서브에이전트가 갖고 있던 프롬프트는 스킬로 전환하고 API 호출은 MCP 도구로 바꾼 뒤, 서브에이전트가 있을 때와 없을 때의 평가 성적을 비교해 유지 여부를 결정한다.

성적을 비교할 때는 총점만 보지 말고 성패가 뒤집힌 개별 과제(flipped tasks)를 반드시 확인해야 한다. 샘플 고객지원 에이전트에서 서브에이전트 하나를 통합해 본 실험에서는 전체 지연 시간이 줄어든 반면, 기존에 통과하던 과제가 실패로 돌아서는 문제가 발견됐다. 주문 조회 도구를 직접 호출하게 된 메인 에이전트가 배송 전문 에이전트에게 배송 예정일을 확인하는 절차를 건너뛰고 단독으로 답변했기 때문이다. 이 문제는 두 번 실행할 때 한 번꼴로만 드러났기 때문에, 실제 운영 환경에서 에이전트들이 연속으로 함께 수행하는 작업과 반드시 준수해야 하는 규칙마다 평가 과제를 만들고 각 과제를 여러 번 반복 실행해야 한다.

여러 팀이 단일 에이전트에 함께 기여하는 방법과 가속 도구

단일 에이전트 루프로 전환한 뒤에는 지식 베이스, 스킬, MCP 도구를 사용해 도메인 추론에 필요한 지식을 관리한다. 개별 에이전트 단위로 배정되어 있던 각 팀의 관리 책임은 스킬과 도구 단위로 재편되고, 소수의 중앙 팀이 시스템 프롬프트와 엔드투엔드 품질 관리 및 배포 전 검수를 맡는다.

특히 MCP 도구에서 선행 조건과 권한을 처리하는 방식이 실용적이다. 예를 들어 Y 작업에 X의 출력이 필요하다면 Y 도구가 이를 직접 확인하고 모델이 수행할 다음 행동을 안내문으로 반환한다. 각 도구는 호출자의 열람 권한과 실행 권한을 확인하고, 권한이 부족하면 모델이 읽을 수 있는 일반 텍스트로 거절 사유를 반환한다. 이렇게 하면 권한 등급마다 별도 에이전트를 구성할 필요 없이 단일 루프로 권한이 서로 다른 사용자들을 응대할 수 있다.

Anthropic은 이러한 마이그레이션 전 과정을 자동화할 수 있도록 Claude API 스킬 4종과 이를 하나의 워크플로우로 묶은 오픈소스 마이그레이션 키트(single-agent-loop-kit)를 함께 공개했다.

• /claude-api build-eval: 중앙 팀이 관리할 첫 엔드투엔드 평가셋이나 각 팀이 스킬에 포함해 배포할 소규모 평가셋 생성을 돕는다.
• /claude-api prompt-audit: 시스템 프롬프트, 스킬, 도구 설명을 점검해 구형 모델 시절에 추가되어 현재는 에이전트를 느리고 경직되게 만드는 지침을 찾아내고 diff 형태로 수정안을 제안한다.
• /claude-api hillclimb: 기존 평가셋을 기준으로 애플리케이션을 반복 개선한다. 서브에이전트를 스킬과 도구로 전환한 뒤 설명문을 반복 최적화하여 통합 버전이 기존 서브에이전트 성능을 달성하거나 능가하는지 검증할 때 유용하다.
• /claude-api cost-optimize: 호출 내역을 프로파일링하여 프롬프트 캐싱, 불필요한 입출력 토큰 절감, 추론 강도(effort) 조절, 모델 선택 등 비용과 지연 시간을 줄이는 방안을 한 번에 한 가지씩 제안한다.

가장 흥미로운 지점

이번 가이드는 멀티에이전트 아키텍처가 조직도를 복제하는 문제(콘웨이의 법칙)와 새 모델로 전환하는 시기가 늦어지는 문제를 연결해 진단한다. 많은 조직이 하위 과제를 팀별로 분담하려고 에이전트를 분리해 왔는데, 그렇게 구축한 다단계 파이프라인과 오케스트레이터는 구형 모델의 추론 한계를 보완하려는 목적이 컸다. Opus 5.5와 Fable 5.1처럼 모델 자체가 계획 수립과 중간 점검을 단일 루프에서 수행할 수 있게 된 시점에는, 과거에 세분화해 둔 하네스가 도리어 새 모델의 수행 범위를 제약한다는 진단이 설득력 있다.

또한 권한 분리나 선행 조건 강제를 별도 서브에이전트로 해결하는 대신 MCP 도구의 반환 메시지로 처리하라는 해법도 실무적이다. 도구가 권한 부족이나 선행 작업 누락을 일반 텍스트 안내로 돌려주면 모델이 같은 루프에서 즉시 대처할 수 있으므로, 아키텍처를 복잡하게 분리하지 않고도 통제력을 유지할 수 있다.

출처

• 저자 및 발표일: Diane Sarkis, Anthropic (2026-10-22)
• 원문: https://claude.com/ko/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop
• 삽화 안내: 치비 서소영 삽화 3장은 「느낌적인 느낌을 숫자로 옮기는 일」의 치비 서소영 라인아트를 참조해 gpt-image-2.5-flare로 따로 생성했다.