AI 에이전트 스웜 완벽 가이드: 플래너, 워커, 검증자

요약 (TL;DR)

AI 에이전트 스웜은 하나의 목표를 세 가지 역할로 나누어 처리합니다. 작업을 여러 세부 태스크로 쪼개는 기획자(Planner), 격리된 작업 공간에서 해당 태스크를 병렬로 구현하는 워커(Worker), 그리고 변경 사항이 최종 반영되기 전에 철저히 검증하는 검증자(Verifier)입니다. 기획자와 검증자에는 가장 성능이 뛰어난 최고 사양 모델을 배치하고, 워커에는 더 저렴하고 빠른 모델을 할당합니다. 이 아키텍처는 워커들이 동일한 파일을 동시에 수정하거나, 검증자가 기계적으로 승인(rubber-stamp)해 버리거나, 비용 상한선을 두지 않을 때 실패하게 됩니다.

AI 에이전트 스웜이 다시 주목받는 이유

Google이 Gemini 4 Carbon을 정식 출시(GA)하며 Google Antigravity의 /swarm 기능을 미리 공개했습니다. 이 기능은 단 하나의 프롬프트만으로 긴밀하게 조율되는 에이전트 팀을 구성해 줍니다. Google의 설명에 따르면, Carbon은 "아키텍처 설계, 조율 및 감사"를 담당하고, 여기에 "병렬로 격리된 작업 공간에서 동작하는 더 빠르고 가벼운 모델들과 모든 변경 사항을 꼼꼼히 테스트하는 적대적 검증자(adversarial verifier)"가 결합됩니다.

이 설명은 현재 보유하고 있는 모델만으로도 충분히 구현할 수 있는 아키텍처 패턴을 뜻합니다. 본 가이드에서는 세 가지 핵심 역할, 기획과 검증에 더 많은 예산을 투입해야 하는 이유, 스웜이 실패하는 원인, 그리고 공유 보드(Shared Board)를 기반으로 스웜을 운영하는 방법을 살펴봅니다. 이미 여러 코딩 에이전트를 운영 중이라면, Sharkly를 통해 각 에이전트에 태스크, 실행 로그, 코드 리뷰 단계를 지정할 수 있어 스웜 구축에 필요한 대부분의 기반을 즉시 확보할 수 있습니다.

AI 에이전트 스웜이란 무엇인가?

AI 에이전트 스웜은 하나의 목표를 독립된 작업 단위로 나누어 동시에 수행하는 AI 에이전트 그룹을 의미합니다. 한 에이전트가 전체 작업을 기획하고 할당하면, 여러 에이전트가 이를 병렬로 실행하며, 하나 이상의 에이전트가 병합(merge) 전에 각 결과물을 철저히 검증합니다. 각 역할은 명확한 담당 업무와 분명한 핸드오프(인수인계) 체계를 갖습니다.

Anthropic 역시 2024년에 이를 오케스트레이터-워커 패턴(orchestrator-workers pattern)으로 소개한 바 있습니다. 중앙 모델이 작업을 세분화하여 각 파트에 위임하고 최종 결과를 취합하는 방식입니다. 여기에 새로 추가된 핵심 요소가 바로 '검증자'이며, 실제로 많은 팀이 가장 놓치기 쉬운 역할이기도 합니다.

스웜은 단순히 "여러 에이전트가 동일한 작업을 중복 수행하는 것"이 아닙니다. 동일한 저장소에서 같은 프롬프트로 다섯 개의 에이전트를 실행하는 것은 팀워크가 아니라 레이스 컨디션(경합 상태)을 유발할 뿐입니다. 진정한 스웜을 만드는 핵심은 바로 명확한 역할 분담입니다. 에이전트 조율에 관한 전반적인 개념은 AI 에이전트 오케스트레이션이란 무엇인가를 참고하시기 바랍니다.

세 가지 핵심 역할: 기획자, 워커, 검증자

