7가지 플러그인(파트 3)은 각각 Power Platform의 한 단면을 다룹니다. 이 플러그인들을 함께 사용할 때 진정한 보상이 나타납니다. 이 마지막 포스트에서는 하나의 연결된 솔루션인 Contoso Field Services(장비 유지보수 기업)를 살펴보며, 실제로 구축하게 될 순서에 따라 각 플러그인이 어디에 배치되는지 보여줍니다.

읽는 법에 대한 참고 사항: CLI에서는 기술(skill)을 이름으로 호출하지 않습니다. 원하는 내용을 평이한 언어로 설명하면 에이전트가 사용자의 요청을 기술과 매칭합니다(파트 2에서 설명한 description 필드가 바로 그 용도입니다). 따라서 아래의 프롬프트(prompt)가 실제 입력값이며, 각 프롬프트 뒤에 명시된 **기술(skill)**은 에이전트가 작업을 수행하기 위해 로드하는 것입니다. 이 프롬프트들은 Copilot CLI와 Claude Code에서 동일하며, 파트 1~2에서 다룬 설정 명령(setup commands)만 두 도구 간에 다릅니다.

시나리오

Contoso는 산업 장비를 수리하기 위해 기술자를 파견합니다. 이들에게는 다음과 같은 기능이 필요합니다:

• 고객이 온라인으로 서비스 요청을 할 수 있어야 함,
• 들어온 요청이 자동화를 시작(할당, 알림)해야 함,
• 배차 담당자가 내부 앱에서 우선순위를 정하고 일정을 예약해야 함,
• 기술자가 현장에서 오프라인 상태로 휴대폰을 통해 작업을 수행해야 함,
• 관리자가 대시보드에서 운영 현황을 확인해야 함,
• 그리고 주변부에서 사용할 몇 가지 보조 앱 및 위젯이 필요함.

기저에는 하나의 Dataverse 데이터 모델이 있고, 그 위에 7개의 플러그인이 올라갑니다.

단계 0: 하나의 공유된 기반

모든 것은 동일한 Dataverse 테이블을 기반으로 하며 하나의 솔루션(solution) 안에 존재하므로, 거기서부터 시작합니다. Power Pages의 setup-datamodel 및 setup-solution 기술은 우리가 구축할 첫 번째 접점이므로 핵심 스키마(schema)를 정의하기에 좋은 지점입니다:

> Customer, Asset, ServiceRequest, WorkOrder, Technician 테이블과 이들 간의 관계를 포함하는 "ContosoFieldServices"라는 이름의 Dataverse 솔루션을 설정하세요.

기술: setup-solution, setup-datamodel (power-pages) → data-model-architect 에이전트로 위임

이름이 지정된 솔루션(named solution) 내에서 모델을 한 번 정의하면, 이후의 모든 앱이 동일한 테이블에 바인딩(bind)되어 함께 배포될 수 있습니다. 이 솔루션 이름을 잘 기억해 두세요. 아래의 모든 과정에 걸쳐 연결됩니다.

1단계: 고객 포털 — power-pages

대중을 위한 공개 관문입니다. 고객은 이곳에 접속하여 서비스 요청을 제출하고 추적합니다.

> 고객이 장비 서비스 요청을 제출하고 상태를 확인할 수 있는 Power Pages 코드 사이트를 생성하세요. React를 사용하세요. 양식을 ServiceRequest 테이블에 바인딩하고 로그인을 요구하세요.

기술 (Skills): create-site, 그 다음 Dataverse Web API를 바인딩하기 위한 integrate-webapi, ID 관리를 위한 setup-auth + create-webroles, 테이블 액세스를 확인하기 위한 audit-permissions.

Power Pages 플러그인에는 Playwright MCP가 포함되어 있으므로, 에이전트는 실행 중인 사이트를 열어 양식이 실제로 렌더링되고 제출되는지 확인한 후 해당 단계가 완료되었음을 호출합니다.

2단계: 접수 자동화 — power-automate

