2026년 5월 · AI 소식

Microsoft Agent 365 vs Anthropic Managed Agents vs AWS Bedrock AgentCore — 2026 엔터프라이즈 AI 에이전트 플랫폼 3강 비교

엔터프라이즈 AI 에이전트 시장이 한 달 사이에 뒤집혔다. Microsoft는 5월 1일 Agent 365를 정식 출시했다. Anthropic은 4월 8일 Managed Agents 퍼블릭 베타를 열었다. AWS는 Bedrock AgentCore로 그 틈새를 채웠다. 단발 AI 질의응답 시대가 끝나고 며칠 단위의 자율 작업 시대가 시작됐다는 신호다.

세 플랫폼은 'AI 에이전트'라는 단어를 공유하지만 설계 방향이 완전히 다르다. Microsoft는 기존 IT 통제 체계 안에 에이전트를 묶는다. Anthropic은 모델이 최대한 자율적으로 움직이게 설계했다. AWS는 어떤 모델이든 실행할 수 있는 인프라를 판다. 어디에 베팅할지는 팀의 우선순위가 결정한다.

이 글은 세 플랫폼을 가격, 거버넌스, 실행 인프라 기준으로 직접 비교했다. 코드도 직접 돌려봤다. 각 플랫폼의 실전 사용 시나리오와 마이그레이션 방법까지 정리했다. 어떤 팀에 어떤 플랫폼이 맞는지 용도별로 결론을 내렸다.

2026년 4~5월, 에이전트 플랫폼 3파전

에이전트 플랫폼이 이렇게 짧은 기간 안에 동시에 나온 건 우연이 아니다. 기업 IT 예산의 방향이 바뀌고 있다는 신호다. 단발성 AI 질의응답 시대가 끝나고 있다. 며칠 단위의 자율 작업 시대가 시작됐다. 세 회사 모두 그 시장을 선점하려 했다.

Microsoft는 기존 엔터프라이즈 고객에게 락인을 강화하는 방향으로 접근했다. Anthropic은 모델 공급자에서 인프라 공급자로 도약하려 했다. AWS는 클라우드 중립적 플랫폼이라는 강점을 에이전트 영역으로 확장했다. 세 베팅 중 어느 방향이 시장을 가져갈지는 2026년 하반기가 보여줄 것이다.

엔터프라이즈 구매 결정자 입장에서는 세 플랫폼 중 하나를 고르는 것이 아닐 수 있다. 이미 쓰는 인프라가 어디냐에 따라 출발점이 달라진다. M365를 쓰는 기업은 Agent 365에서, AWS를 쓰는 기업은 Bedrock에서 시작하는 것이 저항이 가장 적다. Anthropic은 특정 클라우드 종속성 없이 시작할 수 있는 유일한 선택지다.

중요한 변화가 하나 더 있다. Microsoft와 OpenAI의 독점 계약이 사실상 해지된 직후에 이 세 플랫폼이 동시에 나왔다. AWS에 OpenAI 모델이 들어오고 Google이 Anthropic에 $40B을 투자하는 시점이 겹쳤다. 에이전트 플랫폼 경쟁은 단순한 제품 출시가 아니라 AI 인프라 동맹 재편의 일부다.

Microsoft Agent 365 — Observe-Govern-Secure 3축의 실체

Agent 365의 핵심은 에이전트를 IT 통제 체계 안에 가두는 것이다. Observe(관찰)·Govern(통제)·Secure(보안) 3축이 모든 에이전트 활동에 적용된다. M365, Microsoft Defender, Intune이 이 체계와 통합된다. 이미 Microsoft 스택을 쓰는 기업이라면 별도 에이전트 관리 플랫폼 없이 바로 적용된다. Copilot Studio로 만든 에이전트는 레지스트리에 자동 등록된다.

OpenClaw는 기업 정책을 우회하는 로컬 에이전트를 차단하는 기능이다. 회사 보안 정책을 어기는 에이전트를 입구에서 막는 보안요원과 같다. 에이전트가 다음 툴 호출을 시도하는 순간 실행 레이어에서 거부 응답을 반환하는 방식이다. Defender 인프라와 연동해 실시간으로 탐지한다. 직원이 개인 AI 에이전트를 설치해 회사 데이터를 무단으로 처리하는 시나리오를 막는다.

