Agent 365 SDK: 어떤 에이전트든 ‘엔터프라이즈 레디’로 만든다
에이전트를 만드는 일은 쉬워졌지만, 조직 전체에 신뢰할 수 있게 확장하는 일은 여전히 어렵습니다. 엔터프라이즈 도입의 가장 큰 장벽은 중앙집중식 통제의 부재입니다. 에이전트를 널리 배포하기 전에 조직은 명확한 답을 원합니다 — 이 에이전트는 무엇을 할 수 있는가? 어떤 데이터에 접근하는가? 어떻게 모니터링되는가? 문제가 생기면 어떻게 개입하는가?
지금까지 개발자들은 아이덴티티·런타임 보호·관찰성을 여러 솔루션과 오픈소스로 짜깁기해 왔습니다. 그 결과는 파편화된 정책 관리, 단절된 모니터링, 확장하기 어려운 운영 부담이었습니다. 이번에 발표된 Agent 365 SDK는 이 흩어진 능력들을 하나의 컨트롤 플레인으로 묶습니다.
이 글의 한 줄 요약 5월 1일 GA된 Agent 365는 에이전트를 대규모로 관찰·거버넌스·보안하는 컨트롤 플레인입니다. Agent Builder·Copilot Studio·Foundry로 만든 에이전트는 자동 적용되고, 외부 플랫폼·오픈소스로 만든 에이전트는 Agent 365 SDK로 동일한 통제를 받을 수 있습니다. Python·TypeScript·.NET로 지금 사용 가능합니다.
무엇이 새로운가: 외부 에이전트를 위한 ‘진입로’
Microsoft AI 플랫폼(Agent Builder, Copilot Studio, Microsoft Foundry)으로 만든 에이전트는 추가 개발 없이 Agent 365 기능을 자동으로 얻습니다. 반면 외부 플랫폼이나 오픈소스 프레임워크로 만든 에이전트에게 Agent 365 SDK가 그 진입로를 제공합니다.
- SDK: 엔터프라이즈급 관찰성·거버넌스·보안을 부여
- Agent 365 CLI: 에이전트 아이덴티티를 프로비저닝하고 첫날부터 Agent 365에 등록
예를 들어 Microsoft Foundry로 만든 백오피스 에이전트와 OpenAI Agents SDK로 만든 고객 대면 에이전트를, 어떤 플랫폼·프레임워크에서 돌든 동일한 아이덴티티 모델·관찰성 신호·정책 엔진으로 함께 관리할 수 있습니다.
Agent 365 SDK가 제공하는 것
관찰성(Observability)
- 통합 에이전트 레지스트리 — SDK로 등록한 모든 에이전트가 한 레지스트리에 나타나, 소유권·사용량·연결된 도구·지식 원본·권한을 한눈에 파악. 관리되지 않는 로컬 에이전트도 동일 컨트롤 플레인에서 표면화
- Defender의 SOC 가시성 — 보안 운영 센터가 Microsoft Defender 텔레메트리로 에이전트 활동을 헌팅하고, 전체 에이전트 플릿의 취약점·위험을 조사
거버넌스(Governance)
- 에이전트 수명주기 관리 — 규칙 기반 정책으로 비활성 에이전트 자동 만료, 소유자 없는 에이전트 플래그, 위험 에이전트 차단
- 온보딩·거버넌스 — 권한·정책·검토가 끝난 뒤에만 특정 사용자·그룹에 배포. 필요 시 차단·해제·제거
- 정책 템플릿 — Entra·Purview·Defender·SharePoint의 기존 정책을 재사용 가능한 템플릿으로 묶어 승인·온보딩 시 자동 적용
- 도구 제어 — 테넌트 전반에서 도구를 보기/허용/차단해, 에이전트별 설정 없이 승인된 도구만 사용
보안(Security)
- Entra 기반 에이전트 아이덴티티 — SDK가 Entra에 에이전트 아이덴티티를 생성해, 사용자와 동일한 방식으로 정책·역할을 적용
- 액세스 제어 — Entra 조건부 액세스·Identity Protection으로 런타임 보호
- Defender 위협 탐지 — 에이전트 활동이 나머지 환경과 함께 Defender에 표면화되고, SOC가 쓰는 동일 인시던트 파이프라인으로 연결
- 도구 호출 위협 차단 — Agent 365에 등록한 도구의 호출·응답을 Defender 런타임 보호가 감싸, 고위험 호출을 실행 전 차단
누가 어떻게 쓰고 있나
이미 많은 소프트웨어 기업이 Agent 365 SDK를 통합했으며, 크게 세 부류입니다.
- AI 네이티브 SW 벤더 — 고객 대면 에이전트 구축 (Genspark, Zensai, Egnyte, Zendesk 등)
- 에이전트 플랫폼/’에이전트 팩토리’ — 고객이 직접 에이전트를 빌드·운영 (Kore.ai, Kasisto, n8n 등)
- 자체 내부 에이전트를 개발하는 엔터프라이즈
세 부류 모두 같은 이유로 통합합니다. 이 에이전트들이 기업에 배포되면, 조직은 추가 작업 없이 핵심 기능(관찰·거버넌스·보안)을 즉시 적용할 수 있고, 데이터 보안·컴플라이언스 같은 고급 시나리오는 필요 시 Microsoft Purview API로 더할 수 있습니다.
“기업은 오늘날 AI 에이전트를 쉽게 만들 수 있지만, 신뢰와 거버넌스를 갖춰 확장하는 단계에서 대부분 멈춥니다. Kore.ai가 Microsoft Agent 365에 깊이 통합되면서 아이덴티티·보안·거버넌스가 처음부터 내장되어, 기업이 파일럿에서 대규모 AI로 자신 있게 나아갈 수 있습니다.” — Raj Koneru, CEO, Kore.ai
시작하기
Agent 365 SDK는 지금 사용 가능합니다. 이미 실행 중인 에이전트라면 세 단계로 온보딩할 수 있습니다.
- SDK 설치 — Python, TypeScript, 또는 .NET로 에이전트 프로젝트에 추가
- CLI로 등록 — Agent 365 CLI로 아이덴티티를 프로비저닝하고 Agent 365에 자동 온보딩
- 엔트리 포인트 래핑 — SDK로 에이전트 진입점을 감싸 활동·텔레메트리를 컨트롤 플레인으로 스트리밍
데이터 보안 가시성·통제가 필요하면 Microsoft Purview API를 통합해 프롬프트 기반 DLP, Data Security Posture Management, Insider Risk Management, eDiscovery·Communication Compliance·Audit·Data Lifecycle Management 등을 활성화할 수 있습니다.
도입 관점 체크포인트
- 한 번 통합, 모든 고객에 적용: SDK를 한 번 통합하면, 그 에이전트를 배포하는 모든 고객이 엔터프라이즈급 통제를 손쉽게 켤 수 있음
- 아이덴티티 우선 설계: Entra Agent ID 기반이므로, 사용자 관리와 동일한 정책·조건부 액세스 체계로 에이전트를 다룰 수 있음
- 기존 보안 스택 재활용: Defender·Purview·Entra·SharePoint의 기존 정책·파이프라인을 그대로 활용 — 새 도구를 처음부터 구축할 필요 없음
마무리
Agent 365 SDK의 메시지는 분명합니다 — “어디서 만들었든, 엔터프라이즈에서 통제 가능하게.” 플랫폼·프레임워크에 관계없이 동일한 아이덴티티·관찰성·정책으로 에이전트를 다룰 수 있게 되면서, 조직은 파일럿에서 대규모 운영으로 넘어가는 가장 큰 장벽을 넘게 됩니다. 에이전트 확산의 다음 단계는 ‘거버넌스 내장’입니다.
※ 본 글은 Agent 365 Blog의 Make any agent enterprise-ready with the Agent 365 SDK를 바탕으로 한국 독자용으로 정리했습니다. 자세한 내용은 원문을 참조하세요. 출시 일정·기능은 변경될 수 있습니다.