AI 에이전트에게 독립된 Sandbox가 필요한 이유

URL: https://www.youtube.com/watch?v=oWTEiYpxl80 날짜: 2026-10-08 채널: aiDotEngineer 발표자: Philipp Schmid, Google DeepMind

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 에이전트는 단순히 모델에 프롬프트를 보내는 존재가 아니라, 목표를 추론하고 도구를 실행하며 파일·코드·의존성을 다루는 독립된 실행 환경(Sandbox)을 가져야 한다.==

• Interactions API는 모델과 에이전트를 같은 호출 인터페이스로 다루고, 서버 측 상태·비동기 장기 실행·도구 사용을 제공한다.
• 원격 환경(Remote Environment)은 코드 실행, 파일 생성, 의존성 설치, 사용자 도구와 API 호출을 격리된 클라우드 Sandbox에서 맡아 개발자가 인프라를 직접 운영하지 않게 한다.
• Agents API와 파일 기반 구성(AGENTS.md, skills)은 이미 준비된 환경을 여러 사용자·에이전트가 재사용하도록 만들며, 에이전트가 다른 에이전트를 위한 환경을 스스로 준비할 수도 있게 한다.

LLM의 발전은 다음 단어 예측에서 지시 이행, 대화, 함수 호출을 거쳐 목표·추론·행동을 장시간 수행하는 에이전트로 이동했다. 이 단계에서는 함수 호출을 클라이언트가 중계하는 구조보다, 모델과 도구·파일·실행 루프를 하나의 서버 측 Sandbox에 넣는 구조가 자연스럽다. Google의 Gemini API는 이런 구조를 Interactions API, Agents API, Anti-gravity harness, 원격 환경으로 묶어 제공한다.

1. LLM에서 장시간 실행 에이전트로의 전환

단일 응답을 생성하던 모델은 점차 목표를 달성하기 위해 생각하고 행동하고 검증하는 시스템으로 확장됐다.

1.1. 텍스트 생성에서 지시 이행으로

1. 초기 언어 모델의 역할

   1. BERT·GPT 시기의 기대: 2018~2019년 무렵에는 앞에 몇 단어만 주면 문장을 자연스럽게 이어 쓰는 능력이 큰 진전으로 받아들여졌다.
   2. 시의 생성과 한계: 모델은 첫 몇 단어로 시를 계속 쓸 수 있었지만, 그 자체로 사람이 실제 작업을 완수하는 데 유용한 도구는 아니었다.

2. Instruction Following의 등장

   1. 질문-응답 구조: 사전학습 모델이 텍스트를 이어 쓰는 모델이었다면, 지시 이행 모델은 질문을 받고 적절한 답을 내놓도록 훈련됐다.
   2. 유용성의 증가: 사용자는 모델에게 질문을 직접 전달하고 답을 받는 방식으로 모델을 실제 작업에 사용하기 시작했다.

1.2. 대화와 함수 호출에서 에이전트로

1. ChatGPT식 User-Model Turn

   1. 턴 기반 대화: ChatGPT 이후에는 사용자 입력과 모델 출력이 번갈아 이어지는 대화 구조가 대중화됐다.
   2. Function Calling의 결합: 모델이 외부 작업을 수행해야 하므로 함수 호출이 붙었고, 모델의 답변이 실제 행동으로 연결됐다.

2. 현재의 에이전트 구조

   1. 목표 중심 실행: 사용자는 매번 문장을 생성하라고 시키는 대신 목표를 부여하고, 목표를 검증하거나 배포하는 방법까지 에이전트에게 맡긴다.
   2. 장시간 작업: 에이전트는 몇 시간 또는 며칠 동안 실행된 뒤 결과를 돌려줄 수 있어야 한다.
   3. 블랙박스 안의 세 요소: 목표(goal), 생각·추론(thinking), 함수·도구(functions)가 서로 연결된 실행 루프를 이룬다.

