쉬운 설명
AI 에이전트를 만드는 일과 운영 환경에서 돌리는 일은 서로 다른 문제입니다. 모델이 단계를 계획하고, 도구를 부르고, 결과를 읽게 만드는 것이 첫 번째 문제입니다. 그것을 몇 분에서 몇 시간까지 이어 가고, 재시작을 견디고, 남의 서버에 있는 도구에 연결하고, 그것도 수천 명의 사용자를 상대로 동시에 해내는 것이 두 번째 문제입니다. 두 번째는 배관 작업이고, 그 양이 만만치 않습니다.
매니지드 에이전트는 그 두 번째 문제를 플랫폼에 넘깁니다. 에이전트를 돌리려고 서버와 큐, 재시도 로직을 직접 세우는 대신, 제공사에 에이전트를 기술해 두고 실행은 제공사에 맡깁니다. 추론은 여전히 모델에서 나오고, 에이전트의 행동도 여전히 에이전트입니다. 계획을 세우고 도구를 부르고 결과를 점검하는 움직임은 그대로죠. 달라지는 것은 그 아래 실행 환경을 누가 소유하느냐입니다.
매니지드 형태가 대개 떠맡는 부분은 번거롭고 틀리기 쉬운 것들입니다. 오래 걸리는 작업은 플랫폼이 추적하는 백그라운드 작업이 되어, 한 시간짜리 일을 위해 내 프로세스가 옆에서 지키고 있지 않아도 됩니다. 원격 도구 연결은 다른 곳에 있는 도구와 데이터에 에이전트가 닿게 해 주는데, 흔히 MCP를 거치며 하나하나 손으로 잇지 않아도 됩니다. 단계 사이의 상태는 대신 저장되어, 에이전트가 멈춘 자리에서 다시 이어 갑니다. 그리고 확장, 재시작, 에이전트가 무엇을 했는지 들여다보는 일 같은 운영 측면은 제공사 쪽에 놓입니다.
대가는 매니지드 서비스에서 늘 치르는 그것입니다. 실행 환경에 대한 통제를 어느 정도 내려놓고, 에이전트를 정의하고 돌리는 방식이 제공사가 정한 틀을 따르게 됩니다. 그 대신 그 층을 직접 만들고 운영하지 않아도 됩니다.
비유로 보면
차를 직접 소유하는 것과 차량 서비스를 이용하는 것의 차이를 떠올려 보세요. 차를 소유하면 어디로 갈지는 여전히 내가 정하지만, 연료와 정비, 주차, 그리고 고속도로에서 고장 났을 때의 뒷수습까지 내 몫입니다. 차량 서비스는 목적지만 나에게 맡기고 나머지를 가져갑니다. 차량, 운전, 관리, 한밤중에 무언가 멈췄을 때의 문제까지요. 매니지드 에이전트는 그 차량 서비스 쪽입니다. 에이전트가 무엇을 해야 하는지, 목표가 무엇인지는 여전히 내가 정하고, 그 아래 차량을 굴리는 일, 즉 계속 돌리고 장거리 주행에 연료를 대고 고장을 처리하는 일은 플랫폼이 맡습니다.
어디에서 만나나
매니지드 에이전트는 실행 환경을 직접 소유하지 않으면서 운영 환경에서 에이전트 동작을 원하는 곳이면 어디든 등장합니다. 클라우드 AI 플랫폼이 가장 또렷한 자리입니다. 제공사가 에이전트를 정의하고, 도구에 연결하고, 대규모로 돌리는 방식을 호스팅해 제공하는 형태로, 구글의 Gemini API Managed Agents가 그 예입니다. 이 패턴은 오래 걸리는 백오피스 작업, 몇 분씩 돌아가는 리서치·데이터 작업, 그리고 MCP로 여러 원격 도구에 닿아야 하는 비서에 잘 맞습니다. 여러 에이전트나 단계를 조율해야 할 때는 오케스트레이션과, 호스팅된 에이전트가 무엇을 했는지 보는 일이 플랫폼이 제공하는 몫이라는 점에서 모니터링과, 그리고 매니지드 에이전트가 대개 내가 호스팅하는 것이 아니라 부르는 것이라는 점에서 API 층과 관심사가 겹칩니다.
작은 예시
2026년 7월 구글은 Gemini API의 Managed Agents를 확장한다고 밝히며 백그라운드 작업, 원격 MCP 연결 등을 들었고, 개발자가 신뢰할 수 있고 운영에 바로 올릴 만한 에이전트를 만들도록 돕는다고 설명했습니다. 정의에 비춰 보면 각 조각이 매니지드 형태가 떠맡는 운영 층에 그대로 대응합니다. 백그라운드 작업은 플랫폼이 알아서 이어 가는 장기 실행 작업입니다. 원격 MCP는 에이전트가 다른 곳에 있는 도구에 표준 커넥터로 닿는 것으로, 하나씩 직접 배선하는 방식이 아닙니다. 운영 준비 상태는 안정성 쪽, 곧 팀이 아니었으면 직접 만들고 굴려야 했을 부분입니다. 구체적인 한계와 설정은 구글 자체 문서에 있고, 여기서 짚는 것은 그 형태입니다. 제공사가 에이전트를 대신 돌려 주겠다는 제안이죠.
자주 하는 오해
한 줄 정리
매니지드 에이전트는 내가 설정하고 부르되 실행은 플랫폼이 맡는 에이전트로, 운영 층을 대신 떠맡습니다. 오래 걸리는 백그라운드 작업, MCP를 통한 원격 도구 연결, 단계 사이의 상태, 그리고 운영 안정성이 그 층입니다. 에이전트를 더 똑똑하게 만들어 주지도 않고, 에이전트에 무엇을 허용할지에 대한 책임을 없애 주지도 않습니다. 다만 실행 환경을 직접 만들고 굴리는 부담을 덜어 줍니다. 에이전트를 아예 작동시키는 것보다 대규모로 안정적으로 돌리는 쪽이 어려운 문제일 때 꺼내 쓰면 됩니다.
자주 묻는 질문
같은 개념을 두 방향에서 본 것입니다. AI 에이전트는 행동 쪽입니다. 모델이 단계를 계획하고, 도구를 부르고, 결과를 읽고, 다음을 정하는 움직임이죠. 매니지드 에이전트는 그 같은 행동이 플랫폼이 소유하고 운영하는 실행 환경 위에서 돌아가는 것입니다. 구분은 에이전트가 무엇을 하느냐가 아니라 그 아래를 누가 돌리느냐에 있습니다. 직접 호스팅하는 에이전트라면 서버를 세우고, 장기 작업을 살려 두고, 도구를 하나씩 잇고, 상태를 저장하고, 확장과 재시작을 스스로 처리합니다. 매니지드 에이전트라면 그 운영 층을 제공사가 가져가고, 나는 에이전트를 설정해 API로 부릅니다. 추론과 에이전트 루프는 그대로이고, 그 아래 기계의 주인이 바뀝니다.
아닙니다. 플랫폼이 관리하는 것은 실행 환경이지, 에이전트에 무엇을 허용할지에 대한 결정이 아닙니다. 어떤 도구에 에이전트가 닿을 수 있는지, 그 접근이 얼마나 넓은지, 어떤 행동에 사람의 승인 단계를 둘지, 사람 없이 얼마나 진행하게 할지는 여전히 내가 고릅니다. 어느 에이전트의 하네스에나 있는 그 신뢰 관심사와 같고, 제공사가 프로세스를 돌린다고 해서 그 책임이 제공사에게 넘어가지는 않습니다. 지나치게 넓은 도구 접근은 여전히 실수 하나의 파급 범위를 키우고, MCP로 원격 도구에 연결하는 일은 여전히 어떤 데이터가 어디로 흐를지 정하는 문제입니다. 매니지드 에이전트는 인프라 구축을 건너뛰게 해 줄 뿐, 안전장치 설계를 건너뛰게 해 주지는 않습니다.
문제의 어려운 부분이 에이전트를 아예 작동시키는 것이 아니라 운영일 때 맞습니다. 에이전트가 오래 걸리는 작업을 몇 분에서 몇 시간씩 이어 가고, 재시작을 견디고, 여러 원격 도구에 닿고, 동시에 많은 사용자를 상대해야 한다면 그 운영 층은 실제 일거리이고, 매니지드 형태는 그것을 만드는 수고를 건너뛰게 해 줍니다. 빠르게 움직이고 싶고 에이전트를 정의하고 돌리는 제공사의 틀을 받아들일 수 있는 팀에 잘 맞습니다. 실행 환경을 촘촘히 통제해야 하거나, 플랫폼이 지원하지 않는 특수한 요구가 있거나, 한 제공사에 의존하는 것을 피하고 싶을 때는 직접 돌리는 편이 낫습니다. 이 선택은 어떤 매니지드 대 직접 호스팅 결정과도 닮았고, 에이전트에 맞춰 저울질하면 됩니다.