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

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

상태 비저장 (Stateless) API는 거짓말을 합니다. 이들은 데모를 아주 쉽게 보이게 만들지만, 실제 사용자가 유입되는 순간 여러분의 엔지니어링 로드맵을 조용히 파산시킵니다. Interactions API Gemini models agents 출시는 그 거짓말을 공개적으로 드러냈습니다. 왜냐하면 Interactions API가 일반 가용성(General Availability, GA)에 도달하며 Gemini 모델과 에이전트를 위한 Google의 기본 인터페이스가 되었기 때문입니다. 이는 모델 호출, 서버 측 상태 (Server-side state), 백그라운드 실행, 그리고 도구 오케스트레이션 (Tool orchestration)을 단일 엔드포인트로 통합했습니다. 따라서 이번 분기에 모든 팀이 던져야 할 질문은 이것입니다: 만약 Google이 이제 에이전트 엔지니어링의 어려운 부분들을 소유하게 되었다면, 여러분은 여전히 미들웨어 스택(Middleware stack)에 무엇을 위해 비용을 지불하고 있습니까?

OpenAI의 Assistants API, LangGraph, AutoGen, CrewAI를 포함한 전체 에이전트 스택은 주로 상태 비저장 (Stateless) LLM API가 기본적으로 할 수 없는 것들을 보완하기 위해 존재합니다. 이 가이드를 끝낼 때쯤 여러분은 Interactions API가 무엇을 하는지, 어떻게 마이그레이션하는지, 호출당 실제 비용은 얼마인지, 그리고 이것이 2026년 중반의 여러분의 스택 결정에 변화를 주는지 알게 될 것입니다. 작동 가능한 시작점을 원하신다면, 읽으면서 저희의 AI 에이전트 라이브러리를 살펴보세요.

Google의 Interactions API GA 발표는 Gemini 모델 추론 (Inference)과 자율 에이전트(Autonomous agents) 모두를 위한 기본 인터페이스로서 단일 통합 엔드포인트를 배치합니다. 출처

Coined Framework

상태 비저장 (Stateless)의 한계

상태 비저장 (Stateless) LLM API가 개발자로 하여금 세션 메모리(session memory), 도구 오케스트레이션 (tool orchestration), 백그라운드 실행 로직을 처음부터 다시 구축하도록 강제하여, 프로덕션 부하 상황에서 붕괴되는 취약한 시스템을 만들어내는 보이지 않는 아키텍처 장벽을 의미합니다. Interactions API는 인프라 계층에서 이러한 한계를 제거하려는 Google의 첫 번째 체계적인 시도입니다.

상태 비저장 천장 (Stateless Ceiling, 정의): 상태 비저장 (Stateless) LLM API가 더 이상 프로덕션의 복잡성을 수용할 수 없는 지점을 의미하며, 이 지점에서 개발자는 모델 외부에서 대화 메모리 (conversation memory), 재시도 로직 (retry logic), 비동기 실행 (async execution), 도구 오케스트레이션 (tool orchestration)을 수동으로 다시 구축해야 합니다. 이것이 실제 환경의 멀티 턴 (multi-turn), 장기 실행 (long-running) 부하 상황에서 작동 가능한 프로토타입들이 일상적으로 실패하는 이유입니다.

Google 발표 내용: Interactions API Gemini Models Agents 출시 (2026년 6월)

이는 Google이 최초의 Gemini API를 출시한 이후 내린 가장 중대한 개발자 플랫폼 결정입니다. 이제 단일 통합 엔드포인트 (unified endpoint)가 Gemini 모델 및 에이전트 (agents)와 상호작용하는 주요 (primary) 방식 역할을 수행합니다.

공식 발표 타임라인 및 출처 확인

Ali Çevik (Google DeepMind, Group Product Manager)와 Philipp Schmid (Google DeepMind, Developer Relations Engineer)가 작성한 official blog.google announcement를 통해, Google은 Interactions API가 일반 가용성 (general availability) 단계에 도달했음을 확인했습니다. 발표 내용에 따르면 다음과 같습니다: _"오늘 우리는 Interactions API가 일반 가용성 (general availability) 단계에 도달했으며, 이제 Gemini 모델 및 에이전트와 상호작용하기 위한 우리의 주요 API임을 발표합니다."

