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

https://claude.com/ko/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop

Claude Platform에서 여러 서브에이전트를 포함한 에이전트를 만드셨다면, 저희 마이그레이션 키트로 그중 어떤 서브에이전트를 메인 에이전트 루프에 합치는 것이 좋을지 확인해 보세요. 이 키트는 안내형 워크플로를 실행해 여러분이 쓰는 패턴을 파악하고, 대안을 평가하고, 가장 좋은 방식을 검증합니다. 실제 에이전트에 실행하기 전에 모의 시스템에서 써 볼 수 있는 데모도 들어 있습니다.

서브에이전트는 자체 컨텍스트 윈도와 도구, 지침을 갖추고 코디네이터의 조율을 받는 에이전트로, 에이전트 설계의 핵심 구성 요소입니다. 서브에이전트는 검증, 병렬 작업, 모듈 단위 권한 부여에 효과적입니다. 저희도 Claude Platform으로 만드는 여러 자체 에이전트에서 서브에이전트를 사용하며, 멀티 에이전트 리서치 시스템이 그 예입니다.

하지만 최근 Applied AI 팀은 라우터, 플래너, 도메인 서브에이전트를 메인 에이전트 루프에 합쳐서 효과를 본 기업용 에이전트 배포 사례가 반복해서 나타난다는 것을 발견했습니다. 여러 기업 배포 사례를 비교한 결과, 스킬을 갖춘 단일 에이전트가 모든 것을 프롬프트 하나에 담는 설계와 서브에이전트 설계보다 품질 면에서 앞서는 경우가 많았고, 작업당 비용과 지연 시간도 더 낮은 경우가 많았습니다.

예를 들어 한 회사는 고객 응대용 에이전트 안에 둔 전문 서브에이전트 십여 개 때문에 브랜드에 맞는 일관된 경험을 유지하기가 어렵고, 지연 시간도 늘어나 사용자 경험이 나빠진다는 것을 알게 되었습니다.

저희는 익숙한 흐름을 그대로 따르는 에이전트 설계안도 자주 봅니다. 의도 분류기, 고정된 다단계 추론 파이프라인, 사용자 세그먼트별 버킷, 별도의 추천 분기가 있고, 그 위에 멀티 에이전트 오케스트레이터를 올리는 식입니다.

이런 경우 피드백은 대개 다음과 같습니다. 이 구조 대부분은 이제 모델에게 대신해 줄 필요가 없는 일을 하고 있었으며, 명확한 시스템 프롬프트 하나와 얇은 데이터 도구 4~5개, 확실한 출력 가드레일만 있으면 사용 사례 대부분을 다룰 수 있다는 것입니다.

서브에이전트 설계

분명히 말씀드리면, 서브에이전트는 연구의 최전선을 포함해 여전히 쓸모가 있습니다. 다음과 같은 경우에 사용하세요.

• 단일 에이전트 루프에서 컨텍스트 비대화(context bloat) 때문에 측정 가능한 성능 저하가 나타나는 경우, 또는
• 여러 작업을 새 컨텍스트 윈도에서 병렬로 처리해야 하고, 작업이 끝나면 그 컨텍스트 윈도를 버려도 되는 경우, 또는
• 단일 에이전트가 적절한 도구를 고르는 데 어려움을 겪거나, 시스템 프롬프트에 서로 충돌하는 지침이 있는 경우.

하지만 기업들이 팀이나 문제 유형마다 서브에이전트를 하나씩 따로 두어서, 에이전트 아키텍처가 조직도를 그대로 베낀 모습이 되는 경우를 너무 자주 봅니다(콘웨이의 법칙이 그대로 작동하는 셈입니다).

이 글에서는 대규모 조직에서 에이전트를 만들며 얻은 모범 사례와 함께, 서브에이전트를 메인 에이전트 루프에 합치는 방안을 언제 고려해야 하는지 설명합니다.

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

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

