Google I/O 2026에서 가장 과소평가된 발표: 90초짜리 데모 속에 숨겨져 있었다

이 글은 Google I/O Writing Challenge를 위한 제출물입니다. 저는 Google I/O 2026 기조연설을 두 번 시청했습니다. 처음에는 화려한 것들에 마음을 빼앗겼습니다. Gemini 3.5 Flash의 벤치마크(benchmarks). 소름 끼칠 정도로 실감 나는 영상을 생성하는 Veo 3. 멀티모달(multimodal) 물리 연산을 수행하는 Gemini Omni. 멋졌습니다. 예상했던 대로였습니다. 5만 건의 리트윗을 기록하고 목요일이면 사라질 평범한 I/O의 일시적인 흥분(sugar rush)이었죠. 두 번째 시청 때는 다른 것을 포착했습니다. 개발자 기조연설이 시작되고 약 40분쯤 지났을 때, Jules GA 발표와 Stitch 데모 사이에 'Managed Agents API'라고 불리는 무언가에 대해 약 90초 정도의 시간이 할애되었습니다. 발표자가 던진 단 한 마디가 저를 일시 정지하고 되감게 만들었습니다. "추론하고, 코드를 작성하며, 웹을 탐색하고, 보안 샌드박스(sandbox) 내에서 실행되는 자율 에이전트(autonomous agent)를 배포하세요. 단 한 번의 API 호출로 가능합니다." 저는 다른 모든 탭을 닫았습니다. 문서를 불러왔습니다. 코드를 작성하기 시작했습니다.

19일간의 문제
여기 배경 설명이 있습니다. 지난 1년 동안 AI 에이전트(AI agents)로 무언가를 구축해 보려 했다면, 여러분은 그 과정을 잘 알 것입니다. 제가 말하는 '과정'이란 '몇 주간의 고통'을 의미합니다. 예를 들어, GitHub 이슈를 가져와서 코드베이스(codebase)를 읽고, 수정 사항을 작성하고, 테스트를 실행한 뒤 PR(Pull Request)을 여는 에이전트를 원한다고 가정해 봅시다. 간단해 보이죠? 하지만 현실에서는 5개의 서비스를 연결하고, 샌드박스 컨테이너(sandboxed containers)를 구동하며, 인증(auth)을 관리하고, 도구 호출 라우팅(tool-call routing)을 구축하고, 상태 확인(health checks)을 작성하며, 에이전트가 토요일 새벽 3시에 실수로 운영 환경(production)을 날려버리지 않도록 네트워크 정책(network policies)을 설정해야 합니다. 지난달 저는 지원 티켓을 분류하는 내부 봇을 만들었습니다. 3주가 걸렸습니다. 실제 AI 로직(logic)은요? 하루였습니다. 나머지 19일은 순수하게 인프라(infrastructure) 작업이었습니다. Docker 설정, gVisor를 이용한 샌드박스 격리(Sandbox isolation), 네트워크 정책, 타임아웃 처리(Timeout handling), 상태 확인, 재시도 로직(Retry logic). 19일 동안 배관(plumbing) 작업을 하고, 단 하루 동안 생각했습니다. 이 비율은 잘못되었습니다. 그리고 이 API가 방금 그것을 해결했습니다.

3주에서 11줄로
저는 동일한 지원 티켓 봇을 Managed Agents API로 다시 구성했습니다. 데모 버전이 아닙니다. 똑같은 봇입니다. 똑같은 기능입니다.

from google import genai
client = genai .

Client () interaction = client . interactions . create ( agent = " antigravity-preview-05-2026 " , environment = " remote " , input = ( " 당신은 지원 티켓 분류 (triage) 에이전트입니다. " " 다음 티켓을 읽고, 심각도를 분류하며, " " 코드베이스에서 영향을 받는 컴포넌트를 식별하고, " " 제안된 수정 사항이 포함된 답변 초안을 작성하세요. \n\n " f " 티켓: { ticket_text } " ) ) print ( interaction . output_text ) 단 11줄입니다. Docker도, Kubernetes도, 샌드박스 설정 (sandbox config) 도 필요 없습니다. API가 신선하고 격리된 Linux 환경을 실행하고, 에이전트 런타임 (agent runtime) 을 로드하며, 작업을 수행한 뒤, 결과를 반환하고, 샌드박스를 파괴합니다. 끝입니다. 실제 사례는 다음과 같았습니다:

구분	기존 설정 (Old Setup)	Managed Agents API
구축 시간	3주	오후 한나절
인프라 코드 라인 수	~2,400줄	0줄
에이전트 로직 라인 수	~180줄	11줄
종속성 (Dependencies)	Docker, gVisor, Redis, nginx	google-genai pip 패키지
유지보수 부담	컨테이너 업데이트, 상태 확인 (health checks), 스케일링 (scaling)	없음 (Google의 문제)

이것이 작동했을 때 저는 꼬박 1분 동안 화면을 응시했습니다. 결과물이 완벽해서가 아닙니다 (완벽하지 않았습니다). 방금 3주 분량의 인프라 코드를 쓰레기통에 던져버렸기 때문입니다.

Google이 실제로 내부에서 구축한 것

interactions.create를 호출하면 네 가지 일이 일어납니다:

1. 샌드박스 프로비저닝 (Sandbox provisioning). Google은 격리된 Linux VM을 실행합니다. 매번 새로운 파일 시스템이 생성됩니다. 이전 실행의 잔여 상태가 남지 않습니다. 네트워크 액세스는 기본적으로 꺼져 있으며, 선택 시에만 활성화됩니다. 이것만으로도 예전에는 Docker와 gVisor를 붙잡고 씨름하며 일주일은 허비해야 했습니다.
2. 에이전트 하네스 (Agent harness) 부팅. 이것은 Jules와 Antigravity 데스크톱 앱을 구동하는 것과 정확히 동일한 런타임입니다. 축소된 버전이 아닙니다. 똑같은 것입니다. Google이 Jules에 적용하는 모든 개선 사항은 여러분의 Managed Agents에도 그대로 적용됩니다.
3. 추론 루프 (Reasoning loop). 에이전트가 입력을 읽고, 계획을 세우고, 실행을 시작합니다. 파일을 작성하고, 코드를 실행하며, 설정을 켰다면 웹에 접속합니다. 출력을 반환하기 전에 논리적 오류를 잡아내는 "비평가 (critic)" 레이어가 내장되어 있습니다. 모든 응답 전에 실행되는 내장 코드 리뷰어라고 생각하면 됩니다.
4. 정리 (Cleanup).

상호작용이 종료되면 샌드박스 (Sandbox)가 파괴되며, 결과물과 에이전트가 생성한 모든 파일이 사용자에게 전달됩니다. 총 소요 시간은 30초에서 몇 분 정도입니다.

샌드박스의 한계: 프리뷰 (Preview)의 제약 사항
이것이 프로덕션 (Production) 환경에 바로 투입될 준비가 되었다고 거짓말하지는 않겠습니다. 이틀간의 테스트를 통해 실제 문제점들이 드러났습니다.

타임아웃 (Timeout) 장벽: 15,000줄 규모의 코드베이스를 대상으로 특정 모듈의 리팩토링 (Refactoring)을 요청해 보았습니다. 5분 제한에 걸려 중단되었습니다. 크고 복잡한 작업은 과부하가 걸립니다.

호출 간 메모리 부재: 각 상호작용은 깨끗한 샌드박스에서 시작됩니다. 보안 측면에서는 훌륭하지만, 에이전트가 문맥 (Context)을 기억해야 하는 경우에는 최악입니다. 사용자가 직접 상태 (State)를 관리해야 하며, 매번 이후의 호출 시 previous_interaction_id와 관련 문맥을 다시 전달해야 합니다. 어렵지는 않지만, 공짜도 아닙니다. 이것이 바로 "프리뷰" 비용입니다.

정식 출시 (GA) 전 단계: Google은 민감한 데이터를 입력하지 말라고 경고합니다. 사이드 프로젝트나 내부 도구용인가요? 그렇다면 진행하십시오. 프로덕션 환경의 고객 데이터인가요? 기다리십시오.