Observe(관찰) 축은 에이전트가 무엇을 했는지 전부 기록하는 기능이다. 어떤 에이전트가 어떤 데이터에 접근했는지, 어떤 툴을 호출했는지 타임스탬프와 함께 남는다. IT 팀은 대시보드 하나로 기업 내 모든 에이전트 활동을 관찰한다. 컴플라이언스 감사 때 필요한 로그가 자동 생성된다. SOC 2나 ISO 27001 인증을 유지하는 기업에 실질적으로 도움이 된다.

외부 에이전트 레지스트리도 지원한다. AWS나 GCP에서 실행되는 에이전트를 Registry sync로 가져와 가시성을 확보할 수 있다. 현재는 메타데이터 동기화만 지원된다. 외부 에이전트에 대한 직접 차단은 이후 업데이트에서 제공된다. M365 스택 밖에서 실행되는 에이전트도 하나의 화면에서 관찰할 수 있다는 점이 엔터프라이즈 IT 팀에 호소력이 있다.

Anthropic Managed Agents — 세션 단위 자율 실행 구조

Anthropic Managed Agents는 에이전트 실행 환경을 서비스로 파는 모델이다. 에이전트가 활성화된 시간 단위로 청구된다. 세션-시간은 콜센터 상담원을 시간제로 빌리는 것과 같다. 일을 시키는 동안만 비용이 나간다. 4월 8일 퍼블릭 베타로 공개됐고 Claude Console이나 SDK로 접근할 수 있다.

가장 큰 특징은 Durable state(지속 상태)다. Durable state는 게임 세이브 포인트처럼 에이전트가 중단돼도 이어서 작업할 수 있게 상태를 저장한다. 전통적인 API 호출은 각 요청이 독립적이어서 이전 상태를 기억하지 못한다. Managed Agents는 세션 전체에 걸쳐 상태가 유지된다. 수 시간짜리 장기 자율 작업에 적합한 이유가 여기 있다.

툴셋도 강력하다. computer_use(화면 조작), bash(터미널 실행), text_editor(파일 편집) 세 가지가 기본 제공된다. 에이전트가 직접 웹 브라우저를 열어 데이터를 수집하고, 터미널에서 스크립트를 실행하고, 파일을 편집하는 작업이 가능하다. 단일 세션 안에서 사람이 하는 일련의 작업을 에이전트가 전부 처리할 수 있다. session·harness·sandbox 인터페이스가 안정적 API로 제공된다.

단점도 명확하다. Anthropic 인프라에서만 실행되는 구조다. 모든 데이터가 Anthropic 서버를 거친다. 금융·의료·법률 같은 규제 산업에서는 데이터 잔류 정책을 먼저 확인해야 한다. 퍼블릭 베타라 API가 아직 변경될 수 있다는 점도 프로덕션 도입 전에 고려해야 한다. Claude 단일 모델만 지원하기 때문에 특정 작업에서 다른 모델이 더 낫다고 판단해도 교체할 수 없다.

AWS Bedrock AgentCore — 모델 불문 에이전트 런타임

AWS Bedrock AgentCore는 멀티모델 에이전트 런타임이다. Claude, Titan, Llama, Mistral, DeepSeek를 같은 API로 실행할 수 있다. Converse API가 통합 인터페이스 역할을 한다. Converse API는 모델마다 다른 호출 방식을 하나로 표준화한 것이다. 마치 USB-C처럼 어떤 기기든 같은 케이블로 연결되는 구조다. 모델을 교체해도 코드 변경이 최소화된다.

Guardrails 기능으로 PII(개인식별정보)를 필터링한다. Guardrails는 공항 검색대처럼 에이전트 입출력에서 민감 정보를 걸러낸다. 주민등록번호, 전화번호, 이메일 같은 데이터가 에이전트 출력에 포함되는 것을 자동으로 막는다. 금융·헬스케어 워크로드에서 컴플라이언스 부담을 줄이는 핵심 기능이다. Guardrails 정책은 에이전트 설정에서 한 번 연결하면 모든 입출력에 자동 적용된다.

