4,972
코딩 에이전트 여러 개가 동시에 일한다면 무엇을 먼저 정해야 할까요? 이번 글에서는 에이전트의 수보다 각자 바꿀 범위, 공유할 기록, 완료를 판단할 증거에 집중합니다.
Google은 2026년 11월 10일 Antigravity의 /swarm preview를 발표했습니다.[2332] 같은 날 공개 범위를 넓힌 Gemini 4 Carbon과 함께 소개했지만, 이 글의 주제는 새 모델의 순위가 아니라 여러 에이전트의 일을 조율하는 방식입니다.[2331][2332]
💡 💡 핵심:
/swarm은 작업을 나누고, 이름 있는 worker와 verifier가 공유 보드에서 협업하는 기능입니다.[2333] 여기서 가져갈 설계 기준은 “병렬 실행”, “작업 사본 분리”, “검증”을 각각 확인하는 것입니다.
/swarm은 Google Antigravity App과 CLI에서 여러 에이전트를 하나의 작업에 투입하는 명령입니다.[2333] 사용자가 요청하면 현재 대화는 coordinator가 되고, 일을 나누어 worker에게 맡기고 돌아온 결과를 판단합니다.[2333]
Worker는 각자의 대화에서 작업하고, 담당 범위와 완료 조건을 적은 brief를 받습니다.[2333] Verifier는 diff를 읽고 테스트를 실행해 문제를 구현 담당자에게 되돌립니다.[2333] 단순히 terminal을 여러 개 여는 것과 달리 작업 배분과 상호 피드백이 기능의 일부입니다.[2333]
현재 문서는 /swarm을 Google AI Pro·Ultra의 App·CLI 기능으로 안내합니다.[2333] 한편 출시 발표에서 Carbon 모델의 Antigravity 이용 경로는 Ultra 구독자로 안내합니다.[2332] /swarm 기능을 쓸 수 있는지와 Carbon 모델을 선택할 수 있는지는 같은 조건으로 보지 않아야 합니다.
Coordinator는 파일·패키지처럼 서로 겹치지 않는 단위로 작업을 나눕니다.[2333] Worker의 brief에는 무엇을 맡는지, 무엇을 건드리면 안 되는지, 무엇을 완료로 보는지가 들어가며, 다른 구성원도 보드에서 읽을 수 있습니다.[2333]
편집 제안: “API를 개선해 주세요”보다 “이 handler와 인접 테스트만 수정하고, 공용 schema 변경이 필요하면 먼저 질문하세요”처럼 경계를 적는 편이 좋습니다. 이 기준은 다른 코딩 에이전트에 작업을 맡길 때도 활용할 수 있습니다.
작업 지시, 구성원 간 질문, diff 요약, 테스트 결과는 하나의 보드에 올라가며 @name 같은 mention으로 상대를 부릅니다.[2333] 공식 발표는 이를 append-only message board라고 설명합니다.[2332] 개별 worker의 결과를 coordinator만 받아 다시 전달하는 방식과 구분되는 부분입니다.[2332]
App의 Board·Members·Graph에서는 게시물, 구성원 상태, mention 관계의 시간 흐름을 확인할 수 있습니다.[2333] CLI에서는 /swarm board로 보드를 엽니다.[2333] 다만 대화가 잘 보이는 것과 코드가 올바른 것은 별개라는 기준을 유지해야 합니다.
문서는 보통 worker 2~4개당 verifier 한 개를 추가한다고 설명합니다.[2333] Verifier는 코드 변경과 테스트를 확인하고, 발견한 문제를 해당 worker에게 전달합니다.[2333]
Worker의 기본 모델은 현재 대화와 같습니다.[2333] 다른 모델로 검증하고 싶다면 요청에 명시해야 하며, 선택 가능한 모델이어야 합니다.[2333] 공식 문서 예제는 다른 모델의 verifier에게 기존 테스트가 약해지지 않았는지 확인하고 race detector를 실행하도록 요청합니다.[2333]
이 구조는 오류를 찾아볼 역할을 추가하는 방법이지, 서로 다른 모델의 동의만으로 정확성을 보증하는 방법으로 받아들여서는 안 됩니다. 실제 diff와 테스트 결과를 완료 판단에 사용하자는 것이 이 글의 해석입니다.
출시 블로그는 worker가 격리된 Git worktree에서 일하는 구성을 강조합니다.[2332] 하지만 현재 사용 문서는 worker가 기본적으로 workspace를 공유하며, 동시 편집·빌드 시 coordinator가 각자 별도의 저장소 사본을 줄 수 있다고 설명합니다.[2333]
💡 ⚠️ 따라서
/swarm을 실행했다는 이유만으로 작업 사본이 자동 분리됐다고 가정하지 마세요. 발표의 대표 구성과 사용 문서의 기본값이 다르므로, 병렬 편집을 맡기기 전에 실제 작업 경로와 분리 여부를 확인하는 것이 안전합니다.[2332][2333]
편집 제안: 파일 소유권과 작업 사본을 모두 지정하세요. 사본이 달라도 공용 API의 의미를 다르게 바꿀 수 있으므로, 최종 통합된 결과에 대한 검증도 완료 조건에 넣습니다. 이는 이 글의 설계 제안이며 제품의 자동 충돌 해결을 보장하는 설명이 아닙니다.
공식 문서에는 사용자·주문·상품 API handler의 입력 검증을 각각 다른 worker에게 맡기고, verifier가 전체 diff와 테스트를 확인하는 예제가 있습니다.[2333] 반대로 같은 핵심 파일 하나를 계속 고쳐야 한다면, 먼저 작업을 나눌 실익이 있는지 판단하는 편이 좋습니다.
아래는 그 예제에서 확장한 제안 시나리오입니다. 실제 프로젝트에서 실행한 결과가 아닙니다.
제안 요청문: /swarm으로 위 세 handler의 입력 검증을 나누어 진행해 주세요. 각 worker의 수정 범위와 금지 범위를 보드에 적고, 동시에 수정한다면 별도 작업 사본을 사용해 주세요. 공용 schema 변경은 먼저 제안해 주세요. 기존 assertion을 삭제하거나 약화하지 말고, verifier가 통합 결과를 검사해 주세요. 최종 보고에는 변경 파일, 실제 실행한 테스트와 결과, 남은 문제를 구분해 주세요.
공식 문서의 패키지별 테스트 수리 예제도 assertion을 삭제하지 않게 하고, 각 worker가 통과를 보고한 뒤 verifier가 전체 suite를 다시 실행하는 흐름을 제시합니다.[2333] 위 요청문의 작업 범위·중단 조건은 여기에 덧붙인 편집 제안입니다.
대기 중인 구성원은 mention을 기다리는 동안 토큰을 사용하지 않으며, 전체가 조용해졌는데 일이 끝나지 않았다면 @monitor가 진행을 촉구합니다.[2333] 그러나 quota가 소진된 구성원은 한도가 갱신됐다고 자동 재시작하지 않습니다.[2333] 새 보드 게시물이나 모델 변경, 사용자 메시지 같은 계기가 필요합니다.[2333]
편집 제안: 최종 답변에서 “worker들이 끝났습니다”만 확인하지 말고, 어떤 통합 상태를 검사했는지와 미해결 사항을 읽으세요. 대기·중단·완료를 한 종류의 상태로 취급하지 않는 것이 중요합니다.
Antigravity 팀은 내부에서 여러 패키지의 migration, 하위 시스템을 가로지르는 원인 조사, 복잡한 아키텍처 재설계에 /swarm을 사용했다고 보고했습니다.[2332] 이는 제공자 내부 사용 보고이며, 외부 조직의 독립 비교시험은 아닙니다.
Google의 Carbon 발표에는 역사 사진과 공학 도판을 바탕으로 에펠탑 건설 과정을 보여 주는 Three.js 전시를 /swarm으로 만들었다는 데모도 있습니다.[2331] 이 글은 발표의 설명을 확인했지만 해당 앱을 실행하거나 코드 품질을 검증하지 않았습니다. 따라서 데모를 일반적인 개발 속도나 운영 품질의 증거로 확대하지 않습니다.
Hacker News의 drivebyhooting은 /boost·/teamwork·/swarm의 차이를 물으며, 기존 Argon의 복잡한 요청에서 편법을 발견했고 /teamwork****가 도움이 됐지만 더 오래 걸렸다는 개인 경험을 썼습니다.[2337] 다른 참여자 p_l은 Argon과 Flash를 나누어 쓰는 기존 teamwork 구성에서 어느 정도 성과를 얻었다고 보고했습니다.[2337]
둘 다 새 /swarm을 재현 시험한 기록은 아닙니다. 여기서 확인한 것은 개발자들이 작업 분할·검토·시간 부담을 실제 문제로 논의한다는 점이지, 새 기능의 성공이나 결함이 입증됐다는 사실이 아닙니다.
같은 날 토스가 공개한 Agent Platform 설계기는 OpenSandbox로 Workspace Pod를 관리하고, bubblewrap으로 하네스의 파일·통신 접근을 제한하는 구성을 설명합니다.[2334] 또한 접근 범위를 제한하는 것과 작업 결과가 정확한지 확인하는 것은 다르다고 명시합니다.[2334]
토스 사례는 Antigravity 사용 사례가 아닙니다. 작업 사본을 나누는 문제와 실행 권한을 제한하는 문제를 구별하기 위한 비교 자료입니다. 편집 관점에서 /swarm의 workspace 설명만으로 보안 격리까지 검증됐다고 읽지 않는 편이 안전합니다.
/boost가 문서의 구분입니다.[2333]/swarm을 검토합니다.[2333]/teamwork가 문서의 별도 선택지입니다.[2333]이 비교는 공식 문서의 적용 조건과 이 글의 단순성 우선 권고를 정리한 것입니다. 어느 방식이 항상 더 빠르거나 저렴한지는 측정하지 않았습니다.
무료 대기는 무료 실행이 아닙니다. /swarm은 preview이고, worker 각각이 별도 에이전트이므로 일반 대화보다 quota를 훨씬 빠르게 소비한다고 문서와 발표가 경고합니다.[2332][2333]
작업자 제거는 정리 전에 확인해야 합니다. 문서에 따르면 worker를 제거하면 해당 작업 사본도 삭제하므로, 변경을 먼저 반영하도록 합니다.[2333] 완료 보고만 보고 사본을 지우기보다 변경 보존 여부를 확인하세요.
명령·문서와 실제 환경은 구분합니다. 이 글은 2026-11-11 KST에 읽은 공식 발표와 live 문서 기준입니다. 제품을 설치하거나 /swarm을 실행하지 않았고, 설치 버전별 지원·자체 작업의 비용·한국어 협업 품질·장시간 안정성은 검증하지 않았습니다. 새 /swarm의 독립 재현 사용기와 구체적인 실패 보고도 이번 조사에서는 확보하지 못했습니다.
💡 🔬 검증 범위: 공식 자료 기반의 동작 해설이며 독립 성능 검증이 아닙니다. 발표와 문서의 workspace 기본값 차이를 본문에 남겼고, 공식 데모·제공자 내부 사례·기존 기능의 개인 사용기·설계 제안을 구분했습니다.
/swarm 협업의 출발점입니다.[2333][2331] https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-carbon-now-available — Gemini 4 Carbon is now available [2332] https://antigravity.google/blog/gemini-4-carbon-in-google-antigravity — Gemini 4 Carbon and /swarm — official announcement [2333] https://antigravity.google/docs/swarm — Swarm (/swarm) — live official documentation [2334] https://toss.tech/article/agent-platform-foundation — 토스: 실행은 격리하고, 세션은 이어간다 [2337] https://news.ycombinator.com/item?id=50442303 — Hacker News: Carbon launch discussion — user reports, not independent testing