Microsoft Foundry의 네트워크 설계 이해 — 인바운드/아웃바운드로 정리하는 폐쇄형 아키텍처

본 기사는 GitHub Copilot 및 Microsoft Foundry를 활용하여 작성되었습니다. 내용의 정확성에 대해서는 각 공식 문서를 확인해 주시기 바랍니다.

Microsoft Foundry의 가치는 '사용 가능한 모델의 종류가 풍부하다는 것'만이 아닙니다. 엔터프라이즈에서 AI를 본업용으로 운용하는 데 있어 피할 수 없는 '네트워크 요구사항'을 충족하는 기능——프라이빗 네트워크(Private Network)로의 격리, Private Link를 통한 통신 보호, VNet 인젝션(VNet Injection)을 통한 에이전트 실행 기반의 격리, 방화벽을 통한 egress 제어——를 플랫폼 표준으로 제공하고 있다는 점이 큰 강점입니다.

하지만 이러한 네트워크 기능은 개발자가 이해하고 구현하기 어렵다는 것도 사실입니다. Foundry의 폐쇄화는 'Private Endpoint를 설정하면 끝'이 아니라, **인바운드(Inbound)**와 **아웃바운드(Outbound)**의 메커니즘이 완전히 다르며, 특히 아웃바운드는 에이전트 실행 기반을 VNet에 주입하는 '네트워크 인젝션(Network Injection)'이 전제 조건이 됩니다. 이에 본 기사에서는 공식 문서의 아키텍처 도표를 곁들여, Foundry의 네트워크 설계를 인바운드/아웃바운드로 나누어 정리합니다. 아울러 아웃바운드를 Hub & Spoke 구성으로 하는 경우/하지 않는 경우의 차이, 그리고 최근 업데이트인 프라이빗 MCP 서버 연결에 대해서도 해설합니다.

본 기사는 다음의 공식 문서를 근거로 하고 있습니다 (2026년 6월 시점).

공식 문서에서는 Foundry의 네트워크 분리를 다음 3개 영역으로 나누어 생각하도록 제시하고 있습니다.

인바운드(Inbound): Foundry 리소스로 들어오는 통신 (예: 데이터 사이언티스트나 업무용 앱이 Foundry에 액세스함)
아웃바운드(Outbound, Foundry 리소스 발신): Foundry 리소스에서 다른 Azure 서비스(Storage / Key Vault / Container Registry / 모니터링 등)로 나가는 통신
아웃바운드(Outbound, Agent 클라이언트 발신): 에이전트 실행 기반에서 프라이빗 데이터 소스나 Azure PaaS, 허가된 인터넷 대상으로 나가는 통신

아래 그림은 인바운드와 아웃바운드를 조망한 공식 전체 구조도입니다.

포인트는 인바운드는 Private Endpoint (Private Link)로 보호하고, 아웃바운드는 VNet 인젝션 (서브넷 위임)으로 보호한다는 비대칭 구조로 되어 있다는 점입니다. 순서대로 살펴보겠습니다.

인바운드는 비교적 심플합니다. Foundry 프로젝트의 Public Network Access (PNA) 플래그로 입구의 개폐를 제어합니다.

PNA 설정	동작
Disabled	Private Endpoint를 통해서만 액세스 가능 (완전 폐쇄형)
Enabled from selected IP addresses	지정된 IP 주소/VNet에서만 허용
Enabled (기본값)	퍼블릭에 개방

폐쇄화를 하는 경우에는 Disabled를 선택하고, Foundry 리소스에 대해 Private Endpoint를 생성합니다. 이를 통해 VNet 내의 클라이언트(또는 ExpressRoute / VPN으로 연결된 온프레미스)에서 동일한 연결 문자열을 유지한 채 프라이빗 IP로 이름 해석(Name Resolution)이 가능해집니다.

