에이전트 만들기: 서브에이전트를 메인 에이전트 루프에 통합해야 할 때

Claude Platform에서 서브에이전트가 여러 개 포함된 에이전트를 만들었다면, 마이그레이션 키트로 어떤 서브에이전트를 메인 에이전트 루프에 통합하면 좋을지 확인해 보세요. 이 키트는 안내형 워크플로를 통해 현재 사용 중인 패턴을 파악하고, 대안을 평가하고, 가장 적합한 방식을 검증합니다. 실제 에이전트에 적용하기 전에 모의 시스템으로 먼저 체험해 볼 수 있는 데모도 들어 있습니다.

서브에이전트는 독자적인 컨텍스트 윈도우, 도구, 지침을 갖추고 코디네이터의 조율을 받아 동작하는 에이전트로, 에이전트 설계의 핵심 구성 요소입니다. 검증, 병렬 작업, 모듈식 권한 관리에 효과적이며, Anthropic도 Claude Platform으로 만드는 여러 에이전트에 서브에이전트를 활용하고 있습니다. 멀티 에이전트 리서치 시스템이 대표적인 예입니다.

그런데 최근 Applied AI 팀은 기업용 에이전트 배포 사례 가운데 라우터, 플래너, 도메인 서브에이전트를 메인 에이전트 루프에 통합해 효과를 본 패턴이 있음을 발견했습니다. 여러 기업 배포 사례를 비교해 보니, 스킬을 갖춘 단일 에이전트가 "모든 것을 프롬프트 하나에 넣는 설계"와 서브에이전트 설계 모두보다 품질이 높은 경우가 많았고, 작업당 비용과 지연 시간도 더 낮은 경우가 많았습니다.

예를 들어 한 기업은 고객 응대 에이전트 안에 전문 서브에이전트가 십수 개 있었는데, 그 탓에 브랜드에 맞는 일관된 경험을 유지하기 어려웠고 지연 시간까지 늘어 사용자 경험이 나빠졌다고 합니다.

또 에이전트 설계안이 흔히 비슷한 순서로 복잡해지는 모습도 자주 봅니다. 의도 분류기에서 시작해 고정된 다단계 추론 파이프라인, 사용자 세그먼트별 분기, 별도의 추천 분기를 거쳐, 맨 위에 멀티 에이전트 오케스트레이터까지 올라가는 식입니다.

이런 경우 피드백은 대개 이 구조의 상당 부분이 이제 모델에게 굳이 대신 해 줄 필요가 없는 일을 하고 있었다는 것입니다. 명확한 시스템 프롬프트 하나, 얇은 데이터 도구 4~5개, 확실한 출력 가드레일이면 대부분의 사용 사례를 충분히 처리할 수 있습니다.

물론 서브에이전트가 여전히 필요한 경우도 있고, 연구 최전선에서도 마찬가지입니다. 다음과 같은 경우에 사용하세요.

• 단일 에이전트 루프에서 컨텍스트 비대화로 인해 성능 저하가 측정될 때
• 작업이 끝나면 폐기할 수 있는 새 컨텍스트 윈도우에서 여러 작업을 병렬로 처리해야 할 때
• 단일 에이전트가 적절한 도구를 고르지 못하거나 시스템 프롬프트에 서로 충돌하는 지침이 있을 때

그런데 기업에서는 팀이나 문제 유형마다 서브에이전트를 하나씩 두어, 에이전트 아키텍처가 조직도를 그대로 닮아 가는 경우가 너무 많습니다(콘웨이의 법칙이 그대로 작동하는 셈입니다).

이 글에서는 대규모 조직에서 에이전트를 만들며 얻은 모범 사례를 바탕으로, 서브에이전트를 메인 에이전트 루프에 통합할 만한 때가 언제인지 설명합니다.

대규모 조직에서 에이전트를 만들 때 흔히 겪는 실패 유형

기업은 여러 제품과 기능을 하나의 고객 인터페이스로 묶는 에이전트를 만들고 싶어 하는 경우가 많습니다.

