Antigravity CLI에서 잦은 승인 팝업 없이 쾌적하게 코딩하는 법

들어가며

최근 AI 코딩 에이전트와 페어 프로그래밍을 진행하다 보면 매번 도구 실행을 물어보는 확인 창 때문에 작업 흐름이 끊기는 이른바 승인 피로(Approval Fatigue)를 겪게 됩니다. 분명 파일 수정을 알아서 반영해 준다는 accept-edits 모드를 켰는데도 터미널 명령어나 테스트를 실행할 때마다 어김없이 승인 메뉴가 나타납니다. 이번 글에서는 왜 accept-edits 모드에서도 승인 창이 계속 뜨는지 그 구조적 원인을 짚어보고, Claude Code처럼 시원하게 자동 승인하면서도 시스템 안전을 지키는 샌드박스 설정법을 공유합니다.

Antigravity 샌드박스 자동 승인 개념 인포그래픽

핵심 개념

Antigravity의 실행 제어는 Agent Mode(에이전트 동작 모드)와 Tool Permission Policy(도구 실행 정책)라는 2개의 독립된 계층으로 나뉘어 동작합니다. Agent Mode는 파일 수정 시 diff 검토 여부를 제어하고, Tool Permission Policy는 터미널 쉘이나 외부 도구 실행 권한을 제어합니다. 두 계층의 역할을 구분하여 설정해야 불필요한 승인 팝업 없는 매끄러운 자동화 환경을 만들 수 있습니다.

비교로 이해하는 도구별 권한 모델

기존에 Claude Code, GitHub Copilot, OpenAI Codex 환경을 경험해 본 개발자라면 각 도구마다 권한을 다루는 철학이 조금씩 다르다는 점을 알고 계실 것입니다. Antigravity의 구조를 다른 주요 도구들과 비교해 보면 다음과 같습니다.

도구명	기본 실행 철학	파일 수정 자동화	쉘 명령어 자동화 방식	보안 격리 메커니즘
Claude Code	대화형 확인 중심	파일 diff 확인 후 수락	--dangerously-skip-permissions 플래그로 전면 우회	프로세스 수준 및 도구 허용 목록
GitHub Copilot	제안 및 수락 중심	에디터 인라인 diff 수락	터미널 명령 제안 후 개별 실행 확인	IDE 사용자 권한 위임
OpenAI Codex	샌드박스 실행 중심	파일 생성 및 수정 자동화	컨테이너 샌드박스 내부 자동 실행	가상 컨테이너 환경 격리
Antigravity	2계층 분리 구조	accept-edits 모드로 자동화	proceed-in-sandbox 정책으로 격리 자동 실행	로컬 터미널 샌드박스 격리

Claude Code는 개발자의 빠른 작업을 위해 --dangerously-skip-permissions라는 전면 우회 플래그를 제공합니다. Antigravity 역시 동일한 편의 플래그를 지원함과 동시에, 일상 개발 환경을 위해 파일 수정(Agent Mode)과 시스템 명령어(Tool Policy)를 2계층으로 분리하여 안전성과 속도를 동시에 만족시키는 차별화된 구조를 갖추고 있습니다.

설계 전 실측: accept-edits 모드의 한계

처음에는 accept-edits 모드만 켜면 모든 작업이 자동으로 승인될 것이라 기대했습니다. 하지만 실제 사용 과정에서 에이전트가 빌드를 돌리거나 디렉터리를 확인할 때마다 확인 메뉴가 떴습니다.

CLI 내부 명세를 직접 확인해 본 결과, accept-edits 모드의 정의는 명확했습니다. 파일 수정 도구(write_to_file, replace_file_content)는 사용자 확인 없이 자동 승인하지만, 터미널 명령어 실행(run_command)은 반드시 사용자에게 묻도록 설계되어 있었습니다. 즉, 파일 쓰기 권한만 열리고 쉘 명령어 권한은 여전히 잠겨 있었던 것입니다.

준비물

Antigravity CLI (agy) 실행 환경
터미널 접근 권한 및 텍스트 편집기
사용자 설정 파일 (~/.gemini/antigravity-cli/settings.json)

