[!IMPORTANT] 한 줄 브리핑: Google Antigravity Teamwork는 여러 AI 에이전트가 역할을 나눠 장기 과제를 제안·비판·검증하는 방식이다. 업무 적용 전 비용, 검증 기준, 중단 조건을 먼저 설계해야 한다.
분야: IT/AI/Security
30초 요약
- 무슨 기능인가: Google Antigravity의 Teamwork는 여러 AI 에이전트가 하나의 장기 연구·개발 과제를 함께 수행하도록 조정하는 다중 에이전트 오케스트레이션 기능이다.
- 어떻게 작동하나: 과제에 따라 코딩, 증명, 자체 검증, 문서 검토 같은 패턴을 선택하고, 에이전트들이 해법을 제안한 뒤 서로 비판하고 개선하는 흐름을 구성한다.
- 사람의 역할: 목표와 평가 기준을 정하고, 실행 중 에이전트 수와 팀 구조를 조정하며, 최종 결과를 승인한다.
- 업무 적용 포인트: 단순 질문·요약보다 장시간 탐색이 필요한 설계 검토, 코드 변경안 비교, 기술 문서 검증에 적합하다.
- 가장 큰 주의점: 에이전트 수가 늘면 품질이 자동으로 보장되는 것이 아니다. 입력 자료, 검증 절차, 종료 조건, 비용 상한을 함께 관리해야 한다.
무슨 일인가
Google Antigravity Teamwork는 여러 AI 에이전트를 한 팀처럼 운영하는 기능으로 소개됐다. 여기서 에이전트는 사용자의 지시에 따라 자료를 분석하거나 코드를 작성하고, 결과를 다시 평가하는 작업 단위다. 한 에이전트가 모든 일을 순서대로 처리하는 대신, 여러 에이전트가 서로 다른 역할을 맡아 같은 과제를 병렬 또는 반복적으로 다루는 방식이다.
입력 자료에 따르면 Teamwork는 Google I/O에서 처음 공개된 Antigravity의 다중 에이전트 오케스트레이션 프레임워크다. 장기 연구와 소프트웨어 엔지니어링 문제를 대상으로 하며, 과제 특성에 맞춰 다음과 같은 작업 패턴을 선택할 수 있다고 설명된다.
- 코딩: 구현안을 만들고 실행 가능한 결과를 구성
- 증명: 주장의 근거와 논리적 연결을 확인
- 자체 검증: 생성된 결과를 다른 기준으로 다시 점검
- 문서 검토: 요구사항, 설계 문서, 기술 설명의 누락과 모순을 검토
이 구조의 핵심은 단순한 역할 분담이 아니다. 한 에이전트가 낸 결과를 다른 에이전트가 비판하고, 그 비판을 반영해 다시 개선하는 피드백 루프에 있다. 사람은 모든 중간 작업을 직접 수행하기보다 목표, 제약 조건, 검증 방법을 지정하고 주요 판단 지점에서 개입하는 형태를 취한다.
Antigravity 공식 사이트는 이 제품을 대규모 엔터프라이즈 코드베이스에서 일하는 개발자부터 개인적으로 코딩하는 사용자까지 고려한 도구로 소개하며, 사용자 신뢰를 강조한다. 다만 공식 사이트에 표시된 내용만으로 Teamwork의 구체적인 내부 구현, 모델별 성능, 모든 사용 조건을 확인할 수는 없다.
공개된 실험 수치를 읽는 법
Devlery의 관련 글은 teamwork-preview를 사용해 93개 서브에이전트와 2.6B 토큰으로 운영체제 데모를 만든 사례를 다룬다. 이 수치는 다중 에이전트 작업이 매우 큰 규모로 구성될 수 있음을 보여주는 사례로 볼 수 있다. 그러나 특정 과제에서 사용한 구성과 비용을 일반적인 프로젝트의 예상치로 바꿔 해석해서는 안 된다.
즉, “에이전트를 많이 투입하면 같은 결과를 얻을 수 있다”거나 “장기 과제는 항상 사람보다 저렴하다”는 결론은 입력 자료만으로 확인되지 않는다. 사례의 재현 조건, 실제 비용 산정 방식, 결과 품질, 사람이 투입한 검토 시간은 별도로 검증해야 한다.
왜 중요한가
1. 단일 답변형 AI의 한계를 작업 흐름으로 보완한다
짧은 질문에 답하는 방식은 빠르지만, 복수의 가설을 비교하거나 긴 문맥을 유지하면서 구현과 검증을 반복하는 업무에는 별도의 운영 구조가 필요하다. Teamwork 방식은 “답을 한 번 생성”하는 대신 다음 흐름을 만들 수 있다는 점에서 의미가 있다.
- 문제를 작은 작업으로 분해한다.
- 서로 다른 접근법을 제안한다.
- 각 접근법의 약점을 찾는다.
- 실행 또는 문서 근거로 결과를 확인한다.
- 기준을 통과한 결과를 통합한다.
이 흐름은 기술 선택, API 설계, 테스트 계획, 마이그레이션 검토처럼 정답 하나를 즉시 알기 어려운 과제와 잘 맞는다.
2. 병렬화보다 ‘독립적인 검토’가 핵심이다
여러 에이전트가 같은 지시를 복사해 수행하면 작업 수만 늘고 오류가 반복될 수 있다. 실무에서 중요한 것은 에이전트 수 자체가 아니라 각 에이전트가 서로 다른 관점과 검증 책임을 갖는지다.
예를 들어 코드 변경을 검토할 때 다음 역할은 서로 다른 실패를 발견할 가능성이 있다.
- 구현 담당: 요구사항에 맞는 코드 작성
- 테스트 담당: 정상·예외·경계 조건에 대한 테스트 제안
- 보안 검토 담당: 권한, 입력값, 민감정보 노출 점검
- 문서 담당: 변경 이유와 사용 방법 정리
- 통합 담당: 충돌을 정리하고 최종 기준 충족 여부 판단
이런 역할 구분은 사람 팀의 코드 리뷰와 비슷해 보이지만, AI 에이전트가 낸 결과도 독립적인 증거와 실행 결과를 통해 확인해야 한다는 점이 다르다.
3. 비용과 운영 복잡성이 품질 문제로 이어질 수 있다
Devlery 글에서 언급된 93개 에이전트와 2.6B 토큰 사례는 규모가 커질수록 비용과 관리 문제가 함께 커질 수 있음을 보여준다. 에이전트가 많아지면 결과를 합치는 작업, 중복 실행 방지, 실패한 작업의 재시도, 최종 책임 소재도 복잡해진다.
따라서 실무 도입의 질문은 “몇 개의 에이전트를 사용할까?”보다 다음에 가까워야 한다.
- 이 과제는 병렬 작업으로 분해할 수 있는가?
- 각 단계의 완료 조건을 자동 또는 사람이 확인할 수 있는가?
- 실패했을 때 어디서 중단할 것인가?
- 추가 실행에 사용할 비용과 시간을 제한했는가?
- 최종 결과를 승인할 담당자가 있는가?
업무에 어떻게 쓸까
처음부터 장기 자율 실행을 맡기기보다, 검토 범위가 분명하고 결과를 되돌리기 쉬운 과제에서 작은 실험으로 시작하는 것이 좋다. 아래 절차는 특정 제품 화면이나 명령어에 의존하지 않는 운영 템플릿이다.
1단계: 과제를 ‘완료 가능한 단위’로 다시 쓴다
“서비스를 개선해 달라”처럼 넓은 요청은 에이전트 팀이 무엇을 끝내야 하는지 판단하기 어렵다. 다음 항목을 먼저 문서로 고정한다.
- 목표: 무엇을 바꾸거나 판단할 것인가
- 범위: 이번 작업에서 다루지 않을 영역은 무엇인가
- 입력: 저장소, 문서, 로그, 정책 등 사용 가능한 자료
- 산출물: 코드, 비교표, 테스트 결과, 의사결정 문서 등
- 성공 기준: 통과해야 할 기능·품질·정책 조건
- 금지 조건: 삭제, 외부 공개, 운영 배포 등 허용하지 않는 행동
- 종료 조건: 성공, 실패, 시간 초과, 비용 상한 중 무엇으로 끝낼 것인가
예를 들어 “인증 모듈을 개선하라” 대신 “현재 인증 모듈의 오류 처리 흐름을 조사하고, 변경안 두 개와 테스트 계획을 제안하되 운영 코드에는 직접 반영하지 않는다”처럼 작성하면 검토 가능한 결과가 된다.
2단계: 역할을 결과물 기준으로 나눈다
역할은 직함이 아니라 산출물로 정의한다. 다음은 설계 검토에 사용할 수 있는 예시다.
과제: 기존 결제 모듈의 재시도 정책 검토
역할 A - 현황 분석
- 관련 코드와 문서를 찾아 현재 흐름을 요약한다.
- 확인하지 못한 자료와 가정을 별도로 표시한다.
역할 B - 대안 설계
- 서로 다른 재시도 전략을 최소 2개 제안한다.
- 각 전략의 장점, 위험, 변경 범위를 비교한다.
역할 C - 반대 검토
- 역할 A와 B의 주장 중 근거가 약한 부분을 찾는다.
- 장애, 중복 처리, 데이터 일관성 관점의 질문을 만든다.
역할 D - 검증 계획
- 각 대안을 구분할 테스트 조건을 작성한다.
- 실제 실행이 불가능한 검증은 그 이유를 표시한다.
통합 역할
- 확인된 사실, 추정, 미해결 쟁점을 구분한다.
- 최종 권고와 보류 조건을 한 문서로 정리한다.이렇게 하면 에이전트들이 같은 결론을 반복해서 생성하는 것을 줄이고, 결과를 비교할 수 있다. 실제 Teamwork 환경에서 가능한 역할 수와 실행 방식은 별도 확인이 필요하다.
3단계: 먼저 ‘읽기 전용’으로 실행한다
첫 실험에서는 파일 수정, 삭제, 배포, 외부 시스템 변경을 허용하지 않는 편이 안전하다. 저장소를 분석하고 변경 후보와 테스트 계획만 출력하게 하면 다음을 확인할 수 있다.
- 에이전트가 실제 입력 자료를 읽었는가
- 존재하지 않는 파일이나 정책을 가정하지 않았는가
- 서로의 검토 결과가 반영됐는가
- 통합 결과에 출처와 불확실성이 표시됐는가
- 불필요하게 작업을 확장하지 않았는가
읽기 전용 실행에서 품질이 확인된 뒤에만 제한된 샌드박스나 별도 브랜치에서 코드 변경을 허용한다. 운영 환경에 직접 연결하는 것은 별도의 승인 절차와 권한 설계가 필요하다.
4단계: 평가표를 실행 전에 만든다
결과를 본 뒤 기준을 바꾸면 여러 에이전트가 낸 문서 중 마음에 드는 것을 고르는 수준에 머물 수 있다. 아래처럼 사전에 평가표를 작성한다.
| 평가 항목 | 확인 질문 | 판정 방식 |
|---|---|---|
| 사실성 | 입력 자료로 확인되는 주장인가? | 근거 링크 또는 파일 위치 확인 |
| 완전성 | 요구한 산출물이 모두 있는가? | 체크리스트 |
| 검증성 | 실행·재현 가능한 확인 방법이 있는가? | 테스트 또는 재현 절차 |
| 일관성 | 코드, 문서, 결론이 서로 모순되지 않는가? | 교차 검토 |
| 안전성 | 권한·민감정보·운영 영향이 통제되는가? | 사람 승인 |
| 비용·시간 | 정한 상한 안에 끝났는가? | 실행 기록 확인 |
점수만 합산하지 말고, 안전성이나 사실성처럼 반드시 통과해야 하는 항목을 별도로 둔다. 한 항목에서 실패하면 다른 항목의 높은 점수로 상쇄하지 않는 방식이 적절하다.
5단계: 실행 중 조정과 종료를 규칙으로 만든다
Teamwork는 실행 중 에이전트 수와 팀 구조를 조정할 수 있는 기능으로 설명된다. 이를 임의로 늘리는 대신 다음 규칙을 정해 둔다.
- 동일한 결론이 독립 검토에서 반복되면 추가 탐색을 줄인다.
- 서로 다른 결론이 나오면 에이전트를 늘리기 전에 쟁점을 좁힌다.
- 근거가 없는 결과가 반복되면 새 에이전트보다 입력 자료를 보완한다.
- 비용 또는 시간 상한에 도달하면 자동 종료하고 미해결 목록을 남긴다.
- 결과가 운영 변경을 요구하면 AI 실행을 멈추고 사람 승인 단계로 넘긴다.
핵심은 “더 많은 에이전트”를 품질 향상의 기본 해법으로 삼지 않는 것이다. 과제가 분해되지 않거나 평가 기준이 모호하면 에이전트 수를 늘려도 불확실성만 확대될 수 있다.
한계와 주의점
입력 자료만으로 확인되지 않는 내용
현재 제공된 자료만으로는 다음 사항을 확정할 수 없다.
- Teamwork의 정확한 공개 범위와 모든 사용자에게 제공되는 조건
- 실제 인터페이스, API, 권한 모델, 로그·감사 기능의 세부 동작
- 사용되는 모델의 정확한 구성과 과제별 성능
- 93개 에이전트·2.6B 토큰 실험의 전체 비용 산정 기준과 결과 재현성
- 일반적인 개발 과제에서의 품질 향상률, 시간 절감률, 비용 절감률
- 장기 실행 중 발생한 오류율, 중단율, 사람 검토에 필요한 시간
따라서 위 항목은 제품 문서, 실제 실행 기록, 조직의 보안·비용 정책으로 추가 검증해야 한다. 특히 공개 사례의 숫자를 사내 프로젝트 예산이나 생산성 목표로 바로 적용해서는 안 된다.
결과를 서로 검증했다고 해서 사실이 되지는 않는다
여러 에이전트가 같은 잘못된 전제를 공유하면 상호 비판이 충분히 독립적이지 않을 수 있다. 원본 문서, 테스트 실행, 정적 분석, 담당자의 검토처럼 AI 바깥의 확인 수단을 함께 사용해야 한다. “세 에이전트가 동의했다”는 사실은 “주장이 사실이다”와 같은 의미가 아니다.
권한은 최소화하고 변경은 되돌릴 수 있게 한다
코드 저장소, 파일 시스템, 사내 문서, 배포 환경에 연결할 때는 과제에 필요한 최소 권한만 부여한다. 초기 단계에서는 읽기 전용 자료와 격리된 테스트 환경을 사용하고, 변경이 필요하면 별도 브랜치나 복사본에서 수행한다. 운영 배포, 데이터 삭제, 외부 공개, 결제·권한 변경은 AI의 자동 실행 대상에서 제외하고 사람 승인을 요구하는 것이 안전하다.
민감정보와 기밀자료를 먼저 분류한다
장기 연구나 코드 검토 과제는 많은 파일과 문서를 읽을 수 있으므로, 개인정보·접근 토큰·고객 데이터·내부 전략 문서가 입력에 포함되는지 먼저 확인해야 한다. 어떤 자료가 어디로 전달되고 얼마나 보존되는지는 제공된 자료만으로 알 수 없다. 조직 정책과 제품의 데이터 처리·보존 조건을 확인하기 전에는 민감한 자료를 실험에 넣지 않는 편이 낫다.
실무 도입을 위한 최소 체크리스트
- 목표·범위·산출물·종료 조건을 문서화했는가?
- 역할마다 독립적인 결과물이 정의됐는가?
- 읽기 전용 또는 샌드박스에서 먼저 시험했는가?
- 사실성·안전성·재현성 평가 기준을 사전에 정했는가?
- 에이전트 수, 실행 시간, 비용의 상한을 정했는가?
- 운영 변경 전에 사람 승인 단계를 두었는가?
- 확인된 사실과 추정을 최종 문서에서 구분했는가?
- 실패했을 때 남길 로그와 미해결 쟁점을 정했는가?
결론적으로 Teamwork의 실무 가치는 에이전트를 많이 동원하는 데 있지 않다. 장기 과제를 작은 작업으로 나누고, 서로 다른 관점으로 검토하며, 실행 가능한 증거를 기준으로 통합하는 운영 체계를 만드는 데 있다. 기능을 시험할 때도 먼저 짧고 되돌릴 수 있는 과제로 시작한 뒤, 비용과 검증 품질이 확인될 때만 범위를 넓히는 접근이 현실적이다.