제5장 두 개의 뷰: Editor와 Manager

Antigravity를 처음 켰을 때 가장 낯선 지점은 기능이 아니라 시선의 방향이다. 보통의 AI 코딩 도구는 "코드를 쓰는 화면"이 중심이고, AI는 그 옆에 붙는다. 그런데 Antigravity는 반대로 묻는다. "지금 당신은 어떤 파일을 열 건가요?"보다 먼저 "어떤 일을 누구에게 맡길 건가요?"를 묻는다.

이 차이가 별것 아닌 것처럼 보여도, 여기서부터 개발 방식이 달라진다. Editor View는 여전히 중요하다. 하지만 Antigravity의 본체는 Editor가 아니라 Manager다. 이 장의 목적은 바로 그 감각을 몸에 익히는 데 있다. 언제 편집기로 내려가고, 언제 관제센터로 올라와야 하는지 알게 되면, 그제야 Antigravity가 왜 Agent-First 도구인지 이해된다.

왜 화면이 두 개인가

Antigravity는 처음부터 화면을 둘로 나눠 놓았다. 하나는 익숙한 편집기이고, 다른 하나는 에이전트를 지휘하는 관리 화면이다. 공식 Codelab은 이 구조를 단순한 UI 분할이 아니라 역할 분리로 설명한다. Editor와 Agent Manager는 각각 개인 작업과 오케스트레이션을 담당하며, Agent Manager는 계획·코딩·웹 검증까지 수행하는 자율 에이전트를 관리하는 "미션 컨트롤"에 가깝다.¹

이 말은 곧 이런 뜻이다. 사람이 해야 할 일이 더 이상 "매 줄을 직접 타이핑하는 것"만은 아니라는 뜻이다. 어떤 작업을 쪼개고, 어떤 에이전트에게 맡기고, 중간 산출물을 어디서 검토할지 결정하는 일도 개발의 일부가 된다.

예전 도구에서는 채팅창이 하나였고, 대화 흐름도 대체로 직선이었다. 질문 하나, 응답 하나, 수정 하나. Antigravity는 그 선형 흐름을 일부러 깨뜨린다. 로그인 버그를 잡는 에이전트, 테스트를 만드는 에이전트, 문서를 정리하는 에이전트를 따로 돌릴 수 있기 때문이다.¹ 그래서 화면도 하나로는 부족하다. 작업대 하나만으로는 공장을 운영할 수 없듯, 에디터 하나만으로는 멀티 에이전트를 지휘하기 어렵다.

쉽게 정리하면 이렇다. Editor는 "어떻게 고칠까"를 보는 곳이고, Manager는 "무엇을 누구에게 맡길까"를 결정하는 곳이다.

Editor View: 손을 대는 공간

Editor View는 낯설지 않다. VS Code를 써 본 사람이라면 거의 바로 적응한다. 파일 탐색기, 코드 편집 창, 터미널, 우측의 에이전트 패널 같은 요소가 자연스럽게 보이고, 코드 한 줄을 고치거나 diff를 읽거나 직접 저장하는 감각도 익숙하다.¹

이 화면이 가장 빛나는 순간은 가까이서 확인해야 할 때다. 예를 들어 에이전트가 만든 변경 사항을 줄 단위로 읽고 싶을 때, 특정 함수만 수동으로 다듬고 싶을 때, 터미널 출력을 보고 바로 수정 지시를 주고 싶을 때는 Editor가 훨씬 편하다. Manager가 위에서 내려다보는 화면이라면, Editor는 작업대 위에 얼굴을 들이미는 화면이다.

그래서 초보자는 종종 착각한다. "역시 여기서만 일하면 되겠네." 반은 맞고 반은 틀리다. 작은 수정만 한다면 그 말이 맞다. 하지만 에이전트가 계획을 세우고, 브라우저를 열고, 검토 요청을 보내고, 다른 워크스페이스에서 병렬로 일하기 시작하면 Editor는 전체 상황을 보기엔 너무 근거리 화면이 된다.

Editor를 잘 쓰는 요령은 간단하다. 이 화면을 "주 무대"로만 보지 말고 "확대경"으로 생각하는 것이다. 가까이에서 확인하고, 필요한 만큼만 손대고, 다시 위로 올라오는 화면 말이다.

Manager View: 지휘하는 공간

