AI 에이전트를 여러 개로 나눠야 하나: Anthropic '하위 에이전트 줄이기' 지침과 딥시크 슈퍼 에이전트로 본 구축 제안서의 멀티 에이전트 구조 확인법

회사 업무용 AI 에이전트는 하나로 시작하고 나눌 이유가 측정될 때만 여러 개로 나누는 편이 낫습니다. Anthropic은 2026년 10월 22일 공개한 글에서 여러 기업 배포를 비교해 보니 스킬을 갖춘 에이전트 하나가 모든 것을 한 프롬프트에 넣은 설계와 하위 에이전트로 나눈 설계보다 품질이 나은 경우가 많았고 작업당 비용과 지연도 낮은 경우가 많았다고 밝혔습니다. 구축 업체가 부서마다 에이전트를 하나씩 두고 그 위에 지휘 에이전트를 올리는 제안서를 냈다면 왜 나눴는지와 나눈 효과를 무엇으로 쟀는지부터 물어야 합니다.

Anthropic은 무엇을 권했나

Anthropic 글에 따르면 하위 에이전트는 자기 맥락·도구·지시를 따로 갖고 지휘 에이전트가 일을 나눠 주는 구조입니다. 검증, 병렬 작업, 권한을 나눠 주는 데는 효과가 있고 Anthropic도 자사 리서치 시스템에 씁니다. 그런데 기업 배포에서는 라우터·계획 에이전트·업무별 하위 에이전트를 본 에이전트 하나로 합쳤을 때 나아진 경우가 반복해서 나왔다고 합니다. 한 회사는 고객용 에이전트 안의 전문 하위 에이전트 십여 개 때문에 응대 말투를 맞추기 어려웠고 지연도 늘었습니다. 다른 고객은 멀티 에이전트 구조와 단일 에이전트 구조를 비교해 단일 구조에서 실행 시간이 약 2배 빨랐습니다.

Anthropic은 실패 원인으로 다섯 가지를 들었습니다. 에이전트끼리 맥락을 주고받다 세부가 빠집니다. 팀마다 하위 에이전트를 만들다 보면 겹치는 에이전트가 수백 개로 늘어납니다. 팀마다 시스템 프롬프트에 한 문장씩 넣어 규칙이 서로 부딪히고 팀마다 자기 일에만 맞춘 평가를 만들어 전체 품질을 보는 사람이 없어집니다. 구조가 복잡해진 만큼 느려지기도 합니다. 글은 이를 조직도를 그대로 옮긴 에이전트 구조라고 표현했습니다: "too often we see enterprises give each team or problem type its own subagent, with the agent architecture becoming a copy of their org chart".

그래도 나눌 때가 있다고 적었습니다. 맥락이 길어져 성능이 눈에 띄게 떨어질 때, 서로 독립된 작업을 새 맥락에서 동시에 처리해야 할 때, 에이전트 하나가 도구를 제대로 고르지 못하거나 지시가 서로 부딪힐 때입니다. 나눌 때는 업무 유형이 아니라 맥락으로 나누라고 했습니다. 다른 부분에서 받을 정보가 적고 짧은 결과만 돌려주는 일(독립된 조사, 경계가 분명한 부품, 결과만 보는 검증)이 하위 에이전트에 맞는다는 것입니다.

딥시크 슈퍼 에이전트는 왜 나눴나

딥시크 하네스 개발팀은 2026년 10월 31일 위챗 공식 계정 글에서 팀 대화방과 GitHub 이벤트를 받아 일을 나눠 주는 상주 라우터와 각자 독립된 세션에서 일하는 워커를 분리한 구조를 설명하고 연구용 프로토타입 코드를 GitHub에 공개했습니다. 이 경우는 여러 사람의 요청이 동시에 들어와 서로 독립된 작업을 나란히 처리해야 해서 Anthropic이 나누라고 한 조건에 해당합니다.

