구글 Antigravity SDK에서 가장 인상 깊었던 단 한 줄의 코드

Agent SDK를 고를 때 나는 항상 이걸 먼저 본다: “기본값이 무엇인가” 기능 목록이 아니다. API 설계도 아니다. pip install 하고 Hello World를 띄웠을 때, 에이전트가 기본적으로 무엇을 할 수 있는가 — 그게 그 SDK의 철학을 가장 정직하게 드러낸다.

Google의 Antigravity SDK(github.com/google-antigravity/antigravity-sdk-python)를 설치하고 첫 예제를 돌려본 날, 나는 이 기본값 하나에 꽂혔다:

기본값: 읽기 전용(read-only). 모든 도구가 차단되어 있다.

도대체 어떤 SDK가 “기본적으로 아무것도 못 하게” 만들어놨을까? OpenAPI Agents SDK는 함수만 등록하면 바로 실행한다. Claude Code SDK도 기본값이 전체 접근이다. 그런데 Google은 “일단 다 막고, 필요한 것만 열어라”는 철학으로 SDK를 설계했다. 이게 단순한 안전장치가 아니라, 2026년 AI 에이전트의 새로운 패러다임을 보여준다고 생각한다.

이 글에서 다루는 것

Antigravity SDK의 Policy 시스템 구조와 철학
deny / allow / ask_user 3단계 정책의 실제 동작 방식
다른 SDK들과의 안전 기본값 비교
이 설계가 agent 개발 패러다임에 주는 시사점
Drewgent에 적용한다면 어떻게 쓸 수 있을까

Policy 시스템: 다 막고 하나씩 푼다

Antigravity SDK는 LocalAgentConfig의 policies 파라미터로 도구 접근 제어를 선언한다. 코드로 보면 이렇다:

from google.antigravity import LocalAgentConfig
from google.antigravity.hooks.policy import deny, allow, ask_user

policies = [
    deny("*"),                          # 1. 모든 도구 차단
    allow("view_file"),                 # 2. 읽기만 허용
    ask_user("run_command", handler=my_handler),  # 3. 명령 실행은 허가제
]

config = LocalAgentConfig(
    capabilities=CapabilitiesConfig(),
    policies=policies,
)

핵심은 deny(“*”)가 기본값이 아니라 명시적으로 첫 줄에 박혀 있다는 점이다. “필요한 것만 열겠다”는 의도를 코드 레벨에서 강제한다. 실수로 policy를 깜빡해도, 기본 read-only 모드가 모든 위험을 차단한다.

3단계 접근 제어

deny(pattern) — glob 패턴으로 도구 차단. “*”는 전체 차단.
allow(pattern) — 특정 도구만 허용. “view_*”, “read_*” 같은 안전한 패턴.
ask_user(pattern, handler) — 위험한 도구는 실행 전에 사용자에게 확인. handler로 승인 로직 커스터마이징 가능.

이 3단계가 주는 실용적 이점은 퇴출 경로(escape hatch)를 설계에 포함시켰다는 것이다. 완전 차단(deny)에서 시작해, 안전한 도구는 영구 허용(allow), 위험하지만 필요한 도구는 조건부 허용(ask_user) — 이 피라미드는 Zero Trust 보안 모델과 정확히 같은 패턴이다.

왜 이게 중요한가

2026년 기준, 대부분의 AI agent SDK는 “실수로 위험한 도구를 실행하는 것”을 전적으로 개발자 책임으로 남겨둔다.

오픈소스 에이전트 SDK들은 이런 구조다:

OpenAI Agents SDK — function tool 등록 = 즉시 실행 가능. guardrail은 별도 구현.
Anthropic Claude Agent SDK — tool use가 기본. MCP 서버 도구도 자동 등록.
LangChain — Tool 객체 생성 = 호출 가능. 접근 제어는 Tool 커스텀 로직으로 직접 구현.
Vercel AI SDK — 도구 등록 시 자동으로 LLM에 노출. 별도 게이트 없음.

이 SDK들의 공통 가정은 “개발자가 등록한 도구는 안전하다”는 것이다. 하지만 MCP 서버를 연결하고, 외부 플러그인을 불러오고, 서드파티 도구를 등록하기 시작하면 이 가정은 금방 깨진다. 악성 MCP 서버가 rm -rf를 도구로 제공하면? AI가 내 파일 시스템에 접근하는 걸 막을 장치가 없다.