Manager View는 Antigravity의 성격을 가장 솔직하게 보여 준다. 공식 문서와 Codelab이 반복해서 강조하듯, 이곳은 에이전트를 만들고, 상태를 보고, 생성된 아티팩트와 승인 요청을 추적하는 관제 화면이다.¹ 다시 말해, 코드를 쓰는 사람의 화면이 아니라 일을 배분하는 사람의 화면이다.

Manager View에 오래 머물수록 한 가지 사실이 선명해진다. Antigravity는 "채팅이 달린 에디터"가 아니다. 오히려 "에디터를 포함한 관제센터"에 가깝다.

이 화면에서 보게 되는 것은 코드 그 자체보다 흐름이다. 어떤 에이전트가 실행 중인지, 누가 리뷰를 기다리는지, 어느 대화에서 브라우저 권한이 필요한지, 어떤 작업이 멈춰 있는지가 보인다. 이 시야가 중요한 이유는, Agent-First 개발에서 병목은 종종 코드 작성보다 승인 대기와 방향 수정에서 생기기 때문이다.

예를 들어 로그인 화면 수정, 테스트 추가, README 정리를 동시에 돌린다고 해 보자. Editor에서는 셋 중 하나만 크게 보이기 쉽다. 반면 Manager에서는 세 작업이 각각 어디까지 왔는지가 한눈에 들어온다. 이때 개발자는 더 이상 타이피스트가 아니라 교통정리 담당자에 가깝다. 어떤 에이전트는 계속 달리게 하고, 어떤 에이전트는 잠깐 세우고, 어떤 에이전트에는 방향을 틀라고 말한다.

바로 이 감각이 중요하다. Antigravity를 잘 쓰는 사람은 코드를 많이 쓰는 사람이 아니라, 화면을 올바르게 오가며 흐름을 끊지 않는 사람이다.

Cmd+E: 두 세계를 오가는 엘리베이터

Antigravity는 Editor와 Manager 사이 이동을 아주 노골적으로 중요 기능으로 취급한다. 공식 문서에 따르면 Mac에서는 Cmd+E, Windows에서는 Ctrl+E로 두 화면을 즉시 전환할 수 있고, 상단의 Open Editor, Open Agent Manager 버튼으로도 같은 동작을 할 수 있다.²

이 단축키는 생각보다 훨씬 중요하다. 그냥 "화면 전환 단축키"가 아니라, 사고방식 전환 단축키이기 때문이다.

실전에서는 보통 이런 흐름이 가장 자연스럽다.

• Manager에서 새 작업을 만들고, 워크스페이스와 모델, 모드를 정한 뒤 미션을 위임한다.

• 계획이나 아티팩트가 올라오면 Manager에서 먼저 전체 방향을 본다.

• 코드 세부를 확인하고 싶을 때만 Editor로 내려간다.

• 다시 Manager로 돌아와 다른 에이전트 상태와 대기 중인 승인 요청을 확인한다.

이 흐름이 익숙해지면, 작업은 이상하게도 더 덜 바빠 보이는데 실제 처리량은 늘어난다. 한 화면에서 모든 걸 해결하려고 애쓰지 않기 때문이다.

특히 기억할 팁이 하나 있다. Editor에서 에이전트가 멈춘 것처럼 보일 때가 있다. 이때는 "응답이 느린가?"라고 생각하기 쉽지만, 실제로는 Manager 쪽 Inbox에 검토 요청이나 Proceed 버튼이 떠 있는 경우가 적지 않다.⁴ 차가 고장 난 게 아니라 신호등 앞에 멈춰 있는 셈이다.

Inbox, Conversation, Workspace: Antigravity의 기본 구조

Antigravity를 쓰다 보면 금방 비슷해 보이는 단어 셋이 나온다. Inbox, Conversation, Workspace. 처음엔 다 "대화 비슷한 것"처럼 보여서 헷갈리지만, 이 셋의 역할을 정확히 구분하면 화면 구조가 한 번에 정리된다.

가장 쉬운 방법은 우체국 비유로 이해하는 것이다.

• Inbox는 전체 우편함이다. 지금까지의 대화와 작업을 한곳에서 모아 보고, 어떤 항목이 내 승인을 기다리는지 확인하는 중앙 목록이다. 공식 문서도 Inbox를 모든 대화를 추적하는 원스톱 허브로 설명하며, 여기서 터미널 실행, 브라우저 사용, 구현 계획 수립 같은 승인 대기 항목을 확인할 수 있다고 말한다.³

