aspire

aspire skill 개요

aspire skill로 할 수 있는 일

aspire skill은 여기저기 흩어진 문서를 짜깁기하지 않고도 Aspire 기반 분산 애플리케이션을 만들고, 실행하고, 디버그하고, 구성하고, 배포용 결과물을 준비하려는 사용자를 위한 스킬입니다. 핵심 목적이 “Aspire 이론을 배우기”가 아니라 “AppHost를 실제로 띄우고, 서비스를 올바르게 연결하고, 실패 원인을 확인하고, 배포용 아티팩트를 준비하기”일 때 특히 유용합니다.

어떤 사람이 aspire를 써야 하나

다음과 같은 독자에게 가장 잘 맞습니다:

• 멀티서비스 앱의 로컬 오케스트레이션 용도로 Aspire를 검토 중인 개발자
• 기존 API, 컨테이너, 실행 파일 주위에 AppHost를 추가하려는 팀
• aspire install, 초기 설정, 문제 해결, 배포 지향 publish 작업까지 AI 어시스턴트의 도움을 받고 싶은 사용자
• .NET AppHost와 Python, Node.js, Go, Java 또는 컨테이너 서비스가 섞인 폴리글랏 팀

이 aspire skill이 다른 점

이 aspire skill이 일반적인 프롬프트보다 강한 이유는, 작업 종류에 맞는 올바른 참조 경로로 에이전트를 안내하기 때문입니다:

• CLI 사용법과 설치 세부사항은 references/cli-reference.md
• AppHost와 런타임 개념은 references/architecture.md
• 대시보드와 관측성 워크플로는 references/dashboard.md
• 대상별 publish 가이드는 references/deployment.md
• MCP를 통한 통합 검색은 references/integrations-catalog.md

이 점이 중요한 이유는 Aspire에 고유한 사고모델이 있기 때문입니다. AppHost는 리소스와 의존성을 정의하고, 런타임과 대시보드는 이를 로컬에서 운영할 수 있게 도와줍니다.

aspire 설치 전 핵심 판단 포인트

서비스, 의존성, 엔드포인트, 로그, 트레이스, 대상 플랫폼용 publish 아티팩트를 하나의 코드 정의 지점에서 오케스트레이션하고 싶다면 Aspire를 선택하세요. 반대로 한 번의 명령으로 바로 프로덕션 배포까지 끝나길 기대한다면 적합하지 않습니다. 저장소에서도 분명히 하듯, Aspire는 매니페스트와 아티팩트를 publish하고 실제 배포는 이후 CI/CD나 대상 플랫폼이 담당합니다.

aspire skill 사용 방법

aspire skill 설치 맥락

aspire skill을 실용적으로 도입하려면 먼저 스킬을 추가한 뒤, 작업에 맞는 참조 파일만 컨텍스트로 사용하는 방식이 좋습니다:

1. 스킬 설치:
   npx skills add github/awesome-copilot --skill aspire
2. skills/aspire/SKILL.md 열기
3. 모든 파일을 읽기보다 현재 작업에 맞는 참조 파일만 로드하기

권장 읽기 순서:

• SKILL.md
• references/cli-reference.md
• references/architecture.md
• references/deployment.md
• references/troubleshooting.md

Aspire 자체 설치 방법

목표가 실제 Aspire 사용이라면, 이 스킬은 독립형 CLI 설치 흐름을 가리킵니다:

# Linux / macOS
curl -sSL https://aspire.dev/install.sh | bash

# Windows PowerShell
irm https://aspire.dev/install.ps1 | iex

aspire --version

이 점이 중요한 이유는 Aspire CLI가 단순히 dotnet의 부가 기능이 아니라 주요 인터페이스이기 때문입니다.

작업 프레이밍을 올바르게 시작하기

aspire skill은 요청에 다음과 같은 의도가 명확히 들어 있을 때 가장 잘 작동합니다:

• 새 Aspire 앱 만들기
• 기존 솔루션에 AppHost 추가하기
• Redis나 PostgreSQL 같은 의존성 연결하기
• 로컬 분산 앱 실행 및 디버깅하기
• Docker 또는 Kubernetes용 Aspire publish 결과물 만들기
• 시작, 헬스, 서비스 디스커버리 문제 해결하기