보통 기능마다 담당 팀이 따로 있어서, 먼저 각 팀이 자기 에이전트를 만들고 이후 중앙 플랫폼 팀이 그 위에 오케스트레이터를 만드는 식으로 시작합니다. 구조는 오케스트레이터-서브에이전트 방식일 수도 있고, 특정 에이전트를 MCP 도구로 노출한 단일 에이전트일 수도 있습니다.

가장 단순한 해법처럼 보이지만, 곧바로 다음과 같은 복잡성이 생깁니다.

• 컨텍스트 관리: 에이전트끼리 어떤 컨텍스트를 주고받을지 정해야 하고, 오가는 과정에서 세부 정보가 유실되기도 합니다.
• 서브에이전트 난립: 팀마다 자기 서브에이전트를 내놓다 보니, 표준도 담당자도 없이 서로 겹치는 서브에이전트가 수백 개로 불어납니다.
• 프랑켄프롬프트: 팀마다 시스템 프롬프트에 문장을 하나씩 추가하면서 규칙이 서로 충돌하고, 일관된 어조도 사라집니다.
• 검증되지 않은 지나치게 국소적인 평가: 각자 자기 하위 작업에만 과도하게 최적화된 평가를 추가합니다. 전체 평가 세트를 책임지고 관리하는 사람은 없고, 경영진은 희석되고 지나치게 국소적인 점수를 보고 의사 결정을 하게 됩니다.
• 지연 시간: 멀티 에이전트 아키텍처는 복잡한 만큼 지연 시간이 늘어납니다. 멀티 에이전트 하네스를 단일 에이전트 루프와 비교 평가한 한 고객사는 단일 에이전트 루프의 실행 속도가 약 2배 빠른 것을 확인했습니다.

점진적 공개를 활용한 에이전트 루프

앞서 설명한 오케스트레이터-서브에이전트 설계는 여러 팀이 만든 전문 에이전트를 조율하는 합리적인 방법이지만, 스킬로 컨텍스트를 점진적으로 공개하고 도구 검색으로 도구를 점진적으로 공개하는 방식이 더 효과적일 때가 많습니다. 쉽게 말해, 에이전트는 스킬과 도구의 짧은 설명만 보고 있다가 필요할 때 전체 내용을 불러옵니다.

이 방식이 타당한 이유는 세 가지입니다.

• 공유 컨텍스트가 더 나은 답을 만듭니다: 장시간 실행되는 에이전트라면 여러 작업의 컨텍스트가 메인 컨텍스트 윈도우에 함께 있는 편이 좋습니다. 앞선 단계의 결과를 모두 본 에이전트는 그 결과를 서로 연결할 수 있어서, 서브에이전트가 돌려주는 요약 모음보다 풍부한 결과물과 통찰을 내놓습니다. 컨텍스트 윈도우 수가 줄고 정보가 손실되는 인계도 줄어든다는 장점도 있습니다.
• 점진적 공개는 컨텍스트 비대화를 막습니다: 이 기법을 쓰면 모든 컨텍스트를 긴 시스템 프롬프트 하나에 처음부터 올려 두지 않고도 다양한 작업을 해내는 단일 에이전트를 만들 수 있습니다. 팀들이 예전에 서브에이전트로 작업을 나누던 가장 큰 이유가 사라지는 셈입니다. 실제로 Anthropic은 더 고급 모델용 Claude Code의 시스템 프롬프트를 80% 넘게 줄였는데, 여기에는 스킬과 도구를 점진적으로 공개하도록 바꾸면서 덜어 낸 부분도 포함됩니다.
• 모델의 역량이 높아졌습니다: Opus 4.5부터 모델은 대부분의 팀이 예상한 것보다 훨씬 많은 일을 하나의 루프에서 관리할 수 있게 되었습니다. Opus 5.5와 Fable 5.1에서는 thinking을 끌 수 없고, 최근 모델들은 진행 상황을 스스로 설명하고 작업하면서 결과를 점검하는 경향이 갈수록 강해져 일부 하네스 요소가 불필요해졌습니다. 새 모델이 나올 때마다 의사 결정의 더 많은 부분을 하네스에서 모델 자체로 옮길 수 있습니다. 루프가 단순하면 다음 모델로 옮겨 가기도 쉽습니다. 고객의 마이그레이션을 도운 경험상, 새 모델이 더 많은 일을 맡지 못하게 막는 것은 경직된 멀티 에이전트 구조인 경우가 많았습니다.

