Anthropic, 서브에이전트 대신 단일 에이전트 권고하며 전환 키트 공개

Anthropic이 기업들에게 서브에이전트를 합칠 수 있는지 점검해 보라고 권고했다. 필요할 때 맥락을 불러오는 주 에이전트 하나가 전문 에이전트 여러 개보다 품질, 비용, 지연 시간에서 나은 결과를 내는 경우가 많다는 이유다. Anthropic은 한 비교에서 단일 에이전트 구조가 멀티 에이전트 구조보다 약 두 배 빨랐다고 밝혔다.¹

Anthropic은 전환을 돕는 키트를 GitHub에 공개했다. 기존 구조의 패턴을 찾고, 대안을 평가하고, 가장 나은 방식을 검증하는 순서로 안내한다. 권고는 Opus 4.5부터 Opus 5.5와 Fable 5.1까지의 모델을 전제로 한다. Anthropic은 이 모델들이 복잡한 계획을 하나의 루프에서 직접 다룰 수 있다고 설명했다.¹

맥락 손실과 중복된 통제 계층

권고는 여러 기업 도입 사례에서 Anthropic 응용 AI 팀이 얻은 경험에서 나왔다. 스킬을 쓰는 단일 에이전트가 하나의 거대한 프롬프트 설계와 서브에이전트 구성 모두보다 품질이 높은 경우가 많았다고 한다. 한 기업은 고객 응대 에이전트 안에 전문 서브에이전트를 열두 개 두었는데, 브랜드 경험을 일관되게 유지하기 어려웠고 지연 시간이 길어 사용성도 떨어졌다.

기능 작성, 테스트 작성, 코드 리뷰를 나눠 맡기면 넘겨줄 때마다 맥락이 사라진다. 단일 에이전트 방식에서는 맥락을 이미 가진 에이전트 하나가 기능과 테스트를 함께 쓰고, 별도의 검증자는 테스트를 돌려 결과만 보고한다.

Anthropic은 흔한 에이전트 설계를 의도 파악, 고정된 처리 파이프라인, 사용자 분류, 추천 분기, 그 위의 오케스트레이터로 묘사했다. 이 가운데 상당 부분을 모델이 스스로 처리할 수 있다는 입장이다. 새 모델은 자기 진행 상황을 설명하고 결과도 스스로 점검하므로 일부 추가 통제 계층이 필요 없어질 수 있다고 했다.

Anthropic은 조직도를 닮아가는 에이전트 구조를 에이전트판 "콘웨이의 법칙"이라고 불렀다. 팀마다 서브에이전트를 만들다 보면 공통 기준 없이 겹치는 에이전트가 수백 개로 늘고, 팀들이 시스템 프롬프트에 규칙을 덧붙이면서 서로 모순되는 "프랭켄프롬프트"가 생긴다고 했다. 정돈된 시스템 프롬프트, 가벼운 데이터 도구 네다섯 개, 고정된 출력 가드레일이면 상당수 사용 사례를 감당한다는 것이 회사 설명이다. Anthropic은 새 모델용 Claude Code 시스템 프롬프트를 80% 넘게 줄였고, 스킬과 도구를 필요할 때만 불러오는 점이 한 이유라고 밝혔다.¹

전환 방법과 서브에이전트가 남는 경우

Anthropic은 팀마다 에이전트를 두지 말고 업무 절차를 스킬로 묶으라고 권한다. 도구는 도구 검색으로 필요할 때 불러오고, 작은 중앙 팀이 시스템 프롬프트와 전체 품질을 맡는 구조다. 모델의 도구 선택 정확도는 정의된 도구가 30~50개를 넘으면 떨어지기 시작하므로 팀별 담당자가 스킬 라이브러리가 부풀지 않게 관리해야 한다고 했다.¹

도구 검색은 Claude API가 서버에서 실행하는 도구다. 도구 정의에 defer_loading을 true로 지정하면 Claude가 검색으로 찾기 전까지 컨텍스트에 들어가지 않는다. 검색 방식은 정규식과 BM25 두 가지다. 한 번에 반환하는 결과는 기본 5개다. 요청마다 지연 로딩 도구를 최대 1만 개까지 둘 수 있다.

공식 문서는 GitHub, Slack, Sentry, Grafana, Splunk 같은 여러 서버를 연결하면 작업 전에 도구 정의만으로 약 5만 5천 토큰을 쓸 수 있다고 설명한다. 도구 검색은 이를 보통 85% 넘게 줄이고 요청마다 3~5개만 불러온다. 도구가 10개 이상이거나 정의가 1만 토큰을 넘을 때, 또는 MCP 서버를 여럿 묶어 200개 넘는 도구를 쓸 때 쓰라는 안내다. 자주 쓰는 도구 3~5개는 지연 로딩하지 않는 편이 좋다. 지연 로딩 도구는 시스템 프롬프트 앞부분에서 빠지므로 프롬프트 캐싱이 유지된다.²

지침, 제품 사양, 지표 정의 같은 참고 자료는 필요할 때만 검색 도구로 묻는 지식 베이스에 두라고 Anthropic은 권했다. 스킬 안에 참고 파일로 넣어도 된다. 코드로 맥락을 가져와 프롬프트에 바로 주입하는 방식은 피하라고 했다.¹

Anthropic의 커머스 에이전트 안내서도 같은 방향이다. 스킬은 지시문이 이미 전체 대화 기록을 가진 주 에이전트에 로드되므로 서브에이전트로 넘길 때 드는 비용 없이 분야별 모듈화와 맥락 통제를 얻는다고 설명한다. 사용 빈도가 전체 트래픽의 3분의 1 이상인 내용은 시스템 프롬프트에, 나머지는 스킬에 두라는 기준도 제시했다. 사용자가 들어온 페이지처럼 이미 아는 신호로 필요한 스킬을 예측할 수 있으면 첫 모델 호출 전에 하네스가 주입해 스킬을 불러오는 턴을 건너뛰라고 한다.³

서브에이전트가 맞는 경우도 있다. 단일 에이전트의 컨텍스트 창에서 성능 저하가 측정될 때, 별도의 컨텍스트 창으로 여러 작업을 병렬 실행해야 할 때, 단일 에이전트가 도구 선택에 어려움을 겪을 때다. 커머스 안내서는 두 예외를 더 든다. 하나는 서브에이전트가 문서를 읽고 코드를 실행하며 막다른 길까지 오가다가 간결한 답만 돌려주는 심층 조사다. 다른 하나는 약국이나 금융처럼 규정 준수 체계를 갖춘 전용 에이전트가 이미 있는 분야로, 이때는 그 에이전트가 사용자와 직접 작업을 마무리하는 인계가 적절할 수 있다.^1,3

Anthropic은 무작정 합치지 말라고 경고했다. 고객 지원 에이전트 실험에서 서브에이전트를 합치자 지연 시간은 줄었지만 잘 되던 절차가 깨졌다. 주 에이전트가 맞는 전문가에게 묻지 않고 직접 답하기 시작했다는 것이다.¹

외부 연구

Vals의 연구에서는 에이전트 팀이 단일 에이전트보다 빠를 수 있지만 품질이 더 높지는 않았다. 에이전트를 10개에서 30개나 100개로 늘려도 품질은 오르지 않고 비용만 크게 늘었다. OpenAI 개발자 Eric Provencher도 에이전트 떼의 가치에 의문을 제기하며 "거의 확실히" 돈 낭비라고 말했다.¹