Google의 Managed Agents API는 인프라 문제를 해결하지만, 에이전트 프로젝트를 실제로 무너뜨리는 문제는 해결하지 못한다

Google I/O 2026은 기업용 AI 팀들이 지난 2년 동안 갈망해 온 것을 제공했습니다. 바로 에이전트를 실행하기 위해 자체적인 샌드박스 인프라(sandbox infrastructure)를 구축할 필요가 없는 관리형 런타임(managed runtime)입니다. Gemini API의 Managed Agents는 지속적인 실행 환경(Google은 이를 Antigravity harness라고 부릅니다), 서버 측 자격 증명 주입(server-side credential injection), 그리고 호출 간에 유지되는 상태(state)를 함께 제공합니다. environment_id를 전달하면, 에이전트는 파일 등을 포함하여 이전에 멈췄던 지점부터 작업을 이어갑니다.

이것은 진정한 돌파구(unlock)입니다. 하지만 제 생각에 이것은 문제의 쉬운 20%에 불과하며, 키노트 이후 제가 본 대부분의 열광적인 반응들은 바로 그 지점에서 멈춰 있습니다.

Google의 문서와 "프로덕션 준비 완료된 에이전트(production-ready agent)"가 실제로 무엇을 요구하는지에 대한 몇몇 벤더 분석을 검토한 후 내린 저의 솔직하고 편향된 견해는 다음과 같습니다: 인프라 이야기는 이제 기본적으로 해결되었습니다. 이는 향후 12개월간의 기업용 AI의 향방이 누가 가장 멋진 에이전트 데모를 보여주느냐가 아니라, 누가 거버넌스(governance)를 제대로 구현하느냐에 의해 완전히 결정될 것임을 의미합니다. 만약 여러분이 벤더를 평가하거나 이를 사내에서 구축하고 있다면, 바로 이 관점을 사용해야 합니다.

챗봇 시대가 한계에 부딪힌 이유

대부분의 기업용 AI 배포는 여전히 RAG(Retrieval-Augmented Generation) 플레이북을 따릅니다: LLM을 지식 베이스에 연결하고, 검색(retrieval) 기능을 추가하고, 이를 채팅 UI로 감싸서 내부 어시스턴트로 출시하는 방식입니다. "환불 규정이 무엇인가요?"와 같은 질문에는 훌륭합니다. 하지만 워크플로우가 무언가를 수행해야 하는 순간에는 무용지물이 됩니다.

지원 해결 워크플로우는 모델이 질문에 답했을 때 완료되는 것이 아닙니다. ServiceNow, Salesforce, 결제 API, 그리고 이메일에 걸쳐 티켓이 업데이트되고, 환불이 처리되며, 고객에게 알림이 가고, 케이스가 종료되었을 때 비로소 완료됩니다. RAG 챗봇은 세 가지 구조적인 이유로 이 중 그 어떤 것도 건드릴 수 없습니다:

상태(state) 없음: 모든 대화가 새로 시작되므로, 네 번째 단계에 도달했을 때쯤이면 첫 번째 단계에 대한 기억이 없습니다.
쓰기 권한(write access) 없음: RAG는 검색하고 요약할 뿐, 레코드를 업데이트하거나 트랜잭션 API(transactional APIs)를 호출하지 않습니다.
권한 경계(authorization boundary) 없음: 되돌릴 수 없는 동작을 승인 절차 뒤에 배치하여 제어할 수 있는 메커니즘이 없습니다.

이것이 바로 수많은 파일럿 프로젝트가 중단되는 이유입니다. 모델이 충분히 똑똑하지 않아서가 아니라, 주변 아키텍처(architecture)가 모델이 실제로 행동할 수 있도록 설계되지 않았기 때문입니다.

Managed Agents가 실제로 해결하는 것

Google에 대해 공정하게 말하자면, 이 부분은 진정으로 잘 만들어졌습니다. 이전에는 프로덕션 에이전트(production agent)를 구축하려면 상태가 없는(stateless) API 호출을 체이닝(chaining)하며 매 턴마다 컨텍스트(context)를 재구축하거나, 직접 VM, 샌드박스(sandbox), 오케스트레이션 레이어(orchestration layer)를 구축해야 했습니다. Managed Agents API는 이를 다음과 같은 요소로 대체합니다:

에이전트가 추론하고, 코드를 실행하며, 도구(tools)를 호출하고, 파일을 읽고 쓰는 원격 샌드박스(remote sandbox)
호출 간에 상태가 초기화되는 대신 유지되는 지속 가능한 환경(persistent environments)
오케스트레이션 코드 내에서가 아니라 선언적으로 에이전트의 동작을 정의하는 스킬 파일(skill files: AGENTS.md, SKILL.md)
이그레스 프록시(egress proxy)를 통한 서버 측 자격 증명 주입(server-side credential injection)으로, 샌드박스가 환경 변수(env vars)로서 자격 증명을 직접 다루지 않도록 함

마지막 포인트는 들리는 것보다 훨씬 중요합니다. 이는 단순히 규정 준수(compliance)를 위한 체크박스가 아니라, 실제 공격 표면(attack surface)을 제거합니다.

하지만 Google의 자체 문서도 책임이 어디서 끝나는지에 대해 솔직하게 밝히고 있습니다. 에이전트가 완전히 사용되는 것을 보고 싶지 않은 자격 증명을 넘겨주지 마십시오. 그리고 실제로 실행되기를 원하는 범위(scope)만 허용하십시오. 즉, 권한 모델(authorization model), 도구 범위(tool scope), 승인 게이트(approval gates)는 전적으로 해당 시스템을 구축하는 팀의 책임이라는 뜻입니다. Google은 엔진을 만들었습니다. 하지만 브레이크는 아무도 보내주지 않았습니다.

아무도 공짜로 건너뛰지 않는 7가지 계층

이 부분은 제가 생각하기에 현재 받는 것보다 훨씬 더 많은 논의가 이루어져야 할 부분이며, 저의 편향(bias)이 가장 강하게 작용하는 지점이기도 합니다. 이것을 백엔드 통합(backend integration) 문제로 취급하는 팀은 실패합니다. 이것을 시스템 거버넌스(systems governance) 문제로 취급하는 팀은 프로덕션 환경과 맞닥뜨려도 살아남는 결과물을 출시합니다.

구현 팀들이 실제로 이 문제에 어떻게 접근하고 있는지 조사하던 중 발견한 참조 아키텍처(reference architecture)는 이를 7가지 계층으로 나눕니다:

인터페이스 (Interface), 채팅 UI (chat UI), 웹훅 (webhook), 예약된 트리거 (scheduled trigger), 메시지 큐 이벤트 (message queue event). 여기에는 비즈니스 로직이 포함되지 않습니다.
오케스트레이터 (Orchestrator), 목표를 단계별로 나누고, 하위 에이전트 (sub-agents)로 라우팅하며, 결정적으로, 되돌릴 수 없는 작업이 수행되기 전의 인간 승인 게이트 (human approval gate)를 관리합니다.
모델 (Model), 샌드박스 (sandbox) 내부의 실제 추론 (reasoning) 엔진입니다. 팀이 이를 직접 관리하지 않으며, 하네스 (harness)가 모델 선택을 처리합니다.
도구/API 계층 (Tool/API layer), 명시적이고 최소한의 범위 (scope)로 등록된 모든 통합 (integration)입니다. 앱 수준이 아닌 샌드박스 설정 (sandbox config) 수준에서 강제됩니다.
지식 계층 (Knowledge layer), RAG (검색 증강 생성)가 여전히 여기에 존재하지만, 워크플로 (workflow)를 주도하는 대신 지원하는 역할로 격하됩니다.
샌드박스/실행 (Sandbox/execution), Google의 격리된 컨테이너로, 네트워크 이그레스 (network egress)는 명시적인 허용 목록 (allowlisting)을 필요로 합니다.
감사, 관측성, 롤백 (Audit, observability, rollback), 모든 작업, 도구 호출 (tool call), 승인은 구조화된 로그 항목을 생성하며, 모든 쓰기 작업 (write action)에는 정의된 되돌리기 경로 (reversal path)가 필요합니다.

