Cloud-Native | The .NET Blog

Python, TypeScript, .NET으로 azd 훅 작성하기: 셸 스크립트와의 작별

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

이 게시물은 자동으로 번역되었습니다. 원본 버전을 보려면 여기를 클릭하세요.

완전히 .NET으로 구성된 프로젝트에서 azd 훅을 위해 Bash 스크립트를 작성해야 했던 경험이 있다면, 그 불편함을 잘 알 것이다. 프로젝트의 모든 것이 C#인데, 왜 pre-provisioning 단계 하나 때문에 셸 문법으로 전환해야 하는가.

그 불만이 이제 공식적으로 해결됐다. Azure Developer CLI가 훅의 멀티 언어 지원을 출시했으며, 기대했던 것만큼 훌륭하다.

훅이란

훅은 azd 라이프사이클의 핵심 지점에서 실행되는 스크립트다 — 프로비저닝 전, 배포 후 등. azure.yaml에 정의되며 CLI를 수정하지 않고 커스텀 로직을 주입할 수 있게 해준다.

기존에는 Bash와 PowerShell만 지원됐다. 이제 Python, JavaScript, TypeScript 또는 .NET을 사용할 수 있으며, azd가 나머지를 자동으로 처리한다.

감지 방식

훅을 파일로 가리키기만 하면 azd가 파일 확장자에서 언어를 추론한다:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

추가 설정이 필요 없다. 확장자가 모호한 경우 kind: python (또는 해당 언어)을 명시적으로 지정할 수 있다.

언어별 주요 세부 사항

Python

스크립트 옆 (또는 상위 디렉토리)에 requirements.txt나 pyproject.toml을 놓으면 azd가 자동으로 가상 환경을 생성하고 의존성을 설치한 후 스크립트를 실행한다.

JavaScript와 TypeScript

같은 패턴 — 스크립트 근처에 package.json을 두면 azd가 먼저 npm install을 실행한다. TypeScript의 경우 컴파일 단계나 tsconfig.json 없이 npx tsx를 사용한다.

.NET

두 가지 모드 지원:

프로젝트 모드: 스크립트 옆에 .csproj가 있으면 azd가 자동으로 dotnet restore와 dotnet build를 실행한다.
단일 파일 모드: .NET 10+에서 독립 .cs 파일을 dotnet run script.cs로 직접 실행 가능하다. 프로젝트 파일 불필요.

실행기별 설정

각 언어는 선택적 config 블록을 지원한다:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

.NET 개발자에게 중요한 이유

훅은 azd 기반 프로젝트에서 언어 전환을 강제하는 마지막 장소였다. 이제 앱 코드, 인프라 스크립트, 라이프사이클 훅을 포함한 전체 배포 파이프라인이 하나의 언어로 살 수 있다. 기존 .NET 유틸리티를 훅에서 재사용하고, 공유 라이브러리를 참조하고, 셸 스크립트 유지보수에서 해방될 수 있다.

마무리

작은 변화처럼 보이지만 azd 일상 워크플로우에서 많은 마찰을 제거하는 변화 중 하나다. 훅의 멀티 언어 지원은 지금 바로 사용 가능하다 — 공식 게시물에서 전체 문서를 확인해 보자.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026은 2026년 4월 18일 마드리드 Alcobendas의 Kinépolis Diversia에서 개최됩니다. 스페인 최대의 커뮤니티 주도 Azure 이벤트로, AI 에이전트, Azure 네트워킹, Cosmos DB, Fabric, IoT, 보안 등을 다루는 3개 병렬 트랙에 38명의 발표자가 참여합니다.

이벤트는 08:30부터 18:30까지 진행되며, 키노트, 커피 브레이크, 점심, 클로징 Q&A 세션을 포함합니다.

어젠다 하이라이트

Domando Agentes de IA: Azure AI Foundry와 Azure API Management를 활용한 거버넌스, 도구, API
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: 멀티 에이전트 시스템 실전
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

티켓

등록은 상징적인 기부입니다 — 티켓 전체 금액은 Plan International에 직접 기부되어 전 세계 아동 권리와 평등을 지원합니다. 정원이 제한되어 있으니 서둘러 등록하세요.

Azure Tour 2026

마드리드 외에도 Global Azure Tour 2026은 사라고사, 테네리페, 세비야에서도 개최됩니다.

Aspire 13.2에 MongoDB EF Core와 Azure Data Lake 추가 — 꼭 써봐야 할 두 가지 통합

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