2. Gemini API와 Interactions API의 설계

Interactions API는 모델 응답 하나를 받는 API가 아니라, 모델 또는 에이전트와 여러 단계로 상호작용하는 개발자 중심 인터페이스다.

2.1. 빠르게 접근하는 Gemini 개발 환경

1. AI Studio 중심의 진입

   1. 간단한 시작: AI Studio 또는 Google의 AI 개발자 사이트에서 Gmail 계정으로 별도 설정 없이 실험을 시작하고 API 키를 발급할 수 있다.
   2. 사용량 제어: 더 큰 모델이나 많은 사용량이 필요하면 결제 수단을 등록할 수 있고, Google Cloud로 이동하지 않아도 AI Studio 안에서 예산을 설정할 수 있다.
   3. 개발자의 안전장치: 예산 설정은 실험 비용이 통제 불능으로 커지는 것을 막는다.

2. 최근 모델 출시가 보여주는 속도

   1. Nano Banana Light: 발표 전날 출시된 새 이미지 생성 모델로, 매우 빠르고 이미지 한 장당 약 4센트라는 낮은 가격을 강조했다.
   2. Omni Flash와 Interactions API: Omni Flash를 Interactions API에서 사용할 수 있게 되어, 프로그램으로 동영상을 만들고 편집하며 생성형 미디어(Generative Media) 애플리케이션을 만들 수 있다.
   3. 슬라이드의 유효기간: Gemini·Gemma의 지난 2년 성과를 보여주던 발표 슬라이드조차 새 출시 때문에 이미 최신 상태가 아니게 됐다.

2.2. 모델과 에이전트를 하나로 호출하는 방식

1. OpenAI Responses API에 대한 Google식 답변

   1. 개발자 친화성: Interactions API는 Responses API와 비슷한 문제를 다루지만 더 단순하고 웹 개발자에게 친숙한 인터페이스를 목표로 한다.
   2. 동일한 호출 형태: Gemini 모델을 호출하든 Anti-gravity 에이전트를 호출하든 모델 또는 에이전트, 입력, 도구·환경이라는 같은 형태를 사용한다.

2. 입력·출력·도구의 추상화

   1. 입력: 입력은 단순한 문자열일 수도 있고 이미지·오디오 등 멀티모달 데이터일 수도 있다.
   2. 모달리티별 응답: Gemini TTS로 오디오를 생성할 때는 응답 모달리티를 audio로 지정하고 Generation Configuration을 설정한다. 이미지 생성도 같은 패턴으로 이미지 모델과 입력, 생성 설정을 전달한다.
   3. 도구와 환경: 모델 또는 에이전트에는 Google Search, URL Context, 사용자 정의 함수와 실행 환경을 연결할 수 있다.

2.3. 상태 관리와 장기 실행

1. 서버 측 상태(Server-side State)

   1. 클라이언트 부담의 제거: 상태를 클라이언트에서 직접 관리하고 싶지 않으면 서버에 넘길 수 있다.
   2. 후속 턴: 첫 요청의 상호작용 ID를 다음 입력과 함께 보내면 서버가 이전 입력과 새 입력을 이어 붙여 모델이 전체 맥락을 다시 볼 수 있게 한다.
   3. 모든 모달리티에 적용: 텍스트뿐 아니라 오디오·이미지 생성에도 같은 상태 관리 방식이 적용된다.

2. 비동기 장기 실행(Long-running Operations)

   1. HTTP 연결 유지의 문제: Omni 동영상 생성처럼 시간이 오래 걸리는 작업은 HTTP 연결을 계속 열어둘 필요가 없다.
   2. ID 기반 진행: 요청을 보내면 작업 ID를 받고, 스트리밍 또는 폴링으로 완료 시점을 기다린 뒤 결과를 받는다.
   3. 에이전트 작업과의 적합성: 수 초짜리 응답이 아니라 여러 단계의 조사·코드 실행·파일 생성이 이어지는 에이전트 작업에 맞는 모델이다.

