Interactions API Gemini 모델 에이전트: 미들웨어를 무력화하는 GA 출시

원문은 twarx.com에서 처음 게시되었습니다 - 전체 인터랙티브 버전은 그곳에서 읽어보세요.

최종 업데이트: 2026년 6월 27일

Google이 방금 여러분의 에이전트 오케스트레이션 레이어(orchestration layer)를 선택 사항으로 만들었습니다 — 그리고 대부분의 팀은 아직 이를 알아차리지 못했습니다. Interactions API Gemini 모델 에이전트 출시는 프로덕션 AI 아키텍처의 규칙을 즉각적으로 바꾸어 놓았으며, 서드파티 프레임워크를 하룻밤 사이에 선택적인 애드온(add-ons)으로 전락시켰습니다.

2026년 6월 27일, Google은 자사의 Interactions API가 일반 가용성(General Availability, GA) 단계에 도달했으며, 이제 모든 Gemini 모델과 에이전트를 위한 주요(primary) 인터페이스가 되었다고 발표했습니다. 이제 단일 엔드포인트(endpoint)가 서버 측 상태(server-side state), 백그라운드 실행(background execution), 도구 조합(tool combination), 그리고 Google이 제공하는 Linux 샌드박스에서 실행되는 관리형 에이전트(Managed Agents)를 처리합니다. 파편화된 모델별 엔드포인트의 시대는 끝났습니다.

이 글을 마칠 때쯤 여러분은 무엇이 출시되었는지, OpenAI 또는 LangGraph 워크플로우를 어떻게 마이그레이션해야 하는지, 비용은 얼마인지, 그리고 실제로 이동해야 하는지 여부를 정확히 알게 될 것입니다. 이것이 어디에 위치하는지에 대한 더 넓은 관점은 프로덕션 환경의 AI 에이전트 가이드를 참조하세요.

Coined Framework

미들웨어 붕괴 이벤트(The Middleware Collapse Event) — 파운데이션 모델 제공업체가 오케스트레이션(orchestration), 상태 관리(state management), 도구 라우팅(tool-routing)을 API 레이어로 직접 흡수하여, 대부분의 프로덕션 사용 사례에서 서드파티 에이전트 프레임워크를 불필요하게 만드는 아키텍처적 순간

이것이 Interactions API가 촉발하는 구조적 변화입니다. 대화 상태 유지, 도구 라우팅, 장기 작업 실행 등 여러분이 LangGraph, AutoGen, CrewAI에 비용을 지불하며 수행하게 했던 작업들이 제공업체의 API 내부로 이동합니다. 미들웨어가 사라지는 것은 아니지만, 더 이상 필수 사항은 아니게 됩니다.

Google의 Interactions API는 단순한 개발자 경험(Developer Experience) 업데이트가 아닙니다. 이는 LangGraph, AutoGen, 그리고 CrewAI를 하룻밤 사이에 선택적인 애드온(Add-on)으로 만들어버리는 계산된 인프라 장악입니다. 만약 당신이 여전히 자신의 서버를 통해 에이전트 상태(Agent State)를 라우팅하고 있다면, 당신은 이미 레거시 아키텍처(Legacy Architecture)를 운영하고 있는 것입니다.

Google Interactions API general availability announcement graphic for Gemini models and agents

Gemini 모델과 에이전트를 위한 새로운 단일 통합 엔드포인트인 Interactions API의 일반 가용성(General Availability)에 대한 Google의 공식 출시 그래픽. 출처

Google의 발표 내용: Interactions API 공식 출시

발표 날짜, 출처 및 GA 상태

Google은 공식 블로그를 통해 Interactions API가 일반 가용성(General Availability, GA) 단계에 도달했다고 게시했습니다. 퍼블릭 베타는 2025년 12월에 시작되었으며, 발표에 따르면 'Gemini를 사용하여 애플리케이션을 구축하는 개발자들에게 빠르게 가장 선호되는 방식이 되었습니다.' 이번 GA 릴리스에는 **안정적인 스키마(Stable Schema)**와 함께 베타 기간 동안 개발자들이 명시적으로 요청했던 일련의 기능들이 포함되어 제공됩니다. 이 마지막 부분이 중요합니다. Google은 귀를 기울이고 있었으며, 출시된 기능들을 통해 그 사실을 확인할 수 있습니다.