• Private Endpoint를 생성하면, Azure는 privatelink 서브도메인의 프라이빗 DNS 존(Private DNS Zone)에 A 레코드를 생성합니다.
• 온프레미스나 독자적인 DNS를 사용하는 경우에는 privatelink 서브도메인을 Azure DNS (168.63.129.16)로 조건부 전달(Conditional Forward)해야 합니다.
• Foundry(계정)에서 필요로 하는 주요 DNS 존:
  privatelink.cognitiveservices.azure.com
privatelink.openai.azure.com
privatelink.services.ai.azure.com

폐쇄화된 Foundry로 '어디서 들어올 것인가'는 다음 중 하나를 선택합니다.

• ExpressRoute: 온프레미스(On-premises)로부터 프라이빗 연결 (운영 환경의 폐쇄망 요구사항 시 권장)
• VPN Gateway (Point-to-site / Site-to-site)
• Azure Bastion + 점프 박스(Jump box) VM: VNet 내에 개발 환경을 배치

이 부분이 Foundry Agent의 가장 큰 특징입니다.

에이전트의 실체는 **Azure Container Apps 기반 위에서 동작하는 컨테이너 (Agent 클라이언트)**입니다. 이를 고객의 VNet 내에 있는 위임된 서브넷 (Delegated Subnet) (Microsoft.App/environments에 위임)으로 "주입(Injection)"함으로써, 에이전트에서 Cosmos DB / AI Search / Storage 등으로 향하는 아웃바운드(Outbound) 통신을 VNet 내에 가둡니다.

중요: 인바운드(Inbound) Private Endpoint만으로는 에이전트의 아웃바운드를 폐쇄화할 수 없습니다. 아웃바운드에는 VNet 인젝션(위임된 서브넷)이 필수입니다. 두 가지를 모두 구성해야 비로소 "No public egress (공개 아웃바운드 없음)"가 실현됩니다.

아래 그림은 Agent Service와 평가(Evaluation)까지 포함된 권장 네트워크 분리 구성입니다.

![Foundry の推奨ネットワーク分離構成（Agent / 評価）]

Standard Agent Setup (표준 셋업)이 필수입니다. Basic (매니지드 리소스) 구성에서는 VNet 인젝션을 사용할 수 없습니다. -
BYO (Bring Your Own) 리소스가 필수입니다: Azure Storage / Azure AI Search / Azure Cosmos DB를 직접 준비하고, 각각에 대해 Private Endpoint를 수동으로 생성해야 합니다 (Foundry 생성 시 자동으로 생성되지 않습니다). -
Agent 서브넷: Microsoft.App/environments에 위임합니다. 최소 /27 크기이며, 공식 권장 사항은 /24입니다. 다른 Foundry 리소스와 공유할 수 없으며(전용), 10.x.x.x (Class A)를 사용할 수 있는 리전은 제한적이지만 Japan East는 이용 가능합니다. -
리전 제약: Foundry 리소스는 VNet과 동일한 리전에 있어야 합니다.

아웃바운드 네트워크 설정은 나중에 변경할 수 없습니다.

• 위임된 서브넷을 나중에 다른 서브넷으로 변경할 수 없음
• 기존 Foundry에 나중에 VNet 인젝션을 추가할 수 없음 (재배포 필요)

이 때문에, 초기 설계 단계에서 IP 주소 대역과 서브넷을 확정해 두는 것이 매우 중요합니다.

에이전트가 사용하는 "도구(Tool)"는 폐쇄 환경에서의 통신 경로가 도구마다 다릅니다. 이를 이해하지 못하면 "폐쇄화했는데 특정 도구가 인터넷으로 나가고 있었다"는 상황이 발생할 수 있습니다.

도구	폐쇄 대응	트래픽 경로
MCP Tool (프라이빗 MCP)	✅ 대응	자신의 VNet 서브넷 경유
Fabric Data Agent / Logic Apps / File Search / Browser Automation / Computer Use / Image Generation	❌ 미지원	퍼블릭 엔드포인트 (인터넷 경유) (개발 중 등)

출처: Agent tools with network isolation

