자율성의 다이얼: 권한 설정

Antigravity를 처음 열면 많은 사람이 테마보다 먼저 이런 질문과 마주칩니다. 에이전트에게 어디까지 맡길 것인가? 이 질문은 단순한 취향 문제가 아닙니다. 권한 설정은 곧 작업 방식의 설계입니다. 너무 보수적으로 잡으면 팝업이 끊임없이 떠서 자동화가 수동노동이 되고, 너무 느슨하게 풀면 한 번의 잘못된 판단이 파일 삭제나 민감 정보 노출로 이어질 수 있습니다. Antigravity는 이런 행동을 통합 권한 시스템으로 다루며, 각 작업을 Allow와 Deny 규칙으로 제어합니다.¹

이 장의 핵심은 간단합니다. 속도는 나중에 올려도 됩니다. 하지만 권한 설계는 처음에 잘 잡아야 합니다. 그래야 에이전트가 유능한 동료로 남지, 허락 버튼만 기다리는 팝업 머신이 되지 않습니다.

개발 스타일은 사실 권한 프리셋이다

온보딩에서 보이는 Agent-driven, Review-driven, Agent-assisted 같은 개발 스타일은 멋진 이름이 붙은 성향 테스트가 아닙니다. 사실상 여러 권한 정책을 한 번에 묶어 둔 프리셋입니다. 터미널 명령을 얼마나 자동으로 실행할지, Artifact 리뷰를 언제 요구할지, 브라우저에서 JavaScript 실행을 얼마나 허용할지를 함께 정하는 셈입니다.²

Review-driven은 가장 보수적입니다. 에이전트가 자주 멈추고 사람에게 확인을 요청합니다. 처음 도입하는 팀, 레거시 저장소, 운영과 가까운 민감한 프로젝트에 잘 맞습니다. 반대로 Agent-driven은 거의 끊김 없이 밀어붙입니다. 데모용 스캐폴딩이나 버려도 되는 실험용 브랜치에서는 시원하지만, 중요한 저장소에서 곧바로 쓰기에는 과감합니다. 그 사이에 Agent-assisted가 있습니다. 자주 묻지는 않되, 필요하다고 판단할 때 검토를 요청하는 균형형 설정입니다.

실전에서는 이 순서를 권합니다. 처음 며칠은 Review-driven으로 에이전트의 습관을 관찰하고, 익숙해지면 Agent-assisted로 올립니다. Agent-driven은 "신뢰하는 프로젝트 + 격리된 작업공간 + 되돌릴 수 있는 브랜치"라는 세 조건이 충족될 때만 켜는 편이 좋습니다. 자동차로 치면 바로 스포츠 모드로 출발하지 말고, 먼저 브레이크 감도를 확인하라는 이야기입니다.

터미널 실행 정책이 진짜 자율성의 중심이다

에이전트가 코드를 고치는 것보다 더 위험한 일은, 당신의 셸을 대신 두드리는 일입니다. 그래서 권한 설정에서 가장 먼저 봐야 할 것은 터미널 실행 정책입니다. 문서나 버전에 따라 이름은 조금 다르게 보일 수 있습니다. 어떤 화면에서는 Always Proceed, Agent Decides, Request Review로 보이고, 다른 설명에서는 Turbo, Auto, Off처럼 소개되기도 합니다. 이름은 조금 달라도 뜻은 크게 다르지 않습니다.²

Request Review 또는 Off는 모든 명령을 실행 전에 보여 주는 방식입니다. 가장 안전하지만 가장 자주 흐름이 끊깁니다. Agent Decides 또는 Auto는 에이전트가 비교적 안전한 명령은 넘기고, 위험하다고 판단한 순간만 확인을 요청합니다. 대다수 사용자가 처음 정착하기 좋은 지점은 여기입니다. Always Proceed 또는 Turbo는 Deny List에 걸리지 않는 한 거의 다 자동 실행합니다. 속도는 가장 빠르지만, 안전장치를 직접 설계하지 않으면 무섭게도 빨라집니다.

