AI 에이전트 관제탑 전쟁이 시작됐다

AI 요약

• 무슨 일: Microsoft가 Agent 365를 GA로 전환했고, ServiceNow와 Cisco도 같은 주에 에이전트 관제·보안 계층을 강화했습니다.
  • Microsoft는 로컬 OpenClaw, 향후 GitHub Copilot CLI와 Claude Code, AWS Bedrock, Google Cloud agent registry까지 관측 대상으로 넓혔습니다.
• 의미: 에이전트 경쟁의 중심이 모델 성능에서 등록, 신원, 권한, 로그, 차단으로 이동하고 있습니다.
• 주의점: 관제 제품은 아직 preview·Innovation Lab 단계가 섞여 있어, 실제 운영 성숙도와 벤더 종속성은 따로 검증해야 합니다.

5월 첫째 주의 AI 뉴스에서 가장 흥미로운 장면은 새 모델 발표가 아니었습니다. 더 조용하지만 훨씬 실무적인 변화가 있었습니다. Microsoft는 2026년 5월 1일 Agent 365를 commercial customer 대상으로 일반 제공한다고 밝혔습니다. ServiceNow는 5월 5일 Knowledge 2026에서 AI Control Tower 확장을 발표했습니다. Cisco는 하루 앞선 5월 4일 non-human identity 보안 기업 Astrix Security 인수 의향을 공개했습니다.

셋을 따로 보면 평범한 엔터프라이즈 제품 뉴스처럼 보입니다. 하지만 함께 놓으면 방향이 선명합니다. 기업 AI 에이전트 시장은 이제 "에이전트를 만들 수 있는가"에서 "조직이 에이전트를 어떻게 통제할 것인가"로 넘어가고 있습니다. 코딩 에이전트, 업무 자동화 에이전트, SaaS 에이전트, 로컬 데스크톱 에이전트가 늘어나면 문제는 자연스럽게 바뀝니다. 누가 이 에이전트를 만들었는지, 어떤 자격 증명으로 움직이는지, 어떤 데이터에 접근하는지, 사고가 났을 때 어떻게 멈출 수 있는지가 핵심이 됩니다.

이 변화는 개발자에게도 직접적인 신호입니다. 앞으로 엔터프라이즈에서 에이전트를 배포한다는 말은 단순히 프롬프트와 tool calling을 잘 설계한다는 뜻이 아닙니다. 사람 계정, 서비스 계정, 디바이스, SaaS 앱을 관리하던 방식처럼 에이전트도 등록되고, 소유자가 지정되고, 권한이 제한되고, 실행 로그가 남고, 정책 위반 시 차단되어야 합니다. 에이전트가 조직 안에서 실제 일을 하려면 "AI 기능"이 아니라 "운영 가능한 디지털 행위자"로 취급되어야 하는 셈입니다.

Agent 365는 에이전트를 관리 대상 자산으로 만든다

Microsoft의 메시지는 노골적입니다. Agent 365는 에이전트의 control plane입니다. 공식 블로그는 Agent 365가 Microsoft AI로 만든 에이전트뿐 아니라 ecosystem partner agent까지 관측, 거버넌스, 보안 대상으로 삼는다고 설명합니다. 일반 제공은 5월 1일 시작됐고, 동시에 몇 가지 preview 기능이 공개됐습니다.

가장 눈에 띄는 부분은 로컬 에이전트와 shadow AI 탐지입니다. Microsoft는 Defender와 Intune을 이용해 Windows device에서 실행되는 local AI agent를 찾고 관리하는 기능을 설명했습니다. 예시로 OpenClaw agent가 먼저 언급됐고, 향후 GitHub Copilot CLI와 Claude Code 같은 널리 쓰이는 에이전트로 확장하겠다고 밝혔습니다. 이 문장은 중요합니다. 기업 보안팀 입장에서 Claude Code나 Copilot CLI는 더 이상 "개발자가 쓰는 도구"로만 남지 않습니다. 엔드포인트 위에서 권한을 가진 채 작업하는 에이전트이며, 따라서 inventory와 policy 대상이 됩니다.

두 번째 축은 multicloud registry sync입니다. Microsoft는 AWS Bedrock과 Google Cloud connection을 통한 Agent 365 registry sync를 public preview로 발표했습니다. 공식 이미지에는 Microsoft 365 admin center 안에서 Amazon Bedrock connection이 연결되고, Bedrock 쪽 에이전트 4개가 동기화된 화면이 보입니다. 의미는 단순합니다. Agent 365가 Microsoft 365 안의 Copilot 관리 콘솔에 머물지 않고, 경쟁 클라우드에서 만들어진 agent inventory까지 끌어오려 한다는 뜻입니다.

