에이전트 아키텍처를 위한 AI 기술: Google의 Interactions API (2026 가이드)

원문은 twarx.com에서 처음 게시되었습니다 - 전체 대화형 버전은 그곳에서 읽을 수 있습니다.

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

대부분의 AI 기술은 잘못된 계층(layer)에서 최적화되고 있습니다. 팀들은 최고의 모델을 선정하고 가장 영리한 프롬프트(prompt)를 튜닝하는 데 몇 주를 허비하지만, 모델, 도구(tool), 메모리(memory), 그리고 에이전트(agent) 사이의 핸드오프(handoff) 과정에서 상태(state)가 조용히 유실되며 전체 시스템이 무너지는 것을 지켜보게 됩니다. Google은 방금 그런 실수를 저지르기 더 어렵게 만들었습니다. 그렇게 함으로써 Google은 AI 기술의 한 카테고리인 에이전트 아키텍처(agent architecture)를 위한 기본 추상화 계층(abstraction layer)을 재설정했습니다.

당신을 불편하게 만들 부분은 바로 이것입니다. 모델은 거의 병목 현상(bottleneck)의 원인이 아닙니다. 저는 새벽 3시의 장애 리뷰(incident reviews)를 충분히 겪어보았기에, 실패의 원인이

• 개요 (What): Gemini 모델(추론, inference)과 에이전트(자율 작업, autonomous tasks)를 모두 호출하기 위한 Google의 주요 통합 API 엔드포인트 (endpoint).

• 상태 (Status): 2026년 6월 25일 기준 정식 출시 (GA, General Availability); 2025년 12월 퍼블릭 베타 (public beta) 출시.

• 발표자 (Announced by): Ali Çevik (Google DeepMind, Group Product Manager) 및 Philipp Schmid (Google DeepMind, Developer Relations Engineer).

• 핵심 기능 (Core capabilities): 통합 모델+에이전트 엔드포인트, 서버 측 상태 관리 (server-side state), 관리형 에이전트 (Managed Agents, 원격 Linux 샌드박스), 백그라운드 실행 (background=True), 도구 조합 (tool combination), 멀티모달 생성 (multimodal generation), 안정적인 스키마 (stable schema).

• 기본 에이전트 (Default agent): Antigravity 에이전트가 기본 관리형 에이전트 (Managed Agent)로 제공됨.

• 출시 예정 (Forthcoming): Gemini Omni ("곧 출시"로 명시됨).

• 언급된 경쟁사 (Competitors named): OpenAI (Assistants/Responses), Anthropic (Messages + tools, MCP), LangGraph, CrewAI, AutoGen.

• 새롭게 정의된 개념 (Coined concept): AI 조정 격차 (The AI Coordination Gap) — 각 상태가 전달될 때마다 독립적으로는 정확한 AI 구성 요소들 사이에서 누적되는 소리 없는 신뢰성 손실.

Google의 Interactions API가 Gemini 모델과 에이전트를 위한 주요 인터페이스로서 정식 출시(GA)되었습니다. 출처: Google

새롭게 정의된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (The AI Coordination Gap)는 모델, 도구, 메모리 저장소, 에이전트와 같이 독립적으로는 정확한 AI 구성 요소들이 서로에게 상태를 전달할 때마다 발생하는, 소리 없는 신뢰성 손실을 의미합니다. 이는 개별적으로는 매우 뛰어난 부품들이 모였음에도 불구하고 왜 전체 시스템은 취약해지는지를 설명하는 개념입니다.

Google은 Interactions API 정식 출시(GA)를 통해 실제로 무엇을 내놓았는가?

2026년 6월 25일, Google DeepMind는 Interactions API의 정식 출시(GA)를 선언하며, 이를 Gemini 모델 및 에이전트(agents)와 상호작용하기 위한 회사의 주요 API로 명명했습니다. 그룹 제품 매니저(Group Product Manager) Ali Çevik과 개발자 관계 엔지니어(Developer Relations Engineer) Philipp Schmid가 작성한 이 발표에 따르면, 해당 API는 2025년 12월 퍼블릭 베타(public beta)로 출시된 이후 "Gemini를 활용한 애플리케이션을 구축하는 개발자들에게 빠르게 가장 선호되는 방식이 되었다"고 언급했습니다.

"단 한 번의 API 호출로 에이전트가 추론(reasoning), 코드 실행(execute code), 웹 브라우징(browse the web) 및 파일 관리(manage files)를 수행할 수 있는 원격 Linux 샌드박스(sandbox)를 제공합니다." — Ali Çevik & Philipp Schmid, Google DeepMind, Interactions API GA 발표문

