한 기업은 고객 응대용 에이전트 안에 전문 서브에이전트를 열두 개 두고 있었다. 브랜드 경험은 일관되지 않았고, 지연 시간이 길어 쓰기도 불편했다. Anthropic의 Applied AI 팀이 여러 기업 도입 현장에서 마주친 장면 중 하나다.
Anthropic은 이런 경험을 바탕으로 서브에이전트를 합칠 수 있는지 따져보라고 권고했다. 필요할 때 컨텍스트를 불러오는 단일 주 에이전트가 전문 에이전트 여럿보다 나은 결과를 내는 경우가 많다는 것이다. 회사가 든 근거는 이렇다. Opus 4.5부터 Opus 5.5, Fable 5.1까지 새 모델은 복잡한 계획을 하나의 루프 안에서 직접 관리한다. 한 비교에서는 단일 에이전트 구성이 다중 에이전트 구성보다 약 두 배 빨랐다. 스킬(skills)을 쓰는 단일 에이전트가 하나의 거대한 프롬프트나 서브에이전트 구성보다 품질에서 앞서는 일도 잦았다고 한다.
조직도를 닮아가는 에이전트
Anthropic이 짚은 기존 설계는 익숙하다. 의도 감지, 고정된 처리 파이프라인, 사용자 세분화, 갈래별 추천 로직, 그 위에 올라앉은 오케스트레이터다. 이 가운데 상당수는 이제 모델이 알아서 처리할 수 있다는 게 회사 설명이다.
Anthropic은 이 현상을 에이전트판 "콘웨이의 법칙"이라 부른다. 팀마다 서브에이전트를 하나씩 만들다 보면 표준 없이 겹치는 에이전트가 수백 개로 불어난다. 팀마다 시스템 프롬프트에 규칙을 얹다 보면 서로 모순되는 "프랑켄프롬프트"가 나온다. 정리된 시스템 프롬프트, 간결한 데이터 도구 네다섯 개, 고정된 출력 가드레일이면 상당수 용례를 감당한다는 게 Anthropic의 입장이다.
회사는 직접 사례도 들었다. 새 모델용 Claude Code 시스템 프롬프트를 80% 넘게 줄였다. 스킬과 도구가 필요할 때만 로드되기 때문이다. 새 모델이 스스로 진행 상황을 설명하고 결과를 점검하는 덕에 일부 통제 계층은 필요 없어질 수 있다고도 했다.
그래도 서브에이전트가 필요한 경우
Anthropic이 단일 구성을 일률적으로 내세운 것은 아니다. 서브에이전트가 여전히 의미 있는 조건을 세 가지로 적었다.
- 단일 에이전트의 컨텍스트 윈도우에서 성능 저하가 측정될 때
- 별도 컨텍스트 윈도우로 여러 작업을 병렬 실행해야 할 때
- 단일 에이전트가 도구 선택에 어려움을 겪을 때
무작정 합치는 것도 경계했다. 지원 에이전트 테스트에서 서브에이전트를 흡수하자 지연은 줄었지만, 잘 돌던 절차가 깨졌다. 주 에이전트가 전문 에이전트에게 묻지 않고 직접 답하기 시작한 것이다. 그래서 Anthropic은 GitHub에 마이그레이션 키트를 공개했다. 기존 패턴을 식별하고, 대안을 평가하고, 최선의 방식을 검증하는 순서로 안내한다.
합친 뒤의 운영 원칙
팀마다 에이전트를 주는 대신 워크플로를 스킬로 묶고, 도구는 도구 검색(tool search)으로 필요할 때 불러오라는 것이 권고다. 시스템 프롬프트와 전반적 품질은 소규모 중앙 팀이 맡는다. 도구 정의가 30~50개를 넘으면 모델의 도구 선택이 나빠지는 경향이 있어서, 팀별 담당자가 스킬 라이브러리를 관리해야 한다고 했다. 가이드라인·제품 사양·지표 정의 같은 참고 자료는 검색 도구로 필요할 때만 조회하는 지식 베이스에 두거나 스킬 안의 참조 파일로 넣으라고 한다. 코드로 컨텍스트를 가져와 프롬프트에 바로 주입하는 방식은 권하지 않았다.
다른 실험은 무엇을 보여줬나
The Decoder가 정리한 외부 연구도 결이 비슷하다. 평가 업체 Vals AI는 GPT-6 Sol과 Claude Opus 5.5를 Vibe Code Bench에서 단독과 팀 구성으로 나눠, 추론 강도 두 단계(중간·최대)에서 시험했다. 팀 구성의 비용은 단독의 1.8~5.1배였다. 네 번의 비교 중 통계적으로 유의한 개선은 한 번뿐이었다. 추론 강도 중간의 GPT-6 Sol 팀이 7.3점 높았다. 최대 추론에서는 두 모델 모두 팀 구성의 뚜렷한 이점이 없었다.
Anthropic이 Opus 5.5로 한 자체 테스트 두 건에서도 에이전트를 늘릴수록 품질 개선 폭이 줄었다. 10개에서 100개로 늘려도 24시간 뒤 점수는 조금 올랐을 뿐이다.
| Opus 5.5 과제 | 1개 | 10개 | 30개 | 100개 |
|---|---|---|---|---|
| 지식 베이스 | 0.53 | 0.70 | 0.71 | 0.74 |
| Lean 정리 증명 | 0.39 | 0.66 | 0.66 | 0.68 |
OpenAI 연구원 노엄 브라운(Noam Brown)은 Dwarkesh Podcast에서 다중 에이전트 시스템이 주로 사는 것은 속도이지 품질이 아니라고 말했다. 에이전트 4개는 과제를 두 배 빨리 풀었지만 비용도 두 배였다. 웹 리서치와 수학은 병렬화가 잘 되지만 소설 쓰기는 그렇지 않다는 설명도 덧붙였다. OpenAI 개발자 에릭 프로벤처(Eric Provencher)는 에이전트 군집이 "거의 확실히" 돈 낭비일 것이라고 평했다.
국내 팀이 따져볼 지점
에이전트 서비스를 만드는 국내 개발팀도 같은 질문 앞에 선다. 팀마다 에이전트를 하나씩 만들어 온 조직이라면 서브에이전트 수, 중복되는 프롬프트 규칙, 도구 정의 개수부터 세어볼 만하다. 다만 이번 근거는 Anthropic 자체 평가와 기업 도입 경험, 그리고 일부 벤치마크에서 나왔다. 서비스마다 결과가 다를 수 있어, 합치기 전에 키트의 평가·검증 절차를 거쳐야 한다. 서브에이전트를 합치는 것과 유지하는 것, 어느 쪽이든 기준은 컨텍스트 성능, 병렬 실행, 도구 선택 정확도다.
