Originally published at twarx.com - 전체 대화형 버전은 그곳에서 읽어보세요.

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

Google은 모델 호출(model-call)과 에이전트 오케스트레이션(agent-orchestration) 스택 전체를 단일 엔드포인트(endpoint)로 통합했습니다. 그리고 대부분의 팀은 2025년에 배포했던 글루 코드(glue code)가 이제는 쓸모없는 짐이 되었다는 사실을 깨닫는 데 향후 6개월을 소비하게 될 것입니다.

2026년 6월 26일, Google은 자사의 Interactions API가 Gemini 모델 및 에이전트를 위한 주요 AI 기술 (AI technology) 인터페이스로서 일반 가용성(general availability) 단계에 도달했다고 발표했습니다. 이 API는 추론(inference), 자율 에이전트(autonomous agents), 서버 측 상태(server-side state), 백그라운드 실행(background execution) 및 멀티모달 생성(multimodal generation)을 단 한 번의 호출로 통합합니다. 이는 Chat Completions 형식이 사실상의 표준(de facto standard)이 된 이후 빌더들에게 가장 중대한 AI 기술 (AI technology) 변화입니다. 이 글을 마칠 때쯤 여러분은 정확한 사실, 아키텍처(architecture), 비용, 명시된 경쟁사 비교, 그리고 명확한 마이그레이션(migrate) 또는 대기(wait) 결정에 대한 정보를 얻게 될 것입니다.

Google의 Interactions API가 Gemini 모델 및 에이전트를 위한 주요 인터페이스로서 일반 가용성(general availability)에 도달했습니다 — 추론, 에이전트, 상태 및 백그라운드 실행을 위한 단일 엔드포인트입니다. 출처: Google

개요: 대부분의 AI 기술 (AI technology) 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다

시니어 엔지니어들이 에이전트 시스템을 이미 프로덕션(production)에 배포한 후에야 비로소 깨닫게 되는 불편한 진실이 있습니다. 바로 모델이 병목 현상(bottleneck)의 원인이 아니었다는 점입니다. 진짜 문제는 조정(Coordination)이었습니다. 모델 호출, 모델이 사용하는 도구(tools), 읽어들이는 메모리(memory), 시작하는 장기 실행 작업(long-running task), 그리고 이 모든 것을 감독하는 에이전트 사이의 배선(wiring) — 바로 이 지점에서 신뢰성이 무너집니다. 제가 2023년 이후 직접 출시하거나 검토한 12개 이상의 에이전트 빌드 경험을 바탕으로 추산해 보면, 엔지니어링 시간의 약 70%가 모델 작업이 아닌 이러한 조정 계층(coordination layer)에서 조용히 사라집니다. 이는 Gartner의 광범위한 전망과도 일치하는데, Gartner는 모델의 정확도가 아니라 운영 통합 및 오케스트레이션(orchestration) 오버헤드가 대부분의 기업용 AI 프로젝트가 프로덕션에 도달하기 전에 중단되는 원인이라고 경고해 왔습니다. 저는 팀들이 실제 실패 원인이 상태 전달(state-passing) 로직의 레이스 컨디션(race condition)임에도 불구하고, 모델 업그레이드만을 쫓으며 분기 전체를 허비하는 것을 목격해 왔습니다.

2025년 12월 퍼블릭 베타로 출시되어 2026년 6월 26일에 일반 가용성(general availability) 단계에 도달한 Google의 Interactions API는 AI 기술 (AI technology)의 미래가 더 큰 모델이 아니라, 통합된 조정 인터페이스(unified coordination surface)라는 점을 업계에서 가장 명확하게 인정한 사례입니다. 단 하나의 엔드포인트(endpoint). 추론(inference)을 위해서는 모델 ID를 전달합니다. 자율 작업(autonomous tasks)을 위해서는 에이전트 ID를 전달합니다. 장기 실행되는 모든 작업에는 background=True를 설정합니다. 동일한 프리미티브(primitive)가 이 세 가지를 모두 처리합니다.

이것은 단순한 기능 출시가 아닌 구조적 변화입니다. Google은 모든 문서의 기본값을 Interactions API로 전환하고 있으며, Chat Completions 형식이 한 세대의 툴링(tooling)에 대한 사실상의 표준(de facto standard)이 된 것과 마찬가지로, 서드파티 SDK 및 라이브러리 전반에서 이를 기본 인터페이스로 만들기 위해 생태계 파트너들과 협력하고 있습니다.

Coined Framework

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (The AI Coordination Gap)는 개별 모델이 얼마나 뛰어난 성능을 갖추게 되었는지와, 그 주변 시스템들이 상태 (state), 도구 (tools), 메모리 (memory) 및 실행 (execution)을 얼마나 형편없이 조정(coordinate)하고 있는지 사이의 벌어지는 간극을 의미합니다. 이는 대부분의 팀이 모델 품질 문제로 오진하지만, 실제로는 오케스트레이션 아키텍처 (orchestration-architecture) 문제인 시스템적 문제를 지칭합니다.

