Anthropic이 서브에이전트를 메인 루프 하나로 접으라는 설계 가이드를 냈다. 같은 글은 접은 지원 에이전트가 배송일 확인을 건너뛴 실패도 실었다. 하나씩 접고, 과제마다 두 번 돌려 뒤집힌 항목을 확인하면 된다.
사내 에이전트 설계 회의에서 화이트보드에 그려지는 그림은 대개 비슷하다. 가운데 오케스트레이터가 있고, 그 아래 영업·법무·데이터 조회처럼 부서 이름을 단 서브에이전트가 줄지어 붙는다. 부서마다 자기 프롬프트를 관리하니 책임 소재는 깔끔해 보인다.
Anthropic Applied AI 팀의 10월 22일 설계 글은 이 그림을 조직도의 사본, 곧 콘웨이 법칙이 작동한 결과라고 부른다. 구조가 부서를 따라 쪼개지면 서브에이전트 사이를 오갈 때마다 맥락이 한 번씩 깎인다. 글은 메인 루프 하나가 스킬과 도구를 필요할 때만 꺼내 쓰는 구조로 돌아가라고 권한다.
이 글에서 쓸모 있는 부분은 권고보다 절차다. 무엇을 먼저 합치고, 합친 뒤 무엇을 보고 되돌릴지까지 적었다.
서브에이전트를 줄이면 넘겨주기에서 새던 맥락이 돌아온다
Anthropic이 꼽은 다중 에이전트의 비용은 넷이다. 넘겨줄 때마다 잃는 맥락, 늘어나기만 하는 서브에이전트 수, 여러 팀 규칙을 덧댄 시스템 프롬프트, 그리고 지연이다. 한 회사는 고객용 에이전트 안에 전문 서브에이전트를 열두 개 두었다가 브랜드 톤을 일관되게 유지하기 어려웠다. 다른 고객은 자사 다중 에이전트 하네스와 단일 루프를 비교해 실행 시간이 약 2배 빨라진 결과를 얻었다.
대안 구조에서는 모델 하나와 컨텍스트 윈도 하나가 매 턴 도구 호출을 묶어 내보내고, 하네스가 그 호출을 병렬로 실행한다. 계획은 모델이 직접 쓰고 고친다. 서브에이전트가 들고 있던 것들은 아래처럼 옮긴다. Anthropic은 이 방식으로 고급 모델용 Claude Code 시스템 프롬프트를 80% 넘게 줄였다고 밝혔다.
| 서브에이전트에 있던 것 | 접은 뒤 옮길 곳 |
|---|---|
| 프롬프트에 적힌 업무 절차 | 스킬 (팀마다 담당자 1명) |
| 서브에이전트가 부르던 API | 사용자 의도 단위로 묶은 MCP 도구 |
| 권한·승인 같은 강제 한도 | 도구 코드 (거절은 모델이 읽는 문장으로) |
| 턴 수·비용 예산, 쓰기 게이트 | 하네스 |
| 가끔 필요한 참고 자료 | 검색 도구 또는 스킬 안 파일 |
도구를 한 루프에 모으면 정의가 쌓인다는 반론이 남는다. Claude 도구 검색 문서는 도구가 30~50개를 넘으면 Claude의 도구 선택 정확도가 떨어진다고 적었다. GitHub·Slack·Sentry·Grafana·Splunk 서버를 함께 물리면 작업 전에 정의만 약 5만 5천 토큰을 쓴다. defer_loading: true를 단 도구는 검색으로 찾을 때만 컨텍스트에 들어오고, 정의 토큰은 문서 기준 85% 넘게 준다. 서브에이전트를 접는 일과 도구 검색을 켜는 일은 한 묶음으로 움직인다.
통합은 총점이 아니라 통과에서 실패로 뒤집힌 과제로 판정한다
Anthropic이 제시한 순서에서 eval이 맨 앞이다. 끝까지 수행했는지를 보는 공용 과제 세트는 중앙 팀이 갖고, 스킬마다 작은 세트를 따로 붙인다. 시작은 golden example 10건이면 충분하다고 했다. 다음으로 서로의 출력을 이어받거나, 같은 데이터를 만지거나, 늘 함께 불리는 서브에이전트부터 합친다. 남은 서브에이전트는 대화를 넘기지 않고 도구로 부른다. 대화를 통째로 넘기는 경우는 사용자와 직접 말해야 할 때뿐이다.
접는 단위는 한 번에 하나다. 접기 전과 후의 eval을 비교할 때는 어떤 과제가 통과에서 실패로 바뀌었는지 본다. 글의 지원 에이전트 사례가 근거다. 서브에이전트 하나를 접자 지연은 줄었지만, 메인 에이전트가 배송 담당에게 배송일을 묻지 않고 주문 문의에 답했다. 이 실패는 두 번 돌린 실행 중 한 번에서만 나타났다.
총점이 그대로여도 절차 하나는 빠질 수 있다. 과제를 한 번씩만 돌렸다면 이 사례는 통합 성공으로 기록됐을 것이다.
가져갈 것
- 오케스트레이터와 서브에이전트에 붙은 도구 정의를 합치면 30개를 넘는가? 넘는다면 통합 전에 tool search와
defer_loading: true를 붙였는가? - 통합 후보 서브에이전트마다 끝까지 수행 여부를 판정하는 golden example이 10건 이상 있는가?
- eval 과제마다 2회 이상 실행하고, 접기 전후로 통과·실패가 바뀐 과제 목록을 남기는가?
- 이번 분기 첫 통합 대상이 출력을 이어받거나 같은 데이터를 만지거나 함께 호출되는 서브에이전트 쌍인가?
- 사용자와 직접 대화하지 않는 서브에이전트를 handoff가 아니라 도구 호출로 부르고 있는가?
- 턴 수·비용 한도와 쓰기 승인이 시스템 프롬프트 문장이 아니라 하네스와 도구 코드에 들어 있는가?
안 되는 경우
- 단일 루프에서 컨텍스트가 불어 성능이 측정 가능하게 떨어지거나, 새 컨텍스트로 병렬 처리한 뒤 버려도 되는 작업이면 Anthropic도 서브에이전트를 남기라고 했다. GitHub의 10월 1일 Copilot dynamic workflows 공지가 든 PR 변경 파일 병렬 리뷰가 그 예다. 쪼개는 쪽 근거는 Claude Code Dynamic Workflows, 에이전트의 게으름·자기편향·목표 표류는 컨텍스트를 쪼개야 멈춘다에 정리했다.
- 약 2배 빠른 실행과 단일 루프가 자주 더 나았다는 비교는 Applied AI 팀의 관찰과 고객 일화다. 과제 수·정확도·비용 수치는 공개하지 않았다.
- 80% 축소는 고급 모델용 Claude Code 시스템 프롬프트 기준이다. 소형 모델에서도 같은 폭이 나오는지는 밝히지 않았다.
- 30~50개 문턱은 Claude 도구 검색 문서의 수치다. 다른 벤더 모델에 같은 선이 적용된다는 근거는 없다.
이번 주에 바꿀 것은 서브에이전트 목록 한 장이다. 서브에이전트마다 물린 도구 수, 함께 불리는 상대, golden example 수를 옆 칸에 적으면 무엇부터 접을지가 보이고, 접은 뒤 두 번 돌린 eval 기록이 되돌릴 근거가 된다. 에이전트 구조를 조직도에서 떼어 내는 작업을 바깥 시선으로 점검하고 싶다면 함께 따져볼 수 있다. 사업영역 →