현재 두 개의 Microsoft Foundry 포털이 존재하며, 이들 사이의 전환은 "New Foundry"라고 표시된 단일 배너 스위치를 통해 이루어집니다. 이 스위치는 실제 아키텍처 결정 사항을 숨기고 있습니다. 즉, 새로운 포털은 Foundry 프로젝트만 보여주는 반면, 특정 범주의 리소스들(Azure OpenAI, 허브 기반 프로젝트, 관리형 컴퓨팅 모델 호스팅)은 오직 클래식(classic) 측에만 존재합니다. 2026년에 모든 아키텍트가 답해야 할 질문은 "어느 포털이 더 보기 좋은가"가 아닙니다. 그것은 "내 리소스 중 어떤 것이 클래식에 고립되어 있으며, 이를 이동하기 위해 어떤 작업이 필요한가"입니다.

이 기사는 마이그레이션 지도입니다. 이 글은 새로운 포털에 도달한 것과 여전히 클래식 전용인 것을 구분하고, 허브(hub)에서 Foundry로 마이그레이션하는 동안 정확히 무엇이 전송되는지, 그리고 무엇을 수동으로 다시 구축해야 하는지를 나열하며, 실제로 여러분의 결정을 강제할 두 개의 중요한 날짜를 표시합니다. 이 내용은 2026년 중반 기준이며 Microsoft Learn에 근거하고 있습니다. 문서가 확답을 피하는 부분에서는 저 또한 확답을 피하겠습니다. 왜냐하면 가장 중요한 질문 중 일부(클래식 포털은 언제 은퇴하는가?)는 현재 문서에 답이 없기 때문입니다.

먼저 명칭에 대해 언급하자면, Microsoft가 두 번이나 변경했기 때문입니다. 브랜드는 Azure AI Studio에서 Azure AI Foundry를 거쳐 Microsoft Foundry로 진화했으며, AI 서비스 포트폴리오는 Azure Cognitive Services에서 Azure AI Services를 거쳐 Foundry Tools로 변경되었습니다. 이 모든 과정 동안 기반이 되는 Azure 리소스 유형은 navigate-from-classic 가이드에서 Microsoft가 문서화한 대로 Microsoft.CognitiveServices/accounts로 유지되었습니다. 이 기사에서는 New-Foundry-on 경험을 위해 "새로운 포털(new portal)"과 "현재 포털(current portal)"을 혼용하여 사용하며, New-Foundry-off를 위해 "클래식 포털(classic portal)"이라는 용어를 사용합니다.

요약 (TL;DR)

"New Foundry" 배너 스위치에 의해 전환되는 두 개의 포털이 있습니다. 새 포털은 Foundry 프로젝트만 보여줍니다. Azure OpenAI 리소스, 허브 기반(hub-based) 프로젝트, 그리고 프롬프트 플로우(prompt flow)나 관리형 컴퓨팅(managed-compute, 오픈 소스) 모델 호스팅이 필요한 모든 항목에는 클래식 포털이 필요합니다. 새로운 리소스 모델은 기존의 허브(Hub)와 Azure OpenAI, Azure AI Services의 분산된 구조를 단일 프로젝트 엔드포인트 상의 자식 프로젝트를 가진 하나의 Foundry 리소스로 통합합니다. 두 가지 컴포넌트 수준의 날짜는 확정되었습니다: azure-ai-inference 패키지는 2026년 5월 30일에 은퇴(retire)하며, Assistants API는 2026년 8월 26일에 서비스 종료(sunset)됩니다. 클래식 포털 자체, 허브 기반 프로젝트, 또는 이전 브랜드 명칭에 대해 발표된 은퇴 날짜는 없습니다. 대부분의 팀은 Foundry 프로젝트를 기본값으로 사용해야 합니다. 프롬프트 플로우(prompt flow)나 오픈 소스 모델 배포가 구체적으로 필요한 경우에만 허브 기반 프로젝트를 유지하십시오.

월요일의 과제: 클래식에 남겨진 리소스들을 인벤토리화하십시오. 모든 독립형 Azure OpenAI 리소스와 모든 허브 기반 프로젝트를 나열한 다음, 각 항목에 대해 다음 두 가지를 확인하십시오: 2026년 마감 기한이 있는 azure-ai-inference 또는 Assistants API 의존성이 있는지, 그리고 프롬프트 플로우(prompt flow)나 관리형 컴퓨팅(managed compute)(아직 새 포털에 상응하는 기능이 없는 두 가지 기능)이 필요한지 여부입니다. 이 단일 테이블을 통해 무엇을 이동해야 하는지, 무엇을 유지할 수 있는지, 그리고 무엇이 시간 제한(on a clock)에 걸려 있는지 알 수 있습니다. 한 가지 사전 점검 사항을 더 추가하자면: 마이그레이션 전에 Responses API와 Foundry Agent Service의 지역(region) 지원 여부를 확인하십시오. 지원되지 않는 지역은 새 포털에서 에이전트 사용을 완전히 차단하기 때문입니다.

"새로운(New)" 것이 실제로 의미하는 것: 스킨이 아닌 리소스 모델

포털 토글은 눈에 보이는 부분일 뿐입니다. 그 이면의 변화는 리소스 모델(resource model)입니다.

클래식 모델 (classic model)에서는 전형적인 배포 방식이 허브 (Hub), Azure OpenAI 계정, Azure AI Services 등 5개 이상의 엔드포인트 (endpoints)에 걸쳐 분산된 여러 Azure 리소스를 동시에 관리했습니다. 새로운 모델은 이를 하나의 Foundry 리소스로 통합하며, 통합된 RBAC (역할 기반 액세스 제어), 네트워킹 (networking), 정책 (policies) 하에 하나의 Azure 리소스 공급자 네임스페이스 (resource provider namespace) 내에서 단일 프로젝트 엔드포인트를 통해 액세스할 수 있는 하위 프로젝트 (child projects) 구조로 압축합니다. Microsoft는 이러한 통합을 what-is-Foundry 개요에서 설명합니다. 리소스 유형 (resource type) 자체가 바뀐 것은 아닙니다. 서로 연결해야 하는 요소들의 수가 바뀐 것입니다.

이것이 바로 새로운 포털이 "Foundry 프로젝트만 보여주는" 이유입니다. 사용자를 번거롭게 하려고 다른 리소스를 숨기는 것이 아닙니다. 새로운 포털은 새로운 단일 리소스 모델 (single-resource model)을 위한 인터페이스이며, 그 이전의 모든 것(Azure OpenAI 단독 리소스, 허브 기반 프로젝트, 허브 리소스 유형 자체)은 클래식 what-is-Foundry 페이지에 따라 클래식 포털을 통해 접근할 수 있습니다.

따라서 기능을 비교하기 전에 용어를 명확히 정리해야 합니다. 세 가지 용어가 혼란의 대부분을 야기하기 때문입니다.

두 가지 프로젝트 유형, 그리고 Microsoft가 선택하라고 권장하는 하나

이 전체 마이그레이션에서 가장 중대한 선택은 포털 수준이 아닙니다. 프로젝트 수준입니다. 두 가지 프로젝트 유형이 있으며, 이들은 서로 교체할 수 없습니다.

**Foundry 프로젝트 (Foundry project)**는 Microsoft Foundry 리소스 아래에서 직접 관리되며 추가적인 Azure 리소스가 필요하지 않습니다. **허브 기반 프로젝트 (hub-based project)**는 Foundry/AI 허브에 의해 호스팅되며, 이는 다시 종속적인 Azure Storage 및 Key Vault 리소스를 필요로 합니다. 클래식 what-is-Foundry 페이지에 명시된 Microsoft의 자체 가이드는 다음과 같습니다: "대부분의 경우, Foundry 프로젝트를 사용하는 것이 좋습니다."

해당 권장 사항은 마케팅 수단이 아닙니다. 이는 기능 투자(feature investment)가 어디로 향하고 있는지를 반영합니다. Microsoft는 2025년 6월부터 Azure AI Hub 기능의 대부분을 Foundry 리소스 유형(resource type)으로 이동하기 시작했으며, 새로운 기능은 주로 Foundry에 적용된다고 언급했습니다. 다만, resource-types concept page에 따르면 오픈 소스 모델 배포(open-source model deployments)와 같은 특정 사용 사례는 여전히 허브(hub) 리소스를 필요로 합니다. migrate-project guide에 명시된 바와 같이, 새로운 생성형 AI (generative-AI) 및 모델 중심 기능(Foundry API 및 Foundry Agent Service, 모두 일반 가용성 (GA) 상태)은 Foundry 리소스와 그 Foundry 프로젝트를 통해서만 사용할 수 있습니다.

하지만 "대부분의 경우"가 "모든 경우"를 의미하지는 않으며, 예외 사항은 명확합니다. 다음은 두 프로젝트 유형 간의 기능 분할(capability split)입니다.

해당 표를 문서에서 요구하는 방식대로 읽으십시오. 즉, 확정된 계약이 아닌 현재의 스냅샷(snapshot)으로 보아야 합니다. Microsoft는 두 프로젝트 유형 간의 기능적 동등성 (feature parity)이 아직 명시적으로 달성되지 않았음(

프로젝트 유형이 한 축이라면, 다른 한 축은 특정 기능이 어디에서 도달 가능한가입니다. Microsoft의 navigate-from-classic 가이드는 기능들을 세 가지 버킷(bucket)으로 분류하며, 이 분류 방식이 마이그레이션 (migration)을 계획하는 가장 깔끔한 방법입니다.

새로운 포털 전용, 일반적으로 사용 가능 (Generally Available, GA): Responses API, Agents v2 (이는 Responses API와 동일함), 크고 계속 성장 중인 도구 카탈로그 (각 항목은 자체적인 GA 또는 Preview 레이블을 가지고 있으며, 도구별로 확인해야 함), 그리고 Microsoft 365 및 Teams로의 에이전트 게시.

새로운 포털 전용, 미리 보기 (Preview): 멀티 에이전트 워크플로 (multi-agent workflows), 에이전트 메모리 (agent memory), Foundry IQ, 호스팅된 에이전트 (hosted agents), A2A 프로토콜, 그리고 Foundry 제어 평면 (Control Plane). 이 목록의 모든 항목은 Preview 상태입니다. 이 중 어떤 것도 운영 환경 (production path)에서 보호 장치 없이 방치되어서는 안 됩니다.

두 포털 모두 지원: Foundry 프로젝트 자체, 채팅 완성 (chat completions), 미세 조정 (fine-tuning), 평가 (evaluations, 현재 포털에서 강화됨), 그리고 모델 카탈로그 (model catalog, 현재 포털에서 확장됨).

클래식 전용, 마이그레이션 필요: 독립형 Azure OpenAI 리소스 (Foundry 리소스로 업그레이드해야 함) 및 허브 기반 프로젝트 (hub-based projects, 현재 포털에서는 전혀 보이지 않으므로 클래식 포털로 전환하거나 Foundry 프로젝트로 마이그레이션해야 함).

이 구조는 깊이 생각해 볼 가치가 있습니다. 진정으로 새로운 생성형 AI 인터페이스 (agents v2, 멀티 에이전트, 메모리, Foundry IQ, A2A, Control Plane)는 설계 단계부터 새로운 포털 전용으로 만들어졌습니다. 지루하지만 핵심적인 기본 요소들 (chat completions, fine-tuning, evaluations, model catalog)은 양쪽 모두에서 작동합니다. 그리고 당신을 클래식에 고립시키는 두 가지 요소는 오래된 리소스 유형 (독립형 Azure OpenAI)과 오래된 프로젝트 유형 (허브 기반)입니다. 이는 건강한 패턴입니다. 통합은 새로운 쪽에서는 추가적인 방식 (additive)으로 이루어지고, 오래된 쪽에서는 마이그레이션이 관문 역할을 하는 방식 (migration-gated)이지, 강제로 전부 뜯어내고 교체하는 방식 (rip-and-replace)이 아니기 때문입니다.

더 깊은 질문인 "Standalone Azure OpenAI를 쓰는 대신 Foundry를 써야 하는가?"에 대해서는 그 자체의 의사결정 트리(decision tree)를 가진 별개의 문제입니다. 저는 이 내용을 Azure AI Foundry vs Azure OpenAI: The 2026 Decision에서 다루었으며, 이 글은 여러분이 이미 Foundry를 플랫폼으로 결정했다고 가정합니다.

무시할 수 없는 API 및 SDK 명칭 변경

리소스 모델(resource model)이 구조적인 변화라면, API 및 SDK 명칭 변경은 코드를 깨뜨리는(breaks your code) 변화입니다. 이는 기계적이고 문서화가 잘 되어 있지만, 새로운 포털로 이동한다면 피할 수 없는 과정입니다.

navigate-from-classic 가이드에 따라 전반적인 용어가 다음과 같이 변경되었습니다:

SDK 측면에서는, 동일한 navigate-from-classic 가이드에 따라 클래식 패키지와 Azure 전용 클라이언트가 하나의 프로젝트 엔드포인트를 가리키는 표준 openai OpenAI() 클라이언트와 함께 통합된 azure-ai-projects 2.x 프로젝트 클라이언트로 합쳐집니다. 매핑은 다음과 같습니다:

가장 흔한 재작성(rewrite) 방식은 가장 작은 단위의 변경입니다. 즉, Azure 전용 AzureOpenAI 클라이언트와 그에 따른 azure_endpoint 및 api_version을 버리고, API 키 대신 DefaultAzureCredential로 인증하며 단일 /openai/v1 프로젝트 엔드포인트를 가리키는 표준 OpenAI() 클라이언트를 사용하는 것입니다. 이 패턴은 navigate-from-classic 가이드의 전/후(before/after) 예시를 따릅니다.

# 클래식 (Classic): azure-ai-projects 1.x 시대; Azure 전용 클라이언트 + 매월 변경되는 api-version
from openai import AzureOpenAI

...

버전 분리는 가장 뼈아픈 부분입니다: azure-ai-projects 1.x 버전은 클래식 포털 (classic portal)을 대상으로 하고, 2.x 버전은 새로운 포털 (new portal)을 대상으로 하며, 포털 간에 버전을 혼용하면 오류가 발생합니다. 제 경험상 이는 그 어떤 전략적 질문보다도 가장 흔하게 발생하는 걸림돌이며, 증상(ModuleNotFoundError 또는 예상치 못한 API 응답)이 포털 불일치보다는 코드 버그처럼 보이기 때문에 놓치기 쉽습니다. Microsoft는 navigate-from-classic 가이드의 문제 해결 (troubleshooting) 표에 정확히 해당 증상과 그 원인인 "SDK 버전이 포털 대상과 일치하지 않음"을 명시하고 있습니다. 만약 여러분이 "내 컴퓨터에서는 작동하는" SDK 불일치 문제를 디버깅해 본 적이 있다면, 이것은 Foundry라는 배지를 달고 나타난 동일한 함정입니다.

RBAC 역할 (roles) 또한 변경되었습니다. 기존의 Cognitive Services OpenAI User 및 유사한 역할들은 제어 평면 (control-plane)과 데이터 평면 (data-plane)의 분리와 함께 Foundry User, Foundry Project Manager, Foundry Owner, 그리고 Foundry Account Owner로 대체되었습니다. 문서에서 확인할 수 있는 한 가지 안심할 만한 점은, 이 역할들이 최근에 Azure AI User/Owner/Account Owner/Project Manager에서 이름이 변경되었으며, 이름 변경 후에도 역할 ID (role IDs)와 핵심 권한 (core permissions)은 변경되지 않았다는 것입니다. 따라서 표시 이름 (display names) 대신 역할 ID를 사용하여 Bicep 또는 Terraform 코드를 작성했다면, 이름 변경으로 인해 코드가 깨지지는 않았을 것입니다. 만약 스크립트나 문서에 표시 이름을 하드코딩했다면, 이를 업데이트하십시오.

2026년 Azure AI Foundry 마이그레이션 마감일은 언제인가요?