2.4. 도구 선택과 CVE 에이전트 사례

1. 모델이 도구 순서를 결정

   1. 도구 선언: Google Search, URL Context, 사용자 정의 Function을 도구 목록에 선언하고 요청을 보낸다.
   2. 자율적 선택: 모델은 먼저 Google Search를 할지, 함수를 호출할지 스스로 판단한다.

2. React CVE 조사 에이전트

   1. 검색: 에이전트는 React에 알려진 CVE가 있는지 Google Search를 사용해 찾는다.
   2. 원문 확인: URL Context로 관련 웹사이트에 들어가 세부 정보를 읽는다.
   3. 구조화된 저장: Function Calling으로 결과를 정형화해 데이터베이스에 저장하거나 후속 조회에 쓸 수 있다.
   4. 구현의 간결성: 이 흐름을 만드는 데 필요한 코드는 매우 짧으며, 검색·웹 접근·저장 함수가 하나의 요청 흐름에 들어간다.

2.5. User-Model Turn에서 Step 기반 타임라인으로

1. 기존 턴 모델의 불편함

   1. 환경 입력의 왜곡: 이전 API에서는 함수 결과를 다시 user turn의 콘텐츠로 넣어야 했지만, 그 결과는 사용자가 보낸 것이 아니라 환경이 돌려준 값이다.
   2. 추론의 변화: 에이전트와 Reasoning 모델은 오래 생각하고, 생각의 일부나 서명(Signature)만 노출하며, 단순한 사용자 입력-모델 출력의 왕복을 벗어난다.

2. Step 기반 표현

   1. 동기식 타임라인: 사용자 턴과 모델 턴 대신 각 생성·행동을 하나의 타입을 가진 단계(step)로 표현한다.
   2. 명확한 함수 결과: 함수 호출 에이전트는 애매한 user role 콘텐츠가 아니라 명시적인 function result를 반환한다.
   3. 확장성: 미래의 새로운 기능·능력을 각기 다른 단계 타입으로 추가하기 쉽다.
   4. 단순성: 호출자는 실제로 무슨 일이 완료됐는지 정의할 수 있고, 환경의 결과를 사용자 메시지로 위장할 필요가 없다.

3. Anti-gravity와 독립 실행 환경

Anti-gravity는 Gemini API 안에서 호출할 수 있는 에이전트이며, 자체 Sandbox를 통해 코드·파일·도구를 실행한다.

3.1. Agent Harness의 재사용

1. Google I/O에서 공개된 Anti-gravity 에이전트

   1. 공통 실행 백엔드: Gemini API의 원격 Anti-gravity 에이전트는 Anti-gravity 제품에서 쓰는 동일한 Agent Harness로 작동한다.
   2. 제품 범위: Anti-gravity IDE, CLI 또는 Anti-gravity 2.0을 사용한 개발자는 이미 같은 Harness의 일부를 접했을 수 있다.

2. Harness와 Agent의 구분

   1. Harness: 에이전트의 백엔드 실행 기반이다.
   2. 제품별 차이: IDE는 코딩 에이전트이므로 Gemini API 에이전트와 도구나 System Instruction이 다를 수 있다.
   3. 공통 개선 효과: Harness와 Gemini의 실행 능력이 개선되면 IDE와 Gemini API 양쪽 제품이 함께 이득을 얻는다.

3.2. 원격 환경이 제공하는 Sandbox

1. API 호출로 생성되는 클라우드 환경

   1. 자동 프로비저닝: 원격 환경(Remote Environment)을 지정해 요청하면 Google 백엔드가 클라우드 Sandbox를 시작한다.
   2. 실행 범위: 에이전트는 Sandbox에서 코드를 실행하고 파일을 만들고 쓸 수 있으며, 의존성·사용자 도구를 설치하고 사용자 API를 호출할 수 있다.
   3. 인프라 비관리: 개발자는 실행 환경을 직접 프로비저닝하거나 유지할 필요가 없다.

