AI를 이해할 때 같이 보면 좋은 개념이 하나 있다. 바로 Agent Swarm이다.
Agent Swarm은 말 그대로 하나의 AI 에이전트가 모든 일을 혼자 처리하는 대신, 여러 개의 하위 에이전트가 역할을 나눠 동시에 작업하는 구조를 말한다. 어떤 에이전트는 검색을 맡고, 어떤 에이전트는 코드를 분석하고, 어떤 에이전트는 문서를 요약하고, 또 다른 에이전트는 최종 결과물을 검토하는 식이다.
쉽게 말하면, 하나의 똑똑한 개인 비서가 아니라 작은 AI 팀을 자동으로 구성해서 일하게 만드는 방식이다.
왜 Agent Swarm이 등장했나
AI에게 복잡한 일을 시키면 하나의 모델 호출만으로 끝나지 않는 경우가 많다.
예를 들어 “이 코드베이스 전체를 분석해서 버그 원인을 찾고, 수정하고, 테스트까지 해줘”라는 작업을 생각해 보자. 이 작업 안에는 여러 단계가 들어 있다.
먼저 프로젝트 구조를 읽어야 한다. 그다음 관련 파일을 찾아야 한다. 버그가 발생하는 흐름을 추적해야 하고, 수정 후보를 만들고, 테스트를 돌리고, 실패하면 다시 고쳐야 한다. 이 모든 과정을 하나의 에이전트가 순서대로 처리하면 시간이 오래 걸리고, 중간에 맥락이 꼬일 가능성도 커진다.
Agent Swarm은 이 문제를 병렬화로 해결하려는 접근이다. 하나의 중앙 에이전트가 작업을 쪼개고, 여러 하위 에이전트에게 나눠 맡긴 뒤, 마지막에 결과를 합치는 방식이다.
Anthropic의 멀티 에이전트 연구 시스템도 lead agent가 질의를 하위 작업으로 분해하고, 각 subagent에 목표, 출력 형식, 도구 사용 범위, 작업 경계를 명확히 줘야 중복과 누락을 줄일 수 있다고 설명한다.
Agent Swarm의 기본 구조
Agent Swarm은 보통 다음 흐름으로 움직인다.
첫 번째는 분해다.
사용자의 큰 요청을 여러 개의 작은 작업으로 쪼갠다. 예를 들어 “신규 기능 구현”이라는 요청은 요구사항 분석, 관련 코드 탐색, 구현, 테스트 작성, 문서 수정, 리뷰로 나눌 수 있다.
두 번째는 배정이다.
각 작업을 잘 처리할 수 있는 전문 에이전트에게 맡긴다. OpenAI Agents SDK 문서도 멀티 에이전트 시스템의 대표 패턴으로 중앙 manager가 전문 sub-agent를 도구처럼 호출하는 방식과, 한 에이전트가 다른 전문 에이전트에게 대화를 넘기는 handoff 방식을 설명한다.
세 번째는 병렬 실행이다.
여러 에이전트가 동시에 작업한다. 검색 에이전트는 자료를 찾고, 코드 에이전트는 구현 위치를 파악하고, 검토 에이전트는 실패 가능성을 확인하는 식이다.
네 번째는 종합이다.
여러 하위 에이전트가 만든 결과를 중앙 에이전트가 합쳐 최종 답변이나 결과물로 만든다.
이 구조에서 중요한 것은 에이전트 수가 많다는 사실 자체가 아니다. 핵심은 역할 분리, 병렬 처리, 결과 통합이다.
Swarm과 Handoff는 어떻게 다른가
Agent Swarm을 이해할 때 자주 나오는 단어가 handoff다.
Handoff는 한 에이전트가 “이 일은 내가 아니라 다른 전문 에이전트가 처리하는 게 맞다”고 판단하고 작업을 넘기는 방식이다.
OpenAI Agents SDK 문서는 handoff를 한 에이전트가 다른 에이전트에게 작업을 위임하는 구조로 설명하며, 환불, 결제, FAQ처럼 서로 다른 전문 영역을 가진 고객지원 에이전트 예시를 든다.
Agent Swarm은 handoff보다 더 넓은 개념으로 볼 수 있다.
Handoff가 “한 에이전트에서 다른 에이전트로 넘기는 것”에 가깝다면, Swarm은 “여러 에이전트를 동시에 움직여 하나의 목표를 달성하는 것”에 가깝다.
그래서 Swarm은 병렬 검색, 대규모 코드 분석, 복잡한 리서치, 문서 생성, 테스트 자동화 같은 작업에 더 잘 맞는다.
실제 기능으로서의 Agent Swarm
최근에는 Agent Swarm이라는 표현이 실제 제품 기능명으로도 쓰인다.
대표적으로 Kimi K2.6 공식 기술 블로그는 Agent Swarm을 “복잡한 작업을 여러 이질적인 하위 작업으로 동적으로 분해하고, 도메인별 전문 에이전트가 동시에 실행하는 구조”라고 설명한다.
Kimi K2.6은 Agent Swarm이 문서, 웹사이트, 슬라이드, 스프레드시트 같은 결과물을 하나의 자율 실행 안에서 만들 수 있다고 소개한다.
Kimi K2.6의 공식 발표에서는 이 구조가 최대 300개의 sub-agent와 4,000개의 coordinated step까지 확장된다고 설명한다. 이전 K2.5의 100개 sub-agent, 1,500 step보다 확장된 수치다.
다만 이 숫자는 공급자가 공개한 수치이므로, 실제 업무 환경에서의 안정성은 별도로 검증해야 한다.
OpenAI 쪽에도 “Swarm”이라는 이름의 실험적 프레임워크가 있었다.
GitHub의 openai/swarm 저장소는 이를 “가볍고 사용하기 쉬운 멀티 에이전트 오케스트레이션을 탐구하기 위한 교육용 프레임워크”라고 설명한다.
다만 해당 저장소는 현재 Swarm이 OpenAI Agents SDK로 대체되었고, 프로덕션 사용에는 Agents SDK로 마이그레이션하라고 안내한다.
Agent Swarm이 잘 맞는 작업
Agent Swarm은 모든 작업에 필요한 기능은 아니다. 간단한 질문 하나에 여러 에이전트를 띄우는 것은 오히려 느리고 비쌀 수 있다.
하지만 다음과 같은 작업에서는 Swarm 방식이 유용할 수 있다.
복잡한 리서치
복잡한 리서치 작업에서는 여러 에이전트가 서로 다른 관점에서 자료를 찾을 수 있다.
예를 들어 한 에이전트는 공식 문서를 보고, 다른 에이전트는 논문을 보고, 또 다른 에이전트는 뉴스나 실제 사례를 확인하는 식이다.
Anthropic은 복잡한 질의에서는 여러 subagent를 명확히 나눠 투입하고, 단순한 사실 확인에는 적은 수의 agent와 tool call만 쓰는 식으로 작업 복잡도에 따라 effort를 조절해야 한다고 설명한다.
코딩 작업
코딩 작업에서도 Swarm은 잘 맞는다.
한 에이전트는 버그 재현을 맡고, 다른 에이전트는 관련 파일 탐색을 맡고, 또 다른 에이전트는 테스트 작성을 맡을 수 있다.
특히 대규모 코드베이스에서는 한 에이전트가 모든 파일을 순차적으로 보는 것보다 여러 에이전트가 역할을 나눠 탐색하는 편이 빠를 수 있다.
문서와 산출물 생성
문서 작업에서도 쓸 수 있다.
기획서, 발표자료, 데이터 시트, 웹페이지를 동시에 만들어야 한다면 각 결과물마다 전문 에이전트를 두고 마지막에 톤과 형식을 맞추는 방식이 가능하다.
Kimi K2.6 공식 블로그도 Agent Swarm이 문서, 웹사이트, 슬라이드, 스프레드시트까지 걸친 end-to-end output을 만들 수 있다고 설명한다.
Agent Swarm의 한계
Agent Swarm은 강력해 보이지만, 단점도 분명하다.
1. 조율 비용
에이전트가 많아지면 각 에이전트에게 작업을 나누고, 진행 상태를 확인하고, 결과를 다시 합치는 비용이 생긴다.
Subquadratic의 SubQ 발표가 흥미로운 이유도 여기에 있다. SubQ Code는 전체 코드베이스를 하나의 컨텍스트 창에 넣어 plan, execute, review를 한 번에 수행하고, multi-agent system의 coordination overhead를 줄일 수 있다고 설명한다.
2. 중복 작업
중앙 에이전트가 작업을 명확히 나누지 못하면 여러 하위 에이전트가 비슷한 검색을 반복하거나 같은 파일만 분석할 수 있다.
Anthropic은 subagent에게 목표, 출력 형식, 사용할 도구와 소스, 작업 경계를 구체적으로 주지 않으면 중복과 누락이 발생한다고 설명한다.
3. 결과 통합의 어려움
여러 에이전트가 만든 답이 서로 충돌할 수 있다.
한 에이전트는 A 방식이 맞다고 하고, 다른 에이전트는 B 방식이 맞다고 할 수 있다. 이때 중앙 에이전트가 어떤 결과를 믿을지 판단해야 한다.
결과를 합치는 과정에서 근거가 약한 답이 섞이거나, 서로 다른 전제를 가진 결과물이 하나로 합쳐질 위험도 있다.
4. 비용과 추적성
에이전트가 많아질수록 모델 호출, 도구 호출, 로그, 중간 산출물이 늘어난다.
따라서 실제 서비스에서는 각 에이전트가 어떤 판단을 했는지 추적할 수 있어야 하고, 실패했을 때 어디서 잘못됐는지 확인할 수 있어야 한다.
SubQ와 Agent Swarm의 차이
SubQ와 Agent Swarm은 같은 문제를 다른 방식으로 푼다.
Agent Swarm은 복잡한 작업을 여러 에이전트에게 나눠서 처리한다. 즉, 분산과 병렬화가 핵심이다.
SubQ는 긴 컨텍스트를 하나의 모델이 더 효율적으로 처리하게 하려는 접근이다. 공식 홈페이지는 SubQ가 12M 토큰 reasoning을 목표로 하며, 전체 repository, 긴 history, persistent state를 품질 손실 없이 다룰 수 있다고 설명한다.
또한 SubQ는 fully sub-quadratic sparse-attention architecture를 통해 12M 토큰에서 attention compute를 크게 줄인다고 주장한다.
정리하면 다음과 같다.
| 구분 | Agent Swarm | SubQ 방식 |
|---|---|---|
| 핵심 아이디어 | 여러 에이전트가 역할을 나눠 병렬 작업 | 하나의 긴 컨텍스트 모델이 많은 정보를 직접 처리 |
| 장점 | 복잡한 작업을 빠르게 분산 가능 | 조율 비용과 context 손실을 줄일 수 있음 |
| 단점 | 에이전트 간 중복, 충돌, 통합 비용 발생 | 긴 컨텍스트 성능과 비용 주장의 검증 필요 |
| 잘 맞는 작업 | 리서치, 다중 산출물 생성, 병렬 코드 분석 | 전체 코드베이스 분석, 장기 상태 유지, 대규모 문서 처리 |
SubQ가 말하는 방향은 Agent Swarm을 완전히 없애겠다는 뜻이라기보다, Agent Swarm이 필요했던 일부 이유를 긴 컨텍스트 모델로 줄이겠다는 쪽에 가깝다.
SubQ 공식 발표도 긴 컨텍스트 확장이 retrieval pipeline과 agentic workflow의 필요성을 줄이고, context boundary에서 사라지는 정보를 보존하는 데 도움을 줄 수 있다고 설명한다.
한 줄로 정리하면
Agent Swarm은 AI에게 복잡한 일을 시킬 때 여러 하위 에이전트를 만들어 역할을 나누고, 병렬로 실행한 뒤, 결과를 합치는 기능이다.
좋은 Agent Swarm은 단순히 에이전트 수를 늘리는 것이 아니다.
중요한 것은 작업을 잘 쪼개고, 적절한 에이전트에게 배정하고, 중복을 줄이고, 최종 결과를 일관되게 합치는 능력이다.
그래서 Agent Swarm의 본질은 “AI를 많이 띄우는 기술”이 아니라 AI 팀을 설계하고 조율하는 기술에 가깝다.
SubQ 같은 긴 컨텍스트 모델이 등장하면서 앞으로의 흐름은 더 흥미로워질 수 있다.
어떤 작업은 Agent Swarm처럼 여러 에이전트가 나눠 처리하는 방식이 유리하고, 어떤 작업은 SubQ처럼 하나의 거대한 context 안에서 직접 추론하는 방식이 유리할 것이다.
결국 중요한 질문은 이것이다.
“이 문제는 여러 에이전트에게 나눠야 더 잘 풀리는가, 아니면 하나의 모델이 전체 맥락을 보고 풀어야 더 잘 풀리는가?”
Agent Swarm은 전자의 대표적인 접근이고, SubQ는 후자의 가능성을 밀어붙이는 접근이다.
