올해 AWS, Microsoft, Google이 AI 에이전트(AI agents)를 위해 출시한 것들을 자세히 살펴보면 이상한 점을 발견하게 됩니다. 이름도 다르고 브랜딩도 다르지만, 그 밑바닥에는 정확히 똑같은 제품이 있습니다. 이러한 수렴(convergence)은 떠나려고 하기 전까지는 매우 편리합니다. 그들이 모두 무엇을 만들고 있는지, 그리고 왜 여러분이 조금 주의해야 하는지 설명하겠습니다.

세 기업이 실제로 만들고 있는 것

마케팅을 걷어내고 보면, 세 대형 클라우드 기업은 기업용 AI 에이전트를 실행하기 위해 동일한 5가지 구성 요소의 스택(stack)을 조립하고 있습니다. 에이전트를 실행하기 위한 관리형 런타임(managed runtime), 컨텍스트(context)를 기억하기 위한 메모리(memory), 인증 및 거버넌스(governance)를 위한 아이덴티티(identity), 시스템을 호출하기 위한 도구(tools), 그리고 에이전트가 무엇을 했는지 확인할 수 있는 관측성(observability)입니다.

해당 제품들은 AWS Bedrock AgentCore, Agent365 컨트롤 플레인(control plane)을 갖춘 Microsoft의 Azure AI Foundry, 그리고 Google의 Vertex AI 에이전트 스택(agent stack)입니다. 가격 페이지에서는 서로 달라 보일지 모릅니다. 하지만 아키텍처(architecturally) 측면에서 보면, 이들은 동일한 아이디어를 세 번 구현한 것에 불과합니다.

이것은 우연이 아닙니다. 기업 내부에서 에이전트를 안전하게 실행한다는 동일한 문제를 해결하다 보면 결국 동일한 구성 요소들에 도달하게 됩니다. 시장은 기본적으로 2026년 초에 에이전트 플랫폼의 형태에 대해 합의를 보았으며, 각 하이퍼스케일러(hyperscaler)는 자사의 클라우드에서 이를 점유하기 위해 경쟁했습니다.

왜 이러한 수렴이 처음에는 좋게 느껴지는가

만약 여러분의 데이터와 아이덴티티(identity)가 이미 하나의 클라우드에 있다면, 해당 클라우드의 에이전트 런타임(agent runtime)이 프로덕션(production)으로 가는 가장 빠른 경로입니다. 저장소도 그곳에 있고, 아이덴티티 시스템도 그곳에 있으며, 로깅(logging)도 그곳에 있습니다. 플랫폼이 이 모든 것과 즉시 결합됩니다. 거버넌스(governance), 감사 추적(audit trails), 배포(deployment)를 거의 공짜로 얻는 셈입니다.

적절한 통제 하에 에이전트를 실행하기만 하면 되는 팀에게 이것은 정말 큰 선물입니다. 저도 그 매력을 이해합니다.

아무도 슬라이드에 넣지 않는 함정

여기에 함정이 있습니다. 에이전트의 런타임, 자격 증명(credentials), 상태(state), 그리고 텔레메트리(telemetry)가 모두 하나의 클라우드 안에 살게 되면, 이를 다른 곳으로 옮기는 것은 단순한 설정 변경이 아닙니다. 그것은 재구축(rebuild)입니다.

AWS Bedrock AgentCore를 예로 들어보겠습니다. 그 위에서 구축된 에이전트는 AWS의 ID(identity), 네트워킹(networking), 그리고 스토리지(storage)에 연결되어 있습니다. 이를 가져와 Azure나 Google로 옮기는 것은 단순히 몇 가지 통합(integration) 설정을 바꾸는 문제가 아닙니다. IAM 바인딩(bindings), VPC 설정, 그리고 스토리지 훅(storage hooks)이 모두 AWS 전용이기 때문입니다. 에이전트를 옮기는 것이 아니라, 다시 작성(rewrite)해야 하는 것입니다.

이것이 API를 전환하는 것과 클라우드를 전환하는 것의 차이입니다. 몇 가지 통합 기능을 다시 작성하는 것은 짜증 나는 일이지만, 새로운 플랫폼에서 ID(identity), 상태(state), 그리고 텔레메트리(telemetry)를 다시 구현하는 것은 하나의 거대한 프로젝트입니다.

하지만 오픈 프로토콜(open protocols)이 이 문제를 해결해주지 않나요?

