화면 구조 한 장으로 끝내기: Editor View vs Manager Surface
Antigravity는 한 화면에서 모든 걸 해결하려 하지 않습니다. 대신 개발을 두 가지 모드로 쪼갭니다. 손으로 직접 코드를 다루는 Editor View와, 에이전트를 여러 개 띄워 비동기적으로 운영하는 Manager Surface(Agent Manager)입니다.12
이 챕터의 목표는 간단합니다. "어떤 일은 에디터에서, 어떤 일은 매니저에서 해야 가장 빠른가"를 한 장의 규칙으로 정리해, 작업 중에 망설이지 않게 만드는 것입니다.
한 장 요약: 동기식 '코딩'과 비동기식 '운영'
Antigravity를 쓰다 보면 개발의 리듬이 둘로 나뉩니다.
Editor View는 익숙한 흐름을 최적화합니다. 내가 보고 있는 파일을 내가 고치고, 즉시 결과를 확인하며, 작은 결정을 연속으로 내리는 동기식(synchronous) 작업에 맞춰져 있습니다. 구글은 Editor View를 탭 자동완성과 인라인 명령 같은 IDE 경험을 중심으로 설명합니다.1

Manager Surface는 다른 종류의 시간을 다룹니다. 조사→계획→구현→검증처럼 길어지거나, 터미널·브라우저까지 오가며, 중간에 기다림이 생기는 일을 에이전트에게 맡기고 관찰하는 비동기식(asynchronous) 운영에 맞춰져 있습니다. 여러 에이전트를 동시에 띄우고, 서로 다른 워크스페이스에서 병렬로 돌리는 '미션 컨트롤'에 가깝습니다.12