중요한 것은 "무슨 정책이 최고인가"가 아닙니다. "내 저장소의 피해 반경에 맞는가"가 중요합니다. 개인 사이드 프로젝트라도 결제 키가 들어 있는 .env가 붙어 있으면 보안 민감도는 갑자기 높아집니다. 반대로 임시 샌드박스에서 새 앱 뼈대를 만드는 일이라면 높은 자율성이 오히려 합리적일 수 있습니다.

Allow List와 Deny List는 서로 다른 철학이다

여기서 많은 초보자가 헷갈립니다. Allow List와 Deny List는 비슷해 보여도 역할이 다릅니다.

Allow List는 "이것은 자동 승인해도 된다"는 양성 보안 모델입니다. 주로 보수적인 정책, 즉 Off나 Request Review와 함께 빛납니다. Deny List는 "이건 절대 자동으로 지나가면 안 된다"는 음성 보안 모델입니다. 주로 공격적인 정책에서 안전벨트 역할을 합니다.¹³

안전한 기본 운영을 원한다면, 첫 주에는 Off 또는 Request Review에 작은 Allow List를 붙이는 편이 좋습니다. 예를 들어 다음 같은 명령은 비교적 안전하게 시작할 수 있습니다.

• ls, pwd, git status, git diff

• npm test, npm run lint, pytest, jest

• tsc --noEmit 같은 정적 검사 명령

반대로 처음부터 Deny List에 넣어 둘 만한 명령도 꽤 명확합니다.

• rm, rmdir, del, Remove-Item 같은 삭제 계열

• sudo, su, ssh, scp, curl, wget 같은 권한 상승·외부 통신 계열

• git push, git reset --hard, npm publish, docker push 같은 되돌리기 어렵거나 외부 영향이 큰 명령

여기서 한 가지 팁이 있습니다. 읽기 전용처럼 보여도 민감한 파일을 노출할 수 있는 명령은 처음에는 과신하지 않는 편이 좋습니다. 예를 들어 파일 내용을 그대로 출력하는 명령은 .env나 키 파일을 콘솔에 드러낼 수 있습니다. "안전해 보이는 명령"과 "실제로 안전한 명령"은 다를 때가 많습니다.

브라우저 권한은 편리한 검증기이자 외부 입력 창구다

Antigravity의 브라우저 서브에이전트는 매우 매력적입니다. 페이지를 열고, 클릭하고, 스크롤하고, 입력하고, 콘솔 로그를 읽고, 필요하면 JavaScript까지 실행할 수 있습니다.² 문제는 이 능력이 커질수록 외부 웹 콘텐츠와 직접 접촉한다는 점입니다. 다시 말해, 브라우저 권한은 편리한 검증 기능이면서 동시에 외부 세계로 열린 창문이기도 합니다.

그래서 브라우저 설정은 두 겹으로 보는 것이 좋습니다. 첫째는 JavaScript 실행 정책입니다. 처음에는 Request Review로 두는 편이 안전합니다. 로컬 개발 서버나 확실히 신뢰하는 스테이징 환경에서만 점진적으로 자율성을 높이십시오. 둘째는 URL Allowlist입니다. 브라우저가 허용 목록 밖 URL로 이동하려 하면 Antigravity는 확인을 요청하고, 사용자가 항상 허용을 누르면 그 주소가 허용 목록에 추가됩니다.³

이 허용 목록은 욕심내지 않는 것이 좋습니다. 시작은 localhost, 팀 스테이징 도메인, 공식 문서 사이트 정도면 충분합니다. 검색 결과에서 우연히 들어간 임의의 블로그, 광고가 많은 문서 미러, 파일 다운로드 사이트까지 자동 허용해 두면 브라우저는 테스트 도구가 아니라 위험한 통로가 됩니다.

특히 기억할 점이 있습니다. 에이전트가 웹을 읽고, 로컬 파일에 접근하고, 외부로 통신할 수 있는 권한을 동시에 가지면 위험이 크게 커집니다. 그래서 민감한 프로젝트일수록 브라우저 자율성은 늦게 열고, 파일 접근 범위는 좁게 유지하는 편이 낫습니다.

