Devops | The .NET Blog

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026은 2026년 5월 11일~15일 런던의 Barbican Centre에서 개최됩니다. 3일간의 핵심 컨퍼런스는 화요일부터 목요일까지이며, 월요일과 금요일에는 선택적 전일 워크숍이 있습니다.

78개 세션과 14개 워크숍을 갖춘 유럽에서 가장 알찬 개발자 컨퍼런스 중 하나입니다.

주제

아키텍처적 사고
C# 13에서의 함수형 코드
서버리스 디자인
시맨틱 AI
Azure Kubernetes Services
린 DevOps 전략
모델 컨텍스트 프로토콜 (MCP)
.NET에서의 에이전틱 AI
모놀리스 리팩토링
LLM으로 더 빠르게 코딩
포스트 양자 세계의 암호학
로컬 퍼스트 개발

발표자

Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm, Raju Gandhi를 포함한 세계적 수준의 라인업.

티켓 및 정보

SDD 2025 참가자의 98%가 전체 경험을 좋음, 매우 좋음 또는 우수로 평가했습니다.

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 DevOps Server 2026년 4월 패치 — PR 완료 수정 및 보안 업데이트

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

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

셀프 호스팅 Azure DevOps Server를 운영하는 팀들에게 빠른 안내입니다. Microsoft가 세 가지 수정 사항을 포함한 2026년 4월 패치 3을 릴리스했습니다.

수정된 내용

Pull Request 완료 실패 — 작업 항목 자동 완료 중 null 참조 예외로 인해 PR 병합이 실패할 수 있었습니다. 무작위 PR 완료 오류를 겪었다면, 이것이 원인일 가능성이 높습니다
로그아웃 리디렉션 유효성 검사 — 잠재적인 악성 리디렉션을 방지하기 위해 로그아웃 시 유효성 검사가 개선되었습니다. 빠르게 적용할 가치가 있는 보안 수정입니다
GitHub Enterprise Server PAT 연결 — GitHub Enterprise Server에 대한 Personal Access Token 연결 생성이 작동하지 않았는데, 이제 복원되었습니다

업데이트 방법

패치 3을 다운로드하고 설치 프로그램을 실행하세요. 패치가 적용되었는지 확인하려면:

<patch-installer>.exe CheckInstall

Azure DevOps Server를 온프레미스에서 운영하고 있다면, Microsoft는 보안과 안정성 모두를 위해 최신 패치를 유지할 것을 강력히 권장합니다. 전체 세부 사항은 릴리스 노트를 확인하세요.

에이전틱 플랫폼 엔지니어링이 현실이 되고 있다 — Git-APE가 방법을 보여준다

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

플랫폼 엔지니어링은 컨퍼런스에서는 멋지게 들리지만 보통 “내부 포털과 Terraform 래퍼를 만들었습니다"를 의미하는 용어 중 하나였습니다. 진정한 약속 — 실제로 안전하고, 거버넌스가 적용되고, 빠른 셀프 서비스 인프라 — 는 항상 몇 발짝 떨어져 있었습니다.

Azure 팀이 에이전틱 플랫폼 엔지니어링 시리즈의 파트 2를 발표했는데, 이번에는 실전 구현에 대한 내용입니다. Git-APE라고 부릅니다 (네, 약어는 의도적입니다). 이것은 GitHub Copilot 에이전트와 Azure MCP 서버를 사용하여 자연어 요청을 검증되고 배포된 인프라로 전환하는 오픈소스 프로젝트입니다.

Git-APE가 실제로 하는 것

핵심 아이디어: 개발자가 Terraform 모듈을 배우거나, 포털 UI를 탐색하거나, 플랫폼 팀에 티켓을 올리는 대신, Copilot 에이전트와 대화합니다. 에이전트가 의도를 해석하고, Infrastructure-as-Code를 생성하고, 정책에 대해 검증하고, 배포합니다 — 모두 VS Code 안에서.

설정은 이렇습니다:

git clone https://github.com/Azure/git-ape
cd git-ape

VS Code에서 워크스페이스를 열면 에이전트 설정 파일이 GitHub Copilot에 의해 자동 검색됩니다. 에이전트와 직접 상호작용합니다:

@git-ape deploy a function app with storage in West Europe

에이전트는 내부적으로 Azure MCP Server를 사용하여 Azure 서비스와 상호작용합니다. VS Code 설정의 MCP 구성이 특정 기능을 활성화합니다:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

왜 이게 중요한가

