networkSetup/docs/code-design/12-msix-first-builder.md

# MSIX 우선 제작기 — 첫 버전 설계와 화면

결정일: 2026-10-19. 사용자의 “우선 MSIX를 만들어주는 프로그램을 개발” 요청에 따른 현재 기준이다. [11번 설계](11-generic-exe-msix-architecture.md)의 범용 구조를 유지하되 두 형식 동시 완성 요구를 **MSIX 먼저, EXE는 후속**으로 변경한다. Rust/Tauri 앱과 실제 패키징 엔진은 아직 구현하지 않았다.

## 첫 제품의 범위

2026-10-26 명칭·파일 형식 결정: 정식 프로그램 명칭은 **Installer Studio**, 프로젝트 파일은 **`.isproj` (JSON v2)**만 지원한다. 아래 작업용 이름은 최초 시안의 기록이다. [파일 형식 규칙](13-isproj-project-format.md)이 파일명·열기·저장에 관한 이전 예시에 우선하며 기존 JSON 호환은 제공하지 않는다.

첫 제품은 Windows 앱의 배포 파일과 메타데이터를 입력받아 직접 배포 가능한 `.msix`를 만드는 **범용 MSIX 제작기**다. 디자인의 `MSIX Studio`는 작업용 이름이다. EG-BIM에 종속되지 않으며 Store 계정이나 자체 배포 서버 구축 없이 패키지를 만들 수 있어야 한다.

| 1차 필수 | 완료 조건 |
| --- | --- |
| 제품별 프로젝트 | `.isproj` (JSON v2) 전용 열기/저장, 기존 JSON 미지원, 앱 이름·게시자·버전·파일·실행 항목·자산 설정 |
| 입력과 manifest | 파일 포함/제외·경로 충돌·필수 자산·아키텍처·최소 OS·의존성·허용 선언 검증 |
| MSIX 생성 | Windows SDK MakeAppx, 결과 내용/identity 확인, 원본 무변경 |
| 서명 | 개발/운영/미서명 상태 구별, Publisher와 인증서 Subject 검증, 서명 후 최종 해시 |
| 작업/내보내기 | 취소·실패·재시도, 불변 결과·로그·보고서·도구 버전 보존 |
| 직접 배포 업데이트 | 선택적으로 `.appinstaller` 생성, HTTPS 경로·버전·업데이트 정책 검사와 VM 시험 |
| GUI와 CLI | 같은 검증/빌드 계약, 제품별 파일·패키지·서명·업데이트 화면 |
| 검증 | 두 독립 가상 제품의 MSIX 설치·실행·상위 버전 업데이트·제거·데이터 보존 증빙 |

최초 범위는 단일 앱 실행 항목, 한 대상당 단일 아키텍처의 `.msix`다. 지원 OS/CPU의 정확한 조합은 MS0에서 고정한다. 시안의 x64/ARM64와 Windows 버전은 선택 예시이며 지원 인증 결과가 아니다. 자산 파일·스키마·런타임 의존성은 실제 SDK 및 VM에서 검증한다.

후속 범위는 EXE/MSI/MSP/Burn, HTML 설치 마법사/사용자 정의 BA, 설치 과정 핸들러, EG-BIM legacy 전환, 자체 인증/그룹 배포 서버, Store 제출용 프로필·계정 연결·등록, MSIX bundle, 기존 설치기 캡처/자동 변환이다. 기존 작업은 삭제하지 않고 이월한다. **MSIX 제작기 v1 완료에 EXE 생성이나 두 형식 동시 회귀를 요구하지 않는다.**

## 구조와 생성 계약

```mermaid
flowchart LR
    UI[Tauri 제작 화면] --> E[Rust 공통 엔진]
    CLI[CLI] --> E
    E --> V[프로젝트·파일·manifest 검사]
    V --> B[MsixBackend / MakeAppx]
    B --> S[서명·패키지 검증]
    S --> R[불변 MSIX·보고서·선택 App Installer]
```

