06 · 역할별 서브에이전트에서 Large Ultra 에이전트 하나로

Anthropic Applied AI 팀의 Diane Sarkis가 쓴 Building agents: When to fold subagents into your main agent loop(2026-10-22)를 바탕으로 쓴 한국어 요약입니다. 마지막 「이 사이트의 제안 — Large Ultra 에이전트 하나를 관리하기」 절은 원문이 아니라 이 사이트의 판단이며, 측정 결과가 아닙니다. 도식 두 장은 개념을 설명하려고 새로 그렸습니다.

서브에이전트가 늘면 인계와 품질도 관리해야 합니다

역할마다 서브에이전트(별도 컨텍스트 창·도구·지시문을 가진 에이전트)를 두면, 각 역할의 지시문뿐 아니라 에이전트 사이에 전달할 정보도 관리해야 합니다. 개별 에이전트가 자기 일을 잘하는지와 전체 작업이 잘 끝나는지는 서로 다른 평가 대상입니다.

Anthropic Applied AI 팀은 기업에서 기능별 담당 팀이 각자 에이전트를 만들고, 중앙 플랫폼 팀이 오케스트레이터(여러 에이전트의 작업을 조율하는 실행 주체)로 묶는 구성을 자주 봤습니다. 팀이나 문제 유형마다 에이전트를 만들다 보니 설계가 조직도를 닮아 가는 것입니다. 기사는 이를 콘웨이의 법칙(Conway’s law, 조직의 구성이 시스템 설계에 반영되는 현상)으로 설명합니다.

Anthropic이 소개한 한 회사는 고객용 에이전트 안에 전문 서브에이전트를 열두 개쯤 두었습니다. 이 회사는 일관된 브랜드 경험을 유지하기 어려웠고, 늘어난 지연도 사용자 경험을 해쳤습니다.

아래 도식은 오케스트레이터가 전문 에이전트에 일을 나누고 결과를 돌려받는 구성을 보여줍니다.

팀별 에이전트를 오케스트레이터 아래에 두거나 단일 에이전트의 MCP 도구로 노출하면 기능을 한곳에 모을 수 있습니다. Anthropic이 이런 기업 구성에서 지적한 실패 양상은 다음과 같습니다.

• 컨텍스트 관리: 에이전트끼리 어떤 정보를 주고받을지 정해야 하며, 전달 과정에서 세부 정보가 빠진다.
• 서브에이전트 난립: 팀마다 에이전트를 내놓으면서, 적용되는 표준과 명확한 담당자가 없는 중복 서브에이전트가 수백 개로 늘어난다.
• 프랑켄프롬프트(Frankenprompt, 팀별 지시가 뒤섞인 프롬프트): 각 팀이 시스템 프롬프트에 문장을 더하면서 규칙이 충돌하고 일관된 목소리가 사라진다.
• 검증되지 않은 국소 평가: 각 팀이 자기 하위 작업에 지나치게 맞춘 평가를 추가하지만 전체 세트를 책임지고 관리하는 사람이 없다. 경영진은 전체 품질을 제대로 보여 주지 못하는 국소 점수로 판단한다.
• 지연: 여러 에이전트를 조율하는 복잡성이 실행 시간을 늘린다. Anthropic이 소개한 한 고객은 멀티 에이전트 하네스(에이전트 실행을 관리하는 코드)와 단일 에이전트 루프를 비교했고, 후자가 약 2배 빨랐다.

계획과 실행을 같은 컨텍스트에 두기

Anthropic이 비교한 여러 기업 사례에서는 스킬을 갖춘 단일 에이전트가 모든 지시를 한 프롬프트에 넣는 설계와 서브에이전트 설계보다 품질이 높은 경우가 많았습니다. 작업당 비용과 지연도 낮은 경우가 많았습니다. 작업을 분배하거나 계획을 세우는 에이전트, 도메인 서브에이전트를 메인 루프로 옮겨 나아진 사례들입니다.