단일 에이전트 루프 설계에는 규율이 필요합니다. 시스템 프롬프트를 세심하게 관리하고, 적절한 때에 발동하는 스킬·도구 설명을 작성하고, 컨텍스트 윈도우와 메모리, 노트 작성 방식을 의도적으로 다뤄야 합니다. 마이그레이션과 설계 시 고려할 점은 이어지는 섹션에서 더 자세히 다룹니다.

중앙 팀 하나가 엔드투엔드 품질과 시스템 프롬프트를 책임지고, 새 도구와 평가가 출시되기 전에 모두 검증해야 합니다. 중앙 팀을 작게 유지하면 개선 속도가 빨라지고 대규모 조직에서 드는 조율 비용도 줄어듭니다.

멀티 에이전트 방식을 택한다면, 동작할 만한 가장 단순한 패턴(생성기-검증기, 오케스트레이터-서브에이전트 등)에서 시작하세요. 경계를 나눌 때는 컨텍스트를 기준으로 나누는 것이 좋습니다. 나머지 시스템에서 필요로 하는 정보가 적은 작업을 각 서브에이전트에 맡기고, 결과는 간결하게 돌려받습니다. 독립적인 리서치 경로, 인터페이스가 깔끔한 별도 컴포넌트, 블랙박스 검증이 좋은 후보입니다. 문제 유형별로 에이전트를 나누면 "전달 게임"에 빠져, 정보를 주고받을 때마다 정확도가 떨어집니다.

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

이미 많은 팀이 프로덕션에서 오케스트레이터와 전문 에이전트 여러 개를 운영하고 있습니다. 다음은 목표로 삼을 만한 단일 루프 설계입니다.

• 모델 하나와 컨텍스트 윈도우 하나가 개방형 도구 루프를 실행하고, 제한(턴 및 비용 예산, 쓰기 게이트)은 하네스에서 설정합니다.
• 모델은 매 턴 도구 호출을 한 묶음으로 내보냅니다. 하네스는 이를 병렬로 실행해 원시 결과를 같은 모델에 돌려주고, 모델은 다음 단계를 결정합니다. 다른 도구 호출 묶음이 될 수도, 사용자에게 던지는 질문이 될 수도, 최종 답변이 될 수도 있습니다.
• 루프는 모델이 답변하거나 예산에 도달하면 멈춥니다. 답변 뒤에 목표 또는 검증기 확인을 선택적으로 실행할 수도 있습니다.
• 모델은 첫 턴에 컨텍스트 안에 계획을 작성하고, 결과가 들어오는 대로 계획을 수정합니다. 오케스트레이터와 전문 에이전트 구성에서 가장 크게 달라지는 부분이 바로 이것입니다. 계획을 세우는 모델이 직접 실행도 하므로, 턴 도중에 계획을 바꿀 수 있습니다.
• 컨텍스트는 여전히 로드되며, 에이전트가 스스로 관리합니다.
  • 모델이 매 단계를 결정하므로, 규칙 목록을 바탕으로 계획을 다시 쓰는 코드 단계는 더 이상 필요하지 않습니다.
  • 작업 순서와 도메인 절차는 스킬로 옮깁니다.
  • 엄격한 제한(검증, 승인 게이트)과 대화 도중에 필요해지는 그 밖의 기능(예: 메모리 조회)은 도구로 옮깁니다.
  • 코드는 비용이 적게 들고 거의 항상 관련 있는 정보(예: 엔티티 해석 단계)를 로드하는 데, 그리고 루프가 호출하는 도구 안에서 기계적인 부분(페이로드 구성, 스트림 파싱, 확인 질문 이후 재개)을 처리하는 데 여전히 쓸 수 있습니다.