각 역할은 서로 다른 문제를 해결하며, 요구되는 컨텍스트 역시 다릅니다.

기획자는 어떤 역할을 하는가?

기획자는 모호한 목표를 서로 겹치지 않는 독립적인 태스크로 세분화합니다. 훌륭한 실행 계획은 각 태스크가 수정할 수 있는 파일 목록, 완료 여부를 증명할 테스트, 태스크 간 의존성에 따른 실행 순서를 명확히 정의합니다. 만약 두 태스크가 같은 파일을 수정해야 한다면, 기획자는 이를 하나의 태스크로 통합하거나 순차적으로 실행되도록 조율합니다.

워커는 어떤 역할을 하는가?

워커는 병렬로 각자에게 할당된 단 하나의 태스크만 집중해서 구현합니다. 각 워커에게는 독립적인 작업 공간이 주어지며, 일반적으로 동일한 저장소를 각자의 브랜치로 분리 체크아웃하는 git worktree 방식을 활용합니다. 이러한 격리 덕분에 세 명의 워커가 서로의 코드를 덮어쓰지 않고 동시에 코드를 수정할 수 있습니다. 자세한 내용은 격리된 워크트리에서의 병렬 에이전트 운영을 확인해 보세요.

검증자는 어떤 역할을 하는가?

검증자는 변경 사항의 허점과 결함을 적극적으로 찾아내는 역할을 합니다. Google이 표현한 "적대적(adversarial)"이라는 단어가 정확히 들어맞습니다. 검증자는 테스트를 실행하고 태스크 요구사항과 diff를 대조하며, 워커가 부적절한 편법을 쓰지 않았는지 철저히 조사합니다. 단순하게 "테스트가 통과했는가?"만 확인하는 검증자라면, 테스트 코드를 임의로 수정해 통과시킨 워커의 부정행위를 잡아낼 수 없습니다.

기획과 검증에 고성능 모델을 써야 하는 이유

기획과 검증은 읽는 양은 적지만 판단에 따른 리스크가 매우 큽니다. 반면 코드 구현은 출력량이 방대하지만 코드 한 줄당 리스크는 상대적으로 낮습니다. 이러한 비대칭 구조가 모델 배치를 결정하는 핵심 기준이 됩니다.

기획자가 작성하는 태스크 설명은 수백 줄 수준이며, 검증자가 내리는 판정 결과 역시 간결합니다. 두 역할 모두 출력 토큰 수가 적기 때문에 토큰당 단가가 높은 최고 사양 모델을 사용하더라도 전체 비용 부담은 적습니다. 반면 토큰의 대부분을 생성하는 주체는 워커이므로, 워커에 저렴한 모델을 배치해야 가장 큰 비용 절감 효과를 거둘 수 있습니다.

실수가 초래하는 파급력의 크기도 완전히 다릅니다. 잘못된 기획은 모든 워커를 엉뚱한 방향으로 몰고 가고, 부실한 검증자는 결함이 있는 모든 변경 사항을 그대로 통과시켜 버립니다. 반면 성능이 조금 떨어지는 워커가 만든 잘못된 diff는 검증자가 즉시 잡아낼 수 있습니다. 오류가 증폭될 위험이 큰 곳에 가장 뛰어난 추론 능력을 집중 투자해야 합니다.

Google의 모델 포지셔닝 역시 이러한 분업 체계를 뒷받침합니다. Google은 Gemini 4 Argon이 "소프트웨어 엔지니어링 및 지식 업무의 대부분을 처리하는 데 여전히 이상적인 선택"인 반면, Carbon은 "광범위한 탐색, 심층 추론, 확장된 검증 루프를 수행하기 위해" 더 많은 토큰을 활용한다고 설명합니다. Carbon의 가격은 2026년 11월 30일까지 입력 백만 토큰당 2달러, 출력 백만 토큰당 10달러이며, 이후에는 각각 4달러와 20달러로 인상됩니다. 자세한 모델 스펙은 코딩 에이전트를 위한 Gemini 4 Carbon 및 코딩 에이전트를 위한 Gemini 4 Argon 글을 참고하세요. 동일한 원리가 다른 모델 조합에도 그대로 적용됩니다. 저비용 워커와 고성능 리뷰어를 조합한 혼합 모델 크루(Crew) 구성에서 확인해 보세요.

