Google Antigravity 2.0 Remote Control은 작업용 PC에서 이미 실행 중인 agent를 휴대폰이나 다른 컴퓨터의 브라우저로 확인하고 이어서 지시하는 기능입니다. 자리를 비운 사이 진행 상황을 보고, 새 작업을 시작하고, implementation plan이나 artifact를 검토할 수 있습니다.
하지만 작업이 휴대폰이나 새 클라우드 환경으로 옮겨가는 것은 아닙니다. 브라우저는 제어 화면이고 호스트가 실행 환경입니다. 프로젝트 파일, 빌드 도구, 환경 변수, 인증 정보는 원래 컴퓨터에 그대로 있으므로 그 컴퓨터가 절전·종료·오프라인 상태가 되면 원격 페이지도 대신 실행할 수 없습니다.
휴대폰을 들고 나가기 전에 확인할 세 가지
첫째, 어떤 인스턴스를 남길지 정합니다. 평소 사용하는 Antigravity 2.0 desktop 앱이면 설정 토글이 가장 간단합니다. GUI가 없는 서버나 장기 실행 전용 컴퓨터라면 headless daemon이 맞습니다. 둘은 앞뒤 단계가 아니라 대안입니다.
둘째, 호스트가 실제로 깨어 있고 인터넷에 연결된 상태를 유지할 수 있어야 합니다. 화면 꺼짐과 시스템 절전은 다릅니다. 전원 설정을 확인하지 않고 모니터만 켜 두는 것으로는 충분하지 않을 수 있습니다.
셋째, 원격에서 내리는 승인이 호스트에서 실제 command, file, MCP, web 동작으로 이어진다는 점을 받아들여야 합니다. 작은 화면에서 전체 범위를 읽을 수 없다면 승인하지 않는 것이 설정의 일부입니다.
Antigravity 2.0 앱에서 Remote Control 켜기
Google 공식 Remote Control 문서의 현재 절차는 다음과 같습니다.
- macOS에서는
Cmd + ,, Windows/Linux에서는Ctrl + ,로 Settings를 엽니다. 왼쪽 사이드바 아래 Settings도 사용할 수 있습니다. App섹션으로 이동합니다.Enable Remote Control을 On으로 바꿉니다.- 필요하면 컴퓨터를 식별할 Nickname을 정합니다.
이제 휴대폰이나 다른 PC에서 Antigravity Remote Control dashboard를 열고 desktop 앱과 같은 Google 계정으로 로그인합니다. instance switcher에서 호스트를 선택하면 active conversation을 보고, 새 agent task를 시작하고, plan과 artifact를 확인할 수 있습니다.
여러 컴퓨터를 연결할 때 이름은 편의보다 안전에 가깝습니다. work-mac, test-linux처럼 역할은 알 수 있지만 고객명, 내부 IP, 개인 정보가 들어가지 않는 이름이 좋습니다. 휴대폰 화면에서 비슷한 두 인스턴스를 잘못 선택한 뒤 production 명령을 승인하는 사고를 줄일 수 있습니다.
dashboard는 모바일 홈 화면에 web app으로 추가할 수 있습니다. Google은 agent가 작업을 마쳤거나 입력이 필요할 때 push notification을 제공한다고 설명합니다. 알림은 세션을 열어 확인하라는 신호일 뿐, 호스트가 계속 정상 동작했다는 증거는 아닙니다.
서버에는 Headless Daemon을 별도로 설치한다
Linux/macOS용 공식 명령은 현재 다음과 같습니다.
bashcurl -fsSL https://antigravity.google/cli/agy-daemon.sh | bash
설치할 때 이름을 지정하려면 공식 예시는 다음 형태입니다.
bashcurl -fsSL https://antigravity.google/cli/agy-daemon.sh | bash -s -- install --name "build-host"
다운로드한 스크립트를 곧바로 shell에 전달하는 명령이므로 실행 전 내용을 검토하고 조직의 장치 정책을 확인해야 합니다. 공식 도메인이라는 사실만으로 백그라운드 서비스 설치와 자동 업데이트를 무조건 허용하면 안 됩니다.
Windows에서는 관리자 권한으로 연 Command Prompt에서 실행해야 하며 PowerShell이 아닙니다.
batcurl -fsSL https://antigravity.google/cli/agy-daemon.cmd -o agy-daemon.cmd && agy-daemon.cmd install
Windows의 install과 uninstall은 관리자 권한이 필요하고, status와 restart는 일반 프롬프트에서도 동작합니다. --interval weekly, --no-auto-update, --no-prompt 같은 옵션도 있지만 서버의 변경 관리와 복구 계획에 맞춰 선택해야 합니다.
초기 설정 중에는 terminal에 표시된 URL을 열고 코드를 다시 붙여 넣는 별도 sign-in이 진행됩니다. editor 로그인과 daemon 로그인은 독립적이므로 앱에서 이미 로그인했어도 다시 인증을 요구할 수 있습니다. 해당 컴퓨터에서 agy를 sign out하면 서비스도 접근 권한을 잃습니다.
OS마다 서비스가 살아남는 조건이 다르다
daemon이 설치됐다는 한 문장만으로 재부팅 이후 동작을 판단하면 안 됩니다.
| 호스트 OS | 시작 시점 | 사용자 로그아웃 후 | crash 후 |
|---|---|---|---|
| Linux | 부팅 시 | 계속 실행 | 자동 복구 |
| macOS | 사용자 로그인 시 | 중지, 다음 로그인 때 복구 | 로그인 세션 안에서는 자동 복구 |
| Windows | 부팅 시 | 계속 실행 | 다음 부팅, 예약 업데이트 또는 수동 restart 때 복구 |
따라서 로그인 화면에 멈춘 Mac은 Linux 서버처럼 계속 보이지 않습니다. Windows 서비스가 crash한 경우에도 휴대폰 dashboard를 새로고침하는 대신 호스트에서 restart가 필요할 수 있습니다.
설정 파일 위치는 Linux/macOS가 ~/.gemini/config/config.json, Windows가 %USERPROFILE%\.gemini\config\config.json입니다. cliRemoteControlHostname은 daemon, remoteControlHostname은 같은 컴퓨터의 editor 이름입니다. 수정 후 서비스 재시작이 필요하며 설치 때 --name을 지정했다면 그 값이 다시 우선됩니다.
설정 파일 전체를 공개 이슈에 붙이지 마세요. 질문과 무관한 환경 정보, 계정 단서, 민감 값이 없는지 먼저 가려야 합니다.
인스턴스가 안 보일 때는 호스트부터 역순으로 점검한다
원격 UI를 반복해서 새로고침하기 전에 아래 순서로 확인하면 원인을 빠르게 좁힐 수 있습니다.
- 진입 경로: desktop은
Enable Remote Control이 여전히 On인지, daemon은status와 log가 정상인지 봅니다. - 계정: 호스트와 dashboard가 정확히 같은 Google 계정인지 확인합니다. 브라우저에 여러 계정이 로그인돼 있으면 잘못된 계정 화면이 자연스럽게 열릴 수 있습니다.
- 전원 상태: 호스트가 sleep/suspend 상태가 아닌지 확인합니다.
- 호스트 네트워크: 휴대폰 인터넷이 아니라 원래 컴퓨터의 인터넷 연결을 확인합니다.
- 인스턴스 종류: 같은 컴퓨터에서 editor와 daemon을 모두 켜면 두 항목이 나올 수 있습니다. 내용을 확인한 뒤 이름을 구분합니다.
- daemon 인증: log에 sign-in 오류가 있으면 설치를 반복하기보다 공식 setup으로 다시 인증합니다.
- OS lifecycle: macOS 사용자 로그인, Windows service restart, Linux boot service 상태를 각각 확인합니다.
공식 troubleshooting 문서는 web UI가 일시적 연결 끊김 뒤 재연결을 시도한다고 설명합니다. 이미 실행 중인 background agent task와 shell command는 호스트가 인터넷 연결을 유지하는 동안 계속됩니다. 전원 꺼짐, OS crash, 앱 종료까지 살아남는다는 뜻은 아닙니다.
원격 승인도 호스트 권한이다
Antigravity permission 문서는 충돌하는 규칙을 Deny > Ask > Allow 순서로 평가합니다. active workspace 안의 일반적인 파일 읽기·쓰기는 편리한 기본값을 갖지만 command, MCP, web 실행, workspace 밖 파일은 별도 설정이 없다면 Ask가 기본입니다.
휴대폰에서는 다음 기준을 지키는 편이 좋습니다.
- command, path, domain, MCP tool의 전체 범위를 읽지 못하면 큰 화면에서 다시 확인합니다.
- 신뢰하지 않는 프로젝트에서 승인 횟수를 줄이려고
Full machine이나Unrestricted를 사용하지 않습니다. - 삭제, 배포, production 변경, 결제, key 관련 작업은 호스트 이름과 프로젝트를 다시 확인합니다.
- 실수 비용이 큰 작업에는 Ask를 유지합니다.
Google은 Remote Control을 workspace로 들어가는 secure window라고 표현합니다. 그러나 확인한 공개 문서만으로 특정 전송 프로토콜, inbound port 유무, relay 보관, 데이터 레지던시, 규정 준수를 보장할 수는 없습니다. 규제 대상 코드나 자격 증명을 다루는 팀은 최신 공식 문서와 계약 조건을 별도로 평가해야 합니다.
토글이 없다고 특정 요금제를 먼저 결제하지 않는다
2026년 8월 27일 기준 Antigravity 2.0 Remote Control 기능과 문서는 공개되어 있습니다. 다만 확인한 공식 페이지에는 모든 요금제, 국가, 계정 유형, 단계적 rollout을 한 번에 보여 주는 완전한 표가 없습니다. Enable Remote Control이 안 보인다는 이유만으로 특정 구독을 사면 해결된다고 단정할 수 없습니다.
먼저 Antigravity 2.0인지 확인하고 앱 업데이트와 재시작, Google 계정, 관리형 장치 정책을 점검합니다. 그런 다음 최신 공식 절차와 현재 UI를 비교하고, 계정별 제공 상태는 공식 지원 경로에서 확인합니다.
설정 완료의 기준은 online 표시 하나가 아닙니다. 다른 브라우저에서 올바른 호스트를 선택하고, 예상 conversation과 plan 또는 artifact를 열고, 위험이 낮은 작업에서 호스트와 같은 permission boundary를 확인해야 합니다. 그때부터 Remote Control을 장기 작업의 실제 운영 경로로 볼 수 있습니다.
