Aspire | The .NET Blog

프라이빗 Endpoints, VNet, NSG — Aspire가 이제 네트워크를 관리합니다

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

이 시나리오를 너무 많이 봤습니다. 앱이 완성됩니다. 데모가 훌륭합니다. 그런 다음 보안 체크리스트가 나타납니다: 스토리지를 공용 인터넷에서 제거하고, VNet 내에서 실행하고, 파트너 허용 목록을 위한 아웃바운드 IP를 제공하고, 올바른 서브넷만 올바른 서비스와 통신한다는 것을 증명합니다.

이 시점에서 애플리케이션 모델과 인프라 모델이 유지 관리하기 어려운 방식으로 분리되기 시작합니다.

Aspire의 새로운 Azure 엔터프라이즈 네트워킹 지원은 이 문제를 직접적으로 해결합니다. AppHost에서 해당 네트워크를 사용하는 리소스 옆에 네트워크 모양을 설명합니다.

구성 요소

각 Azure 네트워킹 개념이 무엇을 위한 것인지 요약:

기능	사용 시기	중요한 이유
가상 네트워크	프라이빗 주소 공간이 필요할 때	서브넷, 프라이빗 엔드포인트 및 라우팅을 위한 네트워크 경계
서브넷	VNet 내에서 워크로드를 분리해야 할 때	시스템의 각 부분이 자체 주소 범위와 정책 표면을 가짐
위임된 서브넷	플랫폼 서비스(예: ACA)가 서브넷을 관리해야 할 때	서비스가 VNet에 관리되는 인프라를 안전하게 배치할 수 있음
NAT 게이트웨이	예측 가능한 아웃바운드 공용 IP가 필요할 때	허용 목록 및 감사를 위한 안정적인 주소
프라이빗 엔드포인트	PaaS 리소스에 프라이빗하게 접근하고 싶을 때	VNet 내에 해당 서비스의 프라이빗 IP를 배치하고 공용 노출 제거
NSG	서브넷 수준의 트래픽 규칙이 필요할 때	서브넷별 인바운드 및 아웃바운드 트래픽에 대한 명시적 허용/거부

AppHost에서 설명하기

여기서 핵심 변화는 시간이 지남에 따라 앱 모델에서 멀어지는 별도의 Bicep 파일이 아니라 해당 네트워크를 사용하는 리소스 옆에 네트워크를 모델링한다는 것입니다.

AppHost에서 다음을 수행할 수 있습니다:

AddVirtualNetwork() 및 AddSubnet()으로 VNet 및 서브넷 만들기
안정적인 아웃바운드 IP를 위해 서브넷에 NAT 게이트웨이 연결
스토리지, Key Vault, SQL 및 기타 PaaS 서비스에 대한 프라이빗 엔드포인트 만들기
인바운드 및 아웃바운드 보안 규칙으로 NSG 정의
교차 리소스 정책을 위한 네트워크 보안 경계 구성

결과적으로 azd up을 실행하면 인프라가 앱 모델이 필요하다고 말하는 것과 일치합니다. 수동으로 유지 관리되는 템플릿이 말하는 것이 아닙니다.

실제 애플리케이션에 중요한 이유

Aspire에서 네트워크가 모델링되면 훨씬 쉬워지는 몇 가지:

Key Vault 및 스토리지를 위한 프라이빗 엔드포인트 — 해당 리소스에 WithPrivateEndpoint()를 설명하면 Aspire가 DNS 영역 구성 및 엔드포인트 연결을 처리합니다. 앱은 절대 변경되지 않습니다.

일관된 아웃바운드 IP — 관련 서브넷에 NAT 게이트웨이를 추가하면 앱의 모든 아웃바운드 요청이 알려진 안정적인 IP를 통해 이동합니다. 파트너가 허용 목록에 추가할 수 있습니다. 감사자가 추적할 수 있습니다.

코드에서 NSG 규칙 — 포털을 클릭하거나 Bicep 스니펫을 유지 관리하는 대신 보안 규칙이 보호하는 리소스 옆 AppHost에 존재합니다.

이것이 데모를 흥미롭게 만들지는 않지만 프로덕션 시스템을 유지 가능하게 만드는 통합의 종류입니다.