세 번째 축은 실행 환경입니다. Windows 365 for Agents는 public preview로 제공되며, 에이전트가 policy-controlled Cloud PC에서 작업하도록 하는 새로운 종류의 Cloud PC입니다. 데스크톱 앱과 레거시 업무 시스템은 여전히 많은 기업 워크플로의 중심입니다. API가 없는 시스템을 AI가 다루려면 브라우저나 데스크톱을 직접 조작해야 하고, 그 순간 보안팀은 "어디서 실행되는가"를 묻게 됩니다. Microsoft는 이 질문에 Windows 365와 Intune이라는 기존 관리 체계로 답하려 합니다.

가격도 제품의 성격을 보여줍니다. Agent 365는 Microsoft 365 E7에 포함되거나 standalone으로 사용자당 월 15달러에 제공됩니다. Microsoft가 과금 단위를 "에이전트 개수"가 아니라 에이전트를 관리하거나 후원하거나 사용하는 개인 단위로 잡은 것은 흥미롭습니다. 에이전트를 독립된 소프트웨어 자산으로 보면서도, 책임 단위는 여전히 조직 안의 사람과 연결하려는 설계입니다.

ServiceNow는 관제탑을 워크플로 안으로 끌어온다

ServiceNow의 AI Control Tower 확장은 같은 문제를 다른 각도에서 봅니다. ServiceNow는 발표에서 AI Control Tower가 discover, observe, govern, secure, measure 5개 차원으로 확장됐다고 설명했습니다. 30개 신규 enterprise integration, Traceloop 인수 기반의 runtime observability, NIST와 EU AI Act에 맞춘 risk framework, Veza access graph 기반 권한 제어, 비용과 ROI 대시보드가 함께 묶였습니다.

이 중 개발자와 플랫폼 팀이 주목할 부분은 observe와 secure입니다. ServiceNow는 Traceloop을 통해 AI agent behavior를 runtime에서 관측하고, 에이전트가 어떻게 reasoning하고 어디서 결정을 내리는지 볼 수 있다고 설명합니다. 이는 단순한 로그 수집 이상의 주장을 담고 있습니다. 에이전트가 실패했을 때 "모델이 이상한 답을 했다"가 아니라 "어떤 단계에서 어떤 도구와 권한을 사용하다가 문제를 만들었는가"를 추적해야 한다는 관점입니다.

Secure 축에서는 Veza의 access graph가 등장합니다. ServiceNow는 AI 시스템, 에이전트, identity 전반에 least privilege를 적용하고, 에이전트가 권한 밖으로 움직이면 실시간으로 탐지해 중단할 수 있다고 설명했습니다. The Register도 이 발표를 "kill switch" 관점에서 보도했습니다. 에이전트가 사람보다 빠르게 행동한다면, 차단 장치도 사람 승인 대기열보다 빨라야 합니다. 물론 이 주장은 실제 운영 환경에서 얼마나 정확히 탐지하고 오탐을 줄일 수 있는지 검증되어야 합니다.

ServiceNow의 강점은 업무 시스템에 이미 박혀 있다는 점입니다. Microsoft가 identity, endpoint, productivity suite에서 출발한다면, ServiceNow는 incident, approval, HR, ITSM, CMDB, workflow transaction의 맥락에서 출발합니다. 발표에 따르면 ServiceNow는 연간 1000억 개 workflow와 7조 개 workflow transaction이라는 운영 데이터를 강조합니다. 에이전트 관제에서 중요한 것은 단지 "에이전트를 보는 것"이 아니라 "그 에이전트가 어떤 업무 프로세스와 연결돼 있는지 아는 것"입니다. ServiceNow는 바로 이 지점에서 경쟁하려 합니다.

다만 출시 상태는 Microsoft와 다릅니다. AI Agent Advisor와 Intelligent Approvals는 2026년 5월 GA라고 발표됐지만, AI Control Tower enhancements는 5월 Innovation Lab에 들어가고 GA는 2026년 8월이 예상됩니다. 즉 지금의 발표는 방향성은 분명하지만, 모든 기능이 동일한 성숙도로 배포된 상태는 아닙니다.

Cisco는 문제를 non-human identity로 본다

Cisco의 Astrix Security 인수 의향 발표는 조금 다른 층위의 뉴스입니다. Cisco는 Astrix가 API key, service account, OAuth token 같은 modern system의 credential을 보호해온 회사라고 설명합니다. 그리고 바로 그 credential을 AI agent가 사용하고, 때로는 남용할 수 있다고 봅니다.

