이 요약은 다중 서브에이전트를 사용하는 에이전트 시스템을 단일 메인 에이전트 루프로 통합하는 시기와 방법에 대한 지침을 제공합니다. 앤트로픽(Anthropic)은 최근 엔터프라이즈 환경에서 단일 에이전트 루프가 품질, 비용, 지연 시간 면에서 더 나은 성능을 보인다는 사실을 발견했습니다. 이 문서에서는 서브에이전트가 여전히 유용할 수 있는 상황과, 단일 에이전트 루프로 전환할 때 발생할 수 있는 이점, 그리고 여러 팀이 단일 에이전트에 효과적으로 기여할 수 있는 방법을 자세히 설명합니다.

1. 서브에이전트의 역할과 새로운 관점 👀

서브에이전트는 자체 컨텍스트 창, 도구, 지침을 가지고 코디네이터에 의해 조정되는 에이전트 설계의 핵심 요소였어요. 특히 검증, 병렬 작업, 모듈형 권한 부여에 효과적이죠. 앤트로픽에서도 멀티 에이전트 연구 시스템 등 다양한 에이전트에 서브에이전트를 활용해왔습니다.

하지만 최근 앤트로픽의 응용 AI 팀은 라우터, 플래너, 도메인 서브에이전트를 메인 에이전트 루프에 통합했을 때 엔터프라이즈 에이전트 배포에서 상당한 이점을 얻는 패턴을 발견했어요. 여러 엔터프라이즈 배포 사례를 비교해보니, "기술을 가진 단일 에이전트" 🧑‍💻 가 '모든 것을 위한 하나의 프롬프트' 설계나 '서브에이전트' 설계보다 품질 면에서 훨씬 뛰어나고, 종종 더 낮은 비용과 지연 시간으로 작업을 처리하는 경우가 많았다고 합니다.

예를 들어, 어떤 회사는 고객 대면 에이전트 내부에 수십 개의 전문 서브에이전트를 가지고 있었는데, 이로 인해 일관된 브랜드 경험을 유지하기 어려웠고, 사용자 경험을 해치는 지연 시간이 발생하기도 했어요. ⏱️

앤트로픽은 자주 보이는 에이전트 설계 패턴이 의도 분류기, 고정된 다단계 추론 파이프라인, 사용자 세그먼트 버킷, 별도의 추천 분기, 그리고 그 위에 멀티 에이전트 오케스트레이터가 있는 형태라는 것을 지적했습니다. 이런 경우, 종종 피드백은 "대부분의 구조가 모델이 더 이상 필요로 하지 않는 작업을 수행하고 있었다"는 것이었어요. 즉, 명확한 시스템 프롬프트, 4-5개의 간결한 데이터 도구, 그리고 확고한 출력 가드레일만으로도 대부분의 사용 사례를 커버할 수 있었다는 거죠.

그럼에도 불구하고 서브에이전트가 여전히 제 역할을 하는 경우도 분명히 있습니다. 특히 다음과 같은 상황에서는 서브에이전트를 사용하는 것이 적절해요:

• 단일 에이전트 루프가 컨텍스트 블로트(context bloat) 로 인해 측정 가능한 성능 저하를 겪을 때. 📉
• 여러 작업을 병렬로 처리해야 하며, 작업이 완료되면 폐기할 수 있는 새로운 컨텍스트 창이 필요할 때.
• 단일 에이전트가 적절한 도구를 선택하는 데 어려움을 겪거나 시스템 프롬프트에 충돌하는 지침이 있을 때.