단계별 본문

1단계: Claude Code 스타일의 일회성 전면 우회 플래그 확인

터미널에서 일회성 작업을 빠르게 끝내고 싶다면 Claude Code의 bypass 모드와 동일한 명령줄 플래그를 사용할 수 있습니다.

CLI 실행 시 아래와 같이 플래그를 지정합니다.

agy --dangerously-skip-permissions

이 플래그를 붙여 실행하면 모든 도구 권한 요청을 묻지 않고 전자동으로 승인합니다. 단기적인 테스트나 격리된 환경에서 빠른 스크립트 실행이 필요할 때 유용합니다.

하지만 분명한 주의점이 있습니다. 실제로 Claude Code 커뮤니티에서는 이 우회 플래그를 일반 작업 환경에서 사용하다가, 에이전트의 경로 파싱 실수로 발생한 잘못된 rm 명령어로 인해 사용자 홈 디렉터리나 개인 데이터가 손상되는 치명적인 사고 사례가 여러 차례 공유되었습니다. 안전망이 완전히 제거된 전면 우회 모드는 일회성 폐기용 컨테이너가 아닌 일상적인 개발 장비나 운영 서버에서는 큰 위험을 동반합니다.

이 단계가 끝나면 에이전트가 도구를 호출할 때 승인 프롬프트가 단 한 번도 나타나지 않으면 성공입니다.

2단계: 상시 도구 실행 권한 정책(Tool Permission) 구조 이해

많은 개발자들은 위와 같은 위험을 피하기 위해 무거운 Docker 컨테이너를 직접 설치하고 폴더를 마운트하여 에이전트를 격리 실행하는 복잡한 우회책을 쓰기도 합니다. 반면 Antigravity는 복잡한 컨테이너 설정 없이도 OS 수준에서 즉시 동작하는 경량 내장 터미널 샌드박스를 기본 탑재하고 있습니다.

매번 긴 플래그를 입력하지 않고 상시로 안전하게 동작을 바꾸려면 Tool Permission Policy를 조정해야 합니다. Antigravity에서 제공하는 도구 실행 정책은 네 가지입니다.

request-review: 기본 상태로 모든 도구 및 명령어 실행 전 사용자 승인을 요청합니다.
strict: 가장 엄격한 수준으로 모든 작업에 대해 세부 검토를 요구합니다.
always-proceed: 명령어와 외부 호출까지 모두 묻지 않고 완전 자동 승인합니다.
proceed-in-sandbox: 샌드박스 격리 환경 안에서 안전하게 실행 가능한 명령어는 승인 없이 자동 실행하고, 외부 시스템이나 네트워크 접근 시에만 승인을 요청합니다.

24시간 무중단으로 운영되는 서버 환경에서는 무조건적인 always-proceed보다 시스템 안전망을 유지하는 proceed-in-sandbox 방식이 이상적입니다. 별도의 가상화 도구 없이도 내장 샌드박스가 워크스페이스 외부 경로를 자동으로 읽기 전용으로 잠가주기 때문입니다.

이 단계가 끝나면 자신의 작업 환경에 맞는 도구 권한 정책의 기준이 정립되면 성공입니다.

3단계: 대화형 설정(/config) 및 settings.json 적용

이제 실제로 터미널 샌드박스를 활성화하고 샌드박스 내 자동 승인 환경을 구성합니다.

CLI 대화창에서 /config 또는 /settings 명령어를 입력하여 대화형 메뉴로 들어갈 수 있으며, 설정 파일을 직접 편집할 수도 있습니다. 설정 파일 경로인 ~/.gemini/antigravity-cli/settings.json을 열어 아래 항목들을 구성합니다.

{
  "agentMode": "accept-edits",
  "enableTerminalSandbox": true,
  "toolPermission": "proceed-in-sandbox",
  "allowNonWorkspaceAccess": true,
  "queuedMessages": "send-immediately"
}

각 항목의 의미는 다음과 같습니다.