이런 단일 루프 설계는 많은 팀이 지향하는 최종 형태, 즉 사용자의 상위 목표를 이해하고 사용자를 대신해 행동하는 에이전트에도 도움이 됩니다. 에이전트가 학습한 모든 내용이 하나의 컨텍스트에 남기 때문입니다.

아래 제안은 팀이 멀티 에이전트 시스템에서 단일 에이전트 루프로 단계적으로 넘어가는 방법과, 그 과정에서 여러 팀이 계속 에이전트에 기여하는 방법을 다룹니다.

작업 완료 평가

첫 단계는 서브에이전트를 메인 에이전트 루프에 통합할지 판단하는 데 도움이 되는 평가 세트를 만드는 것입니다. 효과를 본 평가 구조는 중앙 팀이 관리하는 엔드투엔드 평가 세트 하나에, 각 스킬을 맡은 팀이 스킬과 함께 내놓는 더 작은 평가 세트를 더한 형태입니다. 골든 예시 10개만 있어도 시작하기에 충분합니다.

답변 품질을 추적하는 출발점으로는 에이전트의 최종 메시지를 루브릭으로 채점하는 방법이 좋습니다. 오케스트레이터가 남아 있는 동안에는 라우팅 정확도(올바른 서브에이전트를 골랐는가?)도 함께 추적해야 합니다. 서브에이전트를 통합한 뒤에는 에이전트가 올바른 스킬을 로드했는지, 올바른 도구를 호출했는지를 대신 확인합니다. 아키텍처를 비교할 때는 작업 완료 평가가 가장 중요하므로, 시간을 두고 그쪽으로 나아가는 것이 좋습니다.

사내 시스템을 재현하기 어렵고 사용자 참여를 시뮬레이션하기 어려운 환경에서는 이 과정이 복잡할 수 있습니다. Anthropic 내부에서 효과를 본 방법은 중요한 이벤트에 타임스탬프를 기록해 두었다가, 나중에 재생해 목적에 맞는 평가로 실행하는 것입니다.

서브에이전트를 점차 줄여 나가기

단일 에이전트 루프로 발전해 간다는 것은 서브에이전트를 도구와 스킬로 통합한다는 뜻입니다. 도메인 서브에이전트를 합치거나, 도구로 호출하거나, 스킬과 도구로 대체하는 방식으로 진행할 수 있습니다.

도메인 에이전트 합치기

첫 번째 통합에 앞서 작은 엔드투엔드 평가를 만드세요. 그런 다음 사용량이 가장 많은 서브에이전트부터 공유 컨텍스트를 기준으로 통합합니다.

서로의 출력을 이어받거나, 같은 데이터를 다루거나, 함께 호출되는 일이 잦은 전문 에이전트는 합치세요. 예를 들어 프로덕션 트래픽의 상당 부분이 한 전문 에이전트 다음에 다른 전문 에이전트가 이어지는 흐름이라면, 두 에이전트는 긴밀하게 결합된 쌍이므로 하나의 도메인 에이전트로 합칠 후보가 됩니다.

서브에이전트를 도구로 호출하기

위의 세 가지 조건 중 하나에 해당해 서브에이전트를 유지하기로 했다면, 메인 에이전트가 서브에이전트를 도구로 호출하게 하는 것이 효과적일 수 있습니다. 그러면 메인 에이전트가 사용자와의 대화를 계속 이어 갈 수 있습니다.

서브에이전트가 대화를 넘겨받는 완전한 인계는 사용자와 직접 이야기해야 할 때만 권장합니다. 그 밖의 경우는 메인 루프 안의 스킬과 도구로 처리할 수 있습니다.

이렇게 하면 서브에이전트가 공유하는 응답 스키마를 정의하고, 메인 에이전트가 실제 데이터로 결론을 검증하고, 최종 종합 단계에 들어가는 입력을 줄일 수 있습니다. 서브에이전트를 다시 작성할 필요가 없어서 첫 단계로 좋습니다. 또 서브에이전트를 메인 에이전트에 통합할지 결정하기 전에 작업 완료 평가의 기준선도 확보할 수 있습니다.