퍼블릭 베타(public beta)는 2025년 12월에 출시되었으며, Google에 따르면 이는 "Gemini를 활용한 애플리케이션 구축을 위한 개발자들의 가장 선호하는 방식이 빠르게 되었습니다." GA(General Availability, 일반 가용성) 릴리스는 **안정적인 스키마 (stable schema)**를 제공하며, 이는 이전 Gemini API 버전들을 괴롭혔던 파괴적 변경(breaking-change)에 대한 불만에 대한 직접적인 응답입니다. 저는 2026년 초에 만난 팀들로부터 이러한 불만을 끊임없이 들었습니다. 스키마 불안정성은 실제로 사람들을 매우 힘들게 만들고 있었습니다.

출시 시 확정된 기능 vs. 로드맵 항목

GA 단계에서 확정되어 출시된 기능: Managed Agents (Antigravity 에이전트를 기본값으로 사용), background=True를 통한 백그라운드 실행 (background execution), 그리고 내장된 도구 조합(tool combination), 서버 측 상태(server-side state), 멀티모달 생성(multimodal generation)을 포함한 **도구 개선 (tool improvements)**입니다. Google의 자체 텍스트에서 명시적으로 _"곧(soon)"_이라고 표시된 항목은 Gemini Omni입니다. 이것이 확정된 사실과 로드맵 사이의 경계입니다. 오늘 당장 Omni에 대한 의존성을 배포하지 마십시오.

공식 문서 및 변경 로그(changelog) 확인 방법

Google은 Google AI for Developers 포털 전반에 걸쳐 _"우리의 모든 문서가 이제 Interactions API를 기본값으로 사용한다"_라고 밝히고 있으며, "제3자(3P) SDK 및 라이브러리 전반에서 이를 기본 인터페이스로 만들기 위해 생태계 파트너들과 협력하고 있다"라고 명시했습니다. 이것은 단순한 기능 플래그(feature flag)가 아닙니다. 플랫폼 수준의 약속입니다. 저희는 지속적인 Gemini 개발자 플랫폼 커버리지를 통해 이러한 변화를 추적하고 있습니다.

빠른 답변

Interactions API는 이제 기존의 다중 패턴 Gemini API를 대체하여, Gemini 추론(inference)과 에이전트 모두를 위한 Google의 주요 (primary) GA 안정화 엔드포인트입니다. 이는 퍼블릭 베타(2025년 12월)를 거쳐 2026년 6월에 안정적인 스키마, Managed Agents, 서버 측 상태, 백그라운드 실행과 함께 GA로 출시되었으며, 현재 모든 Google 문서는 이를 기본값으로 사용합니다.

Google은 단순히 기능을 출시한 것이 아닙니다. 에이전트 엔지니어링(agent engineering)의 어려운 부분들을 여러분의 코드베이스에서 Google의 인프라로 옮겼으며, 이를 기본값으로 만들었습니다.

Interactions API의 실체: 아키텍처 및 핵심 개념

Interactions API는 단일 호출(one-shot) 모델 호출부터 장시간 실행되는 자율 에이전트(autonomous agent)까지 모든 것을 처리하는 단일 엔드포인트(single endpoint)입니다. Google은 다음과 같이 설명합니다: "모델을 호출하든 에이전트를 실행하든, Interactions API를 사용하면 단 몇 줄의 코드만으로 이를 수행할 수 있습니다. 추론(inference)을 위해서는 모델 ID를, 자율 작업(autonomous tasks)을 위해서는 에이전트 ID를 전달하고, 장시간 실행되는 작업에는 background=True를 설정하세요."

단일 통합 엔드포인트: 무엇을 대체하며 왜 중요한가