`PackageBackend` 추상화는 유지하되 첫 구현은 `MsixBackend`만 제공한다. WixBackend 구현·WiX 설치·MSI GUID 발급은 첫 제품의 의존성이 아니다. v2 모델에서 `formats.exe`는 생략 가능하며 MSIX-only 프로젝트에 EXE 설정을 요구하지 않는다. 기존 EXE/v1 프로젝트는 지원 불가 사유와 후속 가져오기 안내를 표시하고 조용히 변환하지 않는다. [MSIX-only 예제](examples/msix.package-project.json)는 미확정 설계 입력이다.

공통 입력 스냅샷 → manifest/자산/의존성 검사 → `MakeAppx pack` → 실제 파일 내용/identity 추출 → 서명/검증 → 최종 해시·불변 저장 순서다. MakeAppx의 검증을 끄지 않는다. `.msixupload` 생성은 MakeAppx의 기본 산출물이라고 표시하지 않는다. [Microsoft MakeAppx 문서](https://learn.microsoft.com/en-us/windows/msix/package/create-app-package-with-makeappx-tool)

GUI/CLI는 `validate`, `plan release --target <id>`, `build --plan-id <id>`, `job status`, `export` 계약을 공유한다. v1은 `distribution=direct`, `delivery=package|appinstaller`만 지원한다. EXE·Store·bundle 요청은 `UnsupportedTarget`으로 차단한다. 다중 MSIX 대상은 직렬 실행하고 부분 실패를 전체 성공으로 표시하지 않는다.

서명은 OS 인증서 저장소 또는 사전 설정한 서명 공급자 프로필을 참조한다. 일반 배포 시 신뢰·Publisher 일치를 확인한다. 개발 인증서 신뢰 설정은 별도 시험 환경에서 수행하며 제작기가 사용자 PC에 인증서를 몰래 설치하지 않는다. 미서명 개발 결과의 보존은 가능하되 직접 설치/배포 준비 상태는 부여하지 않는다.

상태는 `Draft → Planned → Running → Built → ArtifactVerified → Finalized`이며 실패·취소·중단을 구분한다. 서명/해시 검사 성공과 VM 설치 시험 성공은 별도다. `DeploymentReady`는 해당 아티팩트 해시의 실제 증빙이 있어야 한다. 시안의 성공 표시·가상 파일 목록은 어떤 구현 작업의 완료 증빙도 아니다.

## 업데이트와 설치 경계

제작기는 상위 버전 전체 MSIX와 필요 시 `.appinstaller`를 만든다. MSIX는 블록 정보를 이용하는 Windows 차등 업데이트 경로를 활용하며 별도 MSP나 자체 차분 파일을 만들지 않는다. 전체 파일을 먼저 내려받는 자체 다운로드 코드에 전송 절감이 자동 생긴다고 가정하지 않는다. [Microsoft 차등 업데이트](https://learn.microsoft.com/en-us/windows/msix/desktop/managing-your-msix-deployment-update)

업데이트 설정은 사용 여부, 안내 파일 URI, 버전별 불변 MSIX URI, 실행 시 확인 간격, 사용자 안내, 필요 시 실행 전 업데이트 요구를 명시한다. Windows/스키마 지원 범위를 검사한다. 직접 설치만 선택하면 자동 업데이트가 연결된 것으로 표시하지 않는다. 패키지를 버전별 새 URL로 게시하고, App Installer 안내 파일은 명시적 갱신·이력 보존 정책을 사용한다. 업로드 자체는 첫 제품 외부의 수동 작업이다. [Store 밖 자동 업데이트](https://learn.microsoft.com/en-us/windows/msix/app-installer/auto-update-and-repair--overview)

설치 위치는 Windows 관리로 표시하고 임의 설치 폴더 입력을 제공하지 않는다. 사용자 데이터 폴더 선택, 개인정보 동의 수집·기록·기능 제한은 대상 앱 첫 실행 등 앱 자체의 책임이다. 패키지에 HTML을 넣었다고 설치 중 실행되거나 동의가 기록되는 것으로 간주하지 않는다. 공통 HTML 초기 설정 런타임은 후속 별도 설계다.

App Installer의 제한된 XML 외형 커스터마이징과 Store 표시 정보는 HTML 설치 페이지 편집과 다르다. 첫 버전은 표준 표시 메타데이터·앱 자산까지만 제공하며 XML UX 커스터마이징은 후속 검증 범위다. [App Installer UX](https://learn.microsoft.com/en-us/windows/msix/app-installer/how-to-create-custom-app-installer-ux)

## 제작기 디자인

[상호작용 시안](../../output/msix-builder-concept.html), [브라우저 미리보기](../../output/msix-builder-preview.html). 시안은 두 레이아웃을 비교하며 제품 이름, 버전, 파일, Publisher, 서명, 업데이트 설정을 로컬 예제 상태에서 바꿀 수 있다. 실제 파일을 읽거나 MakeAppx/서명/설치를 실행하지 않는다.

| 화면 | 제작자가 설정하는 값 | 피드백 |
| --- | --- | --- |
| 앱 정보 | 표시명·설명·게시자 표시명·4부분 버전·아키텍처·아이콘 | 앱 표시 정보 미리보기; 실제 Windows 설치 화면과 구별 |
| 파일 구성 | 소스·포함/제외·패키지 상대 경로·실행 파일 | 포함 목록·충돌·누락·용량; 시안은 예제 파일 추가/제거 |
| 패키지 설정 | Identity Name·Publisher·최소 OS·앱 선언·의존성 | manifest 요약, 지원하지 않는 시스템 작업 안내 |
| 서명 | OS/공급자 프로필·개발/운영/미서명 | Publisher 불일치 오류, 대상 PC 신뢰와 개발 인증서 구분 |
| 업데이트 | 직접 배포·App Installer 사용·URI·확인 간격·안내 | 생성될 파일 목록; Store와 서버 구축은 후속 |
| 검증·빌드 | 검사·생성·취소·로그·결과 내보내기 | 단계별 상태, 오류 설정 이동, 서명/설치 시험의 독립 상태 |

**프로젝트 작업실형**은 왼쪽 고정 탐색, 중앙 편집, 오른쪽 미리보기/진단을 사용한다. 반복해서 제품 버전을 만드는 작업에 맞춘 기본 제안이다. **단계별 제작형**은 상단 여섯 단계와 이전/다음 흐름으로 처음 패키지를 만드는 사용자를 안내한다. 두 외형은 동일한 필드·검증·결과를 사용하며 제품 출시 시 두 화면을 모두 구현해야 한다는 요구가 아니다. MS5 착수 전에 하나를 선택한다.

상태 시나리오는 정상 설정, 잘못된 버전, 실행 파일 누락, Publisher/인증서 불일치, 잘못된 업데이트 URI, 미서명/개발 서명, 검사 후 설정 변경이다. 시안은 즉시 완료되는 모의 빌드를 사용한다. 실제 빌드는 도구 이벤트와 취소/중단 복구를 연결해야 한다. 출력 폴더 선택, 실파일 가져오기, 자산 크기 검사, 런타임 의존성 편집·검증, 서비스 서명은 시안에 구현되어 있지 않다.

## 완료 기준과 추적

첫 출시 범위는 [백로그](../backlog/README.md)의 1차 18개 항목과 [일정 v3](../plan/10-development-schedule.md)의 MS0~MS6다. EXE·Store·EG-BIM 업무 시험이 공통 MSIX 경로를 차단하지 않도록 의존성을 분리한다. SDK 누락, 잘못된 인증서/identity, 파일 누락, 디스크 부족, 취소/중단, 서버 연결 실패, 실행 중 업데이트, 버전 건너뛰기, 사용자 데이터 보존과 제거를 시험한다.

문서와 디자인 검증은 링크·JSON·의존성·브라우저 렌더링/상호작용까지다. 실제 배포 준비 판정은 구현 후 별도 Windows VM과 실제 서명으로 수행한다. [변경 기록](../changes/2026-10-19-msix-first.md)