새로운 ServiceRequest 행이 그대로 방치되어서는 안 됩니다. 클라우드 흐름(cloud flow)이 이를 분류합니다: 기술자 배정, 우선순위 설정, 고객 통지.

> ServiceRequest가 생성될 때 트리거되는 클라우드 흐름을 생성하세요. 가장 가까운 사용 가능한 기술자(Technician)를 찾고, 작업 지시서(WorkOrder)를 생성하며, 고객에게 확인 이메일을 보내세요.

기술 (Skills): FlowAgent MCP 서버를 통한 create-flow / build-flow (power-automate) (az login 필요).

이것이 연결 조직(connective tissue)입니다: 포털이 행을 작성하면, 흐름이 이를 배정된 작업으로 전환합니다. 나중에 라우팅 로직을 수정해야 하는 경우, 플러그인의 debug-flow 및 정밀 편집(surgical-edit) 기술을 사용하여 전체 흐름을 다시 생성하지 않고도 해당 단계만 변경할 수 있습니다.

3단계: 배차 분류 — model-apps

배차 담당자(Dispatchers)는 이미 모델 기반 앱(model-driven app)에서 작업하고 있습니다. 그들에게 앱을 떠나지 않고도 들어오는 대기열을 확인하고 작업을 예약할 수 있도록, 그곳에 맞춤형 **생성형 페이지 (generative page)**를 제공하세요.

> WorkOrder 및 Technician 테이블에서 데이터를 읽어, 지도 위에 열려 있는 WorkOrder를 표시하고 예약 패널을 갖춘 생성형 페이지를 모델 기반 앱에 추가하세요.

Skill: genpage (model-apps) → genpage-planner, genpage-entity-builder, genpage-connector-builder, 그리고 genpage-page-builder 에이전트들에 의해 병렬로 계획 및 구축됩니다. pac ≥ 2.7.0 및 az가 필요합니다.

4단계: 빠른 자산 조회 도우미 — canvas-apps

모든 내부 요구사항이 전체 앱을 필요로 하는 것은 아닙니다. 배차 담당자(Dispatcher)와 백오피스 직원들은 자산의 서비스 이력을 빠르게 조회할 수 있는 방법을 원합니다. 작은 캔버스 앱(Canvas app)이 이를 수행하며, 이제 이는 수동으로 제작된 화면 대신 버전 관리되는 소스(.pa.yaml)로 제공됩니다.

> 자산을 검색하고 과거의 작업 지시서(WorkOrder)를 보여주는 검색창이 포함된 캔버스 앱을 구축하세요.

Skills: Canvas Authoring MCP 서버를 통한 generate-canvas-app + add-data-source (canvas-apps) ( .NET 10 SDK 필요)._

5단계: 현장 기술자용 앱 — mobile-app

기술자들은 현장에 있으며, 신호가 잡히지 않는 경우가 많습니다. 이들에게는 오프라인 (offline) 상태에서도 작동하며, 사진 촬영을 위한 카메라, 체크인을 위한 GPS 등 기기 기능을 사용할 수 있는 모바일 앱이 필요합니다.

> 기술자가 할당된 작업 지시서(WorkOrder)를 확인하고, 상태를 업데이트하며, 사진을 첨부할 수 있는 모바일 앱을 생성하세요. 반드시 오프라인에서 작동해야 하며, 온라인 상태가 되면 동기화되어야 합니다.

Skills: create-mobile-app, add-native (camera/GPS), 그리고 오프라인 스택인 setup-offline-profile, enable-tables-offline, assign-offline-profile (mobile-app). deploy / open-wrap-url을 통해 Power Apps Wrap으로 배포됩니다.

오프라인 프로필은 배차 담당자 앱이 기록하는 것과 동일한 작업 지시서(WorkOrder) 및 자산(Asset) 테이블을 기준으로 정의됩니다. 즉, 하나의 스키마(Schema)를 두 개의 매우 다른 클라이언트가 사용하는 구조입니다.

6단계: 운영 대시보드 — code-apps-preview