2. 상태의 분리

   1. 관리형·무상태 API 호출: 요청 자체와 인프라 관리는 관리형으로 처리되며, 호출자는 서버를 직접 운영하지 않는다.
   2. 지속되는 환경 상태: 같은 환경 ID를 사용하는 다중 턴 대화에서는 앞선 턴에서 만든 파일과 설치한 도구를 다음 턴에서 계속 사용할 수 있다.
   3. 에이전트 간 공유: 세 에이전트가 하나의 환경에서 일하면 파일 시스템을 통해 맥락을 공유할 수 있고, Sub-agent가 앞선 에이전트의 작업을 이어받을 수 있다.

3.3. Sources, Skills, AGENTS.md

1. 환경에 주입하는 소스

   1. GCS Bucket: Google Cloud Storage의 버킷을 소스로 연결할 수 있다.
   2. GitHub Repository: 기존 코드와 문서를 GitHub 저장소에서 불러올 수 있다.
   3. Inline Files: 요청에 파일을 직접 넣어 환경을 구성할 수도 있다.

2. 파일 시스템 네이티브 에이전트

   1. Skills 디렉터리: Skills를 skills 디렉터리에 저장하면 환경 시작 시 자동으로 찾아 System Instruction에 포함한다.
   2. AGENTS.md: 코딩 에이전트가 사용하는 AGENTS.md 파일도 자동으로 System Instruction에 덧붙여진다.
   3. 실행 규칙의 코드화: 에이전트의 지식과 행동 규칙을 매번 프롬프트에 복사하지 않고 파일 구조로 배포할 수 있다.

4. Agents API와 에이전트가 만드는 환경

Agents API는 에이전트의 두뇌, 지시, 실행 환경을 이름 붙여 재사용하고 팀 간에 공유하는 방식이다.

4.1. 재사용 가능한 Base Agent

1. 정의 대상

   1. Base Agent: 어떤 모델이 underlying brain인지 정의한다.
   2. Instruction: 에이전트가 수행해야 할 규칙과 목표를 설정한다.
   3. Environment: 소스가 포함된 새 환경을 쓰거나 기존 환경을 재사용한다.

2. 팀 간 공유

   1. 팀 1의 제작, 팀 2의 사용: 한 팀이 만든 에이전트를 다른 팀이 고객·사용자에게 제공할 수 있다.
   2. 재구성 비용의 절감: 에이전트 정의와 환경 ID를 공유하므로 같은 설치·설정 과정을 반복하지 않는다.

4.2. 에이전트가 스스로 준비하는 환경

1. 부트스트래핑 에이전트

   1. 초기 설치: GitHub CLI를 설치하고 필요한 Skills를 추가하며 sanity check를 수행하는 작업을 에이전트에게 맡긴다.
   2. 환경 ID 반환: 준비가 끝나면 에이전트가 환경 ID를 돌려준다.

2. 준비된 환경의 재사용

   1. 새 에이전트 생성: 반환받은 환경 ID로 새 에이전트를 정의한다.
   2. 일관된 시작 상태: 새 에이전트를 호출할 때마다 미리 로드되고 사전 구성된 환경에서 시작한다.
   3. DevOps 부담 제거: 사용자는 Terraform, Kubernetes, 마이크로서비스, Firecracker 같은 인프라 구성 요소를 직접 설계할 필요가 없다.

4.3. Gemini API CLI와 Skills

1. Gemini API CLI의 정체

   1. 코딩 에이전트가 아님: Gemini CLI나 코딩 에이전트 자체가 아니라, 다른 에이전트가 Gemini API를 호출할 수 있게 하는 CLI다.
   2. 모델·에셋 호출: 에이전트는 CLI로 Nano Banana와 Omni를 호출해 이미지·동영상 같은 에셋을 생성할 수 있다.
   3. 에이전트 개선: CLI로 에이전트를 만들고, 반복적으로 실행하고, 결과를 보고 개선할 수 있다.