AI 에이전트 스웜이 실패하는 지점

스웜에서 발생하는 대부분의 장애는 상태 공유, 취약한 검증 체계, 예산 미설정이라는 세 가지 빈틈에서 비롯됩니다.

에이전트들이 왜 서로의 코드를 덮어쓰는가?

기획 단계에서 파일 소유권을 엄격히 제한하지 않으면 두 워커가 같은 파일을 동시에 건드리게 됩니다. 격리된 작업 공간이 없다면 나중에 저장한 파일이 이전 작업을 덮어써 버려 먼저 작업한 워커의 변경 사항이 흔적도 없이 사라집니다. 작업 공간을 격리하더라도 두 변경 사항은 병합 시점에 결국 충돌(conflict)을 일으킵니다. 해결책은 기획 단계에 있습니다. 태스크별로 파일 소유권을 명확히 지정하고, 동일한 파일을 공유하는 태스크는 반드시 순차적으로 실행되도록 직렬화해야 합니다.

검증자가 왜 기계적으로 승인(rubber-stamp)해 버리는가?

실제 diff를 보지 않고 워커가 작성한 작업 요약본만 검토하는 검증자는 실제 작업 결과물이 아니라 워커의 일방적인 주장에 점수를 매기는 것과 다름없습니다. "모든 테스트 통과"라는 문구만 보고 그대로 승인해 버리는 것입니다. 검증자에게는 워커의 자체 보고서가 아니라 원본 diff와 실제 테스트 실행 출력을 제공해야 합니다. 또한 워커와 동일한 사각지대를 공유하지 않도록 검증자는 워커와 서로 다른 모델로 실행하는 것이 좋습니다. 검증 에이전트가 검증할 수 있는 영역과 한계에 대해서는 AI 코드 리뷰 에이전트 포스팅을 확인하세요.

스웜 비용은 어떻게 폭증하는가?

검증에서 반려될 때마다 빌드와 리뷰가 처음부터 다시 실행되므로, 3번 실패한 태스크 하나는 각각 4배의 비용을 소모합니다. 10개의 워커가 밤새 무한 반려 루프에 빠지면 일주일 치 예산이 순식간에 날아갈 수 있습니다. 태스크당 재시도 횟수 제한(2회가 합리적인 기본값), 동시 실행 워커 수 제한을 설정하고, 마지막 재시도까지 실패한 태스크는 즉시 사람에게 넘기도록 설계해야 합니다.

또 다른 숨겨진 위험도 있습니다. 기획, 실행, 판정 내역이 단 하나의 컨텍스트 창 안에서만 처리된다면 외부에서 그 결과를 사후 감사할 수 없습니다. 따라서 스웜의 외부에서 이를 지속적으로 감시할 외부 감독 장치가 반드시 필요합니다.

공유 보드를 활용해 AI 에이전트 스웜을 운영하는 방법

스웜을 운영하기 위해 별도의 전용 스웜 툴이 꼭 필요한 것은 아닙니다. 태스크, 격리된 작업 공간, 그리고 승인 게이트(Gate)만 있으면 충분합니다. 공유 보드(Shared Board)는 이 세 가지를 모두 제공하면서 사람이 진행 상황을 한눈에 파악할 수 있는 기록 보관소 역할도 해줍니다.

