Cloud | The .NET Blog

Azure Developer CLI (azd) 2026년 4월 업데이트

Emiliano Montesdeoca — Fri, 08 May 2026 00:00:00 +0000

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

Azure Developer CLI (azd)는 2026년 4월에 5개의 릴리스를 출시했습니다 (1.23.14에서 1.24.2). 큰 주제는 Bash와 PowerShell뿐만 아니라 Python, JavaScript, TypeScript, .NET에서도 실행되는 훅입니다.

azure.yaml의 다중 언어 훅

훅은 이제 셸 스크립트 외에도 .py, .js, .ts, .cs 파일을 가리킬 수 있습니다. 각 언어에 대해 자동 종속성 해결이 제공됩니다.

Python — requirements.txt 또는 pyproject.toml을 감지하고, virtualenv를 생성하며, 실행 전에 종속성을 설치합니다. virtualEnvName으로 환경 이름을 구성합니다.
JavaScript / TypeScript — package.json을 감지하고 자동으로 npm install을 실행합니다. TypeScript는 컴파일 단계 없이 npx tsx를 통해 실행됩니다. packageManager 구성 블록으로 패키지 관리자를 선택합니다.
.NET — dotnet run으로 .cs 파일을 실행합니다. .NET 10+에서 단일 파일 스크립트를 지원합니다. configuration/framework 블록을 통해 대상 프레임워크를 구성합니다.

이는 이미 이러한 언어 중 하나에서 작업하는 팀이 프로비저닝 수명 주기 이벤트를 연결하기 위해 별도의 Bash 또는 PowerShell 훅을 유지할 필요가 없음을 의미합니다.

azd update 공개 미리 보기 출시

azd update가 이제 모든 플랫폼에서 공개 미리 보기로 제공됩니다. azd가 처음 설치된 방법에 관계없이 단일 명령으로 업데이트를 처리합니다. Homebrew, WinGet, MSI 경로를 개별적으로 추적할 필요가 없습니다.

AZD_NON_INTERACTIVE를 통한 비대화형 모드

AZD_NON_INTERACTIVE=true를 설정하거나 --non-interactive / --no-prompt를 사용하면 필요한 입력을 자동으로 해결할 수 없을 때 CI/CD 파이프라인에서 일관되고 결정론적인 오류가 발생합니다. 이전에는 명령 간에 동작이 일치하지 않았습니다.

AI 모델 할당량 프리플라이트 검사

azd provision은 AI 모델 리소스를 프로비저닝하기 전에 Azure Cognitive Services 할당량을 검증합니다. 할당량 제한으로 실패할 배포는 이제 프로비저닝 도중이 아니라 프로세스 초기에 오류를 표시합니다.

Copilot 문제 해결의 “이 오류 수정”

azd Copilot 문제 해결 통합이 제안된 수정 사항을 직접 적용하는 기능을 갖추었습니다. 단순히 설명하는 것이 아니라, 에이전트가 수정 가능한 문제를 식별하면 그 자리에서 변경을 적용할 수 있습니다.

사용자 지정 프로비저닝 공급자 및 Key Vault 비밀 확인자

확장 작성자는 이제 WithProvisioningProvider()를 사용하여 대체 인프라 백엔드를 등록할 수 있습니다. 별도로, azd는 확장에 구성을 전달하기 전에 @Microsoft.KeyVault(...) 참조를 자동으로 해결하여 사용자 지정 공급자에서 수동 비밀 확인이 필요 없어집니다.

템플릿 및 감시 모드 제외

두 개의 새로운 ignore 파일이 파일 처리에 대한 세밀한 제어를 제공합니다.

.azdignore — 기여자 전용 파일(문서, CI 구성)을 템플릿 복사본에서 제외하여 최종 사용자가 깔끔한 프로젝트 스캐폴드를 얻을 수 있도록 합니다.
.azdxignore — azd x watch 중 재빌드 트리거에서 디렉터리를 제외하여 반복 개발 중 노이즈를 줄입니다.

예약된 이름 프리플라이트 및 docker.network 옵션

azd는 프로비저닝이 시작되기 전에 예측된 리소스 이름에 Azure 예약어(MICROSOFT, WINDOWS, 또는 LOGIN 접두사)가 포함될 경우 경고합니다. 새로운 docker.network 옵션은 docker build에 --network를 전달하며, 특정 Docker 네트워크가 필요한 기업 프록시 환경에서 유용합니다.

보안 수정

Windows MSI 패키지에 코드 서명 검증이 포함됩니다. 별도의 수정으로 확장 명령 경계를 넘어 값을 노출할 수 있는 환경 변수 누수가 해결되었습니다.

바쁜 달이었습니다. 다중 언어 훅 지원은 특히 주로 Bash로 작업하지 않는 팀의 실질적인 마찰 지점을 없애줍니다. 5개 릴리스 전체의 완전한 변경 내역은 전체 릴리스 노트를 참조하세요.

Azure에서의 AI 실험이 돈을 태우고 있다 — 해결 방법은 이것이다

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