이 포스트는 Google DeepMind의 그룹 제품 매니저(Group Product Manager)인 Ali Çevik과 Google DeepMind의 개발자 관계 엔지니어(Developer Relations Engineer)인 Philipp Schmid가 작성했습니다. 두 사람 모두 Gemini 스택을 출시하는 Google DeepMind 팀에 직접 소속되어 있습니다.

blog.google의 정확한 공식 문구 및 포지셔닝

이번 발표에서 가장 중대한 단 한 줄은 다음과 같습니다: 'Interactions API는 이제 Gemini 모델 및 에이전트와 상호작용하기 위한 우리의 기본 (primary) API입니다.' 여기서 '기본 (primary)'이라는 단어는 가볍게 쓰인 것이 아닙니다. Google은 또한 다음과 같이 밝혔습니다: '우리의 모든 문서는 이제 Interactions API를 기본값으로 설정하며, 생태계 파트너들과 협력하여 제3자 (3P) SDK 및 라이브러리 전반에서 이를 기본 인터페이스로 만들기 위해 노력하고 있습니다.' 이 문장을 두 번 읽어보십시오. 이것은 단순한 기능 플래그 (feature flag)가 아닙니다. 이는 배포 주도권의 탈취입니다.

파운데이션 모델 (foundation-model) 제공업체가 새로운 접점이 '제3자 (3P) SDK 및 라이브러리 전반의 기본 인터페이스'라고 말할 때, 그들은 기능을 설명하는 것이 아닙니다. 그들은 오케스트레이션 (orchestration) 미들웨어 계층을 직접 겨냥한 배포 전략을 설명하고 있는 것입니다.

이전 Gemini API 접점(surface)에서 변경된 점

GA (General Availability, 일반 가용성) 이전에는 Gemini로 구축한다는 것이 모델별 엔드포인트 (endpoint)를 조율하고, 대화 기록 (conversation history)을 직접 관리하며, 상태 (state) 및 오케스트레이션 (orchestration)을 위해 LangGraph와 같은 프레임워크를 덧붙이는 것을 의미했습니다. Interactions API는 이를 하나의 정전 (canonical) 엔드포인트로 통합합니다. 여기에서 추론 (inference)을 위한 모델 ID, 자율 작업을 위한 에이전트 ID를 전달하고, 장시간 실행되는 모든 작업에 대해 background=True를 설정하면 됩니다. 12월 이후 새로 추가된 사항은 다음과 같습니다: 관리형 에이전트 (Managed Agents), 백그라운드 실행 (background execution), Gemini Omni (곧 출시 예정), 그리고 도구 (tool) 개선 사항입니다. 이것은 점진적인 변화가 아닙니다. 스택 (stack) 전체가 이동하는 것입니다. 만약 오늘 프레임워크를 선택하고 있다면, 우리의 AI 에이전트 프레임워크 비교를 통해 이러한 옵션들을 나란히 비교해 볼 수 있습니다.