관리자들은 캔버스 화면보다는 프로코드(Pro-code) 앱으로서 처리량, SLA 위반, 기술자 부하 등을 보여주는 실제 웹 대시보드를 원합니다.

> 작업 지시서(WorkOrder) 볼륨, 평균 완료 시간(average time-to-close), 기술자 활용도를 보여주는 Power Apps 코드 앱 대시보드를 생성하세요. Dataverse 및 Office 365에 연결하세요.

Skills: create-code-app, add-dataverse, add-office365를 수행한 후 deploy (code-apps-preview). React + Vite 기반이며, pac를 통해 배포됩니다.

7단계: 시각화 위젯 — mcp-apps

Contoso라는 회사가 장비 고장 위험을 점수화하는 작은 내부 **MCP 도구 (MCP tool)**를 작성했다고 가정해 봅시다. 이 도구의 원시 출력값은 JSON입니다. 이를 대화형 위젯으로 감싸서, 해당 도구가 사용되는 어디에서든 실제 UI로 렌더링되도록 만듭니다.

> 고장 위험 도구의 출력을 심각도 색상이 포함된 순위 목록으로 렌더링하는 MCP App 위젯을 생성하세요.

기술: generate-mcp-app-ui (mcp-apps) — MCP Apps 프로토콜을 사용하는 독립형 HTML 위젯.

8단계: 패키징 및 배포 — power-pages를 활용한 ALM

일곱 가지 인터페이스, 하나의 솔루션. Power Pages 플러그인의 ALM 기술이 이를 하나로 묶어 개발(dev)에서 테스트(test), 운영(prod) 환경으로 이동시킵니다. plan-alm은 솔루션 분할 결정 트리(solution-splitting decision tree)까지 실행하는데, 이는 구성 요소가 이만큼 많아졌을 때 매우 유용합니다.

> dev, test, prod 환경 전반에 걸친 ContosoFieldServices 솔루션의 ALM 전략을 계획하고, 배포 파이프라인(deployment pipeline)을 설정한 후 솔루션을 내보내기(export) 하세요.

기술: plan-alm, setup-pipeline, ensure-pipelines-host, deploy-pipeline, export-solution (power-pages). 단계가 실패할 경우 diagnose-deployment를 사용하세요.

전체 그림

                         ┌─────────────────────────┐
   고객 ──▶ power-pages 포털 ──▶ 서비스 요청 (ServiceRequest) ─┐
                         └─────────────────────────┘   │
...

위의 모든 상자는 0단계에서 사용한 것과 동일한 Dataverse 기반이며, 서로 다른 클라이언트를 통해 보고 편집됩니다. 그리고 모든 상자는 도메인 전문 지식을 제공하는 플러그인과 함께, CLI 에이전트에게 평이한 언어로 설명함으로써 구축되었습니다.

다음 단계

• 실행하기 전에 읽어보세요. 기술을 호출하기 전에 해당 기술의 SKILL.md (파트 2)를 열어 플레이북(playbook)과 allowed-tools 범위를 확인하세요.
• 플러그인이 최신 상태를 유지할 수 있도록 자동 업데이트를 켜두세요 (설치 프로그램이 이를 수행합니다). 여러 플러그인이 활발하게 버전 관리되고 있습니다.
• 하나의 인터페이스부터 시작하세요. 일곱 가지가 모두 필요하지는 않습니다. 구축하려는 레이어에 맞는 플러그인을 선택하고, 솔루션이 성장함에 따라 다른 것들을 추가하세요.

이것이 바로 이번 시리즈의 내용입니다. 이러한 에이전트형 CLI (agentic CLIs)가 무엇인지, 어떻게 모든 Power Platform 플러그인을 내려받는지, 각 플러그인이 어떤 역할을 하는지 이해하는 방법, 그리고 이들이 어떻게 하나의 솔루션으로 결합되는지 — 이 모든 것을 Copilot CLI 또는 Claude Code를 통해 터미널에서 수행하는 방법을 다룹니다.

출처: microsoft/power-platform-skills · Get started with the Power Pages plugin