주의: Bing / Web Search / SharePoint Grounding은 폐쇄 환경에서도 "동작"은 하지만, 통신은 퍼블릭 인터넷을 경유합니다. 모든 통신을 사설 네트워크 내에 가두고 싶은 조직에서는 이들이 요구사항을 충족하지 못할 수 있습니다. Azure Policy로 차단하는 것도 가능합니다.

에이전트의 아웃바운드(Egress)를 더욱 엄격하게 제어하고 싶은 경우, Azure Firewall 등을 통해 트래픽을 검사 및 제어합니다. 여기서 구성은 두 가지 패턴으로 나뉩니다.

• 단일 Foundry용 VNet 내에서 완결되는 구성.

• 방화벽(Firewall)도 동일한 VNet 내에 배치하거나, 방화벽을 사용하지 않고 NSG / 라우팅 테이블(Route Table)로 제어.

• 소규모, 단일 프로젝트, PoC(Proof of Concept)에 적합.

• 네트워크 레이아웃은 아래의 Hub & Spoke 도식과는 다른 형태가 됩니다 (공식 문서에서도 "Hub를 전제로 하지 않는 경우 구성이 달라진다"라고 명시).

Hub VNet: 공유 Azure Firewall을 배치 (여러 워크로드의 egress를 일원 관리).

• Spoke VNet: Foundry의 네트워크 (Agent 서브넷 + PE 서브넷)를 배치.
• Hub와 Spoke를 **VNet 피어링 (VNet Peering)**으로 연결하여, Spoke로부터의 egress를 Hub의 방화벽을 경유하도록 강제 (UDR).
• 기업의 공통 네트워크 거버넌스 (중앙 집중형 보안 운영)에 적합.

아래 그림은 공식 Hub & Spoke 구성 예시입니다.

![Foundry의 Hub & Spoke + 방화벽 구성 (egress 제어)]

VNet 인젝션(Injection) 방식으로 방화벽을 배치할 경우, 다음의 FQDN을 허용해야 합니다 (발췌).

시나리오	허용할 FQDN / 서비스 태그 (Service Tag)	용도
Agents	*.identity.azure.net, login.microsoftonline.com, *.login.microsoftonline.com, *.login.microsoft.com (또는 AzureActiveDirectory 서비스 태그)	Agent 서비스의 Container App 위임에 필요
Evaluations & Traces	*.blob.core.windows.net, settings.sdk.monitor.azure.com	평가 카탈로그 / App Insights로 결과 전송
Finetuning	raw.githubusercontent.com	큐레이션된 샘플 데이터셋 이용 시

TLS 인스펙션(Inspection) 주의: 방화벽에서 TLS 인스펙션 (자가 서명 인증서 삽입)을 수행하면 Agent의 통신이 실패합니다. Agent 서브넷의 egress에서는 TLS 인스펙션을 비활성화하십시오.

최근 업데이트를 통해, MCP (Model Context Protocol) 서버를 에이전트의 도구(Tool)로 연결할 때, 퍼블릭(Public) / 프라이빗(Private) 두 종류의 엔드포인트가 지원됩니다.

퍼블릭 MCP만으로는 에이전트에게 전달하고 싶은 "사내 고유의 도구 및 데이터"를 인터넷을 통해 공개할 수밖에 없어 폐쇄망 요구사항을 충족할 수 없었습니다. 프라이빗 MCP는 이 MCP 서버 자체를 VNet 내에 가둔 상태로 에이전트가 이용할 수 있게 합니다. 예를 들어 다음과 같은 시나리오에서 효과를 발휘합니다.

• 사내 API / 기간 시스템을 도구화하고 싶은 경우: 인터넷에 공개할 수 없는 원내 시스템이나 업무 DB에 대한 액세스를 내부 전용 MCP 서버를 통해 에이전트에게 안전하게 제공.
• 민감 데이터를 다루는 규제 산업 (의료·금융·공공): 프롬프트나 도구 호출 내용을 포함하여 모든 통신을 사설 네트워크 내에 가두고 싶은 경우.
• 기존의 사내 도구 자산을 재사용하고 싶은 경우: 자체 호스팅하는 MCP 서버에 사내 지식·검색·계산 로직을 모아 여러 에이전트가 공통으로 이용.
• 서드파티(Third-party) MCP에 의존하고 싶지 않은 경우: 신뢰할 수 있는 자사 호스트 서버로만 액세스를 제한하여 데이터 보관 위치와 경로를 완전히 통제.