이 관점은 중요합니다. 에이전트 보안은 모델 입력 필터링이나 프롬프트 인젝션 방어만으로 끝나지 않습니다. 실제 업무를 수행하는 에이전트는 캘린더, 이메일, 코드 저장소, 배포 시스템, CRM, 결제 API, 데이터 웨어하우스에 접근합니다. 그 접근은 결국 credential과 permission으로 표현됩니다. 사람 계정이 아니기 때문에 MFA나 human approval만으로 설명되지 않는 영역이 생깁니다. Cisco는 이를 agentic workforce와 non-human identity 문제로 명명합니다.

Cisco는 Astrix의 역량을 discovery and governance, access and lifecycle management, threat detection and response, secrets management로 정리했습니다. 인수 완료 후 Cisco Identity Intelligence, Secure Access, Duo Identity and Access Management, Splunk 쪽으로 통합할 계획도 밝혔습니다. Microsoft Agent 365와 ServiceNow AI Control Tower가 "관제 화면과 운영 체계"에 가깝다면, Cisco의 접근은 "에이전트가 쓰는 신원과 자격 증명을 보안 스택에 편입"하는 쪽입니다.

세 발표를 함께 보면 구조가 보인다

이 비교에서 보이는 것은 제품명이 아니라 layer입니다. 에이전트 플랫폼은 적어도 네 층으로 나뉘고 있습니다. 첫째, 모델과 reasoning 계층입니다. OpenAI, Anthropic, Google, xAI, 오픈소스 모델이 경쟁합니다. 둘째, agent runtime과 tool execution 계층입니다. Codex, Claude Code, OpenClaw, Bedrock AgentCore, Windows 365 for Agents, Amazon WorkSpaces for AI agents가 여기에 들어갑니다. 셋째, identity와 permission 계층입니다. Entra, Duo, service account, OAuth token, access graph, secrets management가 핵심입니다. 넷째, control plane과 observability 계층입니다. Agent 365와 AI Control Tower가 이 자리를 노립니다.

초기 에이전트 시장은 첫째와 둘째 층에 집중했습니다. 얼마나 똑똑한가, 얼마나 오래 작업할 수 있는가, 얼마나 많은 도구를 쓸 수 있는가가 뉴스가 됐습니다. 하지만 실제 기업 배포에서는 셋째와 넷째 층이 먼저 막힙니다. 어떤 에이전트가 프로덕션 데이터에 접근했는지 모르면 감사할 수 없습니다. 에이전트가 다른 에이전트를 호출하거나 SaaS workflow를 건드릴 때 identity boundary가 없으면 책임 소재가 흐려집니다. 비용과 ROI가 보이지 않으면 파일럿은 늘어나도 예산은 막힙니다.

개발팀에는 새로운 배포 체크리스트가 생긴다

AI 팀이나 플랫폼 엔지니어에게 이 흐름은 현실적인 요구사항으로 돌아옵니다. 앞으로 "에이전트를 배포했다"는 말은 endpoint 하나를 열었다는 뜻으로 부족합니다. 최소한 다음 질문에 답해야 합니다.

에이전트는 조직의 어느 registry에 등록되는가. 소유자는 누구인가. 사람을 대신해 delegated access로 행동하는가, 아니면 자체 credential과 permission을 가진 독립 행위자인가. 접근 가능한 데이터와 도구는 무엇인가. 실행 로그와 reasoning trace는 어디에 남는가. 정책 위반이나 prompt injection 의심 상황에서 어떤 시스템이 차단하는가. 사용량과 비용은 어떤 단위로 측정되는가. 퇴사자, 프로젝트 종료, 모델 교체, agent decommissioning 때 권한은 어떻게 회수되는가.

이 질문들은 예전에는 보안팀이나 IT 운영팀의 언어처럼 들렸습니다. 이제는 agent developer의 설계 입력이 됩니다. tool calling schema를 만들 때도 scope와 auditability를 고려해야 하고, MCP server를 붙일 때도 어떤 identity로 호출되는지 명확해야 합니다. Claude Code나 Codex 같은 코딩 에이전트를 사내에서 허용할 때도 단순히 "생산성이 오른다"가 아니라 "로컬에서 어떤 명령을 실행하고 어떤 저장소와 secret에 접근하는가"를 설명해야 합니다.

특히 shadow AI 문제는 개발조직에서 먼저 터질 가능성이 큽니다. 개발자는 새 CLI와 에디터 플러그인을 가장 빨리 도입합니다. 보안팀이 공식 플랫폼을 준비하기 전에 로컬 에이전트가 이미 코드베이스, 터미널, 브라우저, 사내 문서에 접근하고 있을 수 있습니다. Microsoft가 OpenClaw, GitHub Copilot CLI, Claude Code 같은 이름을 직접 언급한 이유도 여기에 있습니다. 이 도구들은 개인 생산성 도구이면서 동시에 기업 보안 표면입니다.

