Developer Tools | The .NET Blog

VS Code 1.119: 에이전트 세션용 OpenTelemetry, 브라우저 통합, 보안

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

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

VS Code 1.119는 2026년 5월 6일 출시되었습니다 (직후 1.119.1 보안 패치 포함). 이 릴리스는 에이전트 관찰 가능성, 브라우저 상호 작용, 중단 감소에 중점을 둡니다.

에이전트 세션용 OpenTelemetry 추적

프로덕션에서 에이전트를 실행하거나 에이전트 워크플로를 디버깅하는 누구에게나 주목할 기능입니다. 두 가지 설정으로 활성화합니다:

"github.copilot.chat.otel.enabled": true,
"github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318"

추적은 GenAI 의미 규약을 따릅니다. 각 에이전트 요청은 중첩된 하위 스팬을 포함하는 invoke_agent 루트 스팬을 생성합니다: chat, execute_tool, execute_hook. 토큰 사용량은 요청별로 보고됩니다 — 캐시 읽기 및 생성 횟수 포함.

로컬 에이전트, Copilot CLI 백그라운드 에이전트, Claude 에이전트와 함께 작동합니다. OTLP 호환 백엔드에서 추적을 수신할 수 있습니다 — 로컬 개발에는 Aspire Dashboard 독립 실행형이 잘 작동합니다.

에이전트가 이제 브라우저 탭에 접근 가능

에이전트는 통합 브라우저 탭에 대한 접근을 요청할 수 있습니다 — 하지만 자동이 아닙니다. 컨텍스트 선택기, 드래그 앤 드롭, 또는 제안된 컨텍스트를 통해 명시적으로 탭을 공유해야 합니다. 브라우저에 접근을 취소하는 공유 버튼이 있습니다. 에이전트가 이미 열린 (공유되지 않은) 탭과 같은 도메인에 새 탭을 열려고 할 때, VS Code는 기존 탭을 재사용하도록 안내합니다.

최적화된 토큰 사용량

실험적 경량 모델이 에이전트 할 일 목록 관리를 처리하여 이 관리 작업을 더 비싼 기본 모델에서 분리합니다. 전체 추론 능력이 필요하지 않은 작업의 토큰 소비를 줄입니다.

신뢰 및 보안

중단 감소: VS Code 1.119는 에이전트에 의한 네트워크 접근 요청과 임시 폴더 쓰기 프롬프트를 줄입니다. 1.119.1 패치는 특정 보안 문제를 해결합니다 — 아직 업데이트하지 않았다면 업데이트할 가치가 있습니다.

마크다운 미리보기 빠른 전환

작지만 유용합니다: 이제 탐색 없이 현재 편집기를 마크다운 미리보기로 빠르게 전환할 수 있습니다.

VS Code Agents (Insiders 미리보기)

재설계된 에이전트 세션 UI — 새로운 리포지토리 선택기 (로컬/repos/원격), 하위 세션 개선, 웹 및 모바일 개선, 진행 애니메이션 — 는 Insiders의 insiders.vscode.dev/agents에서 이용 가능합니다.

전체 변경 로그: code.visualstudio.com/updates/v1_119.

Azure Data Studio 은 폐기되었습니다: Azure SQL 워크플로를 VS Code로 이전하세요

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

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

Azure Data Studio는 2025년 2월 6일에 폐기되었습니다. 지원은 2026년 2월 28일에 종료됩니다. 권장 대체 도구는 MSSQL 확장을 갖춘 VS Code입니다.

설치할 항목

시작하기 위한 세 가지:

MSSQL 확장 — VS Code Marketplace에서 “SQL Server (mssql)” 검색
SQL Database Projects 확장 — 코드로서의 스키마, 빌드 유효성 검사, 안내형 게시
.NET 8 SDK — 빌드 시스템에 필요. SDK 누락은 첫 실행 시 가장 흔한 문제

ADS 연결 및 설정 마이그레이션

MSSQL 확장에는 ADS Migration Toolkit이 포함되어 있어 안내형 흐름으로 일회성 마이그레이션을 처리합니다. 저장된 연결, 연결 그룹, 설정, 키 바인딩이 모두 자동으로 가져와집니다.

F5 단축키 감각 복구

ADS 사용자는 쿼리 실행을 위해 F5에 의존합니다. MSSQL Database Management Keymap 확장을 설치하면 F5를 포함한 ADS 스타일 키 바인딩을 복구할 수 있습니다.

SQL Database Projects: 코드로서의 스키마

프로젝트를 마우스 오른쪽 버튼으로 클릭 → 게시 → 대상 구성 → 생성된 T-SQL 스크립트 검토 → 배포. 배포 전 스크립트 미리 보기가 핵심 안전 기능입니다. 항목 템플릿은 테이블, 저장 프로시저, 뷰에 대한 스텁을 생성합니다. SSDT와 동일한 워크플로입니다.

자주 발생하는 문제: .sqlproj 파일의 대상 플랫폼 불일치는 프로젝트가 다른 SQL Server 버전에 대해 생성된 경우 빌드 오류를 유발합니다.

Schema Compare 및 Schema Designer

확장에는 Schema Compare(프로젝트와 배포된 데이터베이스 간의 diff)와 Schema Designer(수동 DDL 작성 없이 시각적 스키마 편집)도 포함되어 있습니다.

Microsoft Fabric 개발자

설정은 동일하지만 VS Code에서 열기 전에 Fabric 포털에서 시작하여 먼저 데이터베이스를 Git에 연결하세요. Microsoft에는 전용 가이드가 있습니다: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

마무리

마이그레이션은 수동 재구축이 아닌 일회성 안내형 흐름입니다. 세 가지 도구를 설치하고, ADS Migration Toolkit을 실행하고, 키 바인딩을 복구하면 10분 이내에 정상으로 돌아올 수 있습니다.

단계별 스크린샷과 Fabric 전용 안내는 전체 기사를 참조하세요.

Azure MCP Server 이제 .mcpb — 런타임 없이 설치하기

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

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

MCP 서버 설정에서 번거로웠던 것이 무엇인지 아시나요? 런타임이 필요했습니다. npm 버전에는 Node.js, pip/uvx에는 Python, dotnet 버전에는 .NET SDK.

Azure MCP Server가 이를 바꿨습니다. 이제 .mcpb — MCP Bundle — 로 제공되며 설정은 드래그 앤 드롭입니다.

MCP Bundle이란?

VS Code 확장(.vsix)이나 브라우저 확장(.crx)처럼 생각하세요. 단, MCP 서버용입니다. .mcpb 파일은 서버 바이너리와 모든 종속성을 포함한 독립적인 ZIP 아카이브입니다.

설치 방법

1. 플랫폼용 번들 다운로드

GitHub Releases 페이지에서 OS와 아키텍처에 맞는 .mcpb 파일을 다운로드합니다.

2. Claude Desktop에 설치

가장 쉬운 방법: 확장 설정 페이지(☰ → 파일 → 설정 → 확장)가 열린 상태에서 .mcpb 파일을 Claude Desktop 창에 드래그 앤 드롭합니다. 서버 세부 정보를 확인하고 설치를 클릭합니다.

3. Azure 인증

az login

끝입니다. Azure MCP Server는 기존 Azure 자격 증명을 사용합니다.

할 수 있는 것

AI 클라이언트에서 직접 100개 이상의 Azure 서비스 도구에 접근:

Cosmos DB, Storage, Key Vault, App Service, Foundry 쿼리 및 관리
모든 작업을 위한 az CLI 명령 생성
Bicep 및 Terraform 템플릿 생성

시작하기

다운로드: GitHub Releases
저장소: aka.ms/azmcp
문서: aka.ms/azmcp/docs

전체 게시물을 확인하세요.

VS Code 1.118: Copilot CLI에 세션 이름, 모델 배지, TypeScript 7.0 나이틀리 옵트인 추가

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

이 포스트는 자동 번역되었습니다. 원본은 여기를 클릭하세요.

Visual Studio Code 1.118은 작지만 집중된 릴리스입니다 — 주로 Copilot CLI 개선에 관한 것이지만 몇 가지 주목할 점이 있습니다.

Copilot CLI: 세션에 진짜 이름 붙기

Copilot CLI SDK 세션 타이틀 API가 이제 세션 이름의 진실 소스로 사용됩니다. 자동 생성된 레이블 대신 SDK의 실제 이름이 표시됩니다.

키보드 단축키로 세션 빠르게 전환

Agents 앱에 이제 Ctrl+1, Ctrl+2 등의 세션 전환 키가 바인딩되었습니다.

채팅에 모델 배지 표시

채팅 패널의 Copilot CLI 응답에 이제 모델 배지가 표시됩니다 — 각 요청을 어떤 모델이 처리했는지 한눈에 볼 수 있습니다.

Copilot CLI에 자동 모델 선택

자동 모델 선택 기능이 이제 Copilot CLI 에이전트에서도 작동합니다.

TypeScript 7.0 나이틀리 옵트인

이제 VS Code 설정에서 직접 TypeScript 7.0 나이틀리 테스트에 옵트인할 수 있습니다. TypeScript 7.0은 대규모 릴리스입니다(베타가 며칠 전 출시).

전체 릴리스 노트를 확인하세요.