이 대안은 점진적 공개(progressive disclosure, 짧은 설명을 먼저 보여 주고 필요할 때 전체 내용을 불러오는 방식)를 사용합니다. 에이전트는 스킬(필요할 때 불러오는 절차·판단 지침)과 도구의 짧은 설명을 보고, 작업에 필요한 내용을 선택해 불러옵니다. 도구에는 도구 검색(tool search, 필요한 도구를 찾아 불러오는 기능)을 씁니다. 처음부터 모든 지시와 자료를 시스템 프롬프트에 넣을 필요가 없는 구성입니다.

같은 컨텍스트에 이전 단계의 결과가 남으면 모델은 그 결과들을 연결할 수 있습니다. Anthropic은 오래 실행되는 에이전트에서 이런 공유 컨텍스트가 서브에이전트의 요약 묶음보다 풍부한 답과 통찰을 만드는 데 도움이 된다고 봅니다. 컨텍스트 창의 수가 줄고, 정보를 전달하면서 생기는 손실도 줄어듭니다.

필요한 내용만 불러오는 방식은 컨텍스트 비대(context bloat, 컨텍스트가 지나치게 커지는 현상)를 막는 데도 쓰입니다. Anthropic은 더 발전한 모델용 Claude Code 시스템 프롬프트를 80% 넘게 줄였습니다. 이 감소분에는 스킬과 도구를 점진적으로 공개하면서 줄인 부분이 포함돼 있습니다.

모델 자체가 맡을 수 있는 일도 늘었습니다. Anthropic에 따르면 Opus 4.5부터 모델은 대부분의 팀이 예상한 것보다 훨씬 많은 일을 루프 하나에서 관리하게 됐습니다. Opus 5.5와 Fable 5.1에서는 thinking(모델의 추론 기능)을 끌 수 없습니다. 최근 모델은 진행 상황을 설명하고 작업을 확인하며 나아가므로, 하네스가 대신하던 일부 기능은 중복됩니다. 새 모델이 나올 때마다 판단을 하네스에서 모델로 더 옮길 수 있으며, 단순한 루프는 다음 모델로 옮기기도 쉽습니다. Anthropic이 도운 마이그레이션에서는 경직된 멀티 에이전트 구성이 새 모델의 능력 활용을 막는 경우가 많았습니다.

기사에는 의도 분류기, 고정된 다단계 추론 파이프라인, 사용자 세그먼트 분류, 별도 추천 분기, 멀티 에이전트 오케스트레이터로 이어지는 설계도 등장합니다. Anthropic은 이런 구성 상당 부분이 모델에게 더는 대신 해 줄 필요가 없는 일을 맡고 있다는 피드백을 자주 소개합니다. 해당 사례에서는 명확한 시스템 프롬프트 하나, 기능을 얇게 나눈 데이터 도구 4~5개, 확실한 출력 제약으로 사용 사례 대부분을 감당할 수 있다는 판단입니다.

아래 도식은 하나의 모델이 같은 컨텍스트에서 계획을 세우고, 필요한 스킬과 도구를 사용하며 다음 행동을 정하는 흐름입니다.

모델 하나와 컨텍스트 창 하나가 도구 호출 루프를 실행합니다. 모델은 첫 턴에 계획을 쓰고, 도구 결과가 들어오면 그 계획을 고칩니다. 계획을 세운 모델이 실행도 맡기 때문에 턴 중간에도 계획을 바꿀 수 있습니다. 규칙 목록에 따라 계획을 다시 작성하던 코드 단계는 모델이 다음 단계를 결정하면서 필요 없어집니다.

매 턴 모델이 도구 호출 묶음을 내면 하네스가 병렬로 실행하고, 원본 결과를 같은 모델에 돌려줍니다. 모델은 도구를 더 부를지, 사용자에게 질문할지, 답을 낼지 정합니다. 턴·비용 예산과 쓰기 게이트는 하네스가 제한하며, 모델이 답하거나 예산에 도달하면 루프가 멈추는 방식입니다. 답을 낸 뒤에는 목표 달성 여부나 검증기를 선택적으로 확인할 수 있습니다.

Anthropic은 이 구성이 사용자의 상위 목표를 이해하고 대신 행동하는 에이전트에도 도움이 된다고 봅니다. 작업하면서 배운 내용이 같은 컨텍스트에 남기 때문입니다.

분리할 근거가 있는 서브에이전트만 남기기

