Google Antigravity MCP 어떻게 배포할까? 2026 클라우드 맥 권한 설정과 검수

Google 공식 문서는 Antigravity Agent에서 MCP 서버를 연결하고 도구별 허용 범위를 설정할 수 있다고 안내합니다. Google Antigravity Agent 공식 문서의 기능 범위를 기준으로 보면, Google Antigravity MCP 배포는 격리된 클라우드 맥에서 원격 주소와 도구 하나를 먼저 검증한 뒤 권한을 넓히는 방식이 적합합니다. 전역 MCP 권한을 곧바로 운영 작업에 적용해서는 안 됩니다.

이 글은 로컬 환경에서 Google Antigravity를 사용하다가 클라우드 맥이나 원격 개발 환경으로 옮기려는 개발자를 위한 안내입니다. 팀의 MCP, 비밀 값, 실행 권한을 관리해야 하는 책임자와 로컬 맥과 원격 환경 중 무엇을 선택할지 비교하는 담당자도 대상입니다.

첫 단계: 배포 범위와 연결 방식을 먼저 나눕니다

Google Antigravity CLI, Gemini API Agent, MCP는 같은 역할을 하지 않습니다. CLI는 개발 환경에서 명령과 프로젝트를 다루는 실행 경로이고, Gemini API Agent는 모델 기반 작업을 조정하는 계층입니다. MCP는 외부 도구와 서버 기능을 정해진 방식으로 연결하는 인터페이스입니다. 따라서 Antigravity를 설치했다고 해서 외부 MCP 서버의 권한이 자동으로 안전해지는 것은 아닙니다.

먼저 MCP를 두 종류로 나눕니다.

로컬 MCP: 클라우드 맥 안에서 프로세스를 실행하고 같은 환경의 파일이나 명령과 연결합니다.
streamable HTTP MCP: 원격 URL을 통해 MCP 서버에 접속합니다. 이 방식은 URL, 인증 헤더, 네트워크 출구, 서버 응답을 각각 확인해야 합니다.

Google Developers의 MCP 설정 안내는 서버 연결에 필요한 설정 구조를 확인하는 기준으로 사용할 수 있습니다. 배포 전에는 다음 다섯 항목을 체크합니다.

[ ] 클라우드 맥의 프로젝트 디렉터리와 임시 테스트 디렉터리를 분리했습니다.
[ ] MCP 서버의 원격 URL을 문서에 적힌 주소와 대조했습니다.
[ ] 인증 값이 환경 변수나 비밀 저장소에 있으며 코드에 직접 들어 있지 않습니다.
[ ] 클라우드 맥의 네트워크 출구에서 원격 주소로 접속할 수 있습니다.
[ ] 파일 읽기, 명령 실행, MCP 도구 호출을 서로 다른 권한으로 관리할 계획이 있습니다.

읽기 전용 조회나 구조화된 데이터 추출은 테스트 환경에 적합합니다. 반대로 비밀 값, 결제 정보, 운영 데이터, 외부 시스템에 대한 쓰기 작업은 초기 연결 검증에 사용해서는 안 됩니다.

두 번째 단계: MCP 등록은 도구 하나로 끝까지 확인합니다

Antigravity에 MCP Server를 추가할 때는 이름, URL, 요청 헤더, allowed_tools를 한꺼번에 확인합니다. 서버 이름은 팀에서 쉽게 식별할 수 있게 정하고, 같은 이름을 가진 서버가 여러 개 생기지 않도록 규칙을 문서화합니다. URL에는 테스트용 주소와 운영용 주소를 섞지 않습니다.

공식 Antigravity 시작 실습 자료를 참고하더라도 실제 원격 서버의 인증 방식과 허용 도구 이름은 서버 문서를 기준으로 확인해야 합니다. 모든 MCP 서버가 같은 헤더 이름이나 입력 구조를 사용하는 것은 아니기 때문입니다.

권장하는 최소 연결 순서는 다음과 같습니다.