요컨대, **"에이전트의 확장 기능(도구)까지 포함하여 완전 폐쇄망으로 구성할 수 있다"**는 점이 프라이빗 MCP의 가치입니다.

엔드포인트 유형	필요한 구성	설명
퍼블릭 MCP	Basic / Standard 모두 가능	공개된 임의의 원격 MCP 서버에 연결 (예: GitHub의 https://api.githubcopilot.com/mcp)
프라이빗 MCP	Standard Agent Setup (폐쇄망) + 전용 MCP 서브넷 필수	인터넷에 공개되지 않은 MCP 서버에 연결

Standard Agent Setup (BYO VNet)이 전제 조건입니다. Basic 구성에서는 프라이빗 MCP 엔드포인트를 사용할 수 없습니다. - MCP 서버는 **Azure Container Apps 상에 내부 전용 인그레스 (Internal Ingress)**로 배포해야 합니다 (--internal-only true). - Microsoft.App/environments에 위임된 전용 MCP 서브넷이 별도로 필요합니다 (Agent 서브넷과는 별도로 설계해야 함). - 공식 Bicep 템플릿 19-private-network-agents-tools-setup이 MCP 서브넷을 포함한 필요한 네트워크를 일괄 프로비저닝(Provisioning)합니다.

비 스트리밍(Non-streaming) MCP 도구 호출은 100초 후에 타임아웃됩니다. 장시간 처리는 서버 측에서 최적화하거나 분할해야 합니다. - 프라이빗 MCP 호스팅은 Azure Container Apps가 검증된 구성입니다. Function Apps / App Service에서도 동작할 가능성은 있으나 내부 검증은 이루어지지 않았습니다.

설계 시 시사점: 프라이빗 MCP를 사용할 계획이라면, Agent 서브넷 (/24 권장) 외에 MCP 전용 위임 서브넷(Delegated Subnet)을 IP 설계 단계부터 미리 포함해 두어야 합니다. 나중에 추가하는 것은 재배포(Redeployment)를 수반할 수 있습니다.

네트워크 분리가 '아직 미지원/일부 지원'되는 기능이 있습니다. 설계 전에 반드시 확인하십시오.

기능	상태	보충
Traces (트레이스)	미지원	프라이빗 App Insights에서의 VNet 지원 미지원
...		아웃바운드 설정 변경

그 외 IP 설계 시 주의할 점:

• 172.17.0.0/16은 사용 금지 (Docker 브리지 네트워크 예약 용도).
• Private Endpoint는 VNet과 동일 리전, 동일 구독 내에 생성해야 합니다.

Microsoft Foundry의 네트워크 설계는 다음 3가지를 파악하면 정리할 수 있습니다.

• 인바운드(Inbound)는 Private Endpoint (Private Link), **아웃바운드(Outbound)는 VNet 인젝션 (위임 서브넷)**이라는 비대칭 구조입니다. 두 가지가 모두 갖춰져야 비로소 완전 폐쇄망이 됩니다.
• 아웃바운드를 Hub & Spoke 구조로 할지 여부는 조직의 거버넌스(중앙 집중식 방화벽 유무)에 따라 선택합니다. 운영 환경, 대규모, 공통 거버넌스가 필요한 경우 Hub & Spoke 방식이 유력합니다.
• 아웃바운드 설정은 나중에 변경할 수 없습니다. Agent 서브넷 (/24 권장), PE 서브넷, (필요한 경우) 프라이빗 MCP용 서브넷을 IP 설계 단계에서 확정해 두어야 합니다.

특히