💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

엔터프라이즈가 관리형 에이전트 서비스를 고르는 이유

2026년 4월 12일 기준으로 Azure AI Foundry Agent Service는 운영 가능한 에이전트를 빠르게 만들고 싶을 때 검토할 만한 관리형 경로다. Microsoft 문서에 따르면 이 서비스는 2025년 5월에 GA 되었고, 현재는 에이전트를 build, deploy, scale 하는 완전 관리형 플랫폼으로 설명된다.

엔터프라이즈가 이런 서비스를 선택하는 이유는 단순하다. 직접 구성하면 Hosting, identity, observability, security를 모두 따로 맞춰야 하기 때문이다. 관리형 서비스를 쓰면 다음이 훨씬 쉬워진다.

배포 패턴을 표준화할 수 있다
tracing과 evaluation을 기본 운영 흐름에 넣을 수 있다
RBAC와 거버넌스를 중앙에서 관리할 수 있다
지원되는 에이전트 유형에서 private networking을 적용할 수 있다
도구를 확장할 때 인프라 스프롤을 줄일 수 있다

또 하나 중요한 점은, 이 서비스가 Foundry model catalog의 다양한 모델을 지원한다는 사실이다. 즉, Azure OpenAI 모델만 고집해야 하는 구조가 아니어서 모델 선택을 비용, 지연 시간, 규정 준수 관점에서 조정하기가 쉽다.

공식 개요는 여기서 시작하면 된다.

Microsoft Foundry Agent Service란 무엇인가

엔터프라이즈가 따라야 할 라이프사이클

Microsoft는 이 서비스를 build-test-deploy-monitor 흐름으로 설명한다.

포털에서 에이전트를 만들거나 코드로 hosted agent를 만든다
playground나 로컬 환경에서 테스트한다
모든 model call, tool invocation, decision을 trace한다
evaluation으로 품질과 회귀를 측정한다
managed resource와 stable endpoint로 publish한다
dashboard와 metrics로 운영 상태를 모니터링한다

이 흐름의 장점은 에이전트 개발을 실험이 아니라 운영 모델로 바꾼다는 점이다. 엔터프라이즈 입장에서는 프로토타입이 감사 가능한 production으로 얼마나 빨리 넘어가는지가 핵심이다.

플랫폼 판단의 핵심은 도구다

대부분의 팀에게 가장 큰 차이는 tool ecosystem이다. Microsoft 문서는 tool catalog와 함께 remote MCP server 지원을 명시하고 있고, 포털의 Add Tools catalog에서 이 서버들을 연결할 수 있다고 설명한다.

이 점이 아키텍처를 바꾸는 이유는 분명하다.

모든 도구 통합을 직접 만들지 않아도 된다
조직 전용 도구는 private tool catalog로 제공할 수 있다
원격 MCP server를 연결하고 허용할 도구 범위를 통제할 수 있다
지원되는 인증 패턴을 사용해 비밀정보 처리를 직접 구현하는 부담을 줄일 수 있다

즉, Agent Service는 단순히 모델을 실행하는 호스팅 계층이 아니라, 도구와 권한을 함께 운영하는 control plane에 가깝다.

도움이 되는 문서:

tracing, evaluation, monitoring은 선택이 아니다

이 서비스가 강한 이유는 observability가 운영 흐름의 일부로 들어가기 때문이다. Microsoft의 lifecycle 가이드는 명시적으로 trace, evaluate, monitor 단계를 포함하고 있고, monitoring dashboard는 Application Insights와 Azure Monitor에 연결된다.

이 부분은 대규모 배포에서 특히 중요하다. 실제로는 다음 질문에 답해야 하기 때문이다.

어떤 tool이 실제로 호출되고 있는가
latency는 어디서 발생하는가
model switch가 품질에 영향을 주었는가
실패 원인이 prompt, tool routing, orchestration 중 어디인가
배포 후 어떤 regression이 생겼는가

classic release notes를 보면 플랫폼이 어떻게 성숙했는지도 보인다.

2025년 5월 GA
2025년 4월 Azure Monitor metrics
2025년 4월 BYO thread storage with Azure Cosmos DB for NoSQL
2025년 6월 Deep Research와 remote MCP 지원
2025년 8월 Browser Automation
2025년 5월 connected agents와 tracing agent threads

이 히스토리는 서비스가 데모용 기능을 넘어서 운영용 플랫폼으로 진화하고 있다는 신호다.

거버넌스와 보안이 진짜 차별점이다

엔터프라이즈가 Agent Service를 선택하는 가장 큰 이유는 prompt ergonomics보다 governance와 security인 경우가 많다.

Microsoft는 다음을 지원한다고 설명한다.

각 에이전트에 대한 전용 Microsoft Entra identity
누가 create, invoke, manage 할 수 있는지 제어하는 Azure RBAC
unsafe output과 prompt injection 완화를 돕는 content filters
지원되는 에이전트 유형의 private networking
thread storage를 위한 고객 소유 자원, 예를 들면 Azure Cosmos DB

보안 리뷰를 통과해야 하는 조직이라면 이 조합이 prototype과 production을 가르는 기준이 된다.

특히 private networking 문서는 Foundry, Azure AI Search, Azure Storage, Azure Cosmos DB를 private endpoint로 보호하는 방법을 설명한다. 네트워크 격리가 필요한 배포라면 초기에 검토하는 편이 좋다.

Foundry Agent Service의 private networking 설정

배포 전 체크리스트

파일럿을 production으로 넓히기 전에 다음을 확인하면 좋다.

이 에이전트가 정말 관리형 호스팅이 필요한지 확인한다.
Foundry model catalog에서 latency, cost, compliance 기준으로 모델을 고른다.
어떤 도구를 catalog에서 쓰고 어떤 도구를 private tool catalog나 remote MCP server로 둘지 정한다.
본격적인 파일럿 전에 tracing을 켠다.
품질, regression, safety에 대한 evaluation 기준을 정한다.
Cosmos DB 기반 BYO thread storage가 필요한지 판단한다.
외부 접근 전에 RBAC, identity, content safety 정책을 검증한다.
배포할 agent type에 필요한 private networking 조건을 확인한다.
monitoring owner와 incident 경로를 먼저 정한다.

정리

Azure AI Foundry Agent Service는 에이전트를 만들 수 있느냐보다 안전하게 운영할 수 있느냐가 중요한 팀에 잘 맞는다. 모델 선택, 도구, tracing, evaluation, monitoring, enterprise control을 하나의 관리형 서비스로 묶어 주기 때문에, 새 엔터프라이즈 에이전트 프로그램의 출발점으로 충분히 강하다.

커스텀 orchestration과 관리형 control plane 사이에서 고민 중이라면, 공식 문서는 새 프로젝트를 관리형 경로에서 시작하는 쪽을 강하게 시사한다.