Azure에서 개발하는 우리에게 이것은 플랫폼 엔지니어링 대화를 “포털을 어떻게 만들까"에서 “가드레일을 API로 어떻게 기술할까"로 전환시킵니다. 플랫폼의 인터페이스가 AI 에이전트가 되면, 제약 조건과 정책의 품질이 곧 제품이 됩니다.

파트 1 블로그는 이론을 제시했습니다: 잘 기술된 API, 제어 스키마, 그리고 명시적인 가드레일이 플랫폼을 에이전트 대응(agent-ready)으로 만듭니다. 파트 2는 실제 도구를 제공하여 이것이 작동한다는 것을 증명합니다. 에이전트는 리소스를 무작정 생성하지 않습니다 — 모범 사례에 대해 검증하고, 명명 규칙을 존중하며, 조직의 정책을 적용합니다.

정리도 마찬가지로 간단합니다:

@git-ape destroy my-resource-group

내 생각

솔직히 — 이건 특정 도구보다는 패턴에 대한 이야기입니다. Git-APE 자체는 데모/참조 아키텍처입니다. 하지만 근본적인 아이디어 — 플랫폼의 인터페이스로서의 에이전트, 프로토콜로서의 MCP, 호스트로서의 GitHub Copilot — 이것이 엔터프라이즈 개발자 경험이 향하는 방향입니다.

내부 도구를 에이전트 친화적으로 만드는 방법을 찾는 플랫폼 팀이라면, 이보다 나은 출발점은 없습니다. 그리고 .NET 개발자로서 이것이 자신의 세계와 어떻게 연결되는지 궁금하다면: Azure MCP Server와 GitHub Copilot 에이전트는 모든 Azure 워크로드에서 작동합니다. ASP.NET Core API, .NET Aspire 스택, 컨테이너화된 마이크로서비스 — 모두가 에이전틱 배포 플로우의 대상이 될 수 있습니다.

마무리

Git-APE는 에이전틱 플랫폼 엔지니어링 실전의 초기이지만 구체적인 모습입니다. 저장소를 클론하고, 데모를 시도하고, 에이전트가 안전하게 사용할 수 있도록 플랫폼의 API와 정책이 어떤 모습이어야 하는지 생각해 보세요.

자세한 워크스루와 데모 비디오는 전체 포스트를 읽어보세요.

Azure DevOps가 드디어 모두가 불평하던 Markdown 편집기를 고쳤다

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

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

Azure Boards를 사용한다면 아마 이런 경험이 있을 겁니다: 작업 항목 설명을 읽고 있는데, 인수 기준을 확인하는 중에 실수로 더블클릭을 합니다. 쾅 — 편집 모드에 들어갔습니다. 아무것도 편집하고 싶지 않았는데. 그냥 읽고 있었을 뿐인데.

Dan Hellem이 수정을 발표했는데, 작아 보이지만 일상 워크플로에서 진짜 마찰을 제거하는 변경입니다.

무엇이 바뀌었나

작업 항목 텍스트 필드의 Markdown 편집기가 이제 기본적으로 미리보기 모드로 열립니다. 콘텐츠를 읽고 상호작용할 수 있습니다 — 링크 따라가기, 포맷 확인 — 실수로 편집 모드에 들어갈 걱정 없이.

실제로 편집하고 싶을 때 필드 상단의 편집 아이콘을 클릭합니다. 완료하면 명시적으로 미리보기 모드로 돌아갑니다. 단순하고, 의도적이고, 예측 가능합니다.

보이는 것보다 더 중요한 이유

커뮤니티 피드백 스레드가 길었습니다. 더블클릭으로 편집하는 동작은 2025년 7월 Markdown 편집기와 함께 도입되었고, 불만은 거의 즉시 시작되었습니다.

Azure Boards로 스프린트 계획, 백로그 개선, 코드 리뷰를 하는 팀에게 이런 미세한 마찰은 누적됩니다.

배포 상태

이미 일부 고객에게 배포되고 있으며 앞으로 2~3주에 걸쳐 전체로 확대됩니다.

마무리

모든 개선이 헤드라인 기능이 될 필요는 없습니다. 때로 최고의 업데이트는 단순히 성가신 것을 제거하는 것입니다. 이것이 바로 그런 것 — 작업 항목을 평화롭게 읽고 싶은 사람들을 위해 Azure Boards를 덜 적대적으로 만드는 작은 UX 수정입니다.