1. 최종 목표를 담은 상위 태스크(Parent Task)를 생성합니다. 기획자가 이를 확인하고 각 파일 목록과 인수 테스트가 포함된 하위 태스크(Subtask)들로 계획을 수립합니다.
2. 각 워커에게 정확히 하나의 태스크만 배정합니다. 태스크 하나당 하나의 에이전트, 하나의 브랜치를 매칭합니다. 두 하위 태스크가 동일한 파일을 공유한다면 작업 착수 전에 먼저 하나로 통합합니다.
3. 각 태스크를 독립된 디렉터리에서 실행합니다. 실행 단위마다 워크트리(worktree)를 분리해 두면 병렬 수정 작업 간의 간섭을 원천 차단할 수 있습니다.
4. Done 단계 직전에 Review 상태를 추가합니다. 워커의 말만 믿고 태스크를 바로 완료(Done) 상태로 전환해서는 안 됩니다.
5. 더 강력한 고성능 모델의 검증자 에이전트에게 리뷰를 할당합니다. 검증자는 diff와 테스트 결과를 면밀히 살펴본 뒤 태스크를 승인하거나 명확한 사유와 함께 반려합니다.
6. 마지막 관문에는 사람을 배치합니다. 검증자가 검토 목록을 압축해 주면, 최종 결과 승인은 사람이 직접 수행합니다.

Sharkly 환경에서는 이 과정이 다음과 같이 구현됩니다. 크루(Crew)는 리더 에이전트의 지휘 아래 사람과 에이전트가 함께 협업하는 재사용 가능한 팀 단위입니다. 상위 태스크를 크루에 할당하면 리더가 가장 먼저 실행됩니다. 리더가 태스크를 파악한 뒤 특정 파트별로 팀원 에이전트를 투입하고 그 결과를 종합합니다. 이러한 '선 리더 기획' 순서 덕분에 계획이 완성되기 전에는 어떤 워커도 섣불리 작업을 시작하지 않습니다.

임시 작업 디렉터리 모드로 동작하는 에이전트는 태스크마다 격리된 디렉터리를 할당받으며, 저장소 기반 작업은 새로운 워크트리를 준비해 병렬 워커 간 파일 충돌을 방지합니다. 각 에이전트는 사용자가 설정한 런타임 환경에서 실행되므로, 리더와 검증자는 워커보다 더 강력한 모델로 유연하게 구성할 수 있습니다.

리뷰 게이트는 태스크 워크플로 내 하나의 상태로 관리됩니다. 에이전트는 사람의 검토가 필요한 상태로 태스크를 넘겨둘 수 있으며, 이 핸드오프 내역은 에이전트 태스크 실행 문서에 나온 것처럼 메인 사이드바의 'Task Chats' 모듈에 실시간 표시됩니다. 실패하거나 차단된 실행 건 역시 인박스(Inbox)로 전달됩니다. 에이전트는 조사, 실행, 테스트 및 보고를 담당하고, 사람은 방향 설정, 권한 승인, 최종 결과 검수를 담당합니다. Sharkly는 무료로 시작할 수 있습니다. 컴퓨터 한 대를 연결하고 두 개의 에이전트를 생성한 뒤, 작은 작업부터 크루에 맡겨보세요. 인간 중심의 검토 설계에 대한 자세한 내용은 병렬 에이전트 환경에서 인간 리뷰 병목 해소하기를 참고하시기 바랍니다.

AI 에이전트 스웜이 필요하지 않은 경우

작업을 여러 개로 분할하기 어려운 경우에는 굳이 스웜을 사용할 필요가 없습니다. 단일 버그 픽스, 단일 파일 리팩터링, 혹은 길고 연속적인 추론 체인이 필요한 작업은 강력한 단일 에이전트 한 대와 한 명의 리뷰어로 진행하는 편이 훨씬 빠릅니다. 독립된 태스크 수가 세 개 미만인 경우, 오케스트레이션에 드는 조율 비용이 병렬화로 얻는 이점보다 커지기 마련입니다.

