크로스-서피스 에이전트: 에디터·터미널·브라우저를 하나로 묶는 워크플로

코드 생성이 빨라져도, 개발 속도가 그대로인 팀이 많습니다. 이유는 간단합니다. 개발에서 시간이 오래 걸리는 구간은 '작성'이 아니라 '실행해보고 확인하는 과정'이기 때문입니다.

Antigravity가 노리는 지점도 거기입니다. 에이전트가 에디터 안에서만 코드를 쓰는 게 아니라, 터미널에서 실행하고(빌드/테스트/실행), 브라우저에서 확인(UI 동작, 콘솔 로그, 클릭/입력)까지 이어서 끝내도록 설계되어 있습니다.¹²

이번 챕터의 목표는 하나입니다.

코드 작성 → 터미널 실행 → 브라우저 테스트가 끊기지 않는 자동 흐름을 여러분이 직접 설계할 수 있게 만드는 것.

'코드만 시키면' 자동화는 절반에서 멈춘다

에이전트에게 "로그인 페이지 만들어줘"라고만 시키면, 대부분 여기서 끝납니다.

• 파일이 수정되고

• "완료했습니다"라는 말이 오고

• 사람은 직접 실행해보며 깨진 지점을 찾습니다.

하지만 Antigravity의 강점은 "말로 완료"가 아니라 "검증 가능한 아티팩트로 완료"에 있습니다. 브라우저 스크린샷과 브라우저 녹화 같은 결과물은, '동작했는지' 자체를 증거로 남겨서 리뷰 시간을 줄여줍니다.²

즉, 크로스-서피스 워크플로의 핵심은 일을 맡기는 범위를 '코드'가 아니라 '끝까지 확인'으로 확장하는 것입니다.

크로스-서피스 설계도: Mission → Surfaces → Artifacts

크로스-서피스 워크플로를 만들 때는, 도구 목록부터 외우기보다 다음 3단계를 머릿속에 고정하는 편이 안전합니다.

먼저 Mission(미션) 입니다. Antigravity는 "한 줄 지시"가 아니라, 계획·코딩·웹 탐색까지 하는 자율 에이전트를 운영하는 '미션 컨트롤'을 전제로 설계되었습니다.²

그다음이 Surfaces(서피스) 입니다.

Editor는 코드와 파일이 있고, Terminal은 실행과 테스트가 있고, Browser는 사용자 경험의 최종 상태가 있습니다. Antigravity는 에이전트를 별도 서피스로 분리하고, 에이전트가 에디터·터미널·브라우저를 넘나들며 작업하도록 도구를 제공합니다.¹

마지막이 Artifacts(아티팩트) 입니다. Antigravity는 작업을 전달하고 검토를 받기 위해 작업 계획, 구현 계획, 워크스루, 스크린샷, 브라우저 녹화 같은 아티팩트를 만든다고 설명합니다.²

이 3가지를 연결하면 이렇게 바뀝니다.

"코드 좀 써줘"가 아니라,

"이 미션을 끝내. 그리고 어떤 아티팩트로 검증했는지 남겨."

0단계: '권한/정책'부터 정해야 자동 흐름이 끊기지 않는다

크로스-서피스는 결국 실행 권한과 승인 지점의 설계입니다. 설정이 애매하면 에이전트는 중간에 멈추고(또는 위험하게 진행하고), 사람은 다시 운전대를 잡게 됩니다.

Codelab이 안내하는 정책만으로도 실무에 필요한 큰 틀은 잡힙니다.²

터미널 실행 정책(명령 실행 게이트)

Antigravity는 에이전트의 터미널 명령 실행을 정책으로 다루며, 대표적으로 "항상 진행"과 "검토 요청" 같은 옵션을 둡니다.²

권장 출발점은 이렇습니다.

개발 초기(탐색/프로토타이핑)에는 검토 요청으로 시작하고, 팀의 안전선이 정리되면 빌드·테스트 같은 저위험 커맨드만 자동화 범위로 포함시키는 방식이 좋습니다.

브라우저 JavaScript 실행 정책(웹 상호작용 게이트)

브라우저에서 자바스크립트를 실행하게 할지 또한 정책으로 제어합니다. "항상 진행"은 자율성이 크지만 보안 노출도 커지고, "검토 요청/사용 중지"는 안전하지만 자동 테스트가 끊길 수 있습니다.²

UI 검증이 중요한 팀이라면, 검토 요청을 기본값으로 두고, 반복적으로 안전하다고 확인된 작업만 자동화 범위로 옮기는 편이 안정적입니다.

아티팩트 검토 정책(품질 게이트)

에이전트가 계획/구현 계획 같은 아티팩트를 만들었을 때, 항상 검토할지/에이전트가 판단할지/항상 검토 요청할지 선택할 수 있습니다.²

크로스-서피스를 처음 설계할 때는 "에이전트가 더 많이 멈추더라도" 항상 검토 요청이 오히려 빠른 경우가 많습니다. 처음부터 자동으로 달리게 만들면, 틀린 방향으로 멀리 가는 비용이 커지기 때문입니다.

패턴 1: 기능 구현 → 로컬 실행 → 브라우저에서 '최소 E2E'로 확인

이 패턴은 가장 자주 쓰입니다. 핵심은 "기능 구현"을 완료 조건으로 삼지 않고, 로컬에서 돌아가는지와 브라우저에서 실제로 보이는지까지를 완료 조건으로 삼는 것입니다.¹²

지시문 템플릿