딥시크의 실험은 메시지 약 300개 중 작업 요청 약 20개가 섞인 합성 부하로 구조별로 5번씩 돌렸습니다. 코딩은 시간만 쓰는 도구로 바꿔서 코딩 실력이 아니라 일을 나누고 처리하는 능력만 쟀습니다. 슈퍼 에이전트의 작업 완료 시간은 중앙값 12.4분, 95번째 백분위 15.7분이었습니다. 하위 에이전트 도구를 가진 단일 세션은 중립적인 프롬프트에서 5번 모두 하위 에이전트를 한 번도 부르지 않았고 95번째 백분위가 29.5분이었습니다. 대신 슈퍼 에이전트는 세션을 여러 개 유지해서 읽기 캐시 토큰을 단일 세션보다 많이 썼습니다. 딥시크는 GitHub에 이 코드가 정식 제품이 아닌 연구용이고 내부 버전과 다르다고 적었습니다.

구글 딥마인드는 10월 29일 보고서 '지능의 경제학'에서 AI의 개별 업무 능력과 여러 에이전트가 일을 나눠 협력하는 능력을 구분했습니다. 보고서는 OpenAI의 노엄 브라운이 수천 개 에이전트로 수학 문제를 풀어 본 뒤 에이전트들이 일을 나누기보다 각자 같은 문제를 풀었고 성과의 10%도 멀티 에이전트 덕으로 보기 어렵다고 말했다고 전했습니다. 에이전트 수를 늘린다고 일이 나뉘지는 않는다는 뜻입니다.

회사가 정할 것

• 합격선 먼저: 구조를 정하기 전에 실제 업무 사례로 정답지를 만듭니다. Anthropic은 골든 예시 10개로도 시작할 수 있다고 했습니다.
• 나눌 이유: 하위 에이전트를 둔다면 맥락 길이·동시 처리·도구 선택 중 어떤 이유인지 한 줄로 적게 합니다.
• 비교 방법: 하나로 둔 구조와 나눈 구조를 같은 정답지로 비교하고 점수만이 아니라 결과가 바뀐 작업을 봅니다. 한 번에 안 드러나는 오류가 있으니 같은 작업을 두 번 이상 돌립니다.
• 비용 단위: 에이전트가 늘면 모델 호출과 토큰이 늘어납니다. 작업당 비용과 완료 시간을 함께 받습니다.
• 책임자: 시스템 프롬프트와 전체 품질을 맡을 작은 팀을 정하고 새 도구·스킬·평가는 그 팀이 검토한 뒤 넣습니다.

구축 업체에 물을 질문

• 제안한 에이전트 수와 각 에이전트가 맡는 일은 무엇이고 에이전트 하나로 하면 무엇이 안 되나요?
• 멀티 에이전트 구조가 단일 구조보다 낫다는 것을 어떤 정답지로 비교했나요?
• 에이전트끼리 넘기는 정보는 무엇이고 넘기면서 빠지는 정보는 어떻게 확인하나요?
• 에이전트가 늘어날 때 작업당 모델 사용료와 완료 시간은 어떻게 달라지나요?
• 새 모델로 바꿀 때 구조를 다시 짜야 하나요?

노벤티스는 어떻게 다루나

노벤티스는 AI 에이전트를 설계할 때 업무별 입력·출력·승인 규칙과 실패 시 사람에게 넘기는 조건을 먼저 정하고 과거 처리 사례로 만든 정답지로 결과를 잽니다. 승인 없이 외부 발신·결제·삭제를 실행하는 자동화는 만들지 않습니다. 에이전트 수는 이 정답지로 비교해서 정합니다. 위 표와 점검 항목은 Anthropic·딥시크·구글 딥마인드의 공개 자료를 바탕으로 정리한 일반 원칙이며 노벤티스의 특정 사례가 아닙니다. 첫 프로젝트는 접점 하나를 대상으로 4~8주 안에 PoC까지 진행하고 범위와 비용은 진단 미팅 후 서면 견적으로 정합니다.

이 글이 맞는 독자: 에이전트 여러 개로 된 구축 제안서를 받은 회사, 부서마다 AI 에이전트를 만들고 있는데 전체를 누가 볼지 정해야 하는 IT·운영 책임자입니다.