하지만 앤트로픽은 종종 기업들이 각 팀이나 문제 유형에 자체 서브에이전트를 할당하여 에이전트 아키텍처가 조직도(Conway's law)를 그대로 모방하는 경향이 있다는 것을 발견했어요. 이 글은 서브에이전트를 메인 에이전트 루프에 통합하는 시점과 그에 대한 모범 사례를 설명하는 것을 목표로 합니다.

2. 대규모 조직의 에이전트 구축 실패 사례 🚨

기업들은 종종 여러 제품과 기능을 하나의 고객 인터페이스로 통합하는 에이전트를 구축하려 합니다. 일반적으로 각 기능은 별도의 팀에서 소유하므로, 기업들은 각 팀이 자체 에이전트를 구축하게 한 다음, 중앙 플랫폼 팀이 그 위에 오케스트레이터를 구축하는 방식으로 시작해요. 이는 오케스트레이터-서브에이전트 구조나 특정 에이전트가 MCP 도구로 노출된 단일 에이전트 등 다양한 구조를 가질 수 있습니다.

이러한 방식은 가장 간단한 해결책처럼 보이지만, 다음과 같은 즉각적인 복잡성을 야기합니다.

• 컨텍스트 관리: 에이전트 간에 어떤 컨텍스트를 교환할지 결정해야 하는데, 이 과정에서 세부 정보가 손실되는 경우가 많아요.
• 서브에이전트 확산: 모든 팀이 자체 서브에이전트를 출시하면서 수백 개의 중복되는 서브에이전트가 생겨나고, 표준도 없고 특정 소유자도 없어집니다.
• 프랑켄프롬프트(Frankenprompt): 모든 팀이 시스템 프롬프트에 한 문장씩 추가하다 보니, 상충하는 규칙들이 생겨나고 일관된 목소리가 사라져요.
• 검증되지 않고 지나치게 지역화된 평가: 각자 자신의 하위 작업에 지나치게 최적화된 평가를 추가합니다. 아무도 전체 평가 세트를 소유하거나 유지 관리하지 않아, 리더십은 희석되고 지나치게 지역화된 점수를 바탕으로 결정을 내리게 됩니다.
• 지연 시간: 멀티 에이전트 아키텍처의 복잡성은 지연 시간을 증가시킵니다. 실제로 한 고객은 멀티 에이전트 시스템과 단일 에이전트 루프를 비교했을 때, 후자가 약 2배 더 빠른 실행 시간을 보였다고 해요.

3. 점진적 공개를 통한 에이전트 루프 활용 🔍

위에서 설명한 오케스트레이터-서브에이전트 설계는 팀 간에 구축된 전문가를 조정하는 합리적인 접근 방식이지만, 종종 더 효과적인 접근 방식은 기술을 통한 컨텍스트의 점진적 공개와 도구 검색을 통한 도구의 점진적 공개입니다. 다시 말해, 에이전트는 기술과 도구에 대한 간략한 설명을 보고, 필요할 때만 완전히 로드하는 방식이죠.

이 접근 방식이 합리적인 세 가지 이유는 다음과 같습니다.

1. 공유된 컨텍스트가 더 나은 답변을 생성: 🤝 장기 실행 에이전트의 경우, 여러 다른 작업의 컨텍스트가 메인 컨텍스트 창에 있어야 합니다. 각 이전 단계의 결과를 본 에이전트는 이를 연결하여, 서브에이전트가 제공하는 요약보다 더 풍부한 출력과 더 나은 통찰력을 얻을 수 있어요. 이는 또한 컨텍스트 창 수를 줄이고 정보 손실이 적은 핸드오프를 의미합니다.
2. 점진적 공개가 컨텍스트 블로트 방지: 이 기술은 팀이 모든 컨텍스트를 하나의 긴 시스템 프롬프트에 즉시 로드할 필요 없이, 광범위한 작업을 수행할 수 있는 단일 에이전트를 구축할 수 있게 해줍니다. 이는 이전에 팀들이 작업을 서브에이전트 간에 분할했던 주된 이유를 제거하죠. 실제로 앤트로픽은 Claude Code의 시스템 프롬프트를 고급 모델의 경우 80% 이상 줄였는데, 이는 기술과 도구의 점진적 공개와 관련된 부분도 포함된 결과입니다.
3. 모델의 능력 향상: 🚀 Opus 4.5부터 모델들은 대부분의 팀이 예상했던 것보다 훨씬 더 많은 것을 단일 루프 내에서 관리할 수 있게 되었습니다. Opus 5.5, Fable 5.1과 같은 최신 모델들은 진행 상황을 설명하고 스스로 작업을 확인하는 능력이 향상되어, 일부 하네스 요소가 불필요해졌어요. 각 새로운 모델은 의사 결정의 상당 부분을 하네스에서 모델 자체로 옮길 수 있게 해주며, 더 간단한 루프는 다음 모델로의 전환을 더 쉽게 만듭니다.

단일 에이전트 루프 설계는 규율을 요구합니다. 즉, 신중하게 관리되는 시스템 프롬프트, 적절한 시기에 트리거되는 기술 및 도구 설명, 그리고 컨텍스트 창, 메모리, 노트 작성의 신중한 처리가 필요하죠.

앤트로픽은 하나의 중앙 팀이 종단 간 품질과 시스템 프롬프트를 소유하고, 모든 새로운 도구와 평가를 출시 전에 검토해야 한다고 조언합니다. 이 중앙 팀을 작게 유지하면 반복 작업이 빠르게 진행되고, 대규모 조직 내에서 조정 비용을 낮출 수 있어요.

만약 멀티 에이전트 경로를 선택한다면, 가장 간단한 패턴(생성기-검증기, 오케스트레이터-서브에이전트 등)으로 시작해야 합니다. 컨텍스트별로 분할하여 경계를 효과적으로 분해해야 해요. 즉, 각 서브에이전트에 시스템의 나머지 부분에서 거의 필요하지 않은 작업을 할당하고, 간결한 결과를 반환하도록 해야 합니다. (독립적인 연구 경로, 깔끔한 인터페이스를 가진 별도의 구성 요소, 또는 블랙박스 검증 등이 좋은 후보입니다.) 에이전트가 문제 유형별로 분할되면, "전화 게임"처럼 정보를 주고받으며 각 핸드오프에서 충실도가 저하될 수 있어요. 😥

4. 서브에이전트를 메인 에이전트 루프에 통합하는 방법 🔄

많은 팀이 이미 오케스트레이터와 전문 에이전트 세트를 운영하고 있을 텐데요. 앤트로픽이 제안하는 단일 루프 설계로 나아가기 위한 방법은 다음과 같습니다.

• 제한(턴 및 비용 예산, 쓰기 게이트)이 하네스에 설정된 개방형 도구 루프를 실행하는 하나의 모델과 하나의 컨텍스트 창 🧠
• 매 턴마다 모델은 일련의 도구 호출을 내보냅니다. 하네스는 이를 병렬로 실행하고 원시 결과를 동일한 모델에 반환하며, 모델은 다음 단계(또 다른 도구 호출, 사용자에게 질문, 또는 답변)를 결정합니다.
• 루프는 모델이 답변하거나 예산에 도달하면 멈춥니다. 답변 후에는 목표 또는 검증기 확인이 선택적으로 실행될 수 있습니다.
• 모델은 첫 턴에 컨텍스트 내에서 계획을 작성하고 결과가 도착하면 이를 수정합니다. 이것이 오케스트레이터 및 전문 에이전트 설정과의 주요 차이점인데요, 계획을 작성하는 모델이 이를 실행하는 모델이므로 중간에 계획을 변경할 수 있다는 점입니다.
• 컨텍스트는 여전히 로드되고 에이전트 자체에 의해 관리됩니다.
  • 모델이 각 단계를 결정하므로 규칙 카탈로그에서 계획을 다시 작성하는 코드 단계는 더 이상 필요 없어요.
  • 순서 지정 및 도메인 절차는 기술(skills) 로 이동합니다.
  • 하드 제한(유효성 검사, 승인 게이트) 및 대화 중에 발생하는 기타 사항(예: 메모리 조회)은 도구(tools) 로 이동합니다.
  • 코드는 여전히 저렴하고 거의 항상 관련 있는 것(예: 엔티티 해결 단계)을 로드하고, 루프가 호출하는 도구 내에서 기계적인 부분(페이로드 구성, 스트림 파싱, 명확화 재개)을 처리하는 데 사용될 수 있습니다.

이 단일 루프 설계는 에이전트가 사용자의 상위 수준 목표를 이해하고 사용자를 대신하여 행동하는 미래 지향적인 목표에도 도움이 됩니다. 에이전트가 학습한 모든 것을 하나의 컨텍스트에 유지하기 때문이죠.

다음은 멀티 에이전트 시스템에서 단일 에이전트 루프로 단계적으로 전환하고, 여러 팀이 이 에이전트에 계속 기여할 수 있는 방법을 제시합니다.

4.1. 작업 완료 평가 (Task-completion evals) ✅

첫 번째 단계는 서브에이전트를 메인 에이전트 루프에 통합해야 할지 결정하는 데 도움이 되는 평가 세트(eval set) 를 만드는 것입니다. 앤트로픽이 효과적이라고 본 평가 구조는 중앙 팀이 소유하는 공유된 종단 간 세트와, 각 팀이 자신의 기술과 함께 제공하는 더 작은 평가 세트예요. 단 10개의 골든 예제만 있어도 시작하기에 충분합니다.

에이전트의 최종 메시지를 루브릭에 따라 평가하는 것은 답변 품질을 추적하는 좋은 출발점입니다. 오케스트레이터가 여전히 있는 동안에는 라우팅 정확도(올바른 서브에이전트를 선택했는지)도 추적해야 합니다. 서브에이전트가 통합된 후에는 에이전트가 올바른 기술을 로드했는지 또는 올바른 도구를 호출했는지 확인해야 해요. 시간이 지남에 따라 작업 완료 평가로 나아가는 것이 유용합니다. 이는 아키텍처를 비교할 때 가장 중요한 부분이기 때문입니다.

내부 시스템을 재현하기 어렵고 사용자 참여를 시뮬레이션하기 어려운 환경에서는 이 과정이 복잡할 수 있어요. 앤트로픽 내부에서 효과적이었던 한 가지 접근 방식은 중요한 이벤트에 타임스탬프를 기록하여 나중에 재생하여 대상화된 평가를 실행할 수 있도록 하는 것이었습니다.

4.2. 서브에이전트 점진적으로 줄이기 📉

단일 에이전트 루프로 진화하려면 서브에이전트를 도구와 기술로 통합해야 합니다. 이는 도메인 서브에이전트를 병합하거나, 이를 도구로 호출하거나, 기술과 도구로 대체함으로써 수행할 수 있습니다.

4.3. 도메인 에이전트 결합 융합 (Combining domain agents) 🤝

첫 번째 병합 전에 작은 종단 간 평가를 구축하세요. 그런 다음 가장 많이 사용되는 서브에이전트부터 공유된 컨텍스트별로 통합합니다.

서로의 출력에 연결되거나, 동일한 데이터에 접근하거나, 자주 함께 호출되는 전문가들을 병합하세요. 예를 들어, 생산 트래픽의 상당 부분이 한 전문가 다음에 두 번째 전문가가 호출되는 경우, 이는 긴밀하게 연결된 쌍이므로 하나의 도메인 에이전트로 병합될 후보가 됩니다.

4.4. 도구로 호출되는 서브에이전트 (Subagents called as tools) 🛠️

위의 세 가지 조건 중 하나가 적용되고 서브에이전트를 유지하는 경우, 메인 에이전트가 서브에이전트를 도구로 호출하도록 하는 것이 효과적일 수 있습니다. 이렇게 하면 메인 에이전트가 사용자와의 대화를 계속 진행할 수 있어요.

서브에이전트가 사용자와 직접 대화해야 할 때만 대화의 완전한 인계를 권장합니다. 그 외의 모든 것은 메인 루프 내의 기술과 도구로 처리할 수 있습니다.

이러면 서브에이전트에 대한 공유 응답 스키마를 정의하고, 메인 에이전트로 실제 데이터에 대해 결론을 검증하고, 최종 합성 단계로의 입력을 다듬을 수 있습니다. 이것은 좋은 첫걸음입니다. 서브에이전트를 다시 작성할 필요가 없기 때문이죠. 또한, 서브에이전트를 메인 에이전트에 통합할지 결정하기 전에 작업 완료 평가에 대한 기준선을 제공합니다.

그러나 여전히 몇 가지 실패 모드가 남아있을 수 있습니다.

• 각 전문가는 자체 프롬프트, 컨텍스트, 소유자 팀, 평가를 가집니다.
• 모든 호출은 여전히 손실이 있는 요약을 반환합니다.
• 모든 호출은 지연 시간을 추가하는 중첩된 모델 루프입니다.

4.5. 서브에이전트를 기술 및 도구를 통해 메인 에이전트로 통합 (Folding subagents into the main agent via skills and tools) 🧠

각 서브에이전트의 프롬프트를 기술로, API 호출을 MCP 도구로 변경하여 서브에이전트를 한 번에 하나씩 메인 에이전트로 통합하세요. 서브에이전트가 있을 때와 없을 때의 평가 성능을 비교하고, 어떤 것을 유지할지 결정합니다.

비교할 때 최종 점수만 보지 말고, 어떤 작업이 바뀌었는지 살펴보세요. 앤트로픽이 샘플 지원 에이전트에서 테스트했을 때, 하나의 서브에이전트를 다른 서브에이전트로 통합하니 지연 시간은 줄었지만, 이전에 성공적으로 처리되던 프로세스가 고장 났습니다. 메인 에이전트가 주문 조회 도구를 가지고 스스로 답변하고, 배송 전문가에게 배송일을 묻지 않았기 때문이죠.

각 변경 전에, 여러분의 평가 세트가 운영 환경에서 함께 실행되는 모든 에이전트 체인에 대한 작업과 에이전트가 위반해서는 안 되는 모든 규칙에 대한 작업을 포함하는지 확인하고, 각 작업을 두 번 이상 실행하세요. 이러한 종류의 오류는 두 번의 실행 중 한 번만 나타나는 경우가 있기 때문입니다.

5. 여러 팀이 단일 에이전트에 기여하는 방법 🤝

도메인 추론은 지식 기반, 기술 및 MCP 도구에서 가져올 수 있습니다. 개별 팀은 에이전트 소유권에서 기술 및 도구 소유권으로 전환할 수 있으며, 소규모 중앙 팀은 시스템 프롬프트 및 종단 간 품질에 대한 소유권을 유지할 수 있습니다. 여기에는 새로운 기술, 도구 및 평가를 출시하기 전에 검토하는 작업이 포함됩니다.

5.1. MCP 도구 (MCP tools) 🛠️

도구는 에이전트가 작업을 수행하거나, 시스템에서 실시간 데이터를 읽거나, 고정된 형식으로 결과를 반환해야 할 때 적합합니다. 마이그레이션하는 동안 서브에이전트를 계속 호출하는 방법으로도 도구를 사용할 수 있어요. 앤트로픽은 사용자 의도별로 그룹화된 도구(API당 하나의 도구가 아님)를 권장합니다. 시스템 프롬프트에 30-50개 이상의 도구 정의가 있으면 도구 선택 능력이 저하되는 경향이 있기 때문입니다.

지연 로딩이 있는 도구 검색을 사용하고, 엄격한 사전 조건을 제한하며, 필요한 모든 것을 도구 안으로 이동시키세요. 예를 들어, Y가 X의 출력을 필요로 한다면, Y의 도구가 이를 확인하고 모델이 행동할 수 있는 지침을 반환합니다. 사용자별 권한도 동일하게 작동합니다. 각 도구는 호출하는 사용자가 무엇을 보거나 할 수 있는지 확인하고, 모델이 읽을 수 있는 간단한 거부 메시지를 반환하므로, 하나의 루프는 권한 수준별로 별도의 에이전트 없이도 다른 액세스 권한을 가진 사용자에게 서비스를 제공할 수 있습니다.

5.2. 기술 (Skills) ✨

기술은 에이전트가 팀이 어떻게 작업하는지 알아야 할 때, 즉 전문 서브에이전트의 프롬프트가 이전에 포함했던 단계, 규칙 및 판단과 같은 내용을 알아야 할 때 적합합니다.

기술 라이브러리를 성장시키는 앤트로픽의 접근 방식은 유지 보수 작업을 기술을 작성하는 사람들에게 다시 돌려주는 것입니다. Claude는 다른 기술을 구축하고, 테스트하고, 가지치기할 수 있는 기술을 통해 이 어려운 작업을 수행할 수 있습니다.

기술 확산을 방지하려면 각 팀의 DRI(Directly Responsible Individual)가 자신의 기술을 소유하고, 잘 만들어지고, 독특하며, 적절한 평가와 함께 출시되도록 할 수 있습니다.

• /skill-creator는 잘 구성된 새로운 기술을 작성하고, 기존 기술을 감사하여 다듬고, 중복을 제거하고, 재구성할 수 있도록 돕습니다.
• /skill-doctor는 라이브러리의 각 기술이 얼마나 비용이 들고 얼마나 자주 실제로 사용되는지 확인하고, 불필요한 부분을 삭제할 수 있도록 해줍니다.

5.3. 지식 기반 (Knowledge bases) 📚

지식 기반은 에이전트가 때때로만 필요로 하는 참조 자료에 적합합니다. 사실 및 참조 자료(정책, 측정 지표 정의, 제품 사양)는 모델이 호출하는 검색 또는 조회 도구 뒤에 있거나, 기술 내에 참조 파일로 포함될 수 있습니다. 코드가 이 컨텍스트를 검색하여 프롬프트에 붙여넣는 것을 피하세요.

6. 작업 가속화를 위한 도구들 🚀

앤트로픽은 최근 위에서 언급된 대부분의 작업을 돕는 Claude API 기술 세트를 출시했어요. 앤트로픽의 마이그레이션 키트는 이러한 기술들을 하나의 안내된 워크플로우로 연결하여 멀티 에이전트 시스템을 단일 에이전트 루프로 평가하고 이동시킬 수 있도록 도와줍니다. 실제 적용 전에 시도해볼 수 있는 데모도 포함되어 있어요.

• /claude-api build-eval: 중앙 팀이 소유하는 첫 번째 종단 간 세트를 만들거나, 각 팀이 자신의 기술과 함께 제공하는 작은 평가 세트를 만드는 데 도움을 줄 수 있습니다.
• /claude-api prompt-audit: 프롬프트, 기술 및 도구 설명에서 이전 모델용으로 작성된 지침을 식별하고, diff 형식으로 수정 사항을 제안할 수 있습니다. 이는 시스템 프롬프트에서 이전 모델을 위해 추가되었지만 이제 에이전트를 느리거나 더 경직되게 만드는 규칙을 찾는 데 사용할 수 있어요. 각 팀의 DRI는 자신의 기술 및 도구 설명에도 이를 실행할 수 있습니다.
• /claude-api hillclimb: 기존 평가에 대해 앱을 반복적으로 개선할 수 있습니다. 이는 "통합 대 유지" 비교(하나의 서브에이전트를 기술과 도구로 통합한 후, 기술과 도구 설명을 반복하고 통합 버전이 서브에이전트와 일치하거나 더 나은지 확인)뿐만 아니라 시스템 프롬프트에도 사용할 수 있습니다.
• /claude-api cost-optimize: 호출이 어디로 가는지 프로파일링하고, 프롬프트 캐싱, 불필요한 입력 및 출력 토큰 다듬기, 노력, 모델 선택과 같은 옵션에서 절약할 수 있는 방법을 한 번에 하나씩 제안합니다. 이는 주어진 설계에서 비용과 지연 시간을 낮추는 데 도움이 될 수 있습니다.

모델이 발전함에 따라, 이를 가장 잘 사용하는 방법과 모범 사례에 대한 이해도 함께 진화합니다. 이는 어떤 단일 아키텍처보다 그 뒤에 있는 원칙, 즉 측정하고, 한 번에 한 가지씩 변경하고, 유지할 가치가 있는 것을 유지하는 것이 더 중요하다는 것을 의미해요.

이것이 바로 그런 경우입니다. 모델이 더 유능해지고 에이전트가 더 오래 실행될수록, 더 많은 서브에이전트가 기술과 도구가 될 수 있습니다. 하지만 이 변화를 한 번에 다 할 필요는 없어요. 작은 종단 간 평가를 구축하고, 하나의 서브에이전트를 통합한 다음, 통합된 버전의 점수가 더 나쁘다면 서브에이전트를 유지하고, 이 과정을 반복하면 됩니다. 😊