결론

프로젝트 라이프사이클 후반에 네트워크 보안이 나타나는 것은 처음부터 앱과 함께 모델링하면 해결된 문제입니다. Aspire의 엔터프라이즈 네트워킹 지원은 별도의 인프라 트랙 없이도 이를 가능하게 합니다.

원본 게시물의 전체 내용: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Kubernetes 지원, 브라우저 로그 및 Aspireify 스킬

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

5주는 릴리스로서 긴 시간이 아니지만 Aspire 13.3은 그렇게 느껴지지 않습니다. 주요 항목들은 의미 있습니다: Helm을 사용한 Kubernetes 및 AKS 퍼스트클래스 배포, Aspireify라는 에이전트 지원 온보딩 스킬, 대시보드에서 직접 브라우저 로그 캡처, 구조화된 명령 결과. 여기에 45개의 새 기능, 134개의 개선 사항, 93개의 버그 수정도 포함됩니다.

하이라이트를 살펴보겠습니다.

Aspireify: 에이전트 지원 온보딩

기존 프로젝트에 Aspire를 추가하는 것은 간단해 보입니다 — AppHost를 추가하면 끝. 실제로는 많은 조사가 필요합니다: 어떤 포트가 중요한지, 어떤 환경 변수가 실제 의존성인지, 어떤 Docker Compose 서비스를 Aspire 통합에 매핑해야 하는지.

새로운 Aspireify 스킬은 코딩 에이전트에게 정확히 이를 위한 가이드 워크플로우를 제공합니다. aspire init이 스켈레톤 AppHost를 만들 때, Aspireify 스킬은 에이전트가 저장소를 검사하고, 이미 어떻게 작동하는지 이해하고, 앱에 맞게 AppHost를 연결하는 데 도움을 줍니다 — 반대가 아닙니다.

기본 입장은 “코드 변경을 최소화"입니다. 앱이 이미 DATABASE_URL을 읽는다면, 에이전트는 구성을 다시 작성하도록 요청하는 대신 WithEnvironment()로 매핑합니다. 포트가 하드코딩된 경우 스킬은 에이전트에게 언제 보존해야 하는지 알려줍니다.

이것이 검토할 작업을 더 생성하는 것이 아니라 실제로 시간을 절약하는 AI 툴링의 유형입니다.

퍼스트클래스 Kubernetes 및 AKS 배포

이것은 한동안 위시리스트에 있었습니다. Aspire 13.3은 Helm을 사용한 Kubernetes 및 AKS 퍼스트클래스 배포 지원을 제공합니다. 이제 Aspire 도구에서 직접 AKS를 배포 대상으로 지정할 수 있습니다.

AKS에서 이미 프로덕션 워크로드를 실행 중인 팀에게 이것은 중요한 격차를 메웁니다. Aspire 앱 모델은 이제 Helm 차트를 수동으로 작성할 필요 없이 로컬 개발에서 Kubernetes로의 깔끔한 경로를 갖게 됩니다.

대시보드의 브라우저 로그

이것은 프론트엔드 문제를 디버깅하기 전까지는 작아 보이는 기능 중 하나입니다.

새로운 WithBrowserLogs() API는 엔드포인트를 지원하는 모든 리소스에 추적된 브라우저 리소스를 첨부합니다. Aspire는 개인 CDP 파이프를 사용하여 Chromium을 시작하고 콘솔 로그, 네트워크 요청 및 오류를 리소스의 로그 스트림으로 직접 스트리밍합니다:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost도 동일하게 지원합니다:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

콘솔 오류, 실패한 네트워크 요청, 클라이언트 측 예외 — 이미 트레이스와 메트릭을 관찰하고 있는 동일한 대시보드에서 모두 볼 수 있습니다. 기본적인 것들을 위해 브라우저 DevTools로 탭을 전환할 필요가 없습니다.

구조화된 명령 결과

리소스 명령이 중요한 업그레이드를 받았습니다. 이전에는 명령이 성공/실패를 반환했습니다. 이제 구조화된 결과를 반환합니다: 모델, 대시보드 UI, CLI 및 MCP 도구를 통해 흐르는 텍스트, JSON 또는 Markdown입니다.

