에이전트는 몇 개나 있을까
회사에 에이전트가 몇 개 있는지 아는 사람이 있을까요.
Copilot Studio에서 누군가 만든 것, 개발팀이 Foundry로 띄운 것, 외부 SaaS가 붙여 준 것, 오픈소스 프레임워크로 누군가 사내 서버에 올린 것. 각자 다른 계정과 권한으로 사내 데이터에 접근합니다.
몇 년 전 '섀도 IT'가 그랬듯, 이제는 '섀도 에이전트'가 생기고 있습니다. Agent 365 발표는 이 문제를 정면으로 다룹니다.
출발점은 등록부
Charles Lamanna의 발표 글에서 가장 기억에 남는 문장은 이것입니다. 에이전트가 무분별하게 늘어나는 것을 막는 최선의 방법은 단일 진실 공급원 역할을 하는 등록부에서 시작하는 것이라는 말입니다.
Agent 365의 등록부는 IT에 에이전트 목록을 줍니다. Entra 에이전트 ID가 있는 에이전트를 포함해서요. 승인되지 않은 에이전트는 격리할 수 있습니다.
순서가 중요합니다. 무엇이 있는지 모르면 아무것도 통제할 수 없으니까요. 서버 자산 관리가 CMDB에서 시작했던 것과 같은 이치입니다.
다섯 가지 기능
글에 나온 기능을 정리하면 이렇습니다.
| 기능 | 하는 일 |
|---|---|
| 등록부 | 에이전트 목록, 미승인 에이전트 격리 |
| 접근 통제 | 필요한 리소스에만 접근, 누가 에이전트를 만들고 관리할지 제한 |
| 시각화 | 에이전트·사용자·리소스 사이의 연결 지도, 성과와 ROI, 규정 준수 로그 |
| 상호운용 | Microsoft 365 앱과 데이터(Work IQ 포함) 접근, 오픈소스·파트너 클라우드와 연동 |
| 보안 | Defender(위협 탐지), Entra(신원·실시간 차단), Purview(데이터 노출·규정 준수) |
시각화 항목의 "연결 지도"가 특히 실용적으로 보입니다. 어떤 에이전트가 어떤 사용자를 대신해 어떤 리소스를 건드리는지 한 장으로 보는 기능입니다. 사고가 났을 때 영향 범위를 가늠하는 데 바로 쓰입니다.
바탕에는 Entra Agent ID가 있다
다섯 기능이 모두 기대는 기반이 Entra Agent ID입니다. 에이전트마다 고유한 신원을 주는 기능입니다.
발표 글은 조직의 모든 에이전트가 고유 에이전트 ID를 갖도록 요구하는 장면을 그립니다. 신원이 있어야 등록부에 오르고, 신원이 있어야 접근 권한을 좁힐 수 있습니다.
Entra는 위험도에 따라 접근 정책을 바꾸고, 탈취됐을 가능성이 있는 에이전트가 조직 리소스에 접근하지 못하게 막을 수 있다고 합니다. 사람 계정에 쓰던 조건부 접근을 에이전트에게도 그대로 적용하는 셈입니다.
서비스 계정과 무엇이 다른가
여기서 질문이 하나 생깁니다. 지금도 에이전트에게 서비스 계정을 주면 되지 않나?
차이는 관리 단위에 있다고 봅니다. 서비스 계정은 "이 프로그램"의 신원이고, 보통 넓은 권한을 오래 갖습니다. 에이전트 ID는 등록부, 소유자, 수명 주기와 묶인 "이 에이전트"의 신원입니다. 만든 사람이 퇴사하면 그 에이전트를 찾아 정리할 수 있어야 합니다. 서비스 계정만으로는 이게 어렵습니다.
마이크로소프트 밖의 에이전트는?
Agent 365는 마이크로소프트 플랫폼, 오픈소스 프레임워크, 파트너 클라우드에서 모두 동작한다고 밝혔습니다. 파트너로 Adobe, Databricks, SAP, ServiceNow, Workday를, 오픈소스 에이전트 게시자로 Anthropic, LangChain, OpenAI, Vercel을 꼽았습니다.
하지만 외부 에이전트가 등록부에 오르려면 결국 Entra 신원 체계 안으로 들어와야 합니다. 마이크로소프트 365를 중심으로 일하는 회사라면 자연스럽습니다. 다른 신원 체계를 쓰는 회사라면 어디까지 연동되는지 따로 확인해야 합니다.
그 뒤의 소식
발표 당시 Agent 365는 Frontier 조기 접근 프로그램으로 Microsoft 365 관리 센터에서 제공됐습니다. 같은 발표 글에는 이후 정식 출시됐다는 안내가 붙어 있습니다.
에이전트를 하나둘 만들기 시작한 팀이라면 지금 할 수 있는 일이 있습니다. 에이전트마다 소유자와 목적, 접근하는 데이터를 적은 목록부터 만들어 두는 것입니다. 어떤 도구를 쓰든 등록부는 결국 그 목록에서 시작합니다.
함께 읽을 개념 정리
- 에이전트가 '나 대신' 일할 때: OAuth 토큰 교환과 위임: 사용자와 에이전트를 둘 다 토큰에 남기는 방법