테스트용 프로젝트 디렉터리를 준비합니다.
MCP 서버 이름과 원격 URL만 먼저 등록합니다.
인증 헤더를 추가하고 비밀 값이 로그에 노출되지 않는지 확인합니다.
읽기 전용 도구 1개만 allowed_tools에 넣습니다.
간단한 조회를 실행하고 도구 이름, 입력값, 반환 형식을 기록합니다.
연결을 종료한 뒤 같은 세션 또는 새 세션에서 복구되는지 확인합니다.

연결이 실패하면 추측으로 설정을 계속 바꾸지 말고 순서를 고정합니다. 첫째 URL과 네트워크 출구를 검사합니다. 둘째 인증 헤더와 만료 여부를 확인합니다. 셋째 MCP 서버가 기대한 프로토콜 응답을 반환하는지 봅니다. 넷째 allowed_tools의 이름과 실제 도구 이름이 정확히 일치하는지 대조합니다.

주의: 연결 성공은 안전한 권한 구성을 의미하지 않습니다. 서버에 접속되더라도 파일 접근이나 명령 실행이 별도로 허용되어 있을 수 있으므로, 성공 로그와 권한 검수 결과를 분리해 저장해야 합니다.

세 번째 단계: 파일, 명령, MCP 권한을 따로 승인합니다

Antigravity MCP 권한 설정에서 가장 위험한 부분은 전역 와일드카드입니다. 모든 파일을 뜻하는 패턴, 모든 명령을 뜻하는 패턴, 모든 MCP 도구를 뜻하는 패턴을 동시에 적용하면 모델의 실수나 잘못된 도구 입력이 큰 범위로 전달될 수 있습니다.

권한은 다음 세 갈래로 나누어 검토합니다.

read_file: 읽을 수 있는 디렉터리를 프로젝트 안으로 제한합니다. 비밀 값이 저장된 경로와 운영 설정 파일은 기본 거부로 둡니다.
command: 실행 가능한 명령과 작업 디렉터리를 제한합니다. 설치, 삭제, 네트워크 변경처럼 결과가 큰 명령은 자동 실행보다 확인 단계를 둡니다.
MCP 도구: 서버 전체가 아니라 특정 서버의 특정 도구만 허용합니다. 쓰기 도구는 읽기 도구와 같은 목록에 넣지 않습니다.

개발 단계에서는 테스트 프로젝트의 읽기와 제한된 명령만 허용합니다. 검증 단계에서는 구조화된 추출과 한 번의 통제된 쓰기를 추가하되, 쓰기 대상과 입력값을 고정합니다. 운영 단계에서는 외부 시스템 변경, 결제 관련 작업, 소스 저장소 반영을 사람의 확인 뒤에 실행하도록 정책을 둡니다.

Google Cloud MCP 접근 제어 문서는 접근 범위를 관리할 때 권한을 넓게 부여하기보다 필요한 범위로 제한하는 기준을 제공합니다. IAM 연동이 필요한 환경에서는 MCP IAM 권한 문서도 함께 검토해야 합니다.

네 번째 단계: 첫 작업은 세 가지 검수로 나눕니다

복잡한 Agent 작업을 곧바로 실행하면 모델 오류, MCP 서버 오류, 원격 맥 오류를 구분하기 어렵습니다. 첫 검수는 작은 작업 세 가지로 나누는 편이 좋습니다.

첫째는 읽기 전용 조회입니다. 정해진 파일이나 공개 테스트 데이터에서 값을 읽고, 반환 내용이 예상한 구조인지 확인합니다. 둘째는 구조화된 추출입니다. 입력과 출력 형식을 고정해 도구가 엉뚱한 인자를 받지 않는지 봅니다. 셋째는 통제된 쓰기입니다. 되돌릴 수 있는 테스트 파일 하나에만 기록하고, 변경 전후 내용을 비교합니다.

각 단계에서 다음 기록을 남깁니다.

연결 성공 여부와 시각
호출한 MCP 서버와 도구 이름
전달한 입력의 형식
도구 반환값과 오류 메시지
재시도 여부와 재시도 뒤 결과
세션 종료 후 로그와 상태 복구 여부

