[Antigravity #9] AI 팀장님 되기: 나만의 AI 개발팀 꾸리기 (Multi-Agent)
Editor’s Note
혼자 일하면 빠르지만, 큰일은 못 합니다.
지금까지는 AI 한 명(Single Agent)과 일했다면, 이제는 여러 명의 전문 에이전트를 부려봅시다.
프론트엔드 담당, 백엔드 담당, QA 담당… 여러분은 코딩하는 사람이 아니라 ‘CTO’가 되는 겁니다.
1. 왜 여러 명이 필요한가요?
“홈페이지 만들어줘”라고 하면 너무 막연하잖아요? 사람도 디자이너, 퍼블리셔, 서버 개발자가 따로 있듯이 AI도 역할(Role)을 나눠주면 훨씬 잘합니다.
- Front-Agent: 화면만 깎음 (React, CSS 장인)
- Back-Agent: API만 만듦 (DB, 서버 장인)
- Tester-Agent: 버그만 찾으러 다님
Antigravity에서는 이들을 동시에 출근시킬 수 있습니다.
멀티 에이전트의 장점은 속도만이 아닙니다. 서로 다른 관점으로 같은 작업을 검토하게 만들 수 있다는 점이 더 큽니다. 구현 담당 에이전트는 “되게 만드는 것”에 집중하고, 테스트 담당 에이전트는 “어디서 깨질지”를 보게 만들면 사람이 혼자 볼 때 놓치는 부분을 줄일 수 있습니다.
다만 역할이 겹치면 오히려 혼란이 생깁니다. 시작 전에 아래 세 가지를 정해두세요.
- 각 에이전트가 담당할 파일 또는 영역
- 서로 건드리면 안 되는 경계
- 통합 전에 제출해야 할 산출물
2. 실전: 게시판 만들기 프로젝트
매니저 뷰에서 이렇게 업무 분장을 해봅시다.
Step 1: Backend Agent에게 지시
1
@Backend "게시글(Post) CRUD API를 만들어. Express랑 SQLite 써서."
(백엔드 에이전트가 server.js와 db.js를 만드는 동안…)
Step 2: Frontend Agent에게 지시 (동시에!)
1
2
@Frontend "지금 백엔드 애가 API 만들고 있거든?
너는 그것만 기다리지 말고 일단 게시판 목록이랑 글쓰기 UI부터 React로 짜놔."
네, 동시에 일합니다. 화면이 분할되면서 왼쪽엔 서버 코드가, 오른쪽엔 UI 코드가 짠! 하고 생겨납니다. 여러분은 가운데서 다리(Bridge) 역할만 하면 됩니다.
동시에 진행할 때는 API 계약을 먼저 정해야 합니다.
1
2
3
4
5
공통 계약:
- GET /api/posts: 게시글 목록
- POST /api/posts: 게시글 생성
- 응답 형식: { id, title, body, createdAt }
- 에러 형식: { message }
이 계약이 없으면 Frontend Agent는 임의의 응답을 가정하고, Backend Agent는 다른 필드명을 만들 수 있습니다. 그러면 나중에 “둘 다 열심히 했는데 안 붙는” 상황이 됩니다.
Step 3: 통합 (Integration)
“@Frontend, 이제 백엔드 API 다 됐대. 연동해봐.”
통합 단계에서는 Tester Agent를 따로 호출하는 것이 좋습니다.
1
2
@Tester 게시글 목록 조회, 글 작성, 새로고침 후 유지 여부를 확인해.
실패하면 재현 단계와 관련 파일 후보를 정리해서 보고해.
이렇게 하면 구현 에이전트가 자기 코드의 문제를 스스로 합리화하는 일을 줄이고, 더 객관적인 검증 흐름을 만들 수 있습니다.
3. Manager’s Mindset (팀장의 자세)
멀티 에이전트를 쓸 때 여러분이 코드를 직접 짜면 안 됩니다. 조율(Orchestration)을 해야 합니다.
- ❌ 하수: “여기 CSS
color: red로 바꿔줘.” -
⭕ 고수: “@Frontend, 3번 버튼 색깔이 @Design-System 규칙이랑 안 맞아. 수정해.”
- ❌ 하수: “이거 에러 뭐야?”
- ⭕ 고수: “@Tester, 지금 로그인 안 된다는데 원인 분석해서 @Backend한테 리포트 넘겨.”
서로 대화하게 시키세요. 그게 진정한 오케스트레이션입니다.
실무에서는 “누가 무엇을 했는지”를 남기는 것도 중요합니다. 멀티 에이전트 작업이 끝나면 각 에이전트에게 짧은 인수인계 메모를 요구하세요.
1
각자 변경한 파일, 실행한 검증, 남은 위험 요소를 5줄 이내로 보고해.
리뷰할 때는 이 메모를 기준으로 diff를 확인하면 됩니다. 변경 파일이 많을수록 이런 요약이 없으면 사람이 전체 맥락을 놓치기 쉽습니다.
4. 멀티 에이전트 실패 패턴
여러 에이전트를 쓰면 무조건 좋아질 것 같지만, 잘못 쓰면 충돌만 늘어납니다.
| 실패 패턴 | 해결 방법 |
|---|---|
| 여러 에이전트가 같은 파일을 동시에 수정 | 담당 파일과 경계를 먼저 나누기 |
| API 계약 없이 프론트/백을 따로 구현 | 엔드포인트와 응답 형식을 먼저 합의 |
| 검증 없이 결과만 합침 | Tester Agent를 독립적으로 투입 |
| 사람이 중간 결정을 하지 않음 | 설계 변경, 보안, 삭제 작업은 직접 승인 |
멀티 에이전트의 목표는 사람을 완전히 빼는 것이 아니라, 사람이 더 높은 수준의 결정을 하도록 반복 작업을 나누는 것입니다.
5. 오늘의 요약
- 큰 프로젝트는 혼자 하지 말고 @Front, @Back 에이전트를 나눠서 시킨다.
- 병렬 작업 전에는 담당 영역, API 계약, 산출물을 먼저 정한다.
- 구현 에이전트와 검증 에이전트를 분리하면 리뷰 품질이 좋아진다.
자, 이제 Antigravity의 모든 것을 배웠습니다. 마지막 [Antigravity #10] 에서는 영원한 라이벌 Claude Code와 계급장 떼고 붙어보겠습니다. 과연 2026년의 최강자는 누구일까요?