Antigravity의 접근법은 2026년의 현실을 반영한다: 에이전트는 점점 더 많은 도구에 접근하게 될 것이고, 모든 도구가 안전하다고 보장할 수 없다. 따라서 구조적 불가능 — “하지 마” 대신 차단하는 설계 — 을 SDK 레벨에서 구현했다.

MCP와의 시너지

Antigravity SDK가 네이티브 MCP 지원을 내장한 건 우연이 아니다. MCP 서버는 외부에서 가져오는 도구 묶음이다. 그 도구들 중 어떤 건 파일 읽기고, 어떤 건 DB 쓰기고, 어떤 건 결제 승인일 수 있다. 이 모든 도구를 일괄 deny하고 필요한 것만 allow하는 정책은 MCP 시대에 가장 적합한 보안 모델이다.

from google.antigravity import Agent, LocalAgentConfig
from google.antigravity.types import McpStdioServer

policies = [
    deny("*"),
    allow("read_*"),
    allow("search_*"),
    ask_user("write_*", handler=confirm_write),
]

config = LocalAgentConfig(
    mcp_servers=[
        McpStdioServer(name="my_server", command="npx", args=["my-mcp-server"]),
    ],
    policies=policies,
)

MCP 서버에서 가져온 모든 도구는 자동으로 deny("*")에 걸린다. read_*만 allow했으니, MCP 서버가 쓰기 도구를 제공해도 에이전트는 실행할 수 없다. MCP 서버 개발자의 의도와 무관하게, SDK 사용자의 정책이 우선한다.

이 설계가 Drewgent에 주는 교훈

Drewgent에서도 비슷한 고민을 하고 있다. P0-brainstem/brain/rules.md에 禁(금) 규칙을 두고, neuron-fs-brain이 파일시스템 레벨에서 접근을 차단한다. vault와 secrets 파일은 opencode watcher exclude에 등록되어 있고, chmod 600으로 OS 레벨에서도 막혀 있다. 구조적 불가능의 다른 구현이다.

Antigravity SDK의 policy 시스템은 이와 같은 구조적 불가능을 SDK 레벨로 가져온 사례다. Drewgent의 Layer 0 (OS/파일시스템) 보안에 Layer 1.5 (SDK 정책)이 추가된 셈이다. 앞으로 에이전트 SDK를 고를 때, “기본값이 무엇인가”를 가장 먼저 확인해야겠다는 생각이 들었다.

한계와 아쉬운 점

물론 완벽한 시스템은 아니다. Antigravity SDK의 policy는 현 시점에서 Python 함수와 MCP 도구에만 적용된다. LLM이 도구 없이도 할 수 있는 행동(프롬프트 인젝션, 환각)은 policy의 범위 밖이다. 또한 policy는 config에서 한 번에 선언되지만, 런타임에 동적으로 변경하거나 외부 정책 서버와 연동하는 기능은 아직 없다.

하지만 방향성은 명확하다. “기본적으로 안전하고, 필요한 만큼만 열어라” — 이 철학이 앞으로 모든 agent SDK의 표준이 될 거라고 본다. Google이 가장 먼저 이 방향을 SDK 레벨에서 구현한 점은 인상적이다.

요약

Antigravity SDK를 평가할 때, 사람들은 보통 “Gemini만 지원한다”거나 “생태계가 작다”는 점을 지적한다. 맞는 말이다. 하지만 policy 시스템 하나만으로 이 SDK는 다른 모든 agent SDK와 다른 위치에 서 있다.

기능은 따라올 수 있다. API 설계는 개선될 수 있다. 하지만 “기본값으로 읽기 전용”이라는 설계 결정은 SDK의 DNA다. 뒤집기는 쉽지 않다. Google이 Antigravity SDK를 설계하면서 가장 먼저 “안전하지 않으면 출시하지 않는다”는 원칙을 세웠다는 증거다.

앞으로 다른 SDK들이 이와 같은 정책 시스템을 도입할지, 아니면 Google의 접근법이 과도한 제한으로 판명날지 지켜보는 재미가 있을 것 같다. 개인적으로는 — 구글의 베팅이 맞았다고 생각한다.

에이전트가 더 많은 권한을 가질수록, 그 권한을 어떻게 제어할지가 더 중요해진다. Antigravity SDK는 이 질문에 가장 먼저 답을 내놓은 제품이다.

읽어줘서 고맙다. 다음 글에서는 Antigravity SDK의 Triggers 시스템을 파헤쳐볼 생각이다. “에이전트가 스스로 주기적으로 작업을 실행한다”는 게 실제로 어떻게 동작하는지 — 거기에도 재미있는 설계 결정이 숨어 있다.