Azure DevOps MCP Server가 Microsoft Foundry에 등장: AI 에이전트에 어떤 의미인가

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP(Model Context Protocol)가 주목받고 있습니다. AI 에이전트 생태계를 따라가고 있다면, MCP 서버가 곳곳에서 등장하고 있다는 것을 알아차렸을 것입니다 — 표준화된 프로토콜을 통해 에이전트가 외부 도구 및 서비스와 상호 작용할 수 있게 해줍니다.

이제 Azure DevOps MCP Server가 Microsoft Foundry에서 사용 가능하며, 이것은 실용적인 가능성에 대해 생각하게 만드는 통합 중 하나입니다.

실제로 무슨 일이 일어나고 있는가

Microsoft는 이미 Azure DevOps MCP Server를 퍼블릭 프리뷰로 출시했습니다 — 그것이 MCP 서버 자체입니다. 새로운 것은 Foundry 통합입니다. 이제 도구 카탈로그에서 직접 Azure DevOps MCP Server를 Foundry 에이전트에 추가할 수 있습니다.

아직 Foundry를 모르는 분들을 위해: 대규모로 AI 기반 애플리케이션과 에이전트를 구축하고 관리하기 위한 Microsoft의 통합 플랫폼입니다. 모델 접근, 오케스트레이션, 평가, 배포 — 모두 한 곳에서.

설정하기

설정은 놀라울 정도로 간단합니다:

Foundry 에이전트에서 Add Tools > Catalog으로 이동
“Azure DevOps” 검색
Azure DevOps MCP Server(preview)를 선택하고 Create 클릭
조직 이름을 입력하고 연결

그게 전부입니다. 이제 에이전트가 Azure DevOps 도구에 접근할 수 있습니다.

에이전트가 접근할 수 있는 것 제어하기

제가 높이 평가하는 부분입니다: 전부 아니면 전무 방식에 갇히지 않습니다. 에이전트에 사용 가능한 도구를 지정할 수 있습니다. 작업 항목만 읽고 파이프라인은 건드리지 않도록 하려면 그렇게 설정할 수 있습니다. 최소 권한 원칙을 AI 에이전트에 적용하는 것이죠.

이것은 누군가가 “릴리스를 도와줘"라고 요청했다고 해서 에이전트가 실수로 배포 파이프라인을 트리거하는 것을 원하지 않는 엔터프라이즈 시나리오에서 중요합니다.

.NET 팀에게 왜 흥미로운가

실제로 이것이 무엇을 가능하게 하는지 생각해 보세요:

스프린트 계획 어시스턴트 — 작업 항목을 가져오고, 속도 데이터를 분석하고, 스프린트 용량을 제안할 수 있는 에이전트
코드 리뷰 봇 — 실제로 저장소와 연결된 작업 항목을 읽을 수 있기 때문에 PR 컨텍스트를 이해하는 에이전트
인시던트 대응 — 작업 항목을 생성하고, 최근 배포를 조회하고, 버그와 최근 변경 사항을 상관시킬 수 있는 에이전트
개발자 온보딩 — “무엇을 해야 하나요?“가 실제 프로젝트 데이터에 기반한 진짜 답변을 받게 됩니다

CI/CD 파이프라인과 프로젝트 관리에 이미 Azure DevOps를 사용하는 .NET 팀에게, 이러한 시스템과 직접 상호 작용할 수 있는 AI 에이전트는 유용한 자동화를 향한 의미 있는 한 걸음입니다.

더 큰 MCP 그림

이것은 더 넓은 트렌드의 일부입니다: MCP 서버는 AI 에이전트가 외부 세계와 상호 작용하는 표준 방식이 되어가고 있습니다. GitHub, Azure DevOps, 데이터베이스, SaaS API에서 볼 수 있으며 — Foundry는 이 모든 연결이 모이는 허브가 되고 있습니다.

.NET 생태계에서 에이전트를 구축하고 있다면, MCP에 주목할 가치가 있습니다. 프로토콜은 표준화되고, 도구는 성숙해지고 있으며, Foundry 통합은 수동으로 서버 연결을 설정할 필요 없이 접근 가능하게 해줍니다.

마무리

Foundry의 Azure DevOps MCP Server는 프리뷰 상태이므로 발전을 기대하세요. 하지만 핵심 워크플로는 견고합니다: 연결하고, 도구 접근을 설정하고, 에이전트가 DevOps 데이터로 작업하게 하세요. 이미 Foundry 생태계에 있다면 몇 번의 클릭이면 됩니다. 시도해보고 어떤 워크플로를 구축할 수 있는지 확인해 보세요.

단계별 설정과 자세한 내용은 전체 공지를 확인하세요.