회의론도 필요하다

물론 control plane이라는 말이 모든 문제를 해결하지는 않습니다. 에이전트 관제 제품에는 몇 가지 어려운 질문이 남습니다. 첫째, discovery의 정확도입니다. 에이전트는 브라우저 확장, CLI, SaaS bot, workflow automation, 커스텀 서버리스 함수 등 다양한 형태로 숨어 있을 수 있습니다. 제품이 말하는 "agent inventory"가 실제 조직의 전체 agent surface를 얼마나 포착하는지는 검증해야 합니다.

둘째, 권한 모델의 현실성입니다. 에이전트가 사람 대신 행동할 때 delegated access만으로 충분한 경우가 있고, 에이전트 자체 credential이 필요한 경우도 있습니다. Microsoft는 두 유형을 모두 언급했습니다. 하지만 실제 운영에서는 둘의 경계가 흐려집니다. 예를 들어 코딩 에이전트가 개발자 계정의 GitHub 권한으로 PR을 만들고, CI secret을 읽고, 배포 로그를 분석한다면 이는 사람의 권한인가 에이전트의 권한인가. 감사 로그는 누구의 행동으로 남아야 하는가.

셋째, 벤더 종속성입니다. Microsoft는 AWS Bedrock과 Google Cloud registry sync를 강조하지만, control plane이 특정 생산성·보안 스택에 깊게 묶일수록 조직은 해당 벤더의 agent ontology를 따라가게 됩니다. ServiceNow도 workflow와 CMDB 맥락을 강점으로 삼지만, 그 강점은 동시에 ServiceNow 중심 운영 모델을 전제합니다. Cisco의 identity 접근도 기존 Cisco 보안 스택과의 결합이 핵심입니다. 표준화가 충분히 성숙하기 전에는 여러 관제 계층이 서로 중복될 수 있습니다.

넷째, kill switch의 오탐과 책임입니다. 에이전트를 실시간으로 멈추는 기능은 매력적이지만, 어떤 근거로 멈췄는지 설명할 수 있어야 합니다. 고객 응대, 보안 대응, 배포 자동화처럼 시간이 중요한 workflow에서 에이전트를 잘못 차단하면 그것도 장애가 됩니다. 반대로 늦게 차단하면 권한 남용과 데이터 유출 위험이 커집니다. 관제 제품은 결국 정책 언어, risk scoring, human approval, rollback 전략까지 포함해야 합니다.

그래도 방향은 분명하다

이번 주의 세 발표가 말하는 큰 방향은 분명합니다. 기업용 AI 에이전트는 "더 강한 모델을 붙인 챗봇" 단계에서 벗어나고 있습니다. 이제 에이전트는 조직 안에서 권한을 가진 실행 주체입니다. 그렇다면 IAM, endpoint management, observability, CMDB, cost governance, incident response가 모두 에이전트 세계로 들어와야 합니다.

개발자에게 좋은 소식은 이 변화가 에이전트 도입을 막기 위한 것만은 아니라는 점입니다. 오히려 제대로 된 관제와 신원 체계가 있어야 더 위험한 일을 에이전트에게 맡길 수 있습니다. 오늘의 로컬 코딩 보조는 내일의 PR 리뷰어, 배포 조사자, 보안 패치 생성자, 고객 지원 자동화가 됩니다. 그때 필요한 것은 더 긴 프롬프트만이 아니라, 누가 무엇을 할 수 있는지 명확히 제한하고 추적하는 운영 구조입니다.

Microsoft Agent 365 GA는 이 시장이 더 이상 실험실 단계가 아니라는 신호입니다. ServiceNow AI Control Tower 확장은 업무 프로세스 안에서 에이전트를 관측하고 멈추려는 시도입니다. Cisco의 Astrix 인수 의향은 에이전트 보안의 핵심이 non-human identity로 이동하고 있음을 보여줍니다. 서로 다른 출발점이지만 결론은 같습니다. AI 에이전트 시대의 다음 병목은 intelligence가 아니라 control입니다.

그래서 앞으로 몇 달 동안 봐야 할 뉴스는 새 agent demo만이 아닙니다. 어떤 벤더가 agent registry의 사실상 표준을 잡는지, MCP와 OAuth, enterprise IAM이 어떻게 연결되는지, 로컬 코딩 에이전트가 보안 정책 안으로 어떻게 들어오는지, 그리고 실제 기업이 비용과 위험을 어떤 지표로 측정하는지가 더 중요해질 것입니다. 에이전트가 많아질수록 에이전트를 만드는 기술보다 에이전트를 책임 있게 운영하는 기술이 더 큰 시장이 됩니다.