Foundry Toolboxes: AI 에이전트 도구를 위한 단일 엔드포인트

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

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

직접 겪기 전까지는 사소해 보이는 문제가 있다: 조직이 여러 AI 에이전트를 구축하고, 각 에이전트는 도구가 필요하며, 각 팀은 처음부터 다시 구성한다. 같은 웹 검색 통합, 같은 Azure AI Search 설정, 같은 GitHub MCP 서버 연결 — 하지만 다른 저장소에, 다른 팀이, 다른 자격증명으로, 공유 거버넌스 없이.

Microsoft Foundry가 공개 프리뷰로 Toolboxes를 출시했으며, 이는 그 문제에 대한 직접적인 해답이다.

Toolbox란

Toolbox는 Foundry에서 한 번 정의하고 단일 MCP 호환 엔드포인트를 통해 노출하는 명명된 재사용 가능한 도구 번들이다. MCP를 사용하는 모든 에이전트 런타임이 소비할 수 있다 — Foundry Agents에 종속되지 않는다.

제안은 간단하다: build once, consume anywhere. 도구를 정의하고, 인증을 중앙에서 설정하고 (OAuth 패스스루, Entra 관리 ID), 엔드포인트를 게시한다. 그 도구가 필요한 각 에이전트는 엔드포인트에 연결하면 모두 가져온다.

4개의 기둥 (오늘 2개 사용 가능)

기둥	상태	기능
Discover	출시 예정	수동 검색 없이 승인된 도구 발견
Build	사용 가능	도구를 재사용 가능한 번들로 구성
Consume	사용 가능	단일 MCP 엔드포인트가 모든 도구 노출
Govern	출시 예정	모든 도구 호출의 중앙 인증 + 가시성