이 글 전체를 통해 우리는 Interactions API를 핵심 계층별로 분해하고, 각 계층이 실제 운영 환경에서 정확히 어떻게 작동하는지 보여줄 것입니다. 또한 이를 언제 도입해야 하는지(그리고 도입하지 말아야 하는지)를 매핑하고, LangGraph, Vertex AI Agent Builder, AWS Bedrock Agents, Anthropic's API, OpenAI's stack과 정면으로 비교하며, 실제 마이그레이션 과정을 살펴볼 것입니다. 글 전체를 관통하는 논지는 다음과 같습니다. AI 에이전트 (AI agents)를 통해 승리하는 팀은 가장 많은 GPU를 보유한 팀이 아니라, 조정 격차 (Coordination Gap)를 해소한 팀이라는 것입니다.

1
모델, 에이전트, 상태 및 백그라운드 실행을 위한 통합 엔드포인트
[Google, 2026](https://blog.google/innovation-and-ai/technology/developers-tools/interactions-api-general-availability/)
...

발표된 내용 — 정확한 사실 관계

누가: Google DeepMind가 발표하였으며, Google DeepMind의 그룹 제품 매니저(Group Product Manager)인 Ali Çevik과 Google DeepMind의 개발자 관계 엔지니어(Developer Relations Engineer)인 Philipp Schmid가 The Keyword (blog.google)에 공동 작성하였습니다.

무엇을: Interactions API가 정식 출시(general availability)되었으며, 이제 Gemini 모델 및 에이전트와 상호작용하기 위한 Google의 주요 (primary) API가 되었습니다. 이는 '서버 측 상태 (server-side state), 백그라운드 실행 (background execution), 도구 조합 (tool combination) 및 멀티모달 생성 (multimodal generation) 기능을 갖춘 Gemini 모델 및 에이전트를 위한 단일 통합 엔드포인트'로 설명됩니다.

언제: 정식 출시(GA)는 2026년 6월 26일입니다. 퍼블릭 베타(public beta)는 2025년 12월에 시작되었습니다.

위치: Google AI Studio 및 Gemini 개발자 환경(developer surface) 내에서 제공되며, 현재 문서화(documentation)의 기본값이 Interactions API로 설정되어 있습니다.

공식 발표에 따르면, 정식 출시(GA) 버전은 **안정적인 스키마 (stable schema)**와 함께 개발자들이 요청했던 주요 신기능들을 제공합니다: 관리형 에이전트 (Managed Agents), 백그라운드 실행 (background execution), Gemini Omni (출시 예정) 및 도구(tool) 개선 사항입니다. Google DeepMind의 개발자 관계 엔지니어(Developer Relations Engineer)인 Philipp Schmid는 발표에서 베타 버전이 'Gemini를 사용하여 애플리케이션을 구축하는 개발자들에게 빠르게 가장 선호되는 방식이 되었다'라고 설명했습니다.

단계당 성공률이 97%인 6단계 파이프라인은 엔드 투 엔드(end-to-end)로 볼 때 신뢰도가 83%에 불과합니다. 이것은 Gemini의 문제가 아니라 조정(coordination)의 문제이며, 더 큰 모델이라고 해서 이를 해결할 수 있는 것은 아닙니다.

이것은 무엇인가: 쉬운 설명

여러분이 작은 사업을 운영하고 있고 'AI 에이전트'가 필요하다는 말을 들었다고 상상해 보세요. 오늘날 에이전트를 구축한다는 것은 모델 API, 별도의 메모리 저장소(memory store), 도구 실행 레이어(tool-execution layer), 코드를 안전하게 실행할 샌드박스(sandbox), 그리고 몇 초 이상 걸리는 작업을 위한 작업 큐(job queue)를 하나하나 엮는 것을 의미합니다. 다섯 개의 업체, 다섯 개의 청구서, 그리고 각각 독립적으로 고장 날 수 있는 다섯 가지 요소들입니다. 저는 작업 큐 하나를 관리하기 위해서만 전담 온콜(on-call) 교대 근무가 필요한 팀들을 보기도 했습니다.

Interactions API는 이러한 복잡한 배관 작업(plumbing)을 단일한 출입구로 대체합니다. 여러분은 단 한 번의 요청만 보내면 됩니다. 그 요청 안에 여러분이 원하는 것을 명시하기만 하면 됩니다:

• 모델이 질문에 답하기를 원하나요? 모델 ID (model ID) (예: Gemini 모델)를 전달하면 추론(inference) 결과가 제공됩니다.

• 자율 에이전트가 다단계 작업을 수행하기를 원하나요? _에이전트 ID (agent ID)_를 전달하면 시스템이 추론(reasoning)하고, 도구를 사용하며, 작업을 완료합니다.

• 작업이 오래 걸리나요? background=True로 설정하면 Google이 서버에서 비동기(asynchronously) 방식으로 실행합니다. 여러분의 앱은 그 자리에서 계속 기다릴 필요가 없습니다.

진정으로 새로운 부분은 **Managed Agents (관리형 에이전트)**입니다. 단 한 번의 API 호출로 에이전트가 '추론하고, 코드를 실행하며, 웹을 탐색하고, 파일을 관리할 수 있는' 원격 Linux 샌드박스 (sandbox)를 프로비저닝합니다. Google의 Antigravity 에이전트가 기본값으로 제공되며, 여러분은 지침(instructions), 기술(skills), 데이터 소스(data sources)를 사용하여 자신만의 커스텀 에이전트를 정의할 수 있습니다.

반드시 기억해야 할 문구는 바로 **서버 측 상태 (server-side state)**입니다. 2025년에는 여러분이 대화 메모리(conversation memory)를 소유하고 매 호출마다 이를 주고받아야 했습니다. Interactions API를 사용하면 서버가 상태를 유지합니다. 이는 토큰 낭비가 줄어들고, 경합 조건 (race conditions)이 감소하며, 매 턴마다 수동으로 컨텍스트 윈도우 (context windows)를 다시 구축할 필요가 없음을 의미합니다.

시각화된 AI 조정 격차 (AI Coordination Gap): 파편화된 멀티 벤더 에이전트 스택 (왼쪽) 대 상태, 도구, 샌드박스 및 백그라운드 실행을 흡수하는 통합된 Interactions API 단일 엔드포인트 (오른쪽).

Interactions API가 AI 기술 조정 방식을 바꾸는 방법 — 메커니즘과 아키텍처

내부적으로 Interactions API는 여러분의 애플리케이션과 기반이 되는 Gemini 모델 사이에 위치하는 **조정 계층 (coordination layer)**입니다. 여러분이 루프를 오케스트레이션(orchestrating)하는 대신 — 모델 호출, 출력 파싱, 도구 결정, 도구 호출, 결과 피드백, 반복 — 서버가 여러분을 대신해 해당 루프를 실행하고 단계 사이에 상태를 유지합니다. 이러한 변화가 점진적인 것처럼 들릴 수 있지만, 그렇지 않습니다. 클라이언트에서 제거하는 모든 홉 (hop)은 프로덕션 환경에서 제거되는 결함 모드 (failure mode)입니다.

Interactions API 요청 라이프사이클 (모델 호출 → 에이전트 → 백그라운드 실행)

  1

    **Interactions API 엔드포인트로의 단일 요청**

여러분의 앱은 한 번의 호출을 보냅니다. 여기에는 모델 ID (추론) 또는 에이전트 ID (자율 작업)와 함께 background=True와 같은 선택적 플래그가 포함됩니다. 입력값은 텍스트, 이미지, 오디오와 같은 멀티모달 (multimodal) 형태일 수 있습니다.

↓

  2
...

이 API는 서버에 저장된 상호작용 상태 (interaction state)를 로드하므로, 전체 이력을 다시 보낼 필요가 없습니다. 이것이 바로 조정 격차 (Coordination Gap)가 해소되는 지점입니다. 메모리가 클라이언트가 아닌 실행부 바로 옆에 존재하게 됩니다.

↓

  3
...

에이전트가 추론하고, 코드를 실행하며, 웹을 탐색하고, 파일을 관리할 수 있는 원격 Linux 샌드박스 (sandbox)가 구동됩니다. Antigravity가 기본 에이전트이며, 커스텀 에이전트는 자체적인 지침 (instructions), 기술 (skills), 데이터 소스를 가져옵니다.

↓

  4
...

내장된 도구 (built-in tools)들은 혼합되어 서버 측에서 호출됩니다. 모델이 결정하면 서버가 실행하고, 그 결과는 다시 동일한 저장된 상호작용으로 피드백됩니다. 즉, 클라이언트의 왕복 (round-trips) 없이 루프가 실행됩니다.

↓

  5
...

background=True 설정을 사용하면 상호작용이 비동기적 (asynchronously)으로 실행됩니다. 앱은 나중에 완료된 결과를 폴링 (poll)하거나 수신하게 되며, 이는 연구 작업, 코드 생성 또는 긴 브라우징 세션에 이상적입니다.

이 시퀀스가 중요한 이유는 클라이언트에서 제거하는 모든 단계(hop)가 곧 프로덕션에서 제거되는 실패 모드 (failure mode)이기 때문입니다. 이것이 전체적인 가치 제안 (value proposition)입니다.

그래프를 직접 작성하고, 상태 머신 (state machine)을 관리하며, 도구 런타임 (tool runtime)을 호스팅하고, 샌드박스를 직접 운영해야 하는 기존의 LangGraph 또는 AutoGen 배포 방식과 비교해 보십시오. Interactions API가 이러한 프레임워크들을 쓸모없게 만드는 것은 아닙니다. 다만, 그 프레임워크들이 관리하기 위해 만들어졌던 운영상의 부담 (operational burden)을 흡수하는 것입니다. 이는 매우 의미 있는 차이입니다.

지난 3년 동안 우리는 모델을 오케스트레이션 (orchestrate)하기 위한 프레임워크를 구축해 왔습니다. Google은 방금 그 오케스트레이션을 API 내부로 옮겼습니다. 프레임워크 계층은 곧 매우 얇아질 것입니다.

전체 기능 목록 — 가능한 모든 것

Google의 발표에 근거하여, Interactions API의 GA (General Availability) 릴리스는 다음을 제공합니다: