Google DeepMind가 agent 시대에 맞춰 Gemini API의 바탕을 다시 짰습니다. 새 Interactions API는 일반 모델 호출과 오래 도는 agent 작업을 하나의 창구로 받고, 대화와 추론 상태를 서버가 대신 기억합니다. 여기에 Linux sandbox(격리된 실행 환경)까지 API 호출 한 번으로 빌려 쓰는 Managed Agent가 더해졌습니다. agent를 직접 만들던 개발자라면 상태 관리, 실행 환경, 비밀값 보호를 어디까지 맡길 수 있는지 다시 따져 볼 시점으로 보입니다.

응답 한 번에서 agent로, API가 뒤처진 이유

언어 모델을 쓰는 방식은 세 단계를 거쳐 왔습니다. 처음에는 ‘농담 하나 해 줘’ 같은 prompt(모델에 주는 지시문)에 글 한 덩어리로 답하는 완성형 호출이었습니다. 이어 앱이 모델 출력을 안정적으로 받아 써야 하자 function calling(모델이 정해진 형식의 함수 호출을 JSON으로 내놓는 방식)이 나왔습니다. ’뉴욕 날씨를 알려 줘’라는 요청에 모델이 날씨 함수를 부르는 구조화된 값을 돌려주면, 서버는 회원 가입 양식의 아이디와 비밀번호를 받듯 그 값으로 정해진 동작을 합니다.

지금의 모델은 한발 더 나아가 목표를 받고 스스로 추론하며 여러 도구를 오래 다룬 뒤 결과를 냅니다. Google DeepMind는 agent를 다음 네 요소의 합으로 정리합니다.

요소 하는 일
모델의 추론 사용자의 의도를 해석하고 다음 행동을 정함
도구 검색, 코드 실행, 사용자 정의 함수 호출
맥락·메모리 짧은 기억과 긴 기억을 불러옴
실행 환경 코드와 함수를 돌리는 sandbox

Google DeepMind의 한 개발자 경험 담당 엔지니어는 최근 모델일수록 복잡한 보조 구조가 덜 필요하다고 봅니다. 파일 읽기와 편집 도구를 따로 두지 않아도 Claude Opus나 Claude Haiku 같은 최근 모델은 bash 도구 하나로 일을 처리하는 경우가 많다는 것입니다. 문제는 작업이 길어졌다는 점입니다. 한 번에 끝나던 호출이 3분 넘게 자료를 찾아 보고서를 쓰는 deep research agent 같은 배경 작업으로 바뀌었는데, 기존 API는 깊게 중첩된 JSON을 뒤져 결과를 꺼내고 대화 기록을 개발자가 직접 관리하게 했습니다.

interaction ID 하나로 이어 가는 대화와 추론

Interactions API의 중심은 선택형 서버 측 상태 관리입니다. 첫 호출의 응답에 담긴 interaction ID를 다음 호출의 previous_interaction_id로 넘기면, 서버가 이전 대화 기록과 모델의 내부 추론 상태를 그대로 복원합니다.

이것이 중요한 까닭은 thought signature 때문입니다. 최근 Gemini 모델은 추론 과정을 사람이 읽을 수 없는 서명값으로 남기고, 이 값을 다음 차례에 돌려줘야 성능을 온전히 냅니다. 서명을 빠뜨리면 추론 품질이 눈에 띄게 떨어진다는 것이 Google DeepMind의 설명입니다. 대화 기록을 손으로 이어 붙이면 공백 하나만 달라져도 서버 캐시가 무효가 되는 등 오류가 생기기 쉬웠는데, ID 하나를 넘기는 방식은 이런 오류를 막아 줍니다.

ID 하나로 이전 대화와 추론 상태를 다시 불러오는 구조

▲ interaction ID로 잇는 상태

출력도 정리됐습니다. 텍스트, 음성, 이미지 응답이 같은 형태의 타입 지정 객체로 나오므로 output.type 값만 보고 처리하면 됩니다. 출력 형식을 바꿀 때도 generation_config와 response_modalities 같은 설정만 고칩니다. Google DeepMind 팀의 한 개발자가 만든 여행 시뮬레이터는 사진 한 장을 올리면 베네치아 운하, 노이슈반슈타인 성 같은 여러 장소의 이미지를 동시에 만들고, interaction ID를 이어 받아 첫 장면에서 움직이는 영상까지 만들어 냅니다.

도구 호출과 Steps Data Model

Gemini는 한 번의 API 호출 안에서 무엇을 더 알아야 하는지 스스로 판단해 도구를 부르고 답을 냅니다. Google Search와 URL 맥락 도구로 학습 시점 이후의 웹 정보를 가져오고, 같은 요청에 보안 사고를 사내 티켓 시스템에 등록하는 file_incident 같은 사용자 정의 함수를 함께 넣을 수 있습니다. 찾아보는 일과 실제 조치를 한 요청에서 처리하는 셈입니다.

이렇게 여러 단계가 오가는 작업을 담으려고 Google은 기존 outputs 배열을 Steps Data Model로 바꿨습니다. 모델이 한 상호작용 동안 한 일을 타입이 정해진 시간순 목록으로 남기는 구조입니다.

구성 내용
단계 종류 모델 출력, 생각, 함수 호출, Google Search 호출 등
상태 완료, 대기, 진행 중
구조화 필드 도구 이름, 인자, thought signature
콘텐츠 영역 텍스트, 이미지, 음성, 영상 원본

Managed Agent, sandbox까지 API로 빌리기