“help with Aspire” 같은 막연한 요청은 추측을 유도합니다. 반면 “내 API, Redis, Python worker를 위한 AppHost를 구성하고 Docker publish output까지 준비해줘”처럼 말하면, 에이전트가 적절한 참조를 사용할 만큼 충분한 형태가 갖춰집니다.

aspire skill이 필요로 하는 입력

품질 높은 출력을 원한다면 다음 정보를 제공하세요:

• 현재 저장소 구조
• 대상 언어와 런타임
• 이미 AppHost가 있는지 여부
• Docker 또는 Podman 사용 가능 여부 같은 로컬 런타임 제약
• 대상 publish 플랫폼: Docker, Kubernetes 또는 Azure 지향 출력
• 문제 해결 중이라면 관찰된 실패 증상

유용한 입력 예시:

I have a .NET API, a React frontend, and a Redis dependency. I want Aspire for local orchestration and Docker publish artifacts. I already use Docker Desktop. Show me the AppHost shape, CLI commands, and likely package choices.

거친 목표를 강한 aspire 프롬프트로 바꾸는 법

좋은 aspire 가이드 프롬프트는 보통 다섯 가지 요소를 포함합니다:

1. 현재 앱 구조
2. 원하는 리소스
3. 로컬 실행 기대사항
4. 배포 대상
5. 원하는 결과 형식

예시:

Use the aspire skill to propose an AppHost for:
- .NET API in src/Api
- Node frontend in src/Web
- PostgreSQL for local dev
Need:
- service startup order
- endpoint wiring
- environment variable strategy
- Aspire CLI commands
- publish path for Kubernetes
Return code snippets plus a short explanation of tradeoffs.

실제 사용 전에 먼저 읽어야 할 저장소 파일

aspire skill 도입을 검토 중이라면, 다음 파일들이 특히 중요합니다:

• 범위와 라우팅을 위한 SKILL.md
• 설치, aspire new, aspire run, aspire publish, 버전별 명령을 위한 references/cli-reference.md
• publish와 deploy의 핵심 경계를 설명하는 references/deployment.md
• 서비스가 모두 .NET이 아닐 때 필요한 references/polyglot-apis.md
• 어시스턴트 기반 점검과 문서 조회를 원할 때의 references/mcp-server.md
• 로컬 오케스트레이션이 실패할 때의 references/troubleshooting.md

이 구조는 실무적으로 유용합니다. 이 스킬은 참조 주도형이므로, 품질은 모든 파일을 읽는 데서가 아니라 맞는 파일을 정확히 불러오는 데서 결정됩니다.

실제로 aspire를 쓰는 흐름

일반적인 aspire 사용 순서는 다음과 같습니다:

1. AppHost를 만들거나 열기
2. 리소스와 참조 정의하기
3. aspire run으로 로컬 실행하기
4. 대시보드에서 리소스 상태, 로그, 엔드포인트, 트레이스 확인하기
5. 설정을 반복 조정하기
6. 배포 대상에 맞는 아티팩트 publish하기

이 워크플로가 곧바로 배포로 점프하는 것보다 나은 이유는, Aspire가 먼저 로컬 오케스트레이션과 관측성을 중심에 두도록 설계되어 있기 때문입니다.

올바른 방식으로 aspire for Deployment 사용하기

aspire for Deployment에서 가장 중요한 사실은 aspire publish가 배포 아티팩트를 생성한다는 점이지, 그것을 직접 배포해 주는 것은 아니라는 점입니다.

참조 문서의 예시:

aspire publish -p docker -o ./docker-output
aspire publish -p kubernetes -o ./k8s-output

판단 팁:

• 로컬에서 쓰는 동일한 AppHost 모델로부터 배포 아티팩트도 파생되길 원한다면 Aspire를 선택하세요
• 앱 정의와 프로덕션 롤아웃 관리까지 하나의 도구가 모두 해주길 기대한다면 적합하지 않습니다

MCP 경로를 써야 하는 경우