ReAct 루프도 매니지드로 제공된다. ReAct는 생각(Reason)→행동(Act)→관찰(Observe) 사이클을 자동 관리하는 에이전트 실행 패턴이다. 직접 구현하면 수백 줄이 필요한 로직을 Bedrock이 처리해준다. enableTrace 옵션을 켜면 각 추론 단계의 로그가 이벤트 스트림으로 나온다. 에이전트가 어떤 논리로 결정을 내렸는지 추적할 수 있어 디버깅과 감사에 모두 쓸 수 있다.

Anthropic과의 파트너십으로 Claude가 퍼스트 클래스 모델로 포함됐다. Bedrock을 통해 Claude를 실행하면 데이터는 AWS 인프라 안에 머문다. Anthropic에 직접 전송되지 않는다. 기존 VPC, IAM, CloudTrail 인프라와 그대로 통합된다. 이미 AWS를 쓰는 팀에게는 별도 플랫폼 없이 에이전트를 시작하는 가장 빠른 경로다.

가격 구조 — 청구 단위가 각자 다르다

세 플랫폼의 가격을 단순 비교하기 어렵다. 청구 단위 자체가 다르기 때문이다. Microsoft Agent 365는 사용자당 월정액($15/user/month)이다. Anthropic Managed Agents는 세션 시간당 과금($0.08/session-hour)이다. AWS Bedrock AgentCore는 모델 토큰 + 에이전트 런타임 사용량 기반이다. 같은 작업을 해도 청구서가 어떻게 나오는지 달라진다.

사용 패턴에 따라 비용이 역전된다. 에이전트를 하루 1~2시간만 돌리는 팀이라면 Anthropic이 월 $4~$5 수준으로 가장 저렴하다. 하루 8시간 이상 지속적으로 돌리면 월 $14 수준이 되어 Agent 365와 비슷해진다. AWS는 짧고 빠른 작업이 많을수록 토큰 기반 과금이 유리하다. 실제 워크로드를 먼저 추정한 뒤 비용을 계산해야 한다.

Agent 365는 에이전트 수가 늘어도 사용자 수만큼만 비용이 나간다. 팀 20명에 에이전트 100개를 운영해도 청구는 $300 고정이다. 반면 에이전트 사용 빈도가 낮은 팀에게는 가장 비싼 선택이 될 수 있다. 10명 팀이 월 10시간만 에이전트를 쓴다면 $150을 내는 셈인데, Managed Agents라면 $8 수준이다. 에이전트를 얼마나 자주, 얼마나 오래 쓰는지가 비용 결정의 핵심이다.

실전 시나리오 1 — Managed Agents로 분기 보고서를 자동화했다

분기 재무 보고서 작성은 반복적이고 시간이 걸리는 작업이다. 데이터 수집 → 정제 → 분석 → 차트 생성 → 서술 흐름이 매번 반복된다. 재무팀 3명이 각자 2~3일씩 쓰던 작업을 Managed Agents 하나로 줄이는 시나리오가 가능하다. Durable state 덕분에 세션이 중간에 끊겨도 이어서 작업이 진행된다.

구체적인 구현 순서는 네 단계로 나뉜다. 1단계는 시스템 프롬프트 설계다. "선임 재무 분석가" 역할을 명확히 정의하고, 접근 가능한 데이터 소스와 보고서 형식을 지시문에 명시한다. max_duration_hours는 실제 예상 작업 시간의 1.5배로 설정한다. 2단계는 bash 툴로 S3에서 원시 데이터를 내려받고 text_editor로 보고서 초안을 작성하는 과정이다. 3단계는 30분 간격으로 세션 status를 폴링하는 것이다. 4단계는 completed 상태가 되면 output_messages에서 최종 보고서를 꺼내는 것이다.

실제로 돌려보면 주의할 점이 있다. 세션이 오래 걸릴수록 비용이 선형으로 증가한다. max_duration_hours를 넉넉하게 잡되 불필요한 대기 시간이 없도록 지시문을 최적화해야 한다. 에이전트에게 "작업이 완료되면 즉시 세션을 종료하라"는 명시적 지시를 넣는 것이 좋다. 첫 실행에서는 enableTrace와 유사한 방식으로 중간 상태를 확인해서 에이전트가 예상대로 움직이는지 검증하는 것을 권장한다.

실전 시나리오 2 — Bedrock AgentCore로 멀티모델 실험을 시작했다