보통 기능마다 담당 팀이 따로 있기 때문에, 기업들은 먼저 각 팀이 자기 에이전트를 만들게 하고, 그다음 중앙 플랫폼 팀이 그 위에 오케스트레이터를 만드는 방식으로 시작합니다. 이 방식은 오케스트레이터-서브에이전트 구조나, 특정 에이전트를 MCP 도구로 노출한 단일 에이전트 구조 등 여러 형태가 될 수 있습니다.

가장 간단한 해결책처럼 보이지만, 곧바로 다음과 같은 복잡한 문제가 생깁니다.

• 컨텍스트 관리: 에이전트끼리 어떤 컨텍스트를 주고받을지 정해야 하고, 그렇게 주고받는 과정에서 세부 정보를 잃는 경우가 많습니다.
• 서브에이전트 난립(subagent sprawl): 팀마다 자기 서브에이전트를 내놓다 보니, 기업은 강제되는 표준도 없고 정해진 담당자도 없는, 서로 겹치는 서브에이전트를 수백 개나 떠안게 됩니다.
• 프랑켄프롬프트(The Frankenprompt): 팀마다 시스템 프롬프트에 문장을 하나씩 덧붙이다 보니, 규칙이 서로 충돌하고 말투도 일관되지 않게 됩니다.
• 검증되지 않고 지나치게 국소적인 평가(eval): 저마다 자기 하위 작업에 지나치게 최적화된 평가를 추가합니다. 전체 평가 세트를 맡아 관리하는 사람은 없고, 경영진은 희석되고 지나치게 국소적인 점수를 바탕으로 결정을 내립니다.
• 지연 시간: 멀티 에이전트 아키텍처가 복잡해지면 지연 시간이 늘어납니다. 자사의 멀티 에이전트 하네스를 단일 에이전트 루프와 비교 평가한 한 고객은 단일 에이전트 루프 쪽이 약 2배 빠르게 실행되는 것을 확인했습니다.

점진적 공개(progressive disclosure)를 활용한 에이전트 루프

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

이 방식이 합리적일 수 있는 이유는 세 가지입니다.

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

단일 에이전트 루프 설계에는 규율이 필요합니다. 시스템 프롬프트를 신중하게 관리해야 하고, 스킬과 도구 설명이 알맞은 때에 트리거되도록 다듬어야 하며, 컨텍스트 윈도와 메모리, 메모 작성을 의도적으로 다뤄야 합니다. 이 글의 뒤쪽 섹션에서 마이그레이션과 설계 시 고려할 점을 더 깊이 다룹니다.

중앙 팀 하나가 엔드투엔드 품질과 시스템 프롬프트를 책임지고, 새 도구와 평가를 출시 전에 모두 검토해야 합니다. 중앙 팀을 작게 유지하면 반복 개선이 빨라지고, 큰 조직 전반의 조율 비용도 낮아집니다.

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

문제 유형별로 나눈 서브에이전트

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

이미 오케스트레이터와 여러 전문 에이전트를 프로덕션에서 운영하는 팀이 많습니다. 저희가 목표로 삼아 나아가기를 권하는 단일 루프 설계는 다음과 같습니다.

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

이 단일 루프 설계는 많은 팀이 목표로 하는 최종 형태, 즉 사용자의 큰 목표를 이해하고 사용자를 대신해 행동하는 에이전트에도 도움이 됩니다. 에이전트가 알게 된 모든 것을 하나의 컨텍스트에 담아 두기 때문입니다.

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

작업 완료 평가

첫 단계는 서브에이전트를 메인 에이전트 루프에 합쳐야 할지 판단하는 데 도움이 되는 평가 세트를 만드는 것입니다. 저희가 효과를 확인한 평가 구조는 중앙 팀이 맡는 공유 엔드투엔드 평가 세트 하나와, 각 스킬을 담당하는 팀이 스킬과 함께 내놓는 더 작은 평가 세트들로 이루어집니다. 골든 예시 10개짜리 세트로도 충분히 시작할 수 있습니다.

