실전 유즈케이스 3 — 엔터프라이즈: Agent Manager로 여러 워크스페이스를 운영하기
엔터프라이즈에서 개발 속도를 갉아먹는 건 대개 "키보드 타이핑 속도"가 아닙니다. 더 흔한 병목은 전환 비용입니다. 이슈 트래커를 보다가, 로컬을 켜고, 로그를 뒤지고, 누가 무엇을 했는지 따라가고, 또 다른 저장소로 넘어가고, 마지막에는 리뷰 컨텍스트를 다시 세팅하는 비용이 누적됩니다.
Antigravity가 '에이전트-퍼스트'로 강조하는 지점은 여기입니다. 개발자가 더 높은 작업 단위에서, 여러 워크스페이스를 가로지르며 에이전트를 운영하도록 설계됐다는 점입니다.1 이때 Agent Manager는 "코드를 쓰는 화면"이라기보다 일을 올리고(지시), 진행을 보고(관찰), 증거를 확인해(검증), 병합을 승인하는(결정) 운영 화면이 됩니다.1
이 챕터의 목표는 단순합니다.
여러 에이전트를 동시에 돌려 유지보수·버그픽스·장기 작업을 병렬화한다.
그 과정에서 사람이 하는 일은 "구현"이 아니라 전환 비용을 줄이는 운영이 되도록 만든다.
엔터프라이즈에서 '병렬화'의 진짜 목적: 코드를 나누는 게 아니라 컨텍스트를 지킨다
병렬화는 개발자를 "더 바쁘게" 만들기 위한 게 아닙니다. 오히려 반대입니다. 사람이 동시에 세 가지를 붙잡으면 품질이 떨어지고 실수만 늘어납니다. 엔터프라이즈 병렬화의 목적은 사람의 컨텍스트를 보호하는 데 있습니다.
Agent Manager에서 병렬로 돌리는 건 '사람'이 아니라 '에이전트'입니다. 문서가 말하듯 Antigravity는 로컬 비동기 에이전트가 여러 워크스페이스에서 병렬로 일할 수 있는 구성을 핵심 기능으로 둡니다.1 즉, 사람은 하나의 의사결정 흐름(우선순위→승인→병합)을 유지하고, 에이전트가 여러 갈래의 실행을 동시에 진행하도록 만드는 게 정답입니다.
여기서 전환 비용을 줄이는 핵심 원리는 세 가지입니다.
첫째, 일을 큐(대기열)로 만든다. "생각나는 대로 처리"가 아니라, 들어오는 작업을 표준 형태로 받고, 분류하고, 배치한다.
둘째, 작업을 인터페이스로 쪼갠다. 기능을 쪼개라는 말이 아니라, "에이전트가 건드려도 되는 범위"와 "사람이 판단해야 하는 경계"를 명확히 하라는 뜻입니다.
셋째, 검증을 결과물(Artifacts)로 고정한다. 구두 보고가 아니라, 리뷰 가능한 증거가 있어야 운영이 확장됩니다.1
운영의 기본 단위: '워크스페이스 × 에이전트' 매트릭스
엔터프라이즈 환경에서는 저장소가 하나가 아닙니다. 모놀리식이라도 모듈이 많고, 마이크로서비스라면 당연히 코드베이스가 분리됩니다. Antigravity는 "여러 코드베이스에 걸쳐 여러 에이전트를 오케스트레이션하고 모니터링"하는 그림을 전제로 합니다.1
여기서 실무적으로 중요한 건, 워크스페이스를 '프로젝트 폴더'가 아니라 '운영 경계'로 정의하는 일입니다.
워크스페이스를 나누는 3가지 기준
워크스페이스 분리는 곧 충돌 가능성을 줄이는 일입니다. 다음 기준 중 하나라도 해당하면, 별도 워크스페이스로 분리하는 편이 운영이 쉬워집니다.
배포 단위가 다르다. 같은 PR로 같이 배포되지 않는다면, 에이전트를 함께 돌릴 이유가 없습니다.
권한/비밀이 다르다. 운영 키, 고객 데이터, 내부 정책 문서처럼 접근 통제가 다르면 분리해야 합니다.
검증 루프가 다르다. 한쪽은
npm test가 핵심이고, 다른 쪽은 스테이징에서 클릭 검증이 핵심이면, 같은 실행 흐름으로 묶으면 전환 비용이 다시 생깁니다.
에이전트는 '사람의 역할'이 아니라 '운영 슬롯'이다
엔터프라이즈에서 에이전트를 사람처럼 이름 붙이고 성격을 부여하는 건 재미있지만, 규모가 커지면 유지되지 않습니다. 대신 에이전트를 운영 슬롯(slot) 으로 생각하세요.
슬롯은 "무슨 일을 하는지"가 아니라 "어떤 형태의 일을 받는지"로 정의합니다.
슬롯은 교체 가능해야 합니다. 사람이 바뀌어도 운영이 유지되도록, 입력/출력 형태가 고정돼야 합니다.
예를 들어 '버그 픽스 슬롯'은 다음을 항상 요구하도록 표준화할 수 있습니다.
재현 절차
원인 가설
최소 수정 diff
회귀 테스트 또는 검증 아티팩트
이렇게 정의하면, 어떤 이슈가 들어와도 사람이 다시 컨텍스트를 세팅하는 시간이 줄어듭니다.
Agent Manager 운영 루프: 계획(Plan)보다 '배치(Batch)'가 먼저다
소규모 팀에서는 계획을 잘 세우는 것만으로도 충분합니다. 하지만 엔터프라이즈의 현실은 일감이 끊임없이 들어온다는 점입니다. 계획을 예쁘게 그려도, 중간에 인시던트 한 번 터지면 전부 깨집니다.
그래서 Agent Manager 운영의 출발점은 계획이 아니라 배치입니다.
Antigravity가 Agent Manager를 "대화 UI와 아티팩트 검토에 초점을 둔 오케스트레이션 '노코드' 뷰"로 설명하는 이유도 같습니다.1 배치를 해두면, 사람은 대화(지시/질문/피드백)와 아티팩트(증거)만 보고도 의사결정을 이어갈 수 있습니다.
배치 운영의 4단계
엔터프라이즈에서 가장 잘 작동하는 루프는 다음 4단계로 단순화됩니다.
1) 인입( Intake ): "요청"을 "작업 계약"으로 바꾼다
전환 비용은 대개 인입 단계에서 결정됩니다. 요청이 모호하면, 에이전트도 사람도 결국 같은 질문을 반복합니다.
인입 템플릿은 길 필요가 없습니다. 대신 빠뜨리면 다시 물어야 하는 항목만 넣습니다.
무엇이 문제인가(증상)
무엇이 정답인가(기대 동작)
어디서 시작해야 하는가(서비스/엔드포인트/화면/로그 위치)
무엇이 금지인가(변경 금지 파일, 사용 금지 라이브러리, 롤백 불가 조건)
이 템플릿을 Agent Manager에 그대로 붙여 넣는 순간, 사람의 뇌에서 빠져나온 일을 "큐에 올릴 수 있는 형태"로 고정하게 됩니다.
2) 분배( Dispatch ): 겹치지 않게 쪼개고, 겹치는 건 아예 순서를 정한다
병렬화의 실패는 거의 항상 "겹치는 파일"에서 시작합니다. 엔터프라이즈 코드베이스에는 모두가 건드리는 핫스팟(라우팅, 설정, 공통 컴포넌트, 스키마)이 있습니다.
핫스팟을 건드리는 작업은 순차로 보냅니다.
핫스팟을 건드리지 않는 작업은 병렬로 묶습니다.
여기서 중요한 건, 이 판단을 사람의 머리로만 하지 않는 겁니다. 에이전트에게 먼저 "영향 범위(변경될 가능성이 큰 파일 목록)"를 아티팩트로 제출하게 하고, 그 결과로 병렬/순차를 결정하면 전환 비용이 줄어듭니다.
3) 검증( Verify ): '통과 조건'을 테스트/증거로 바꾼다
엔터프라이즈에서는 "내 로컬에선 됐어요"가 통과 조건이 될 수 없습니다. 그래서 에이전트에게 다음 중 하나 이상을 반드시 요구합니다.
테스트 실행 로그(최소: 어떤 명령을 실행했고, 결과가 어땠는지)
브라우저 검증 기록(스크린샷/녹화)
변경 diff(리뷰 가능한 형태)
재현/회귀 시나리오 체크리스트
Antigravity는 에이전트가 에디터·터미널·브라우저를 넘나들며 일을 수행하고, 그 과정과 결과를 아티팩트로 커뮤니케이션하도록 강조합니다.1
4) 통합( Integrate ): 사람은 '머지'가 아니라 '승인'만 한다
병렬 운영이 커질수록, 사람의 역할은 코드를 고치는 게 아니라 승인(approve)과 통합(merge) 순서를 결정하는 쪽으로 이동합니다.
이때 가장 중요한 규칙은 하나입니다.
"검증 아티팩트가 없는 변경은 통합하지 않는다."
이 규칙 하나만 지켜도, 나중에 "누가 왜 이렇게 했지?"를 추적하는 시간이 줄어듭니다.
역할 분리 설계: 1명의 리드가 6명의 에이전트를 다루는 방법
엔터프라이즈 운영에서 가장 효과적인 구도는 "리드 1명 + 에이전트 N개"입니다. 리드는 컨텍스트를 유지하고, 에이전트는 실행을 병렬화합니다.
다음은 실무에서 안정적으로 굴러가는 역할 분리입니다.
Triage(분류) 에이전트: 이슈를 읽고 영향 범위/우선순위를 정리해 제출한다.
Repro(재현) 에이전트: 재현 절차와 최소 재현 케이스를 만든다.
Fix(수정) 에이전트: 수정 diff와 단위 테스트를 만든다.
Verify(검증) 에이전트: 테스트·브라우저·성능 체크 등 통과 조건을 실행해 아티팩트로 남긴다.
Doc(문서) 에이전트: 릴리스 노트, 운영 가이드, 롤백 절차를 업데이트한다.
여기서 핵심은 "각 에이전트가 무엇을 잘하냐"가 아니라, 각 역할의 출력물이 다음 역할의 입력물이 되도록 연결하는 것입니다. 그래야 리드가 하루에 열 번씩 동일한 맥락을 설명하지 않아도 됩니다.
시나리오: 3개 워크스페이스에서 동시에 버그 1건을 끝낸다
엔터프라이즈에서 흔한 상황을 하나 가정해 봅시다.
워크스페이스 A: 프론트엔드(사용자 화면)
워크스페이스 B: 백엔드 API
워크스페이스 C: 인프라/배포 설정
증상은 "특정 사용자에서 결제 버튼이 비활성화된다"입니다.
1) Agent Manager에서 '동시에' 세 갈래를 연다
리드는 Agent Manager에서 다음 세 작업을 동시에 올립니다.
프론트엔드 에이전트: 버튼 비활성 조건(Feature flag, 권한, 상태값)을 추적하고 재현 절차를 아티팩트로 제출.
백엔드 에이전트: 해당 사용자 케이스에서 내려오는 응답 차이를 로그/테스트로 재현하고 원인 후보를 3개로 정리.
인프라 에이전트: 최근 배포 변경, 플래그 설정, 외부 설정(환경 변수/실험군) 변화를 조사해 요약.
Antigravity가 지향하는 그림처럼, 사용자는 여러 코드베이스에 걸쳐 여러 에이전트를 시작하고 모니터링합니다.1
2) 리드는 '탐색 결과'만 비교해 가설을 확정한다
세 에이전트가 제출한 아티팩트가 모이면, 리드는 코드를 깊게 읽지 않고도 가설을 고를 수 있습니다.
예를 들어 백엔드 에이전트가 "특정 사용자만 구독 상태가 trial_expired로 내려온다"를 확인했고, 프론트엔드 에이전트가 "trial_expired면 버튼 비활성"을 발견했다면, 원인은 인프라/설정/데이터 중 하나로 좁혀집니다.
이 순간 전환 비용이 줄어듭니다. 사람은 "어디를 봐야 하지?"를 다시 생각하지 않아도 됩니다. 이미 비교 가능한 형태로 증거가 모였기 때문입니다.
3) 수정은 한 갈래에서만 일어나게 만든다
수정은 대개 한 워크스페이스에서만 하도록 설계하는 편이 안정적입니다. 예를 들어 백엔드가 상태값 매핑을 고치고, 프론트는 그대로 두는 전략을 선택할 수 있습니다.
리드는 Fix 에이전트에게 다음처럼 경계를 줍니다.
변경 허용: 상태 매핑 로직과 해당 로직의 테스트
변경 금지: API 스펙 변경, 프론트 조건식 리팩터링
통과 조건: 단위 테스트 + 회귀 시나리오(해당 사용자 케이스) 재현 스크립트
이렇게 하면 병렬 운영이 '멀티 머지 지옥'으로 빠지지 않습니다.
전환 비용을 줄이는 운영 장치 5가지
여기부터는 엔터프라이즈에서 운영 체계가 없을 때 병렬화가 오히려 혼란이 되는 지점을, 장치로 막는 방법입니다.
1) "대화는 짧게, 아티팩트는 길게"
Agent Manager가 대화와 아티팩트 검토 중심이라는 말은,1 실무에서는 이렇게 번역됩니다.
대화: 작업 계약(범위/금지/통과 조건)만 적는다.
아티팩트: 실행 로그, diff, 스크린샷, 체크리스트를 남긴다.
대화가 길어지면, 그 자체가 다시 '읽기 비용'이 됩니다.
2) 핫스팟 파일을 공용 규칙으로 지정한다
핫스팟 파일은 "수정 금지"가 아니라 "수정 시 절차 고정"이 정답입니다.
예를 들어 routes.ts, schema.prisma, feature_flags.yaml 같은 파일은 다음 규칙을 붙입니다.
이 파일을 건드리면, 반드시 영향 범위를 아티팩트로 제출한다.
이 파일을 건드리는 작업은 동시에 두 개 이상 승인하지 않는다.
3) 리뷰는 '시간'이 아니라 '종류'로 배치한다
엔터프라이즈에서 리뷰 전환 비용은 생각보다 큽니다. 테스트만 추가하는 PR과, 인증 로직을 바꾸는 PR을 섞어 보면 뇌가 계속 리셋됩니다.
그래서 리뷰를 "점심 전 30분" 같은 시간 단위로 하지 말고, "테스트 PR 묶음", "설정 변경 묶음", "핫스팟 변경 묶음"처럼 종류로 묶어 처리하는 편이 좋습니다.
4) 장기 작업은 '완료' 대신 '진행률 아티팩트'를 요구한다
엔터프라이즈에는 하루 만에 끝나지 않는 일이 많습니다. 이때 "언제 끝나요?"라는 질문이 전환 비용을 다시 키웁니다.
장기 작업은 완료 아티팩트가 아니라 다음을 요구하세요.
이번 사이클에 확인한 사실(팩트)
다음에 해야 할 일(태스크)
막히는 지점(질문/의존성)
이렇게 하면 리드는 작업을 잊지 않고, 다른 우선순위가 들어와도 다시 들어갈 때 컨텍스트를 빠르게 복구할 수 있습니다.
5) '사람이 손대는 순간'을 명확히 예약한다
병렬 운영에서 가장 흔한 혼란은 이것입니다.
에이전트가 80%까지 해놨는데,
사람이 "마무리한다"는 이유로 범위를 확 넓혀서,
결국 다시 원점으로 돌아가는 상황
사람이 손대는 순간은 다음 둘 중 하나로 제한하는 편이 좋습니다.
승인 전 마지막 20% 다듬기(에디터에서)
경계 재설정(다음 사이클로)
이 원칙이 서면, 에이전트 병렬화가 엔터프라이즈에서도 유지됩니다.
이 운영이 조직에 주는 변화: '전환 비용'이 팀 공통 자산이 된다
병목이 전환 비용이라는 말은, 반대로 말하면 전환 비용을 줄이는 방법도 자산화할 수 있다는 뜻입니다.
어떤 입력 템플릿이 질문을 줄이는지
어떤 검증 아티팩트가 리뷰 시간을 줄이는지
어떤 핫스팟 규칙이 충돌을 줄이는지
이런 것들은 개인의 요령이 아니라 팀의 운영 방식이 됩니다. Antigravity가 작업과 검증을 "대화와 아티팩트"로 구조화하려는 이유도, 결국 이 운영을 반복 가능하게 만들기 위해서입니다.1
다음 챕터에서는 이 반복 가능한 운영을 더 강하게 만드는 장치, 즉 지식베이스(knowledge) 를 통해 "반복 업무를 학습 자산으로 바꾸는" 방법으로 넘어갑니다.
참고
1Google Antigravity Documentation — Agent Manager
2Google Antigravity Documentation — Workspaces
3Google Antigravity Documentation — Review Changes + Source Control (Manager)
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.