가격 정책은 블랙박스입니다. 프리뷰 기간 동안은 무료입니다. 대규모 운영 시 비용이 얼마나 들지는 아무도 모릅니다. 이는 프로덕션 워크로드 (Workload)를 계획하는 누구에게나 실제적인 문제입니다.

네트워크 액세스 (Network access)는 미완성 상태입니다. 에이전트가 공개 웹을 탐색할 수는 있습니다. 하지만 내부 API에 접근하려면 브릿지 역할을 하는 MCP 서버가 필요하며, 이는 다시 인프라 오버헤드 (Infrastructure overhead) 문제를 야기합니다. 다소 아이러니한 부분입니다.

경쟁사와의 비교
제가 주목하게 된 이유는 다음과 같습니다. 현재 샌드박스에서 실행되는 자율 에이전트 (Autonomous agent)를 원한다면 선택지는 다음과 같습니다.

OpenAI Assistants API는 샌드박스 내 코드 실행 기능을 제공하지만, OpenAI 모델에 종속되어 있으며 샌드박스가 제한적입니다 (임의의 바이너리 실행 불가, 웹 브라우징 불가). 또한 토큰당 비용과 도구 호출 (Tool-call) 수수료를 지불해야 합니다. 이는 진정한 의미의 "에이전트 배포"라기보다는 "도구를 사용한 대화 실행"에 가깝습니다.

Anthropic의 도구 사용 (Tool-use) 기능은 단일 턴 도구 호출 (Single-turn tool calling)에는 강력하지만, 관리형 샌드박스는 제공하지 않습니다. 사용자가 직접 실행 환경을 가져와야 합니다. 결국 다시 Docker와 gVisor를 다루는 번거로운 작업으로 돌아가게 됩니다.

LangGraph Cloud는 에이전트 오케스트레이션 (Orchestration)을 제공하지만, 이 역시 인프라를 직접 관리해야 합니다.

실행 환경(Execution environment)은 여러분의 문제입니다. Google의 접근 방식은 다릅니다. 그들은 이렇게 말하고 있습니다. 지침(Instructions)만 주면, 샌드박스(Sandbox), 실행, 보안, 그리고 정리(Cleanup)는 우리가 처리하겠다고 말이죠. 여러분은 인프라에 대해 전혀 고민할 필요가 없습니다. 이는 이 분야에서 진정으로 새로운 포지션입니다. 주요 클라우드 제공업체가 자율 에이전트(Autonomous agents)를 단순한 '도구 사용 채팅(Chat-with-tools)'이 아닌, 서버리스 컴퓨팅(Serverless compute)으로 취급하는 것은 이번이 처음입니다. 트레이드오프(Tradeoff)는 무엇일까요? Google의 생태계에 종속(Lock-in)된다는 점입니다. 에이전트는 Gemini 모델에서 실행됩니다. 특정 작업을 위해 Claude나 GPT-4가 필요하다면, 이것은 여러분을 위한 도구가 아닙니다. 하지만 이미 Google 스택을 사용 중인 팀에게는 마찰(Friction) 감소 효과가 실질적입니다.

나를 정말 사로잡은 기능: 저장된 에이전트 (Saved Agents)
단발성 상호작용(One-shot interactions)도 멋지지만, agents.create에서 상황이 흥미로워집니다. 커스텀 지침(Custom instructions), 특정 도구(Tools), MCP 연결, 그리고 환경 설정(Environment settings)을 사용하여 에이전트를 정의합니다. 그 전체 구성을 저장하세요. 그런 다음 어디에서든 ID를 통해 이를 트리거할 수 있습니다. 크론 잡(Cron job), 웹훅(Webhook), GitHub Action, 혹은 다른 에이전트 등 말이죠.

agent = client.agents.create(
    display_name = "ticket-triage-v1",
    system_instruction = (
        "You are a senior support engineer."
        "Classify tickets by severity."
        "Always check error logs before suggesting a fix."
        "Never suggest restarting the service as a first option."
    ),
    tools = ["code_execution", "web_browse"],
    environment_config = {
        "sandbox": "remote",
        "timeout_seconds": 300
    }
)