이 글은 자동 번역되었습니다. 원문은 여기를 참조하세요.

Aspire 13.2가 두 가지 새로운 데이터베이스 통합과 함께 출시되었습니다. 주목할 만한 것은 MongoDB Entity Framework Core와 Azure Data Lake Storage입니다. Aspire 앱에서 MongoDB와 EF Core를 사용하고 싶었거나, 서비스 디스커버리가 포함된 Data Lake 워크로드를 연결해야 했다면, 이번 릴리스가 둘 다 제공합니다.

Aspire에서 MongoDB가 EF Core를 만나다

이것이 제가 가장 기대하고 있는 통합입니다. Aspire는 한동안 MongoDB를 지원해 왔지만, 항상 원시 드라이버였습니다 — EF Core 없이, DbContext 없이, 문서에 대한 LINQ 쿼리 없이. 이제 MongoDB에서 완전한 EF Core 경험을 얻을 수 있으며, Aspire의 자동 헬스 체크와 서비스 디스커버리도 함께 제공됩니다.

설정은 전형적인 Aspire 패턴을 따릅니다. AppHost에서:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

그런 다음 소비 프로젝트에서 EF Core 통합을 추가합니다:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

그리고 DbContext를 등록합니다:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

이후로는 표준 EF Core입니다. 엔티티를 정의하고, 다른 프로바이더와 마찬가지로 DbContext를 사용하면 됩니다. 커넥션 풀링, OpenTelemetry 트레이스, 헬스 체크는 통합이 백그라운드에서 처리합니다.

원시 드라이버로 MongoDB를 사용하면서 커넥션 문자열을 수동으로 설정하던 .NET 개발자들에게 이것은 반가운 개선입니다. Aspire의 서비스 디스커버리를 잃지 않으면서 완전한 EF Core 추상화를 얻을 수 있습니다.

Azure Data Lake Storage 합류

두 번째 큰 추가 사항은 Azure Data Lake Storage (ADLS) 통합입니다. 데이터 파이프라인, ETL 프로세스 또는 분석 플랫폼을 구축하고 있다면, 이제 다른 Aspire 의존성과 동일한 방식으로 Data Lake 리소스를 연결할 수 있습니다.

AppHost에서:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

소비 프로젝트에서:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

수동 커넥션 문자열 관리도, 크레덴셜 찾기도 필요 없습니다. Aspire가 리소스를 프로비저닝하고 주입합니다. 운영 데이터와 분석 워크로드를 모두 다루는 클라우드 네이티브 .NET 앱을 구축하는 우리에게, Data Lake가 Aspire 모델에서 일급 시민처럼 느껴지게 됩니다.

사소하지만 중요한 수정 사항

주요 기능 외에도 몇 가지 주목할 만한 개선 사항이 있습니다:

MongoDB 커넥션 문자열 수정 — 데이터베이스 이름 앞의 슬래시가 이제 올바르게 처리됩니다. 우회 방법을 사용하고 있었다면 이제 제거할 수 있습니다
SQL Server 내보내기 — Aspire.Hosting.SqlServer가 이제 더 세밀한 제어를 위한 추가 서버 구성 옵션을 내보냅니다
에뮬레이터 업데이트 — ServiceBus 에뮬레이터 2.0.0, App Configuration 에뮬레이터 1.0.2, CosmosDB 프리뷰 에뮬레이터에 레디니스 체크 추가
Azure Managed Redis — 이제 기본적으로 rediss://(Redis Secure)를 사용하여 연결이 기본 암호화됩니다

마지막 항목은 미묘하지만 중요합니다 — 기본 암호화 Redis는 프로덕션에서 설정해야 할 것이 하나 줄어든다는 의미입니다.

마무리

Aspire 13.2는 점진적인 릴리스이지만, MongoDB EF Core와 Data Lake 통합은 실질적인 공백을 채웁니다. Aspire에서 MongoDB에 대한 적절한 EF Core 지원을 기다리고 있었거나, Data Lake를 일급 의존성으로 필요로 했다면, 13.2로 업그레이드하고 사용해 보세요. aspire add 명령이 필요한 모든 것을 스캐폴딩합니다.

전체 릴리스 노트에서 자세한 내용을 확인하고, 통합 갤러리에서 전체 목록을 살펴보세요.

Azure Smart Tier GA 출시 — 수명 주기 규칙 없이 Blob Storage 비용 자동 최적화

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

이 글은 자동 번역되었습니다. 원문은 여기를 참조하세요.