에이전트의 최종 메시지를 루브릭에 따라 채점하는 것은 답변 품질을 추적하는 좋은 출발점입니다. 아직 오케스트레이터가 있다면 라우팅 정확도(알맞은 서브에이전트를 골랐는가?)도 추적해야 합니다. 서브에이전트를 합친 뒤에는 라우팅 정확도 대신, 에이전트가 알맞은 스킬을 불러왔는지, 알맞은 도구를 호출했는지 확인하세요. 아키텍처를 비교할 때는 작업 완료 평가가 가장 중요하므로, 시간을 두고 작업 완료 평가를 갖춰 나가는 것이 좋습니다.

내부 시스템을 재현하기 어렵고 사용자 상호작용을 시뮬레이션하기 어려운 환경에서는 이 작업이 복잡해질 수 있습니다. 저희가 내부적으로 효과를 본 방법 하나는 중요한 이벤트에 타임스탬프를 기록해 두는 것입니다. 그러면 나중에 그 이벤트를 재생해 목표가 분명한 평가로 실행할 수 있습니다.

서브에이전트를 점차 줄이기

단일 에이전트 루프로 발전해 가려면 서브에이전트를 도구와 스킬로 합쳐야 합니다. 도메인 서브에이전트를 병합하거나, 서브에이전트를 도구로 호출하거나, 스킬과 도구로 대체하는 방법이 있습니다.

서브에이전트 합치기

도메인 에이전트 결합하기

첫 병합에 앞서 작은 엔드투엔드 평가를 만드세요. 그런 다음 컨텍스트 공유를 기준으로, 가장 많이 쓰이는 서브에이전트부터 합치세요.

서로의 출력을 이어받아 처리하거나, 같은 데이터를 다루거나, 함께 호출되는 경우가 많은 전문 에이전트는 병합하세요. 예를 들어 프로덕션 트래픽의 상당 부분이 한 전문 에이전트 다음에 두 번째 전문 에이전트로 이어진다면, 둘은 긴밀하게 결합된 쌍이므로 하나의 도메인 에이전트로 병합할 후보가 됩니다.

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

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

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

이렇게 하면 서브에이전트용 공유 응답 스키마를 정의하고, 메인 에이전트로 결론을 실제 데이터와 대조해 검증하고, 마지막 종합 단계에 들어가는 입력을 줄일 수 있습니다. 서브에이전트를 다시 작성할 필요가 없으니 좋은 첫 단계입니다. 또한 서브에이전트를 메인 에이전트에 합칠지 결정하기 전에, 작업 완료 평가에서 기준선(baseline)을 얻을 수 있습니다.

하지만 몇 가지 실패 유형은 그대로 남습니다.

• 전문 에이전트마다 자체 프롬프트, 컨텍스트, 담당 팀, 평가가 따로 있습니다
• 호출할 때마다 여전히 정보가 손실된 요약을 돌려받습니다
• 호출 하나하나가 중첩된 모델 루프라서 지연 시간이 늘어납니다

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

각 서브에이전트의 프롬프트는 스킬로, API 호출은 MCP 도구로 바꿔서 서브에이전트를 하나씩 메인 에이전트에 합치세요. 서브에이전트가 있을 때와 없을 때의 평가 성능을 비교하세요. 그런 다음 어느 쪽을 유지할지 결정하세요.

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

무언가를 바꾸기 전에는 매번, 프로덕션에서 함께 실행되는 에이전트 연쇄와 에이전트가 절대 어겨서는 안 되는 규칙 하나하나에 대응하는 작업이 평가에 들어 있는지 확인하세요. 또 각 작업을 두 번 이상 실행하세요. 이번 사례 같은 문제는 두 번 실행 중 한 번에서만 드러났기 때문입니다.

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

도메인 추론에 필요한 내용은 지식 베이스, 스킬, MCP 도구에서 가져올 수 있습니다. 각 팀은 담당 대상을 에이전트에서 스킬과 도구로 바꾸고, 작은 중앙 팀 하나가 시스템 프롬프트와 엔드투엔드 품질을 계속 책임지면 됩니다. 여기에는 새 스킬, 도구, 평가를 출시 전에 검토하는 일이 포함됩니다.

MCP 도구