대시보드는 헤더의 새로운 알림 센터로 이 모든 것을 묶습니다. 명령 결과는 Markdown 렌더링과 “응답 보기” 작업이 있는 타임스탬프된 알림으로 나타납니다.

이는 리소스 명령을 진정으로 조합 가능하게 만듭니다. 이제 통합은 단순히 어딘가의 상태를 변경하는 것이 아니라 터널 URL과 같은 의미 있는 출력을 반환하는 명령을 노출할 수 있습니다.

결론

Aspire 13.3은 Kubernetes 지원만으로도 업데이트할 가치가 있습니다. 브라우저 로그와 구조화된 명령 결과는 일상적인 개발 워크플로우에서 빠르게 쌓이는 삶의 질 향상 유형입니다.

전체 릴리스 노트: What’s New in Aspire 13.3

Aspire 13.2: Bun 지원, 더 나은 컨테이너, 그리고 적은 디버깅 마찰

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

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

.NET 백엔드와 JavaScript 프론트엔드를 Aspire에서 구축하고 있다면, 13.2는 조용히 하루를 더 나게 만드는 업데이트입니다.

Bun이 이제 일급 시민입니다

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

팀이 이미 Bun을 사용한다면, Aspire는 더 이상 역류를 강요하지 않습니다.

Yarn이 더 안정적으로

withYarn()과 addViteApp()에서 신비한 실패가 줄어듭니다.

컨테이너 개선

ImagePullPolicy.Never로 레지스트리 없이 로컬 이미지 사용. PostgreSQL 18+ 데이터 볼륨이 이제 올바르게 작동합니다.

디버깅 개선

코어 타입에 DebuggerDisplayAttribute, WaitFor의 개선된 오류 메시지, 올바른 타이밍에 발화하는 BeforeResourceStartedEvent.

David Pine의 원본 포스트: Aspire 13.2: Bun Support and Container Enhancements.

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의 분리 모드가 워크플로를 바꾼다

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를 설치하세요.

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

Aspire 13.2 대시보드에 텔레메트리 API가 추가됐다 — 그리고 모든 것이 바뀐다

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

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

.NET Aspire로 분산 앱을 구축해왔다면, 대시보드가 전체 경험에서 가장 훌륭한 부분이라는 걸 이미 알고 있을 겁니다. 모든 트레이스, 로그, 메트릭이 한 곳에 — 외부 Jaeger도 필요 없고, Seq 설정도 필요 없고, “다른 터미널 확인해 볼게” 같은 순간도 없습니다.

Aspire 13.2가 이를 크게 개선했습니다. James Newton-King이 업데이트를 발표했는데, 솔직히? 텔레메트리 내보내기와 API 기능만으로도 업그레이드할 가치가 있습니다.

텔레메트리를 제대로 내보내기

우리 모두 겪어본 시나리오입니다: 분산 문제를 디버깅하면서 20분간의 설정 끝에 마침내 재현했는데, 이제 팀에게 무슨 일이 있었는지 공유해야 합니다. 이전에는? 스크린샷. 트레이스 ID 복사 붙여넣기. 항상 그러는 것처럼.

Aspire 13.2는 로그 및 텔레메트리 관리 대화상자를 추가했습니다:

모든 텔레메트리 삭제 (재현 시도 전에 유용)
선택한 텔레메트리를 표준 OTLP/JSON 형식의 ZIP 파일로 내보내기
나중에 해당 ZIP을 아무 Aspire 대시보드에 다시 가져오기

마지막 부분이 핵심 기능입니다. 버그를 재현하고, 텔레메트리를 내보내고, 작업 항목에 첨부하면, 팀원이 자신의 대시보드에 가져와서 당신이 본 것과 정확히 같은 것을 볼 수 있습니다. “네 컴퓨터에서 재현해볼 수 있어?“는 이제 그만.

개별 트레이스, 스팬, 로그에도 컨텍스트 메뉴에 “Export JSON” 옵션이 있습니다. 특정 트레이스를 공유해야 할 때? 우클릭, JSON 복사, PR 설명에 붙여넣기. 끝.

텔레메트리 API가 진짜 게임 체인저

