에이전트 스워밍 (Agent Swarming)의 진실: 전문가들이 비용, 실패, 보안에 대해 말해주지 않는 것들

지금 모든 이들이 "AI 에이전트 팀"을 구축하고 있습니다. 다섯 명의 에이전트, 열 명의 에이전트, 복잡한 작업을 위해 협업하는 거대한 스웜 (Swarm)까지 말이죠. 적어도 YouTube 썸네일들은 그렇게 약속합니다. 현실은 어떨까요? 이러한 시스템 대부분은 돈을 낭비하고, 데이터를 유출하며, 구축한 이들이 청구서를 받기 전까지는 인지조차 못 하는 방식으로 실패하고 있습니다. 저는 멀티 에이전트 시스템 (Multi-agent system)을 구축했습니다. 그것은 매일 프로덕션 환경에서 실행되고 있습니다. 따라서 저는 에이전트 스워밍 (Agent swarming)이 작동하지 않는다고 말하러 온 것이 아닙니다. 저는 그것에 대해 떠도는 대부분의 조언이 위험할 정도로 불완전하다는 사실을 말하러 왔습니다.

스웜 하이프 사이클 (Swarm Hype Cycle)이 한창 진행 중입니다. 지금 당장 Twitter나 YouTube를 열어보면 20분 안에 멀티 에이전트 팀을 구성하는 방법을 보여주는 수백 개의 튜토리얼을 찾을 수 있을 것입니다. CrewAI, AutoGen, LangGraph. 프레임워크는 계속해서 늘어나고 있습니다. 데모는 믿기지 않을 정도로 멋져 보입니다. 에이전트들이 조사하고, 에이전트들이 글을 쓰고, 에이전트들이 서로의 작업을 검토하며, 이 모든 것이 아름다운 파이프라인 (Pipeline)으로 오케스트레이션 (Orchestrated)됩니다.

여기서 데모가 보여주지 않는 것이 있습니다. 그 파이프라인을 500번 실행할 때, 혹은 5,000번 실행할 때 어떤 일이 벌어지는지 말입니다. 또는 한 에이전트가 환각 (Hallucination)을 일으키고, 다음 에이전트가 그 환각을 사실로 취급하여 이를 하류 (Downstream)의 세 번째 에이전트에게 전달하고, 그 에이전트가 이를 바탕으로 행동을 취할 때 어떤 일이 벌어지는지 말입니다. 전문가들의 콘텐츠는 일정한 패턴을 따릅니다. 설정을 보여주고, 한 번의 성공적인 실행을 보여주고, 실패 모드 (Failure modes)는 건너뛰고, 청구서는 건너뛰고, 보안상의 영향도 건너뜁니다. 이는 마치 완벽한 저녁 서비스 장면 하나를 촬영한 뒤, 위생 검사관이 나타나기 전에 편집하여 누군가에게 식당을 시작하는 법을 보여주는 것과 같습니다.

이러한 현상의 최신 버전은 "AI 에이전트로 30분 만에 회사 전체를 구축했습니다"입니다. 누군가가 Paperclip 같은 프레임워크를 실행하고 (공정하게 말하자면, Paperclip은 하트비트 스케줄링 (Heartbeat scheduling), 예산 제한 (Budget caps), 작업 큐 (Task queues), 감사 추적 (Audit trails) 등 진정으로 탄탄한 엔지니어링을 갖추고 있습니다), 그 뒤에 이어지는 콘텐츠들은 마치 하룻밤 사이에 조직 전체를 대체할 수 있는 것처럼 들리게 만듭니다. 도구가 문제는 아닙니다. 도구는 괜찮습니다.

문제는 해석 계층 (interpretation layer)입니다. 전문가(gurus)들은 설정 과정을 촬영하면서, 48개의 사전 구성된 에이전트 (agents)가 4시간마다 프론티어 모델 (frontier model) 위에서 깨어날 때 발생하는 비용에 대해서는 언급하지 않습니다. 월말에 그 비용이 얼마나 청구될지에 대해서도 말이죠. 혹은 23번 에이전트가 오염된 입력 (poisoned input)을 받았을 때, 나머지 47개가 그 출력값을 신뢰하게 되면 어떤 일이 벌어질지에 대해서도 말입니다.

왜 멀티 에이전트 AI (Multi-Agent AI)가 실제 운영 환경 (production)에서 실패하는가