Azure Blob Storage 수명 주기 정책을 조정하는 데 시간을 쏟았다가 액세스 패턴이 바뀌면서 다 무너지는 걸 본 적이 있다면, 이 글이 딱 맞습니다. Microsoft가 Azure Blob 및 Data Lake Storage용 smart tier의 정식 출시를 발표했습니다 — 실제 사용량을 기반으로 hot, cool, cold 티어 간에 객체를 자동으로 이동하는 완전 관리형 티어링 기능입니다.

Smart tier가 실제로 하는 일

개념은 간단합니다. smart tier는 스토리지 계정 내 각 객체의 마지막 액세스 시간을 지속적으로 평가합니다. 자주 액세스하는 데이터는 hot에 유지되고, 비활성 데이터는 30일 후 cool로, 그리고 60일 후 cold로 이동합니다. 데이터에 다시 액세스하면 즉시 hot으로 승격됩니다. 사이클이 다시 시작됩니다.

구성할 수명 주기 규칙 없음. 액세스 패턴 예측 없음. 수동 튜닝 없음.

프리뷰 기간 동안 Microsoft는 smart tier로 관리되는 용량의 50% 이상이 실제 액세스 패턴을 기반으로 자동으로 더 차가운 티어로 이동했다고 보고했습니다. 대규모 스토리지 계정에 대해 의미 있는 비용 절감입니다.

.NET 개발자에게 왜 중요한가

로그, 텔레메트리, 분석 데이터, 또는 어떤 종류든 계속 늘어나는 데이터 자산을 생성하는 애플리케이션을 구축하고 있다면 — 솔직히, 안 그런 사람이 있나요? — 스토리지 비용은 빠르게 쌓입니다. 기존 방식은 수명 주기 관리 정책을 작성하고, 테스트하고, 앱의 액세스 패턴이 변경되면 다시 조정하는 것이었습니다. Smart tier는 그 전체 워크플로를 제거합니다.

도움이 되는 실용적인 시나리오들:

애플리케이션 텔레메트리 및 로그 — 디버깅 중에는 hot, 몇 주 후에는 거의 액세스하지 않음
데이터 파이프라인 및 ETL 출력 — 처리 중에는 집중적으로 액세스, 이후에는 대부분 cold
사용자 생성 콘텐츠 — 최근 업로드는 hot, 오래된 콘텐츠는 점차 냉각
백업 및 아카이브 데이터 — 컴플라이언스를 위해 가끔 액세스, 대부분 유휴 상태

설정 방법

Smart tier 활성화는 일회성 구성입니다:

새 계정: 스토리지 계정 생성 시 smart tier를 기본 액세스 티어로 선택 (영역 중복 필요)
기존 계정: blob 액세스 티어를 현재 기본값에서 smart tier로 변경

128 KiB보다 작은 객체는 hot에 유지되며 모니터링 요금이 발생하지 않습니다. 그 외의 모든 객체는 티어 전환 요금 없이, 조기 삭제 수수료 없이, 데이터 검색 비용 없이 표준 hot/cool/cold 용량 요금을 지불합니다. 객체당 월별 모니터링 요금이 오케스트레이션을 커버합니다.

알아야 할 트레이드오프

Smart tier의 티어링 규칙은 고정입니다 (30일 → cool, 90일 → cold). 사용자 정의 임계값이 필요한 경우 — 예를 들어 특정 워크로드에 대해 7일 후 cool로 이동 — 수명 주기 규칙이 여전히 올바른 선택입니다. 그리고 둘 다 혼합하지 마세요: smart tier로 관리되는 객체에 수명 주기 규칙을 사용하면 충돌할 수 있으므로 피하세요.

마무리

혁명적이진 않지만, 실제 운영상의 골칫거리를 해결합니다. 성장하는 blob storage 계정을 관리하고 있고 수명 주기 정책 유지 관리에 지쳤다면, smart tier를 활성화하고 Azure에 맡기세요. 현재 거의 모든 영역 퍼블릭 클라우드 리전에서 사용 가능합니다.

Azure에서 AI 에이전트를 어디에 호스팅해야 할까? 실용적인 의사결정 가이드

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

이 글은 자동 번역되었습니다. 원문은 여기를 참조하세요.