다만 일부 실패 유형은 그대로 남습니다.

• 전문 에이전트마다 고유한 프롬프트, 컨텍스트, 담당 팀, 평가가 있습니다
• 호출할 때마다 여전히 정보가 손실된 요약이 돌아옵니다
• 모든 호출이 중첩된 모델 루프라서 지연 시간이 늘어납니다

스킬과 도구로 서브에이전트를 메인 에이전트에 통합하기

서브에이전트를 한 번에 하나씩 메인 에이전트에 통합하세요. 각 서브에이전트의 프롬프트는 스킬로, API 호출은 MCP 도구로 바꾸면 됩니다. 서브에이전트가 있을 때와 없을 때의 평가 성능을 비교한 다음, 어떤 것을 유지할지 결정합니다.

비교할 때는 최종 점수만 보지 말고 어떤 작업의 결과가 뒤바뀌었는지 살펴보세요. 샘플 고객 지원 에이전트로 테스트했을 때, 서브에이전트 하나를 다른 서브에이전트에 통합하자 지연 시간은 줄었지만 잘 통과하던 프로세스가 깨졌습니다. 메인 에이전트가 주문 조회 도구를 직접 들고 있다 보니, 배송 전문 에이전트에게 배송 예정일을 묻지 않고 혼자 답해 버린 것입니다.

변경하기 전에 평가에 다음이 모두 들어 있는지 확인하세요. 프로덕션에서 함께 실행되는 에이전트 체인마다 작업이 하나씩 있어야 하고, 에이전트가 절대 어기면 안 되는 규칙마다 작업이 하나씩 있어야 합니다. 그리고 각 작업을 두 번 이상 실행하세요. 이 사례의 문제도 두 번 실행한 중 한 번에서만 나타났습니다.

여러 팀이 하나의 에이전트에 기여하는 방법

도메인 추론은 지식 베이스, 스킬, MCP 도구에서 가져올 수 있습니다. 각 팀은 에이전트 대신 스킬과 도구를 맡는 쪽으로 담당 영역을 옮기고, 작은 중앙 팀 하나가 시스템 프롬프트와 엔드투엔드 품질을 계속 책임집니다. 여기에는 새 스킬, 도구, 평가를 출시 전에 검증하는 일이 포함됩니다.

MCP 도구

도구는 에이전트가 어떤 동작을 수행하거나, 시스템에서 실시간 데이터를 읽거나, 고정된 형식으로 결과를 반환해야 할 때 적합합니다. 마이그레이션하는 동안 서브에이전트를 계속 호출하는 수단으로 도구를 쓸 수도 있습니다. API 하나당 도구 하나가 아니라 사용자 의도별로 묶은 도구를 권장합니다. 시스템 프롬프트의 도구 정의가 30~50개를 넘으면 도구 선택 능력이 떨어지는 경향이 있기 때문입니다.

지연 로딩을 지원하는 도구 검색을 사용하고, 엄격한 선행 조건은 제한하되 꼭 필요한 조건은 도구 안으로 옮기세요. 예를 들어 Y가 X의 출력을 필요로 한다면, Y의 도구가 그 출력이 있는지 확인하고 모델이 따를 수 있는 지시를 반환하게 합니다. 사용자별 권한도 같은 방식으로 처리합니다. 각 도구가 호출한 사용자가 무엇을 보고 할 수 있는지 확인한 뒤 모델이 읽을 수 있는 평이한 거부 메시지를 반환하면, 권한 수준마다 별도 에이전트를 두지 않고도 루프 하나로 접근 권한이 서로 다른 사용자들을 응대할 수 있습니다.

스킬

스킬은 팀이 일하는 방식, 즉 전문 서브에이전트의 프롬프트에 담겨 있던 절차, 규칙, 판단 기준을 에이전트가 알아야 할 때 적합합니다.

스킬 라이브러리를 키워 가는 Anthropic의 방식은 유지 관리를 스킬을 작성하는 사람들에게 다시 맡기는 것입니다. 힘든 작업은 다른 스킬을 만들고, 테스트하고, 정리하는 스킬을 통해 Claude가 대신해 줄 수 있습니다.