실제 예시

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="문서를 검색하고 GitHub 이슈에 응답",
 tools=[
 {"type": "web_search", "description": "공개 문서 검색"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

게시 후 Foundry는 통합 엔드포인트를 제공한다. 한 번 연결하면 모든 도구를 사용할 수 있다.

Foundry Agents에 종속되지 않는다

Toolboxes는 Foundry에서 생성·관리되지만 소비 면은 오픈 MCP 프로토콜이다. Microsoft Agent Framework나 LangGraph로 만든 커스텀 에이전트, GitHub Copilot 및 기타 MCP 지원 IDE에서 사용할 수 있다.

지금 왜 중요한가

멀티 에이전트 물결이 프로덕션에 도달하고 있다. 새로운 에이전트마다 중복 설정, 오래된 자격증명, 일관성 없는 동작의 새로운 표면이 생긴다. Build + Consume 기반은 중앙화를 시작하기에 충분하다. Govern 기둥이 출시되면 전체 에이전트 플리트에 완전히 관찰 가능하고 중앙 제어되는 도구 계층을 갖게 된다.

마무리

아직 초기 단계다 — 공개 프리뷰, Python SDK 우선, Discover와 Govern은 예정되어 있다. 하지만 모델은 견고하고, MCP 네이티브 설계는 이미 구축 중인 도구와 함께 작동한다는 것을 의미한다. 공식 발표를 확인해 시작해보자.

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 일상 워크플로우에서 많은 마찰을 제거하는 변화 중 하나다. 훅의 멀티 언어 지원은 지금 바로 사용 가능하다 — 공식 게시물에서 전체 문서를 확인해 보자.

Windows App Dev CLI v0.3: 터미널에서 F5 디버그와 에이전트를 위한 UI 자동화

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

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

Visual Studio의 F5 경험은 훌륭합니다. 하지만 CI 파이프라인, 자동화 워크플로우, 또는 AI 에이전트가 테스트를 수행할 때 패키지된 Windows 앱을 시작하고 디버그하기 위해 VS를 열어야 한다면 너무 번거롭습니다.

Windows App Development CLI v0.3이 출시되었으며, 두 가지 핵심 기능으로 이를 직접 해결합니다: winapp run과 winapp ui.

winapp run: 어디서나 F5

winapp run은 언패키지된 앱 폴더와 매니페스트를 받아, VS가 디버그 시작 시 수행하는 모든 작업을 실행합니다: 루스 패키지 등록, 앱 시작, 재배포 간 LocalState 보존.

# 앱을 빌드한 다음 패키지 앱으로 실행
winapp run ./bin/Debug

WinUI, WPF, WinForms, Console, Avalonia 등에서 동작합니다. 모드는 개발자와 자동화 워크플로우 모두를 위해 설계되었습니다:

--detach: 시작 후 즉시 터미널에 제어권을 반환합니다. CI/자동화에 적합합니다.
--unregister-on-exit: 앱 종료 시 등록된 패키지를 정리합니다.
--debug-output: OutputDebugString 메시지와 예외를 실시간으로 캡처합니다.

새로운 NuGet 패키지: 패키지 앱을 위한 dotnet run

.NET 개발자를 위한 새로운 NuGet 패키지가 있습니다: Microsoft.Windows.SDK.BuildTools.WinApp. 설치 후 dotnet run이 전체 이너 루프를 처리합니다: 빌드, 루스 레이아웃 패키지 준비, Windows 등록 및 시작 — 모두 한 단계로.

winapp init
# 또는
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: 커맨드 라인에서 UI 자동화

이것이 에이전트 시나리오를 여는 기능입니다. winapp ui는 터미널에서 실행 중인 모든 Windows 앱(WPF, WinForms, Win32, Electron, WinUI3)에 대한 완전한 UI 자동화 액세스를 제공합니다.

가능한 작업:

모든 최상위 창 나열
창의 전체 UI 자동화 트리 탐색
이름, 유형 또는 자동화 ID로 요소 검색
클릭, 호출 및 값 설정
스크린샷 캡처
요소 나타날 때까지 대기 — 테스트 동기화에 이상적

winapp ui와 winapp run을 결합하면 터미널에서 완전한 빌드 → 시작 → 검증 워크플로우가 가능합니다. 에이전트가 앱을 실행하고, UI 상태를 검사하고, 프로그래밍 방식으로 상호작용하여 결과를 검증할 수 있습니다.

기타 새로운 기능

winapp unregister: 완료 후 사이드로드된 패키지를 제거합니다.
winapp manifest add-alias: 터미널에서 이름으로 앱을 시작하는 별칭을 추가합니다.
탭 자동완성: 단일 명령으로 PowerShell 완성을 구성합니다.

설치 방법

winget install Microsoft.WinAppCli
# 또는
npm install -g @microsoft/winappcli

CLI는 공개 미리 보기 중입니다. 전체 문서는 GitHub 저장소를, 모든 세부 정보는 원본 발표를 참조하세요.

VS Code 1.117: 에이전트가 전용 Git 브랜치를 갖게 됐다, 완전 찬성이다

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

“AI 어시스턴트"와 “AI 팀원” 사이의 경계가 계속 얇아지고 있다. VS Code 1.117이 출시됐고 전체 릴리스 노트는 내용이 가득하지만, 이야기는 분명하다: 에이전트가 개발 워크플로의 일등 시민이 되고 있다.

진짜 중요한 것들을 정리했다.

Autopilot 모드가 드디어 설정을 기억한다

이전에는 새 세션을 시작할 때마다 Autopilot을 다시 활성화해야 했다. 짜증났다. 이제 권한 모드가 세션 간에 유지되고, 기본값도 설정할 수 있다.

Agent Host는 세 가지 세션 설정을 지원한다:

Default — 도구가 실행 전에 확인을 요청
Bypass — 모든 것을 자동 승인
Autopilot — 완전 자율, 스스로 질문에 답하고 계속 진행

마이그레이션, Docker, CI와 함께 새 .NET 프로젝트를 스캐폴딩하고 있다면 — Autopilot으로 한 번 설정하고 잊어버리면 된다. 그 설정이 유지된다.

에이전트 세션을 위한 worktree와 git 격리

이게 핵심이다. 에이전트 세션이 이제 완전한 worktree와 git 격리를 지원한다. 에이전트가 작업을 수행할 때 자체 브랜치와 작업 디렉토리를 갖게 된다는 뜻이다. 메인 브랜치는 전혀 영향을 받지 않는다.

더 좋은 건 — Copilot CLI가 이 worktree 세션에 의미 있는 브랜치 이름을 생성해준다. 더 이상 agent-session-abc123 같은 이름은 없다. 에이전트가 실제로 무엇을 하고 있는지 설명하는 이름을 받게 된다.

여러 피처 브랜치를 관리하거나 긴 스캐폴딩 작업이 실행되는 동안 버그를 수정하는 .NET 개발자에게 이건 게임 체인저다. 한 worktree에서 에이전트가 API 컨트롤러를 빌드하는 동안 다른 worktree에서 서비스 레이어 문제를 디버깅할 수 있다. 충돌 없음. 스태시 없음. 혼란 없음.

서브에이전트와 에이전트 팀

Agent Host Protocol이 이제 서브에이전트를 지원한다. 에이전트가 작업의 일부를 처리하기 위해 다른 에이전트를 생성할 수 있다. 위임이라고 생각하면 된다 — 메인 에이전트가 조율하고, 전문 에이전트가 각 부분을 담당한다.

아직 초기 단계지만 .NET 워크플로에 대한 잠재력은 분명하다. 한 에이전트가 EF Core 마이그레이션을 처리하고 다른 에이전트가 통합 테스트를 설정하는 모습을 상상해보라. 아직 완전히 도달하지는 않았지만, 프로토콜 지원이 지금 들어왔다는 것은 도구가 빠르게 따라올 것이라는 뜻이다.

에이전트가 입력을 보낼 때 터미널 출력이 자동으로 포함

작지만 의미 있다. 에이전트가 터미널에 입력을 보내면 터미널 출력이 이제 자동으로 컨텍스트에 포함된다. 이전에는 에이전트가 무슨 일이 일어났는지 읽기 위해 추가 턴이 필요했다.

에이전트가 dotnet build를 실행하고, 실패하고, 에러를 보기 위해 또 한 번 왕복하는 걸 본 적이 있다면 — 그 마찰이 사라졌다. 출력을 즉시 보고 반응한다.

macOS Agents 앱 자동 업데이트

macOS의 독립형 Agents 앱이 이제 자동 업데이트된다. 더 이상 새 버전을 수동으로 다운로드할 필요가 없다. 그냥 최신 상태를 유지한다.

알아둘 만한 작은 것들

package.json 호버가 이제 설치된 버전과 최신 사용 가능 버전을 모두 표시한다. .NET 프로젝트와 함께 npm 도구를 관리하는 경우 유용하다.
JSDoc 주석의 이미지가 호버와 자동완성에서 올바르게 렌더링된다.
Copilot CLI 세션이 VS Code에서 생성됐는지 외부에서 생성됐는지 표시한다 — 터미널 간에 이동할 때 편리하다.
Copilot CLI, Claude Code, Gemini CLI가 셸 타입으로 인식된다. 에디터가 무엇을 실행하고 있는지 알고 있다.

핵심 정리

VS Code 1.117은 화려한 기능 나열이 아니다. 인프라다. Worktree 격리, 영구 권한, 서브에이전트 프로토콜 — 이것들은 에이전트가 코드를 건드리지 않으면서 실제 병렬 작업을 처리하는 워크플로를 위한 기반이다.

.NET으로 개발하면서 아직 에이전트 워크플로에 뛰어들지 않았다면, 솔직히 지금이 시작할 때다.

Docker Sandbox로 Copilot 에이전트가 머신 위험 없이 코드를 리팩터링할 수 있게 되었다

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

Copilot의 에이전트 모드를 작은 편집 이상의 용도로 써본 적이 있다면, 그 고통을 알 겁니다. 파일 쓰기마다, 터미널 명령마다 — 또 권한 프롬프트. 이제 이걸 50개 프로젝트에서 한다고 상상해 보세요. 전혀 재미없죠.

Azure 팀이 GitHub Copilot 에이전트를 위한 Docker Sandbox에 관한 포스트를 공개했는데, 솔직히 제가 본 에이전틱 툴링 개선 중 가장 실용적인 것 중 하나입니다. 마이크로VM을 활용해 Copilot에게 완전히 격리된 환경을 제공하여 패키지 설치, 빌드 실행, 테스트 실행까지 — 호스트 시스템을 전혀 건드리지 않고 자유롭게 작업할 수 있게 합니다.

Docker Sandbox가 실제로 제공하는 것

핵심 아이디어는 간단합니다: 완전한 Linux 환경을 갖춘 경량 마이크로VM을 띄우고, 워크스페이스를 그 안에 동기화한 다음, Copilot 에이전트가 내부에서 자유롭게 작업하게 하는 것입니다. 작업이 끝나면 변경 사항이 다시 동기화됩니다.

단순히 “컨테이너 안에서 실행하는 것” 이상으로 만드는 요소들입니다:

양방향 워크스페이스 동기화로 절대 경로가 보존됩니다. 프로젝트 구조가 샌드박스 안에서도 동일하게 보입니다. 경로 관련 빌드 실패가 없습니다.
프라이빗 Docker 데몬이 마이크로VM 안에서 실행됩니다. 에이전트는 호스트의 Docker 소켓을 마운트하지 않고도 컨테이너를 빌드하고 실행할 수 있습니다. 보안 측면에서 큰 발전입니다.
HTTP/HTTPS 필터링 프록시가 에이전트의 네트워크 접근을 제어합니다. 어떤 레지스트리와 엔드포인트를 허용할지는 여러분이 결정합니다. 샌드박스 내 악의적인 npm install로 인한 공급망 공격? 차단됩니다.
YOLO 모드 — 네, 정말로 그렇게 부릅니다. 에이전트가 호스트를 말 그대로 손상시킬 수 없기 때문에 권한 프롬프트 없이 실행됩니다. 모든 파괴적 행위가 격리됩니다.

.NET 개발자가 주목해야 하는 이유

지금 수많은 팀이 직면하고 있는 현대화 작업을 생각해 보세요. 30개 프로젝트가 있는 .NET Framework 솔루션이 있고, .NET 9로 마이그레이션해야 합니다. 수백 개의 파일 변경이 필요합니다 — 프로젝트 파일, 네임스페이스 업데이트, API 교체, NuGet 마이그레이션.

Docker Sandbox를 사용하면 Copilot 에이전트를 프로젝트에 지정하고, 마이크로VM 안에서 자유롭게 리팩터링하게 한 다음, dotnet build와 dotnet test로 검증하고, 실제로 작동하는 변경 사항만 받아들일 수 있습니다. 실험 과정에서 로컬 개발 환경을 실수로 망가뜨릴 위험이 없습니다.

포스트에서는 병렬 에이전트 플릿 운영도 설명합니다 — 각각 자체 샌드박스에서 서로 다른 프로젝트를 동시에 처리합니다. 대규모 .NET 솔루션이나 마이크로서비스 아키텍처에서는 엄청난 시간 절약입니다. 서비스당 에이전트 하나, 모두 격리 실행, 모두 독립 검증.

보안 관점이 중요하다

대부분의 사람들이 놓치는 점이 있습니다: AI 에이전트에게 임의의 명령 실행을 허용하면, 여러분의 전체 머신을 맡기는 겁니다. Docker Sandbox는 이 모델을 뒤집습니다. 에이전트는 일회용 환경에서 완전한 자율성을 얻습니다. 네트워크 프록시가 승인된 소스에서만 다운로드할 수 있도록 보장합니다. 호스트 파일시스템, Docker 데몬, 자격 증명은 그대로 유지됩니다.

컴플라이언스 요구사항이 있는 팀 — 대부분의 엔터프라이즈 .NET 기업이 해당합니다 — 에게 이것은 “에이전틱 AI를 사용할 수 없다"와 “안전하게 도입할 수 있다"의 차이입니다.

정리

Docker Sandbox는 에이전틱 코딩의 근본적인 긴장을 해결합니다: 에이전트가 유용하려면 자유가 필요하지만, 호스트 머신에서의 자유는 위험합니다. 마이크로VM은 둘 다 가능하게 합니다. 대규모 .NET 리팩터링이나 현대화를 계획하고 있다면, 지금 설정할 가치가 있습니다. Copilot의 코드 인텔리전스와 안전한 실행 환경의 조합은 프로덕션 팀이 기다려온 바로 그것입니다.

터미널 감시는 그만: Aspire의 분리 모드가 워크플로를 바꾼다

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

Aspire AppHost를 실행할 때마다 터미널이 사라집니다. 잠겨버립니다. Ctrl+C를 누를 때까지 점유된 상태입니다. 빠르게 명령어를 실행해야 하나요? 다른 탭을 엽니다. 로그를 확인하고 싶나요? 또 다른 탭. 작은 불편함이지만 빠르게 쌓입니다.

Aspire 13.2가 이 문제를 해결합니다. James Newton-King이 자세한 내용을 작성했는데, 솔직히 이건 사용하는 순간 바로 작업 방식이 바뀌는 기능 중 하나입니다.

분리 모드: 명령어 하나로 터미널 되찾기

aspire start

이것은 aspire run --detach의 단축 명령입니다. AppHost가 백그라운드에서 시작되고 터미널이 즉시 돌아옵니다. 추가 탭 없이. 터미널 멀티플렉서 없이. 프롬프트만 준비된 상태로요.

실행 중인 프로세스 관리하기

핵심은 이겁니다 — 백그라운드 실행은 실행 중인 것을 관리할 수 있어야만 의미가 있습니다. Aspire 13.2는 바로 이를 위한 완전한 CLI 명령 세트를 제공합니다:

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

이로써 Aspire CLI가 본격적인 프로세스 관리자가 됩니다. 여러 AppHost를 시작하고, 상태를 확인하고, 로그를 추적하고, 종료할 수 있습니다 — 모두 하나의 터미널 세션에서.

격리 모드와 결합하기

분리 모드는 격리 모드와 자연스럽게 어울립니다. 포트 충돌 없이 같은 프로젝트의 인스턴스 두 개를 백그라운드에서 실행하고 싶다면?

aspire start --isolated
aspire start --isolated

각각 랜덤 포트, 별도의 시크릿, 자체 라이프사이클을 갖습니다. aspire ps로 둘 다 확인하고, aspire stop으로 필요 없는 것을 중지하세요.

코딩 에이전트에게 이것이 중요한 이유

여기서부터 정말 흥미로워집니다. 터미널에서 작업하는 코딩 에이전트가 이제 다음을 할 수 있습니다:

aspire start로 앱 시작
aspire describe로 상태 조회
aspire logs로 로그를 확인하여 문제 진단
완료 후 aspire stop으로 중지

모두 터미널 세션을 잃지 않고 수행할 수 있습니다. 분리 모드 이전에는 AppHost를 실행한 에이전트가 자신의 터미널에 갇혀버렸습니다. 이제는 시작, 관찰, 반복, 정리가 가능합니다 — 자율 에이전트에게 기대하는 바로 그 동작입니다.

Aspire 팀은 이 부분에 공을 들였습니다. aspire agent init을 실행하면 에이전트에게 이러한 명령을 가르치는 Aspire 스킬 파일이 설정됩니다. 이를 통해 Copilot의 코딩 에이전트 같은 도구가 바로 Aspire 워크로드를 관리할 수 있습니다.

마무리

분리 모드는 단순한 플래그로 위장한 워크플로 업그레이드입니다. 터미널 간 컨텍스트 전환이 사라지고, 에이전트가 스스로를 차단하지 않으며, 새로운 CLI 명령으로 실행 중인 것을 실시간으로 파악할 수 있습니다. 실용적이고, 깔끔하며, 일상 개발 사이클이 눈에 띄게 매끄러워집니다.

전체 글에서 모든 세부 사항을 확인하고, aspire update --self로 Aspire 13.2를 설치하세요.

Azure MCP 도구가 Visual Studio 2022에 기본 탑재 — 확장 프로그램 설치 불필요

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

Visual Studio에서 별도 확장 프로그램을 통해 Azure MCP 도구를 사용해 왔다면, 그 과정을 잘 아실 겁니다 — VSIX 설치, 재시작, 문제가 안 생기길 바라기, 버전 불일치 관리. 그 번거로움이 사라졌습니다.

Yun Jung Choi가 발표한 바와 같이, Azure MCP 도구가 이제 Visual Studio 2022의 Azure 개발 워크로드의 일부로 직접 제공됩니다. 확장 프로그램 없음. VSIX 없음. 재시작 댄스 없음.

이것이 실제로 의미하는 것

Visual Studio 2022 버전 17.14.30부터 Azure MCP Server가 Azure 개발 워크로드에 번들로 포함됩니다. 이미 해당 워크로드가 설치되어 있다면, GitHub Copilot Chat에서 활성화하기만 하면 됩니다.

45개 Azure 서비스에 걸친 230개 이상의 도구 — 채팅 창에서 직접 접근할 수 있습니다. 스토리지 계정 목록 조회, ASP.NET Core 앱 배포, App Service 문제 진단, Log Analytics 쿼리 — 브라우저 탭을 열 필요 없이 모두 가능합니다.

왜 이것이 들리는 것보다 더 중요한가

개발자 도구에 대해 이런 말이 있습니다: 추가 단계 하나하나가 마찰이고, 마찰은 도입을 망칩니다. MCP가 별도 확장 프로그램이었을 때는 버전 불일치, 설치 실패, 그리고 업데이트해야 할 것이 하나 더 생긴다는 것을 의미했습니다. 워크로드에 내장된다는 것은:

단일 업데이트 경로 — Visual Studio Installer를 통해
버전 차이 없음 — 확장 프로그램과 IDE 간에
항상 최신 — MCP Server가 정기 VS 릴리스와 함께 업데이트

Azure를 표준으로 사용하는 팀에게 이것은 큰 의미가 있습니다. 워크로드를 한 번 설치하고, 도구를 활성화하면, 매 세션마다 사용할 수 있습니다.

이것으로 무엇을 할 수 있는가

도구들은 Copilot Chat를 통해 전체 개발 라이프사이클을 지원합니다:

학습 — Azure 서비스, 모범 사례, 아키텍처 패턴에 대해 질문
설계 및 개발 — 서비스 추천 받기, 앱 코드 구성
배포 — 리소스 프로비저닝 및 IDE에서 직접 배포
문제 해결 — 로그 쿼리, 리소스 상태 확인, 프로덕션 문제 진단

간단한 예시 — Copilot Chat에 다음을 입력해 보세요:

List my storage accounts in my current subscription.

Copilot이 뒤에서 Azure MCP 도구를 호출하고, 구독을 조회하여, 이름, 위치, SKU가 포함된 정리된 목록을 반환합니다. 포털이 필요 없습니다.

활성화 방법

Visual Studio 2022 17.14.30 이상으로 업데이트
Azure development 워크로드가 설치되어 있는지 확인
GitHub Copilot Chat 열기
Select tools 버튼(렌치 아이콘) 클릭
Azure MCP Server 활성화

끝입니다. 세션 간에 활성화 상태가 유지됩니다.

한 가지 주의사항

도구는 기본적으로 비활성화되어 있습니다 — 직접 활성화해야 합니다. 그리고 VS 2026 전용 도구는 VS 2022에서 사용할 수 없습니다. 도구 사용 가능 여부는 Azure 구독 권한에 따라 달라지며, 포털과 동일합니다.

더 큰 그림

이것은 분명한 트렌드의 일부입니다: MCP는 개발자 IDE에서 클라우드 도구를 제공하는 표준이 되어가고 있습니다. 이미 Azure MCP Server 2.0 안정 버전 출시와 VS Code 및 기타 에디터에서의 MCP 통합을 봐왔습니다. Visual Studio의 워크로드 시스템에 내장하는 것은 자연스러운 발전입니다.

Visual Studio에서 살다시피 하는 .NET 개발자에게, Azure 포털로 컨텍스트 전환해야 할 이유가 하나 더 사라진 셈입니다. 솔직히, 탭 전환은 적을수록 좋으니까요.

azd update — 모든 패키지 매니저를 지배하는 하나의 명령어

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

몇 주마다 뜨는 “새로운 버전의 azd를 사용할 수 있습니다” 메시지 아시죠? azd를 winget으로 설치했는지, Homebrew인지, 아니면 6개월 전에 실행한 curl 스크립트인지 기억이 안 나서 그냥 무시하게 되는 그 메시지요. 드디어 해결됐습니다.

Microsoft가 azd update를 출시했습니다 — 원래 어떤 방법으로 설치했든 상관없이 Azure Developer CLI를 최신 버전으로 업데이트하는 단 하나의 명령어입니다. Windows, macOS, Linux — 상관없습니다. 명령어 하나면 됩니다.

작동 방식

azd update

이게 전부입니다. 새로운 기능을 미리 체험하고 싶다면 일일 Insiders 빌드로 전환할 수 있습니다:

azd update --channel daily
azd update --channel stable

이 명령어는 현재 설치 방법을 감지하고 내부적으로 적절한 업데이트 메커니즘을 사용합니다. 더 이상 “잠깐, 이 컴퓨터에서 winget을 썼었나, choco였나?” 고민할 필요 없습니다.

한 가지 참고사항

azd update는 버전 1.23.x부터 제공됩니다. 이전 버전을 사용 중이라면 원래 설치 방법으로 마지막 수동 업데이트를 한 번만 해주면 됩니다. 그 이후로는 azd update가 모든 것을 처리합니다.

azd version으로 현재 버전을 확인하세요. 새로 설치가 필요하다면 설치 문서를 참고하세요.

왜 중요한가

작은 삶의 질 개선이지만, AI 에이전트와 Aspire 앱을 Azure에 배포하기 위해 매일 azd를 사용하는 우리에게 최신 상태를 유지한다는 것은 “그 버그는 최신 버전에서 이미 수정됐습니다"라는 순간이 줄어든다는 의미입니다. 신경 쓸 일이 하나 줄어드는 거죠.

전체 발표와 Jon Gallant의 상세 분석에서 자세한 내용을 확인하세요.

.NET Aspire 13.2는 AI 에이전트의 가장 친한 친구가 되고 싶어한다

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

AI 코딩 에이전트가 꽤 괜찮은 코드를 작성해서 기대했는데, 그것을 실제로 실행하려고 하면 전부 무너지는 그 순간 아시죠? 포트 충돌, 고스트 프로세스, 잘못된 환경 변수 — 갑자기 에이전트가 기능을 만드는 대신 시작 문제를 디버깅하느라 토큰을 소모합니다.

Aspire 팀이 바로 이 문제에 대한 정말 사려 깊은 글을 발표했고, 그들의 답은 설득력이 있습니다: Aspire 13.2는 인간만을 위한 것이 아니라 AI 에이전트를 위해서도 설계되었습니다.

문제는 현실입니다

AI 에이전트는 코드 작성에 놀라운 능력을 보여줍니다. 하지만 작동하는 풀스택 앱을 배포하려면 파일 생성 이상의 것이 필요합니다. 서비스를 올바른 순서로 시작하고, 포트를 관리하고, 환경 변수를 설정하고, 데이터베이스를 연결하고, 문제가 생겼을 때 피드백을 받아야 합니다. 현재 대부분의 에이전트는 이 모든 것을 시행착오로 처리합니다 — 명령 실행, 에러 출력 읽기, 재시도.

Markdown 지침, 커스텀 스킬, 프롬프트를 쌓아올려 가이드하려 하지만, 이것들은 예측 불가능하고 컴파일할 수 없으며 파싱하는 것만으로도 토큰이 듭니다. Aspire 팀은 핵심 인사이트를 정확히 짚었습니다: 에이전트에게 필요한 것은 컴파일러와 구조화된 API이지, 더 많은 Markdown이 아닙니다.

에이전트 인프라로서의 Aspire

Aspire 13.2가 에이전틱 개발 테이블에 가져오는 것들:

전체 스택을 타입이 있는 코드로. AppHost가 앱의 전체 토폴로지 — API, 프론트엔드, 데이터베이스, 캐시 — 를 컴파일 가능한 TypeScript 또는 C#로 정의합니다:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

에이전트는 이것을 읽어 앱 토폴로지를 이해하고, 리소스를 추가하고, 연결을 설정하고, 검증을 위해 빌드할 수 있습니다. 컴파일러가 뭔가 잘못되면 즉시 알려줍니다. 추측 불필요, 설정 파일에 대한 시행착오 불필요.

하나의 명령으로 모두 지배. 에이전트가 docker compose up, npm run dev, 데이터베이스 시작 스크립트를 저글링하는 대신, 모든 것이 aspire start 하나입니다. 모든 리소스가 올바른 순서로, 올바른 포트에, 올바른 설정으로 시작됩니다. 장시간 실행 프로세스도 에이전트를 멈추지 않습니다 — Aspire가 관리합니다.

병렬 에이전트를 위한 격리 모드. --isolated를 사용하면 각 Aspire 실행이 자체 랜덤 포트와 별도의 사용자 시크릿을 갖습니다. 여러 에이전트가 git worktree에서 작업 중인가요? 충돌하지 않습니다. 이것은 VS Code의 백그라운드 에이전트처럼 병렬 환경을 생성하는 도구에 매우 중요합니다.

텔레메트리를 통한 에이전트의 눈. 여기서 정말 강력해집니다. Aspire CLI는 개발 중 완전한 OpenTelemetry 데이터를 노출합니다 — 트레이스, 메트릭, 구조화된 로그. 에이전트가 콘솔 출력을 읽고 최선을 바라는 것이 아닙니다. 서비스 간 실패한 요청을 추적하고, 느린 엔드포인트를 프로파일링하고, 정확히 어디서 문제가 발생하는지 파악할 수 있습니다. 개발 루프에 프로덕션급 관찰 가능성이 있는 것입니다.

볼링 범퍼 비유

Aspire 팀은 훌륭한 비유를 사용합니다: Aspire를 AI 에이전트를 위한 볼링 레인 범퍼라고 생각하세요. 에이전트가 완벽하지 않다면 (그리고 완벽하지 않을 것입니다), 범퍼가 거터볼을 치지 않도록 막아줍니다. 스택 정의가 잘못된 구성을 방지하고, 컴파일러가 오류를 잡고, CLI가 프로세스 관리를 담당하고, 텔레메트리가 피드백 루프를 제공합니다.

이것을 Playwright CLI 같은 것과 결합하면, 에이전트가 실제로 앱을 사용할 수 있습니다 — 플로우를 클릭하고, DOM을 확인하고, 텔레메트리에서 깨진 것을 보고, 코드를 수정하고, 재시작하고, 다시 테스트합니다. 빌드, 실행, 관찰, 수정. 이것이 우리가 추구해온 자율 개발 루프입니다.

시작하기

Aspire가 처음이세요? get.aspire.dev에서 CLI를 설치하고 시작 가이드를 따르세요.

이미 Aspire를 사용 중이세요? aspire update --self를 실행하여 13.2를 받고, 좋아하는 코딩 에이전트를 레포에 연결하세요. Aspire의 가드레일이 있으면 에이전트가 얼마나 더 멀리까지 갈 수 있는지 놀라실 수 있습니다.

마무리

Aspire 13.2는 더 이상 단순한 분산 앱 프레임워크가 아닙니다 — 필수적인 에이전트 인프라가 되고 있습니다. 구조화된 스택 정의, 원커맨드 시작, 격리된 병렬 실행, 실시간 텔레메트리가 AI 에이전트에게 코드 작성에서 앱 배포로 넘어가는 데 필요한 모든 것을 제공합니다.

Aspire 팀의 전체 포스트에서 모든 세부사항과 데모 비디오를 확인하세요.

Aspire의 격리 모드가 병렬 개발의 포트 충돌 악몽을 해결한다

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

같은 프로젝트의 두 인스턴스를 동시에 실행하려고 해본 적이 있다면, 그 고통을 알 것입니다. 포트 8080이 이미 사용 중입니다. 포트 17370이 점유되어 있습니다. 뭔가를 kill하고, 재시작하고, 환경 변수를 저글링하는 — 생산성 킬러입니다.

이 문제는 나아지는 게 아니라 악화되고 있습니다. AI 에이전트가 독립적으로 작업하기 위해 git worktree를 만듭니다. 백그라운드 에이전트가 별도의 환경을 생성합니다. 개발자가 피처 브랜치를 위해 같은 레포를 두 번 체크아웃합니다. 이 모든 시나리오가 같은 벽에 부딪힙니다: 같은 앱의 두 인스턴스가 같은 포트를 놓고 싸우는 것입니다.

Aspire 13.2가 단 하나의 플래그로 이것을 해결합니다. Aspire 팀의 James Newton-King이 전체 상세 내용을 작성했는데, “왜 진작 이게 없었지?“라는 기능 중 하나입니다.

해결책: `--isolated`

aspire run --isolated

끝입니다. 각 실행이 다음을 얻습니다:

랜덤 포트 — 인스턴스 간 충돌 없음
격리된 사용자 시크릿 — 연결 문자열과 API 키가 인스턴스별로 분리

수동 포트 재할당이 필요 없습니다. 환경 변수 저글링도 필요 없습니다. 각 실행이 자동으로 깨끗하고 충돌 없는 환경을 얻습니다.

이 기능이 빛나는 실제 시나리오

다중 체크아웃. 한 디렉토리에 피처 브랜치가 있고 다른 디렉토리에 버그픽스가 있는 경우:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

둘 다 충돌 없이 실행됩니다. 대시보드에서 무엇이 어디서 실행 중인지 확인할 수 있습니다.

VS Code의 백그라운드 에이전트. Copilot Chat의 백그라운드 에이전트가 코드에 독립적으로 작업하기 위해 git worktree를 만들면, Aspire AppHost를 실행해야 할 수 있습니다. --isolated 없이는 기본 worktree와 포트 충돌이 발생합니다. 이것이 있으면 두 인스턴스 모두 문제없이 동작합니다.

aspire agent init에 포함된 Aspire 스킬은 worktree에서 작업할 때 --isolated를 사용하도록 에이전트에게 자동으로 지시합니다. 따라서 Copilot의 백그라운드 에이전트는 이것을 기본적으로 처리할 것입니다.

개발과 병행하는 통합 테스트. 기능을 계속 만들면서 라이브 AppHost에 대해 테스트를 실행해야 하나요? 격리 모드는 각 컨텍스트에 자체 포트와 설정을 제공합니다.

내부 작동 원리

--isolated를 전달하면, CLI가 해당 실행을 위한 고유 인스턴스 ID를 생성합니다. 이것이 두 가지 동작을 구동합니다:

포트 랜덤화 — AppHost 설정에 정의된 예측 가능한 포트에 바인딩하는 대신, 격리 모드는 모든 것에 대해 사용 가능한 랜덤 포트를 선택합니다 — 대시보드, 서비스 엔드포인트, 전부. 서비스 디스커버리가 자동으로 조정되어 어떤 포트에 할당되든 서비스들이 서로를 찾습니다.
시크릿 격리 — 각 격리된 실행은 인스턴스 ID로 키가 지정된 자체 사용자 시크릿 저장소를 갖습니다. 한 실행의 연결 문자열과 API 키가 다른 실행으로 누출되지 않습니다.

코드 변경은 필요 없습니다. Aspire의 서비스 디스커버리가 런타임에 엔드포인트를 해석하므로, 포트 할당에 관계없이 모든 것이 올바르게 연결됩니다.

언제 사용할 것인가

같은 AppHost의 여러 인스턴스를 동시에 실행할 때 --isolated를 사용하세요 — 병렬 개발, 자동화된 테스트, AI 에이전트, 또는 git worktree 어떤 경우든. 예측 가능한 포트를 선호하는 단일 인스턴스 개발에는 일반 aspire run이 여전히 잘 작동합니다.

마무리

격리 모드는 실제적이고 점점 더 흔해지는 문제를 해결하는 작은 기능입니다. AI 지원 개발이 더 많은 병렬 워크플로우 — 다중 에이전트, 다중 worktree, 다중 컨텍스트 — 로 우리를 밀어붙이는 만큼, 포트 경쟁 없이 또 다른 인스턴스를 간단히 띄울 수 있는 능력은 필수적입니다.

전체 포스트에서 모든 기술적 세부사항을 확인하고, aspire update --self로 13.2를 받아 시도해 보세요.

VS Code 1.116 — Agents 앱에 키보드 내비게이션과 파일 컨텍스트 자동완성 추가

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

VS Code 1.116은 2026년 4월 릴리스입니다. 최근 몇몇 업데이트보다 가벼운 편이지만, 변경 사항은 집중적이고 의미 있습니다 — 특히 Agents 앱을 매일 사용하고 있다면요.

공식 릴리스 노트를 바탕으로 무엇이 추가되었는지 살펴보겠습니다.

Agents 앱 개선 사항

Agents 앱은 일상 워크플로에 진정한 차이를 만드는 사용성 개선으로 계속 성숙해지고 있습니다:

전용 키바인딩 — 이제 변경 사항 뷰, 변경 사항 내의 파일 트리, 그리고 채팅 커스터마이제이션 뷰에 전용 명령과 키보드 단축키로 포커스를 맞출 수 있습니다. Agents 앱에서 여기저기 클릭하며 탐색하고 있었다면, 이제 완전한 키보드 기반 워크플로가 가능합니다.

접근성 도움말 대화상자 — 채팅 입력 상자에서 Alt+F1을 누르면 사용 가능한 명령과 키바인딩을 보여주는 접근성 도움말 대화상자가 열립니다. 스크린 리더 사용자는 안내 방송의 상세도도 제어할 수 있습니다. 좋은 접근성은 모든 사람에게 도움이 됩니다.

파일 컨텍스트 자동완성 — Agents 앱 채팅에서 #을 입력하면 현재 워크스페이스 범위의 파일 컨텍스트 자동완성이 트리거됩니다. 모든 상호작용을 빠르게 해주는 작은 편의성 개선 중 하나입니다 — 코드를 참조할 때 전체 파일 경로를 입력할 필요가 없어집니다.

CSS `@import` 링크 해석

프론트엔드 개발자에게 좋은 소식: VS Code가 이제 node_modules 경로를 사용하는 CSS @import 참조를 해석합니다. 번들러를 사용할 때 @import "some-module/style.css" 같은 임포트를 Ctrl+클릭으로 따라갈 수 있습니다. 작지만 CSS 워크플로의 마찰점을 제거합니다.

마무리

VS Code 1.116은 세련됨에 관한 것입니다 — Agents 앱을 더 탐색하기 쉽고, 더 접근 가능하며, 더 키보드 친화적으로 만드는 것. Agents 앱에서 상당한 시간을 보내고 있다면 (그리고 많은 분들이 그럴 것으로 생각합니다), 이러한 변경 사항들은 쌓여갑니다.

전체 목록은 전체 릴리스 노트를 확인하세요.

몰랐던 Visual Studio 플로팅 윈도우 설정 (하지만 알아야 할)

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

Visual Studio에서 여러 모니터를 사용한다면 (솔직히 요즘 누가 안 쓰겠어요?), 아마 이런 불편함을 경험했을 겁니다: 플로팅 도구 창이 메인 IDE를 최소화하면 사라지고, 항상 다른 모든 것 위에 표시되며, 작업 표시줄에 별도의 버튼으로 나타나지 않습니다. 일부 워크플로에서는 괜찮지만 멀티 모니터 설정에서는 정말 답답합니다.

Visual Studio 팀의 Mads Kristensen이 플로팅 윈도우의 동작을 완전히 바꾸는 잘 알려지지 않은 설정을 공유했습니다. 드롭다운 하나. 그게 전부입니다.

설정

Tools > Options > Environment > Windows > Floating Windows

드롭다운 “These floating windows are owned by the main window"에는 세 가지 옵션이 있습니다:

None — 완전한 독립. 모든 플로팅 윈도우가 자체 작업 표시줄 항목을 가지며 일반 Windows 창처럼 동작합니다.
Tool Windows (기본값) — 문서는 자유롭게 플로팅, 도구 창은 IDE에 연결됩니다.
Documents and Tool Windows — 클래식 Visual Studio 동작, 모든 것이 메인 창에 연결됩니다.

멀티 모니터 설정에서 “None"이 최적인 이유

None으로 설정하면 갑자기 모든 플로팅 도구 창과 문서가 진짜 Windows 애플리케이션처럼 동작합니다. 작업 표시줄에 나타나고, Visual Studio 메인 창을 최소화해도 보이며, 더 이상 모든 것 앞으로 강제되지 않습니다.

이것을 PowerToys FancyZones와 결합하면 완전히 달라집니다. 모니터 전체에 커스텀 레이아웃을 만들고, 솔루션 탐색기를 한 존에, 디버거를 다른 존에, 코드 파일을 원하는 곳에 배치하세요. 모든 것이 제자리에 있고, 모든 것이 독립적으로 접근 가능하며, 작업 공간이 혼란스럽지 않고 정돈된 느낌입니다.

빠른 추천

멀티 모니터 파워 유저: None으로 설정하고 FancyZones와 함께 사용
가끔 플로팅하는 분: Tool Windows (기본값)가 좋은 중간 지점
전통적인 워크플로: Documents and Tool Windows가 클래식한 방식 유지

프로 팁: 아무 도구 창의 제목 표시줄에서 Ctrl + 더블 클릭으로 즉시 플로팅 또는 도킹할 수 있습니다. 설정 변경 후 재시작이 필요 없습니다.

마무리

전형적인 “이걸 왜 몰랐지” 설정입니다. Visual Studio의 플로팅 윈도우가 한 번이라도 불편했다면, 지금 바로 바꾸러 가세요.

자세한 내용과 스크린샷은 전체 포스트에서 확인하세요.

VS Code 1.115 — 백그라운드 터미널 알림, SSH 에이전트 모드 등

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115가 출시되었습니다. 주요 기능 면에서는 가벼운 릴리스이지만, AI 코딩 어시스턴트를 매일 사용하고 있다면 에이전트 관련 개선사항들이 정말 유용합니다.

실제로 알아둘 가치가 있는 것들을 짚어보겠습니다.

백그라운드 터미널이 에이전트에게 알림을 보냅니다

이번 릴리스의 핵심 기능입니다. 백그라운드 터미널이 이제 명령이 완료되면 종료 코드와 터미널 출력을 포함하여 에이전트에게 자동으로 알림을 보냅니다. 백그라운드 터미널의 입력 프롬프트도 감지되어 사용자에게 표시됩니다.

왜 중요할까요? Copilot의 에이전트 모드로 빌드 명령이나 테스트 스위트를 백그라운드에서 실행해 본 적이 있다면, “그거 끝났나?“라는 고통을 알 것입니다. 백그라운드 터미널은 기본적으로 실행 후 잊어버리는 방식이었습니다. 이제 에이전트가 dotnet build나 dotnet test가 완료되면 알림을 받고, 출력을 확인하고, 그에 따라 대응할 수 있습니다. 작은 변화지만 에이전트 기반 워크플로우의 신뢰성을 크게 향상시킵니다.

또한 새로운 send_to_terminal 도구가 추가되어 에이전트가 사용자 확인을 거쳐 백그라운드 터미널에 명령을 보낼 수 있게 되었습니다. 이로써 run_in_terminal에 타임아웃을 설정하면 터미널이 백그라운드로 이동하고 읽기 전용이 되는 문제가 해결되었습니다.

SSH 원격 에이전트 호스팅

VS Code가 이제 SSH를 통해 원격 머신에 연결하고, CLI를 자동으로 설치하여 에이전트 호스트 모드로 시작할 수 있습니다. 이는 AI 에이전트 세션이 원격 환경을 직접 타겟팅할 수 있다는 의미입니다. Linux 서버나 클라우드 VM에서 빌드하고 테스트하는 .NET 개발자에게 유용합니다.

에이전트 세션의 편집 추적

에이전트 세션 중에 수행된 파일 편집이 이제 diff, 실행 취소/다시 실행, 상태 복원과 함께 추적되고 복원됩니다. 에이전트가 코드를 변경했는데 문제가 생기면, 정확히 무엇이 변경되었는지 확인하고 롤백할 수 있습니다. 에이전트가 코드베이스를 수정하도록 맡길 때 마음의 평화를 줍니다.

브라우저 탭 인식 및 기타 개선사항

몇 가지 추가적인 생활의 질 개선사항:

브라우저 탭 추적 — 채팅이 세션 중 열린 브라우저 탭을 추적하고 링크할 수 있어 에이전트가 보고 있는 웹 페이지를 참조할 수 있습니다
터미널 파일 붙여넣기 — Ctrl+V, 드래그 앤 드롭 또는 우클릭으로 터미널에 파일(이미지 포함)을 붙여넣기
미니맵의 테스트 커버리지 — 테스트 커버리지 표시가 이제 미니맵에 나타나 빠른 시각적 개요를 제공합니다
Mac에서 핀치 투 줌 — 통합 브라우저가 핀치 투 줌 제스처를 지원합니다
세션의 Copilot 사용 권한 — 상태 표시줄이 세션 보기에서 사용량 정보를 표시합니다
파일로 이동의 파비콘 — 열린 웹 페이지가 빠른 선택 목록에 파비콘을 표시합니다

마무리

VS Code 1.115는 점진적인 릴리스이지만, 에이전트 개선 — 백그라운드 터미널 알림, SSH 에이전트 호스팅, 편집 추적 — 이 합쳐져 AI 지원 개발에서 눈에 띄게 부드러운 경험을 제공합니다. .NET 프로젝트에서 Copilot의 에이전트 모드를 사용하고 있다면, 이런 것들이 매일의 마찰을 줄여주는 생활의 질 개선입니다.

모든 세부사항은 전체 릴리스 노트를 확인하세요.

Aspire 13.2에 문서 CLI가 탑재 — AI 에이전트도 사용할 수 있습니다

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

Aspire AppHost 깊숙이 들어가서 통합을 연결하는 중에, Redis 통합이 정확히 어떤 파라미터를 기대하는지 확인해야 하는 그 순간을 아시죠? Alt-Tab으로 브라우저로 전환하고, aspire.dev를 뒤지고, API 문서를 눈을 가늘게 뜨고 보다가, 다시 에디터로 돌아옵니다. 컨텍스트를 잃었고, 플로우가 끊겼습니다.

Aspire 13.2가 바로 그 해결책을 출시했습니다. aspire docs CLI를 사용하면 터미널에서 직접 Aspire 공식 문서를 검색하고, 탐색하고, 읽을 수 있습니다. 그리고 재사용 가능한 서비스에 기반하고 있어서, AI 에이전트와 스킬이 같은 명령어를 사용해 문서를 조회할 수 있습니다. 존재하지 않는 API를 환각하는 대신에요.

이것이 실제로 해결하는 문제

David Pine이 원문에서 정확히 짚었습니다: AI 에이전트는 개발자가 Aspire 앱을 구축하는 것을 돕는 데 끔찍했습니다. aspire run 대신 dotnet run을 추천하고, aspire.dev에 있는 문서에 대해 learn.microsoft.com을 참조하고, 오래된 NuGet 패키지를 제안하고, 그리고 — 개인적으로 가장 좋아하는 — 존재하지 않는 API를 환각했습니다.

왜 그럴까요? Aspire가 폴리글랏이 된 것보다 .NET 전용이었던 기간이 훨씬 길었고, LLM은 최신 기능보다 앞선 학습 데이터로 작동하기 때문입니다. AI 에이전트에게 현재 문서를 실제로 조회할 수 있는 능력을 주면, 추측을 멈추고 유용해지기 시작합니다.

세 가지 명령어, 브라우저 탭은 제로

CLI는 상쾌할 정도로 간단합니다:

모든 문서 나열

aspire docs list

aspire.dev에서 사용 가능한 모든 문서 페이지를 반환합니다. 기계가 읽을 수 있는 출력이 필요하세요? --format Json을 추가하세요.

주제 검색

aspire docs search "redis"

가중 관련성 점수로 제목과 콘텐츠 모두를 검색합니다. 내부적으로 문서 도구를 구동하는 것과 같은 검색 엔진입니다. 제목, 슬러그, 관련성 점수가 포함된 순위별 결과를 얻을 수 있습니다.

전체 페이지 읽기 (또는 한 섹션만)

aspire docs get redis-integration

전체 페이지를 마크다운으로 터미널에 스트리밍합니다. 한 섹션만 필요하세요?

aspire docs get redis-integration --section "Add Redis resource"

외과적 정밀도. 500줄을 스크롤할 필요 없습니다. 필요한 부분만.

AI 에이전트 관점

AI 도구로 개발하는 우리 개발자들에게 흥미로워지는 부분입니다. 같은 aspire docs 명령어가 스킬, MCP 서버, 또는 간단한 CLI 래퍼를 통해 AI 에이전트의 도구로 작동합니다.

AI 어시스턴트가 오래된 학습 데이터를 기반으로 Aspire API를 지어내는 대신, aspire docs search "postgres"를 호출하고, 공식 통합 문서를 찾고, 올바른 페이지를 읽고, 문서화된 접근 방식을 제공할 수 있습니다. 실시간이고 최신인 문서 — 모델이 6개월 전에 기억한 것이 아닙니다.

이 뒤의 아키텍처는 의도적입니다. Aspire 팀은 일회성 통합 대신 재사용 가능한 서비스(IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache)를 구축했습니다. 이는 같은 검색 엔진이 터미널의 사람, 에디터의 AI 에이전트, CI 파이프라인의 자동화를 위해 작동한다는 의미입니다.

실제 시나리오

터미널에서 빠른 조회: 파일 세 개 깊이에 있고 Redis 설정 파라미터가 필요합니다. 두 개의 명령어, 90초, 다시 작업으로:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI 지원 개발: VS Code 스킬이 CLI 명령어를 래핑합니다. “내 AppHost에 PostgreSQL 데이터베이스를 추가해"라고 물으면 에이전트가 답변하기 전에 실제 문서를 조회합니다. 환각 없음.

CI/CD 검증: 파이프라인이 공식 문서에 대해 AppHost 설정을 프로그래밍 방식으로 검증합니다. --format Json 출력은 jq 및 다른 도구와 깔끔하게 연결됩니다.

커스텀 지식 베이스: 자체 AI 도구를 구축하고 있나요? 구조화된 JSON 출력을 지식 베이스에 직접 파이프:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

웹 스크래핑 없음. API 키 없음. 문서 도구가 내부적으로 사용하는 것과 같은 구조화된 데이터.

문서는 항상 최신 상태

이것이 제가 가장 높이 평가하는 부분입니다. CLI는 스냅샷을 다운로드하지 않습니다 — ETag 기반 캐싱으로 aspire.dev를 조회합니다. 문서가 업데이트되는 순간, CLI와 그 위에 구축된 모든 스킬이 이를 반영합니다. 오래된 복사본도 없고, “하지만 위키에는…“하는 순간도 없습니다.

마무리

aspire docs는 실제 문제를 깔끔하게 해결하는 작은 기능 중 하나입니다. 사람은 터미널 네이티브 문서 접근을 얻습니다. AI 에이전트는 추측을 멈추고 실제 문서를 참조할 수 있는 방법을 얻습니다. 그리고 모든 것이 같은 진실의 원천에 의해 뒷받침됩니다.

.NET Aspire로 개발하고 있고 아직 CLI를 시도해보지 않았다면, aspire docs search "여러분의-주제" 를 실행하고 어떤 느낌인지 확인해 보세요. 그런 다음 사용 중인 AI 스킬이나 자동화 설정에 이 명령어들을 래핑하는 것을 고려해 보세요 — 여러분의 에이전트가 감사할 것입니다.

문서 도구가 어떻게 만들어졌는지에 대한 David Pine의 심층 분석과 모든 세부 사항이 담긴 공식 CLI 레퍼런스를 확인해 보세요.

azd로 AI 에이전트를 로컬에서 실행하고 디버깅할 수 있게 됐다 — 2026년 3월 변경사항 정리

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

한 달에 7개 릴리스. Azure Developer CLI (azd) 팀이 2026년 3월에 발행한 것이며, 메인 기능은 제가 기다리던 것입니다: AI 에이전트를 위한 로컬 실행 및 디버그 루프.

PC Chan이 전체 요약을 게시했는데, 내용이 많지만 AI 기반 앱을 구축하는 .NET 개발자에게 실제로 중요한 것만 걸러보겠습니다.

배포 없이 AI 에이전트 실행 및 디버깅

이것이 핵심입니다. 새로운 azure.ai.agents 확장이 AI 에이전트를 위한 적절한 이너 루프 경험을 제공하는 명령을 추가합니다:

azd ai agent run — 에이전트를 로컬에서 시작
azd ai agent invoke — 메시지 전송 (로컬 또는 배포된 에이전트)
azd ai agent show — 컨테이너 상태 및 건강 표시
azd ai agent monitor — 컨테이너 로그를 실시간 스트리밍

이전에는 AI 에이전트 테스트가 변경할 때마다 Microsoft Foundry로 배포하는 것을 의미했습니다. 이제 로컬에서 반복하고, 에이전트 동작을 테스트하고, 준비가 되면 배포할 수 있습니다.

GitHub Copilot이 azd 프로젝트를 설정

azd init에 “Set up with GitHub Copilot (Preview)” 옵션이 추가됐습니다. 프로젝트 구조에 대한 프롬프트에 수동으로 답하는 대신, Copilot 에이전트가 구성을 생성합니다. 명령이 실패하면 azd가 AI 지원 문제 해결을 제공합니다.

Container App Jobs 및 배포 개선

Container App Jobs: azd가 기존 host: containerapp 설정으로 Microsoft.App/jobs 배포
설정 가능한 배포 타임아웃: azd deploy의 새 --timeout 플래그와 azure.yaml의 deployTimeout 필드
원격 빌드 폴백: ACR 빌드 실패 시 로컬 Docker/Podman 빌드로 자동 폴백
로컬 프리플라이트 검증: 배포 전 Bicep 매개변수를 로컬에서 검증

DX 개선

자동 pnpm/yarn 감지 — JS/TS 프로젝트용
pyproject.toml 지원 — Python 패키징용
로컬 템플릿 디렉토리 — azd init --template이 파일시스템 경로 허용
개선된 오류 메시지 — --no-prompt 모드
빌드 환경 변수 — 모든 프레임워크 빌드 서브프로세스에 주입 (.NET, Node.js, Java, Python)

마무리

로컬 AI 에이전트 디버그 루프가 이번 릴리스의 스타이지만, 배포 개선과 DX 폴리시의 축적으로 azd가 그 어느 때보다 성숙해졌습니다. Azure에 .NET 앱을 배포하고 있다면 — 특히 AI 에이전트라면 — 이번 업데이트는 가치가 있습니다.

전체 릴리스 노트에서 모든 세부사항을 확인하세요.

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 수정입니다.

Bookmark Studio가 Visual Studio 북마크에 슬롯 기반 내비게이션과 공유 기능을 추가

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

Visual Studio의 북마크는 항상…그럭저럭이었습니다. 하나 설정하고, 다음으로 이동하고, 어떤 게 어떤 건지 잊어버립니다. 작동하지만 강력하다고 부를 수 있는 기능은 아니었습니다.

Mads Kristensen이 Bookmark Studio를 출시했습니다. 정기적으로 북마크를 사용한다면 느꼈을 빈틈을 정확히 채우는 실험적 확장입니다.

슬롯 기반 내비게이션

북마크를 1-9번 슬롯에 할당하고 Alt+Shift+1부터 Alt+Shift+9로 직접 이동할 수 있습니다. 새 북마크는 자동으로 다음 사용 가능한 슬롯을 받습니다.

북마크 관리자

새 도구 창에서 모든 북마크를 표시하고 이름, 파일, 위치, 색상, 슬롯으로 필터링할 수 있습니다.

라벨, 색상, 폴더로 정리

북마크에 라벨, 색상을 추가하고 폴더로 그룹화할 수 있습니다. 메타데이터는 솔루션별로 저장됩니다.

내보내기 및 공유

Bookmark Studio는 북마크를 일반 텍스트, Markdown 또는 CSV로 내보낼 수 있습니다.

코드 이동을 따라가는 북마크

Bookmark Studio는 고정된 텍스트에 상대적으로 북마크를 추적하므로 편집 중 잘못된 줄로 떠내려가지 않습니다.

마무리

Bookmark Studio는 아무것도 재발명하지 않습니다. 수년간 “충분했던” 기능을 진정으로 유용하게 만듭니다. Visual Studio Marketplace에서 다운로드하세요.

Visual Studio 3월 업데이트로 커스텀 Copilot 에이전트 제작 가능 — find_symbol이 큰 변화

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

Visual Studio가 가장 중요한 Copilot 업데이트를 받았습니다. Mark Downie가 3월 릴리스를 발표했는데, 헤드라인은 커스텀 에이전트이지만 솔직히 find_symbol 도구가 워크플로를 가장 많이 바꿀 기능일 수 있습니다.

리포에 커스텀 Copilot 에이전트

Copilot이 팀의 코딩 표준을 따르게 하고 싶으세요? 커스텀 에이전트는 리포의 .github/agents/에 .agent.md 파일로 정의됩니다. 각 에이전트는 워크스페이스 인식, 코드 이해, 도구, 선호 모델, MCP 연결에 대한 전체 접근 권한을 가집니다.

에이전트 스킬: 재사용 가능한 인스트럭션 팩

스킬은 리포의 .github/skills/나 프로필의 ~/.copilot/skills/에서 자동 로드됩니다.

find_symbol: 언어 인식 내비게이션

새로운 find_symbol 도구는 Copilot의 에이전트 모드에 언어 서비스 기반 심볼 내비게이션을 제공합니다. 텍스트 검색 대신 심볼의 모든 참조를 찾고 타입 정보와 스코프에 접근할 수 있습니다.

.NET 개발자에게 이것은 엄청난 개선입니다 — 깊은 타입 계층 구조를 가진 C# 코드베이스가 크게 혜택을 받습니다.

Copilot으로 테스트 프로파일링

Test Explorer 컨텍스트 메뉴에 Profile with Copilot이 추가됐습니다. Profiling Agent가 테스트를 실행하고 자동으로 성능을 분석합니다.

라이브 디버깅 중 Perf Tips

성능 최적화가 이제 디버깅 중에 이루어집니다. Visual Studio가 인라인으로 실행 시간을 표시합니다. 느린 라인을 발견하면 Perf Tip을 클릭하고 Copilot에게 최적화 제안을 요청하세요.

Solution Explorer에서 NuGet 취약점 수정

NuGet 패키지 취약점이 감지되면 Solution Explorer에 직접 Fix with GitHub Copilot 링크가 표시됩니다.

마무리

커스텀 에이전트와 스킬이 헤드라인이지만, find_symbol이 숨겨진 보석입니다 — .NET 코드 리팩토링 시 Copilot의 정확도를 근본적으로 바꿉니다. Visual Studio 2026 Insiders를 다운로드해서 모든 기능을 체험해보세요.

노트북에서 프로덕션까지: 두 개의 명령으로 AI 에이전트를 Microsoft Foundry에 배포

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

“내 컴퓨터에서는 되는데"와 “배포되어 트래픽을 처리 중”—이 사이의 간극을 아시나요? AI 에이전트의 경우 이 간극은 고통스럽게 넓었습니다. 리소스 프로비저닝, 모델 배포, ID 설정, 모니터링 구축 — 이 모든 것이 누군가가 실제로 에이전트를 호출할 수 있기 전에 필요한 작업입니다.

Azure Developer CLI가 이것을 두 개의 명령으로 해결했습니다.

새로운 `azd ai agent` 워크플로

실제로 어떤 모습인지 보여드리겠습니다. AI 에이전트 프로젝트가 있다고 합시다 — 호텔 컨시어지 에이전트라고 하죠. 로컬에서 동작합니다. Microsoft Foundry에서 실행하고 싶습니다.

azd ai agent init
azd up

끝입니다. 두 개의 명령. azd ai agent init이 저장소에 Infrastructure as Code를 생성하고, azd up이 Azure에서 모든 것을 프로비저닝하고 에이전트를 퍼블리시합니다. Foundry 포털에서 에이전트로의 직접 링크를 받게 됩니다.

내부에서 일어나는 일

init 명령은 저장소에 실제 검사 가능한 Bicep 템플릿을 생성합니다:

Foundry Resource (최상위 컨테이너)
Foundry Project (에이전트가 존재하는 곳)
모델 배포 설정 (GPT-4o 등)
적절한 RBAC 역할 할당이 있는 관리 ID
서비스 맵용 azure.yaml
에이전트 메타데이터와 환경 변수가 있는 agent.yaml

핵심 포인트: 이 모든 것은 여러분 것입니다. 저장소에 버전 관리되는 Bicep입니다. 검사하고, 커스터마이즈하고, 에이전트 코드와 함께 커밋할 수 있습니다. 마법의 블랙박스는 없습니다.

개발 내부 루프

정말 마음에 드는 것은 로컬 개발 경험입니다. 에이전트 로직을 반복할 때, 프롬프트를 바꿀 때마다 재배포하고 싶지 않죠:

azd ai agent run

이것으로 에이전트를 로컬에서 시작합니다. azd ai agent invoke와 결합하여 테스트 프롬프트를 보내면 빠른 피드백 루프를 얻습니다. 코드 편집, 재시작, 호출, 반복.

invoke 명령은 라우팅도 똑똑합니다 — 로컬 에이전트가 실행 중이면 자동으로 그쪽을 타겟합니다. 실행 중이 아니면 원격 엔드포인트로 갑니다.

실시간 모니터링

이것이 저를 설득한 기능입니다. 에이전트가 배포되면:

azd ai agent monitor --follow

에이전트를 통과하는 모든 요청과 응답이 실시간으로 터미널에 스트리밍됩니다. 프로덕션 문제를 디버깅하는 데 이것은 값으로 매길 수 없습니다. Log Analytics를 뒤질 필요 없이, 메트릭이 집계되길 기다릴 필요 없이 — 지금 무슨 일이 일어나고 있는지 볼 수 있습니다.

전체 명령 세트

빠른 참조:

명령	기능
`azd ai agent init`	IaC로 Foundry 에이전트 프로젝트 스캐폴드
`azd up`	Azure 리소스 프로비저닝 및 에이전트 배포
`azd ai agent invoke`	원격 또는 로컬 에이전트에 프롬프트 전송
`azd ai agent run`	개발용으로 에이전트를 로컬에서 실행
`azd ai agent monitor`	퍼블리시된 에이전트의 실시간 로그 스트리밍
`azd ai agent show`	에이전트 상태 및 건강 확인
`azd down`	모든 Azure 리소스 정리

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

공지의 예제는 Python 기반이지만, 인프라 이야기는 언어에 구애받지 않습니다. .NET 에이전트도 동일한 Bicep 스캐폴딩, 동일한 관리 ID 설정, 동일한 모니터링 파이프라인을 받습니다. 그리고 이미 .NET Aspire 앱이나 Azure 배포에 azd를 사용하고 있다면, 기존 워크플로에 바로 통합됩니다.

AI 에이전트의 배포 간극은 생태계에서 가장 큰 마찰 포인트 중 하나였습니다. 작동하는 프로토타입에서 적절한 ID, 네트워킹, 모니터링을 갖춘 프로덕션 엔드포인트로 전환하는 데 일주일의 DevOps 작업이 필요해서는 안 됩니다. 이제 두 개의 명령과 몇 분이면 됩니다.

마무리

azd ai agent는 지금 사용할 수 있습니다. 인프라 설정이 너무 많은 작업처럼 보여서 AI 에이전트 배포를 미루고 있었다면 시도해 보세요. 프론트엔드 채팅 앱 통합을 포함한 완전한 단계별 가이드는 전체 워크스루를 확인하세요.