2026년 6월, 기업이 주목해야 할 가장 중요한 신호는 또 하나의 LLM 등장이나 벤치마크 경쟁이 아니다. Google Cloud, AWS, Microsoft, Databricks에서 보이는 진짜 전환은 다른 곳에 있다. MLOps가 에이전트 운영의 학문으로 바뀌고 있으며, 비즈니스 컨텍스트, 거버넌스, 관측 가능성, 추론 단가라는 네 가지 과제가 동시에 부상하고 있다. 모든 주요 플레이어가 runtime, identity, gateways, memory, traceability, continuous evaluation을 중심으로 발표를 재편하고 있다면, 이는 유행이 아니라 계층의 변화다.
다시 말해, 2024년에는 어떤 모델을 선택할지가 핵심 질문이었다면, 2026년에는 무엇이 컨텍스트, 권한, 추적 로그, 비용, 그리고 공급업체 전환 가능성을 통제하는지가 프로덕션 전환을 좌우한다. Microsoft는 이를 거의 노골적으로 말한다. 병목은 더 이상 모델의 성능이 아니라 기업의 shared context라는 것이다. Databricks 역시 눈에 보이는 agentic loop는 작업의 극히 일부일 뿐이며, 나머지는 보안, 배포, 모니터링, 비용, 품질로 이루어진 숨은 technical debt라고 설명한다. AWS는 이제 production traces를 기반으로 한 지속적 개선을 강조한다. Google은 에이전트를 구축, 배포, 거버넌스, 최적화하는 완전한 플랫폼을 밀고 있다.
AI가 cloud로 들어가는 것이 아니다. cloud가 다시 AI의 운영체제가 되고 있다.
모든 공급업체에서 공통적으로 보이는 전환
올봄과 6월의 발표에서 공통적으로 드러나는 점은 매우 선명하다. Google Cloud는 Gemini Enterprise Agent Platform을 출시해 에이전트를 구축, 확장, 거버넌스, 최적화하기 위한 플랫폼으로 포지셔닝했다. 여기에는 model selection, integration tools, DevOps, orchestration, security가 하나의 계층에 통합되어 있다. Google Cloud Next ’26에서는 graph 기반 Agent Developer Kit와 대규모 에이전트의 구축, 테스트, 배포를 위한 Agent Studio도 강조했다.
Microsoft의 Build 2026 메시지도 그보다 조금 덜 직접적일 뿐 본질은 같다. 회사는 이제 문제의 핵심이 모델의 힘이 아니라, 비즈니스 시스템 안에서 행동해야 하는 에이전트에게 일관된 data context를 제공하는 능력이라고 말한다. Build 2026 공식 페이지 역시 주요 발표 항목으로 “observability to ROI for AI agents”부터 portable governance, Foundry의 대규모 배포 및 실행까지 다양한 구성요소를 전면에 내세운다.
AWS는 Bedrock AgentCore를 산업적 운영의 논리로 전환했다. 2026년 6월 18일 발표된 새로운 optimization 기능은 에이전트 생성보다도, production traces를 통해 무엇이 일어나는지 파악하고, 문제를 수정하고, 그 수정이 실제로 시스템을 개선했음을 입증하는 순환 구조에 더 초점을 맞춘다. AWS는 가장 위험한 장애를 에러를 반환하는 경우가 아니라, 나중에 고객 불만으로만 드러나는 silent failure라고 정의한다.
Databricks 역시 같은 해석을 다른 언어로 제시한다. DAIS 2026 글에서 이 회사는 agentic loop는 보이는 “1%”에 불과하며, 나머지 “99%”는 deployment, token capacity, security, evaluation, observability, context, sharing에 속한다고 설명한다. 여기서 중요한 것은 제품 발표 그 자체보다 framing이다. Databricks에게 시장의 문제는 이미 에이전트 데모를 만드는 방법이 아니라, 신뢰할 수 있는 agentic system을 운영하는 방법이다.
의사결정자에게 주는 교훈은 단순하다. Google, AWS, Microsoft, Databricks가 각기 다른 용어를 쓰면서도 runtime, identity, memory, gateways, tracing, scoring, governance라는 동일한 블록으로 수렴한다면, 이는 “POC + hype”의 단계가 끝나고 architecture의 단계로 들어갔다는 뜻이다. 따라서 MLOps의 중심은 모델에서 운영 체인으로 이동한다.
왜 MLOps가 AgentOps가 되는가
이 변화는 기술 스택의 성격 자체를 바꾼다. 전통적인 MLOps에서는 데이터와 모델 버전 관리, endpoint 배포, 몇 가지 메트릭 추적, 그리고 재학습 pipeline 재실행이 핵심이었다. 하지만 2026년의 스택에서는 여기에 더해 agent runtime, short-term 및 long-term memory, action permissions, external tools, execution traces, response quality, behavior compliance, multi-step chain latency까지 관리해야 한다. Google은 이미 이 계층을 문서화하고 있다. Agent Platform은 managed runtime, sessions, Memory Bank, logging, tracing, monitoring, 그리고 agent별 identity를 제공한다.
가장 흥미로운 세부 사항은 agentic identity의 부상이다. Google 문서에서 Agent Identity는 SPIFFE 표준을 기반으로 한 cryptographically attested identity에 의존하며, 이를 통해 agent를 MCP servers, cloud resources, endpoints, 다른 agents에 대해 인증한다. 즉, 문제는 더 이상 “누가 API를 호출하는가?”가 아니라 “어떤 agent가, 누구를 대신해, 어떤 권한 범위로 행동하는가?”가 된다. 이는 보안이 자동화된 행동의 수준으로 올라간다는 의미다.
AWS 역시 같은 방향으로 움직이고 있다. AgentCore Gateway는 기존 API, Lambda functions, services를 Model Context Protocol 호환 도구로 전환하며, inbound/outbound authentication, 즉시 사용 가능한 integrations, 세밀한 access control을 제공한다. 이 계층은 에이전트 세계와 실제 enterprise IT를 연결하기 때문에 전략적이다. CRM, messaging, ticketing, documentation, databases, workflows가 모두 여기에 연결된다. 그 결과 MLOps는 더 이상 순수한 “모델” 이슈가 아니라 platform + integration + security의 문제로 바뀐다.
또 다른 전환은 qualitative observability다. Databricks의 MLflow 3는 이미 real-time traces, scorers, human feedback, versioning을 통해 GenAI applications와 agents의 tracking, evaluation, observability를 통합한다. 운영 환경에서는 샘플 trace에 대해 scorers를 자동 실행해 품질을 지속 평가하는 monitoring을 제공한다. 이는 배포 전에 한 번 평가하는 것이 아니라, 실제 서비스에 올라간 뒤의 행동을 평가한다는 뜻이다. AWS도 다른 방식으로 같은 메시지를 전한다. AgentCore Observability는 session 수, latency, duration, token usage, error rate에 대한 실시간 metrics를 제공하며, investigation을 위한 metadata filtering도 지원한다.
마지막으로 inference 인프라 자체가 “단순 GPU 호스팅”이 아니라 “platform”이 되고 있다. CNCF는 Gateway API 기반 Inference Gateway가 이제 GA 상태이며, model name, LoRA adapter, endpoint 상태에 따라 트래픽을 라우팅해 server pool을 더 효율적으로 공유하고 accelerator utilization을 높일 수 있다고 설명한다. Google은 NVIDIA Dynamo를 GKE Inference Gateway와 통합하고, 더 정교한 capacity planning을 위한 fractionable G4 VM도 발표했다. 여기서도 질문은 더 이상 “GPU를 어디서 구할까?”가 아니라 “추론 용량을 어떻게 discipline 있게, 공유하면서, 세밀하게 운영할까?”로 바뀐다.
조직 측면에서 이것이 의미하는 바는 결정적이다. 이제 MLOps는 security, cloud platform, data engineering, IAM team, FinOps team, 때로는 legal과도 협업해야 한다. “AgentOps”는 단순한 유행어가 아니다. AI 운영이 data science의 사일로를 벗어나 SI의 핵심 운영 영역으로 들어왔다는 증거다.
결국 예산으로 돌아오는 숨은 비용
여기서부터는 진짜 의사결정의 문제다. Flexera의 State of the Cloud 2026에 따르면, 조직의 58%는 이미 public cloud의 GenAI 서비스를 사용하고 있으며, 45%는 이를 광범위하게 사용한다고 답했다. 73%는 hybrid로 운영하고 있고, 49%는 이제 cloud 지출을 business outcome과 연결하기 위해 unit economics를 활용한다. 또한 IaaS/PaaS waste는 29%로 추정된다. Flexera는 64%의 조직이 cloud를 단순한 cost efficiency보다 business value 기준으로 측정한다고도 밝힌다. 이는 단순한 통계가 아니다. 대화의 초점이 “얼마나 드는가?”에서 “서비스당, 사용량당, workflow당, 팀당, 고객당 비용은 얼마인가?”로 옮겨가고 있다는 뜻이다.
이 변화는 유럽 기업들이 현장에서 이미 체감하는 흐름과도 맞물린다. Reuters는 Siemens, Renault, Orange, ChapsVision 같은 기업들이 종속 위험을 줄이기 위해 공급업체를 다변화하고 있다고 보도했다. 동시에 agent가 더 많은 업무를 자동화할수록 token 단가가 민감한 이슈가 되기 때문이라고 설명한다. 기사에서는 예정보다 훨씬 빨리 소진되는 token budget 사례도 직접 언급된다. 금융시장조차 hyperscaler의 AI 인프라 지출 규모를 우려하기 시작했는데, 이는 경제적 ROI 문제가 더 이상 기술 커뮤니티 안에만 머물지 않는다는 신호다.
또 하나 자주 오해되는 점이 있다. agentic system의 비용은 model API 가격으로 끝나지 않는다. AWS의 AgentCore pricing 페이지를 보면 model 외에도 gateway calls, short-term memory, long-term memory storage, memory retrieval, observability 등 여러 비용이 별도 항목으로 쌓인다. AWS가 공개한 pricing examples는 바로 이런 세분성을 보여준다. 즉, model 비용을 제외하더라도 agentic operations layer 자체가 별도의 경제 구조를 만든다.
따라서 CIO나 CFO에게 적절한 예산 질문은 “prompt 하나당 비용이 얼마인가?”가 아니라 “유의미한 agent 하나당 전체 비용은 얼마인가?”여야 한다. 이 전체 비용에는 최소한 model, external tools, memory, logging, tracing, security, guardrails, storage, context data, 그리고 evaluation과 remediation에 필요한 human time이 포함된다. 이 unit economics를 추적하지 않으면, 기업은 adoption은 확인하되 그것이 value를 만드는지 아니면 cloud load만 늘리는지 알 수 없게 된다.
이 때문에 FinOps도 성격이 바뀐다. Flexera는 더 이상 전통적인 cloud cost management 기능만 말하지 않고, applications, agents, models, data platforms, compute를 포괄하는 AI Cost Management 계층을 제시한다. 암묵적인 메시지는 분명하다. AI 지출은 이제 cloud 지출의 부속 항목이 아니라, 별도의 운영 대상이 될 만큼 복잡한 독립적 관리 영역이 되었다.
AI cloud는 다시 주권의 문제다
또 다른 오독은 AI cloud를 AWS, Azure, Google Cloud 사이의 단순한 기술 선택으로 보는 것이다. 유럽에서 2026년 6월 현재, 이 문제는 business continuity와 operational sovereignty의 문제이기도 하다. 유럽연합 집행위원회는 6월 3일 Cloud and AI Development Act 제안을 채택했으며, 이는 유럽의 cloud 및 AI 생태계, 투자, 인프라를 강화하기 위한 수단으로 제시됐다. 동시에 공식 일정에 따르면 AI Act는 2026년 8월 2일부터 전면 적용되며, 2026년 8월부터 transparency 규정이 발효되고, 전반적 프레임워크는 공급자와 배포자의 책임을 강화한다.
이 정치적 차원은 이미 기업 아키텍처에 반영되고 있다. Reuters는 일부 미국 서비스에 대한 접근 제한 이후 유럽 대기업들이 모델과 공급업체 다변화를 가속화하고 있다고 전했다. 이는 원격의 proprietary service가 공급자에 의해 제한될 수 있고, 고객 자체 서버에서 반드시 운영 가능한 것은 아니기 때문이다. 여기서 sovereignty는 autarky를 뜻하지 않는다. Siemens, Orange, Renault가 말하는 것은 주로 flexibility, multi-vendor mix, 그리고 어떤 업체가 접근을 차단하거나 조건을 바꿨을 때의 백업 능력이다.
이런 맥락에서 OVHcloud의 발표를 읽어야 한다. Reuters에 따르면 프랑스 기업 OVHcloud는 frontier models를 학습해 유럽의 두 번째 대형 LLM 플레이어가 되겠다는 계획을 세우고 있으며, 이 새로운 기술 사이클의 비용은 1억5천만~2억 유로로 추정된다. 이는 이전에 흔히 거론되던 10억 유로와는 거리가 멀다. 이 계획이 상업적으로 성공하든 아니든, 중요한 점은 분명하다. AI cloud sovereignty는 더 이상 추상적 제도 담론이 아니라, 유럽 주요 기업들의 product와 infrastructure 전략 안으로 들어왔다.
기업 입장에서 이 긴장의 실무적 해석은 매우 구체적이다. “sovereign” architecture는 단지 유럽에 호스팅된 아키텍처가 아니다. 어떤 구성요소를 자체적으로 운영 가능해야 하는지, 어떤 도구는 대체 가능성을 유지해야 하는지, 어떤 context data는 proprietary runtime에 갇히면 안 되는지, 그리고 중요한 agent를 며칠 안에 다른 model이나 provider로 전환할 수 있는지를 정의하는 아키텍처다. agent가 비즈니스 프로세스 위에서 행동하는 순간, 공급업체 의존성은 개발자의 선택이 아니라 risk variable이 된다.
지금 의사결정을 위한 유용한 프레임
따라서 질문은 “생성형 AI를 위해 MLOps를 해야 하는가?”가 아니라, 어떤 유형의 운영 방식을 표준화할 것인가이다. 아래 표는 2026년 6월의 신호가 기업에 실제로 무엇을 바꾸는지 요약한다. 예산, 아키텍처 로드맵, 공급업체 선택을 결정할 때 참고할 수 있다.
| 의사결정 축 | 2026년에 달라지는 점 | 위원회에서 던질 질문 |
|---|---|---|
| 아키텍처 | 기반은 더 이상 model endpoint가 아니라 runtime + memory + gateway + identity + traces + evaluation의 조합이다. | 단일 agent runtime을 표준화할 것인가, 아니면 여러 cloud와 framework 사이에서 portable한 계층을 유지할 것인가? |
| 거버넌스 | observability가 행동 중심으로 바뀐다: token, latency, session, 호출된 tools, traces, feedback, continuous scoring. | 프로덕션 전환 전에 어떤 지표를 반드시 요구할 것인가: 비용, 품질, groundedness, 보안, 해결 시간? |
| 예산 | AI 지출은 model, memory, tools, logs, tracing, security, data, GPU capacity가 결합된 복합 비용이 된다. Flexera는 unit economics와 cloud waste의 부상을 관찰한다. | 우리는 유의미한 agent 하나당, 사용자 여정 하나당, 또는 비즈니스 기능 하나당 전체 비용을 알고 있는가? |
| 비즈니스 컨텍스트 | Microsoft는 병목이 model이 아니라 shared context라고 강조하고, Databricks는 context quality와 knowledge governance를 플랫폼의 핵심으로 둔다. | 어떤 데이터셋, ontology, 문서, 권한이 agent의 “source of truth”를 구성하는가? |
| 주권 | 유럽에서는 resilience가 공급업체 다양성, 대체 가능성, 일부 구성요소의 로컬 운영 능력에서 나온다. 규제 프레임은 2026년 8월까지 더 엄격해진다. | 공급업체가 접근 정책을 바꾸면, 우리는 며칠 안에 핵심 agent를 전환할 수 있는가? |
가장 실용적인 결론은 AI cloud 구매를 더 이상 “가장 좋은 model” 기준으로 평가해서는 안 된다는 점이다. 대신 context portability, observability의 품질, control의 세밀함, cost visibility, fallback capability라는 다섯 가지 기준이 더 중요하다. 어떤 공급업체는 데모에서는 뛰어나지만 산업화에서는 약할 수 있다. 바로 이 간극이 지금 시장을 재편하고 있다.
앞서가는 기업들은 이미 무엇을 이해했는가
선도 기업들이 읽어야 할 신호는 분명하다. 다음 기업용 AI 전쟁은 더 나은 model에 접근할 수 있는가보다, 경제적·법적으로 지속 가능한 틀 안에서 agents를 운영할 수 있는가에 관한 싸움이 될 것이다. 앞서가는 조직은 단지 빨리 배포하는 조직이 아니다. agents를 측정 가능하고, 변경 가능하고, 거버넌스 가능한 상태로 만드는 조직이다. 이들은 context를 전략 자산으로, cost를 product metric으로, security를 권한 목록이 아니라 action policy로 다룬다.
물론 방법론적 신중함은 필요하다. 신호의 상당 부분은 공급업체 발표와 제품 문서에서 나오며, 일부 기능은 Databricks의 MLflow 3 production monitoring처럼 아직 beta 또는 preview 단계다. 이는 실제 도입 속도가 keynote가 암시하는 것보다 더 느리고 불균등할 수 있음을 뜻한다. 하지만 이 한계가 본질을 바꾸지는 못한다. 네 개의 대형 cloud 및 data 생태계가 동일한 기술 primitive로 수렴하고 있다면, 그 흐름은 오래 갈 가능성이 높다.
따라서 반드시 기억할 핵심 문장은 다음과 같다. 2026년 MLOps & Cloud AI의 진짜 과제는 model을 서빙하는 것이 아니라, context, evidence, guardrails를 갖춘 agents를 운영하는 것이다. 이를 단순한 tooling 문제로 읽는 기업은 뒤처질 것이다. 반대로 이를 cloud 운영, 재무 통제, 운영 거버넌스의 재설계로 이해하는 기업은 다음 물결을 더 잘 흡수할 수 있다.