Anthropic이 여러 서브에이전트 대신 단일 에이전트를 권하는 이유

the-decoder7일 전조회 2

Anthropic이 기업 고객 환경에서 얻은 경험을 바탕으로, 여러 개의 전문화된 서브에이전트를 유지하기 전에 하나의 에이전트로 통합할 수 있는지 먼저 검토하라고 권고했다. 핵심은 컨텍스트를 미리 나눠 갖는 대신, 필요할 때 그때그때 불러오는 단일 에이전트 구조다. 회사는 이 전환을 돕기 위한 마이그레이션 킷도 GitHub에 함께 공개했다.

근거가 된 것은 모델 자체의 변화다. Opus 4.5를 시작으로 Opus 5.5, Fable 5.1 같은 최신 모델은 복잡한 계획을 하나의 루프 안에서 직접 처리할 수 있게 됐다. Anthropic이 공개한 한 비교에서는 단일 에이전트 구조가 다중 에이전트 구성보다 약 두 배 빠르게 동작했다. 속도뿐 아니라 품질과 비용 측면에서도 단일 구조가 앞서는 사례가 나왔다.

Applied AI 팀이 여러 기업 배포 현장에서 확인한 결과, 이른바 '스킬'을 활용하는 단일 에이전트가 거대한 단일 프롬프트 설계나 서브에이전트 조합보다 품질에서 자주 우위를 보였다. 한 회사는 고객 응대 에이전트 안에 열두 개가 넘는 전문화 서브에이전트를 두고 있었는데, 그 결과 일관된 브랜드 경험을 유지하기 어려워졌고 응답 지연까지 겹쳐 사용성이 떨어졌다.

문제는 인수인계 지점마다 발생한다. 기능 구현, 테스트 작성, 코드 리뷰가 각기 다른 에이전트로 나뉘어 있으면 단계가 넘어갈 때마다 맥락이 조금씩 유실된다. 단일 에이전트는 이미 맥락을 들고 있으므로 기능과 테스트를 한 번에 작성하고, 별도의 검증 에이전트는 테스트를 실행해 결과만 보고하는 식으로 역할을 단순화할 수 있다.

Anthropic은 이런 분화가 조직도가 그대로 아키텍처로 복사되는 현상이라고 표현하며, 이를 에이전트판 '콘웨이의 법칙'이라고 불렀다. 팀마다 자기 서브에이전트를 내놓다 보면 수백 개의 중복 에이전트가 공통 기준 없이 쌓이고, 결국 각 팀이 시스템 프롬프트에 덧붙인 규칙들이 서로 충돌하는 상태에 이른다. 회사는 깔끔한 시스템 프롬프트 하나, 서너 개의 군더더기 없는 데이터 도구, 고정된 출력 가드레일만으로 상당 부분의 유스케이스를 커버할 수 있다고 본다. 실제로 최신 모델용 Claude Code 시스템 프롬프트는 80% 이상 줄었는데, 스킬과 도구가 필요할 때만 로드되는 방식이 자리 잡은 덕분이다.

서브에이전트가 완전히 사라지는 것은 아니다. 단일 에이전트의 컨텍스트 윈도가 커질수록 성능 저하가 측정 가능한 수준으로 나타날 때, 서로 다른 컨텍스트 윈도로 병렬 실행해야 하는 작업이 있을 때, 도구 선택 자체가 버거워질 때는 분리가 여전히 합리적이다.

전환은 무작정 합치는 방식이어서는 안 된다는 경고도 붙었다. 지원 에이전트를 대상으로 한 실험에서 서브에이전트를 흡수하자 지연은 줄었지만, 원래 잘 동작하던 프로세스가 깨졌다. 메인 에이전트가 적절한 전문가를 거치지 않고 스스로 답을 내버린 것이다. 공개된 마이그레이션 킷은 기존 패턴을 식별하고 대안을 평가한 뒤 최적안을 검증하는 절차를 단계별로 안내한다.

운영 측면에서는 스킬 라이브러리가 비대해지지 않도록 관리해야 한다. 팀마다 별도 에이전트를 주는 대신 워크플로를 스킬로 패키징하고, 도구 검색을 통해 필요한 도구만 불러오는 방식이 권장된다. 시스템 프롬프트와 전반적 품질은 소규모 중앙 팀이 맡고, 각 팀의 지정 담당자가 스킬 라이브러리를 유지보수해야 한다. 모델의 도구 선택 정확도는 도구 정의가 30~50개를 넘어서면 떨어지는 경향이 있다는 점도 함께 짚었다. 가이드라인이나 제품 스펙, 지표 정의 같은 참고 자료는 검색 도구로 필요할 때만 조회하는 지식 베이스에 두거나 스킬 내부의 참조 파일로 넣는 편이 낫고, 코드로 컨텍스트를 가져와 프롬프트에 직접 주입하는 방식은 피하라고 조언한다.

외부 연구도 같은 방향을 가리킨다. Vals의 연구에서는 에이전트 팀이 단일 에이전트보다 빠를 수는 있어도 품질이 더 높아지지는 않았고, 에이전트 수를 10개에서 30개, 100개로 늘려도 품질 향상 없이 비용만 커졌다. OpenAI 개발자 Eric Provencher도 에이전트 군집의 가치에 의문을 제기하며 비용 낭비일 가능성이 크다고 지적한 바 있다.

개발자 입장에서 이번 권고는 에이전트 설계의 출발점을 바꾼다. 기능별로 에이전트를 나누는 것이 기본값이 아니라, 하나의 에이전트와 필요할 때 로드되는 스킬·도구·지식 베이스로 먼저 구성해 보고, 측정 가능한 성능 저하나 병렬 처리 요구가 확인될 때 분리를 검토하는 순서가 더 합리적이라는 뜻이다.