반면 서로 다른 파일을 수정해야 하는 다수의 작업으로 쪼개질 때는 스웜이 큰 위력을 발휘합니다. 멀티 패키지 마이그레이션, 모듈 전반에 걸친 테스트 코드 보강, 10개 서비스에 동시 적용해야 하는 API 스펙 변경 등이 대표적입니다. Google 역시 다중 에이전트 환경에서 Carbon이 탁월한 성과를 내는 대표적인 작업 유형으로 '멀티 패키지 마이그레이션'과 '하위 시스템 간 근본 원인 분석'을 꼽았습니다.

마치며

AI 에이전트 스웜은 거대한 단일 프롬프트가 아니라 기획, 구현, 검증이라는 세 가지 명확한 직무의 결합체입니다. 가장 뛰어난 모델은 기획과 판정에 집중시키고, 저렴한 모델은 코드 구현에 투입하며, 모든 결과물은 사람이 쉽게 검토할 수 있는 투명한 공간에 보관하세요. 상위 태스크 하나, 세 명의 워커, 그리고 한 명의 검증자로 시작해 보시기 바랍니다. 보유 중인 에이전트로 이러한 아키텍처를 바로 구축해 보고 싶다면, 지금 Sharkly에 컴퓨터를 연결하고 첫 번째 크루를 배정해 보세요.

자주 묻는 질문 (FAQ)

에이전트 스웜과 멀티 에이전트 오케스트레이션의 차이점은 무엇인가요?

오케스트레이션은 여러 에이전트를 조율하는 전반적인 방식과 프로세스를 아우르는 포괄적인 개념입니다. 스웜은 기획자, 병렬 워커, 검증자라는 고정된 역할을 기반으로 하는 구체적인 오케스트레이션 패턴 중 하나입니다. 즉, 모든 스웜은 오케스트레이션되지만, 모든 오케스트레이션이 스웜인 것은 아닙니다.

AI 에이전트 스웜은 몇 개의 에이전트로 구성하는 것이 이상적인가요?

기획자 1대, 워커 3대, 검증자 1대로 시작하는 것을 권장합니다. 태스크가 완벽히 독립적으로 유지되고 리뷰 대기열이 밀리지 않고 원활히 소화될 때에만 워커를 추가하세요. 리뷰 역량을 초과해 워커만 무작정 늘리는 것은 병목 지점을 검증자에게로 떠넘길 뿐입니다.

기획자와 검증자를 동일한 에이전트로 구성해도 되나요?

동일한 LLM 모델을 사용할 수는 있지만, 반드시 컨텍스트가 분리된 개별 세션으로 나누어 실행해야 합니다. 기획자가 자신이 세운 계획의 산출물을 직접 리뷰하면 편향이 생겨 그대로 승인해 버리기 쉽습니다. 독립된 새 검증자가 기획자의 선입견 없이 객관적으로 diff를 검토해야 결함을 제대로 짚어낼 수 있습니다.

에이전트 스웜을 운영하려면 Google Antigravity가 반드시 필요한가요?

아닙니다. /swarm은 Antigravity에 내장된 프리뷰 기능일 뿐이며, 스웜 패턴의 핵심은 작업 분할, 격리된 작업 공간, 그리고 검증 단계의 존재 여부입니다. git worktree와 칸반 보드만 있다면 현재 사용 중인 어떤 코딩 에이전트로도 직접 구현할 수 있습니다.

스웜 워커들이 동일한 파일을 동시에 수정하지 않도록 어떻게 방지하나요?

기획 단계에서 태스크별 파일 소유권을 엄격히 분배하여 작업 범위가 겹치지 않게 하고, 격리된 작업 공간을 통해 병합 전까지 각 워커의 수정 사항이 각자의 브랜치에만 머물도록 합니다. 여기에 CODEOWNERS 규칙을 함께 도입하면 리뷰 시점에도 이중 점검이 가능합니다.