# 어디에서든 트리거
result = client.interactions.create(
    agent = agent.id,
    input = f"New ticket: {ticket_text}"
)

저는 이것을 저희 Slack에 연결했습니다. 누군가 버그를 보고하면, 에이전트가 자동으로 분류(Triage)하고, 관련 로그를 가져와서, 스레드에 분석 내용을 게시합니다. 단 40줄의 Python 코드와 웹훅 하나로 말이죠.

Lambda의 순간 (The Lambda Moment)
2014년이 기억나시나요? Lambda가 나오기 전, 클라우드에서 코드를 실행한다는 것은 EC2 인스턴스, 로드 밸런서(Load balancers), 오토 스케일링 그룹(Auto-scaling groups) 등을 의미했습니다. 온갖 작업이 필요했죠. Lambda는 말했습니다. 함수(Function)만 주면 나머지는 우리가 처리하겠다고요. 사람들은 그것을 장난감이라고 불렀습니다. 그러다 Lambda는 백엔드 세상을 집어삼켰습니다. 저는 계속해서 똑같은 패턴을 보고 있습니다.

이 API가 나오기 전에는 에이전트 (Agent)를 구축한다는 것이 인프라 (Infrastructure)를 관리해야 함을 의미했습니다. 이제는 지침을 전달하기만 하면 Google이 샌드박스 환경 (Sandboxed environment)에서 이를 실행합니다. 제가 틀렸을 수도 있습니다. 어쩌면 이것은 니치 (Niche)한 영역으로 남을지도 모릅니다. 하지만 이 평행 이론이 계속 저를 괴롭히고 있으며, 저는 스스로를 설득하지 못하고 있습니다.

다음에 제가 만들고 싶은 것들

문서 드리프트 탐지기 (Docs drift detector): 리포지토리 (Repo)를 가리키면 README를 읽고, 코드를 실행하여 문서와 동작이 서로 달라진 부분을 찾아냅니다. 모든 프로젝트에는 이 문제가 있습니다. 아무도 이를 수동으로 고치지 않습니다.

의존성 변경 로그 판독기 (Dependency changelog reader): 의존성 (Deps)의 변경 로그를 실제로 읽고, 파괴적 변경 사항 (Breaking changes)을 이해하며, 어떤 업데이트가 자동 병합 (Auto-merge)하기에 안전한지, 어떤 것이 인간의 검토가 필요한지 알려줍니다.

사전 검토 PR 에이전트 (Pre-review PR agent): 인간 검토자가 PR을 열기 전에 변경 사항을 읽고, 수정된 파일의 테스트 커버리지 (Test coverage)를 확인하며, 위험한 차이점 (Diffs)을 식별하고, 검토 노트 (Review notes)를 작성합니다. 마치 잠들지 않는 철저한 주니어 개발자처럼 말이죠.

이전에는 이 모든 것들이 몇 주가 걸리는 프로젝트였을 것입니다. 이제는 오후 한때면 구축할 수 있는 수준입니다. 그것이 바로 변화입니다. 에이전트가 무엇을 할 수 있느냐가 아니라, 얼마나 빨리 출시할 수 있느냐의 변화 말입니다.

그래서 이제 어떻게 해야 할까요?

Google I/O 2026에는 헤드라인을 장식할 뉴스들이 넘쳐났습니다. Gemini 3.5 Flash는 빠릅니다. Veo 3는 놀랍습니다. 물리 법칙을 이해하는 Gemini Omni를 보면 2027년이 어떤 모습일지 궁금해집니다. 하지만 저의 화요일을 실제로 바꿔놓은 것은 바로 이 조용하고 작은 API였습니다. 이것은 저를 "와우"하게 만들지 않았습니다. 대신 코드를 삭제하게 만들었습니다. 그리고 보통 중요한 일은 그런 방식으로 시작됩니다.

문서를 열어보세요. 파이썬 (Python) 코드 11줄을 작성해 보세요. 어떤 일이 일어나는지 확인해 보세요.

이 내용이 유용했나요? 반응을 남겨주시면 다른 사람들도 찾을 수 있습니다. API나 이를 활용한 구축에 대한 질문이 있으신가요? 댓글에서 기다리겠습니다.