프롬프트를 더 잘 쓰는 대신, 에이전트에게 ‘일할 자리’를 줘야 한다

AI에게 코드를 써달라고 시키는 일은 이제 어렵지 않다. 진짜 막히는 지점은 그다음이다. 에이전트가 만든 파일은 어디에 남는가? 여러 단계의 작업은 어떻게 이어지는가? 오래 걸리는 분석이 끝날 때까지 연결을 붙잡고 있어야 하는가? 프롬프트의 품질보다 에이전트가 일할 환경과 상태를 설계하는 일이 더 큰 병목이 되고 있다.

Google I/O 2026의 개발자 발표를 이 관점에서 읽으면 핵심이 선명해진다. Google은 새 모델 하나를 소개한 것이 아니라, 프롬프트에서 결과물까지 이어지는 개발 표면을 묶어 내놓았다. 결론부터 말하면 이제 에이전트 도입의 질문은 “어떤 모델이 더 똑똑한가?”가 아니라 “반복 업무를 어느 표면에서, 어떤 상태와 권한으로 맡길 것인가?”여야 한다.

지금까지의 AI 도입은 ‘대화창’에서 멈췄다

많은 팀이 AI를 도입할 때 첫 장면은 비슷하다. 개발자가 채팅창에 요구사항을 넣고, 코드를 복사해 로컬 프로젝트에 붙인다. 다음 질문을 던지면 앞선 파일과 실행 결과를 다시 설명한다. 테스트를 돌리고, 오류 로그를 붙이고, 새 결과를 다시 복사한다. 모델은 빨라졌지만 사람은 여전히 컨텍스트를 운반하는 운영자로 남는다.

에이전트가 실제 업무를 맡으려면 대화 이상의 것이 필요하다. 코드를 실행할 장소, 파일을 보존할 저장소, 도구를 호출할 권한, 실패한 작업을 이어갈 세션, 사람이 멈춰 세울 승인 지점이 필요하다. 이 다섯 가지를 직접 붙이는 순간 “간단한 AI 기능”은 샌드박스·큐·권한·상태 복구를 포함한 작은 시스템이 된다.

Google Antigravity가 개발자를 위한 에이전트 생태계로 확장되는 모습을 보여주는 공식 이미지 — Google Antigravity 공식 이미지. 출처: Google Antigravity @ I/O 2026

외부 정보 — I/O 2026이 바꾼 것은 모델이 아니라 개발 표면이다

Google 공식 발표에 따르면 Gemini 3.5 Flash는 에이전트 작업을 겨냥한 고속 모델이다. Google은 이 모델이 Gemini 3.1 Pro보다 거의 모든 벤치마크에서 앞서고, 다른 프런티어 모델보다 네 배 빠르게 실행된다고 설명한다. 이 수치는 Google의 발표상 비교 결과이므로 독립적인 성능 보증으로 읽기보다, 긴 작업을 빠르게 반복하려는 제품 방향을 보여주는 신호로 보는 편이 정확하다.

더 중요한 발표는 모델 주변에 놓였다. Google은 같은 에이전트 하네스를 여러 방식으로 쓸 수 있도록 Antigravity 생태계를 확장했다.

Antigravity 2.0: IDE에 종속되지 않는 데스크톱 앱이다. 여러 에이전트를 병렬로 조율하고, 동적 서브에이전트와 예약 작업을 사용한다.
Antigravity CLI: 터미널을 떠나지 않고 에이전트를 만들고 관찰하는 표면이다. GUI보다 빠른 반복이 중요한 개발 흐름에 맞는다.
Antigravity SDK: 같은 에이전트 하네스에 프로그래밍 방식으로 접근해 커스텀 동작을 정의하고 원하는 인프라에 배포하는 표면이다.
Gemini API Managed Agents: 한 번의 API 호출로 추론·도구 사용·코드 실행이 가능한 에이전트를 격리된 Linux 환경에서 시작한다.
Google AI Studio: 프롬프트로 앱을 만들고, Workspace 데이터와 연결하고, 로컬 개발을 위해 Antigravity로 프로젝트와 대화 맥락을 내보내는 빌드 표면이다.