핵심은 "어느 화면이 더 좋다"가 아니라, 작업의 형태가 다르면 화면도 달라져야 한다는 점입니다.
Editor View: '내 손이 필요한 순간'에 쓰는 화면
Editor View는 개발자가 직접 조향해야 할 순간을 위해 존재합니다. 여기서의 최적화 목표는 생산성이 아니라 즉시성입니다.
Editor View가 가장 빠른 작업
다음 범주의 일은 에디터에서 처리할수록 빠릅니다.
수정 범위가 눈에 보이는 작은 변경(변수명 변경, 조건문 한두 줄 조정, UI 간격 미세 조정)
코드 읽기와 이해가 곧바로 수정으로 이어지는 디버깅(브레이크포인트, 로그 삽입/삭제, 한 파일 안의 흐름 추적)
내가 직접 결정을 내려야 하는 설계의 갈림길(추상화 레벨, API 형태, 예외 처리 정책)
이때 에이전트는 "대체자"가 아니라 증폭기로 쓰는 편이 좋습니다. 즉, 내가 결정한 방향을 기준으로 코드 생성·수정 속도를 높이거나, 반복 타이핑을 줄이는 방식입니다.1
Editor View에 오래 머물면 느려지는 작업
반대로, 에디터에 붙잡고 있으면 일이 커지기 쉬운 종류가 있습니다.
조사/비교/정리로 시작하는 작업(레퍼런스 탐색, 라이브러리 선택, 기존 코드베이스 패턴 수집)
여러 도구를 계속 오가야 하는 작업(터미널에서 명령 실행, 브라우저에서 동작 확인, 스크린샷/녹화로 증거 남기기)
기다림이 섞인 작업(테스트가 오래 걸리거나, 재현 절차가 길거나, 여러 번 반복 확인이 필요한 경우)
이 지점이 Manager Surface로 넘길 타이밍입니다.
Manager Surface: '에이전트가 일하도록' 설계된 운영 화면
구글은 Antigravity에서 에이전트가 사이드바 챗봇이 아니라 전용 공간을 가져야 한다고 말합니다.1 Manager Surface는 그 전용 공간이며, 관점이 바뀝니다. "내가 파일을 연다"가 아니라 "내가 일을 올려둔다"가 중심이 됩니다.
Manager Surface가 가장 빠른 작업
Manager Surface는 다음 같은 작업에서 시간을 크게 줄입니다.
끝까지 완주해야 의미가 있는 엔드투엔드 작업(기능 구현 + 테스트 + 브라우저 검증까지)
동시에 여러 건을 굴려야 하는 작업(한쪽은 리팩터링, 다른 쪽은 버그 재현/테스트 작성 같은 병렬 처리)
워크스페이스가 여러 개인 작업(프로젝트가 여러 개이거나, 실험용 분기/샌드박스를 따로 두는 경우)
구글은 Manager Surface를 여러 에이전트를 생성(spawn)하고 오케스트레이션하며, 진행 상황을 관찰하는 인터페이스로 소개합니다.12
"한 창에 합치지 않았다"는 설계 의도
Antigravity는 비동기 운영(Manager)과 동기 편집(Editor)을 한 창에 억지로 우겨 넣지 않고, 즉각적인 핸드오프를 최적화했다고 설명합니다.2 이 말은 실무적으로 중요합니다.
작업은 늘 섞여 있기 때문입니다. 에이전트가 대략 80%까지 밀어놓으면, 마지막 20%는 사람이 손으로 만져야 하는 경우가 많습니다. 그때 "매니저에서 확인 → 에디터로 들어가 직접 수정 → 다시 매니저로 검증 요청"이 자연스럽게 이어져야 합니다.
전환 규칙: '작업 길이'가 아니라 '불확실성'으로 판단하기
많은 사람이 전환을 "큰 작업이면 매니저, 작은 작업이면 에디터"로 외우려 합니다. 그런데 실제 기준은 작업의 크기보다 불확실성에 더 가깝습니다.
Editor View로 시작하기 좋은 신호
에디터에서 시작하면 좋은 경우는 보통 이런 신호가 있습니다.
바꿀 파일/함수가 이미 머릿속에 있다
원하는 결과를 내 눈으로 바로 확인할 수 있다(로컬 실행이 빠르거나, 수정→새로고침 루프가 짧다)
중간에 판단을 계속 내려야 한다(여러 선택지 중 '내 취향/팀 기준'이 중요한 작업)
Manager Surface로 넘기기 좋은 신호
매니저로 넘기면 좋은 경우는 이런 신호가 나타납니다.
"일단 조사해보고"라는 말이 나올 때(레퍼런스 수집, 기존 패턴 탐색, 영향 범위 파악)
터미널·브라우저·문서 확인이 필수일 때(교차 서피스 작업)
검증이 '결과물'로 남아야 할 때(스크린샷, 브라우저 녹화, 체크리스트 같은 아티팩트 기반 검토)
Antigravity는 이런 검증을 로그가 아니라 작업 단위의 산출물(Artifacts)로 보이게 하려는 방향을 강조합니다.12
실전 흐름 2가지: 가장 많이 쓰는 왕복 패턴
1) UI 변경(반복·검증 중심): 매니저에서 시작해 에디터로 마무리
UI 작업은 "고치기"보다 "확인하기"가 오래 걸립니다. 특히 브라우저에서 화면을 보고, 스크린샷으로 비교하고, 접근성이나 반응형까지 확인하려면 쉽게 장기 작업이 됩니다.
이때는 Manager Surface에서 에이전트에게 작업을 맡기고, 결과를 스크린샷/워크스루 같은 형태로 받는 편이 효율적입니다.1 그 다음, 마지막 디테일(간격, 애니메이션, 네이밍)은 Editor View에서 손으로 다듬는 방식이 가장 흔한 왕복입니다.
외부 글에서도 Antigravity가 내장 브라우저를 포함하고, 에이전트가 UI를 수정한 뒤 시각적 산출물로 검증을 돕는다고 정리합니다.3
2) 긴급 버그(즉시성 중심): 에디터에서 시작해 매니저로 확장
반대로 "지금 당장 빨리 고쳐야" 하는 버그는 에디터에서 시작하는 게 빠릅니다. 재현이 되면, 최소 수정으로 일단 막고, 테스트를 돌려 안전을 확보합니다.
그다음부터는 매니저가 빛납니다. 원인 분석을 더 깊게 하거나, 회귀 테스트를 추가하거나, 문서/체크리스트까지 정리하는 후속 작업은 비동기로 돌려두는 편이 좋습니다. 즉, 핫픽스는 동기식, 후속 정리는 비동기식으로 쪼개면 팀 전체 속도가 올라갑니다.
화면을 '레이아웃'이 아니라 '작업대'로 생각하기
Antigravity를 처음 쓰면 화면 전환이 낯설 수 있습니다. 하지만 IDE를 생각해보면 원래도 우리는 작업에 따라 화면을 바꿔왔습니다.
VS Code는 사이드바/패널/에디터 영역을 재배치해 작업 흐름에 맞게 바꿀 수 있다고 설명합니다.4 Visual Studio 역시 창 레이아웃을 저장해 "편집용/디버깅용"으로 전환하라고 권합니다.5 Antigravity의 Editor vs Manager도 같은 발상입니다. 다만 그 기준이 "디버깅 창 배치"가 아니라, 개발을 동기식 편집과 비동기식 운영으로 나눴다는 점이 다릅니다.
결국 익숙해져야 할 질문은 하나입니다.
"지금 나는 코드를 쓰고 있는가, 아니면 작업을 운영하고 있는가?"
이 질문에 답이 서면, 다음 챕터부터 배우는 Editor View 기능과 에이전트/아티팩트가 어디에 꽂혀야 하는지도 자연스럽게 정리됩니다.
참고
1Build with Google Antigravity, our new agentic development platform
2Introducing Google Antigravity, a New Era in AI-Assisted Software Development
3Google Antigravity vs Gemini CLI: Which AI Coding Tool Is Right for You?
4Custom Layout (Visual Studio Code Documentation)
5Customize window layouts and personalize tabs (Visual Studio Documentation)
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.