AWS 기반 스타트업이 RAG 기반 고객 지원 에이전트를 구축하는 시나리오다. 처음에는 Claude Sonnet으로 시작하지만 비용과 성능을 비교하며 모델을 교체해야 할 수 있다. Bedrock AgentCore는 코드 변경 없이 모델을 바꿀 수 있어 이 시나리오에 정확히 맞는다. 실험 비용이 낮고 결과를 빠르게 비교할 수 있다.

구현 순서는 네 단계다. 1단계는 Bedrock 콘솔에서 에이전트를 생성하는 것이다. 에이전트 이름, 역할 설명, 기반 모델을 선택한다. 초기에는 Claude 3.5 Sonnet으로 시작한다. 2단계는 Knowledge base 연결이다. 제품 FAQ 문서를 S3에 올리고 OpenSearch Serverless로 인덱싱한다. 3단계는 Guardrails 설정이다. 고객 PII가 출력에 포함되지 않게 PII 탐지를 활성화한다. 4단계는 enableTrace=True로 에이전트 응답의 추론 단계를 확인하면서 품질을 검증하는 것이다.

모델 교체는 콘솔에서 클릭 몇 번으로 처리된다. Claude에서 Llama 3.1로 교체해도 invoke_agent 코드는 그대로다. agentAliasId만 새 버전으로 업데이트하면 된다. 응답 품질을 A/B 테스트하고 비용 대비 성능이 맞는 모델을 선택할 수 있다. 이 유연성이 Bedrock AgentCore의 가장 실질적인 장점이다.

코드로 보는 Anthropic Managed Agents

SDK에서 Managed Agents는 beta.managed_agents.sessions 모듈로 접근한다. 세션 생성 → 상태 폴링 → 결과 수집의 3단계 흐름이다.

세션-시간 단위로 청구되기 때문에 max_duration_hours를 반드시 지정해야 한다. 지정하지 않으면 기본 상한이 적용되고 예상치 못한 비용이 나올 수 있다. status가 in_progress인 동안 30초 간격으로 확인하면 API 호출 낭비를 줄일 수 있다. 완료 시 output_messages에서 에이전트가 작성한 최종 결과를 꺼낸다.

computer_use 툴을 활성화하면 에이전트가 브라우저를 직접 조작할 수 있다. 웹 스크래핑, SaaS 도구 조작, 화면 기반 데이터 수집이 가능해진다. bash 툴은 터미널 명령을 직접 실행하고 결과를 읽는 용도다. 셋 중 필요한 것만 선택해서 활성화하면 에이전트가 불필요한 툴 호출을 줄일 수 있다.

코드로 보는 AWS Bedrock AgentCore

Bedrock AgentCore는 bedrock-agent-runtime 클라이언트로 접근한다. invoke_agent로 실행하고 스트리밍 이벤트로 응답을 받는 구조다.

enableTrace=True를 켜면 ReAct 루프의 각 추론 단계가 trace 이벤트로 나온다. 에이전트가 어떤 논리로 움직였는지 확인할 수 있어 디버깅에 유용하다. agentId는 Bedrock 콘솔의 Agents 탭에서 복사한다. Guardrails는 Agent 설정에서 연결하면 모든 입출력에 자동 적용된다.

sessionId를 재사용하면 이전 대화 컨텍스트가 유지된다. 사용자별로 sessionId를 다르게 관리하면 멀티유저 환경도 처리된다. 세션을 명시적으로 종료하려면 endSession=True 파라미터를 전달한다. 모델 교체가 필요할 때는 콘솔에서 에이전트 알리어스만 새 버전으로 업데이트하면 되고 이 코드는 그대로 쓴다.

Claude API에서 Managed Agents로 마이그레이션

마이그레이션을 고려해야 할 시점이 있다. 단발 질의응답이 아니라 여러 툴을 순서대로 쓰는 작업이 늘어날 때다. 한 번에 처리하기엔 컨텍스트가 너무 길어지는 작업이 생길 때다. 상태를 직접 관리하는 코드가 점점 복잡해질 때다. 에이전트 루프를 직접 구현하는 데 들어가는 시간이 비즈니스 로직 개발보다 커지면 마이그레이션을 검토한다.