Anthropic은 서브에이전트를 없애라고 권하지 않습니다. 검증, 병렬 작업, 모듈 단위 권한 부여에는 효과가 있으며, 자사의 멀티 에이전트 리서치 시스템에도 사용합니다. 서브에이전트를 남길 기준으로 제시한 것은 다음 세 조건입니다.

• 단일 에이전트 루프가 컨텍스트 비대 때문에 측정 가능한 성능 저하를 겪을 때
• 여러 작업을 새 컨텍스트 창에서 병렬로 처리하고, 작업이 끝나면 그 컨텍스트를 버려도 될 때
• 단일 에이전트가 알맞은 도구를 고르지 못하거나 시스템 프롬프트 안의 지시가 서로 충돌할 때

분리가 필요하다면 컨텍스트를 기준으로 경계를 잡습니다. 다른 작업의 정보가 거의 필요 없는 일을 맡기고, 압축된 결과를 돌려받는 방식입니다. 독립적인 조사 경로, 인터페이스가 명확한 별도 구성 요소, 블랙박스 검증이 좋은 후보입니다. 문제 유형만으로 나누면 에이전트가 정보를 주고받을 때마다 세부가 빠지는 전화 게임(telephone game, 말 전달 놀이)이 벌어집니다.

멀티 에이전트 구성도 생성기-검증기(generator-verifier, 생성과 검증을 나누는 방식)나 오케스트레이터-서브에이전트처럼 작동할 만한 가장 단순한 패턴에서 시작합니다. 남긴 서브에이전트는 메인 에이전트가 도구로 호출하고, 사용자와의 대화는 메인 에이전트가 이어 가도록 권합니다. 완전한 핸드오프(사용자와의 대화까지 다른 에이전트에 넘기는 방식)는 서브에이전트가 사용자와 직접 대화해야 할 때만 권하는 선택입니다.

도구로 호출하면 공통 응답 스키마를 정하고, 메인 에이전트가 결론을 실제 데이터와 대조하며, 최종 종합 단계에 넣을 입력을 줄일 수 있습니다. 기존 서브에이전트를 다시 작성하지 않아도 되므로 이전 과정의 첫 단계로 쓰기 좋습니다. 메인 루프로 접기 전에 작업 완료 평가의 기준선을 얻는 방법이기도 합니다.

도구 호출로 바꿔도 남는 문제는 있습니다.

• 전문가마다 프롬프트, 컨텍스트, 담당 팀, 평가가 따로 있다.
• 호출마다 세부 정보가 빠진 요약을 돌려받는다.
• 호출마다 중첩된 모델 루프가 실행돼 지연을 더한다.

팀이 관리할 대상을 스킬과 도구로 옮기기

Anthropic이 권하는 소유권의 변화는 각 팀이 에이전트 대신 스킬과 도구를 관리하는 것입니다. 작은 중앙 팀 하나가 시스템 프롬프트와 종단 간(end-to-end, 작업 시작부터 완료까지) 품질을 책임지고, 새 스킬·도구·평가를 내놓기 전에 검토합니다. 중앙 팀을 작게 유지하면 반복 개선이 빨라지고 조직 내 조율 비용도 낮아집니다.

단일 루프에도 세심한 관리는 필요합니다. 시스템 프롬프트를 관리하고, 스킬과 도구가 알맞은 때 선택되도록 설명을 작성해야 합니다. 컨텍스트 창, 메모리, 노트 작성 방식도 의도적으로 설계할 대상입니다.

스킬에는 전문 서브에이전트의 프롬프트가 담고 있던 작업 순서, 도메인 절차, 규칙, 판단 기준을 옮깁니다. 각 팀의 DRI(직접 책임자)는 자기 스킬이 잘 작성됐는지, 다른 스킬과 겹치지 않는지, 적절한 평가를 갖췄는지 확인합니다. Anthropic은 스킬 작성자가 유지보수도 맡고, 다른 스킬을 만들고 시험하고 정리하는 스킬로 Claude의 도움을 받는 방식을 씁니다.

/skill-creator는 형식이 갖춰진 새 스킬을 작성하거나 기존 스킬의 불필요한 내용과 중복을 줄이고 재구성하는 데 사용합니다. /skill-doctor로는 각 스킬의 비용과 실제 사용 빈도를 살펴보고 쓰지 않는 스킬을 지울 수 있습니다.