2025년 12월
Interactions API 퍼블릭 베타 출시
[Google Blog, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
...

Interactions API란 무엇인가: 아키텍처 및 핵심 설계

통합 엔드포인트 모델 설명

핵심 설계는 매우 단순합니다. 하나의 엔드포인트가 Gemini 모델(예: Gemini 3 Pro)과 에이전트(예: Google의 네이티브 Antigravity 에이전트)를 모두 노출합니다. 공식 포스트에 따르면, '모델을 호출하든 에이전트를 실행하든, Interactions API를 사용하면 단 몇 줄의 코드로 이를 수행할 수 있습니다. 추론(inference)을 위해 모델 ID를 전달하거나, 자율 작업(autonomous tasks)을 위해 에이전트 ID를 전달하고, 오래 걸리는 작업에는 background=True를 설정하면 됩니다.' 단 하나의 요청 형태면 충분합니다.

이는 역사적으로 분리되어 있던 두 가지 관심사, 즉 무상태 추론 (stateless inference)과 상태 유지 에이전트 실행 (stateful agentic execution)을 동일한 호출 뒤로 통합합니다. 더 이상 '챗봇을 만드는지' 또는 '에이전트를 만드는지'에 따라 SDK를 선택할 필요가 없습니다. API 계층에서 그 구분은 더 이상 중요하지 않게 되었습니다.

서버 측 상태(Server-side state)와 그것이 대체하는 것

이것이 미들웨어 계층을 폭파시키는 기능입니다. 서버 측 상태 (server-side state)를 통해 Google이 대화 기록, 세션 연속성(session continuity), 그리고 컨텍스트 윈도우 (context window)를 대신 관리해 줍니다. 이제 세션 토큰을 관리하거나, 메시지 배열을 다시 재생(replaying)하거나, Redis 기반의 메모리 저장소를 유지 관리할 필요가 없습니다. 저는 팀들이 정확히 이 문제에 분기별 엔지니어 3~4명분의 시간을 쏟아붓는 것을 보았습니다. 팀들이 오케스트레이션 프레임워크 (orchestration framework)를 찾았던 고전적인 이유인 '에이전트의 상태를 유지할 공간이 필요하다'는 논리는 대부분의 사용 사례에서 증발해 버립니다. 우리는 AI 에이전트 메모리 아키텍처 (AI agent memory architectures) 분석을 통해 이 기능이 대체하는 패턴들을 상세히 다룹니다.

상태가 제공자(provider) 측에 존재하는 순간, 모든 에이전트 프레임워크 가치 제안의 절반은 필수적인 의존성 (load-bearing dependency)이 아닌 편의를 위한 래퍼 (convenience wrapper)로 전락합니다.

인프라 수준에서 백그라운드 실행이 작동하는 방식

Interactions API 요청 라이프사이클: 호출부터 관리형 에이전트 실행까지

  1

    **단일 엔드포인트로의 클라이언트 호출**

개발자는 하나의 요청을 보냅니다: 모델 ID (예: Gemini 3 Pro) 또는 에이전트 ID (예: Antigravity), 그리고 선택 사항인 background=True. SDK를 전환할 필요가 없습니다.

↓

  2
...

Google은 이전 대화/세션 상태(state)를 자동으로 가져옵니다. 클라이언트 측의 히스토리 배열(history array)이나 토큰 관리(token bookkeeping)가 필요 없습니다.

↓

  3
...

내장 도구(Built-in tools: Search, Code Execution)는 단일 요청 내에서 사용자의 커스텀 함수 호출(custom function calls)과 병합됩니다. API가 이를 라우팅(routing)합니다.

↓

  4
...

에이전트가 추론(reasoning)하고, 코드를 실행하며, 웹을 탐색하고, 파일을 관리할 수 있는 원격 Linux 샌드박스(sandbox)가 프로비저닝(provisioned)됩니다.

↓

  5
...

전체 라이프사이클(lifecycle)을 보면 왜 표준적인 에이전트 워크로드(agentic workloads)에 외부 오케스트레이션 레이어(orchestration layer)가 필요하지 않은지 알 수 있습니다. 상태(state), 라우팅(routing), 실행(execution)이 모두 서버 측(server-side)에서 이루어지기 때문입니다.

더 넓은 Google ADK 생태계에서 Interactions API의 역할

Agent Development Kit (ADK)는 Interactions API에 직접 연결됩니다. 기존에 ADK가 별도의 오케스트레이션 루프(orchestration loop)를 필요로 했던 것과 달리, 이제는 서버 측 상태(server-side state)와 관리형 에이전트(Managed Agents)를 런타임(runtime)으로 활용할 수 있습니다. 정의를 위한 ADK와 실행을 위한 Interactions API의 조합은 Google이 지금까지 출시한 가장 일관된 에이전트 스택(agentic stack)입니다. 독립적인 라이브러리들을 조합하여 멀티 에이전트 시스템(multi-agent systems)을 구축하는 것과 비교하면, 프로덕션 팀들에게 주는 매력은 명확합니다. 완벽하지는 않습니다. 하지만 구성 요소들이 실제로 연결되는 첫 번째 사례입니다.

Diagram comparing legacy client-side agent state architecture versus server-side Interactions API architecture

미들웨어 붕괴(Middleware Collapse) 이벤트의 전/후: 레거시 아키텍처(legacy architecture)는 상태를 사용자의 서버와 오케스트레이션 프레임워크를 통해 라우팅하지만, Interactions API는 상태, 도구 라우팅(tool-routing), 실행을 서버 측에서 흡수합니다.

전체 기능 상세 분석: GA 출시와 함께 제공되는 모든 기능

관리형 에이전트(Managed Agents): 정의 및 작동 방식

Google의 발표에 따르면, '단 한 번의 API 호출로 에이전트가 추론, 코드 실행, 웹 브라우징 및 파일 관리를 수행할 수 있는 원격 Linux 샌드박스 (sandbox)가 프로비저닝됩니다.' Antigravity 에이전트가 기본값으로 제공되며, 사용자는 '지침(instructions), 기술(skills) 및 데이터 소스(data sources)'를 통해 커스텀 에이전트를 정의할 수 있습니다. 결정적으로, 자체 호스팅 실행 환경 (self-hosted execution environment)이 필요하지 않습니다 — 샌드박스는 Google이 관리합니다. 이는 CrewAI 또는 AutoGen 워커를 자체 인프라에서 실행하는 것과의 구조적 차이점입니다. 프로비저닝할 VM도, 관리할 컨테이너도 필요 없습니다. 단 한 번의 호출이면 충분합니다. 기성 빌딩 블록 (building blocks)을 원하신다면, AI 에이전트 라이브러리를 탐색하여 관리형 에이전트 (Managed Agents)에 매핑되는 패턴을 확인해 보세요.

도구 조합 및 멀티모달 입력 지원

이번 GA 출시를 통해 사용자는 단일 요청 내에서 검색 (Search) 및 코드 실행 (Code Execution)을 포함한 '내장 도구들을 혼합'하고 커스텀 함수 호출 (function calls)과 함께 사용할 수 있습니다. 이를 통해 AutoGen과 같은 프레임워크가 전통적으로 처리하던 수동적인 도구 라우팅 오케스트레이션 (tool-routing orchestration)을 제거할 수 있습니다. 멀티모달 생성 (Multimodal generation)은 통합 엔드포인트 (unified endpoint)의 일부이며, 공식 포스트에서는 Gemini Omni가 '곧(soon)' 지원될 것이라고 명시되어 있습니다. 아직 완전히 구현되지는 않았지만, 계획을 세우기에 충분히 가까운 시점입니다.

상태 유지 멀티턴 상호작용 모델 (Stateful multi-turn interaction model)

상태 (state)가 서버 측에 존재하기 때문에, 멀티턴 대화와 장기 실행되는 에이전트 루프 (agent loops)가 클라이언트 측의 리플레이 (replay) 없이도 지속됩니다. 이는 이전에 팀들이 LangGraph의 체크포인팅 (checkpointing)이나 커스텀 세션 저장소 (session store)를 강제로 사용하게 만들었던 상태 유지 프리미티브 (stateful primitive)입니다. 만약 직접 저장소를 구축해 본 경험이 있다면, 그것이 얼마나 차별화되지 않은(undifferentiated) 작업인지 정확히 알 것입니다. 이제는 그럴 필요가 없습니다.

모든 마이그레이션 전에 던져야 할 첫 번째 질문은 이것입니다: '내 스택에서 턴 사이의 상태를 유지하기 위해서만 존재하는 것은 무엇인가?' 만약 그것이 미들웨어 (middleware)의 대부분을 차지한다면, Interactions API는 그것을 유지해야 할 이유를 방금 삭제해 버린 것입니다.

Gemini 3 전용 파라미터: 지연 시간(latency), 비용, 그리고 멀티모달 충실도 제어

Gemini 3 Pro는 통합 엔드포인트(unified endpoint)를 통해 직접 호출할 수 있으며, 더 넓은 Gemini 3 제품군(family)은 요청 수준의 제어(request-level controls) 기능을 제공하여 품질과 비용 사이의 균형을 조절할 수 있게 합니다. 대규모 파이프라인(high-volume pipelines)을 운영하는 빌더들에게 있어, 요청당 충실도 튜닝(per-request fidelity tuning)은 지속 가능한 단위 경제(unit economics) 모델과 걷잡을 수 없이 불어나는 청구서 사이의 차이를 결정짓는 요소입니다. 현재 적용 중인 정확한 파라미터는 Gemini API pricing documentation에서 직접 확인하시기 바랍니다. 이러한 파라미터는 변경될 수 있으며, 문서가 대시보드의 변경 사항을 항상 즉각적으로 반영하지는 못할 수도 있습니다.