이 목록을 제품 카탈로그처럼 읽으면 기능이 많아 보일 뿐이다. 하지만 워크플로로 번역하면 선택 기준은 단순해진다. 아이디어를 빠르게 검증하면 AI Studio, 터미널 중심으로 반복하면 CLI, 여러 에이전트를 감독하면 데스크톱 앱, 제품 안에 에이전트를 넣으면 Managed Agents와 SDK다.

가장 실용적인 변화는 ‘두 종류의 상태’를 맡기는 일이다

Managed Agents 문서에서 특히 중요한 개념은 대화 상태와 실행 환경 상태가 분리된다는 점이다. previous_interaction_id는 앞선 상호작용의 맥락을 이어가고, environment_id는 샌드박스의 파일과 실행 환경을 이어간다. 이 둘을 구분하면 에이전트를 단순한 채팅 세션이 아니라 작업 공간으로 설계할 수 있다.

상태	보존하는 것	워크플로에서의 의미
대화 상태	요청, 이전 답변, 도구 호출 맥락	“아까 만든 분석을 이어서 수정해줘”
환경 상태	파일, 설치 패키지, 샌드박스 작업 공간	“지난번에 저장한 CSV로 새 차트를 만들어줘”

이 분리는 실무에서 꽤 큰 차이를 만든다. 대화 맥락은 버리고 파일만 재사용할 수 있고, 반대로 대화는 이어가되 새 작업 공간에서 다시 검증할 수도 있다. 사람이 매번 “어디까지 했는지”를 설명하는 비용이 줄어드는 것이다.

Google AI Studio에서 아이디어를 앱으로 만드는 흐름을 상징하는 공식 이미지 — Google AI Studio의 빌드 경험을 소개하는 공식 이미지. 출처: Google AI Studio at I/O 2026

도입은 ‘만능 에이전트’가 아니라 한 가지 반복 업무로 시작해야 한다

에이전트 플랫폼이 커질수록 처음부터 모든 일을 맡기고 싶은 유혹도 커진다. 하지만 범위가 넓으면 성과를 측정할 수 없다. 첫 실험은 결과물이 분명하고, 실패해도 원상 복구가 쉬우며, 사람이 마지막에 검토할 수 있는 업무여야 한다.

반복 업무 하나를 고른다. 주간 경쟁사 리포트, 저장소의 테스트 실패 분류, 고객 피드백 요약처럼 입력과 출력이 분명한 작업이 좋다.
완료 조건을 문장으로 쓴다. “그럴듯한 보고서”가 아니라 출처 URL 포함, 표의 필수 열 유지, 미확인 값 표시처럼 검사 가능한 조건이어야 한다.
읽기 작업부터 맡긴다. 웹 검색·파일 분석·코드 실행처럼 원본을 바꾸지 않는 단계로 시작한다. 외부 시스템을 수정하거나 메시지를 발송하는 단계는 사람 승인 뒤로 둔다.
상태를 의도적으로 저장한다. 다음 실행에 필요한 파일과 대화 맥락을 구분하고, 어떤 ID를 보존할지 정한다. 상태가 필요 없는 작업이라면 매번 새 환경을 만들어 재현성을 우선한다.
사람의 수정 횟수를 잰다. 모델의 말투보다 결과를 완성하는 데 사람이 고친 문장 수, 다시 실행한 횟수, 소요 시간을 비교해야 한다.

Managed Agents의 가장 단순한 시작점은 아래와 같은 형태다. 핵심은 코드가 짧다는 데 있지 않다. 에이전트에게 질문만 주는 것이 아니라, 작업을 수행하고 파일을 남길 environment까지 함께 준다는 데 있다.

from google import genai

client = genai.Client()
interaction = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="지난달 판매 데이터를 분석하고 chart.png와 요약 보고서를 만들어줘.",
    environment="remote",
)

print(interaction.id)
print(interaction.environment_id)
print(interaction.output_text)

