한 줄 정의

Microsoft Foundry는 Azure 위에서 AI 모델, 에이전트, 도구, 관측, 거버넌스를 한 프로젝트 경계로 묶는 기업용 AI 앱·에이전트 플랫폼이야. Azure 전체를 새 이름으로 바꾼 것도 아니고, GPT나 Claude 같은 모델 하나를 뜻하는 말도 아니야. 모델을 고르고, Agent를 만들고, 배포 뒤 로그와 비용과 권한을 보는 작업대를 Microsoft 클라우드 안에 모아 둔 제품군으로 보면 돼.

Microsoft 문서가 이 이름을 “AI app and agent factory”라고 부르는 이유도 여기에 있어. 개발자는 프로젝트 엔드포인트에서 모델과 도구를 호출하고, 운영자는 Control Plane에서 에이전트 묶음, eval, 추적, 비용, 정책 위반 신호를 본다. 그래서 기사에서 이 이름이 나오면 “어떤 새 모델인가”보다 “그 모델과 에이전트를 Azure의 어떤 운영 경계 안에서 쓰나”를 먼저 확인하는 편이 맞아.

실제로 무엇을 하나

가장 기본 단위는 Foundry resource와 project야. Microsoft의 SDK 문서는 Foundry SDK가 https://{resource}.services.ai.azure.com/api/projects/{project} 같은 프로젝트 엔드포인트를 쓰고, OpenAI SDK 호환 호출은 https://{resource}.openai.azure.com/openai/v1 경로를 쓴다고 나눠. 그래서 기존 OpenAI API식 호출을 유지할지, Foundry 고유의 프로젝트 client와 추적 기능을 쓸지 처음부터 갈라야 해.

모델 쪽에서는 Foundry Models가 카탈로그 역할을 해. 2026년 4월 20일 갱신된 해당 문서는 1,900개가 넘는 모델을 Microsoft, OpenAI, Anthropic, Mistral, xAI, Meta, DeepSeek, Hugging Face 같은 공급자 범위에서 탐색·평가·배포한다고 설명해. 이 안에서도 Microsoft가 직접 판매·지원하는 Azure Direct 모델과 파트너·커뮤니티 모델이 갈리고, 배포 방식도 서버리스 배포와 관리형 컴퓨트로 나뉘어. 같은 모델명이라도 과금, SLA, 네트워크, Guardrail 적용 방식이 달라질 수 있어.

에이전트 쪽에서는 Foundry Agent Service와 워크플로가 붙어. 예를 들어 고객지원 자동화라면 하나의 에이전트 노드가 정책 문서를 읽고, 다른 노드가 CRM API를 부르고, 조건 분기나 사람 승인 단계가 처리 여부를 가를 수 있어. 워크플로 문서는 순차 실행, 그룹 채팅, 사람 승인 패턴을 템플릿으로 제공하고, 에이전트 노드에는 모델, 프롬프트, 도구, JSON 스키마 출력 같은 설정을 붙인다고 설명해.

운영 단계에서는 Foundry Control Plane이 중요해져. 한두 개 챗봇을 테스트하는 수준이면 로그 화면만 봐도 되지만, 부서별 에이전트가 늘면 누가 어떤 도구를 호출했고, 어떤 모델 버전을 썼고, 토큰 사용량과 비용 이상 신호가 어디서 났는지 모아 봐야 해. Control Plane 문서는 활성 에이전트, 실행 완료율, 규정 준수 상태, 비용 효율, 금지 행동 같은 지표와 Defender, Purview, Entra 연동을 한 운영 화면으로 다룬다고 설명해.

왜 중요한가

이 플랫폼이 중요한 이유는 기업 AI 도입의 병목이 모델 호출 코드 한 줄이 아니라 운영 경계로 옮겨가고 있기 때문이야. 좋은 모델을 골라도 사내 문서 접근 권한, 도구 호출 승인, prompt injection 대응, 장애 재현 로그, 비용 라벨, region 제한을 같이 풀지 못하면 운영용 에이전트로 쓰기 어려워. Foundry는 이 문제를 Microsoft의 Azure 계정, resource, RBAC, 네트워크, 보안 제품과 붙여서 처리하려는 경로야.

이 점은 Amazon Bedrock과 비교하면 더 잘 보여. Bedrock은 AWS 안에서 여러 기반 모델, RAG, Guardrails, 에이전트 실행을 관리하는 길이고, Foundry는 Azure와 Microsoft 365, Entra, Defender, Purview 쪽 조직 운영과 잘 맞물리는 길이야. 이미 회사 데이터와 보안 심사가 Azure에 몰려 있으면 Foundry가 자연스럽고, 이미 AWS에 데이터 레이크와 IAM 정책이 잡혀 있으면 Bedrock이 더 빠를 수 있어. 모델 성능표만 보면 이 차이가 잘 안 보여.

또 이 제품군은 외부 모델 공급자가 기업 배포 채널을 설명할 때도 등장해. Anthropic은 Claude Opus 4.7 개발자 접근 경로로 Claude Platform, Amazon Bedrock, Vertex AI, 이 플랫폼을 함께 적었어. 이 문장은 Foundry가 Claude 자체라는 뜻이 아니라, 기업이 Claude 같은 모델을 Microsoft의 클라우드 운영 경계 안에서 쓰는 유통·운영 채널이라는 뜻에 가까워.

주의해서 볼 점

첫째, Foundry와 Foundry classic을 섞어 읽으면 안 돼. Microsoft 문서는 Azure AI Studio와 Azure AI Foundry 이름을 현재 브랜드로 정리하면서도, hub 기반 project와 classic portal 문서를 따로 남겨 둬. 새 프로젝트 엔드포인트, SDK 2.x, Responses API 경로를 쓰는지, classic hub와 예전 엔드포인트를 쓰는지 확인해야 샘플 코드가 엇나가지 않아.

둘째, 모델 수는 도입 가능성과 같지 않아. Microsoft 문서는 1,900개가 넘는 모델을 말하지만, region support 문서는 Foundry project가 열리는 32개 Azure region과 기능별 제공 여부를 따로 확인하라고 해. 모델 공급자, 배포 유형, quota, data zone, region, 과금 meter가 맞아야 실제 workload에 붙일 수 있어.

셋째, 보안 문구를 자동 면책처럼 읽으면 곤란해. Azure Direct Models 문서는 프롬프트, 완성 결과, 임베딩, 학습 데이터가 다른 고객이나 OpenAI·다른 모델 공급자에 제공되지 않고 허가 없이 기반 모델 학습에 쓰이지 않는다고 적어. 그래도 Responses API, Assistants, batch, fine-tuning, vector store처럼 상태를 저장하는 기능을 쓰면 저장 데이터와 삭제 조건을 따로 봐야 해. Global이나 DataZone 배포는 처리 위치 조건도 달라질 수 있어.

넷째, Foundry를 쓰면 AI 안전이나 Agent Observability가 자동으로 끝난다고 보면 안 돼. Responsible AI 문서는 위험 발견, 보호, 거버넌스 흐름을 제시하고, adversarial prompt 테스트, Guardrails, 추적, 모니터링, 규정 연동을 권장해. 이건 플랫폼이 도구를 준다는 뜻이지, 각 팀의 권한 설계와 테스트 책임이 사라진다는 뜻은 아니야.