지금 .NET으로 AI 에이전트를 구축하고 있다면, 아마 눈치챘을 겁니다: Azure에서 호스팅하는 방법이 정말 많다는 것을. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — 실제로 하나를 선택해야 할 때까지는 모두 합리적으로 들립니다. Microsoft가 방금 Azure AI 에이전트 호스팅에 대한 종합 가이드를 발표했고, .NET 개발자의 실용적인 관점에서 정리해 보겠습니다.

6가지 옵션 한눈에 보기

옵션	최적 용도	관리 대상
Container Apps	K8s 복잡성 없이 전체 컨테이너 제어	관측성, 상태, 라이프사이클
AKS	엔터프라이즈 컴플라이언스, 멀티 클러스터, 커스텀 네트워킹	모든 것 (그것이 포인트)
Azure Functions	이벤트 기반 단기 에이전트 작업	거의 없음 — 진정한 서버리스
App Service	단순 HTTP 에이전트, 예측 가능한 트래픽	배포, 스케일링 설정
Foundry Agents	포털/SDK를 통한 코드 불필요 에이전트	거의 없음
Foundry Hosted Agents	관리형 인프라의 커스텀 프레임워크 에이전트	에이전트 코드만

처음 4개는 범용 컴퓨팅입니다 — 에이전트를 실행할 수는 있지만 그것을 위해 설계된 것은 아닙니다. 마지막 2개는 에이전트 네이티브로, 대화, 도구 호출, 에이전트 라이프사이클을 일급 개념으로 이해합니다.

Foundry Hosted Agents — .NET 에이전트 개발자를 위한 최적점

제 주목을 끈 부분입니다. Foundry Hosted Agents는 정확히 중간에 위치합니다: 자신의 코드를 실행할 수 있는 유연성(Semantic Kernel, Agent Framework, LangGraph — 무엇이든)을 얻으면서 플랫폼이 인프라, 관측성, 대화 관리를 처리합니다.

핵심은 Hosting Adapter입니다 — 에이전트 프레임워크를 Foundry 플랫폼에 연결하는 얇은 추상화 레이어입니다. Microsoft Agent Framework의 경우:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

이것이 호스팅의 전부입니다. 어댑터가 프로토콜 변환, server-sent events를 통한 스트리밍, 대화 이력, OpenTelemetry 트레이싱을 자동으로 처리합니다. 커스텀 미들웨어도, 수동 배관 작업도 필요 없습니다.

배포가 진짜 간단합니다

이전에 Container Apps에 에이전트를 배포해 봤고 작동하지만, 상태 관리와 관측성을 위한 글루 코드를 많이 작성하게 됩니다. Hosted Agents와 azd를 사용하면:

# AI 에이전트 익스텐션 설치
azd ext install azure.ai.agents

# 템플릿에서 초기화
azd ai agent init

# 빌드, 푸시, 배포 — 완료
azd up

이 하나의 azd up이 컨테이너를 빌드하고, ACR에 푸시하고, Foundry 프로젝트를 프로비저닝하고, 모델 엔드포인트를 배포하고, 에이전트를 시작합니다. 다섯 단계가 하나의 명령어로 압축됩니다.

내장 대화 관리

프로덕션에서 가장 많은 시간을 절약하는 부분입니다. 자체 대화 상태 저장소를 구축하는 대신 Hosted Agents가 네이티브로 처리합니다:

# 영구 대화 생성
conversation = openai_client.conversations.create()

# 첫 번째 턴
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# 두 번째 턴 — 컨텍스트 유지
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Redis 불필요. Cosmos DB 세션 스토어 불필요. 메시지 직렬화를 위한 커스텀 미들웨어 불필요. 플랫폼이 그냥 처리합니다.

나의 결정 프레임워크

6가지 옵션을 모두 검토한 후의 빠른 멘탈 모델:

인프라가 필요 없다면? → Foundry Agents (포털/SDK, 컨테이너 없음)
커스텀 에이전트 코드가 있지만 관리형 호스팅을 원한다면? → Foundry Hosted Agents
이벤트 기반 단기 에이전트 작업이 필요하다면? → Azure Functions
K8s 없이 최대한의 컨테이너 제어가 필요하다면? → Container Apps
엄격한 컴플라이언스와 멀티 클러스터가 필요하다면? → AKS
예측 가능한 트래픽의 간단한 HTTP 에이전트라면? → App Service

Semantic Kernel이나 Microsoft Agent Framework로 구축하는 대부분의 .NET 개발자에게 Hosted Agents가 적절한 출발점일 것입니다. Kubernetes를 관리하거나 자체 관측성 스택을 구축하지 않고도 scale-to-zero, 내장 OpenTelemetry, 대화 관리, 프레임워크 유연성을 얻을 수 있습니다.

