AI 기술의 변화: Gemini Interactions API가 이제 Google의 기본값이 되다

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

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

2026년 중반 가장 중대한 AI 기술 변화: Google이 전체 Gemini 개발자 스택을 단일 엔드포인트(endpoint)로 통합했으며, 여러분의 오케스트레이션(orchestration) 접착 코드(glue code) 대부분을 조용히 쓸모없게 만들었습니다.

오늘 Google은 Gemini Interactions API가 일반 사용 가능(general availability, GA) 상태에 도달했으며, 이제 Gemini 모델 및 에이전트(agents)와 상호작용하기 위한 기본 API가 되었다고 발표했습니다. 이는 서버 측 상태(server-side state), 백그라운드 실행(background execution), 도구 조합(tool combination), 멀티모달 생성(multimodal generation)을 포함하는 이전의 요청 패턴을 대체합니다. 이는 프런티어 연구소(frontier lab)가 모델뿐만 아니라 개발자 인터페이스 자체를 재편하는 드문 AI 기술적 순간입니다. 자체 베타 테스트 결과, 하나의 도구 조합 에이전트가 약 200줄의 LangGraph 접착 코드(glue code)에서 단 한 번의 API 호출로 줄어들었습니다. 이 글을 읽고 나면 무엇이 출시되었는지, 관리형 에이전트(Managed Agents)가 어떻게 작동하는지, 엔지니어링 시간과 비용을 얼마나 절약할 수 있는지, 그리고 언제 LangGraph, AutoGen 또는 CrewAI 대신 이를 선택해야 하는지 정확히 알게 될 것입니다.

Gemini Interactions API GA 발표: 서버 측 상태 및 백그라운드 실행을 갖춘 Gemini 모델 및 에이전트를 위한 단일 통합 엔드포인트. 출처: Google

Gemini Interactions API GA가 개발자에게 중요한 이유는 무엇인가요?

대부분의 AI 워크플로우(workflows)는 완전히 잘못된 문제를 해결하고 있습니다.

팀들은 프롬프트 엔지니어링 (prompt engineering), 모델 선택, 그리고 컨텍스트 윈도우 (context windows)에 집착합니다. 그러고는 모델과 그 외 모든 것 사이의, 화려하지 않은 영역에서 신뢰성의 거대한 부분을 잃어버립니다. 데모에서는 절대 보여주지 않는 부분들을 상상해 보세요. 새벽 2시에 도구 (tool)가 타임아웃되었을 때 실행되는 재시도 (retry), 대화를 기억하기 위해 덧붙이는 세션 스토어 (session store), 40분 동안 실행되는 연구 작업을 관리하는 작업 큐 (job queue) 같은 것들 말입니다. 그러한 배관 (plumbing) 작업 과정에서 제품은 조용히 고장 나며, 이것이 바로 이번 AI 기술 출시가 겨냥하고 있는 지점입니다.

Gemini Interactions API는 Google DeepMind가 그 간극을 직접적으로 공략하기 위해 내놓은 무기입니다. 이 API는 **2025년 12월 퍼블릭 베타 (public beta)**로 출시되었으며, 공식 발표에 따르면 "Gemini를 사용하여 애플리케이션을 구축하는 개발자들이 가장 선호하는 방식이 빠르게 되었습니다." 2026년 6월 26일의 GA (General Availability) 릴리스는 안정적인 스키마 (schema)와 더불어 개발자들이 실제로 요청했던 기능들, 즉 관리형 에이전트 (Managed Agents), 백그라운드 실행 (background execution), Gemini Omni (출시 예정), 그리고 개선된 도구 조합 기능을 추가했습니다.

이 전략적 움직임은 단순한 기능 목록 그 이상입니다. Google은 이제 자사의 모든 문서가 Interactions API를 기본값으로 사용하며, "제3자 (3P) SDK 및 라이브러리 전반에 걸쳐 이를 기본 인터페이스로 만들기 위해 생태계 파트너들과 협력하고 있다"라고 밝혔습니다. 이것은 단순한 기능 발표가 아닙니다. 플랫폼 제어를 위한 움직임입니다. 모델 호출을 상태가 없는 (stateless) 요청-응답 방식으로 보던 기존의 사고 모델은 은퇴하고, 추론 (inference)을 실행하든 자율 에이전트 (autonomous agent)를 실행하든 상태가 유지되는 (stateful) 서버 관리형 상호작용 (interaction) 방식으로 전환되고 있습니다.

