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

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

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 모델들이 도구(tools), 에이전트(agents), 상태(state)와 함께 조정되어야 하는 지점에서 신뢰성이 조용히 무너지고 있음에도 불구하고, 그들은 어떤 모델을 호출할지에만 집착합니다. 현대 AI 기술의 어려운 점은 추론(inference)이 아니라, 그 주변의 조정(coordination)이었습니다.

그것이 바로 Google이 방금 겨냥한 격차입니다. 2026년 6월 26일, Google은 Interactions API가 일반 가용성(GA)에 도달했으며, 이제 Gemini 모델 및 에이전트와 상호작용하기 위한 기본 API가 되었다고 발표했습니다. 이는 이전의 기본 방식을 대체하며, 관리형 에이전트(Managed Agents), 백그라운드 실행(background execution), 그리고 도구 조합(tool combination)을 하나의 통합된 엔드포인트로 제공합니다.

빠른 답변

• Google의 Interactions API (2026년 6월 26일 GA)는 Gemini 모델 및 에이전트로 구축하기 위한 새로운 주요 기본(primary, default) 방식입니다.

• 이 API는 관리형 에이전트 (Managed Agents) (단일 호출 Linux 샌드박스), 서버 측 상태 (server-side state), 그리고 백그라운드 실행 (background execution) 기능을 추가합니다.

• 에이전트 버그의 주요 원인이었던, 기존에 직접 작성해야 했던 오케스트레이션(orchestration) 코드를 제거합니다.

• Gemini 네이티브 프로덕션에 가장 적합하며, 멀티 벤더 이식성(multi-vendor portability)이 필요한 경우에는 여전히 LangGraph가 우세합니다.

이 글을 다 읽고 나면, 무엇이 출시되었는지, 아키텍처가 어떻게 작동하는지, 비용은 얼마인지, 언제 LangGraph 또는 AutoGen 대신 사용해야 하는지, 그리고 현재의 스택에 어떤 영향을 미치는지 정확히 알게 될 것입니다.

Gemini 모델과 에이전트를 위한 주요 인터페이스로서 Interactions API가 정식 출시(General Availability)되었다는 Google의 공식 발표입니다. 출처

조어된 프레임워크 — 정의

AI 조정 격차 (The AI Coordination Gap)

정의: AI 조정 격차(AI Coordination Gap)란 단일 모델 호출 내부가 아니라, 모델, 도구(Tools), 에이전트(Agents), 그리고 상태(State) 사이의 인계(Handoffs) 과정에서 누적되는 신뢰성 및 비용 페널티를 의미합니다. 이는 현대 AI 기술에서 가장 지배적인 실패 지점(Failure surface)이며, Interactions API가 명시적으로 해결하기 위해 설계된 문제입니다.

개요: Google이 이 AI 기술에 대해 실제로 발표한 내용

가장 중대한 사실은 다음과 같습니다: Google은 더 이상 모델 호출(Model call)을 상호작용의 기본 단위로 취급하지 않습니다. Interactions API의 정식 출시(GA)와 함께, 이제 기본 단위는 '상호작용(Interaction)'이 되었습니다. 이는 서버에서 관리되는 상태 유지형(Stateful)이며, 잠재적으로 장시간 실행될 수 있는 세션으로, 하나의 엔드포인트를 통해 모델 또는 에이전트를 대상으로 할 수 있습니다.

Ali Çevik (Google DeepMind, 그룹 제품 매니저)와 Philipp Schmid (Google DeepMind, 개발자 관계 엔지니어)가 작성한 공식 발표에 따르면, 이 API는 2025년 12월에 퍼블릭 베타(Public beta)로 출시되었으며, 그들의 표현을 빌리자면 'Gemini를 사용하여 애플리케이션을 구축하는 개발자들이 가장 선호하는 방식이 빠르게 되었다'고 합니다. 이번 정식 출시(GA)를 통해 안정적인 스키마(Schema)가 확정되었으며, 개발자들이 가장 많이 요청했던 기능들이 추가되었습니다.