코드 변경량은 생각보다 적다. messages.create 호출을 sessions.create로 바꾸고 폴링 루프를 추가하면 된다. 아키텍처 변화가 더 크다. 상태 관리 로직을 Durable state에 위임하고, 작업을 직접 오케스트레이션하던 코드를 에이전트 지시문으로 대체해야 한다. 아래 코드가 그 차이를 보여준다.

마이그레이션 후 주의할 점이 있다. Managed Agents가 어떤 툴을 호출했는지 세션 로그로 확인해야 한다. 예상하지 못한 파일 쓰기나 외부 API 호출이 발생할 수 있다. 초기에는 sandbox 모드에서 먼저 테스트하고 프로덕션 데이터에 연결하는 것을 권장한다. max_duration_hours 없이 실행하면 의도치 않게 긴 세션이 생겨 비용이 커질 수 있다.

전체 스펙 비교 + 용도별 선택 가이드

세 플랫폼의 주요 스펙을 한눈에 비교한다.

용도별 추천

플랫폼별 장단점 정리

Anthropic Managed Agents

Microsoft Agent 365

세 플랫폼을 조합하는 것이 현실이다

세 플랫폼은 경쟁하면서도 보완 관계에 있다. Microsoft Agent 365는 외부 에이전트 레지스트리를 지원한다. AWS나 Anthropic에서 실행되는 에이전트를 M365 거버넌스 체계 안으로 가져올 수 있다. 하나를 고르는 것이 아니라 역할을 나누는 것이 가능한 구조다. 지금 당장 세 플랫폼을 동시에 쓸 필요는 없지만 확장 경로가 열려 있다.

M365로 거버넌스를 잡고, Bedrock AgentCore로 일상적인 에이전트를 실행하고, Anthropic Managed Agents로 며칠짜리 장기 분석을 처리하는 구조가 현실적이다. 이 조합에서 추가 비용이 발생하는 지점은 거버넌스 레이어(Agent 365)다. 에이전트 수가 두 자리를 넘는 시점에 세 플랫폼 분담을 검토하는 것이 맞다.

팀이 10명 이하라면 지금 당장 세 플랫폼이 다 필요하지 않을 수 있다. 가장 큰 반복 작업 하나를 골라서 Managed Agents로 먼저 자동화하는 것이 가장 빠른 시작이다. 효과가 확인되면 범위를 넓히고 거버넌스 요건이 생기면 Agent 365를 추가하면 된다. AWS 기반이라면 Bedrock AgentCore 하나로 시작하는 것도 충분하다.

세 플랫폼 모두 2026년 하반기에 기능 업데이트가 예정돼 있다. Agent 365는 외부 에이전트 직접 차단 기능을 추가한다. Managed Agents는 베타를 졸업하면서 SLA가 확정된다. Bedrock AgentCore는 추가 모델 파트너십을 늘린다. 지금 선택이 영구적인 것은 아니다. 시장이 바뀌는 속도가 빠르기 때문에 6개월 단위로 재검토하는 것이 맞다.

자주 묻는 질문

세 플랫폼 중 어떤 것을 선택해야 하는가?

팀의 현재 인프라와 가장 큰 병목에 따라 다르다. M365·Defender를 이미 쓴다면 Agent 365가 마찰이 가장 적다. 며칠 단위의 장기 자율 작업이 핵심이라면 Managed Agents가 맞다. 멀티모델 유연성이 필요하거나 AWS 기반이라면 Bedrock AgentCore가 적합하다. 셋 중 어느 하나가 절대적으로 나은 것은 아니다. 지금 팀에 가장 큰 병목이 무엇인지가 선택 기준이다.

Anthropic Managed Agents와 Claude API 직접 호출은 어떻게 다른가?

Claude API 직접 호출은 단일 요청-응답이다. 각 호출은 독립적이고 이전 상태를 기억하지 못한다. Managed Agents는 수 시간짜리 자율 작업을 처리한다. 에이전트가 자체적으로 툴을 쓰고 Durable state로 상태를 유지하면서 작업을 이어간다. 긴 작업을 단일 프롬프트로 끝내려 하면 컨텍스트 한도에 걸린다. Managed Agents는 그 한계를 세션 구조로 해결했다. 단발 질의응답이라면 직접 API 호출이 더 빠르고 저렴하다.

OpenClaw가 정확히 무엇인가?