도구는 행동을 실행하거나 실시간 데이터를 읽거나 정해진 형식의 결과를 반환할 때 적합합니다. 이전하는 동안 서브에이전트를 계속 호출하는 수단으로도 도구를 쓸 수 있습니다. Anthropic은 시스템 프롬프트의 도구 정의가 30~50개를 넘으면 도구 선택 품질이 떨어지는 경향이 있다고 설명합니다. 그래서 API마다 도구를 만들기보다 사용자 의도를 기준으로 묶도록 권합니다.

도구 검색에는 지연 로딩(deferred loading, 필요한 시점에 도구 정의를 불러오는 방식)을 함께 씁니다. 강한 선행 조건은 줄이고, 꼭 필요한 조건은 도구 안에서 확인합니다. 예를 들어 Y가 X의 출력을 요구하면 Y의 도구가 이를 검사하고 모델이 따를 수 있는 지시를 반환하는 방식입니다. 사용자별 권한도 각 도구가 검사하고 읽기 쉬운 거절을 반환하면, 권한 수준마다 에이전트를 따로 두지 않고 하나의 루프로 처리할 수 있습니다.

검증·승인 게이트 같은 강제 한도와 대화 중 필요한 메모리 조회도 도구가 맡습니다. 값싸고 거의 항상 필요한 정보의 로딩에는 여전히 코드를 쓸 수 있습니다. 루프가 호출하는 도구 안에서 페이로드 구성, 스트림 파싱, 확인 질문 재개 같은 기계적인 처리를 맡기는 것도 가능합니다.

정책, 메트릭 정의, 제품 명세처럼 가끔 필요한 참고 자료는 지식 베이스에 둡니다. 모델이 검색·조회 도구로 가져오거나 스킬의 참고 파일로 읽게 하는 것입니다. Anthropic은 코드가 이런 자료를 미리 조회해 프롬프트에 붙여 넣는 방식은 피하도록 권합니다.

함께 쓰이는 역할부터 평가하며 접기

Anthropic이 제시하는 출발점은 작은 종단 간 평가 세트입니다. 중앙 팀이 공유 세트를 관리하고, 각 팀은 자기 스킬과 함께 작은 평가 세트를 제공하는 구성이 효과적이었습니다. Anthropic은 골든 예제(평가 기준으로 삼는 대표 사례) 10개만으로도 시작할 수 있다고 봅니다.

처음에는 최종 메시지를 채점 기준에 따라 평가해 답의 품질을 추적합니다. 오케스트레이터가 남아 있다면 알맞은 서브에이전트를 골랐는지도 확인해야 합니다. 해당 역할을 메인 루프로 옮긴 뒤에는 알맞은 스킬을 불러왔는지, 필요한 도구를 호출했는지로 확인 대상이 바뀝니다. 구성 간 비교에서 가장 중요한 것은 작업을 실제로 완료했는지이므로, 평가도 점차 그 방향으로 발전시킵니다.

내부 시스템을 재현하거나 사용자 상호작용을 모의 실행하기 어려운 경우도 있습니다. Anthropic 내부에서는 중요한 이벤트에 타임스탬프를 기록하고 나중에 재생해 특정 상황을 평가하는 방법이 효과적이었습니다.

평가를 준비했다면 공유 컨텍스트를 기준으로 많이 쓰이는 서브에이전트부터 살펴봅니다. 서로의 출력을 이어받거나, 같은 데이터를 다루거나, 자주 함께 호출되는 역할이 합칠 후보입니다. 상당한 트래픽에서 한 전문가 다음에 다른 전문가가 호출된다면, 둘을 하나의 도메인 에이전트로 합치는 단계를 거칠 수도 있습니다.

메인 루프로 옮길 때는 서브에이전트 하나씩 프롬프트를 스킬로 바꾸고 API 호출을 MCP 도구로 옮깁니다. 서브에이전트를 유지한 버전과 접은 버전의 평가를 비교하되, 전체 점수뿐 아니라 통과와 실패가 뒤집힌 과제를 확인해야 합니다.