2. 배포 자료

   1. GitHub Repository: 발표 화면의 QR 코드는 해당 CLI 저장소로 연결된다.
   2. 전용 Skills: Interactions API와 Agents API를 다루는 전용 Skills가 제공되어 후속 실험을 돕는다.

5. AI Talk Radio: 여러 모델과 Sandbox의 결합

AI Talk Radio는 관리형 에이전트가 여러 Gemini 모델과 도구를 조합해 하나의 완성된 미디어 결과물을 만드는 사례다.

5.1. AI Studio의 Build Gallery

1. 앱렛의 구성

   1. 관리형 에이전트 위의 UI: AI Studio의 Build 영역과 Gallery에는 Gemini를 활용한 사전 제작 앱렛·사용 사례가 있다.
   2. 다중 모델 접근: Talk Show Radio 에이전트는 썸네일, 음성, 음악 생성과 조사에 여러 Gemini 모델을 사용할 수 있다.
   3. 원샷 라디오 생성: 조사부터 대본, 음성, 음악, 믹싱까지 이어지는 라디오를 한 번에 생성한다.

2. 사용 방식

   1. 무료 일일 사용량: 앱렛은 매일 일정량을 무료로 사용할 수 있다.
   2. 주제 입력: 파인애플을 피자에 올려도 되는지를 주제로 Talk Show Radio 생성을 요청했다.
   3. 실행 순서: 먼저 환경을 시작하고, 모델이 필요한 작업을 추론한 뒤 Python 의존성을 설치하고 Skills를 읽으며 작업을 이어간다.

5.2. 시리얼과 우유 논쟁 라디오

1. 다중 인물 토론 포맷

   1. 단순 Podcast가 아님: 한 사람이 읽는 오디오가 아니라 여러 인물이 각자 추론하고 의견을 나누는 토크쇼다.
   2. 질문: 시리얼을 먼저 붓는지 우유를 먼저 붓는지를 두고 객관적으로 장단점을 비교한다.

2. 실제 대화의 사례

   1. 진행자 Paul: 런던 스튜디오에서 아침 식사 논쟁을 소개하고 Boston의 David에게 전화를 연결한다.
   2. David의 시리얼 우선 주장: 시리얼은 독립 변수이므로 양을 눈으로 확인한 뒤 우유를 부어야 하며, 우유에 마른 시리얼을 부으면 튀어 엉망이 된다고 주장한다.
   3. 매시드 포테이토 비유: 그레이비를 그릇에 먼저 담고 그 위에 감자 덩어리를 올리지는 않을 것이라는 비유로 시리얼 우선의 질서와 청결을 강조한다.
   4. Sarah의 반론: Sydney의 Sarah는 David가 틀렸으며 우유를 먼저 부어야 식감이 달라진다고 반박한다. 재료가 부딪히는 질감의 문제를 우유 우선의 핵심 근거로 제시한다.
   5. 생성형 미디어의 의미: 사소한 아침 식사 논쟁도 조사·대본·다중 화자·음성·음악을 결합하는 에이전트의 작업 단위가 된다.

5.3. Remix 가능한 오픈 앱렛

1. Gallery에서의 재구성

   1. Build 섹션: Gallery에서 Talk Show Radio 앱렛을 선택하고 Remix할 수 있다.
   2. 용도 변경: Talk Show가 마음에 들지 않으면 같은 코드를 실제 Podcast 애플리케이션 등 다른 제품으로 바꿀 수 있다.
   3. 오픈 코드: 앱렛의 코드를 볼 수 있으므로 UI 뒤에서 에이전트가 어떤 파일과 도구를 사용하는지 확인할 수 있다.

