Cli | The .NET Blog

dotnet new WinUI: Visual Studio 없이 Windows 앱 만들기

Emiliano Montesdeoca — Wed, 27 May 2026 00:00:00 +0000

WinUI 개발에는 이전에 Visual Studio가 필요했습니다. 이것이 바뀌고 있습니다: Microsoft가 dotnet new에서 작동하는 WinUI용 오픈 소스 프로젝트 및 항목 템플릿을 공개하여 Windows 앱 개발을 표준 CLI 워크플로우에 통합했습니다.

세 가지 명령으로 시작하기

# 템플릿 설치
dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates

# NavigationView 앱 만들기
dotnet new winui-navview -n MyApp

# 실행
cd MyApp
dotnet run

Visual Studio 없음, 수동 프로젝트 설정 없음. 앱은 dotnet run으로 실행됩니다.

포함된 내용

빈 템플릿 (dotnet new winui) — Fluent 제목 표시줄이 이미 연결된 현대적인 출발점. .ico 에셋이 포함된 업데이트된 기본 앱 아이콘, 올바른 밝은/어두운 모드 기본값. 기본 사항을 직접 설정해야 했던 이전 빈 템플릿보다 낫습니다.

NavigationView 템플릿 (dotnet new winui-navview) — 마스터-상세 탐색 패턴, NavigationView, 현대적인 제목 표시줄, 다중 페이지 탐색 구조가 완전히 연결되어 있습니다. 탐색 기반 앱을 위한 표준 Windows 앱 실루엣을 따릅니다. 사이드 탐색이 있는 것을 빌드하는 경우 여기서 시작하세요.

두 템플릿 모두 Windows 앱 실루엣 — 레이아웃, 탐색, 시각적 구조를 위한 현대적인 Fluent Design 패턴 — 을 즉시 따릅니다.

Visual Studio를 사용하지 않는 개발자에게 중요한 이유

VS Code, Rider 또는 명령줄 도구를 사용하는 WinUI 개발자들은 홀대받아 왔습니다. 기존 Visual Studio 템플릿은 VS 외부에서 사용할 수 없었고, 프로젝트 구조를 수동으로 다시 만들고 기본 사항을 연결해야 했습니다.