Antigravity를 원격 agent로 쓰는 Managed Agent는 Google이 관리하는 보안 Linux sandbox 안에서 Gemini가 스스로 일하게 합니다. bash 코드 실행, 파일 시스템, 웹 검색, URL 맥락 확인, agent skill이 기본 도구로 들어 있습니다. 예전에는 coding agent(코드를 작성하고 실행하는 agent)를 만들려면 실행 틀을 직접 다듬고, 외부 sandbox 서비스를 찾아 설정하고, 맥락 유지 방법까지 혼자 풀어야 했습니다. 이제는 API 호출 하나로 유지되는 sandbox를 받습니다.

Google이 보여 준 사례에서 agent는 GitHub 저장소를 받아 복제하고 폴더 구조를 훑은 뒤 소스 파일을 하나씩 읽어 프로젝트 개요를 정리했습니다. 직접 만든 프로그래밍 언어와 강화학습 루프를 담은 해커톤 제출작을 여러 차례에 걸쳐 평가할 때는 200만 token(모델이 처리하는 글의 단위) 넘게 쓰면서도 sandbox 상태를 잃지 않았습니다.

여러 차례 이어지는 작업에서는 두 값을 함께 보관하는 것이 핵심입니다.

값 이어 주는 것
interaction ID 대화와 추론 맥락
environment_id 기존 sandbox의 파일과 실행 상태

sandbox에는 Google Cloud Storage 버킷, GitHub 저장소, 설정 파일이나 설치 스크립트 같은 인라인 파일을 미리 실어 둘 수 있습니다.

격리된 sandbox 밖의 proxy가 요청에 인증 정보를 붙이는 모습

▲ sandbox와 network proxy

비밀값을 모델에 보여 주지 않는 network proxy

agent를 쓰는 개발자가 자주 묻는 것은 인증 정보 유출과 prompt injection(외부 콘텐츠에 숨긴 지시로 모델을 속이는 공격)입니다. Google은 관리형 중간자 network proxy로 이 문제를 다룹니다. sandbox 안의 코드가 GitHub API 같은 외부 주소로 요청을 보내면 proxy가 그 요청을 가로채 인증 헤더에 인증 정보를 넣어 보냅니다.

모델은 원래의 비밀값을 보지도, 기억하지도 않습니다. 누군가 prompt injection으로 모델이 메모리나 환경 정보를 출력하게 만들더라도 API 키는 처음부터 모델 쪽에 없으니 새어 나갈 수 없다는 구조입니다. 비밀값을 지시문이나 모델이 읽을 수 있는 환경 변수에 넣던 방식과 비교하면 방어 지점이 모델 밖으로 옮겨 갔다고 볼 수 있습니다.

이름 붙인 agent, CLI, skill 저장소

잘 다듬은 지시문, 파일, 의존성은 이름 붙인 Managed Agent로 고정해 다시 쓸 수 있습니다. 방법은 두 가지입니다.

  • 소스 정의: 기본 agent 명세에 쓸 skill과 설정 파일을 적어 만듭니다.
  • 스냅숏: sandbox 안에서 agent와 대화하며 Library를 설치한 뒤 그 환경을 그대로 저장하고 이름을 붙입니다.

프로젝트마다 이름 붙인 agent를 1,000개까지 둘 수 있고, 환경 저장이나 쉬는 sandbox에는 요금을 받지 않습니다. 요금은 모델 token 사용량에만 붙습니다.

터미널에서는 오픈소스로 공개된 Gemini API CLI로 여러 모델에 prompt를 보내 보고, agent를 만들고 배포할 수 있습니다. 기존 coding agent를 새 API로 옮기는 일은 GitHub의 gemini-skills 저장소가 돕습니다. 모델은 학습 데이터에 많이 나온 Gemini 2.0이나 Gemini 2.5 Flash 시절의 코드를 쓰려는 경향이 있어, 새 API 사용법을 담은 skill을 넣어 줘야 최신 방식대로 코드를 짠다는 설명입니다. Google은 이 skill이 최신 권장 방식대로 코드를 만드는지 계속 평가하고 있다고 밝혔습니다.

정리: Gemini로 agent를 만드는 개발자가 바꿀 것

Interactions API와 Managed Agent는 agent 개발에서 개발자가 떠안던 상태 관리, 실행 환경, 비밀값 보호를 플랫폼 쪽으로 옮기려는 시도로 보입니다. Gemini로 agent를 만들고 있다면 다음 순서로 점검해 볼 만합니다.

  1. 여러 차례 대화를 손으로 이어 붙이고 있다면 응답의 interaction ID를 previous_interaction_id로 넘기는 방식으로 바꿉니다. thought signature를 잃지 않는 가장 간단한 방법입니다.
  2. multimodal 응답은 중첩 경로를 하드코딩하지 말고 output.type으로 나눠 처리합니다.
  3. Managed Agent를 쓸 때는 interaction ID와 environment_id를 함께 저장해 맥락과 sandbox를 모두 이어 갑니다.
  4. API 키는 지시문이나 환경 변수 대신 network proxy로 주입합니다.
  5. 기존 coding agent에는 gemini-skills 저장소의 Interactions API skill을 넣고, 이름 붙인 agent로 굳히기 전에 Gemini API CLI로 터미널에서 먼저 시험합니다.

빠르게 시험해 보려면 별도 설정 없이 무료 사용량을 주는 Google AI Studio에서 시작하는 것이 가장 가까운 길입니다.