첫 실행 뒤에는 두 ID를 보존하고, 다음 작업에서 대화와 환경을 각각 이어갈지 결정한다. 예를 들어 보고서 초안을 다시 쓰는 일은 대화 맥락을 이어가고, 새로운 데이터셋으로 같은 분석을 재현하는 일은 새 대화와 별도 환경에서 시작하는 식이다. 이 구분만 해도 “에이전트가 왜 지난번 파일을 기억하지 못하지?” 같은 혼란이 크게 줄어든다.

속도가 빨라질수록 승인 지점은 더 선명해야 한다

격리된 Linux 환경은 좋은 출발점이지만 안전의 종착점은 아니다. Google 문서는 Managed Agents를 공개 프리뷰로 안내한다. 문서상 샌드박스는 코드 실행·파일 관리·웹 탐색을 지원하고 네트워크 접근을 제어할 수 있지만, 개발팀이 어떤 데이터와 도구를 연결하는지까지 대신 결정해주지는 않는다.

따라서 도입 체크리스트에는 다음 세 가지를 넣어야 한다.

데이터 경계: 테스트 데이터로 시작하고, 비밀값은 프롬프트나 파일에 직접 넣지 않는다.
도구 경계: MCP나 외부 API는 읽기 전용 권한으로 시작하고, 쓰기 권한은 별도 승인 함수로 분리한다.
결과 경계: 고객 발송·배포·결제·운영 데이터 변경은 에이전트의 자동 완료가 아니라 사람의 확인을 거친다.

에이전트 도입의 목적은 사람을 승인 절차에서 제거하는 것이 아니다. 사람이 반복적인 조사와 파일 운반에서 빠져나와, 어떤 결과를 승인할지 판단하는 일에 집중하게 만드는 것이다. 속도와 통제는 반대말이 아니다. 경계를 먼저 정하면 둘을 함께 얻을 수 있다.

이번 발표에서 가져갈 한 문장: 모델이 아니라 작업 단위를 고르자

I/O 2026의 개발자 발표는 “이제 누구나 앱을 만들 수 있다”는 낙관적인 메시지를 내놓았다. 그러나 실무자가 가져가야 할 더 냉정한 메시지는 따로 있다. 앱과 에이전트의 차이는 프롬프트 한 줄이 아니라 작업을 지속할 상태, 호출할 도구, 실행할 환경, 멈출 승인 지점을 제품의 기본 단위로 삼는 데서 생긴다.

그러니 오늘 새 모델을 비교하는 대신 지난 일주일 동안 두 번 이상 반복한 업무 하나를 적어보자. 그 업무의 입력·출력·금지사항·완료 조건을 한 페이지로 만들고, AI Studio에서 프로토타입을 만든 뒤 필요할 때 Antigravity나 Managed Agents로 옮기는 흐름을 실험하면 된다. 에이전트를 도입할지 고민하는 가장 빠른 방법은 거대한 계획이 아니라, 측정 가능한 지루한 업무 하나를 맡겨보는 것이다.

첫 실험에서 줄어든 것이 토큰 비용이든, 파일을 옮기는 시간이든, 사람이 고치는 횟수든 하나의 숫자로 남겨라. 그 숫자가 다음 에이전트를 도입할 이유가 된다.

근거 출처

외부 정보(하베스터 수집) — Google 공식 블로그의 I/O 2026 developer highlights(2026-05-19)를 바탕으로 Gemini 3.5 Flash, Antigravity 2.0·CLI·SDK, Managed Agents, AI Studio 통합 내용을 확인했다. AI Studio의 Workspace 연동, Antigravity 내보내기, 네이티브 Android 빌드 관련 내용은 Google AI Studio at I/O 2026를 참조했다. 대화 상태와 실행 환경 상태, 원격 Linux 샌드박스의 구분 및 사용 예시는 Gemini API 에이전트 개요, Managed Agent 환경 문서, Managed Agents Quickstart를 바탕으로 정리했다. Antigravity 생태계의 제품 표면은 Google Antigravity @ I/O 2026에서 교차 확인했다.

상호작용(에이전트-드루 대화·작업) — 이 글에는 별도의 에이전트-드루 대화나 내부 작업 경험을 외부 통계·제품 성능의 근거로 사용하지 않았다. 도입 순서, 승인 지점, 측정 항목은 위 외부 자료를 실제 워크플로 관점에서 해석한 편집자 분석이다.