안전한 기본값은 이렇게 잡아라

이제 가장 실용적인 결론을 내리겠습니다. 처음 도입하는 독자라면 아래 세 단계 중 첫 번째 프로필에서 시작하면 됩니다.

첫 도입 3일

개발 스타일은 Review-driven으로 둡니다. 터미널은 Off 또는 Request Review로 두고, Allow List에는 상태 확인과 테스트 계열 명령만 넣습니다. 브라우저 JavaScript는 Request Review, URL Allowlist는 localhost와 공식 문서만 허용합니다. 작업공간 밖 파일 접근은 꺼 두는 편이 안전합니다.²

이 단계의 목적은 생산성이 아닙니다. 에이전트가 어떤 식으로 계획하고, 어떤 순간에 과감해지는지 감을 익히는 것입니다.

신뢰하는 프로젝트에서의 기본 운영

이제 개발 스타일을 Agent-assisted로 올립니다. 터미널은 Auto 또는 Agent Decides로 바꾸고, 테스트와 린트 외에 의존성 설치 같은 자주 쓰는 명령을 조금씩 Allow List에 추가합니다. 대신 Deny List의 삭제, 외부 통신, 배포 계열 명령은 유지합니다. 브라우저는 로컬과 스테이징만 허용하고, JavaScript는 여전히 리뷰 중심으로 가는 편이 안전합니다.

대부분의 개발자는 여기서 가장 오래 머뭅니다. 속도와 안정성이 동시에 나오는 지점이기 때문입니다.

고속 자율 실행이 필요한 순간

새 프로젝트 뼈대를 빠르게 만들거나, 격리된 worktree에서 실험할 때만 Agent-driven을 씁니다. 터미널은 Turbo나 Always Proceed로 올릴 수 있지만, 그 전제는 탄탄한 Deny List, 버려도 되는 브랜치, 중요한 자격 증명이 없는 환경입니다. 고속 모드는 "실력이 늘면 항상 쓰는 모드"가 아니라, "조건이 맞을 때만 꺼내는 특수 모드"에 가깝습니다.

팀이 가장 자주 하는 실수

권한 설정에서 반복되는 실수는 늘 비슷합니다.

• 처음부터 모든 권한을 열어 놓고, 에이전트가 한 번 사고를 낸 뒤 전체 도입을 포기한다.

• 반대로 모든 것을 매번 승인하게 만들어 놓고, 팝업 피로 때문에 결국 기능을 거의 쓰지 않게 된다.

• Allow List와 Deny List를 개인 취향으로만 관리하고, 팀 기준으로 공유하지 않는다.

좋은 운영은 그 가운데 있습니다. 작은 안전 목록으로 시작하고, 실제로 반복되는 작업만 점진적으로 자동화해야 합니다. 자율성은 신뢰의 결과이지, 신뢰의 출발점이 아닙니다.

결국 권한 설정은 개발 문화다

Antigravity에서 권한은 단순한 보안 옵션이 아닙니다. 개발자가 에이전트를 어떻게 대할지 결정하는 운영 문화에 가깝습니다. "일단 다 막고 내가 직접 한다"도 답이 아니고, "알아서 해"도 답이 아닙니다. 좋은 설정은 에이전트가 반복 작업은 시원하게 처리하되, 파괴적이거나 외부 영향이 큰 순간에는 반드시 멈추게 만드는 것입니다.

한 줄로 요약하면 이렇습니다. 처음에는 느리게 설정하고, Artifacts와 실행 결과를 보며 신뢰를 쌓으십시오. 그러고 나서 자율성의 다이얼을 한 칸씩 올리십시오. Antigravity의 진짜 속도는 무턱대고 풀어 줄 때가 아니라, 잘 설계된 가드레일 안에서 가장 안정적으로 나옵니다.

참고

¹Agent permissions

²Google Antigravity 시작하기

³Allowlist and denylist