2. 에이전트는 파일의 집합

   1. AGENTS.md의 역할: 환경 안의 AGENTS.md는 시작 시 로드되어 에이전트의 System Instruction에 들어간다.
   2. 작업 지시: 조사, 화자별 스크립트 작성, 음악 생성, 음성 생성, 전체 결과 믹싱이 지시 파일에 기록된다.
   3. TTS Generation Skill: TTS 생성 Skill에는 실행할 Python 파일이 있으며, Python 파일은 Interactions API로 다른 Gemini 모델을 호출해 음성을 만든다.
   4. 백엔드 전환: UI에서 쓰던 에이전트를 백엔드에서 쓰려면 해당 파일을 복사해 에이전트를 생성하고 호출하면 된다.

6. Playground에서 확인하는 실제 Sandbox

Playground의 Agent 모델 선택 영역은 환경을 탐색하고 에이전트가 실제 머신에서 명령을 실행하는 과정을 보여준다.

6.1. Agent Templates와 환경 탐색

1. 사용 가능한 템플릿

   1. Agent 영역: 모델 선택기에 Deep Research와 Anti-gravity 에이전트가 별도 항목으로 있다.
   2. 여섯 가지 Anti-gravity 템플릿: 여섯 종류의 템플릿 중 하나를 선택해 동작을 시험할 수 있다.
   3. Standard 템플릿: 시연에서는 Standard를 선택하고 에이전트가 자신이 실행되는 환경을 직접 탐색하도록 했다.

2. 첫 요청의 지연

   1. 7~10초의 시작 시간: 첫 요청에서는 환경이 만들어져야 하므로 약 7~10초가 걸린다.
   2. 실행 과정의 가시성: 에이전트의 추론과 Bash 명령 실행이 화면에 나타나며, 숨겨진 원격 머신이 실제로 일하고 있음을 확인할 수 있다.

6.2. Sandbox의 머신 사양과 후속 실행

1. 환경 점검 결과

   1. 운영체제: Ubuntu에서 실행된다.
   2. 컴퓨팅 자원: 8 vCPU와 16GB 메모리를 제공한다.
   3. 개발 도구: Python과 pip가 설치되어 있다.
   4. 자기 인식 명령: 에이전트는 자신의 버전과 CPU·메모리를 확인하는 Bash 명령을 실행했다.

2. 다중 턴 후속 작업

   1. 상태 유지: “Node가 설치되어 있는가?” 같은 후속 질문을 같은 환경에 보낼 수 있다.
   2. 이전 작업의 연속: 새 요청은 앞선 프롬프트와 이미 준비된 환경을 바탕으로 이어진다.
   3. 파일 추출: 에이전트가 만든 파일은 오른쪽의 Download 기능으로 내려받을 수 있고, 같은 작업을 위한 API도 제공된다.

6.3. 서버 측 전체 에이전트 루프

1. 단일 API 호출의 실행 흐름

   1. 환경 시작: 요청이 들어오면 Sandbox가 시작된다.
   2. 파일 로드: 연결된 소스와 환경 파일이 로드된다.
   3. 서버 측 루프: 에이전트의 추론·도구 호출·결과 확인 루프가 전부 Google 서버의 원격 환경에서 실행된다.

2. 클라이언트 오케스트레이션과의 차이

   1. 일반적인 방식: 클라이언트가 함수 호출을 받고, 어딘가에서 함수를 실행한 뒤, 함수 결과를 모델에 다시 보내는 중계 코드를 직접 관리해야 한다.
   2. 관리형 에이전트 방식: 단일 API 호출만으로 함수 실행과 반복 루프가 원격 Sandbox 안에서 완료된다.
   3. MCP 연결: 원격 MCP 서버를 연결하거나 Sandbox 내부에서 로컬 MCP 서버를 실행할 수 있다.
   4. 개발자의 역할 변화: 인프라·중계 루프보다 환경의 파일, Skills, 도구와 에이전트 목표를 설계하는 일이 핵심이 된다.

7. 실험을 시작하는 경로와 최종 결론