마무리

Azure의 에이전트 호스팅 환경은 빠르게 성숙하고 있습니다. 오늘 새 AI 에이전트 프로젝트를 시작한다면, 습관적으로 Container Apps나 AKS를 선택하기 전에 Foundry Hosted Agents를 진지하게 고려해 보세요. 관리형 인프라가 실질적인 시간을 절약하고, hosting adapter 패턴으로 프레임워크 선택을 유지할 수 있습니다.

Microsoft의 전체 가이드와 Foundry Samples 저장소에서 작동하는 예제를 확인하세요.

KubeCon Europe 2026: .NET 개발자가 실제로 알아야 할 것

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

이 게시물은 자동 번역되었습니다. 원본은 여기를 클릭하세요.

거대한 발표 글이 올라오고 스크롤하면서 “멋지긴 한데, 이게 실제로 나한테 뭘 바꿔주는 거지?“라고 생각하는 그 느낌 아시죠? 매 KubeCon 시즌마다 저한테 벌어지는 일입니다.

Microsoft가 방금 KubeCon Europe 2026 전체 요약을 발표했는데요 — Brendan Burns 본인이 직접 작성했습니다 — 솔직히? 진짜 내용이 있습니다. 기능 체크리스트가 아니라, 프로덕션에서 운영하는 방식을 바꿔주는 운영 개선 사항들입니다.

.NET 개발자로서 진짜 중요한 것만 정리해 보겠습니다.

서비스 메시 세금 없는 mTLS

서비스 메시의 문제점: 모두가 보안 보장을 원하지만, 운영 오버헤드는 아무도 원하지 않습니다. AKS가 드디어 이 격차를 메우고 있습니다.

Azure Kubernetes Application Network은 상호 TLS, 애플리케이션 인식 인가, 트래픽 텔레메트리를 제공합니다 — 사이드카가 무거운 풀 메시를 배포할 필요 없이요. Advanced Container Networking Services의 Cilium mTLS와 결합하면, X.509 인증서와 SPIRE 신원 관리를 사용한 암호화된 pod 간 통신을 얻을 수 있습니다.

실제로 의미하는 것: ASP.NET Core API가 백그라운드 워커와 통신하고, gRPC 서비스가 서로 호출하는 것 — 모두 네트워크 수준에서 암호화되고 신원 검증되며, 애플리케이션 코드 변경은 제로. 이건 큽니다.

ingress-nginx에서 마이그레이션하는 팀을 위해, Meshless Istio를 사용한 Application Routing도 있으며 Kubernetes Gateway API를 완전히 지원합니다. 사이드카 없음. 표준 기반. 점진적 마이그레이션을 위한 ingress2gateway 도구도 함께 출시되었습니다.

뒤늦은 생각이 아닌 GPU 관측성

.NET 서비스와 함께 AI 추론을 실행하고 있다면(솔직히, 누가 시작하지 않고 있겠어요?), GPU 모니터링 사각지대를 경험했을 겁니다. CPU/메모리 대시보드는 훌륭했는데, GPU는… 수동 익스포터 설정 없이는 아무것도 없었죠.

AKS가 이제 GPU 메트릭을 네이티브로 노출합니다 — 관리형 Prometheus와 Grafana에서. 같은 스택, 같은 대시보드, 같은 알림 파이프라인. 커스텀 익스포터도 서드파티 에이전트도 불필요.

네트워크 측에서는, HTTP, gRPC, Kafka 트래픽에 대한 플로우별 가시성이 원클릭 Azure Monitor 경험과 함께 추가되었습니다. IP, 포트, 워크로드, 플로우 방향, 정책 결정 — 모두 내장 대시보드에서.

그리고 두 번 쳐다보게 만든 것: agentic container networking이 자연어로 클러스터의 네트워크 상태에 대해 질문할 수 있는 웹 UI를 추가합니다. “Pod X가 서비스 Y에 도달하지 못하는 이유는?” → 라이브 텔레메트리에서 읽기 전용 진단. 새벽 2시에 진짜 유용합니다.

박사 학위 필요 없는 크로스 클러스터 네트워킹

멀티 클러스터 Kubernetes는 역사적으로 “자체 네트워크 접착제를 가져오세요” 경험이었습니다. Azure Kubernetes Fleet Manager가 이제 관리형 Cilium 클러스터 메시를 통한 크로스 클러스터 네트워킹을 제공합니다:

AKS 클러스터 간 통합 연결
크로스 클러스터 디스커버리를 위한 글로벌 서비스 레지스트리
클러스터마다 반복하지 않고 중앙에서 관리되는 설정

복원력이나 컴플라이언스를 위해 여러 리전에서 .NET 마이크로서비스를 실행하고 있다면, 많은 취약한 커스텀 접착제를 대체합니다. West Europe의 서비스 A가 메시를 통해 East US의 서비스 B를 발견하고 호출할 수 있으며, 일관된 라우팅과 보안 정책이 적용됩니다.

용기가 필요 없는 업그레이드

솔직히 — 프로덕션에서의 Kubernetes 업그레이드는 스트레스입니다. “업그레이드하고 기도하기"가 너무 많은 팀의 사실상 전략이었고, 클러스터가 버전에서 뒤처지는 주된 이유입니다.

두 가지 새로운 기능이 이것을 바꿉니다:

Blue-green 에이전트 풀 업그레이드는 새 설정으로 병렬 노드 풀을 생성합니다. 동작을 검증하고, 트래픽을 점진적으로 이동하고, 깨끗한 롤백 경로를 유지하세요. 프로덕션 노드에서의 인플레이스 변경은 이제 끝.

에이전트 풀 롤백은 업그레이드가 잘못된 후 클러스터를 재구축하지 않고 노드 풀을 이전 Kubernetes 버전과 노드 이미지로 되돌릴 수 있게 합니다.

함께 사용하면, 운영자에게 업그레이드 생명주기에 대한 진정한 통제력을 제공합니다. .NET 팀에게 중요한 이유는 플랫폼 속도가 새로운 런タ임, 보안 패치, 네트워크 기능을 얼마나 빨리 채택하는지를 직접 제어하기 때문입니다.

AI 워크로드가 Kubernetes의 일급 시민이 되다

업스트림 오픈소스 작업도 마찬가지로 중요합니다. Dynamic Resource Allocation (DRA)이 Kubernetes 1.36에서 GA가 되어, GPU 스케줄링이 우회 방법이 아닌 진정한 일급 기능이 되었습니다.

주목할 프로젝트들:

프로젝트	하는 일
AI Runway	추론을 위한 공통 Kubernetes API — K8s를 몰라도 모델 배포 가능, HuggingFace 검색과 비용 추정 포함
HolmesGPT	클라우드 네이티브를 위한 에이전트 문제 해결 — CNCF Sandbox 프로젝트로 합류
Dalec	SBOM 생성을 포함한 선언적 컨테이너 이미지 빌드 — 빌드 단계에서 CVE 감소

방향은 명확합니다: 여러분의 .NET API, Semantic Kernel 오케스트레이션 레이어, 추론 워크로드 모두 하나의 일관된 플랫폼 모델에서 실행되어야 합니다. 거기에 도달하고 있습니다.

이번 주부터 시작한다면

팀에서 이러한 변경 사항을 평가하고 있다면, 제 솔직한 우선순위 목록:

관측성 먼저 — 비프로덕션 클러스터에서 GPU 메트릭과 네트워크 플로우 로그를 활성화하세요. 놓치고 있던 것을 확인하세요.
Blue-green 업그레이드 테스트 — 다음 프로덕션 클러스터 업그레이드 전에 롤백 워크플로우를 테스트하세요. 프로세스에 대한 신뢰를 구축하세요.
신원 인식 네트워킹 파일럿 — 내부 서비스 경로 하나를 선택해서 Cilium으로 mTLS를 활성화하세요. 오버헤드를 측정하세요 (스포일러: 최소).
Fleet Manager 평가 — 두 개 이상의 클러스터를 운영한다면, 크로스 클러스터 네트워킹은 커스텀 접착제 감소만으로도 투자 대비 이득.

작은 실험, 빠른 피드백. 항상 정답인 방법입니다.

마무리

KubeCon 발표는 압도적일 수 있지만, 이번 배치는 AKS의 .NET 팀에게 진정으로 바늘을 움직입니다. 메시 오버헤드 없는 더 나은 네트워크 보안, 진짜 GPU 관측성, 더 안전한 업그레이드, 그리고 더 강력한 AI 인프라 기반.

이미 AKS를 사용하고 있다면, 운영 기준선을 강화할 좋은 시점입니다. .NET 워크로드를 Kubernetes로 이동할 계획이라면 — 플랫폼이 훨씬 더 프로덕션에 준비되었습니다.