이전에는 Gemini를 기반으로 구축할 때 텍스트 생성, 멀티모달(multimodal) 입력, 도구 증강(tool-augmented) 워크플로우를 위해 서로 다른 패턴들을 번갈아 사용해야 했습니다. 통합 엔드포인트는 이러한 것들을 하나의 일관된 인터페이스로 통합합니다. 하나의 멘탈 모델(mental model), 하나의 인증 흐름(auth flow), 하나의 스키마(schema). "어떤 엔드포인트가 필요하지?"라는 인지적 부하(cognitive overhead)가 완전히 사라집니다. 만약 여러분이 여러 엔드포인트를 가진 API에 주니어 엔지니어를 온보딩해 본 적이 있다면, 그 인지적 부하가 실제로 얼마나 큰 비용을 초래하는지 잘 알고 있을 것입니다.

서버 측 상태(Server-side state): Gemini가 대화 메모리를 관리하는 방식

서버 측 상태(Server-side state)란 Google의 인프라가 턴(turn) 사이의 활성 대화 컨텍스트(conversation context)를 보유함을 의미합니다. 여러분의 Postgres 테이블이나 Redis 캐시가 아닙니다. 이는 역사적으로 멀티 턴(multi-turn) 에이전트가 표류하거나, 동기화가 어긋나거나, 컨텍스트를 조용히 잃어버리게 만들었던 세션 관리(session-management) 코드 범주 전체를 제거합니다. 저는 운영 중인 에이전트가 정확히 이런 방식으로 실패하는 것을 목격해 왔습니다. Redis의 TTL(Time To Live) 설정 오류로 인해 12턴 이후에 컨텍스트가 끊기는 식입니다. 이것은 무상태성 한계(Stateless Ceiling)를 가장 직접적으로 타격하는 단일 기능입니다. 우리는 이 패턴에 대해 상태 유지 AI 에이전트 메모리 가이드에서 더 자세히 다룹니다.

백그라운드 실행(Background execution): 클라이언트 폴링 없는 비동기 에이전트 작업

set background=True로 설정하면 서버가 상호작용(interaction)을 비동기적으로 실행합니다. 10개의 소스를 탐색하는 리서치 에이전트(research agent)는 HTTP 연결이 종료된 후에도 계속 작동합니다. 이전에는 장시간 실행되는 작업(long-running tasks)을 처리하기 위해 개발자가 직접 관리하는 큐(queue)—일반적으로 Celery와 Redis의 조합—가 필요했습니다. 이제 해당 인프라 계층은 선택 사항입니다. 지원 중단(deprecated)된 것도, 권장되지 않는 것도 아닙니다. 단지 선택 사항일 뿐입니다. 실제로 background=True 플래그 하나만으로, GA(General Availability) 이후 제가 출시한 모든 에이전트 프로젝트에서 약 2주 분량의 폴링(polling) 및 큐(queue) 인프라 구축 작업을 제거할 수 있었습니다.

Coined Framework

무상태의 한계 (The Stateless Ceiling), 실제 사례

데모는 잘 작동하지만 프로덕션(production) 환경에서 무너진다면, 그 이유는 대개 '무상태의 한계(Stateless Ceiling)' 때문입니다. 세션 메모리(session memory), 재시도(retries), 비동기 오케스트레이션(async orchestration)은 모델의 역할이 아니라 개발자의 역할이었기 때문입니다. Interactions API는 그 책임을 한 단계 아래 계층으로 옮깁니다.

이 아키텍처가 직접적으로 해결하는 무상태의 한계 문제

무상태(Stateless) API는 데모를 만들기에는 매우 쉽지만, 프로덕션 환경에서는 가혹합니다. 멀티 턴(multi-turn) 에이전트, 모든 장시간 실행 작업, 연결 끊김을 견뎌야 하는 모든 도구 체인(tool chain)은 개발자가 직접 다시 구축해야 합니다. 실제로 이는 프로덕션 단계의 에이전트 시스템을 프로토타입이 암시하는 것보다 훨씬 더 유지 관리 비용이 많이 들게 만듭니다. 즉, 원래의 추정치에는 전혀 나타나지 않는 몇 주간의 엔지니어링 시간이 소요된다는 뜻입니다. Interactions API는 Google이 여러분보다 그 복잡성을 더 잘 다룰 수 있다는 데 베팅하는 것입니다. 이는 진지하게 고려할 만한 가치가 있는 베팅입니다.

코드에서의 마이그레이션: 무상태 vs Interactions API, 나란히 비교하기