이 중 하나라도 건너뛴다면, 단순히 조금 더 성능이 낮은 에이전트를 얻게 되는 것이 아니라, 프로덕션 (production) 환경으로 넘어가지 못하는 파일럿을 얻게 되거나, 더 나쁜 경우 프로덕션에 투입되어 사고를 일으키는 에이전트를 얻게 됩니다.

누가 실제로 이를 제대로 구축하고 있는지에 대한 나의 주관적인 견해

최근 Vercel, LangChain, 그리고 엔터프라이즈 AI 도입을 수행하는 다양한 시스템 통합 업체 (systems-integrator shops) 등 에이전트 구현 작업에 대해 공개적으로 글을 쓰는 몇몇 팀들을 살펴보았습니다. 이 분야의 대부분의 공개 콘텐츠는 여전히 데모 중심입니다: "보세요, 에이전트가 항공권을 예약했습니다." 멋진 기술이지만, 이것이 감사를 통과할 수 있을지 여부에 대해서는 아무것도 알려주지 않습니다.

제가 이 글을 쓰게 된 계기가 된 분석은 GeekyAnts의 Managed Agents API 분석에서 비롯되었으며, 이는 제가 계속해서 되새기게 되는 내용입니다. 그 이유는 이 분석이 거버넌스 (Governance)를 아키텍처 다이어그램에 나중에 덧붙이는 부수적인 요소로 취급하지 않고, 제어 평면 (Control Plane)을 실제 결과물로 취급하기 때문입니다. 특히 리스크 계층화 (Risk-tiering) 접근 방식이 눈에 띄었습니다. 저위험 작업 (읽기, 초안 작성)은 자유롭게 실행되고, 중위험 작업 (기록 업데이트)은 짧은 검토 기간과 함께 로그가 기록되며, 고위험 작업 (결제, 외부 통신)은 실행 전 명시적인 인간의 승인이 필요합니다. 이것 자체가 새로운 아이디어는 아니지만, 단일한 "인간 참여 (Human-in-the-loop)" 체크박스로 처리하는 대신 7개 계층 전체에 걸쳐 일관되게 적용되는 것을 보는 것은 현재 시장에 나와 있는 것들에 비해 매우 드문 일입니다.

제 편향된 견해를 솔직하게 말씀드리겠습니다. 만약 당신이 "에이전트가 무엇을 할 수 있는지 보세요"를 앞세우는 에이전트 AI 벤더 또는 컨설팅 파트너와, "에이전트가 무엇을 할 수 있도록 범위를 지정할 것인지 보세요"를 앞세우는 파트너 중 하나를 선택해야 한다면, 두 번째를 선택하십시오. 첫 번째 유형의 피칭은 데모에서는 괜찮아 보일지 몰라도, 사고 사후 분석 (Incident postmortem) 단계에서는 최악이 됩니다.

누가 만들든 상관없이 훔쳐올 가치가 있는 마이그레이션 프레임워크

특정 벤더를 선택하든 아니든, 이 프레임워크의 이 부분은 그 자체로 훌륭한 엔지니어링 상식이며 통째로 가져올 가치가 있습니다:

기존 워크플로우를 두 가지 축으로 매핑하세요: 프로세스가 얼마나 잘 정의되어 있는지, 그리고 프로세스의 어느 정도가 이미 API 접근 권한을 가지고 있는지입니다. 모호한 판단이 필요한 부분이나 API 레이어가 없는 시스템은 파일럿 단계가 아닌 다음 단계로 넘겨야 합니다.
얇은 API 래퍼 (API wrapper)를 먼저 구축하세요. 개념 증명 (PoC) 이후 정체되는 대부분의 에이전트 프로젝트는 바로 이 지점에서 실패합니다. 즉, REST 레이어나 구조화된 응답 (structured responses)이 없는 레거시 시스템들 때문입니다.
워크플로우 단위가 아닌 액션 (action) 단위로 리스크 계층 (risk tiers)을 할당하세요. 단일 워크플로우 내에는 저위험, 중위험, 고위험 단계가 혼재될 수 있습니다.
모든 설정 변경 시에 평가 (evals)를 실행하세요. 여기에는 해피 패스 (happy path), 엣지 케이스 (edge cases), 그리고 정답이 "작업 완료"가 아니라 "사람에게 에스컬레이션 (escalate to a human)"인 경우를 모두 포함해야 합니다.
첫날부터 모니터링을 도구화 (instrument) 하세요: 작업 완료율, 단계별 에러율, 승인 빈도, 단계별 지연 시간 (latency) 등을 측정해야 합니다. 만약 특정 액션 유형에 대해 승인 빈도가 계속 높게 유지된다면, 이는 승인 게이트를 억제해야 할 이유가 아니라 리스크 임계값 (risk threshold)을 재검토해야 한다는 신호입니다.

파일럿 대상을 선정 중이라면, 다음과 같은 좋은 시작 워크플로우 카테고리가 있습니다: 지원 해결 (support resolution), 문서 운영 (계약서/송장 추출 및 기록화), 엔지니어링 유지보수 (승인 단계가 포함된 의존성 취약점 스캔 및 PR 생성), 그리고 내부 지식-액션 전환 (정책 질문 → 내부 프로세스 완료).

거버넌스 회의론자들에게 불편한 부분

이 논의가 논쟁의 여지가 없다고 가장하지 않겠습니다. 솔직하게 언급할 가치가 있는 반대 입장도 존재하기 때문입니다. 일부 팀은 과도한 거버넌스 구조화 — 리스크 계층, 모든 호출에 대한 감사 로그 (audit logs), 의무적인 30일간의 인간 승인 기반 롤아웃 (human-gated rollout) — 가 에이전트가 제거하기로 했던 마찰을 다시 도입할 뿐이라고 주장할 것입니다. 또한 리스크가 낮은 내부 도구의 경우, 실질적인 이득 없이 배포 속도만 늦추는 과잉 대응이라고 말할 수도 있습니다. 이는 진정으로 리스크가 낮고 되돌릴 수 있는(reversible) 워크플로우에 대해서는 타당한 지적입니다. 하지만 워크플로우가 돈, 고객 데이터, 또는 되돌릴 수 없는 무언가에 접촉하는 순간, 그 지적은 더 이상 타당하지 않게 됩니다. 그리고 실제로 기업이 자동화하기를 원하는 대부분의 작업은 바로 여기에 해당합니다.

이것이 기업 팀들에게 남기는 과제

인프라에 대한 논쟁은 끝났습니다. Google, 그리고 솔직히 말해서 대부분의 주요 모델 제공업체들은 "우리가 런타임 (runtime)을 관리할 테니, 당신은 신뢰 경계 (trust boundary)를 관리하십시오"라는 방향으로 수렴했습니다. 이것은 올바른 분업이며, 앞으로 차별화 요소가 되지는 않을 것입니다.

향후 1년 동안 팀들을 차별화할 요소는 권한 부여 (authorization), 도구 범위 (tool scope), 승인 게이트 (approval gates), 그리고 감사 추적 (audit trails)을 첫날부터 일급 아키텍처 (first-class architecture)로 취급했는지, 아니면 첫 사고가 발생한 후에 사후 수정 (retrofit)해야 할 사항으로 취급했는지 여부입니다. 저의 솔직한 견해는 이렇습니다. 현재 파일럿 모드에 있는 대부분의 팀은 자신이 어느 범주에 속해 있는지를 혹독한 경험을 통해 곧 깨닫게 될 것입니다.