에이전트가 행동을 취하거나, 시스템에서 실시간 데이터를 읽거나, 정해진 형태로 결과를 돌려줘야 할 때는 도구가 알맞습니다. 마이그레이션하는 동안에는 도구를 통해 서브에이전트를 계속 호출할 수도 있습니다. 저희는 API마다 도구를 하나씩 두기보다 사용자 의도별로 묶은 도구를 권합니다. 시스템 프롬프트의 도구 정의가 30~50개를 넘으면 도구 선택 정확도가 떨어지는 경향이 있기 때문입니다.

지연 로딩(deferred loading)과 함께 도구 검색을 사용하고, 엄격한 전제 조건은 최소한으로 두되 꼭 필요한 조건은 도구 안으로 옮기세요. 예를 들어 Y에 X의 출력이 필요하다면, Y의 도구가 그 출력이 있는지 확인해서 모델이 바로 따를 수 있는 지시를 돌려줍니다. 사용자별 권한도 같은 방식으로 처리합니다. 각 도구는 호출한 사용자가 무엇을 보거나 할 수 있는지 확인하고, 모델이 읽을 수 있는 평이한 거부 메시지를 돌려줍니다. 그러면 권한 수준마다 에이전트를 따로 둘 필요 없이, 루프 하나로 접근 권한이 서로 다른 사용자를 모두 지원할 수 있습니다.

스킬

에이전트가 팀의 일하는 방식을 알아야 할 때는 스킬이 알맞습니다. 예전에 전문 서브에이전트의 프롬프트에 담겨 있던 단계, 규칙, 판단 기준 같은 것들입니다.

스킬 라이브러리를 키워 가는 저희 방식은 유지 보수 작업을 스킬을 작성하는 사람들에게 다시 돌려주는 것입니다. 다른 스킬을 만들고, 테스트하고, 정리하는 스킬을 쓰면 힘든 일은 Claude가 대신할 수 있습니다.

스킬이 난립하지 않도록, 팀별 DRI(직접 책임자)가 자기 팀 스킬을 맡아 각 스킬이 잘 만들어졌는지, 다른 스킬과 겹치지 않는지, 적절한 평가와 함께 출시되는지 확인하게 할 수 있습니다.

• /skill-creator를 쓰면 처음부터 형식이 잘 갖춰진 새 스킬을 작성할 수 있고, 기존 스킬을 점검해 다듬고, 중복을 없애고, 구조를 다시 짤 수 있습니다.
• /skill-doctor를 쓰면 라이브러리에 있는 스킬마다 비용이 얼마나 드는지, 실제로 얼마나 자주 쓰이는지 확인하고, 쓸모없는 스킬을 삭제할 수 있습니다.

지식 베이스

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

이 작업을 빠르게 진행하도록 돕는 도구

저희는 최근 앞에서 이야기한 작업 대부분에 도움이 되는 Claude API 스킬 모음을 출시했습니다. 저희 마이그레이션 키트는 이 스킬들을 하나의 안내형 워크플로로 엮어, 멀티 에이전트 시스템을 평가하고 단일 에이전트 루프로 옮기는 과정을 도와줍니다. 실제 시스템에 실행하기 전에 써 볼 수 있는 데모도 들어 있습니다.

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

모델이 발전함에 따라, 모델을 가장 잘 활용하는 방법에 대한 저희 이해와 모범 사례 안내도 함께 바뀝니다. 그렇기 때문에 어떤 아키텍처 하나보다는 그 바탕에 있는 원칙이 더 중요합니다. 바로 측정하고, 한 번에 하나만 바꾸고, 검증을 견딘 것만 남긴다는 원칙입니다.

이 글의 주제도 그런 경우 중 하나입니다. 모델의 역량이 높아지고 에이전트가 더 오래 실행될수록, 더 많은 서브에이전트를 스킬과 도구로 바꿀 수 있습니다. 하지만 이 전환을 한 번에 끝낼 필요는 없습니다. 작은 엔드투엔드 평가를 만들고, 서브에이전트 하나를 합쳐 보고, 합친 버전의 점수가 더 낮을 때만 서브에이전트로 유지하세요. 그리고 이 과정을 계속 반복하면 됩니다.