에이전트에게 다음처럼 미션을 내리면, 서피스가 자연스럽게 연결됩니다.

"/feature-x를 구현해. 구현 후 터미널에서 로컬 실행(또는 테스트)을 통과시키고, 브라우저에서 핵심 화면 2개를 직접 열어 동작을 확인해. 결과는 워크스루 + 스크린샷(전/후)로 남겨."²

기대 아티팩트(검증의 최소 세트)

• Task List / Implementation Plan

• 실행한 커맨드와 결과가 포함된 워크스루

• 변경된 UI를 보여주는 스크린샷²

사람이 잡아야 할 운전대

브라우저에서 "어떤 화면이 성공인지"는 제품 의사결정에 가깝습니다. 버튼 문구, 엣지 케이스 UX 같은 부분은 사람이 기준을 못 박아줘야 브라우저 검증이 의미를 갖습니다.

패턴 2: 버그 재현 → 패치 → 회귀 테스트 → 브라우저 '녹화'로 증거 남기기

버그는 "고친 것"보다 "다시는 안 깨지는 것"이 중요합니다. 그래서 이 패턴은 브라우저 녹화가 특히 잘 맞습니다.

Antigravity는 브라우저 하위 에이전트가 클릭/스크롤/입력, 콘솔 로그 읽기 같은 상호작용 도구를 쓰고, DOM 캡처·스크린샷·동영상 촬영까지 할 수 있다고 설명합니다.²

지시문 템플릿

"버그를 먼저 재현해. 재현 절차를 문서로 남기고, 패치 후 동일 절차로 재현이 사라졌다는 걸 브라우저 녹화로 남겨. 가능하면 회귀 테스트 1개를 추가하고, 터미널에서 테스트를 실행해 결과를 워크스루에 포함해."²

기대 아티팩트('고쳤다'의 증거)

• 재현 절차가 포함된 워크스루

• 회귀 테스트(또는 최소 검증 스크립트)와 실행 결과

• 버그 재현/해결 과정이 담긴 Browser Recordings²

사람이 잡아야 할 운전대

버그의 '정의'가 모호하면, 에이전트는 다른 문제를 고쳐버릴 수 있습니다. "어떤 입력에서", "어떤 기대 결과가", "어떻게 깨지는지"를 먼저 한 문단으로 고정하세요.

패턴 3: UI 반복 작업 — 스크린샷을 '비교 가능한 산출물'로 만든다

UI 작업은 수정 자체보다 확인이 오래 걸립니다. 그래서 크로스-서피스가 시간 절약을 가장 크게 만드는 영역입니다.

UI 반복에서는 목표를 "UI를 예쁘게"가 아니라 "전/후 상태를 비교 가능한 스크린샷으로 남기기"로 바꾸는 순간부터 속도가 붙습니다. Antigravity는 스크린샷과 브라우저 녹화를 대표 아티팩트로 제시합니다.²

지시문 템플릿

"헤더 높이를 56px로 통일하고, 버튼 간격을 스펙대로 맞춰. 변경 전/후를 같은 해상도에서 스크린샷으로 남기고, 상호작용이 있는 부분은 짧은 브라우저 녹화로 확인해."²

사람이 잡아야 할 운전대

UI는 팀 취향이 섞입니다. "스펙(디자인 기준)"을 정확히 주지 않으면, 에이전트는 그럴듯한 대안을 내놓습니다. 디자인 링크/수치/우선순위를 먼저 주고 시작하세요.

서피스 간 핸드오프를 '규칙'으로 만들기

크로스-서피스가 흔들리는 지점은 대부분 핸드오프입니다.

• 에디터에서 코드가 만들어졌는데 실행을 안 함

• 터미널에서 에러가 났는데 수정으로 안 이어짐

• 브라우저에서 깨졌는데 "아마 됐을 것"으로 끝냄

Antigravity는 에디터와 에이전트 관리자(미션 컨트롤)를 분리하고, 병렬로 여러 에이전트를 운영하도록 설계했다고 설명합니다.² 그러면 핸드오프도 '대화'가 아니라 '규칙'으로 바꿀 수 있습니다.

예를 들어 팀에서 다음 두 문장을 기본 규칙으로 삼는 것만으로도 결과가 달라집니다.

첫째, "코드 변경이 있으면, 최소 1개의 터미널 검증(빌드/테스트/실행) 커맨드를 반드시 포함한다."

둘째, "UI 변경이 있으면, 최소 1개의 스크린샷 또는 브라우저 녹화를 반드시 포함한다."²

이 규칙이 생기면, 크로스-서피스는 '고급 기능'이 아니라 '기본 습관'이 됩니다.

요약: '실행해보고 확인'까지 맡겨야 진짜 시간 절약이 된다

크로스-서피스 워크플로는 화려한 자동화가 아닙니다. 완료 정의를 바꾸는 일입니다.

• 완료는 "코드가 생성됨"이 아니라 "터미널에서 실행됨"까지

• 완료는 "대충 동작할 것 같음"이 아니라 "브라우저에서 확인됨"까지

• 완료 보고는 말이 아니라, 스크린샷/녹화/워크스루 같은 아티팩트로²

이렇게 설계하면, 여러분은 에이전트에게 '코드 타이핑'이 아니라 '개발 루프'를 위임하게 됩니다. 그때부터 Antigravity는 보조 도구가 아니라, 실제로 시간을 돌려주는 워크플로가 됩니다.¹²

참고

¹Google Antigravity Documentation — Home

²Google Antigravity 시작하기 | Google Codelabs