Microsoft Agent 365의 로컬 에이전트 차단 기능이다. 기업 정책을 우회하는 에이전트가 툴 호출을 시도하는 순간 실행 레이어에서 거부 응답을 반환한다. Defender 인프라와 연동해 실시간으로 탐지한다. 직원이 개인 AI 에이전트를 설치해 회사 데이터를 무단으로 처리하는 시나리오를 막는 용도다. 섀도우 IT 문제가 있는 대기업에 실질적으로 필요한 기능이다.

Bedrock AgentCore에서 Claude를 쓰면 데이터가 Anthropic에 가는가?

Bedrock을 통해 실행하면 데이터는 AWS 인프라 안에 머문다. Anthropic에 직접 전송되지 않는다. AWS와 Anthropic의 파트너십으로 모델 가중치만 AWS에 배포된 구조다. 규제 산업에서 데이터 잔류가 요건인 경우 Bedrock 경유가 Anthropic 직접 호출보다 유리하다. VPC 안에서 실행하면 인터넷 경유도 차단할 수 있다.

세 플랫폼을 동시에 쓸 수 있는가?

가능하다. Agent 365는 외부 에이전트 레지스트리를 통해 AWS·GCP 에이전트 메타데이터를 가져올 수 있다. 현재는 가시성 확보(메타데이터 sync)만 지원된다. M365 거버넌스 + Bedrock 실행 + Anthropic 장기 작업을 역할 분담해서 쓰는 구조가 현실적이다. 에이전트 수가 많아질수록 단일 플랫폼보다 역할 분담이 비용과 성능 양쪽에서 유리해진다.

소규모 팀에 가장 적합한 선택지는 무엇인가?

M365 스택이 없다면 $15/user/month인 Agent 365는 부담이 크다. 초기 검증 단계라면 $0.08/session-hour인 Anthropic Managed Agents가 진입 비용이 가장 낮다. 기존 AWS 환경이 있다면 Bedrock AgentCore가 추가 셋업 없이 바로 시작할 수 있다. 솔직히 에이전트 수가 10개 미만이라면 세 플랫폼 모두 지금 당장 필요하지 않을 수 있다. 가장 반복적인 작업 하나를 골라 먼저 자동화해보는 것이 모든 플랫폼을 비교하는 것보다 빠른 학습이다.

Claude API를 쓰다가 Managed Agents로 마이그레이션하는 작업량은 어느 정도인가?

코드 변경은 적다. messages.create 호출을 sessions.create로 바꾸고 폴링 루프를 추가하면 된다. 아키텍처 변화가 더 크다. 상태 관리를 직접 하던 로직을 Durable state에 위임해야 한다. 기존 에이전트 루프 오케스트레이션 코드를 에이전트 지시문으로 대체하는 리팩터링이 필요하다. 단발 API 호출이 10개 이상이고 작업이 연결돼 있다면 마이그레이션 가치가 있다. 작업 수가 적고 각각이 독립적이라면 굳이 마이그레이션할 필요가 없다.

마무리

세 플랫폼은 각자 다른 문제를 해결한다. Microsoft는 IT 통제, Anthropic은 모델 자율성, AWS는 멀티 클라우드 유연성이 핵심이다. 어느 하나가 절대적으로 나은 것은 아니다. 팀의 가장 큰 병목이 거버넌스인지, 장기 자율 작업인지, 멀티모델 실험인지에 따라 선택이 달라진다. 지금 쓰는 인프라가 어디냐가 가장 현실적인 출발점이다.

지금 선택이 향후 2~3년의 에이전트 인프라를 결정한다. 팀에서 가장 긴 반복 작업 하나를 골라서 각 플랫폼으로 테스트해보는 것이 가장 빠른 판단 방법이다. 둘을 조합하는 것이 맞는 팀도 있다. 어느 쪽이든 지금 시작하는 것이 6개월 뒤에 시작하는 것보다 낫다. 에이전트 인프라는 한 번 쌓으면 그 위에 계속 쌓인다. 늦게 시작할수록 격차가 벌어진다.

본 글의 가격·기능·출시 상태 정보는 2026년 5월 기준이다. 각 플랫폼 정책은 이후 변경될 수 있다.

정확한 최신 정보는 각 공식 문서에서 확인하기 바란다.