부분적으로는 그렇습니다. 이 부분은 정확히 짚고 넘어갈 가치가 있습니다. 에이전트를 도구에 연결하는 MCP와 같은 오픈 표준(open standards)이나 에이전트 간 프로토콜(agent-to-agent protocols)은 에이전트가 사물과 통신하는 방식을 표준화합니다. 이는 실질적인 진전입니다.

하지만 '대화(talking)'가 문제의 전부는 아닙니다. 이식성(Portability)에는 세 가지 축이 있습니다: 에이전트가 사용하는 프레임워크(framework), 에이전트가 실행되는 모델(model), 그리고 에이전트가 거주하는 클라우드(cloud)입니다. 오픈 프로토콜은 주로 앞의 두 가지를 도와줍니다. 하지만 여러분의 배포(deployment), ID 설정, 또는 저장된 상태(stored state)를 다른 클라우드로 옮겨주지는 않습니다. 이 축들 중 어느 하나라도 실패한다면, 여러분은 단지 한 종류의 락인(lock-in)을 다른 종류의 락인으로 바꾼 것에 불과합니다.

클라우드 불가지론(cloud-agnostic)이 실제로 요구하는 것

진정한 이식성이란 나중에 덧붙이는 것이 아니라, 처음부터 세 가지 축 모두에 대해 의도적으로 설계하는 것을 의미합니다.

에이전트의 두뇌가 특정 벤더에 용접되지 않도록, 클라우드의 독점적인 프리미티브(proprietary primitives) 대신 여러분이 제어할 수 있는 프레임워크 내에 에이전트 로직을 유지하십시오. 가격과 품질이 매달 변하므로, 추상화(abstraction) 계층 뒤에서 모델을 교체 가능하게 유지하십시오. 그리고 어떤 클라우드나 프레임워크에서 생성되었든 상관없이 에이전트를 통제, 관찰 및 감사할 수 있는 에이전트 게이트웨이(agent gateway)나 관리 계층과 같은 클라우드 상위의 컨트롤 플레인(control plane)을 유지하십시오.

좋은 소식은 이러한 계층이 등장하고 있다는 점입니다. Microsoft Purview, Databricks Unity Catalog, 그리고 Google의 Agent Governance Framework와 같은 거버넌스(governance) 도구들이 에이전트 전반에 걸친 감사 추적(audit trails)과 데이터 계보(data lineage)를 제공하기 시작했습니다. 문제는 특정 클라우드의 거버넌스 도구를 사용하는 것이 당신을 조용히 해당 클라우드로 다시 끌어들일 수 있다는 점입니다. 목표는 중립성을 유지하는 것입니다.

이에 대한 나의 대응 방안

하이퍼스케일러(hyperscaler) 플랫폼을 반드시 피해야 하는 것은 아닙니다. 이들은 진정으로 훌륭하며, 단일 클라우드 환경을 운영하는 기업에게 락인(lock-in)은 속도를 위해 지불할 가치가 있는 대가일 수 있습니다. 다만, 그것이 사고가 아닌 '결정'이 되도록 하십시오.

하나의 플랫폼 위에서 구축하기 전에, 지루할 정도로 근본적인 질문들을 던져보십시오. 만약 1년 안에 이 에이전트를 다른 클라우드로 옮겨야 한다면, 무엇이 망가질까요? 에이전트의 상태(state)는 어디에 저장됩니까? 에이전트의 정체성(identity)은 누가 소유합니까? 만약 정직한 답변이 "모든 것이 망가진다"라면, 당신은 락인을 선택하고 있는 것이며, 그것이 의도된 선택이라면 괜찮습니다.

결론

Amazon, Microsoft, Google은 모두 동일한 기업용 에이전트 플랫폼을 구축하고 있으며, 각 플랫폼은 자신의 클라우드 내부에서 도입하기가 가장 쉽고 떠나기가 가장 어렵습니다. 개방형 프로토콜(open protocols)은 에이전트가 통신하는 방식을 표준화하지만, 당신의 배포 환경을 이식 가능하게(portable) 만들어주지는 않습니다. 나중에 클라우드를 옮기는 것이 중요하다면, 첫날부터 에이전트 로직, 모델, 그리고 컨트롤 플레인(control plane)을 벤더 중립적(vendor-neutral)으로 유지하십시오. 지금의 편의성을 택할 것인지, 나중의 자유를 택할 것인지. 단, 당신이 무엇을 선택했는지는 반드시 알고 있어야 합니다.