이 템플릿들은 오픈 소스입니다 (WindowsAppSDK PR #6407 참조). 커뮤니티 피드백에서 개발되었으며 지금 사용 가능합니다. Visual Studio 지원도 진행 중 — 이 동일한 템플릿들은 결국 거기서도 작동할 것입니다.

WinUI 프로젝트 설정을 스크립트로 작성하거나, CI에 통합하거나, 단순히 Visual Studio가 아닌 다른 에디터를 사용하려는 팀에게 이것은 의미 있는 개선입니다.

원본 게시물: Introducing dotnet new WinUI templates

Cosmos DB Shell이 공개 미리 보기 중 — 그리고 MCP 서버가 내장되어 있습니다

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

Cosmos DB 질문 하나에 답하기 위해 포털 탭, SDK 샘플, 반쯤 완성된 스크립트 사이를 왔다갔다 해야 했던 경험이 있다면, 이 프로젝트가 제거하려는 마찰을 이미 알고 있을 것입니다.

Azure Cosmos DB Shell이 방금 공개 미리 보기에 들어갔습니다. bash와 유사한 구문을 가진 오픈 소스 CLI이며 — 이것을 흥미롭게 만드는 부분 — 통합된 MCP 서버를 갖추고 있습니다.

다른 데이터베이스 CLI와의 차별점

CLI 자체는 유용합니다: 친숙한 명령, 스크립팅 지원, CI/CD 통합. 이 부분은 개발자 중심 데이터베이스 도구의 기본입니다.

흥미로운 부분은 MCP 서버 통합입니다. CLI가 노출하는 모든 명령이 AI 에이전트가 호출할 수 있는 MCP 도구로 사용 가능해집니다. 사용자 정의 API 레이어가 없고, 작성할 통합 코드도 없습니다. 에이전트가 다음을 수행할 수 있습니다:

cd, ls, pwd로 데이터베이스 계층 구조 탐색
query로 SQL 쿼리를 실행하고 구조화된 결과 받기
create item, update, rm으로 항목 생성 및 수정
mkdb, mkcon, rmdb, rmcon으로 데이터베이스 및 컨테이너 관리
endpoint, pwd로 현재 컨텍스트 확인

핵심 변화: 에이전트가 Cosmos DB API와 대화하는 것이 아니라 — 당신이 사용하는 것과 동일한 셸 인터페이스와 대화합니다. 명령은 결정론적이고, 감사 가능하며, 정확히 무슨 일이 일어나고 있는지 검사할 수 있도록 오픈 소스입니다.

오픈 소스 기반이 중요합니다

이것은 블랙박스 관리형 서비스가 아닙니다. 셸은 오픈 소스이며, 이것이 의미하는 바는:

보안 팀이 구현을 감사할 수 있음
플랫폼 팀이 특정 표준에 맞게 포크하고 확장할 수 있음
개발자들이 모두에게 도움이 되는 개선 사항을 기여할 수 있음

AI 도구를 채택하는 기업 팀에게 “정확히 어떻게 작동하는지 볼 수 있습니까"는 점점 더 선택적인 요구 사항이 아닙니다. 여기서 오픈 소스는 의미 있는 차별화 요소입니다.

더 쉬워지는 세 가지 시나리오

지능적인 데이터 분석 — 에이전트를 셸에 연결하고, 자연어로 질문하고, 구조화된 쿼리 결과를 얻습니다. 에이전트는 쿼리 구성을 처리하고, 셸은 실행을 처리합니다.

자율적인 데이터 관리 — Cosmos DB에서 데이터를 생성, 업데이트 또는 제거해야 하는 워크플로우는 사용자 정의 통합 없이 MCP 도구를 통해 수행할 수 있습니다.

실시간 모니터링 및 알림 — 에이전트가 주기적으로 컨테이너를 쿼리하고, 결과를 비교하며, 적절한 알림 채널을 통해 이상 징후를 표시할 수 있습니다.

MCP 인터페이스는 이러한 시나리오를 MCP를 지원하는 모든 AI 플랫폼과 조합 가능하게 만듭니다 — Microsoft 도구만이 아닙니다.

시작하기

셸은 공개 미리 보기 중입니다. 설치하고, Cosmos DB 연결을 구성하고, MCP 서버를 활성화합니다. 거기서부터 MCP 호환 에이전트 호스트라면 어디서든 도구를 검색하고 사용할 수 있습니다.

원본 게시물: Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

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 저장소를, 모든 세부 정보는 원본 발표를 참조하세요.

터미널 감시는 그만: 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를 설치하세요.

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를 받아 시도해 보세요.

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 레퍼런스를 확인해 보세요.

Cli | The .NET Blog

dotnet new WinUI: Visual Studio 없이 Windows 앱 만들기

세 가지 명령으로 시작하기

포함된 내용

Visual Studio를 사용하지 않는 개발자에게 중요한 이유

Cosmos DB Shell이 공개 미리 보기 중 — 그리고 MCP 서버가 내장되어 있습니다

다른 데이터베이스 CLI와의 차별점

오픈 소스 기반이 중요합니다

더 쉬워지는 세 가지 시나리오

시작하기

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

winapp run: 어디서나 F5

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

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

기타 새로운 기능

설치 방법

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

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

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

격리 모드와 결합하기

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

마무리

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

작동 방식

한 가지 참고사항

왜 중요한가

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

문제는 현실입니다

에이전트 인프라로서의 Aspire

볼링 범퍼 비유

시작하기

마무리

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

해결책: --isolated

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

내부 작동 원리

언제 사용할 것인가

마무리

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

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

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

모든 문서 나열

주제 검색

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

AI 에이전트 관점

실제 시나리오

문서는 항상 최신 상태

마무리

해결책: `--isolated`