Platform Engineering | The .NET Blog

Agentic Platform Engineering으로 마이그레이션의 반복 작업 제거하기

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

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

Removing the Monkey Work of Migration with Agentic Platform Engineering — Git-Ape(git 에이전틱 플랫폼 엔지니어링 도구)가 실제 AWS Terraform 리포지토리를 Azure로 마이그레이션하는 과정을 보여주며, 줄 단위 변환이 아닌 배포 의도 추출에 초점을 맞춥니다.

입력: contoso-migration

소스는 AWS에서 Next.js 앱을 배포하는 실제 Terraform 프로젝트(contoso-migration)입니다 — 컴퓨팅에 EC2, 로드 밸런싱에 ALB, 아티팩트에 S3, 아이덴티티에 IAM 키. 비용: 월 ~$34. 목표는 Azure에서 동일한 인프라를 재현하는 것이 아닙니다. 배포가 실제로 무엇을 하려는지 파악하고 Azure 네이티브 서비스로 재구축하는 것입니다.

1단계: 검증 및 인증

Git-Ape는 무언가를 건드리기 전에 모든 필수 CLI 도구 — az, aws, gh, jq, git — 를 검증하고 활성 인증 세션을 확인하는 것으로 시작합니다. 부분 실행은 없습니다.

2단계: 의도 추출

에이전트는 GitHub API를 통해 전체 소스 리포지토리를 읽고 배포 의도를 추출합니다: 런타임(Node.js), 컴퓨팅 유형, 인그레스 패턴, 아티팩트 처리, 아이덴티티 모델, 네트워킹, 모니터링. 이것이 핵심 단계입니다 — Terraform 키워드가 아니라 배포가 무엇을 하는지의 시맨틱 모델을 구축합니다.

3단계: 서비스 매핑

AWS 서비스가 Azure 동등물로 매핑됩니다:

EC2 → App Service (Linux, Node 20 LTS)
ALB → App Service 내장 로드 밸런싱
IAM 역할/키 → Managed Identity
Terraform → Bicep + GitHub Actions

4단계: 비평 에이전트

출력을 생성하기 전에 비평 에이전트가 실행되어 두 가지 차단 문제를 발견합니다:

시작 시 빌드 안티패턴 — 원래 Terraform이 EC2 시작 시 npm install && npm run build를 실행하고 있었습니다. 수정: CI에서 빌드하고 준비된 아티팩트를 배포합니다.
불필요한 Blob Storage — S3가 적절한 CI/CD로 제거할 수 있는 아티팩트 스테이징에 사용되었습니다. 비평 에이전트가 이를 완전히 제거했습니다.

5단계: 생성된 출력

결과는 원래 200줄 이상의 Terraform 대신 약 80줄의 Bicep입니다. 에이전트는 infra/main.bicep 및 .github/workflows/deploy.yml이 포함된 새 GitHub 리포지토리를 생성하고 모든 AWS 전용 파일을 제거했습니다.

보안 태세 비교

마이그레이션은 또한 의미 있는 보안 개선을 가져왔습니다:

AWS 원본	Azure 출력
HTTP만	HTTPS만, TLS 1.2
SSH가 0.0.0.0/0에 열려 있음	SSH 노출 없음
IAM 액세스 키	OIDC + Managed Identity
모니터링 없음	Application Insights

비용: 원래 $34/월 대비 ~$13/월.

구문 변환기와의 차이점

비평 에이전트 단계가 이것을 기계적 번역과 구별시키는 것입니다. AWS에서는 작동하지만 Azure에서는 잘못될 패턴을 발견하고 복제 대신 수정했습니다. 출력은 “Azure 구문의 AWS"가 아닙니다. 동일한 목표를 더 깔끔하게 달성하는 Azure 네이티브 배포입니다.

완전한 에이전트 추적 및 생성된 파일은 전체 가이드를 참조하세요.

에이전틱 플랫폼 엔지니어링이 현실이 되고 있다 — 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와 정책이 어떤 모습이어야 하는지 생각해 보세요.

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