AI Platform Demo

AI · App Platform Demo

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

산출물

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

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

입력

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

표현 계약

• 첫 화면에서 고객 결과 한 문장, KPI 3~5개, primary action 1개를 보여준다.
• 각 route는 임원의 질문 하나에 답하고 행동 하나를 강조한다.
• 메뉴는 목적에 필요한 58개만 노출하고 기본 시연 동선은 46개 핵심 장면으로 끝낸다.
• CEO·COO·CFO·CIO 등 청중별 story.guidedJourneys, 보이는 route path, 다음 장면 CTA를 제공한다. 역할 탭을 선택하면 해당 persona의 첫 의사결정 화면으로 즉시 이동한다.
• 업무 예외에서 시작해 선택한 플랫폼 화면 2개 이상을 같은 scenarioTrace.id로 연결한다.
• 제품 catalog로 시작하지 않는다. 고객 가치 → 업무 흐름 → 담당 서비스 순으로 설명한다.
• 고객의 현재 도입이 확인되지 않은 서비스는 목표 아키텍처 또는 시연 가정으로 표시한다.
• 임원이 보는 메뉴·제목·버튼·상태·표·Agent 문구는 LANG를 따른다. 한국어일 때만 자연스러운 한국어를 우선하고 공식 제품명·일반 약어는 원문을 유지한다.
• 한국어 데모는 protectedTerms를 제외한 설명용 영문 문자 비율 약 40%를 목표로 한다. 서비스명·기능명은 계산에서 중립 처리하고 반드시 영문으로 유지한다.
• Customer Overlay의 meta.languagePolicy.protectedTerms에 실제 사용하는 서비스·공식 기능명을 원문으로 기록한다. 예: GitHub Copilot, GitHub Actions, GitHub Advanced Security, Microsoft Foundry, Hosted Agents, Toolboxes, AKS, ACA, MCP.

플랫폼 역할은 고객 과제에 필요한 화면에서만 연결한다: Foundry·Agent Framework는 모델·Agent·평가, GitHub는 계획·코드·PR·Actions·Advanced Security, AKS·ACA는 배포·확장·운영, Entra·Purview·Defender· 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 Accepted Fact source URL 2개 이상이 필요하다. 데모 매핑은 Ledger를 확장하지 않고 Customer Overlay와 demo spec에 기록한다.
• 모든 고객 사실·KPI 범위·서사는 이 Ledger에 근거한다. 확인하지 못한 내용은 사실처럼 표현하지 않는다.

2. 스토리라인

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

1. 고객 과제와 목표 결과를 연결하는 서사 한 줄
2. 청중 직무별 핵심 메시지와 담당 route
3. 청중별 46개 guidedJourneys, route bridge, focus별 climax, 58개 story.routeScope
4. 업무 route에서 시작해 활성 플랫폼 2개 이상으로 이어지는 3~6단계 scenarioTrace

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

3. View Contract와 Customer Overlay

reference/screen-blueprints.md를 참고해 업무 archetype 35개와 GitHub Ecosystem·Microsoft Foundry·App Platform 중 23개를 선택한다. view-contract.md에는 선택한 route별 질문·KPI·primary action·필수 DOM ID·시뮬레이터 결과·Agent 전환 조건과 세 플랫폼 route의 buyer next step을 기록한다.

reference/composable-spec.md에 따라 customer-overlay.json을 만든다. Overlay는 고객 meta·story·route·Agent와 선택적 design.tokens.brand/accent를 소유한다. 나머지 디자인과 interaction engine은 Golden Runtime이 제공한다.

4. 빌드

1. 적합한 Industry Pack이 있으면 base 예제의 내부 ID를 유지한 채 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이다. 한국어 Overlay에는 meta.languagePolicy와 관련 protectedTerms를 포함한다.
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 위반을 화면별로 확인한다. 한국어 데모는 설명 문구의 language balance와 protectedTerms 영문 보존도 함께 lint한다.
3. 콘솔/페이지 오류와 빠른 route 전환 오류가 0인지 확인한다.
4. 모든 클릭 대상의 handler binding과 슬라이더·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이 즉시 보인다.
• 고객 업무 35개 + 플랫폼 서비스 23개의 58개 route와 46개 핵심 시연 동선이 완성됐다.
• 청중별 guided journey와 다음 장면 CTA가 고객 업무 결과에서 선택한 플랫폼 서비스로 자연스럽게 이어진다.
• 활성 GitHub·Foundry·App Platform 화면에 사업 KPI·통제 증거·구매 다음 단계가 보인다.
• Purview·Azure AI Content Safety·Entra·Defender·GitHub AI Controls/Advanced Security 역할이 검증된다.
• 노출된 모든 route의 클릭 handler가 연결되고 버튼·슬라이더·Agent 전환·채팅의 핵심 상태 변화가 동작한다.
• 콘솔/페이지 오류와 route 전환 시 null 접근·listener 누수가 없다.
• 고객 사실은 Fact Ledger와 연결되고 가정 수치는 시연 데이터로 표시된다.
• 한국어 설명은 한글 우선이며 서비스명·공식 기능명은 영문으로 유지되고 language balance lint를 통과한다.
• 디자인은 공용 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