AIREITER하나의 증명에 Lean 4 코드 5,000만 줄, 2주 만에 안전한 Rust 코드 80만 줄, TPU 커널 성능 4.09배 향상. 11월 13일 공개된 Google의 연구 업데이트는 Antigravity Teamwork가 어디까지 해낼 수 있는지 보여줍니다. 다만 Teamwork는 몇 시간에서 며칠씩 이어지는 마일스톤 프로젝트에서만 대체로 제값을 합니다. 한 번 실행해도 주간 쿼터의 상당 부분을 소모할 수 있기 때문입니다.
Antigravity Teamwork는 정확히 무엇인가
Antigravity Teamwork는 Antigravity 안에서 규모가 크고 검증이 중요한 작업을 처리하기 위한 Google의 멀티 에이전트 오케스트레이션 워크플로입니다. /teamwork 명령을 실행하면 Sentinel, Project Orchestrator, Explorers, Workers, Critic, Challenger, Auditor, Success Auditor로 구성된 팀이 만들어집니다. 이 팀은 마일스톤 단위로 계획을 세우고 전용 프로젝트 디렉터리에서 작업하며, 각 마일스톤을 독립적인 검증 절차로 통과시킨 뒤 다음 단계로 넘어갑니다.
Teamwork는 두 단계로 진행됩니다. 1단계는 범위 설정 인터뷰입니다. 메인 에이전트가 목표, 요구사항, 검증 방법, 승인 기준, 프로젝트 디렉터리(기본값 ~/teamwork_projects/{PROJECT_NAME})를 기록합니다. 2단계에서는 요청서, 프로젝트 계획, 진행 기록 같은 구조화된 산출물을 바탕으로 자율 실행이 이어집니다. Worker와 Critic, Challenger, Auditor, Success Auditor가 파일 소유권과 검증 게이트를 나눠 맡으며, 각 게이트를 통과해야 다음 단계로 인계됩니다(Teamwork 문서).
인터뷰 중 설정하는 무결성 모드는 검증 강도를 결정합니다.
development(기본값): 빠른 반복 작업에 적합합니다. 기존 코드와 프레임워크는 사용할 수 있지만, 조작된 결과나 외관만 갖춘 구현은 허용하지 않습니다.demo: 재현 가능한 시연을 위한 모드입니다. 오픈소스에서 핵심 로직을 그대로 복사하거나, 핵심 작업을 외부에 맡기거나, 답을 찾기 위해 테스트 소스 코드를 읽는 행위가 금지됩니다.benchmark: 가장 엄격한 모드입니다. 해당 언어의 표준 라이브러리만 사용해 처음부터 구현하고, 독립적인 기준 데이터로 결과를 평가합니다.
실행 경로에 따라 팀 구성도 자동으로 달라집니다.
- 일반 분산 코딩(기본값): 여러 파일을 다루는 엔지니어링과 리팩터링
- 반복 코딩: 프롬프트에 "keep it small"처럼 범위를 작게 유지하라는 요구가 있는 단일 수정 작업
- Document Review: 논문과 설계 문서를 여러 관점에서 검토
- Math / Proof 및 Math / Proof Large Team: 형식적 추론과 대규모 추측 검증 작업
일반적인 작업 시간은 유료 플랜의 Antigravity App과 CLI에서 몇 시간에서 며칠 정도입니다(Teamwork 문서).
Teamwork, Swarm, Boost, 서브에이전트는 어떻게 다른가
마일스톤과 감사 게이트, 전용 디렉터리가 모두 필요한 작업이라야 Antigravity Teamwork를 선택할 이유가 있습니다. 일상적인 작업 대부분은 더 가벼운 도구로 충분합니다. 잘못 고르면 필요 이상으로 쿼터만 소모합니다.
| 도구 | 적합한 작업 | 실행 방법 | 작업 공간 | 검증 방식 | 일반적인 작업 시간 | 플랜 |
|---|---|---|---|---|---|---|
| 서브에이전트 | 저장소 조사, 브라우저 확인, 테스트 실행 같은 집중형 보조 작업 | 자동 실행 또는 @subagent | 현재 작업 공간 | 상위 에이전트가 응답 확인 | 수 초~수 분 | 모든 플랜 |
Boost (/boost) | 경쟁 조건, 까다로운 버그, 알고리즘처럼 어렵지만 범위가 좁은 문제 | /boost <task>로 즉시 시작 | 현재 작업 공간, 격리된 컨텍스트 | Worker가 서로 도전하고 재검증하며 오케스트레이터가 표본 검사 | 수 초~수 시간 | 유료 플랜 |
Swarm (/swarm) | 파일, 패키지, 테스트 모음처럼 깔끔하게 분할할 수 있는 광범위한 작업 | /swarm <task>로 즉시 시작 | 현재 작업 공간 또는 Worker별 복사본 | 전담 @verifier가 diff를 검토하고 테스트 실행 | 수 분~수 시간 | Google AI Pro 및 Ultra |
Teamwork (/teamwork) | 마이그레이션, 시뮬레이션, 형식 증명 같은 다중 마일스톤 프로젝트 | /teamwork <goal> 실행 후 범위 설정 인터뷰 | 전용 ~/teamwork_projects/{PROJECT_NAME} | Critic, Challenger, Auditor, Success Auditor 게이트 | 수 시간~수 일 | 유료 플랜 |
수십 개 파일에 걸친 REST-to-Fastify 마이그레이션과 전체 테스트 커버리지, 하드웨어 타이머로 검증하는 사이클 정확도 시뮬레이터, Lean 4로 검사하는 형식 증명에는 Teamwork가 어울립니다. 반면 독립적인 API 핸들러 3개에 검증 로직을 추가하고 Worker 한 명씩 파일을 맡긴 뒤 npm test를 실행하는 정도라면 Swarm이 낫습니다. 단일 경쟁 조건이나, 병렬 Worker보다 순차적인 도전-수정-검증 과정이 효과적인 결합 리팩터링에는 Boost를 쓰면 됩니다. 메인 대화를 계속 진행하면서 배경 조사를 맡길 때는 서브에이전트가 적합합니다.
혼란스러울 만합니다. 한 Antigravity 사용자는 이렇게 말했습니다.
"agy has way too many modes now and honestly it's getting confusing. right now we have ... /teamwork (long milestone projects with audit gates) ... and now dynamic workflows... to be fair, we really don't need all of them. fewer modes = less confusion..."
— @Heamanth_alturi (X)
간단한 기준은 이렇습니다. 완료 조건이 하나이고 한 번에 끝나는 작업이라면 Teamwork는 과합니다. 계획 산출물과 진행 산출물이 필요하고, 각 마일스톤마다 작성자와 다른 사람이 승인해야 한다면 Teamwork가 맞습니다.
11월 연구 업데이트가 실제로 보여준 것
11월 13일 공개된 Google Research 업데이트는 출시 공지가 아니라 성과 보고서입니다. Teamwork는 그보다 앞서 유료 플랜에서 /teamwork-preview라는 이름으로 제공되고 있었고, 이번 업데이트는 Gemini 4 Argon, Carbon, Hydrogen을 활용한 마일스톤 기반 팀이 어떤 결과를 냈는지 소개합니다. 문제와 제약 조건, 평가 환경은 사람이 정했고, 독립적인 Critic은 깨끗한 컨텍스트에서 결과를 다시 검토했습니다.
| 분야 | 프로젝트 예시 | 에이전트 구성 | 보고된 결과 |
|---|---|---|---|
| 수학 | Courtade–Kumar 추측 증명(Google, CUHK, USC, CMU) | 장기 증명 패턴, Lean 4 형식화 | Lean 코드 약 5,000만 줄 규모의 완전한 증명 |
| 화학 | NMR 데이터에서 분자 구조 도출 | 전문화 에이전트 30개와 물리 시뮬레이터 | top-1 정확도 95%, top-3 정확히 일치 100% |
| 시스템 | Zircon C++-to-Rust 재작성 | Argon을 활용한 2주 캠페인 | 안전한 Rust 코드 약 80만 줄, arm64 부팅 성공 |
| ML 하드웨어 | TPU 커널 최적화(DuoDiscover) | 프록시 평가기(23초 대 7~32분) | 17개 JAXBench 커널에서 평균 4.09배 속도 향상 |
Google은 학술 연구자 10,000명을 대상으로 6개월간 최상위 액세스를 제공하는 신청도 받기 시작했습니다. 다만 게시물에 소개된 일부 워크플로는 외부 사용자에게 아직 순차적으로 배포되는 중입니다. 따라서 표의 결과는 기능의 가능성을 보여주는 근거로 봐야 하며, 모든 프로젝트에서 동일한 성과가 재현된다는 보장은 아닙니다.
공식 페이지에 드러나지 않는 쿼터 비용
Antigravity 가격 페이지에 따르면 Individual은 월 0달러이며 Tab 자동 완성은 무제한으로 제공되지만 기본 주간 한도가 있습니다. Pro와 Ultra는 더 높은 한도와 유연한 AI 크레딧 풀을 제공하지만, 정확한 요청 횟수는 공개하지 않습니다. Pro와 Ultra 쿼터는 주간 한도에 도달하기 전까지 5시간마다 갱신되며, 초과분은 구매한 크레딧으로 처리하도록 Never 또는 Always 설정을 선택할 수 있습니다(플랜 문서). Teamwork와 Boost는 유료 플랜이 필요하고, Swarm은 Pro 또는 Ultra에서만 사용할 수 있습니다(Swarm 문서). Google의 자체 OS 개발기에서도 복잡한 프리뷰 작업 두 번 정도만으로 주간 쿼터 전체를 소모할 수 있다고 경고했습니다(Antigravity OS 게시물).
대표성을 보장할 수 없는 사용자 경험담이지만, 실제 사용 보고는 부담이 적은 경우부터 심각한 경우까지 편차가 큽니다.
"holy crap that sucked all my quota in about only 5 minutes (3.5 Flash (high))"
— u/Several_Bag_3665 (Reddit)
"very usable on ultra sub actually, had a teamwork preview with gemini flash medium going for 50 minutes straight and it took about 20% of my 5-hour quota and did huge refactorings properly"
— u/ningkaiyang (Reddit)
이처럼 차이가 나는 이유는 두 가지입니다. Antigravity는 /swarm 문서에서 각 Worker가 별도의 에이전트로 동작하고, 대기 중인 Worker는 토큰을 소모하지 않으며, 쿼터가 바닥난 Worker는 새 보드 게시물이나 모델 변경, 다이렉트 메시지가 올 때까지 자동 재시도 없이 일시 정지한다고 설명합니다(Swarm 문서). Teamwork 문서에는 동일한 재개 동작이 명시되어 있지 않으므로, 이를 모든 멀티 에이전트 작업에 공통된 동작으로 단정하지 말고 사용하는 플랜에서 직접 확인해야 합니다. 또한 Teamwork는 요청서, 계획서, 진행 기록뿐 아니라 에이전트별 임시 메모와 검증 로그까지 대량으로 생성합니다(Teamwork 문서). 이런 파일은 정상적인 상태 기록이지, 반드시 실질적인 진척을 의미하는 것은 아닙니다.
주간 쿼터를 날리지 않고 첫 Teamwork 실행하기
Teamwork 실행 자체는 명령 한 줄이면 되지만, 실제 비용은 범위 설정 인터뷰에서 결정됩니다. App에서는 프로젝트 대화를 열고 /teamwork Migrate our REST API service from Express to Fastify, including full test coverage, TypeScript typing, and benchmark validation을 입력합니다. CLI에서는 프로젝트 디렉터리에서 /teamwork Design and implement a cycle-accurate memory controller with lockstep simulation tests를 실행하면 됩니다. 서브에이전트 패널이나 CLI 상태 표시줄에서 진행 상황을 확인하고, Alt+J로 승인 항목으로 이동할 수 있으며, 계획과 진행 산출물도 실시간으로 살펴볼 수 있습니다(Teamwork 문서).
비용을 통제하려면 1단계를 대충 넘기지 마세요. 구현 방법보다 무엇을 만들지 명확히 적어야 합니다. 목표와 대상(데모, 프로덕션, 벤치마크), 반드시 지켜야 할 제약 조건, 그리고 테스트 모음이나 측정 스크립트처럼 요구사항마다 하나씩 대응하는 객관적인 검사 방법을 지정하세요. 반복 개발에는 development를 선택하고, 결과를 보여줘야 하거나 처음부터 구현했다는 증명이 중요한 경우에만 demo나 benchmark를 사용하세요. 검증이 엄격할수록 에이전트 작업량도 늘어납니다. 승인하기 전에 전용 프로젝트 디렉터리도 확인해야 합니다.
실행 중에는 조율을 중앙에서 관리하세요. 범위 변경은 코디네이터를 통해 전달하고, Worker를 제거하기 전에는 해당 Worker의 변경 사항을 반영해야 합니다. 파일 개수보다 마일스톤 게이트와 테스트 증거를 기준으로 진척을 판단하는 것도 중요합니다. 첫 실행에서는 Settings의 AI 크레딧 초과 사용을 Never로 설정하세요. 기본 쿼터가 소진되면 크레딧을 조용히 쓰는 대신 작업을 멈추게 할 수 있습니다(플랜 문서). 플랜 문서에서 허용한다면 더 강한 플래너와 저렴한 구현 모델을 조합하는 방법도 있습니다. Ultra는 Orchestrator(Carbon)와 Orchestrator(Argon)를 지원하며, Gemini 4 Carbon 또는 Argon이 계획을 세우고 Gemini 4 Hydrogen이 구현을 맡습니다(가격 페이지). 이는 Carbon과 Argon 비교에서도 확인할 수 있는 트레이드오프입니다.
FAQ
/teamwork와 /teamwork-preview의 차이는 무엇인가요?
/teamwork-preview는 초기 리서치 프리뷰에서 사용하던 이름입니다. 현재 Teamwork 문서는 유료 플랜에서 /teamwork를 사용한다고 안내합니다. Google은 별도의 정식 출시 공지는 공개하지 않았습니다.
쿼터가 소진된 뒤 Teamwork를 일시 정지하거나 복구할 수 있나요?
문서에 명시된 /swarm의 동작은 쿼터가 소진된 Worker가 새 보드 게시물, 모델 변경, 다이렉트 메시지가 올 때까지 일시 정지하는 방식입니다(Swarm 문서). Teamwork 문서에는 동일한 재개 경로가 확인되어 있지 않습니다. 다시 시작하기 전에 ~/teamwork_projects/{PROJECT_NAME}의 플랜과 진행 산출물을 확인하세요. 완료되지 않은 마일스톤도 파일 형태로 남아 있기 때문입니다.
Teamwork는 어떤 산출물을 생성하나요?
요청서, 프로젝트 계획서, 진행 기록과 함께 에이전트별 임시 메모, 보조 스크립트, 검증 로그를 생성합니다(Teamwork 문서). Markdown 파일이 많이 생기는 것은 정상입니다. 진척 여부는 파일 개수가 아니라 마일스톤 게이트와 테스트 증거로 판단하세요.
프로덕션 저장소에서 Teamwork를 사용해도 안전한가요?
Teamwork는 전용 디렉터리에서 작업을 격리하고, 파일별 소유권과 감사 게이트를 적용해 충돌 위험을 낮춥니다(Teamwork 문서). 그래도 병합 전에는 승인 기준, 테스트 증거, 최종 Success Auditor 결과를 사람이 직접 검토해야 합니다.
/teamwork를 입력하기 전 30초 체크리스트
다섯 가지 조건을 모두 만족할 때만 /teamwork를 입력하세요. 작업이 여러 마일스톤으로 나뉘고, 각 마일스톤에 객관적인 검사가 있으며, 전용 디렉터리가 도움이 되고, 독립적인 감사 게이트가 중요하며, 쿼터를 많이 쓰는 한 번의 실행이 몇 주간의 수작업보다 저렴해야 합니다. 그렇지 않다면 병렬 처리가 가능한 폭넓은 작업에는 Swarm, 어렵지만 범위가 좁은 버그에는 Boost, 배경 보조 작업에는 서브에이전트를 사용하세요. Teamwork는 정말 팀이 필요한 프로젝트를 위해 남겨두면 됩니다.