가장 기대되는 부분입니다. 대시보드가 이제 /api/telemetry 하위에 HTTP API를 제공하여 텔레메트리 데이터를 프로그래밍 방식으로 조회할 수 있습니다. 사용 가능한 엔드포인트:

GET /api/telemetry/resources — 텔레메트리가 있는 리소스 목록
GET /api/telemetry/spans — 필터를 사용한 스팬 조회
GET /api/telemetry/logs — 필터를 사용한 로그 조회
GET /api/telemetry/traces — 트레이스 목록
GET /api/telemetry/traces/{traceId} — 특정 트레이스의 모든 스팬 가져오기

모든 것이 OTLP JSON 형식으로 반환됩니다. 이것은 새로운 CLI 명령 aspire agent mcp와 aspire otel을 구동하지만, 진정한 의미는 더 큽니다: 이제 앱의 텔레메트리를 직접 조회하는 도구, 스크립트, AI 에이전트 통합을 구축할 수 있습니다.

디버깅 중에 실제 분산 트레이스를 볼 수 있는 AI 코딩 에이전트를 상상해보세요. 더 이상 가설이 아닙니다 — 이 API가 가능하게 하는 것입니다.

GenAI 텔레메트리가 실용적으로

Semantic Kernel이나 Microsoft.Extensions.AI로 AI 기반 앱을 구축하고 있다면, 개선된 GenAI 텔레메트리 시각화 도구를 좋아할 겁니다. Aspire 13.2 추가 기능:

AI 도구 설명을 Markdown으로 렌더링
트레이스 페이지에 전용 GenAI 버튼으로 빠른 접근
잘린 또는 비표준 GenAI JSON에 대한 더 나은 에러 처리
도구 정의 간 클릭-하이라이트 내비게이션

블로그 포스트에서 VS Code Copilot chat, Copilot CLI, OpenCode 모두 OTEL_EXPORTER_OTLP_ENDPOINT 설정을 지원한다고 언급합니다. Aspire 대시보드를 가리키면 텔레메트리를 통해 AI 에이전트가 실시간으로 생각하는 모습을 말 그대로 볼 수 있습니다. 다른 곳에서는 찾을 수 없는 디버깅 경험입니다.

마무리

Aspire 13.2는 대시보드를 “괜찮은 디버깅 UI"에서 “프로그래밍 가능한 관찰성 플랫폼"으로 변화시킵니다. 내보내기/가져오기 워크플로만으로도 분산 디버깅에서 실질적인 시간을 절약하고, 텔레메트리 API는 AI 지원 진단의 문을 엽니다.

이미 Aspire를 사용 중이라면 업그레이드하세요. 아직이라면 — aspire.dev를 확인해볼 좋은 이유입니다.

Aspire | The .NET Blog

프라이빗 Endpoints, VNet, NSG — Aspire가 이제 네트워크를 관리합니다

구성 요소

AppHost에서 설명하기

실제 애플리케이션에 중요한 이유

결론

Aspire 13.3: Kubernetes 지원, 브라우저 로그 및 Aspireify 스킬

Aspireify: 에이전트 지원 온보딩

퍼스트클래스 Kubernetes 및 AKS 배포

대시보드의 브라우저 로그

구조화된 명령 결과

결론

Aspire 13.2: Bun 지원, 더 나은 컨테이너, 그리고 적은 디버깅 마찰

Bun이 이제 일급 시민입니다

Yarn이 더 안정적으로

컨테이너 개선

디버깅 개선

Global Azure Spain 2026

어젠다 하이라이트

티켓

Azure Tour 2026

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

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

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

격리 모드와 결합하기

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

마무리

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

문제는 현실입니다

에이전트 인프라로서의 Aspire

볼링 범퍼 비유

시작하기

마무리

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

해결책: --isolated

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

내부 작동 원리

언제 사용할 것인가

마무리

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

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

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

모든 문서 나열

주제 검색

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

AI 에이전트 관점

실제 시나리오

문서는 항상 최신 상태

마무리

Aspire 13.2 대시보드에 텔레메트리 API가 추가됐다 — 그리고 모든 것이 바뀐다

텔레메트리를 제대로 내보내기

텔레메트리 API가 진짜 게임 체인저

GenAI 텔레메트리가 실용적으로

마무리

해결책: `--isolated`