이번 정식 출시(GA)는 프로덕션 시스템(production systems)을 배포하는 모든 이들에게 중요한 세 가지 변화를 가져옵니다. 첫째, **안정적인 스키마(stable schema)**를 고정하여, 오늘 구축한 계약(contract)이 향후 변경되어 사용자에게 영향을 미치지 않도록 합니다. 둘째, 역사적으로 분리되어 있던 두 가지 기본 요소(primitives)인 '모델 호출(calling a model)'과 '에이전트 실행(running an agent)'을 _하나의 엔드포인트(one endpoint)_로 통합합니다. 마지막으로, 베타 기간 동안 개발자들이 요청했던 기능들인 관리형 에이전트(Managed Agents), 백그라운드 실행(background execution), Gemini Omni (출시 예정), 그리고 확장된 도구 조합(tool combination) 기능을 추가했습니다.

이를 명확하게 설명하자면 다음과 같은 개념적 도약이 있습니다. 오늘날 대부분의 스택에서는 상태 관리(state), 재시도(retries), 도구 호출(tool calls), 다단계 추론(multi-step reasoning)을 관리하기 위해 모델 API 위에 LangGraph, CrewAI, AutoGen과 같은 오케스트레이션 프레임워크(orchestration framework)를 덧붙여 사용합니다. Google은 이러한 조정 로직(coordination logic)을 단일 요청 뒤의 _서버 측(server-side)_으로 이동시키고 있습니다. 추론(inference)을 위한 모델 ID를 전달하고, 자율 작업(autonomous tasks)을 위한 에이전트 ID를 전달하며, 오래 걸리는 작업에 대해 background=True를 설정하기만 하면 됩니다. 이것이 전체적인 사고 모델(mental model)입니다.

왜 지금일까요? 업계가 AI 조정 격차 (AI Coordination Gap)를 보완하기 위해 지난 2년 동안 정교한 클라이언트 측 오케스트레이션 (client-side orchestration)을 구축하는 데 시간을 보냈기 때문입니다. 그리고 Google은 그 격차가 애플리케이션 코드가 아닌 서버에 위치해야 한다고 주장하고 있습니다. 발표에 따르면, 이제 Google의 모든 문서는 Interactions API를 기본값으로 설정하며, Google은 "에코시스템 파트너들과 협력하여 제3자 (3P) SDK 및 라이브러리 전반에 걸쳐 이를 기본 인터페이스로 만들기 위해 노력하고 있다"고 밝혔습니다. 이 마지막 문구는 조용한 폭탄과 같습니다. 이것은 단순히 새로운 엔드포인트 (endpoint)가 아닙니다. AI 기술의 전체 에코시스템에 대한 기본 추상화 계층 (abstraction layer)을 재설정하려는 시도입니다.

에이전트 (agents)를 통해 승리하고 있는 팀들은 조정 (coordination) 기능을 앱 코드에서 분리하여, 새벽 3시에 디버깅할 필요가 없는 인프라로 옮겼습니다.

시니어 엔지니어들에게 실질적인 질문은 이분법적입니다. 직접 만든 오케스트레이션 계층을 계속 유지할 것인가, 아니면 플랫폼이 상태 (state), 재시도 (retries), 그리고 샌드박스 (sandbox)를 관리하게 할 것인가? 이 글은 가격, 비교, 마이그레이션 (migration) 위험, 그리고 이 기술을 도입해서는 안 되는 정확한 시나리오 등 구체적인 내용을 통해 그 답을 제시합니다.

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

Google Interactions API란 무엇인가? (쉬운 설명)

당신이 바쁜 레스토랑 주방을 운영한다고 상상해 보세요. 오늘날 당신 — 즉 개발자 — 은 각 스테이션 사이에서 소리치는 헤드 셰프입니다: "그릴, 스테이크 올려! 디저트 팀, 플레이팅 해! 누가 주문서 다시 확인해!" 정보가 스테이션 사이를 전달될 때마다 무언가 누락될 수 있습니다. 이러한 외침과 조정 과정이 오늘날 소프트웨어에서 오케스트레이션 프레임워크 (orchestration frameworks)가 하는 일입니다.

Interactions API는 주방 _내부_에 상주하는 주방 매니저를 고용하는 것과 같습니다. 당신은 그들에게 주문서 한 장을 건네줍니다. 그들은 어떤 스테이션을 사용할지 결정하고, 진행 상황을 추적하며, 실패한 작업은 재시작하고, 완성된 접시를 당신에게 다시 전달합니다. 당신은 더 이상 모든 스테이션을 마이크로매니징 (micromanaging) 하는 셰프가 아닙니다. 당신은 명확한 주문 하나를 내리는 고객입니다.

기술적인 용어로 설명하자면, Interactions API는 Gemini 모델을 실행(단일하고 빠른 예측)하거나 **에이전트 (agent)**를 실행(여러 단계에 걸쳐 추론하고, 도구를 사용하며, 자율적으로 목표를 추구하는 시스템)할 수 있는 **단일 HTTP 엔드포인트 (single HTTP endpoint)**입니다. 서버가 대화 상태와 작업 진행 상황 — Google이 **서버 측 상태 (server-side state)**라고 부르는 것 — 을 유지하므로, 귀하의 앱이 모든 요청에 전체 이력을 쑤셔 넣을 필요가 없습니다.

이번 발표에서 가장 간과된 단 한 줄은 바로