조정 문제 (coordination problem)는 실재하며, 규모가 커질수록 악화됩니다. 멀티 에이전트 신뢰성에 관한 Galileo의 연구에 따르면, 에이전트를 추가할수록 실패 지점 (failure points)이 기하급수적으로 늘어납니다. 4개의 에이전트는 4개가 아니라 6개의 잠재적 실패 지점을 생성합니다. 10개의 에이전트는 45개를 생성합니다. 에이전트 간의 모든 핸드오프 (handoff)는 컨텍스트 (context)가 유실되거나, 지시 사항이 오해되거나, 출력이 손상되는 지점이 됩니다.

CIO는 2026년 3월, 진정한 멀티 에이전트 협업은 여전히 대체로 열망적인 단계에 머물러 있다고 보고했습니다. 그들의 테스트 결과, 단일 에이전트는 격리된 작업에서 100% 성공률을 기록한 반면, 계층적 멀티 에이전트 구조 (hierarchical multi-agent structures)는 64%의 확률로 실패했고, 자기 조직화된 스웜 (self-organized swarms)은 68%의 확률로 실패했습니다. 이것은 단순한 반올림 오차가 아닙니다. 그것은 근본적인 조정 비용 (coordination tax)입니다.

제가 직접 목격한 실패 모드 (failure modes)들은 다음과 같습니다:

목적 정의의 부재: 누군가 멋진 데모를 보았기 때문에 에이전트가 존재하는 것이지, 작업의 분해 (decomposition)가 필요해서 존재하는 것이 아닙니다. 도구가 잘 갖춰진 단일 에이전트가 프롬프트 (prompt)를 잘 작성했을 때, 잘못 조율된 5명의 팀보다 언제나 더 나은 성능을 보여줍니다.

역할 경계의 부재: 두 에이전트가 서로의 업무를 침범하거나, 더 나쁜 경우 한 에이전트가 다른 에이전트가 방금 수행한 작업을 되돌려 놓습니다. 엄격한 범위 설정 (scoping) 없이는 에이전트들이 루프 (loops) 속에서 논쟁하며, 아무것도 생산하지 못한 채 토큰 (tokens)만 태우게 됩니다.

연쇄 실패 (Cascade failures): 에이전트 A가

실패 패턴	발생하는 현상	규모 확장 시 영향
목적 정의 부재 (No purpose definition)	에이전트들이 작업을 수행하지만, 단일 에이전트로도 처리 가능한 수준임	비용은 배로 증가하나 품질은 정체됨
역할 경계 부재 (No role boundaries)	에이전트들이 서로의 작업을 중복하거나 되돌림	토큰 소모 (Token burn)가 에이전트 수에 따라 이차 함수적으로 증가함
연쇄 환각 (Cascade hallucination)	잘못된 출력이 체인을 통해 전파됨	단계(hop)마다 오류가 복합적으로 누적됨. 3개의 에이전트 = 3개 층의 복합 오류
컨텍스트 윈도우 초과 (Context window overflow)	공유된 컨텍스트가 모델의 한계를 초과하여 에이전트들이 맥락을 놓침	모든 에이전트의 출력이 다른 모든 에이전트를 위한 공유 컨텍스트를 팽창시킴
오케스트레이터 병목 (Orchestrator bottleneck)	단일 조정자 (coordinator)가 가장 취약한 연결 고점이 됨	오케스트레이터의 복잡도가 에이전트 수에 따라 $O(n^2)$로 증가함

아무도 보여주지 않는 API 청구서

스웜 (swarm) 내의 모든 에이전트는 하나의 API 호출입니다. 더 정확하게 말하면, 모든 에이전트는 초기 프롬프트 (prompt), 도구 호출 (tool calls), 재시도 (retries), 에이전트 간의 컨텍스트 공유 등 여러 번의 API 호출을 수행합니다. 최첨단 모델 (frontier model)에서 작동하는 5인 에이전트 팀은 단일 에이전트 비용의 5배가 아닙니다. 조정 오버헤드 (coordination overhead)를 고려하면 종종 1015배에 달합니다. Monetizely가 인용한 Stanford의 AI Index Report에 따르면, 성숙한 멀티 에이전트 시스템 (multi-agent systems)에서 조정 오버헤드만으로 전체 운영 비용의 1525%를 차지하는 것으로 나타났습니다. 이는 실제 작업 실행 비용을 계산하기 전의 수치입니다.