왜 조정(Coordination)이 이토록 중요할까요? 데이터가 이를 증명하기 때문입니다. Stack Overflow의 2024 Developer Survey에 따르면, 개발자의 76%가 워크플로(Workflow)에서 AI 도구를 사용 중이거나 사용할 계획이라고 답했습니다. 하지만 이들 중 단 43%만이 해당 도구의 정확도를 신뢰한다고 답했습니다. 이러한 신뢰의 격차는 모델의 원시 품질(Raw model quality)보다는 실행(Execution)과 조정(Coordination) 단계에서 거의 전적으로 발생합니다. 이와 별개로, GitHub의 개발자 생산성 연구는 엔지니어가 통합(Integration) 및 글루 워크(Glue work, 연결 작업)에 낭비하는 시간이 핵심 로직(Core logic) 자체에 소비하는 시간보다 훨씬 크다는 것을 반복적으로 보여주었습니다.

네 가지 주요 추가 사항:

• Managed Agents (관리형 에이전트) — 단 한 번의 API 호출로 에이전트가 추론(Reasoning)하고, 코드를 실행하며, 웹을 탐색하고, 파일을 관리할 수 있는 원격 Linux 샌드박스(Sandbox)를 프로비저닝(Provisioning)합니다. Antigravity 에이전트가 기본값으로 제공되며, 지침(Instructions), 기술(Skills), 데이터 소스(Data sources)를 사용하여 커스텀 에이전트를 정의할 수 있습니다.

• Background execution (백그라운드 실행) — 모든 호출에서 background=True로 설정하면 서버가 상호작용을 비동기(Asynchronously)로 실행합니다. 더 이상 오래 걸리는 작업을 위해 연결(Connection)을 계속 열어둘 필요가 없습니다.

• Tool improvements (도구 개선) — 단일 상호작용 내에서 내장 도구(Built-in tools)와 사용자 정의 도구를 혼합하여 사용할 수 있습니다. 드디어 가능해졌습니다.

• Gemini Omni (곧 출시 예정) — 멀티모달 생성(Multimodal generation) 기능이 단기 추가 사항으로 도입될 예정입니다.

전략적 신호 또한 기능만큼이나 중요합니다. Google은 _이제 모든 문서의 기본값이 Interactions API로 설정되었다_고 밝혔으며, 서드파티 SDK 및 라이브러리 전반에 걸쳐 이를 기본 인터페이스로 만들기 위해 생태계 파트너들과 협력하고 있습니다. 이는 단순한 기능 출시가 아니라 플랫폼 수준의 리포지셔닝(Repositioning)입니다.