스킬이 난립하지 않게 하려면 팀별 DRI가 각자의 스킬을 책임지고, 스킬이 잘 작성되어 있고 서로 구분되며 적절한 평가와 함께 출시되도록 관리하게 하면 됩니다.

• /skill-creator로는 처음부터 구조가 잘 잡힌 새 스킬을 작성할 수 있고, 기존 스킬을 점검해 줄이고, 중복을 없애고, 구조를 재정리할 수 있습니다.
• /skill-doctor로는 라이브러리의 각 스킬에 드는 비용과 실제 사용 빈도를 확인하고, 쓸모없는 스킬을 삭제할 수 있습니다.

지식 베이스

지식 베이스는 에이전트가 가끔만 필요로 하는 참고 자료에 적합합니다. 사실 정보와 참고 자료(정책, 지표 정의, 제품 사양)는 모델이 호출하는 검색 또는 조회 도구 뒤에 두거나, 스킬 안에 참조 파일로 담아 배포할 수 있습니다. 코드가 이런 컨텍스트를 가져와 프롬프트에 붙여 넣는 방식은 피하세요.

이 작업을 빠르게 해 주는 도구

Anthropic은 최근 위에서 설명한 작업 대부분에 도움이 되는 Claude API 스킬 모음을 공개했습니다. 마이그레이션 키트는 이 스킬들을 하나의 안내형 워크플로로 연결해, 멀티 에이전트 시스템을 평가하고 단일 에이전트 루프로 옮기도록 돕습니다. 실제 시스템에 적용하기 전에 체험해 볼 수 있는 데모도 포함되어 있습니다.

• /claude-api build-eval: 중앙 팀이 관리하는 첫 엔드투엔드 평가 세트나, 각 팀이 스킬과 함께 내놓는 작은 평가를 만드는 데 도움이 됩니다.
• /claude-api prompt-audit: 프롬프트, 스킬, 도구 설명에서 이전 모델용으로 작성된 지침을 찾아 diff 형태로 수정안을 제안합니다. 시스템 프롬프트에 실행하면 이전 모델을 위해 추가했다가 지금은 에이전트를 느리고 경직되게 만드는 규칙을 찾아낼 수 있습니다. 각 팀의 DRI도 자기 팀의 스킬과 도구 설명에 실행해 볼 수 있습니다.
• /claude-api hillclimb: 기존 평가를 기준으로 앱을 반복해서 개선합니다. "통합 대 유지" 비교에 쓸 수 있고(서브에이전트 하나를 스킬과 도구로 통합한 뒤 스킬과 도구 설명을 반복 개선하게 해서, 통합한 버전이 서브에이전트와 같거나 더 나은 성능을 내는지 확인), 시스템 프롬프트 개선에도 쓸 수 있습니다.
• /claude-api cost-optimize: 호출이 어디에 쓰이는지 프로파일링하고, 프롬프트 캐싱, 불필요한 입출력 토큰 줄이기, effort, 모델 선택 같은 방법으로 비용 절감안을 한 번에 하나씩 제안합니다. 특정 설계의 비용과 지연 시간을 낮추는 데 도움이 됩니다.

모델이 발전하면 모델을 가장 잘 쓰는 방법에 대한 이해와 모범 사례 가이드도 함께 발전합니다. 그래서 특정 아키텍처보다 그 바탕에 있는 원칙이 더 중요합니다. 측정하고, 한 번에 하나씩 바꾸고, 효과가 확인된 것만 남기는 것입니다.

이번 경우도 그런 사례입니다. 모델이 더 유능해지고 에이전트가 더 오래 실행될수록, 서브에이전트 가운데 더 많은 부분을 스킬과 도구로 바꿀 수 있습니다. 다만 한 번에 모두 옮길 필요는 없습니다. 작은 엔드투엔드 평가를 만들고, 서브에이전트 하나를 통합해 보고, 통합한 버전의 점수가 더 나쁠 때만 서브에이전트로 남겨 두세요. 그런 다음 같은 과정을 반복하면 됩니다.