실제 계산 방식은 다음과 같습니다. 5개의 에이전트(연구원, 분석가, 작가, 편집자, 팩트 체크 담당자)로 구성된 '연구 및 작성 파이프라인'을 실행한다고 가정해 봅시다. 각 에이전트는 작업당 평균 3,000개의 입력 토큰 (input tokens)과 1,500개의 출력 토큰 (output tokens)을 사용합니다. 최첨단 모델을 사용할 경우, 에이전트당 작업당 비용은 약 $0.04입니다 (2026년 3월 기준 가격; 현재 제공업체의 요율을 확인하십시오). 5명의 에이전트라면 작업당 $0.20입니다. 저렴해 보이나요? 이제 재시도 (retries, 에이전트가 다른 에이전트의 출력에 동의하지 않아 다시 실행하는 경우)를 더해봅시다. 컨텍스트 공유 (context sharing, 모든 에이전트가 다른 에이전트가 생성한 내용을 확인해야 하므로 입력 토큰이 배수로 증가함)를 더해봅시다. 오케스트레이터의 오버헤드를 더해봅시다. 에이전트가 정교화를 위해 자기 자신을 호출하는 재귀적 사고 (recursive thinking)까지 더해봅시다. 실제 운영 환경에서 이 $0.20짜리 작업은 일상적으로 $0.80~$1.50가 됩니다.

하루에 100번 실행한다면 매일 $80~$150, 즉 월간 $2,400~$4,500의 비용을 보게 될 것입니다. 단 하나의 파이프라인(pipeline)만으로 말이죠. 전문가들은 결코 여러분에게 결제 대시보드(billing dashboard)를 보여주지 않습니다. 저는 오케스트레이터(orchestrator)가 잡아내지 못한 에이전트의 재시도 루프(retry loop)로 인해 단 하루 만에 비용이 4배로 급증하는 것을 직접 경험했습니다. 이것은 20분짜리 튜토리얼이 아니라, 실제 운영 환경(production)에서만 배울 수 있는 종류의 교훈입니다. 저는 자율 에이전트(autonomous agents)가 실제 운영 환경에서 실제로 얼마의 비용이 드는지, 그리고 멀티 에이전트(multi-agent) 환경에서 어떻게 이 문제가 복합적으로 발생하는지에 대해 더 자세히 작성했습니다.