실행 중인 앱을 어시스턴트가 직접 점검하거나, 수동 검색 없이 통합 문서를 가져오게 하고 싶다면 aspire skill은 MCP와 함께 쓸 때 특히 유용합니다.

references/mcp-server.md에는 aspire mcp init가 나오며, 지원되는 AI 환경을 설정하고 .vscode/mcp.json과 AGENTS.md를 생성할 수 있습니다. 이는 “어시스턴트가 Aspire 개념을 안다”에서 “어시스턴트가 내 실제 리소스, 로그, 트레이스를 볼 수 있다”로 넘어가는 간극을 줄여주기 때문에 도입 판단에 중요합니다.

출력 품질을 눈에 띄게 높이는 실전 팁

• 워크로드가 .NET project, container, executable 중 무엇인지 명시하세요. Aspire는 이를 서로 다르게 모델링합니다.
• 로컬 런타임 가용성은 초반에 알려주세요. 폴리글랏 앱은 AppHost가 .NET이어도 대상 언어 런타임이 따로 설치되어 있어야 할 수 있습니다.
• 시작 순서와 의존성 연결을 명시적으로 요청하세요. AppHost의 가치가 가장 잘 드러나는 지점입니다.
• 배포가 최종 목표라면, 로컬 오케스트레이션 선택과 publish 대상 선택을 분리해서 설명해 달라고 요청하세요.
• 명령이 실패했다면 “안 돼요”라고만 하지 말고, 전체 명령과 대시보드/로그에서 관찰한 상태를 함께 제공하세요.

aspire skill FAQ

aspire skill은 초보자에게도 괜찮은가

네, 멀티서비스 앱에 대한 기본 이해가 있다면 충분히 유용합니다. aspire skill은 초보자가 가장 자주 막히는 지점을 줄여줍니다. 어떤 CLI 명령이 중요한지, AppHost가 무엇을 책임지는지, 대시보드 동작은 어디서 봐야 하는지, 그리고 왜 publish가 deploy와 같지 않은지를 더 빠르게 파악할 수 있습니다.

aspire skill의 범위는 어디까지인가

aspire skill은 로컬 오케스트레이션, AppHost 개념, 통합 검색, MCP 설정, 대시보드 워크플로, 문제 해결, publish 중심의 배포 준비를 다룹니다. 다만 플랫폼별 CI/CD, 클러스터 운영, 클라우드 보안 설계까지 전부 대체하는 도구는 아닙니다.

일반 프롬프트보다 aspire skill이 나은 점은 무엇인가

일반 프롬프트는 그럴듯하지만 틀린 설정 조언을 내놓을 수 있습니다. 다음이 필요할 때는 aspire skill이 더 낫습니다:

• 버전을 고려한 CLI 가이드
• publish와 deploy의 정확한 구분
• 폴리글랏 호스팅 패턴
• 대시보드 및 문제 해결 경로
• MCP 도구를 통한 통합 검색

aspire는 .NET 팀만을 위한 것인가

아닙니다. 참조 문서에서 폴리글랏 워크로드를 명시적으로 다룹니다. AppHost 자체는 .NET 기반이지만, 오케스트레이션되는 서비스는 다른 언어의 컨테이너나 실행 파일일 수 있습니다. 즉, Aspire는 순수 .NET 솔루션뿐 아니라 혼합 스택에도 잘 맞습니다.

언제 aspire를 쓰지 말아야 하나

다음에 해당하면 Aspire를 건너뛰는 편이 좋습니다:

• 단일 프로세스 앱만 필요할 때
• 팀에 이미 잘 맞는 로컬 오케스트레이션 표준이 있을 때
• 생성된 아티팩트보다 직접적인 프로덕션 배포 관리가 필요할 때
• 환경상 필요한 로컬 런타임이나 컨테이너 도구를 지원할 수 없을 때

aspire 설치에 Docker가 꼭 필요한가

항상 그런 것은 아니지만, 실전의 많은 Aspire 워크플로는 컨테이너 지원의 이점을 크게 봅니다. 아키텍처 참조 문서에서도 컨테이너는 Docker나 Podman 같은 로컬 런타임으로 실행될 수 있고, 실행 파일은 네이티브 프로세스로 실행된다고 설명합니다. 실제 필요 조건은 오케스트레이션하려는 리소스에 따라 달라집니다.