마케팅 수식어를 걷어내고 보면, Interactions API는 단순한 원칙 하나로 작동합니다: 조정 상태(coordination state)를 클라이언트에서 서버로 이동시키는 것입니다. 전통적인 스택에서는 애플리케이션이 컨텍스트를 구성하고, 모델을 호출하고, 도구 요청(tool requests)을 파싱하고, 해당 도구들을 실행하고, 결과를 다시 입력하며, 완료될 때까지 루프를 돕니다. 이러한 모든 핸드오프(handoff) 과정 하나하나가 AI 조정 격차(AI Coordination Gap)가 신뢰성을 갉아먹는 지점입니다.

제 경험을 바탕으로 말씀드리겠습니다. 이전 프로젝트에서 제품 페이지를 크롤링하고 비교 보고서를 작성하는 리서치 에이전트(research agent)를 구축한 적이 있습니다. Gemini 호출 자체는 우리가 던진 모든 평가(eval)를 통과했습니다. 하지만 시스템은 스테이징 환경에서 6번 중 1번꼴로 실패했습니다. 범인은 모델이 아니었습니다. 가끔 출력이 잘리는 도구 결과 파서(tool-result parser)였고, 우리의 재시도 로직(retry logic)이 오류를 조용히 삼켜버리는 바람에 5단계가 6단계에 쓰레기 데이터를 전달했던 것입니다. 우리는 엔드 투 엔드(end-to-end) 실패율을 약 16%로 기록했는데, 이는 단계당 약 97%의 성공률을 가진 6단계 체인에서 복합 오류 수학(compound-error math)이 예측하는 값과 거의 일치했습니다. 우리는 더 나은 모델로 이를 해결하지 않았습니다. 단계를 삭제하고 재시도를 중앙 집중화함으로써 해결했습니다. Interactions API는 여러분을 대신해 그 삭제 작업을 수행해 줍니다.

Interactions API 요청 흐름 — 단일 호출에서 작업 완료까지

  1

    **클라이언트가 단일 요청을 보냄**

모델 ID(추론) 또는 에이전트 ID(자율 작업)를 포함하여 단일 Interactions 엔드포인트로 POST 요청을 보냅니다. 오래 걸리는 작업의 경우 background=True를 추가하세요. 클라이언트 측에서는 오케스트레이션(orchestration) 코드가 필요하지 않습니다.

↓

  2
...

모델 ID는 빠른 추론(inference)으로 라우팅되어 결과를 반환합니다. 에이전트 ID는 관리형 에이전트(Managed Agent)를 프로비저닝합니다. 이는 추론(reasoning), 코드 실행, 웹 브라우징 및 파일 관리가 가능한 원격 Linux 샌드박스(sandbox)입니다.

↓

  3
...

대화 이력(conversation history)과 작업 진행 상황은 귀하의 요청 페이로드(payload)가 아닌 Google의 인프라에 상주합니다. 재시도(retries), 도구 루프(tool loops), 중간 결과물은 귀하를 대신해 관리됩니다 — 바로 이 지점에서 조정 격차(Coordination Gap)가 해소됩니다.

↓

  4
...

내장된 도구(Built-in tools)는 단일 상호작용(interaction) 내에서 귀하의 커스텀 도구(custom tools)와 혼합되어 사용됩니다. 에이전트는 스스로 추론하고, 도구를 호출하며, 샌드박스(sandbox) 내에서 코드를 실행하고, 목표를 향해 자율적으로 반복(iterate)합니다.

↓

  5
...

background=True를 설정하면 서버가 상호작용을 비동기(asynchronously) 방식으로 실행합니다. 작업이 완료되면 폴링(poll)하거나 결과를 수신하면 됩니다. 연결을 계속 유지해야 하는 HTTP 연결(held-open HTTP connection)이나 클라이언트 측의 타임아웃 조절(timeout juggling)이 필요 없습니다.

이 시퀀스(sequence)가 중요한 이유는 기존의 클라이언트 측 핸드오프(handoff)가 서버 관리형 전환(server-managed transition)으로 대체되기 때문입니다. 이를 통해 AI 조정 격차(AI Coordination Gap)로 인해 발생하는 누적적인 신뢰성 손실을 제거합니다.

백그라운드 실행(background execution) 기능은 정말 강조할 만한 가치가 있습니다. 발표 내용에 따르면 다음과 같습니다: "모든 호출에 background=True를 설정하십시오. 서버가 상호작용을 비동기 방식으로 실행합니다." 이 단일 플래그(flag)는 에이전트 시스템에서 가장 까다로운 문제 중 하나인, HTTP 타임아웃을 초과하는 장기 실행 작업(long-running tasks) 문제를 해결합니다. 40개의 페이지를 탐색하고 보고서를 작성하는 리서치 에이전트(research agent)를 위해 더 이상 취약한 웹소켓(websocket)이나, 귀하가 한밤중에 직접 구축해야 했던 폴링 상태 머신(polling state machine)이 필요하지 않습니다. 서버가 라이프사이클(lifecycle)을 관리합니다.