Ai platform demo

AI · App Platform Demo

특정 고객의 임원이 직접 클릭하며 가치를 이해할 수 있는 단일 HTML SaaS 데모를 만든다. 디자인과 runtime은 재사용하고, 고객별 서사·메뉴·데이터·Agent만 교체한다.

산출물

• 인라인 CSS/JS를 포함한 단일 .html 파일 1개
• GitHub Primer Dark Dimmed 계열 soft-dark 디자인의 고정 8-route SPA
• 고객 주요사업 5개 route와 GitHub Ecosystem, Microsoft Foundry, App Platform(ACA/AKS) 3개 route
• 버튼·슬라이더·목록·채팅이 실제 동작하고 KPI·차트·활동 피드가 변하는 데모
• 모든 화면에 ● 시연 데이터 표시

고객별 작업 파일과 스크린샷은 저장소와 최종 출력 폴더 밖의 세션 작업 디렉터리에 둔다. 재사용 가능한 Puppeteer·Chromium만 외부 공용 캐시에 유지하고, 최종 출력 위치에는 HTML 하나만 남긴다.

입력

입력	처리
CUSTOMER	고객 회사명
INDUSTRY	주요 사업·산업
AUDIENCE	임원 직무와 관심사
DEMO_FOCUS	균형형, AI 중심, App Platform·CI/CD 중심
EMPHASIS	강조할 Microsoft·GitHub 서비스
LANG	지정 언어를 준수. 미지정 시 한국어, 공식 제품명·일반 약어는 원문 유지
APP_NAME	기본 <CUSTOMER> IQ
ROUTE_SCOPE	고정 8개 전체 노출. 시연 동선만 목적에 맞는 4~6개 장면으로 압축

고객과 산업은 필수다. 결과를 크게 바꾸는 모호성만 한 번에 하나씩 확인한다. CI, PI처럼 의미가 여러 개인 직무 약어는 실제 역할을 확인한다.

표현 계약

• 첫 화면에서 고객 결과 한 문장, KPI 4개, primary action 1개를 보여준다.
• 각 route는 임원의 질문 하나에 답하고 행동 하나를 강조한다.
• 메뉴는 항상 8개를 노출한다. 기본 시연 동선은 이 중 4~6개 핵심 장면으로 끝낸다.
• CEO·COO·CFO·CIO 등 청중별 story.guidedJourneys, 보이는 route path, 다음 장면 CTA를 제공한다. 역할 탭을 선택하면 해당 persona의 첫 의사결정 화면으로 즉시 이동한다.
• 업무 예외 → Foundry 의사결정 → GitHub 변경 → ACA/AKS 운영을 같은 scenarioTrace.id로 연결한다.
• 제품 catalog로 시작하지 않는다. 고객 가치 → 업무 흐름 → 담당 서비스 순으로 설명한다.
• 고객의 현재 도입이 확인되지 않은 서비스는 목표 아키텍처 또는 시연 가정으로 표시한다.
• 임원이 보는 메뉴·제목·버튼·상태·표·Agent 문구는 LANG를 따른다. 한국어일 때만 자연스러운 한국어를 우선하고 공식 제품명·일반 약어는 원문을 유지한다.

플랫폼 역할은 고객 과제에 필요한 화면에서만 구체적으로 연결한다.

• Microsoft Foundry + Microsoft Agent Framework: 모델·Agent·도구·오케스트레이션·평가
• GitHub Copilot + GitHub Platform: 계획·코드·PR·GitHub Actions·GitHub Advanced Security
• AKS + Azure Container Apps: 애플리케이션·Agent workload의 배포·확장·운영
• Microsoft Entra·Purview·Defender·Azure AI Content Safety·GitHub AI Controls: 통제와 거버넌스

세 플랫폼 route는 기능 시연만으로 끝내지 않는다. 각각 sales 계약으로 임원 질문, 가능해지는 사업 성과, 사업 KPI 2개, 차별화 기능, 통제 증거, 담당자·기간·성공 기준이 있는 구매 다음 단계를 제공한다. App Platform readiness는 진단 → 미해결 Gap → 개선 계획 → 예상 점수로 분리하며 진단만으로 점수를 올리지 않는다.

필수 워크플로

1. 고객 조사

• 먼저 web-search 스킬로 고객 사업, 규모, DX/AI/App Platform/DevOps 현황, 최근 이슈를 조사한다.
• 검색 backend와 원문 검증 방법은 web-search가 결정하며 이 스킬에서 별도 정책을 정의하지 않는다.
• 고객 요청마다 변동 사실을 다시 확인하고, 이전 Ledger와 Industry Pack은 검색 출발점으로만 사용한다.
• 결과를 web-search의 공통 Fact Ledger 계약과 schema에 맞춘 fact-ledger.json으로 저장한다. checkedAt과 서로 다른 canonical Fact source URL 2개 이상이 필요하다. 데모 매핑이 필요하면 Demo candidate만 확장 필드로 추가한다.
• 모든 고객 사실·KPI 범위·서사는 이 Ledger에 근거한다. 확인하지 못한 내용은 사실처럼 표현하지 않는다.

2. 스토리라인