aspire skill 개선 방법

aspire skill에 구체적인 아키텍처 입력 주기

aspire skill 결과를 가장 빨리 개선하는 방법은 추상적인 예시를 요청하는 대신 실제 토폴로지를 제공하는 것입니다:

• 서비스 이름
• 포트 또는 엔드포인트 기대사항
• 의존성 그래프
• 로컬 런타임 제약
• 대상 publish 플랫폼

이렇게 해야 AppHost 제안이 더 정확해지고, 엔드포인트 연결이 깔끔해지며, 일반적인 플레이스홀더도 줄어듭니다.

배포 가능한 단위로 출력 요청하기

“Aspire setup 만들어줘” 대신 다음처럼 요청하세요:

• AppHost 코드
• 패키지 및 템플릿 명령
• 로컬 실행 단계
• 대시보드 검증 단계
• 대상 플랫폼용 publish 명령

이 구조는 Aspire의 실제 사용 방식과 맞아떨어지고, 결과를 검증하기도 더 쉽습니다.

references 폴더를 의도적으로 활용하기

품질을 높이려면 어떤 소스를 기준으로 답할지 에이전트에 명시하세요:

• “publish 선택지는 references/deployment.md를 사용해”
• “Node와 Python 호스팅 옵션은 references/polyglot-apis.md를 사용해”
• “실패한 시작 문제는 references/troubleshooting.md를 기준으로 진단해”

이렇게 해야 아키텍처, 런타임 동작, 배포가 뒤섞인 혼합 답변을 피할 수 있습니다.

흔한 실패 패턴: 로컬 오케스트레이션과 프로덕션 배포를 혼동함

도입 과정에서 가장 흔한 실수 중 하나는 Aspire 자체가 프로덕션 배포까지 한다고 가정하는 것입니다. 첫 답변이 그 방향으로 흐르면 바로 수정하세요. 먼저 publish 아티팩트를 요청하고, 그다음 별도의 CI/CD 인계 계획을 요청해야 합니다. 그래야 aspire 가이드가 실용적이고 정확한 상태를 유지합니다.

흔한 실패 패턴: 의존성과 헬스 가정이 빠짐

서비스가 잘못된 순서로 시작되거나 디스커버리에 실패한다면, 에이전트에게 다음을 명시적으로 모델링하라고 요청하세요:

• 리소스 간 참조
• 대기/헬스 동작
• 의존성으로부터 파생되는 환경 변수
• 외부 엔드포인트 노출 필요 여부

막연한 aspire 사용 요청이 자주 기대 이하의 결과를 내는 지점이 바로 여기입니다.

관찰 가능한 증거를 공유해 문제 해결 품질 높이기

aspire skill로 문제를 디버그하고 싶다면 다음을 제공하세요:

• 사용한 aspire run 명령
• 각 리소스의 대시보드 상태
• 실패한 리소스의 로그
• 실패가 시작 단계인지, 연결성인지, publish 관련인지 여부

방대한 코드 덤프보다 관찰 가능한 증거가 더 중요합니다.

대상 제약을 주어 aspire for Deployment 출력 개선하기

aspire for Deployment를 쓸 때는 플랫폼이 무엇을 기대하는지 명확히 말하세요:

• Docker Compose 아티팩트
• Kubernetes 매니페스트
• Helm 친화적 출력
• 환경별 구성 경계
• replica 또는 ingress 기대사항

배포 참조 문서가 보여주듯 publish 출력은 대상별로 달라지므로, 요청도 그에 맞게 구체적이어야 합니다.

처음 답변 후 다시 시작하지 말고 반복 개선하기

강한 2차 프롬프트는 보통 다음과 같습니다:

Revise the Aspire plan using these constraints:
- frontend must stay outside Aspire
- API and worker should run under AppHost
- use PostgreSQL container locally
- produce Kubernetes publish output
- explain what must still be handled by CI/CD

이런 식의 반복은 새롭고 막연한 aspire guide를 다시 요청하는 것보다 훨씬 더 적합도를 높여줍니다.