Anthropic이 서브에이전트를 줄이라는 이유: 합칠 때와 남길 때

한 줄 핵심

새로운 모델일수록 서브에이전트와 긴 하네스를 무조건 늘리기보다, 스킬로 합치고 실제 평가로 남길 것만 남기는 편이 더 빠르고 싸며 때로는 더 높은 품질을 낸다.

시간별 요약

1. 0:00
   서브에이전트를 줄이면 더 잘할까 하나의 에이전트에 스킬을 묶은 방식이 거대한 프롬프트나 다수의 서브에이전트보다 품질이 더 좋고, 더 빠르며 더 저렴한 경우가 많다. 실제로 일부 고객 사례에서는 다중 에이전트 구성보다 단일 루프가 약 2배 빨랐다.
2. 0:27
   조직도처럼 나누면 생기는 문제 에이전트를 조직도처럼 쪼개면 핸드오프마다 정보 손실이 생기고, 오케스트레이터와 시스템 프롬프트가 복잡해지면서 Conway's law와 비슷한 문제가 나타난다. 이를 줄이려면 필요한 정보만 점진적으로 드러내는 방식이 유효하며, 스킬처럼 짧은 설명만 먼저 로드하고 필요할 때만 전체 내용을 불러오는 구조가 컨텍스트를 깔끔하게 유지한다.
3. 1:37
   모델이 발전하면 하네스도 달라진다 서브에이전트와 긴 시스템 프롬프트는 6개월 전 모델에 맞춘 보조 장치였고, 더 나은 모델에서는 그 복잡성이 더 이상 성과로 이어지지 않거나 오히려 방해가 될 수 있다. 따라서 복잡도는 관성으로 유지할 것이 아니라, 실제 성능 향상을 입증할 때만 추가해야 한다.
4. 2:11
   스킬로 합쳐서 비교하는 방법 서로 출력이 연결되거나 같은 데이터를 다루는 서브에이전트부터 스킬로 합치는 것이 출발점이다. 다만 도구 권한이 제한돼 있어서 분리된 서브에이전트는 유지할 이유가 있으며, 전환 전에는 10개의 다양한 프롬프트로 기준선을 잡고, 서브에이전트 파일을 스킬 MD로 옮긴 뒤 같은 테스트를 다시 돌려 성능이 유지되는지 확인해야 한다.
5. 3:18
   서브에이전트를 남겨야 할 때 컨텍스트가 과도하게 불어나는 작업은 별도 서브에이전트가 유리하고, 서로 병렬로 조사한 뒤 요약만 전달하는 구조가 특히 효과적이다. 또한 잘못된 도구 선택을 줄이거나, 코드베이스 탐색·로그 분석·대량 조사처럼 병렬 연구가 큰 가치를 내는 작업에서는 서브에이전트의 효율이 높다.
6. 4:19
   내부 평가 수치와 서로 의존하는 작업 작업 단계가 서로 강하게 의존하거나 빠른 피드백과 왕복 수정이 필요한 경우에는 서브에이전트로 쪼개지 말고 메인 에이전트 안에 두는 편이 낫다. 예시처럼 배경과 캐릭터가 맞물려야 하는 작업은 분리하면 결과가 어긋나기 쉽다.
7. 4:52
   스킬과 상시 지침도 점검하기 스킬은 검증 체크리스트를 의무 작업으로 바꿔버려, 사소한 변경에도 과도한 테스트나 절차를 강제할 수 있다. 현재 모델이 지시 없이도 할 행동이라면 상시 지침과 스킬에서 과감히 지우고, 필요하면 이후 평가로 검증하는 편이 낫다.
8. 5:39
   줄인다고 비용도 줄어들까 하네스나 스킬을 줄인다고 항상 비용이 바로 내려가지는 않으며, 여전히 작업 성격에 따라 코디네이터와 워커, 안전장치가 필요한 경우도 있다. 스킬을 줄여도 과금이 크게 변하지 않을 수 있고, 비용 절감 효과는 초기 프롬프트 캐시 구조와 실제 사용 패턴까지 함께 봐야 판단할 수 있다.
9. 6:39
   정리와 마무리 핵심은 서브에이전트와 스킬을 무조건 많이 두는 것이 아니라, 현재 모델과 작업 특성에 맞게 최소 구조로 통합하고 평가로 검증하는 것이다. 실제 성능이 오를 때만 복잡도를 유지해야 하며, 그렇지 않으면 더 단순한 하네스가 더 좋은 선택이 된다.

실무 인사이트

• 서브에이전트 정리는 '조직도와 비슷한가'보다 '핸드오프가 실제로 품질을 떨어뜨리는가'를 기준으로 판단하는 것이 실무적으로 유효하다.
• 스킬로 합칠 수 있는 작업은 먼저 합쳐 보고, 분리된 상태와 비교 평가를 돌려서 남길 이유가 있는 서브에이전트만 유지하는 방식이 가장 안전하다.
• 비용 절감은 구조 축소만으로 보장되지 않으므로, 토큰 사용량뿐 아니라 캐시, 컨텍스트 낭비, 재시도율까지 함께 봐야 한다.