이것이 바로 제가 **AI 조정 간극 (The AI Coordination Gap)**이라고 부르는 것입니다. 그리고 Gemini Interactions API는 프런티어 연구소 (frontier lab)가 프레임워크 (framework) 수준이 아닌 플랫폼 수준에서 이 간극을 메우기 위해 시도하는 가장 공격적인 노력입니다. LangGraph, AutoGen, CrewAI가 여러분의 코드 내에서 조정을 해결한다면, Google은 이를 단일 엔드포인트 (endpoint) 뒤의 서버 측으로 옮기고 있습니다.

정립된 프레임워크

AI 조정 간극 (The AI Coordination Gap)

AI 조정 간극 (The AI Coordination Gap)은 모델과 세션 메모리 (session memory), 재시도 (retries), 도구 라우팅 (tool routing), 장기 실행 (long-running execution), 멀티 에이전트 핸드오프 (multi-agent handoffs)와 같은 시스템의 나머지 부분 사이에 존재하는 신뢰성 및 엔지니어링 비용을 의미합니다. 이는 정확한 모델을 신뢰할 수 없는 제품으로 만드는 작업이며, 대부분의 AI 프로젝트가 조용히 실패하는 지점이기도 합니다.

시니어 엔지니어와 AI 리드들에게 질문은 "Gemini Interactions API가 좋은가?"가 아닙니다. "조정 (coordination) 기능을 서버 측으로 옮기는 것이 나의 빌드 대 구매 (build-vs-buy) 계산법을 바꾸는가?"입니다. 이 글을 끝낼 때쯤이면, 여러분은 방어 가능한 답변과 이를 뒷받침할 구체적인 금액 수치를 얻게 될 것입니다.

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

Gemini Interactions API란 무엇이며 정확히 무엇이 발표되었는가?

누가 (Who): Google DeepMind. Google DeepMind의 그룹 제품 매니저인 Ali Çevik과 Google DeepMind의 개발자 관계 엔지니어인 Philipp Schmid가 발표를 작성했습니다.

무엇을 (What): Gemini Interactions API가 일반 가용성 (GA, general availability) 단계에 도달했으며, 이제 Gemini 모델 및 에이전트와 상호작용하기 위한 Google의 기본 API입니다. 공식적인 한 줄 설명은 다음과 같습니다: "서버 측 상태 (server-side state), 백그라운드 실행 (background execution), 도구 조합 (tool combination) 및 멀티모달 생성 (multimodal generation) 기능을 갖춘 Gemini 모델 및 에이전트를 위한 단일 통합 엔드포인트 (unified endpoint)."

언제 (When): GA는 2026년 6월 26일에 발표되었습니다. 퍼블릭 베타는 2025년 12월에 출시되었습니다. 이는 약 6개월의 베타에서 GA로 이어지는 사이클로, 이 정도 규모의 AI 기술 플랫폼으로서는 매우 빠른 속도입니다.

어디서 (Where): Google AI Studio 내부에서 제공되며, 이제 Google의 개발자 인터페이스 전반에 걸쳐 문서화가 Interactions API를 기본값으로 설정합니다.

12월 이후 확인된 새로운 기능 (출처 기준):

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

• Background execution (백그라운드 실행) — "모든 호출에서 background=True를 설정하십시오. 서버는 상호작용을 비동기적 (asynchronously)으로 실행합니다."

• Tool improvements (도구 개선) — 내장 도구 (built-in tools)를 혼합할 수 있는 능력 (원문 텍스트가 문장 중간에서 잘려 있으며, 이후의 구체적인 도구 정보는 아직 확인되지 않은 것으로 간주합니다).

• Gemini Omni — "곧(soon)" 출시될 예정이라고 발표되었으며, 즉 아직 일반적으로 사용 가능(generally available)한 상태는 아닙니다.