Anthropic이 샘플 지원 에이전트에서 서브에이전트 하나를 다른 서브에이전트에 합친 시험에서는 지연이 줄었지만, 통과하던 절차가 깨졌습니다. 주문 조회 도구를 가진 메인 에이전트가 배송 전문가에게 배송일을 묻지 않고 답한 것입니다. Anthropic의 이 시험에서는 오류가 두 번 중 한 번만 드러났습니다.

따라서 바꾸기 전에 실제로 함께 실행되는 에이전트 연쇄마다, 반드시 지켜야 하는 규칙마다 평가 과제가 있는지 확인합니다. 각 과제도 두 번 이상 실행해야 합니다.

Anthropic의 마이그레이션 킷은 아래 Claude API 스킬들을 안내형 워크플로로 연결해 현재 구성을 평가하고 단일 루프로 옮기는 일을 돕습니다. 실제 시스템에 적용하기 전에 모의 시스템에서 실행할 수 있는 데모도 포함돼 있습니다.

Anthropic은 특정 구조보다 그 뒤의 원칙이 중요하다고 글을 맺습니다. 측정하고, 한 번에 하나만 바꾸고, 평가에서 효과가 확인된 것을 남기는 원칙입니다. 모델이 좋아지고 에이전트가 더 오래 실행될수록 더 많은 서브에이전트를 스킬과 도구로 바꿀 수 있지만, 한 번에 모두 옮길 필요는 없습니다. 작은 종단 간 평가 세트로 시작해 하나씩 접고 비교한 뒤, 접은 버전의 점수가 더 낮을 때만 서브에이전트로 남기는 과정을 반복합니다.

이 사이트의 제안 — Large Ultra 에이전트 하나를 관리하기

여기부터는 앞의 내용을 이 사이트의 작업 방식에 적용한 판단입니다. 아래 구성을 평가해 얻은 측정 결과는 아닙니다.

이 사이트의 문서 작업은 구현, 탐색, 리뷰, 검증, 문서 조사를 역할별 서브에이전트 여러 개에 나누고 모델 티어별로 위임하는 방식입니다. 메인 루프는 판단과 조율을 맡습니다. 역할마다 프롬프트를 따로 관리하며, 작업을 넘길 때마다 요약을 돌려받는 구성입니다.

앞으로는 큰 메인 에이전트 하나를 관리 대상으로 삼자는 제안입니다. 이 글에서는 그 단일 루프에 Large Ultra 에이전트라는 이름을 붙입니다.

시스템 프롬프트와 종단 간 품질은 이 메인 에이전트 하나가 책임지게 합니다. 역할별 에이전트에 따로 두던 지시문은 스킬로 옮기는 방식입니다. 빈도 집계, 정규식 판별, 링크·빌드 검증처럼 결정적인 판정은 스크립트 도구에 둡니다. 원문의 검증·강제 한도를 도구로 옮기라는 방향을 이 작업에 적용한 것입니다.

서브에이전트는 앞서 본 세 조건에 맞을 때만 남깁니다. 원문 수십 개를 새 컨텍스트에서 병렬로 읽고 끝난 컨텍스트를 버리는 수집, 외부 모델에 맡기는 블랙박스 교차 검증, 컨텍스트 비대로 성능 저하가 실제로 측정되는 장문 작업이 그 대상입니다. 남긴 서브에이전트도 메인 에이전트가 도구로 호출하고, 메인이 결과를 직접 대조하도록 합니다.

이전 순서는 평가부터 시작합니다. 자주 겪는 작업으로 골든 과제 10개 정도의 평가 세트를 만들고, 함께 불리는 역할부터 하나씩 접는 방식입니다. 바꿀 때마다 통과와 실패가 뒤집힌 과제를 확인하고 각 과제를 두 번 이상 실행합니다. 점수가 떨어지면 해당 역할은 서브에이전트로 유지합니다.

이 제안이 비용에 미치는 영향은 확인하지 못했습니다. 위임에는 메인 모델보다 싼 모델로 토큰을 처리하려는 목적도 있으므로, 하나로 합치면 품질과 지연이 나아지는 경우에도 토큰 단가가 오를 수 있습니다. 평가 세트에 비용과 소요 시간을 함께 기록하고 그 결과로 판단합니다.