이 글은 자동 번역되었습니다. 원문은 여기에서 확인하세요.

지금 Azure에서 AI 기반 앱을 구축하고 있다면, 아마 한 가지 눈치챈 게 있을 겁니다: 클라우드 청구서가 예전과 다르게 보인다는 것입니다. 단순히 높아진 게 아니라 — 이상해졌습니다. 들쭉날쭉하고, 예측하기 어렵습니다.

Microsoft가 여전히 중요한 클라우드 비용 최적화 원칙에 대한 훌륭한 글을 방금 게시했는데, 솔직히 이보다 더 좋은 타이밍은 없었을 겁니다. AI 워크로드가 비용에 관한 게임의 규칙을 바꿔놓았으니까요.

AI 워크로드가 다른 이유

핵심은 이겁니다. 전통적인 .NET 워크로드는 비교적 예측 가능합니다. App Service 티어를 알고, SQL DTU를 알고, 월별 지출을 꽤 정확하게 추정할 수 있습니다. AI 워크로드는요? 그렇지 않습니다.

어떤 모델이 맞는지 여러 모델을 테스트하고 있습니다. 파인튜닝을 위해 GPU 지원 인프라를 올리고 있습니다. 프롬프트 길이와 사용자 행동에 따라 토큰 소비가 크게 달라지는 Azure OpenAI API를 호출하고 있습니다. 모든 실험에는 실제 비용이 들고, 올바른 접근 방식을 찾기까지 수십 번을 실행해야 할 수도 있습니다.

이 예측 불가능성이 바로 비용 최적화가 중요한 이유입니다 — 나중에 생각할 것이 아니라, 첫날부터.

관리 vs. 최적화 — 차이를 알아야 합니다

기사에서 개발자들이 간과하는 것 같은 구분이 있습니다: 비용 관리와 비용 최적화에는 차이가 있다는 것입니다.

관리는 추적과 보고입니다. Azure Cost Management에서 예산을 설정하고, 알림을 받고, 대시보드를 봅니다. 이건 기본 중의 기본입니다.

최적화는 실제로 결정을 내리는 곳입니다. 정말 S3 티어가 필요한 건지, S1으로 부하를 감당할 수 있는 건지? 항상 켜져 있는 컴퓨트 인스턴스가 주말에 놀고 있지는 않은지? 학습 작업에 스팟 인스턴스를 사용할 수는 없는지?

.NET 개발자로서 우리는 코드에 집중하고 인프라 결정은 “운영팀"에 맡기는 경향이 있습니다. 하지만 Azure에 배포하고 있다면, 그 결정은 여러분의 결정이기도 합니다.

실제로 효과가 있는 것

기사와 제 개인적인 경험을 바탕으로, 실제로 차이를 만드는 것들입니다:

무엇에 얼마를 쓰고 있는지 파악하세요. 리소스에 태그를 달아주세요. 진심입니다. 어떤 프로젝트나 실험이 예산을 잡아먹고 있는지 구분할 수 없다면, 아무것도 최적화할 수 없습니다. 적절한 태깅이 된 Azure Cost Management가 가장 좋은 친구입니다.

실험하기 전에 가드레일을 설정하세요. Azure Policy를 사용해 dev/test 환경에서 비싼 SKU를 제한하세요. Azure OpenAI 배포에 지출 한도를 설정하세요. 누군가가 주말 동안 GPU 클러스터를 켜둔 채 놔뒀다는 걸 청구서가 도착하고 나서야 알게 되는 일은 없어야 합니다.

지속적으로 적정 규모를 유지하세요. 프로토타이핑 중에 선택한 그 VM? 프로덕션에는 아마 맞지 않을 겁니다. Azure Advisor가 추천을 해줍니다 — 실제로 살펴보세요. 1년에 한 번이 아니라 매달 검토하세요.

라이프사이클을 생각하세요. 개발 리소스는 종료되어야 합니다. 테스트 환경이 24시간 돌아갈 필요는 없습니다. 자동 종료 정책을 사용하세요. AI 워크로드의 경우 특히, 컴퓨트를 계속 켜두는 대신 실행당 과금되는 서버리스 옵션을 고려하세요.

비용만이 아닌 가치를 측정하세요. 이건 잊기 쉽습니다. 비용은 더 들지만 훨씬 더 나은 결과를 제공하는 모델이 올바른 선택일 수 있습니다. 목표는 가장 적게 쓰는 것이 아니라 — 똑똑하게 쓰는 것입니다.

핵심 요약

클라우드 비용 최적화는 일회성 정리가 아닙니다. 습관입니다. AI 워크로드로 인해 지출이 그 어느 때보다 예측하기 어려워진 지금, 이 습관을 일찍 들이면 나중에 고통스러운 깜짝 놀랄 일을 방지할 수 있습니다.

Azure에서 구축하는 .NET 개발자라면, 클라우드 청구서를 코드 다루듯 대하기 시작하세요 — 정기적으로 리뷰하고, 지저분해지면 리팩토링하고, 비용을 이해하지 않은 채 절대 배포하지 마세요.