Agent Runtime(에이전트 런타임)

한 줄 정의

Agent Runtime은 Agent를 프로덕션에 올려 실행하는 관리형 런타임 계층이야. 일반 Runtime이 모델 파일이나 추론 엔진을 돌리는 쪽에 가깝다면, Agent Runtime은 모델 호출뿐 아니라 도구 호출, 세션, 메모리, 코드 실행, 로그, 보안 경계까지 붙은 에이전트 프로세스를 배포하고 운영하는 쪽에 가까워.

Google Cloud의 Agent Platform 문맥에서는 이 기능이 scale 묶음에 들어가. Google Cloud 문서는 Agent Runtime을 프로덕션 AI 에이전트를 배포, 관리, 스케일하게 해 주는 서비스 묶음으로 설명하고, 관리형 런타임과 세션, Memory Bank, Code Execution, Observability, Agent Identity, Agent Gateway를 같은 운영 표면 안에 둔다.

실제로 무엇을 하나

가장 먼저 하는 일은 배포야. 개발자는 ADK, LangChain, LangGraph, AG2, LlamaIndex, 커스텀 Python 프레임워크로 만든 agent를 Agent Runtime에 올리고, API 요청으로 호출해. 문서의 기본 흐름도 환경 설정, agent 개발, 관리형 런타임 배포, API 요청, 배포된 agent 관리 순서로 잡혀 있어.

두 번째는 실행 상태를 유지하는 일이야. 단일 프롬프트 응답은 모델 API만으로도 충분할 수 있지만, 고객지원이나 영업 자동화처럼 여러 단계가 이어지는 agent는 세션과 메모리가 필요해. Agent Platform Sessions는 사용자와 agent 사이의 개별 상호작용을 저장하고, Memory Bank는 세션에서 나온 정보를 다시 꺼내 개인화에 쓰는 쪽이야. 그래서 큰 context window만으로 해결할 수 없는 장기 상태 문제를 따로 다루게 돼.

세 번째는 도구와 코드 실행이야. Agent Runtime은 function calling 같은 모델 도구 호출을 쓸 수 있게 하고, Code Execution으로 모델이 만든 코드를 격리된 관리형 샌드박스에서 실행하게 해. 예를 들어 데이터 분석 agent가 SQL을 만들고, 파일을 정리하고, 내부 API를 호출해야 한다면 런타임은 이 작업들이 어디서 어떤 권한으로 도는지 정하는 자리가 돼.

네 번째는 관측과 거버넌스야. Google 문서는 Cloud Trace, Cloud Monitoring, Cloud Logging, OpenTelemetry를 통한 Agent Observability를 런타임 범위에 넣고, Security Command Center 기반 Agent Runtime Threat Detection, Agent Identity, Agent Gateway도 함께 제시해. 운영자는 여기서 어느 agent가 어떤 도구를 호출했는지, 어디서 느려졌는지, 어떤 권한으로 실행됐는지 확인해야 해.

왜 중요한가

Agent Runtime이 중요한 이유는 agent 도입이 모델 호출 한 번에서 끝나지 않기 때문이야. AI Studio 같은 실험 화면에서는 프롬프트와 도구 설정을 빠르게 바꿔 볼 수 있어. 그런데 실제 업무에 넣는 순간에는 배포, 인증, IAM, 네트워크, 로그, 비용 라벨, 세션 저장, 실패 재현이 따라온다. 이 차이를 놓치면 프로토타입은 잘 되는데 운영에서는 어디서 깨졌는지 모르는 상태가 돼.

Google Cloud Blog는 2026년 4월 23일 발표에서 Agent Runtime을 production으로 가는 길이라고 잡고, sub-second cold start, seconds 단위 새 agent 프로비저닝, 며칠 동안 자율 실행되는 장기 워크플로를 예로 들었어. 이 숫자는 Google Cloud의 제품 주장으로 봐야 하지만, 방향은 분명해. 런타임은 “답을 빨리 받는 모델”보다 “상태 있는 작업을 오래, 추적 가능하게 돌리는 환경”에 가깝다.

모델 문서와 비교하면 경계가 더 선명해져. Gemini 2.5 Flash 문서는 gemini-2.5-flash 모델 ID, 텍스트·코드·이미지·오디오·비디오 입력, 텍스트 출력, 최대 입력 1,048,576토큰, 기본 최대 출력 65,535토큰, 입력 크기 500MB를 알려 줘. 이건 어떤 모델을 고를지 보는 표야. Agent Runtime 판단은 그 모델을 쓰는 agent가 어떤 세션을 남기고, 어떤 도구를 호출하고, 어떤 로그와 권한 아래에서 실행되는지 보는 일이야.

주의해서 볼 점

첫째, Agent Runtime을 일반 모델 Runtime과 같은 말로 쓰면 범위가 흐려져. vLLM이나 ONNX Runtime 같은 말은 대체로 모델 추론 실행 계층을 떠올리게 해. Agent Runtime은 그보다 위에서 agent 배포, 상태, 도구 호출, 관측, 보안을 묶는 운영 프레임워크에 가깝다.

둘째, 장기 실행과 장기 기억을 같은 것으로 보면 안 돼. Cloud Blog는 장기 실행 agent가 days at a time으로 돌 수 있다고 말하고, 문서는 Sessions와 Memory Bank를 따로 둬. 오래 도는 것, 세션을 저장하는 것, 개인화 기억을 다시 꺼내는 것은 서로 다른 설계 항목이야. 이 셋을 한 덩어리로 보면 개인정보 보관과 삭제 정책을 놓치기 쉬워.

셋째, 보안 기능 이름만으로 충분하다고 보면 위험해. Agent Identity, Agent Gateway, Threat Detection, VPC Service Controls, Private Service Connect, CMEK가 있더라도 실제 프로젝트의 IAM, 네트워크, 로그 보관 기간, 승인 흐름이 맞아야 해. 특히 Code Execution은 격리된 관리형 샌드박스를 제공하지만, 모델이 만든 코드가 어떤 데이터와 권한을 만지는지는 별도 정책으로 막아야 한다.

넷째, 제품 이름이 바뀌는 흔적도 봐야 해. Agent Runtime 문서는 API reference 리소스 이름이 과거 호환성 때문에 ReasoningEngine으로 남아 있다고 적어. 문서, SDK, 로그, 권한 이름에서 Agent Runtime과 ReasoningEngine이 같이 보이면 같은 계층의 이름 변화로 읽어야지, 완전히 다른 제품처럼 나누면 운영 문서를 놓칠 수 있어.

마지막으로 벤더 경계가 있어. Alibaba Cloud Model Studio처럼 다른 클라우드도 모델 호출, agent app, workflow app을 콘솔 안에 묶는다. Agent Runtime은 Google Cloud의 Agent Platform, Vertex AI 전환, Cloud Trace, IAM, Security Command Center와 강하게 붙어 있어. 이미 데이터와 권한 체계가 어느 클라우드에 있는지가 모델 점수보다 더 크게 작동할 수 있어.