7.1. 문서와 코딩 Skills

1. Gemini API 문서

   1. Agents 빠른 시작: 첫 요청 보내기, 첫 에이전트 만들기, 실행 환경을 연결하는 단계별 문서가 제공된다.
   2. API 실험: AI Studio에서 API 키와 예산을 준비한 뒤 Interactions API를 사용해 모델·도구·환경을 한 요청에 연결할 수 있다.

2. 코딩 에이전트 활용

   1. Skills 설치: Claude, Codex 등 사용하는 코딩 모델이 Gemini API 에이전트 구성을 돕도록 코딩 Skills를 설치할 수 있다.
   2. 점진적 구축: 단순한 환경에서 시작해 AGENTS.md, Skills, GitHub 소스, MCP와 장기 실행 작업을 차례로 추가한다.

7.2. 핵심 결론

1. Sandbox는 선택 기능이 아니다

   1. 에이전트가 코드·파일·의존성·API를 다루는 순간 실행 환경은 프롬프트의 부속물이 아니라 에이전트의 일부가 된다.
   2. 환경을 독립시키면 보안 경계를 만들고, 재현 가능한 도구 상태를 확보하며, 여러 턴과 여러 에이전트 사이의 작업물을 보존할 수 있다.

2. 추상화의 방향

   1. Interactions API는 대화 턴을 실행 단계로 바꾸고, 서버 측 상태와 비동기 작업을 제공한다.
   2. Agents API는 두뇌·지시·환경을 재사용 가능한 단위로 묶는다.
   3. Anti-gravity Harness와 파일 기반 Skills는 동일한 실행 원리를 IDE, CLI, API로 확장한다.

3. 실무적 시사점

   1. 개발자는 매번 함수 호출 중계 서버를 만들기보다 에이전트가 사용할 환경과 도구를 선언할 수 있다.
   2. 환경을 먼저 부트스트랩하는 에이전트를 만들고, 반환된 환경 ID로 고객용 에이전트를 파생할 수 있다.
   3. 작은 데모인 AI Talk Radio부터 조사·코드·미디어 생성·MCP를 결합한 장기 실행 제품까지 같은 Sandbox 원리를 확장할 수 있다.

주요 발언 모음

“AI 에이전트는 각자 자신의 Sandbox를 가져야 한다.”

“우리는 더 이상 User-Model Turn 원칙만으로 작업하지 않고, 동기식 타임라인의 Step으로 이동했다.”

“에이전트는 코드를 실행하고 파일을 만들고 쓰며, 의존성과 자체 도구를 설치하고 사용자 API를 호출할 수 있다.”

“환경 ID를 사용하면 에이전트가 자기 환경을 만들고, 그 환경에서 새 에이전트를 만들 수 있다.”

“Terraform, Kubernetes, 마이크로서비스, Firecracker를 직접 고민하지 않아도 된다.”

“관리형 에이전트에서는 단일 API 호출만으로 모든 일이 원격 Sandbox 안에서 실행된다.”

핵심 데이터 & 수치

• 20분 42초: 전체 발표 길이.
• 약 4센트/이미지: 전날 출시된 Nano Banana Light의 이미지 생성 비용으로 제시된 수치.
• 약 7~10초: Anti-gravity Sandbox가 첫 요청을 위해 시작되는 데 걸리는 시간.
• 8 vCPU·16GB 메모리: Playground에서 확인한 Ubuntu 원격 환경의 기본 컴퓨팅 자원.
• Python·pip 설치 상태: 표준 Sandbox에 기본으로 준비된 개발 도구.
• 6개 Anti-gravity Agent Template: Playground에서 선택해 시험할 수 있는 템플릿 수.
• 1개 API 호출: 클라이언트가 함수 호출 루프를 직접 중계하지 않고 관리형 에이전트를 실행하는 표면적 인터페이스.

결론 및 시사점