agentMode: accept-edits로 지정하여 코드 수정 diff 확인 과정을 자동 승인합니다.
enableTerminalSandbox: true로 설정하여 안전한 격리 샌드박스를 켭니다.
toolPermission: proceed-in-sandbox로 설정하여 샌드박스 내부 명령을 묻지 않고 즉시 자동 실행합니다.
allowNonWorkspaceAccess: true로 설정하여 프로젝트 외부 파일 참조 시 발생하는 불필요한 질문을 생략합니다.
queuedMessages: send-immediately로 설정하여 대기열 메시지를 즉시 전송해 응답 지연을 줄입니다.

이 단계가 끝나면 settings.json 파일에 다섯 가지 설정이 오타 없이 올바르게 저장되면 성공입니다.

4단계: 실측 검증과 예외 안전망 확인

설정 변경 후 실제 에이전트가 어떻게 반응하는지 검증을 진행했습니다.

로컬 워크스페이스 내 파일 생성, 코드 수정, 디렉터리 탐색, 단위 테스트 실행은 사용자 승인 창 없이 즉각 매끄럽게 처리되었습니다. 반면 외부 인터넷 패키지 다운로드나 시스템 레벨 데몬 조작처럼 샌드박스 격리를 우회해야 하는 명령은 여전히 사용자 승인 창을 띄워 안전망 역할을 충실히 수행했습니다.

또한 자주 사용하는 특정 외부 명령어(예: docker, openclaw 등)는 settings.json의 permissions.allow 목록에 미리 등록해 두면 번거로운 승인 절차를 우회할 수 있습니다.

이 단계가 끝나면 로컬 파일 작업과 샌드박스 명령은 자동으로 통과하고 위험한 외부 작업만 승인 창이 뜨면 성공입니다.

보안 및 주의사항

24시간 서비스 서버에서는 always-proceed 설정을 신중하게 적용해야 합니다. rm이나 kill 같은 위험 명령어가 오작동할 경우 서버 장애로 이어질 수 있습니다.
터미널 샌드박스(enableTerminalSandbox: true)를 켜 둔 상태에서 proceed-in-sandbox를 사용하는 것이 생산성과 보안의 최적 균형점입니다.
샌드박스를 우회하면서도 자주 써야 하는 특정 명령어는 permissions.allow 목록을 활용하여 화이트리스트 방식으로 선별 허용하는 것을 권장합니다.

트러블슈팅

설정 변경 후에도 계속 명령어 승인 창이 뜹니다.
agentMode만 accept-edits로 되어 있고 toolPermission이 request-review로 남아있을 가능성이 높습니다. toolPermission 항목이 proceed-in-sandbox로 설정되어 있는지 확인합니다.
샌드박스 내부인데도 파일 쓰기 오류가 발생합니다.
샌드박스는 워크스페이스 디렉터리와 /tmp, 특정 앱 경로에만 쓰기 권한을 허용합니다. 워크스페이스 외부 경로에 파일을 직접 생성하려 할 경우 읽기 전용 에러가 발생하므로 작업 경로를 워크스페이스 내부로 지정해야 합니다.
네트워크가 필요한 npm install 명령에서 승인을 묻습니다.
샌드박스는 보안 격리를 위해 외부 네트워크 접근을 기본적으로 차단합니다. 네트워크 접근은 정상적인 안전망 동작이므로 확인 후 승인하거나 필요한 경우 permissions.allow 목록에 해당 명령어를 추가합니다.
TUI 환경에서 바로 실행 모드를 바꾸고 싶습니다.
터미널 대화 도중 Shift + Tab 키를 누르면 default, accept-edits, plan 모드를 빠르게 순환하며 변경할 수 있습니다.

마무리

AI 에이전트를 도입할 때 개발자가 겪는 가장 큰 장벽 중 하나는 끊임없이 반복되는 승인 질문입니다. 파일 수정만 열어주는 accept-edits 모드에 그치지 않고, enableTerminalSandbox와 proceed-in-sandbox 정책을 함께 결합하면 안전성과 개발 속도를 모두 잡을 수 있습니다. 일회성 무제한 실행이 필요할 때는 --dangerously-skip-permissions 플래그를, 안정적인 일상 개발 환경에는 샌드박스 자동 승인 세팅을 활용해 보시기 바랍니다.