76%
의 개발자가 워크플로에서 AI 도구를 사용하거나 사용할 계획임
[Stack Overflow Developer Survey, 2024](https://survey.stackoverflow.co/2024/)
...

개발자의 단 43%만이 AI 출력물을 신뢰합니다 (Stack Overflow, 2024). 누락된 57%는 모델의 문제가 아니라, 조정 (coordination)의 문제입니다. 조정 레이어 (coordination layer)를 점유하는 자가 에이전트 시대를 지배할 것입니다.

이것은 무엇인가: 비전문가를 위한 Interactions API 설명

전문 용어를 걷어내고 설명하겠습니다. 수년간 대규모 언어 모델 (LLM)을 사용하여 구축한다는 것은 한 가지 패턴을 의미했습니다. 요청을 보내고, 응답을 받으면, 그 응답을 둘러싼 모든 것에 대해 개발자인 당신이 책임을 지는 방식입니다. 당신이 대화 기록 (conversation history)을 보유해야 했습니다. 도구 (tool)를 호출할 시점을 직접 결정해야 했습니다. 에이전트 루프 (agent loop)를 직접 연결해야 했습니다. 오래 실행되는 작업들을 일일이 관리해야 했습니다. 모델은 하나의 함수였고, 당신의 코드가 시스템이었습니다. 저 또한 셀 수 없이 많은 횟수로 그런 상용구 코드 (boilerplate)를 작성해 왔습니다.

Interactions API는 이를 뒤집습니다. 조정 (coordination) 작업을 Google의 서버로 옮깁니다. 당신은 원하는 바를 기술하기만 하면 됩니다. 모델이 답변하기를 원하는지, 혹은 에이전트가 다단계 작업 (multi-step task)을 수행하기를 원하는지 말이죠. 그러면 플랫폼이 상태 (state), 도구 호출 (tool calls), 샌드박스 (sandbox), 그리고 실행 생명주기 (execution lifecycle)를 관리합니다.

이를 자동차 엔진을 빌리는 것과 경로를 이미 알고 있는 운전사가 있는 자동차를 빌리는 것의 차이로 생각해 보세요. 이전에는 엔진 (모델)을 받고 자동차를 직접 제작하며 도로를 스스로 익혀야 했습니다. 이제는 목적지를 전달하기만 하면 관리형 에이전트 (managed agent)가 운전하게 할 수 있습니다. 에이전트는 코드를 작성하고, 웹을 탐색하며, 파일을 관리할 수 있는 실제 Linux 샌드박스 내부에서 작동합니다.

여기서 조용히 일어나는 변화는 바로 **서버 측 상태 (server-side state)**입니다. 서버가 대화 상태 (conversation state)를 소유하게 되면, 매 호출마다 전체 기록을 전송할 필요가 없습니다. 이는 긴 세션에서의 토큰 비용 (token costs)을 절감하며, 클라이언트가 관리하는 에이전트 루프에서 발생하는 고질적인 상태 동기화 (state-sync) 버그의 한 부류를 완전히 제거합니다. 저희도 이전 운영 시스템에서 정확히 이 버그 때문에 2주를 허비한 적이 있습니다.

Interactions API가 나타내는 아키텍처의 변화: 조정 로직(coordination logic)이 애플리케이션 코드에서 Google의 관리형 인프라(managed infrastructure)로 이동하며, 이는 AI 조정 격차(AI Coordination Gap) 문제를 직접적으로 해결합니다.

Interactions API의 작동 방식: AI 기술 아키텍처

이 메커니즘은 네 개의 조정된 레이어(layers)로 이해하는 것이 가장 좋습니다. 단일 호출을 실행할 때의 실제 흐름은 다음과 같습니다.

Interactions API: 단일 호출에서 관리형 실행까지

  1

    **통합 엔드포인트 (Unified Endpoint, Interactions API)**

사용자는 하나의 요청을 보냅니다. 직접적인 추론(inference)을 위해 모델 ID(model ID)를 전달하거나, 자율적인 작업을 위해 에이전트 ID(agent ID)를 전달합니다. 오래 걸리는 작업의 경우 background=True로 설정합니다. 어떤 방식이든 엔드포인트는 동일합니다.

↓

  2
...

Google의 서버가 상호작용(interaction)의 대화 기록, 도구 결과(tool results), 그리고 컨텍스트(context)를 보유합니다. 전체 트랜스크립트(transcript)를 다시 보낼 필요 없이 ID로 상호작용을 참조하므로, 페이로드(payload)를 줄이고 클라이언트 측의 상태 드리프트(state drift)를 제거할 수 있습니다.

↓

  3
...

에이전트 호출의 경우, 단일 API 호출이 원격 Linux 샌드박스(sandbox)를 프로비저닝(provision)합니다. Antigravity 에이전트(기본값) 또는 지침(instructions), 기술(skills), 데이터 소스(data sources)를 갖춘 사용자 정의 에이전트가 그 내부에서 추론하고, 코드를 실행하며, 웹을 탐색하고, 파일을 관리합니다.

↓

  4
...

background=True를 설정하면 상호작용이 서버 측에서 비동기(asynchronously)로 실행됩니다. 준비가 되면 결과를 폴링(poll)하거나 수신하면 됩니다. 연결을 계속 유지할 필요도 없고, 긴 작업에 대해 클라이언트 타임아웃(client timeout)을 관리하며 신경 쓸 필요도 없습니다.

↓

  5
...

내장된 도구(웹 브라우징, 코드 실행)가 단일 상호작용 내에서 사용자의 커스텀 도구와 혼합되어 작동하므로, 에이전트는 사용자가 직접 핸드오프(handoff)를 오케스트레이션(orchestrating)하지 않아도 Google 관리형 기능과 사용자 소유 기능 사이를 자유롭게 이동할 수 있습니다.

이 시퀀스가 중요한 이유는, 이 단계들 사이의 모든 화살표가 과거에는 사용자가 직접 작성하고 유지 관리해야 했던 코드였기 때문입니다. 그리고 그 코드가 바로 AI 조정 격차(AI Coordination Gap)였습니다.

코드를 보면 그 차이가 명확해집니다. '모델을 호출하든 에이전트 (Agent)를 실행하든, Interactions API를 사용하면 단 몇 줄의 코드로 이를 구현할 수 있다'는 Google의 포지셔닝은 면밀히 검토했을 때도 타당합니다. 아래는 개념적인 구조이며, 여러분이 유지 관리해야 할 코드가 얼마나 적은지 주목해 보십시오.

python — 개념적 예시

직접적인 모델 추론 (Direct model inference)

interaction = client.interactions.create(
model='gemini-model-id',
input='이 분기 보고서를 요약해줘.'
)

백그라운드에서 실행되는 자율 에이전트 (Autonomous agent) 작업

interaction = client.interactions.create(
agent='antigravity', # 기본 관리형 에이전트 (Managed Agent)
input='경쟁사 가격을 조사하고 비교표를 작성해줘.',
background=True # 서버에서 비동기적으로 실행됨
)

나중에: interaction ID로 결과 가져오기 — 상태(State)는 서버 측에 존재함

result = client.interactions.get(interaction.id)

무엇이 빠져 있는지 주목하십시오. 수동적인 에이전트 루프(Agent loop), 도구 라우팅(Tool-routing)을 위한 switch 문, 직접 관리해야 하는 대화 기록(Conversation-history) 배열이 전혀 없습니다. 삭제된 바로 그 코드가 대부분의 프로덕션 에이전트 버그가 발생하는 지점입니다. 에이전트 신뢰성에 관한 연구에 따르면, 실패의 원인은 모델의 추론 (Reasoning) 능력이 아니라 오케스트레이션 접착 코드 (Orchestration glue)에 있음이 일관되게 나타납니다.

[
▶

YouTube에서 시청하기
Google Gemini Interactions API & Managed Agents — walkthrough
Google DeepMind • Gemini agents architecture

](https://www.youtube.com/results?search_query=google+gemini+interactions+api+agents)

전체 기능 목록: Interactions API가 할 수 있는 모든 것

발표 내용을 엄격히 바탕으로 한, GA(General Availability) 기준 확인된 전체 기능 세트는 다음과 같습니다:

• 단일 통합 엔드포인트 (Single unified endpoint) — Gemini 모델 및 에이전트를 위한 하나의 인터페이스, 하나의 모델 ID 또는 에이전트 ID.

• 서버 측 상태 (Server-side state) — 플랫폼이 대화 및 상호작용 상태를 관리합니다.

• 백그라운드 실행 (Background execution) — background=True를 통해 모든 상호작용을 서버 측에서 비동기적으로 실행합니다.

• 도구 조합 (Tool combination) — 단일 상호작용 내에서 내장 도구와 사용자 정의 도구를 혼합하여 사용합니다.

• 멀티모달 생성 (Multimodal generation) — Gemini Omni(곧 출시 예정으로 발표됨)를 통해 제공됩니다.

• 관리형 에이전트 (Managed Agents) — 단 한 번의 API 호출로 원격 Linux 샌드박스(sandbox)를 프로비저닝합니다.

• 코드 실행 (Code execution) — 에이전트가 샌드박스 내부에서 코드를 실행합니다.

• 웹 브라우징 (Web browsing) — 에이전트가 내장된 기능으로서 웹을 탐색합니다.

• 파일 관리 (File management) — 에이전트가 샌드박스 내의 파일을 관리합니다.

• Antigravity 기본 에이전트 (Antigravity default agent) — 즉시 사용 가능한(out-of-the-box) 관리형 에이전트로 제공됩니다.

• 사용자 정의 에이전트 (Custom agents) — 지침(instructions), 기술(skills), 데이터 소스를 사용하여 자신만의 에이전트를 정의합니다. 바로 이 지점에서 흥미로운 프로덕션 작업이 이루어집니다.

• 안정적인 스키마 (Stable schema) — GA(General Availability)는 프로덕션 빌드를 위한 스키마 안정성을 보장합니다.

• 생태계 기본값 (Ecosystem default) — 제3자 SDK 및 라이브러리 전반에 걸쳐 기본값으로 자리 잡고 있습니다.

Google이 방금 배관(plumbing)을 무료로 제공했습니다.

액세스 및 사용 방법: 실제 작동 시연