사내의 여러 팀이 각자 필요에 따라 AI 에이전트를 만들어 쓰기 시작했다. 인사팀은 휴가 신청을 돕는 봇을, 개발팀은 코드 리뷰를 돕는 봇을 만들었다. 하지만 시간이 흐르자 문제가 생겼다. 누가 어떤 에이전트를 만들었는지, 이들이 서로 충돌하지는 않는지, 보안 규칙은 잘 지키고 있는지 확인할 길이 없다. 이른바 섀도우 에이전트(관리자 모르게 개별적으로 도입된 AI 도구)들이 늘어나며 기업 내부의 AI 환경은 통제 불능의 상태로 치닫고 있다.

구글과 AWS가 제시한 서로 다른 관리 도구

최근 AI 시장의 거물들이 이 혼란을 해결하기 위한 각자의 도구를 내놓았다. 구글은 기존의 Vertex AI(구글의 AI 개발 플랫폼)를 Gemini Enterprise Platform(제미나이 엔터프라이즈 플랫폼)으로 이름을 바꾸고, Gemini Enterprise Application(제미나이 엔터프라이즈 애플리케이션)과 함께 하나의 통합 체계로 묶었다. 구글은 기업이 모든 AI 시스템과 도구에 접근할 수 있는 단일 창구를 제공하며, 보안과 거버넌스(기업의 의사결정 체계 및 관리 규칙) 도구를 구독 서비스의 일부로 무료 제공한다.

AWS는 Bedrock AgentCore(AWS의 에이전트 구축 도구)에 새로운 관리형 에이전트 하네스를 추가했다. 여기서 하네스(Harness)란 복잡한 구축 과정 없이 설정만으로 에이전트를 빠르게 실행하게 돕는 장치를 말한다. 이 시스템은 AWS의 오픈소스 에이전트 프레임워크(AI 에이전트의 뼈대가 되는 기본 구조)인 Strands Agents를 기반으로 작동한다. 사용자가 에이전트의 역할, 사용할 모델, 호출할 도구만 정의하면 AgentCore가 이를 자동으로 연결해 실행한다.

이 외에도 Anthropic은 Claude Managed Agents(앤스로픽의 관리형 에이전트 서비스)를 통해 백엔드 작업을 단순화했고, OpenAI는 Agents SDK(OpenAI의 에이전트 개발 도구 모음)를 업데이트해 샌드박스(외부 영향 없이 안전하게 코드를 실행하는 격리 공간) 지원과 준비된 하네스 기능을 추가했다.

실행 속도와 시스템 제어의 트레이드오프

이들의 접근 방식은 AI 스택을 바라보는 관점에서 극명하게 갈린다. 쉽게 말하면 AWS, OpenAI, Anthropic은 빠르게 제품을 출시하는 속도에 집중하고 있고, 구글은 전체 시스템을 어떻게 통제할 것인가라는 관리 효율에 집중하고 있다.

비유하자면 AWS의 방식은 밀키트와 같다. 정해진 재료와 레시피가 있어 누구나 빠르게 요리를 완성해 식탁에 올릴 수 있다. 반면 구글의 방식은 거대한 주방의 관제 시스템과 같다. 어떤 재료가 들어오고 나가는지, 위생 규칙은 지켜지는지, 요리사가 실수하지 않는지를 한곳에서 감시하고 조정하는 제어 평면(Kubernetes-style control plane, 시스템 전체를 한곳에서 관리하는 제어 센터 방식)을 구축하는 것이다.

이런 관리 체계가 중요해진 이유는 상태 드리프트(State drift, 시간이 흐르며 에이전트의 기억이 실제 데이터와 어긋나는 현상) 때문이다. 에이전트가 단순한 일회성 답변을 넘어 장기적인 업무를 수행하면, 과거의 기억과 현재의 데이터가 충돌하며 답변의 정확도가 떨어지기 시작한다. 비유하자면 1년 전 메뉴판을 외우고 있는 직원이 지금은 없어진 메뉴를 계속 추천하는 것과 같다. 실행 속도만 높인 시스템에서는 이런 오류를 잡아내기 어렵지만, 구글처럼 제어 중심의 시스템에서는 에이전트의 행동을 모니터링하며 즉시 교정할 수 있다.

결국 기업은 리스크 관리 수준에 따라 선택지를 골라야 한다. 매출에 직접적인 영향을 주지 않는 가벼운 서비스라면 AWS나 OpenAI의 하네스 방식을 통해 빠르게 실험하는 것이 유리하다. 하지만 금융 거래나 고객 개인정보 처리처럼 단 한 번의 실수도 허용되지 않는 핵심 프로세스라면, 구글처럼 중앙에서 정체성을 관리하고 정책을 강제할 수 있는 제어 시스템이 필수적이다.

AI 에이전트의 경쟁은 이제 누가 더 똑똑한 모델을 만드느냐가 아니라, 누가 더 안전하게 기업의 업무 흐름 속에 안착시키느냐의 싸움으로 옮겨갔다.