storyline.md에 다음만 먼저 확정한다.

1. 고객 과제와 목표 결과를 연결하는 서사 한 줄
2. 청중 직무별 핵심 메시지와 담당 route
3. 청중별 4~6개 guidedJourneys, route bridge, focus별 climax, 고정 8개 story.routeScope
4. 업무 route → Foundry → GitHub → App Platform 공통 scenarioTrace

서사는 고정 인용문이나 범용 AI 메시지에서 시작하지 않는다. 조사로 확인한 고객 과제와 사업 언어에서 시작한다. AI 중심은 Agent 협업·평가·거버넌스, App Platform·CI/CD 중심은 계획→코드→배포→운영→학습의 폐루프를 climax로 둔다.

3. View Contract와 Customer Overlay

reference/screen-blueprints.md를 참고해 앞의 5개 route를 고객 주요사업에 매핑하고, 뒤의 3개 route를 GitHub Ecosystem·Microsoft Foundry·App Platform으로 구성한다. view-contract.md에는 8개 route별 질문·KPI·primary action·필수 DOM ID·시뮬레이터 결과·Agent 전환 조건과 세 플랫폼 route의 buyer next step을 기록한다.

reference/composable-spec.md에 따라 customer-overlay.json을 만든다. Overlay는 고객 meta·story·route·Agent만 소유하며 design을 정의하지 않는다. 디자인은 Golden Runtime이 고정 제공한다.

4. 빌드

1. 적합한 Industry Pack이 있으면 terminology·공식·Agent 역할의 출발점으로 사용한다.
2. Pack이 맞지 않으면 억지로 사용하지 않고 전체 Spec을 직접 작성한다.
3. scripts/compose_demo_spec.py로 Base + Pack + Overlay + Fact Ledger를 합쳐 demo-spec.json과 HTML을 생성한다.
4. 직접 작성한 Spec은 먼저 scripts/lint_spec.py로 검사한 뒤 scripts/render_demo.py로 렌더한다.
5. 기본 수정 surface는 HTML이 아니라 customer-overlay.json이다.
6. Golden Runtime으로 핵심 장면을 표현할 수 없을 때만 해당 route를 세션 작업 폴더에서 확장한다. 고객 전용 분기를 공용 runtime이나 Pack에 추가하지 않는다.

구체 명령과 파일 계약은 reference/authoring-cheatsheet.md, reference/composable-spec.md, reference/demo-spec.md를 따른다.

5. 검증

scripts/verify_demo.js와 reference/verification.md를 사용한다.

1. 노출된 모든 route를 한 browser/page 세션에서 전체 렌더한다.
2. 레이아웃·겹침·깨짐·LANG 위반을 화면별로 확인한다.
3. 콘솔/페이지 오류와 빠른 route 전환 오류가 0인지 확인한다.
4. 슬라이더, action button, 모든 클릭 가능한 행, Agent 전환, 채팅을 검증한다.
5. 청중 journey preset, 다음 장면 CTA, 공통 scenario trace를 검증한다.
6. App Platform 진단에서 점수가 유지되고 Gap이 노출된 뒤 개선 계획에서만 예상 점수가 변하는지 확인한다.
7. 결함을 일괄 수정하고 영향 route를 빠르게 확인한다.
8. 수정 후에는 완료 전에 전체 route와 핵심 interaction을 다시 검증한다.

캐시와 증분 검증 방법은 reference/full-optimized.md를 따르되 최종 전체 QA를 생략하지 않는다.

완료 조건

• 최종 산출물이 외부 빌드 없이 열리는 단일 HTML이다.
• 첫 화면에서 고객 결과·KPI·primary action이 즉시 보인다.
• 고객 주요사업 5개 + 플랫폼 서비스 3개의 고정 8개 route와 4~6개 핵심 시연 동선이 완성됐다.
• 청중별 guided journey와 다음 장면 CTA가 고객 업무 결과에서 세 플랫폼 서비스로 자연스럽게 이어진다.
• GitHub·Foundry·App Platform 화면에 사업 KPI·통제 증거·구매 다음 단계가 보인다.
• Purview·Azure AI Content Safety·Entra·Defender·GitHub AI Controls/Advanced Security 역할이 검증된다.
• 노출된 모든 route, 버튼, 슬라이더, 클릭 가능한 행, Agent 전환, 채팅이 동작한다.
• 콘솔/페이지 오류와 route 전환 시 null 접근·listener 누수가 없다.
• 고객 사실은 Fact Ledger와 연결되고 가정 수치는 시연 데이터로 표시된다.
• 디자인은 공용 Golden Runtime을 유지하고 고객 전용 내용이 runtime·Pack에 섞이지 않았다.
• 저장소와 최종 출력 폴더에는 결과 HTML 외 임시 파일이 남지 않는다.

참고

• Golden Runtime: reference/golden-runtime.md
• 고정 디자인: reference/fixed-design-dna.md
• 화면 매핑: reference/screen-blueprints.md
• Spec 합성: reference/composable-spec.md
• 직접 작성: reference/authoring-cheatsheet.md
• 검증: reference/verification.md
• 최적화: reference/full-optimized.md