아무도 말하지 않는 보안 문제 (The Security Problem Nobody's Talking About)
이 부분이 제가 진심으로 우려하는 지점입니다. 사람들은 GitHub에서 MCP 서버를 다운로드하고, 미리 만들어진 에이전트 빌더(agent builders)를 연결하며, 자신의 데이터를 라우팅하는 코드 한 줄도 감사(auditing)하지 않은 채 스웜(swarm)에 운영 데이터베이스, 파일 시스템, API에 대한 접근 권한을 부여하고 있습니다. CovertSwarm의 2026년 1월 분석에 따르면, 에이전트 간 통신(agent-to-agent communication)이 프롬프트 인젝션(prompt injection)을 통해 어떻게 악용될 수 있는지 드러났습니다. 즉, 탈취된 하나의 에이전트가 정교하게 만들어진 출력물을 통해 다른 에이전트의 행동을 조작하는 방식입니다. 멀티 에이전트 시스템에서는 단 하나의 탈취된 노드(node)가 스웜 전체로 조작을 확산(cascade)시킬 수 있습니다.

제가 끊임없이 목격하는 보안 격차(security gaps)는 다음과 같습니다:

1. 자격 증명 범위 제한(Credential scoping)의 부재: 모든 에이전트가 동일한 권한을 가진 동일한 API 키를 가집니다. 여러분의 리서치 에이전트가 운영 데이터베이스에 대한 쓰기 권한(write access)을 가지고 있고, 요약 에이전트(summarizer)가 이메일을 보낼 수 있습니다. 왜 그럴까요?
2. 출력 경계(Output boundaries)의 부재: 에이전트의 출력물이 다음 에이전트로 전달되기 전에 정화(sanitized)되지 않습니다. 이것이 프롬프트 인젝션이 전파되는 방식입니다. 리서치 결과에 포함된 악의적인 입력값이 다음 에이전트에게는 명령(instruction)이 됩니다.
3. 감사되지 않은 외부 도구(Unaudited external tools): GitHub 별점이 200개라는 이유로 다운로드한 그 MCP 서버 말입니다. 소스 코드를 읽어보셨나요? 여러분의 데이터를 어디로 전송하는지 알고 계십니까? 대부분의 사람들은 모릅니다. 대부분의 AI 도구는 여러분의 입력값과 LLM 사이에서 어떤 일이 일어나는지에 대해 투명성이 제각각인 래퍼(wrapper)일 뿐입니다.
4. 감사 추적(Audit trail)의 부재: 5개의 에이전트로 구성된 파이프라인에서 문제가 발생했을 때, 각 에이전트가 무엇을 보고, 무엇을 결정했으며, 무엇을 생성했는지 재구성할 수 있습니까?

대부분의 프레임워크는 기본적으로 그 정도의 세밀한 수준까지 로그를 남기지 않습니다.

실제로 작동하는 방식 (직접 구축해 본 사람의 관점)
저는 프로덕션 환경에서 멀티 에이전트 시스템 (Multi-agent system)을 운영하고 있습니다. 잘 작동합니다. 하지만 이는 프레임워크 튜토리얼을 따랐기 때문이 아니라, 첫날부터 특정 제약 사항들을 적용하여 구축했기 때문에 가능한 것입니다. 설계도를 공개하지 않는 선에서 제가 배운 것들을 공유하겠습니다.

목적부터 시작하십시오. 시스템 내의 모든 에이전트는 특정 작업이 필요하기 때문에 존재해야 합니다. 만약 단일 에이전트가 그 일을 수행할 수 있다면, 단일 에이전트가 수행하게 하십시오. 질문은 "에이전트를 얼마나 더 추가할 수 있는가?"가 아니라, "이 작업 분해 (Task decomposition)를 실제로 가치 있게 만드는 최소한의 에이전트 수는 몇 개인가?"가 되어야 합니다.

자율적이 아닌, 모니터링 하에 실행하십시오. 환상은 당신이 잠든 동안 에이전트들이 24시간 내내 완전히 스스로 돌아가는 것입니다. 현실은 모니터링되지 않는 에이전트들은 표류한다는 것입니다. 그들은 당신이 의도하지 않은 패턴을 만들어냅니다. 당신의 오케스트레이션 (Orchestration)이 처리하지 못하는 엣지 케이스 (Edge cases)를 찾아냅니다. 특히 초기에는 집중적으로 모니터링하십시오.

종료 날짜를 설정하십시오. 끝이 없는 방식이 아닌, 경계가 있는 실행 (Bounded execution)이어야 합니다. 에이전트 스웜 (Agent swarm)은 작업을 완료하고 멈춰야 합니다. "이 분석을 실행하고, 이 결과물을 생성한 뒤, 종료하라"라고 해야지, "내가 멈추라고 할 때까지 계속 실행하라"라고 해서는 안 됩니다. 끝이 없는 스웜은 비용과 표류가 복리로 쌓이는 곳입니다.

각 에이전트의 권한 범위를 제한하십시오. 모든 에이전트는 정확히 필요한 접근 권한만을 가져야 하며, 그 이상은 안 됩니다. 가능한 경우 읽기 전용 (Read-only)으로 설정하십시오. 공유 자격 증명 (Shared credentials)을 사용하지 마십시오. 만약 에이전트가 데이터베이스에 기록해야 한다면, 그것은 기본 설정이 아니라 경계가 설정된 의도적인 아키텍처 결정이어야 합니다.

연결하기 전에 모든 외부 도구를 감사 (Audit)하십시오. 모든 MCP 서버, 모든 API 통합, 모든 외부 데이터 소스를 확인하십시오. 코드를 읽고, 데이터 흐름을 이해하며, 신뢰 경계 (Trust boundaries)를 검증하십시오. 감사할 수 없다면 연결하지 마십시오.

이 모든 것의 밑바탕에 깔린 패턴은 다음과 같습니다: 멀티 에이전트 시스템은 모든 구성 요소를 이해하는 사람이 목적에 맞게 직접 구축했을 때 비로소 작동합니다.

이들은 "신뢰할 수 있는 프로덕션 시스템 (reliable production system)" 대신 "멋진 데모 (cool demo)"를 최적화하려는 사람들이 YouTube 튜토리얼을 보고 조립했을 때 실패합니다.

자주 묻는 질문 (Frequently Asked Questions)

멀티 에이전트 AI 시스템을 구축할 가치가 있나요?

• 네, 만약 작업이 전문화된 역할 간의 분해 (decomposition)를 진정으로 필요로 한다면 그렇습니다. 연구 파이프라인 (Research pipelines), 복잡한 분석 워크플로우 (complex analysis workflows), 그리고 별도의 기술 요구 사항이 있는 다단계 프로세스는 정당한 사용 사례입니다. 문제는 멀티 에이전트라는 개념 자체가 아닙니다. 잘 갖춰진 도구를 가진 단일 에이전트가 더 저렴하고, 더 신뢰할 수 있으며, 더 잘 수행할 수 있는 상황에서 멀티 에이전트를 기본 접근 방식 (default approach)으로 선택하는 것이 문제입니다.

멀티 에이전트 AI 시스템을 운영하는 데 비용이 얼마나 드나요?

• 모델, 에이전트 수, 작업 복잡도에 따라 다르지만, 멀티 에이전트 비용은 가산적 (additive)이지 않고 승수적 (multiplicative)입니다. 컨텍스트 공유 (context sharing), 재시도 (retries), 그리고 조정 오버헤드 (coordination overhead)를 고려하면, 프런티어 모델 (frontier model) 기반의 5개 에이전트 파이프라인은 작업당 단일 에이전트 비용보다 1015배 더 많이 들 수 있습니다. Monetizely를 통한 Stanford의 AI Index Report에 따르면, 조정 오버헤드만으로 운영 비용의 1525%를 차지한다고 추정합니다. 멀티 에이전트 배포를 계획할 때는 단일 에이전트 기준점의 최소 3~5배를 예산으로 책정하십시오.

AI 에이전트 스웜 (agent swarms)의 가장 큰 보안 리스크는 무엇인가요?

• 주요 리스크는 범위가 지정되지 않은 자격 증명 (unscoped credentials, 모든 에이전트가 최소 필요 권한 대신 전체 액세스 권한을 갖는 경우), 감사되지 않은 외부 도구 (소스 코드를 읽지 않은 MCP 서버 및 API 통합), 그리고 에이전트 간 프롬프트 인젝션 (agent-to-agent prompt injection, 탈취된 에이전트가 정교하게 조작된 출력을 통해 다른 에이전트를 조종하는 경우)입니다. CovertSwarm은 2026년 1월에 에이전트 간의 신뢰가 어떻게 악용될 수 있는지 기록했습니다.

멀티 에이전트 AI를 위해 CrewAI, AutoGen, 또는 LangGraph 중 무엇을 사용해야 하나요?

• 프레임워크 자체보다는 그 안에서 내리는 아키텍처 결정 (architecture decisions)이 더 중요합니다. 세 가지 모두 작동하는 멀티 에이전트 시스템을 만들 수 있지만, 세 가지 모두 비용이 많이 드는 실패를 초래할 수도 있습니다. 실제로 중요한 질문은 다음과 같습니다: 각 에이전트에 대한 명확한 목적이 있는가? 권한이 에이전트별로 범위가 지정되어 있는가? 모니터링 및 비용 제어 수단이 있는가?

모든 외부 통합 (external integration)을 감사 (audit)할 수 있습니까? 이 네 가지 질문 모두에 대해 '예'라고 답할 수 없다면, 프레임워크의 선택은 무의미합니다. 어떤 것을 선택하든 실패할 것입니다.

결론 (The Bottom Line): 에이전트 스워밍 (Agent swarms) 자체가 나쁜 것은 아닙니다. 검토되지 않은 스워밍이 나쁜 것입니다. 기술은 작동합니다. 저도 매일 사용합니다. 하지만 이 기술이 작동하는 이유는 모든 에이전트가 목적을 가지고 있고, 모든 권한이 범위가 지정되어 있으며, 모든 외부 도구가 감사되고, 전체 시스템이 제한된 실행 (bounded execution) 하에 모니터링되며 운영되기 때문입니다.

현재 논의의 간극은 기술적 역량이 아닙니다. 그것은 운영 성숙도 (operational maturity)입니다. 프레임워크는 점점 좋아지고 있습니다. 모델은 점점 저렴해지고 있습니다. 하지만 유포되는 조언들(