Claude Platform에서 여러 서브에이전트를 포함한 에이전트를 만들었다면, 저희가 제공하는 마이그레이션 키트로 어떤 서브에이전트를 메인 에이전트 루프에 합치는 것이 타당한지 확인해 보세요. 이 키트는 안내형 워크플로를 실행하여 여러분이 쓰는 패턴을 파악하고, 대안을 평가하고, 가장 좋은 접근 방식을 검증합니다. 실제 에이전트에 적용하기 전에 모의 시스템에서 시험해 볼 수 있는 데모도 들어 있습니다.
서브에이전트는 자신만의 컨텍스트 윈도, 도구, 지시문을 갖추고 코디네이터의 조율을 받는 에이전트이며, 에이전트 설계에서 핵심적인 구성 요소입니다. 서브에이전트는 검증, 병렬 작업, 모듈 단위의 권한 부여에 효과적입니다. 저희도 Claude Platform으로 만드는 여러 자체 에이전트에서 서브에이전트를 사용하며, 멀티 에이전트 리서치 시스템이 그 예입니다.
그런데 최근 Applied AI 팀은 라우터, 플래너, 도메인 서브에이전트를 메인 에이전트 루프에 합쳐서 효과를 본 엔터프라이즈 에이전트 배포 사례에서 공통된 패턴을 발견했습니다. 여러 엔터프라이즈 배포를 비교해 보니, 스킬을 갖춘 단일 에이전트가 모든 일을 프롬프트 하나에 담는 설계와 서브에이전트 설계를 품질 면에서 모두 앞서는 경우가 많았고, 작업당 비용과 지연 시간도 더 낮은 경우가 많았습니다.
예를 들어 한 회사는 고객용 에이전트 안에 둔 십여 개의 전문 서브에이전트 때문에 브랜드에 맞는 일관된 경험을 유지하기가 어려웠고, 늘어난 지연 시간이 사용자 경험을 해친다는 사실을 알게 되었습니다.
저희는 익숙한 단계를 밟아 가는 에이전트 설계안도 자주 봅니다. 의도 분류기, 고정된 다단계 추론 파이프라인, 사용자 세그먼트별 분류, 별도의 추천 분기를 두고, 그 위에 멀티 에이전트 오케스트레이터를 얹는 식입니다.
이런 경우에 저희가 주는 피드백은 대개 비슷합니다. 이 구조 대부분은 이제 모델이 스스로 할 수 있어서 대신해 줄 필요가 없는 일을 하고 있으며, 명확한 시스템 프롬프트 하나와 얇은 데이터 도구 4–5개, 확실한 출력 가드레일만 있으면 사용 사례 대부분을 감당할 수 있다는 것입니다.
서브에이전트 설계
분명히 말하자면, 서브에이전트는 연구의 최전선을 포함해 여전히 쓸모가 있습니다. 다음과 같은 경우에는 서브에이전트를 사용하세요.
- 단일 에이전트 루프에서 컨텍스트가 비대해져 측정 가능한 성능 저하가 발생하는 경우
- 여러 작업을 병렬로 처리해야 하고, 작업이 끝나면 버릴 수 있는 새 컨텍스트 윈도가 필요한 경우
- 단일 에이전트가 적절한 도구를 고르지 못하거나 시스템 프롬프트 안에 서로 충돌하는 지시문이 있는 경우
하지만 기업이 팀이나 문제 유형마다 서브에이전트를 하나씩 배정하여, 에이전트 아키텍처가 조직도를 그대로 복제하는 모습을 너무 자주 봅니다(콘웨이의 법칙이 작동하는 것입니다).
이 글에서는 대규모 조직에서 에이전트를 만들며 얻은 모범 사례와 함께, 서브에이전트를 메인 에이전트 루프에 합치는 방안을 언제 고려해야 하는지 설명합니다.
대규모 조직에서 에이전트를 만들 때 생기는 실패 유형
기업들은 여러 제품과 기능을 하나의 고객 접점으로 묶는 에이전트를 만들고 싶어 하는 경우가 많습니다.
보통 각 기능은 서로 다른 팀이 담당하므로, 기업들은 먼저 각 팀이 자기 에이전트를 만들게 한 다음 중앙 플랫폼 팀이 그 위에 오케스트레이터를 얹는 방식으로 시작합니다. 이 방식은 오케스트레이터와 서브에이전트 구조나, 특정 에이전트를 MCP 도구로 노출한 단일 에이전트 구조 등 여러 형태가 될 수 있습니다.
이 방식은 가장 단순한 해법처럼 보이지만, 곧바로 다음과 같은 복잡성을 불러옵니다.
- 컨텍스트 관리: 에이전트끼리 어떤 컨텍스트를 주고받을지 정해야 하고, 주고받는 과정에서 세부 정보를 잃는 경우가 많습니다.
- 서브에이전트 난립: 모든 팀이 자기 서브에이전트를 내놓다 보니, 기업은 강제되는 표준도 없고 정해진 담당자도 없는 서브에이전트 수백 개가 서로 겹치는 상황에 이릅니다.
- 프랑켄프롬프트: 모든 팀이 시스템 프롬프트에 문장을 하나씩 추가하여, 규칙끼리 충돌하고 일관된 어조도 사라집니다.
- 검증되지 않고 지나치게 국지적인 평가: 모두가 자기 하위 작업에 과도하게 최적화된 평가를 각자 추가합니다. 전체 평가 세트를 소유하거나 관리하는 사람은 없고, 경영진은 희석되고 지나치게 국지적인 점수를 바탕으로 결정을 내립니다.
- 지연 시간: 멀티 에이전트 아키텍처의 복잡성은 지연 시간을 늘립니다. 자사의 멀티 에이전트 하네스를 단일 에이전트 루프와 비교 평가한 한 고객은 단일 에이전트 루프의 실행 속도가 약 2배 빠르다는 결과를 얻었습니다.
점진적 노출을 적용한 에이전트 루프 사용하기
위에서 설명한 오케스트레이터와 서브에이전트 설계는 여러 팀이 만든 전문 에이전트를 조율하는 합리적인 접근 방식입니다. 하지만 스킬로 컨텍스트를 점진적으로 노출하고 도구 검색으로 도구를 점진적으로 노출하는 방식이 더 효과적인 경우가 많습니다. 다시 말해, 에이전트는 스킬과 도구의 짧은 설명만 보고, 필요할 때에만 그 전체 내용을 불러옵니다.
이 접근 방식이 타당할 수 있는 이유는 세 가지입니다.
- 공유된 컨텍스트가 더 나은 답을 만듭니다: 오래 실행되는 에이전트라면 여러 작업에서 나온 컨텍스트가 메인 컨텍스트 윈도에 함께 있어야 합니다. 앞선 단계의 결과를 모두 본 에이전트는 그 결과들을 서로 연결할 수 있으며, 서브에이전트들이 돌려준 요약 묶음보다 더 풍부한 출력과 더 나은 통찰을 만들어 냅니다. 이는 컨텍스트 윈도의 수가 줄고 정보를 잃는 인계도 줄어든다는 뜻이기도 합니다.
- 점진적 노출은 컨텍스트 비대화를 막습니다: 이 기법을 쓰면 팀은 모든 컨텍스트를 긴 시스템 프롬프트 하나에 한꺼번에 불러오지 않고도 다양한 작업을 해내는 단일 에이전트를 만들 수 있습니다. 이로써 예전에 팀들이 작업을 여러 서브에이전트로 나누던 주된 이유가 사라집니다. 실제로 저희는 더 발전된 모델용 Claude Code 시스템 프롬프트를 80% 넘게 줄였는데, 이 감축에는 스킬과 도구를 점진적으로 노출하는 것과 관련된 부분이 포함되어 있었습니다.
- 모델의 능력이 높아졌습니다: Opus 4.5부터 모델은 대부분의 팀이 예상한 것보다 훨씬 많은 일을 단일 루프 안에서 관리할 수 있게 되었습니다. Opus 5.5와 Fable 5.1에서는 thinking을 끌 수 없으며, 최근 모델들은 진행 상황을 스스로 설명하고 작업 도중에 결과를 점검하는 경향이 점점 강해져서 하네스의 일부 요소가 불필요해졌습니다. 새 모델이 나올 때마다 더 많은 의사 결정을 하네스에서 모델 자체로 옮길 수 있습니다. 단순한 루프는 다음 모델로 옮기기도 더 쉽습니다. 저희가 고객을 도운 마이그레이션에서는 경직된 멀티 에이전트 구조가 새 모델이 더 많은 일을 맡지 못하게 막는 원인인 경우가 많았습니다.
단일 에이전트 루프 설계에는 규율이 필요합니다. 시스템 프롬프트를 신중하게 관리해야 하고, 스킬과 도구의 설명이 적절한 시점에 작동하도록 써야 하며, 컨텍스트 윈도와 메모리, 메모 작성을 의도적으로 다뤄야 합니다. 이 글의 이어지는 절에서 마이그레이션과 설계 시 고려 사항을 더 깊이 다룹니다.
중앙 팀 하나가 엔드투엔드 품질과 시스템 프롬프트를 소유하고, 새 도구와 평가를 출시하기 전에 모두 검토해야 합니다. 이 중앙 팀을 작게 유지하면 반복 개선이 빨라지고, 대규모 조직 전반의 조율 비용도 낮아집니다.
멀티 에이전트 방식을 택한다면, 효과가 있을 만한 가장 단순한 패턴(생성자와 검증자, 오케스트레이터와 서브에이전트 등)부터 시작하세요. 컨텍스트 경계를 기준으로 나누어 효과적으로 분해하세요. 각 서브에이전트에게는 시스템의 나머지 부분에서 필요한 것이 거의 없는 작업을 맡기고, 간결한 결과를 돌려받으세요(서로 독립적인 리서치 경로, 인터페이스가 깔끔하게 분리된 별도 구성 요소, 블랙박스 검증 등이 좋은 후보입니다). 에이전트를 문제 유형별로 나누면 에이전트들은 "말 전하기 놀이"를 하게 됩니다. 정보를 주고받을 때마다 인계 과정에서 정확도가 떨어집니다.
문제 유형별로 나눈 서브에이전트
서브에이전트를 메인 에이전트 루프에 합치는 방법
많은 팀이 이미 오케스트레이터와 전문 에이전트 묶음을 프로덕션에서 운영하고 있습니다. 저희가 목표로 삼기를 권하는 단일 루프 설계는 다음과 같습니다.
- 모델 하나와 컨텍스트 윈도 하나가 열린 형태의 도구 루프를 실행하며, 제한(턴 예산과 비용 예산, 쓰기 게이트)은 하네스에서 설정합니다.
- 턴마다 모델은 도구 호출을 묶음으로 내보냅니다. 하네스는 그 호출들을 병렬로 실행하고 원본 결과를 같은 모델에게 돌려주며, 모델이 다음 단계를 결정합니다. 다음 단계는 또 다른 호출 묶음일 수도 있고, 사용자에게 던지는 질문이나 답변일 수도 있습니다.
- 루프는 모델이 답변하거나 예산에 도달하면 멈춥니다. 답변 뒤에 목표 점검이나 검증기 점검을 선택적으로 실행할 수 있습니다.
- 모델은 첫 턴에 컨텍스트 안에 계획을 쓰고, 결과가 들어오는 대로 계획을 고칩니다. 이것이 오케스트레이터와 전문 에이전트 구성과 비교했을 때 가장 큰 변화입니다. 계획을 쓰는 모델이 그 계획을 실행하는 모델이기도 하므로, 턴 도중에 계획을 바꿀 수 있습니다.
- 컨텍스트는 여전히 불러오지만, 그 관리는 에이전트가 스스로 맡습니다.
- 규칙 카탈로그를 바탕으로 계획을 다시 쓰는 코드 단계는 더 이상 필요하지 않습니다. 모델이 각 단계를 결정하기 때문입니다.
- 순서와 도메인 절차는 스킬로 옮깁니다.
- 강제 제한(검증, 승인 게이트)과 대화 도중에 생기는 그 밖의 일(예: 메모리 조회)은 도구로 옮깁니다.
- 비용이 적고 거의 항상 관련 있는 것(예: 엔티티 확인 단계)을 불러오거나, 루프가 호출하는 도구 안에서 기계적인 부분(페이로드 구성, 스트림 파싱, 명확화 질문 이후 재개)을 처리하는 데에는 여전히 코드를 쓸 수 있습니다.
- 규칙 카탈로그를 바탕으로 계획을 다시 쓰는 코드 단계는 더 이상 필요하지 않습니다. 모델이 각 단계를 결정하기 때문입니다.
이 단일 루프 설계는 많은 팀이 지향하는 최종 상태, 즉 사용자의 상위 목표를 이해하고 사용자를 대신해 행동하는 에이전트에도 도움이 됩니다. 에이전트가 알게 된 모든 것을 하나의 컨텍스트에 유지하기 때문입니다.
아래 제안은 팀이 멀티 에이전트 시스템에서 단일 에이전트 루프로 단계적으로 옮겨 가는 방법과, 그 과정에서 여러 팀이 계속 그 에이전트에 기여하는 방법을 다룹니다.
작업 완료 평가
첫 단계는 서브에이전트를 메인 에이전트 루프에 합쳐야 할지 판단하는 데 도움이 되는 평가 세트를 만드는 것입니다. 저희가 효과를 확인한 평가 구조는 중앙 팀이 소유하는 공유 엔드투엔드 세트 하나와, 각 스킬을 소유한 팀이 그 스킬과 함께 내놓는 작은 평가 세트들입니다. 골든 예시 10개짜리 세트만으로도 시작하기에 충분합니다.
에이전트의 최종 메시지를 루브릭에 따라 채점하는 것은 답변 품질을 추적하는 좋은 출발점입니다. 아직 오케스트레이터가 있는 동안에는 라우팅 정확도(올바른 서브에이전트를 골랐는가?)도 추적해야 합니다. 서브에이전트를 합친 뒤에는 그 대신 에이전트가 올바른 스킬을 불러왔는지, 올바른 도구를 호출했는지 확인합니다. 아키텍처를 비교할 때 가장 중요한 것은 작업 완료 여부이므로, 시간을 두고 작업 완료 평가로 나아가는 것이 도움이 됩니다.
내부 시스템을 재현하기 어렵고 사용자 참여를 시뮬레이션하기 어려운 환경에서는 이 작업이 복잡해질 수 있습니다. 저희 내부에서 효과가 있었던 한 가지 방법은 중요한 이벤트에 타임스탬프를 기록해 두었다가, 나중에 그 이벤트를 재생하여 표적 평가로 실행하는 것입니다.
서브에이전트를 점차 줄이기
단일 에이전트 루프로 발전해 가려면 서브에이전트를 도구와 스킬로 합쳐야 합니다. 이는 도메인 서브에이전트를 병합하거나, 서브에이전트를 도구로 호출하거나, 서브에이전트를 스킬과 도구로 대체하는 방식으로 할 수 있습니다.
서브에이전트 합치기
도메인 에이전트 결합하기
첫 병합 전에 작은 엔드투엔드 평가를 만드세요. 그런 다음 가장 많이 쓰이는 서브에이전트부터 공유 컨텍스트를 기준으로 합치세요.
서로의 출력을 이어받거나, 같은 데이터를 다루거나, 자주 함께 호출되는 전문 에이전트를 병합하세요. 예를 들어 프로덕션 트래픽의 상당 부분이 한 전문 에이전트 다음에 두 번째 전문 에이전트를 호출하는 흐름이라면, 둘은 긴밀하게 결합된 쌍이므로 하나의 도메인 에이전트로 병합할 후보가 됩니다.
도구로 호출되는 서브에이전트
앞에서 말한 세 가지 조건 중 하나에 해당하여 서브에이전트를 유지한다면, 메인 에이전트가 서브에이전트를 도구로 호출하게 하는 방식이 효과적일 수 있습니다. 그러면 메인 에이전트가 사용자와의 대화를 계속 주도할 수 있습니다.
서브에이전트가 대화를 넘겨받는 완전한 핸드오프는 서브에이전트가 사용자와 직접 대화해야 할 때에만 권합니다. 그 밖의 모든 것은 메인 루프 안의 스킬과 도구로 처리할 수 있습니다.
이렇게 하면 서브에이전트용 공유 응답 스키마를 정의하고, 메인 에이전트가 실제 데이터에 비추어 결론을 검증하고, 마지막 종합 단계에 들어가는 입력을 줄일 수 있습니다. 서브에이전트를 다시 작성할 필요가 없으므로 좋은 첫 단계입니다. 또한 서브에이전트를 메인 에이전트에 합칠지 결정하기 전에 작업 완료 평가에서 기준선을 확보할 수 있습니다.
하지만 몇 가지 실패 유형은 남습니다.
- 전문 에이전트마다 자체 프롬프트, 컨텍스트, 담당 팀, 평가를 갖습니다
- 호출할 때마다 여전히 정보가 손실된 요약을 돌려받습니다
- 모든 호출이 중첩된 모델 루프이므로 지연 시간이 늘어납니다
스킬과 도구로 서브에이전트를 메인 에이전트에 합치기
각 서브에이전트의 프롬프트는 스킬로, API 호출은 MCP 도구로 바꾸어 서브에이전트를 한 번에 하나씩 메인 에이전트에 합치세요. 서브에이전트가 있을 때와 없을 때의 평가 성능을 비교하세요. 그런 다음 무엇을 남길지 결정하세요.
비교할 때는 최종 점수만 보지 말고, 어떤 작업의 결과가 뒤집혔는지 살펴보세요. 저희가 샘플 지원 에이전트로 이를 시험했을 때, 서브에이전트 하나를 다른 서브에이전트에 합치자 지연 시간은 줄었지만 통과하던 프로세스 하나가 깨졌습니다. 메인 에이전트가 주문 조회 도구를 직접 사용해 혼자 답변하면서, 배송 전문 에이전트에게 배송일을 묻지 않았던 것입니다.
매번 변경하기 전에 평가에 프로덕션에서 함께 실행되는 모든 에이전트 체인과 에이전트가 어겨서는 안 되는 모든 규칙에 대한 작업이 들어 있는지 확인하세요. 그리고 각 작업을 두 번 이상 실행하세요. 이번처럼 깨지는 현상은 두 번 실행 중 한 번에서만 나타났기 때문입니다.
여러 팀이 하나의 에이전트에 기여하는 방법
도메인 추론은 지식 베이스, 스킬, MCP 도구에서 가져올 수 있습니다. 각 팀은 소유 대상을 에이전트에서 스킬과 도구로 옮기고, 작은 중앙 팀 하나가 시스템 프롬프트와 엔드투엔드 품질의 소유권을 유지할 수 있습니다. 여기에는 새 스킬, 도구, 평가를 출시하기 전에 검토하는 일이 포함됩니다.
MCP 도구
에이전트가 행동을 취해야 하거나, 시스템에서 실시간 데이터를 읽어야 하거나, 고정된 형태로 결과를 돌려줘야 할 때에는 도구가 알맞습니다. 마이그레이션하는 동안 서브에이전트를 계속 호출하는 수단으로 도구를 쓸 수도 있습니다. 시스템 프롬프트의 도구 정의가 30–50개를 넘으면 도구 선택의 정확도가 떨어지는 경향이 있으므로, API마다 도구 하나를 두기보다 사용자 의도별로 묶은 도구를 권합니다.
지연 로딩을 적용한 도구 검색을 사용하고, 강제 전제 조건은 최소화하며, 꼭 필요한 전제 조건은 도구 안으로 옮기세요. 예를 들어 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, 모델 선택 같은 선택지에서 절감 방안을 한 번에 하나씩 제안합니다. 주어진 설계에서 비용과 지연 시간을 낮추는 데 도움이 됩니다.
모델이 발전함에 따라, 모델을 가장 잘 활용하는 방법에 대한 저희의 이해와 모범 사례에 관한 지침도 함께 발전합니다. 그래서 특정 아키텍처 하나보다는 그 바탕에 있는 원칙이 더 중요합니다. 측정하고, 한 번에 하나씩 바꾸고, 효과가 유지되는 것을 남기는 것입니다.
이번 경우도 마찬가지입니다. 모델의 능력이 높아지고 에이전트가 더 오래 실행될수록, 더 많은 서브에이전트를 스킬과 도구로 바꿀 수 있습니다. 하지만 그 전환을 한 번에 할 필요는 없습니다. 작은 엔드투엔드 평가를 만들고, 서브에이전트 하나를 합치고, 합친 버전의 점수가 더 낮을 때에만 서브에이전트로 남겨 두세요. 그리고 이 과정을 반복하세요.