• Conversation은 개별 작업 티켓이다. 하나의 목표를 중심으로 에이전트와 주고받은 메시지, 계획, 아티팩트, 코멘트가 묶여 있는 작업 단위다. "로그인 버튼 버그 수정" 하나가 하나의 Conversation이 될 수 있다.

• Workspace는 프로젝트 현장이다. 실제 파일이 있는 폴더이자, 에이전트가 맥락을 붙잡고 일하는 범위다. 같은 워크스페이스 안에서 여러 Conversation이 생길 수 있고, 같은 프로젝트를 두고 여러 에이전트가 각자 다른 일을 맡을 수도 있다.¹

이 셋의 관계를 문장 하나로 요약하면 이렇다. Workspace는 일터, Conversation은 작업 지시서, Inbox는 전체 지시서 보관함이다.

이 구조를 이해하면 몇 가지 혼란이 사라진다. 왜 같은 프로젝트에서 대화가 여러 개 생기는지, 왜 특정 승인 요청은 코드 화면이 아니라 별도 목록에서 확인하는지, 왜 "지금 내 차례인 일"과 "전체 프로젝트 맥락"이 분리되어 보이는지가 자연스럽게 설명된다.

Conversation은 채팅 로그가 아니라 작업 단위다

여기서 특히 강조하고 싶은 것은 Conversation의 의미다. 많은 사용자가 Conversation을 그냥 "지난 채팅 내역"처럼 여긴다. 하지만 Antigravity에서 Conversation은 훨씬 더 무겁다.

Conversation 하나에는 보통 다음이 함께 붙는다. 처음 지시한 목표, 에이전트의 진행 상태, 중간 계획, 구현 결과, 스크린샷이나 브라우저 녹화 같은 아티팩트, 그리고 사용자가 남긴 피드백이다. 즉, 단순한 문답 기록이 아니라 한 작업의 생애주기 전체가 들어간다.

그래서 좋은 습관은 작업을 주제별로 분리하는 것이다. 로그인 버그 수정, 다크 모드 추가, 테스트 리팩터링을 한 Conversation에 몰아넣으면 나중에 읽는 사람도 헷갈리고, 에이전트도 목적을 흐리기 쉽다. 반대로 작업 하나당 Conversation 하나라는 감각을 갖고 있으면, 나중에 Inbox에서 다시 찾아볼 때도 훨씬 명확하다.

말하자면 Conversation은 채팅방이 아니라 "작업 상자"다. 상자 안에 계획서, 변경 내역, 검토 메모, 검증 증거가 함께 들어 있다고 생각하면 된다.

Workspace는 단순한 폴더보다 크다

Workspace도 겉으로는 그냥 프로젝트 폴더처럼 보인다. 실제로 출발은 폴더가 맞다. 그러나 Antigravity 안에서 Workspace는 단순 경로 이상의 의미를 갖는다. 에이전트가 어떤 파일들을 읽고, 어떤 맥락을 기억하고, 어디까지를 자기 작업 범위로 볼지 정하는 기준점이 되기 때문이다.¹

이 차이를 이해하면 왜 Manager에서 워크스페이스별로 작업을 나눠 보는지가 납득된다. 워크스페이스가 다르면 프로젝트의 규칙도 다르고, 파일 구조도 다르고, 목표도 다르다. 결국 에이전트를 잘 부리려면 "무슨 일을 시킬까"만큼이나 "어느 작업장에 투입할까"가 중요하다.

또 한 가지. 같은 워크스페이스를 Manager와 Editor에서 함께 보고 있다면, 두 화면은 서로 경쟁 관계가 아니라 협업 관계가 된다. Manager에서 지시하고 상태를 보고, Editor에서 파일을 열어 확인하고, 다시 Manager에서 승인한다. 하나의 프로젝트를 두 개의 높이에서 보는 셈이다.

이렇게 써야 감이 온다: 추천 워크플로우

이 장의 내용을 가장 빨리 체득하는 방법은 일부러 두 화면을 번갈아 써 보는 것이다. 예를 들어 기존 프로젝트에 작은 UI 개선 작업을 맡긴다고 해 보자.