1. AI 에이전트의 단위는 모델 호출이 아니라 목표·추론·도구·환경이 결합된 실행 루프다.
2. 서버 측 상태와 지속 환경을 분리하면 API 호출은 관리형으로 유지하면서 파일·의존성·작업 맥락은 다음 턴에 보존할 수 있다.
3. Interactions API의 Step 기반 모델은 환경이 반환한 함수 결과를 사용자 메시지로 위장하지 않고 새로운 기능을 확장하기 쉽게 만든다.
4. Agents API는 사전 구성 환경을 ID로 재사용하게 하므로 팀 내부 플랫폼과 고객용 에이전트를 같은 기반에서 만들 수 있다.
5. AGENTS.md와 Skills를 파일 시스템에 배치하면 에이전트의 행동 규칙·도구·지식을 코드와 함께 버전 관리할 수 있다.
6. AI Talk Radio 사례는 조사, 다중 인물 대본, TTS, 음악, 믹싱을 하나의 Sandbox 안에서 연쇄 실행할 수 있음을 보여준다.
7. 첫 실험은 AI Studio의 Playground에서 환경 사양과 Bash 실행을 확인하고, 이후 GitHub·MCP·장기 작업으로 확장하는 방식이 적절하다.

독립적으로 읽는 핵심 요약 20줄

• LLM은 문장 이어 쓰기에서 지시 이행, 대화, 함수 호출을 거쳐 목표를 장시간 수행하는 에이전트로 발전했다.
• 에이전트는 목표를 받고 추론하며 도구를 실행하고 결과를 검증하는 실행 루프를 구성한다.
• 단순 User-Model Turn은 추론 토큰과 환경이 반환한 함수 결과를 표현하기에 부족하다.
• Interactions API는 사용자·모델 턴 대신 각 행동과 생성을 명시적인 Step으로 표현한다.
• Interactions API는 모델과 에이전트를 같은 개발자 친화적 호출 인터페이스로 다룬다.
• 문자열과 멀티모달 입력, Google Search, URL Context, 사용자 함수, 실행 환경을 한 흐름에 연결한다.
• 서버 측 상태는 클라이언트가 대화 이력을 직접 조립하지 않아도 후속 상호작용을 이어가게 한다.
• 장기 생성 작업은 ID를 반환하고 스트리밍이나 폴링으로 완료를 기다리는 비동기 방식으로 처리한다.
• React CVE 에이전트는 검색, 웹 원문 확인, 구조화된 데이터베이스 저장을 자동으로 연결한다.
• Anti-gravity는 Gemini API와 제품군에서 공통 Agent Harness를 활용하는 에이전트다.
• 제품별 도구와 System Instruction은 달라도 공통 Harness 개선은 IDE와 API에 함께 반영된다.
• 원격 Sandbox는 코드·파일·의존성·사용자 도구·사용자 API를 격리된 클라우드 환경에서 실행한다.
• 동일 환경 ID를 사용하면 다중 턴 대화가 앞선 파일과 설치 상태를 계속 활용한다.
• 여러 에이전트와 Sub-agent는 파일 시스템을 통해 같은 환경의 맥락과 산출물을 공유한다.
• GCS Bucket, GitHub Repository, Inline Files를 환경의 소스로 연결할 수 있다.
• Skills 디렉터리와 AGENTS.md는 시작 시 System Instruction에 자동으로 포함된다.
• Agents API는 Base Agent의 두뇌, 지시, 환경을 정의해 팀과 고객에게 재사용하게 한다.
• 부트스트래핑 에이전트는 GitHub CLI와 Skills를 설치한 뒤 환경 ID를 반환해 후속 에이전트를 만든다.
• AI Talk Radio는 조사·대본·음성·음악·믹싱을 여러 Gemini 모델로 묶은 관리형 에이전트 사례다.
• Sandbox와 단일 API 호출은 개발자가 Terraform·Kubernetes·함수 중계 루프 없이 장기 실행 에이전트를 운영하게 한다.