• Stable schema (안정적인 스키마) — GA (General Availability) 마일스톤은 이제 요청/응답 계약 (request/response contract)이 프로덕션 환경에서 신뢰할 수 있도록 고정되었음을 의미합니다.

이번 발표에서 가장 중대한 단 한 줄은 기능이 아니라 바로 이것입니다: Google은 "제3자 (3P) SDK 및 라이브러리 전반에 걸쳐 이를 기본 인터페이스로 만들기 위해 생태계 파트너들과 협력하고 있다"는 점입니다. 이는 현재 LangChain 등이 점유하고 있는 오케스트레이션 계층 (orchestration layer)을 정조준한 플랫폼 제어 전략이며, 프레임워크 생태계가 이번 AI 기술 변화에서 가장 주의 깊게 읽어야 할 부분입니다.

기존의 사고 모델 — 모델 호출을 상태가 없는 (stateless) 요청-응답으로 보는 모델 — 은 퇴출되고 있습니다. 조정 계층 (coordination layer)을 소유하는 자가 개발자를 소유하게 되며, Google은 방금 단일 기본 엔드포인트(endpoint) 뒤로 그 조정 기능을 옮겼습니다.

Gemini Interactions API는 쉬운 언어로 어떻게 작동하나요?

AI 모델을 호출해 본 적이 있다면 전형적인 패턴을 알고 있을 것입니다: 프롬프트를 보내고, 텍스트를 돌려받고, 서버는 모든 것을 잊어버리며, 다음번에 대화 기록 전체를 다시 보내야 합니다. 당신은 메모리 (memory), 재시도 (retries), 도구 호출 (tool calls), 그리고 이 모든 것을 하나로 엮는 작업을 책임져야 했습니다. 그 "그 외의 모든 것"이 실제 작업이었습니다.

Gemini Interactions API는 모델 호출을 하나의 상호작용 (interaction) — 즉, 서버가 사용자를 대신해 관리하는 상태 유지 단위 (stateful unit) — 로 재정의합니다. 공식 소스에 따르면, 사용자는 "추론을 위한 모델 ID (model ID), 자율 작업을 위한 에이전트 ID (agent ID)를 전달하고, 오래 걸리는 모든 작업에 대해 background=True를 설정"하면 됩니다. 세 가지 조절 장치(knobs)만 있으면 됩니다. 상태 관리는 서버가 처리합니다.

이 방식이 일반적인 모델 엔드포인트 (model endpoint)와 다른 점은 두 가지입니다:

• 서버 측 상태 (Server-side state). Google이 상호작용을 기억하므로, 기본적인 흐름을 위해 컨텍스트를 다시 재생하거나 자체적인 세션 저장소 (session store)를 구축할 필요가 없습니다.

• 모델과 에이전트를 위한 단일 엔드포인트. 모델 호출과 자율 에이전트 실행이 동일한 경로를 통과합니다. "단순히 Gemini에게 질문하기"에서 "에이전트에게 목표와 Linux 샌드박스 (sandbox)를 부여하기"로 전환하는 것은 아키텍처의 재설계가 아닌 파라미터 (parameter) 변경일 뿐입니다.

소상공인의 관점에서 설명하자면: 기존 API는 완전한 단기 기억상실증에 걸린 유능한 컨설턴트를 고용하는 것과 같습니다. 이메일을 보낼 때마다 매번 다시 브리핑해야 하죠. 반면 Interactions API는 책상과 서류 보관함이 있고, 당신이 자는 동안 몇 시간 동안 연구를 수행할 수 있는 능력까지 갖춘 컨설턴트를 고용하는 것과 같습니다. 이것이 실질적인 도약이며, 당신이 직접 API 호출 코드를 작성하지 않더라도 이 AI 기술의 변화가 중요한 이유입니다.

상태가 없는 (stateless) 요청-응답 방식에서 상태가 유지되는 (stateful) 서버 관리형 상호작용으로의 전환은 Gemini Interactions API가 'AI 조정 격차 (The AI Coordination Gap)'를 해소하는 핵심 방식입니다.

Gemini API는 호출부터 결과까지 요청을 어떻게 라우팅(route)할까?