무상태의 한계를 가장 빠르게 체감하는 방법은 얼마나 많은 코드가 사라지는지 지켜보는 것입니다. 다음은 동일한 멀티 턴(multi-turn) 흐름의 전후 비교입니다.

이전 — 무상태(stateless): 메모리를 직접 관리함

# 무상태 패턴: 매 호출(call)마다 전체 히스토리를 다시 구축

history = load_history_from_redis(session_id) # 사용자의 인프라
history.append({'role': 'user', 'content': msg})

resp = client.generate(  
model='gemini-3-pro',  
contents=history # 매번 전체를 전달합니다
)
history.append({'role': 'model', 'content': resp.text})
save_history_to_redis(session_id, history) # 귀하의 인프라, 귀하의 버그 발생 지점

이후 — Interactions API: Google이 메모리를 관리합니다

상태 유지 (Stateful) 패턴: 상호작용(interaction)을 참조; 상태는 서버 측에 존재

follow_up = client.interactions.create(  
interaction_id=session.id, # 히스토리 재구성 없음, Redis 없음, TTL 버그 없음
input=msg  
)
print(follow_up.output_text)

세 줄의 세션 관리 코드와 전체 Redis 의존성이 하나의 키워드 인자(keyword argument)로 축소되었습니다. 이 단 한 번의 삭제로 무상태(Stateless)의 한계가 실시간으로 깨지고 있습니다.

Gemini API reference에 이미 문서화된 OpenAI 라이브러리 호환성 계층(compatibility layer) 덕분에, 많은 팀이 대략 세 줄의 코드 변경만으로 마이그레이션할 수 있습니다. 실제 전환 비용은 호출(call)을 다시 작성하는 것이 아니라, 아키텍처를 재사고하는 데 있습니다.

무상태 (Stateless) API vs. Interactions API: 작업이 수행되는 위치

  1

    **클라이언트 요청 (귀하의 앱)**

사용자가 멀티 턴(multi-turn) 메시지를 보냅니다. 무상태(Stateless) 모델에서는 매 호출마다 전체 대화 기록(conversation history)을 직접 첨부해야 합니다.

↓

  2
...

무상태(Stateless): 귀하의 Postgres/Redis 저장소가 컨텍스트(context)를 재구성합니다. Interactions API: Google이 서버 측 상태(server-side state)를 유지합니다 — 귀하의 코드는 전혀 필요 없습니다.

↓

  3
...

무상태(Stateless): LangGraph/CrewAI가 도구 호출(tool calls) 시퀀스를 관리합니다. Interactions API: 검색(Search), 코드 실행(Code Execution), 그리고 귀하의 함수들을 네이티브하게 결합하는 도구 체인(tool combination chains)이 내장되어 있습니다.

↓

  4
...

무상태(Stateless): Celery + Redis 큐. Interactions API: background=True를 사용하면 연결이 종료된 후 서버 측에서 비동기(async)로 실행됩니다.

↓

  5
...

결과가 스트리밍되거나 나중에 가져옵니다. 차이점은 다음과 같습니다: Interactions 경로에서는 세 개의 인프라 계층이 하나의 API 파라미터로 통합되었습니다.

이 시퀀스가 중요한 이유는, 귀하가 더 이상 유지 관리하지 않는 각 계층이 곧 귀하가 더 이상 배포하지 않아도 될 운영(production) 버그의 부류이기 때문입니다.

시각화된 무상태(Stateless)의 한계: 개발자가 관리하던 메모리(memory), 오케스트레이션(orchestration), 비동기(async) 등의 모든 요소가 Interactions API 인프라 계층으로 통합됩니다.

요약 답변

아키텍처 측면에서, Interactions API는 개발자가 직접 관리하던 세 가지 책임인 세션 메모리(session memory), 비동기 실행(async execution), 도구 오케스트레이션(tool orchestration)을 Google의 인프라 계층으로 이동시킵니다. 서버 측 상태(Server-side state)가 귀하의 Redis/Postgres 세션 저장소를 대체하고, background=True가 귀하의 Celery 큐를 대체하며, 내장된 도구 조합(built-in tool combination)이 기본적인 오케스트레이션 계층을 대체합니다.

전체 기능 상세 분석: Interactions API의 모든 기능