모델이 잘못된 도구를 선택했다면 추론 또는 도구 설명 문제일 수 있습니다. 서버가 인증을 거부했다면 MCP 서비스 문제일 가능성이 큽니다. 연결 자체가 끊기거나 프로젝트 파일이 보이지 않는다면 클라우드 맥의 네트워크, 세션, 디스크 또는 작업 디렉터리를 먼저 확인해야 합니다.

Google의 Agent Hooks 안내는 Agent 실행 전후의 제어 지점을 검토할 때 참고할 수 있습니다. 다만 훅을 추가했다고 해서 위험한 명령이나 외부 쓰기가 자동으로 차단된다고 가정해서는 안 됩니다.

다섯 번째 단계: 팀에 배포하기 전 운영 항목을 고정합니다

개인 테스트가 성공한 뒤에는 설정 파일을 그대로 팀에 복사하지 않습니다. 먼저 비밀 키의 생성 위치와 보관 위치를 정하고, 담당자가 바뀌어도 회수할 수 있는 절차를 만듭니다. 키를 교체한 뒤 이전 키가 실제로 거부되는지 확인해야 합니다.

운영 전 점검 목록은 다음과 같습니다.

[ ] MCP 서버별 담당자와 승인자를 정했습니다.
[ ] 새 서버를 등록할 때 URL과 제공 도구를 검토하는 절차가 있습니다.
[ ] 사용하지 않는 도구와 이전 인증 키를 철회했습니다.
[ ] 설정 파일의 버전과 변경 이유를 기록합니다.
[ ] 오류 로그에 인증 값이나 소스 비밀 값이 남지 않습니다.
[ ] 클라우드 맥의 디스크 사용량과 로그 보존 정책을 확인했습니다.
[ ] 동시 세션 수와 유휴 세션의 종료 기준을 정했습니다.
[ ] 장시간 실행이 필요한 작업과 일회성 검증 작업을 분리했습니다.

단일 클라우드 맥은 개인 개발, 짧은 검증, 분리된 프로젝트에 적합합니다. 여러 팀이 같은 MCP 서버를 사용하거나 권한 승인과 감사 로그를 중앙에서 관리해야 한다면, 단일 원격 맥에 설정을 계속 덧붙이기보다 중앙 Agent 실행 환경을 검토하는 편이 낫습니다. 이때도 물리 장치 접근, macOS 전용 도구, 별도 GUI 세션이 필요하다면 클라우드 맥을 유지해야 합니다.

클라우드 맥의 준비 환경이 필요한 경우에는 Vuncloud의 맥 미니 대여 안내에서 제공 방식과 사용 조건을 확인할 수 있습니다. 연결 전에 환경 지원 범위를 확인하려면 Vuncloud 지원 안내도 함께 살펴보는 것이 좋습니다.

자주 묻는 내용

FAQ에서는 Google Antigravity에 MCP Server를 추가하는 순서, 권한을 세분화하는 방법, 클라우드 맥의 네트워크와 비밀 값 관리, 호출 실패 원인 분류를 각각 다룹니다. 특히 연결이 성공한 뒤에도 도구별 승인과 사람의 확인이 남아 있다는 점을 놓치지 않아야 합니다.

현재 로컬 맥에서 모든 권한을 한 번에 허용하는 방식은 초기에는 편해 보여도, 프로젝트 경로와 비밀 값이 섞이고 작업 기록을 재현하기 어렵다는 단점이 있습니다. 반면 Vuncloud의 클라우드 맥은 작업 공간을 분리하고 필요할 때 원격 개발 환경을 마련하기 쉽기 때문에, 단기 테스트나 팀 표준 환경 검증에는 더 나은 선택이 될 수 있습니다. 다만 장기간 고정 부하, 특수한 물리 장치 연결, 로컬 네트워크에만 접근 가능한 업무라면 직접 보유한 맥이 더 적합할 수 있습니다.

MCP를 읽기 전용 도구 하나로 연결한 뒤 권한과 로그를 확인하는 단계까지 완료했다면, 다음에는 원격 Agent 권한 격리와 클라우드 맥 환경 검수 기준을 별도로 정리해야 합니다. 그 기준을 통과한 뒤에만 외부 쓰기 작업과 팀 공용 MCP 서버를 추가하는 순서가 안전합니다.