먼저 Manager View에서 새 Conversation을 시작한다. "대시보드의 empty state를 더 친절하게 바꾸고, 모바일에서도 보기 좋게 정리해 줘"처럼 목표를 준다. 에이전트가 Plan 모드에서 구조를 잡고, 필요한 경우 스크린샷이나 구현 계획을 만든다.

그다음 Editor View로 내려가 실제로 어느 파일이 바뀌는지 본다. src/components/EmptyState.tsx가 생겼는지, 스타일이 어디에 들어갔는지, 내가 직접 만지고 싶은 부분이 있는지 확인한다. 필요하면 작은 수동 수정도 한다.

이후 다시 Manager View로 돌아온다. 이제 중요한 건 코드 한 줄이 아니라 작업 전체 상태다. 브라우저 검증이 끝났는지, 스크린샷이 올라왔는지, 내가 승인해야 할 항목이 있는지 확인한다. 코멘트를 남기고 다시 돌릴 수도 있다.

이 과정을 몇 번만 반복하면 패턴이 보인다. 일은 Manager에서 시작하고, 검사는 Editor에서 하고, 판단은 다시 Manager에서 끝낸다.

이 순서를 거꾸로 하면 자주 피곤해진다. 처음부터 Editor만 붙잡고 있으면 왜 멈췄는지, 다른 작업은 어떻게 되는지, 승인 요청이 어디서 왔는지 놓치기 쉽다.

초보자가 가장 자주 헷갈리는 장면

처음 며칠은 누구나 비슷한 장면에서 멈춘다.

첫째, "왜 에디터가 메인이 아니지?"라는 당혹감이다. 이건 정상이다. Antigravity는 일부러 그렇게 설계됐다. 당신을 코드 작성자이면서 동시에 작업 관리자라고 보기 때문이다.

둘째, "대화가 사라진 것 같은데?"라는 느낌이다. 실제로는 사라졌다기보다 다른 층위에 있는 경우가 많다. 전체를 보고 싶으면 Inbox를, 특정 프로젝트 맥락을 보고 싶으면 Workspace를, 개별 작업의 흐름을 보려면 Conversation을 봐야 한다.

셋째, "에이전트가 멈췄다"는 오해다. 앞서 말했듯 Editor에서 기다림 표시만 보일 때는 Manager의 Inbox부터 확인하는 습관이 좋다. 승인 대기 항목이 숨어 있을 수 있다.⁴

넷째, "둘 중 하나만 쓰면 안 되나?"라는 질문이다. 아주 작은 작업이라면 가능하다. 하지만 Antigravity의 강점은 두 화면을 같이 쓸 때 비로소 드러난다. Editor만 쓰면 그냥 똑똑한 VS Code처럼 보이고, Manager만 쓰면 코드 감각이 떨어진다. 둘을 오갈 때만 Agent-First다운 리듬이 생긴다.

이 장의 핵심: Antigravity는 에디터를 가진 관제센터다

이 장에서 꼭 남겨야 할 문장은 하나다. Antigravity는 에디터가 아니라 관제센터다. 에디터가 없는 게 아니라, 에디터보다 더 위에 있는 운영 화면이 존재한다는 뜻이다.

Editor View는 여전히 손에 익은 도구다. 코드를 읽고, 수정하고, diff를 확인하고, 세밀하게 만지는 곳이다. 반면 Manager View는 에이전트를 병렬로 운영하고, 승인 요청을 처리하고, 작업 전체를 비동기로 조율하는 곳이다. 그리고 Inbox, Conversation, Workspace는 그 흐름을 각각 전체 목록, 개별 작업, 프로젝트 맥락으로 나눠 주는 뼈대다.

이 구조가 한 번 머리에 들어오면 다음부터는 훨씬 덜 헤맨다. 화면이 둘이라서 복잡한 것이 아니라, 역할이 나뉘어 있어서 오히려 생각이 정리된다. 오늘 해야 할 일은 Editor에서만 보이지 않고, Manager에서도 보인다. 그리고 그 순간부터 당신은 단순히 코드를 쓰는 사람이 아니라, 에이전트들의 작업 흐름을 설계하는 사람이 된다.

그게 바로 Antigravity가 원하는 개발자의 자리다.

참고

¹Google Antigravity 시작하기 | Google Codelabs

²Google Antigravity Documentation - Agent Manager

³Google Antigravity Documentation - Inbox

⁴Tip: In Google Antigravity, keep the Editor and Agent Manager view open