내부적으로 Gemini Interactions API는 모든 요청을 통합된 제어 평면 (control plane)을 통해 라우팅합니다. 핵심적인 아키텍처 결정 사항은 _조정(coordination)이 어디에서 일어나는가_이며, Google은 이를 자사 서버로 옮겼습니다.

Gemini Interactions API: 요청에서 결과까지의 흐름 (Request-to-Result Flow)

  1

    **클라이언트 호출 (모델 ID 또는 에이전트 ID)**

추론을 위한 Gemini 모델 ID 또는 자율 작업을 위한 에이전트 ID 중 하나를 지정하여 하나의 요청을 보냅니다. 선택적으로 background=True를 설정할 수 있습니다. 이것이 클라이언트 측의 전체 인터페이스(surface)입니다.

↓

  2
...

Google은 상호작용 상태(interaction state)를 유지합니다. 표준 흐름(standard flows)의 경우 클라이언트 측의 세션 재생(session replay)이 필요하지 않습니다. 조정 메모리(coordination memory)가 서버 측에 존재하기 때문입니다.

↓

  3
...

모델 ID는 직접 추론(inference)에 도달합니다. 에이전트 ID는 에이전트가 추론(reasoning)하고, 코드를 실행하며, 웹을 탐색하고, 파일을 관리할 수 있는 원격 Linux 샌드박스(sandbox)를 프로비저닝(provision)합니다.

↓

  4
...

플래그가 없으면 응답을 기다려야 합니다. background=True를 사용하면 서버가 상호작용을 비동기(asynchronously)로 실행하며, 나중에 폴링(poll)하거나 알림을 받게 됩니다. 이것이 실행 시간이 긴 에이전트 작업이 HTTP 타임아웃(timeout)을 견뎌내는 방식입니다.

↓

  5
...

내장 도구(및 커스텀 에이전트를 위한 커스텀 기술/데이터 소스)가 실행 중에 혼합됩니다. 출력은 텍스트뿐만 아니라 멀티모달(multimodal)일 수 있습니다.

↓

  6
...

출력을 받게 되며, 상호작용 상태가 계속 유지되므로 수동으로 컨텍스트를 재구성(context reconstruction)할 필요가 없습니다.

이 시퀀스가 중요한 이유는 2~4단계가 평소 여러분의 오케스트레이션(orchestration) 코드에 존재하던 작업과 정확히 일치하기 때문입니다. Google은 이 작업을 서버 측으로 옮겼습니다.

Antigravity 에이전트가 _기본값(default)_이라는 점은 대부분의 사람들이 대충 훑어보고 지나치겠지만, 결코 놓쳐서는 안 될 부분입니다. 에이전트 ID를 전달하는 순간, 여러분은 단 하나의 컨테이너도 직접 구축할 필요 없이 코드를 실행하고, 웹 브라우징을 하며, 파일을 관리하는 기능이 갖춰진 에이전트를 즉시 얻게 됩니다. 샌드박스(sandbox) 보안과 격리(isolation) 문제로 씨름해 온 팀들 — 저 또한 두 명의 팀원이 기능 하나 출시하지 못한 채 컨테이너 탈출(container escape) 방어 강화 작업에 한 스프린트 전체를 허비하는 것을 지켜본 경험이 있습니다 — 그런 팀들에게는 빌드 과정의 상당 부분이 단순히 사라진 것과 다름없습니다. 저희의 자체 베타 테스트 결과에 따르면, 과거에는 전담 인프라 엔지니어가 필요했던 부분이 단 한 번의 호출에 포함된 파라미터(parameter)로 변했습니다. 이것이 바로 첫 기획 회의에서 프로젝트의 범위(scope)를 정하는 방식을 바꾸는 AI 기술적 디테일입니다. 장벽은 "안전한 샌드박스를 구축할 수 있는가"에서 "API 호출 한 번을 작성할 수 있는가"로 이동하며, 이는 에이전트 작업이 승인될 때 회의실에 누가 들어올 수 있는지에 대한 프레임을 재구성합니다.

이러한 장벽의 변화가 바로 이 이야기의 핵심입니다.