docs: define MSIX-first packaging design and roadmap

Document package formats, release workflows, deployment planning and UI concepts. Closes #1
2026-10-27 16:30:00 +09:00
1 parent 54f0cfe360
commit 24b624301c
@@ -1,5 +1,9 @@
 # 요구사항과 기존 프로그램 현황

+현재 1차 범위는 [MSIX 우선 제작기](../code-design/12-msix-first-builder.md)다. EXE/MSP·EG-BIM 전환·자체 그룹 배포·Store 제출은 후속으로 유지하며 첫 출시 의존성에서 제외한다. 아래 기존 분석/확장 계약보다 이 범위와 [일정 v3](10-development-schedule.md)가 우선한다.
+
+제품의 공통 요구는 여러 제품의 EXE·MSIX 설치 패키지를 만드는 범용 제작기다. 아래 경로·GUID·수량·기존 업데이터 분석은 **EG-BIM 적용 사례**의 현황이며 공통 엔진 기본값이나 모든 제품의 선행 조건이 아니다. [범용 출력 설계](../code-design/11-generic-exe-msix-architecture.md) 참조.
+
 EG-BIM의 기존 설치 기반을 보존하면서 네트워크 배포를 추가한다. 설치 도구 변경과 앱 구조 변경을 한 번에 강제하지 않는 방향으로 검토한다.

 ## 확정 요구사항
@@ -1,5 +1,9 @@
 # InstallShield 대체와 기존 설치본 전환

+현재 1차 범위는 [MSIX 우선 제작기](../code-design/12-msix-first-builder.md)다. EXE/MSP·EG-BIM 전환·자체 그룹 배포·Store 제출은 후속으로 유지하며 첫 출시 의존성에서 제외한다. 아래 기존 분석/확장 계약보다 이 범위와 [일정 v3](10-development-schedule.md)가 우선한다.
+
+이 문서는 EG-BIM의 InstallShield→EXE/MSI 전환 적용 계획이다. 범용 제작기는 별도로 MSIX 출력도 필수 지원한다. 다른 제품의 패키지 생성에 EG-BIM 자료나 구버전 제거를 요구하지 않는다. [범용 출력 설계](../code-design/11-generic-exe-msix-architecture.md) 참조.
+
 권고안은 WiX로 MSI를 작성하고 Burn으로 필수 런타임과 MSI를 묶은 전체 설치 EXE를 만드는 것이다. 사용자에게는 기존처럼 EXE 설치 파일을 제공할 수 있다. WiX 채택과 도구 버전·이용 조건은 구현 시작 전에 확정한다.

 ## 대체 도구 검토
@@ -1,5 +1,9 @@
 # 버전별 패키지 관리와 업로드

+현재 1차 범위는 [MSIX 우선 제작기](../code-design/12-msix-first-builder.md)다. EXE/MSP·EG-BIM 전환·자체 그룹 배포·Store 제출은 후속으로 유지하며 첫 출시 의존성에서 제외한다. 아래 기존 분석/확장 계약보다 이 범위와 [일정 v3](10-development-schedule.md)가 우선한다.
+
+불변 아티팩트·해시·증빙 원칙은 EXE와 MSIX에 공통 적용한다. MSI/MSP 식별자와 기준 상태는 EXE 대상에만 적용하고 MSIX identity/업데이트 경로는 별도 기록한다. 아래 서버 업로드는 선택한 배포 연계의 책임이며 로컬 빌드의 필수 의존성이 아니다. [범용 출력 설계](../code-design/11-generic-exe-msix-architecture.md) 참조.
+
 패키지는 등록 후 변경하지 않고 배포 정책만 변경한다. 같은 릴리스를 개발자 테스트부터 일반 배포까지 사용하며, 수정이 필요하면 새 릴리스를 만든다.

 ## 버전 및 관리 정보
@@ -1,5 +1,9 @@
 # 사용자 그룹별 4단계 배포

+현재 1차 범위는 [MSIX 우선 제작기](../code-design/12-msix-first-builder.md)다. EXE/MSP·EG-BIM 전환·자체 그룹 배포·Store 제출은 후속으로 유지하며 첫 출시 의존성에서 제외한다. 아래 기존 분석/확장 계약보다 이 범위와 [일정 v3](10-development-schedule.md)가 우선한다.
+
+이 문서는 자체 서버와 EG-BIM 적용 트랙의 단계 배포 계약이다. 범용 EXE/MSIX 생성은 이 서버 없이 가능해야 한다. Store 공개·MSIX 업데이트는 각 배포 대상의 별도 정책을 사용하며 서버 승인 상태와 동일시하지 않는다. [범용 출력 설계](../code-design/11-generic-exe-msix-architecture.md) 참조.
+
 하나의 릴리스를 네 그룹에 순차적으로 공개한다. 초기에는 담당자가 관측 결과를 확인한 후 다음 단계를 승인하는 방식을 권고한다.

 ## 그룹 구성
@@ -1,6 +1,10 @@
 # Microsoft Store 배포 방식

-현재 EG-BIM에는 자체 업데이터와 PC 전체 설치 구조가 있으므로 MSI·EXE 등록 경로를 우선 검토한다. Store 배포에 MSIX가 반드시 필요한 것은 아니다.
+처음 등록하는 담당자는 [초보자용 Store 배포 매뉴얼](../manuals/microsoft-store/README.md)을 따른다. 2026-10-26 확인한 계정 가입 절차와 현재 제작기의 지원 범위를 별도로 설명한다. 이 문서의 출력 계약은 설계이며 현재 구현 완료 목록이 아니다.
+
+현재 1차 범위는 [MSIX 우선 제작기](../code-design/12-msix-first-builder.md)다. EXE/MSP·EG-BIM 전환·자체 그룹 배포·Store 제출은 후속으로 유지하며 첫 출시 의존성에서 제외한다. 아래 기존 분석/확장 계약보다 이 범위와 [일정 v3](10-development-schedule.md)가 우선한다.
+
+**Store는 범용 제작기의 출력 파일을 등록하는 배포 채널이다.** 제작기는 Store 등록 여부와 관계없이 EXE와 MSIX를 모두 생성한다. 제품마다 적합한 형식으로 등록하며 EG-BIM의 기존 구조만으로 범용 제품의 형식을 제한하지 않는다. [출력과 배포 대상 계약](../code-design/11-generic-exe-msix-architecture.md) 참조.

 ## 두 경로의 차이

@@ -11,7 +15,7 @@
 | 업데이트 | 자체 업데이터 담당 | Store 관리 |
 | 지정 테스터 배포 | 자체 서버에서 구현 | Package Flights 지원 |
 | 비율 배포 | 자체 서버에서 구현 | Store 점진 업데이트 지원 |
-| 현재 앱 적용 | 기존 경로와 설치 기능을 유지하는 방향 | 경로·레지스트리·CAD 연동·업데이터 검증 필요 |
+| 제품별 적합성 | 기존 설치 경로와 무인 실행 동작 검증 | 패키지 identity·선언 기능·앱 동작 검증; CAD 연동은 해당 제품만 추가 |

 [Microsoft 배포 방식 비교](https://learn.microsoft.com/en-us/windows/apps/distribute-through-store/how-to-distribute-your-win32-app-through-microsoft-store)

@@ -25,9 +29,9 @@

 Store용은 필요한 오프라인 런타임과 MSI를 포함한 단일 `FullSetup.exe` 등 제출 요건을 만족하는 파일로 만든다. 대용량으로 단일 파일의 생성·서명 제한을 넘으면 이 경로를 사용 가능하다고 간주하지 않는다. 자체 배포용 분할 CAB 폴더나 작은 `WebSetup.exe`가 그대로 Store 제출을 대신하는 것은 아니다. 현재 `.ism`의 웹 설치형 선행 조건은 그대로 이관하지 않고 실제 의존성을 정리한다. [공식 패키지 요구사항](https://learn.microsoft.com/en-us/windows/apps/publish/publish-your-app/msi/app-package-requirements), [출력 프로필과 용량 검사](../code-design/05-release-pipeline.md)

-## 자체 배포와 함께 운영
+## EXE 자체 배포와 함께 운영

-자체 사이트와 Store에서 같은 검증 완료 전체 설치 파일을 사용할 수 있다. Store에는 일반 사용자에게 공개할 릴리스만 등록한다. 최초 설치 후의 업데이트는 자체 서버가 그룹별로 제어한다.
+자체 사이트와 Store에서 같은 검증 완료 전체 설치 파일을 사용할 수 있다. EG-BIM 적용 정책에서는 Store에 일반 사용자에게 공개할 릴리스만 등록한다. 다른 제품의 공개 정책은 해당 프로젝트에서 정한다. 최초 설치 후의 업데이트는 자체 서버가 그룹별로 제어한다.

 Store MSI·EXE 등록은 자체 서버의 4단계 배포 정책을 대신하지 않는다. 자체 서버의 배포 중지와 Store의 새 사용자 설치 중지는 별도 조치다. 두 경로의 공개 상태와 설치 패키지 버전을 함께 기록해야 한다.

@@ -35,16 +39,29 @@ Store 등록·심사 시점과 자체 배포 시점을 조정하고, Store의

 Store의 신규 설치용 등록 파일은 항상 전체 MSI·EXE로 유지한다. MSP를 신규 설치 파일 대신 제출하지 않는다. 설치 이후 자체 업데이터는 [버전별 패치 정책](08-version-patching.md)에 따라 호환되는 MSP를 적용할 수 있으며, 해당 버전의 전체 설치본과 패치 적용 결과가 같은 관리 상태가 되는지 검증한다.

-## MSIX로 전환할 경우
+## 제작한 MSIX를 Store에 제출할 경우

 Package Flights에 개발자·1차·2차 테스트 그룹을 구성하고 정식 제출을 일반 사용자 단계에 연결할 수 있다. Microsoft 계정으로 테스터를 등록하고 Flight도 인증 절차를 거친다. 초기 앱 제출 게시 후 Flight를 구성하는 흐름을 고려한다. [Package Flights](https://learn.microsoft.com/en-us/windows/apps/publish/package-flights)

 Store 점진 배포는 기존 사용자의 업데이트에 대한 비율 제어다. 최초 설치에도 같은 비율 제한이 적용된다고 가정하지 않는다. 중지는 이미 업데이트된 앱을 이전 버전으로 되돌리지 않으므로 수정 릴리스를 준비해야 한다. [점진 배포](https://learn.microsoft.com/en-us/windows/apps/publish/gradual-package-rollout)

-MSIX 전환 시에는 고정 설치 경로, 설치 위치 쓰기, 외부 CAD·플러그인·COM 연동, 사용자 설정 이동, 런타임을 검증한다. 현재 구조만으로 불가능하다고 판정한 것은 아니다. [MSIX 준비 사항](https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-prepare)
+기존 제품을 MSIX로 배포하려면 설치 위치 쓰기, 외부 연동, 데이터 이전, 런타임을 제품별로 검증한다. EG-BIM의 CAD·플러그인·COM 적합성은 별도 검토다. 범용 MSIX 출력 기능을 이 제품의 전환 성공에 종속시키지 않는다. [MSIX 준비 사항](https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-prepare)

 ## SmartScreen과 설치 경로

 Microsoft 공식 안내는 Store를 통한 MSI·EXE 설치 과정에는 SmartScreen 경고가 없고 UAC는 나타날 수 있다고 구분한다. 이는 Microsoft가 해당 EXE를 재서명한다는 의미가 아니다. Store에서 제공하는 MSIX 패키지 서명 처리와 다르다.

 같은 EXE를 자체 웹사이트에서 내려받으면 일반 다운로드의 SmartScreen 평판 판단을 받는다. Store 등록만으로 자체 배포 URL까지 경고 면제가 되지는 않는다. Store 설치 후 자체 업데이터가 내려받는 파일도 별도의 서명·검증이 필요하며 Store 설치 경로의 효과를 그대로 가정하지 않는다. [코드 서명 및 배포 경로 비교](https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/code-signing-options)
+
+## 등록 전 제작기의 산출물
+
+| 출력 대상 | 생성/검증 | 등록 단계 |
+| --- | --- | --- |
+| 직접 배포 EXE | 단일/분할/네트워크 구성과 자체 서명 | 자체 배포; Store 불필요 |
+| Store EXE | 완전 오프라인 단일 파일, 서명, 무인 설치 인자와 제출 검사 보고서 | 고정 HTTPS URL과 등록 자료를 별도로 제출 |
+| 직접 배포 MSIX | manifest·MakeAppx 패키지·신뢰 가능한 서명; 선택적으로 App Installer | 직접 설치/기업 배포; Store 불필요 |
+| Store MSIX | Store identity를 적용한 `.msix`, 제출 검사 보고서 | Partner Center 업로드, 심사 후 Store 배포 서명 |
+
+MSIX 자체 생성은 1차 필수다. Store 제출용 내보내기 계약과 등록은 후속 범위다. 실제 계정 설정·등록·심사·공개 운영은 BL-44/45의 선택 작업이다. Store 제출 파일은 직접 설치용 서명본과 별도 아티팩트로 관리한다. [MSIX 업로드 지원 형식](https://learn.microsoft.com/en-us/windows/apps/publish/publish-your-app/msix/upload-app-packages)
+
+설치 경로와 UI는 배포 채널이 아니라 형식의 제약을 따른다. EXE는 제품 프로젝트가 정한 경로/기본값과 무인 인자를 사용한다. MSIX는 Windows가 경로를 관리하므로 제작기에 임의 설치 폴더나 Burn 마법사 편집을 제공하지 않는다. 앱 데이터 경로는 패키지 설치 위치와 분리한다. [MSIX 파일 배치](https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes)
@@ -1,5 +1,9 @@
 # 코드 서명 서비스와 SmartScreen

+현재 1차 범위는 [MSIX 우선 제작기](../code-design/12-msix-first-builder.md)다. EXE/MSP·EG-BIM 전환·자체 그룹 배포·Store 제출은 후속으로 유지하며 첫 출시 의존성에서 제외한다. 아래 기존 분석/확장 계약보다 이 범위와 [일정 v3](10-development-schedule.md)가 우선한다.
+
+EXE 내부 PE·MSI·MSP·Burn의 서명 순서와 MSIX 패키지 서명을 구분한다. 직접 배포 MSIX는 manifest Publisher와 인증서 Subject 일치 및 대상 PC의 신뢰를 검사한다. Store MSIX 제출 파일과 Store가 최종 서명한 배포 파일의 상태·해시는 별도이며, 제출용 미서명 파일을 직접 배포 준비 완료로 표시하지 않는다. [범용 출력 설계](../code-design/11-generic-exe-msix-architecture.md) 참조.
+
 WiX는 설치 패키지 생성 도구다. 회사 명의의 코드 서명 인증서 또는 서명 서비스는 별도로 준비해야 한다. WiX 빌드에서 서명 도구를 호출해 자동화할 수 있다.

 ## 역할과 서비스 선택
@@ -1,7 +1,13 @@
 # 구현 순서와 검증 계획

+현재 1차 범위는 [MSIX 우선 제작기](../code-design/12-msix-first-builder.md)다. EXE/MSP·EG-BIM 전환·자체 그룹 배포·Store 제출은 후속으로 유지하며 첫 출시 의존성에서 제외한다. 아래 기존 분석/확장 계약보다 이 범위와 [일정 v3](10-development-schedule.md)가 우선한다.
+
+현재 제품 완료 기준에는 **EXE와 MSIX 생성·검증**이 모두 포함된다. 아래 legacy 전환·자체 서버·4단계 배포는 EG-BIM 적용·연계 트랙이다. 범용 제작기는 두 독립 가상 제품에서 두 형식의 설치/업데이트/제거를 검증하며 EG-BIM 전환·Store 심사를 공통 생성 차단 조건으로 두지 않는다. 통합 순서는 [일정 v2](10-development-schedule.md)와 BL-46~53을 포함한 백로그를 따른다. [범용 출력 설계](../code-design/11-generic-exe-msix-architecture.md) 참조.
+
 첫 검증 목표는 기존 InstallShield 설치본을 새 설치본으로 전환하면서 사용자 설정과 CAD 연동을 보존하는 것이다. 이 경로를 검증한 뒤 서버의 단계 배포를 연결한다.

+영역별 구현 항목은 아래 목록을 유지한다. 2026-10-19 기준 통합 실행 순서와 인력·일정은 [개발 일정과 마일스톤](10-development-schedule.md), 개별 작업의 선행 조건과 완료 기준은 [구현 백로그](../backlog/README.md)를 따른다.
+
 ## 구현 전 결정할 항목

 | 항목 | 현재 상태 | 필요한 결정·확인 |
@@ -1,5 +1,9 @@
 # 버전별 패치와 복구

+현재 1차 범위는 [MSIX 우선 제작기](../code-design/12-msix-first-builder.md)다. EXE/MSP·EG-BIM 전환·자체 그룹 배포·Store 제출은 후속으로 유지하며 첫 출시 의존성에서 제외한다. 아래 기존 분석/확장 계약보다 이 범위와 [일정 v3](10-development-schedule.md)가 우선한다.
+
+이 문서의 MSP·MSI 기준 상태·Burn 적용 경로는 **EXE/MSI 제품 전용**이다. 범용 제작기의 MSIX 출력은 버전 증가 패키지로 업데이트하며 MSP를 적용하지 않는다. EXE↔MSIX 전환은 별도 데이터 이전·공존 검증이 필요한 작업이다. [범용 출력 설계](../code-design/11-generic-exe-msix-architecture.md) 참조.
+
 버전별 패치는 필수 요구사항이다. 현재 설치된 버전과 상태를 확인해 변경분만 적용할 수 있어야 하며, 신규 설치·최초 설치기 전환·패치 비호환 상태를 위한 전체 설치 패키지도 함께 제공한다.

 ## 권장 구현 방식
@@ -0,0 +1,41 @@
+# 계획 검토 결과
+
+현재 1차 범위는 [MSIX 우선 제작기](../code-design/12-msix-first-builder.md)다. EXE/MSP·EG-BIM 전환·자체 그룹 배포·Store 제출은 후속으로 유지하며 첫 출시 의존성에서 제외한다. 아래 기존 분석/확장 계약보다 이 범위와 [일정 v3](10-development-schedule.md)가 우선한다.
+
+범위 정정: 초기 검토의 EG-BIM 중심 가정과 MSIX 후순위 분류를 수정했다. [범용 출력 설계](../code-design/11-generic-exe-msix-architecture.md)와 [변경 기록](../changes/2026-10-19-general-package-builder.md)이 현재 기준이다. 기존 위험 분석은 해당 EXE/EG-BIM 적용 범위에서 유효하다.
+
+초기 검토일: 2026-10-19, Asia/Seoul. 초기 검토 대상은 `docs/plan/01~08`, `docs/code-design/01~09`, 프로젝트 JSON 예제와 설치 화면 시안이다. 이번 검토는 문서의 범위·의존성·완료 기준을 대조한 것이다. 기존 EG-BIM 소스나 실제 출시 설치 파일을 다시 조사하거나 Windows 설치 시험을 실행한 결과는 아니다. 외부 서비스 가격·가입 자격·Store 정책도 초기 검토에서는 재확인하지 않았다. 이후 범용 범위 정정에서는 MakeAppx·MSIX 서명/버전·Store 제출 공식 문서를 확인하고 11번 설계에 근거를 연결했다. 서비스 가격·계약 자격은 재검토 범위가 아니다.
+
+## 판단
+
+범용 EXE·MSIX 제작을 중심으로 형식별 업데이트와 사용자 데이터 보존·불변 아티팩트를 유지한다. 먼저 두 형식의 작은 빌드/설치 실험과 공통 모델을 검증한다. EG-BIM 적용에는 실제 구버전 설치본 확보와 전환·패치·설치 UI 실험을 추가한다.
+
+현재 저장소에는 계획·설계·시안이 있으며 실행 가능한 Rust/Tauri 제작기, WiX 패키지, 업데이터 연동, 서버 구현은 없다. 설계에 적혀 있는 기능을 구현 완료로 간주하지 않는다. 아래 백로그의 구현 항목은 모두 미착수로 시작한다.
+
+## 주요 발견과 조치
+
+| ID | 중요도 | 근거와 발견 | 영향 및 권고 조치 | 연결 백로그 |
+| --- | --- | --- | --- | --- |
+| R01 | 높음 | [운영 구현 순서](07-implementation-and-validation.md)는 전환 보존을 첫 목표로 두지만 [코드 구현 순서](../code-design/08-validation-and-roadmap.md)는 실제 EG-BIM 전환을 UI 뒤에 배치한다. | 순서가 다른 두 목록은 제품 전체의 일정을 제공하지 못한다. 실제 구버전 제거 영향 실험을 초반에 하고, 본 전환 구현을 패치·GUI 완성보다 앞에 둔다. | BL-01, BL-07, BL-22 |
+| R02 | 높음 | [설치 UI 설계](../code-design/09-install-flow-and-ui.md)는 Rust/Burn 연결과 WebView2 없는 PC의 시작 경로를 미검증으로 명시한다. | 자유로운 페이지 편집을 구현한 뒤 실행 백엔드가 불가능하다고 판명될 수 있다. 최소 BA 연결 실험을 초기에 실시하고 실패 시 대안·유지보수 비용을 기록한다. 기본 테마만으로 자유 페이지 요구를 완료 처리하지 않는다. | BL-08, BL-31, BL-32 |
+| R03 | 높음 | [전체 릴리스](../code-design/05-release-pipeline.md)와 [패치 설계](../code-design/06-patch-pipeline.md)는 같은 ProductCode의 전체 대체 경로와 Burn/MSP 유지보수를 미검증으로 남긴다. | MSP 생성 성공만으로 배포할 수 없다. 실제 source state별 전체 대체 경로와 repair·제거·다음 업데이트를 패치 완료의 필수 조건으로 묶는다. | BL-04, BL-25~28 |
+| R04 | 높음 | [프로젝트 예제](../code-design/examples/egbim.package-project.json)의 제조사·서명 프로필은 비어 있고 런타임·레지스트리·전환 검증 플래그는 미확정이다. | 실제 payload와 출시본 목록이 없으면 일정과 설치 결과를 검증할 수 없다. 확인 자료를 별도 관리하고 초안 프로젝트의 정식 릴리스 확정을 차단한다. | BL-01~03, BL-10 |
+| R05 | 높음 | [생성기 상태](../code-design/05-release-pipeline.md)의 `Finalized/DeploymentReady`와 [서버 상태](03-package-and-upload.md)의 `Uploaded/Verified/Ready`가 각각 존재한다. | 서로 다른 검증 범위를 같은 성공으로 해석할 위험이 있다. 상태 간 매핑, 증빙 발급 주체, 누락·만료·철회 처리를 하나의 내보내기/수신 계약으로 정의한다. | BL-20, BL-34, BL-35 |
+| R06 | 높음 | [기존 업데이트 현황](01-requirements-and-current-state.md)은 NuGet 호출부만 확인했고, 사용자 채널과 장치 단위 배포 그룹의 대응도 미정이다. | 기존 라이브러리 재사용을 전제로 일정 단축을 계산하지 않는다. 실행·권한·종료 코드·재부팅·서명 검증 지원을 조사하고 부족한 부분의 구현 경계를 확정한다. | BL-05, BL-23, BL-24, BL-36~39 |
+| R07 | 중간 | [배포 승인 기준](04-staged-rollout.md)의 관찰 기간·성공률·표본 수는 예시이고 승인 담당자는 미정이다. | 날짜 도달을 승격 승인으로 사용할 수 없다. 분모·취소·미응답·재부팅 대기 처리와 중대 장애 기준을 정하고 실제 테스터 확보를 출시 의존성으로 둔다. | BL-06, BL-38, BL-42, BL-43 |
+| R08 | 중간 | [서명](06-code-signing-and-smartscreen.md), [Store](05-microsoft-store.md)는 계약·제3자 파일·용량·외부 정책에 의존한다. | 서명 준비는 초반에 시작하되 외부 처리 기간을 개발 완료로 보장하지 않는다. Store는 별도 가능성 판단 후 일정에 추가한다. 단일 파일 출력 불가를 전체 설치 기능 실패와 구분한다. | BL-03, BL-18, BL-19, BL-44, BL-45 |
+| R09 | 중간 | [시안](../../output/egbim-installer-preview.html)은 설치 사용자의 화면이며 [제작기 화면 목록](../code-design/07-ui-and-commands.md)을 구현한 것이 아니다. | 제작기와 최종 Setup 화면을 별도 항목으로 추적한다. 시안의 성공 상태와 진행률은 실제 측정 결과가 아니며 native 화면·접근성·실패 상태 시험이 남아 있다. | BL-29~33 |
+| R10 | 중간 | [보존 정책](03-package-and-upload.md)은 지원 기준·패치·복구·Store URL 보존을 요구하지만 기간과 삭제 절차는 미정이다. | 오래된 원본을 정리하면 repair와 후속 패치가 깨질 수 있다. 참조 추적, 보존 만료, 백업 복구 시험을 운영 인수 조건으로 만든다. | BL-04, BL-20, BL-40, BL-43 |
+| R11 | 높음 | 기존 설계가 EG-BIM 전용으로 읽히고 MSIX를 후속 선택으로 제외했다. | 범용 제작기·두 형식 필수·Store 별도 배포로 정정. 공통/형식별 모델·두 백엔드·검증·일정 v2 반영. | BL-46~53 |
+
+## 범위 정리
+
+이전 v2 범위 정정에서는 범용 제작기 완료 범위를 **EXE·MSIX 생성**으로 두었다. 현재 v3는 MSIX 먼저이며 아래 EXE·서버 항목은 후속이다. 장기 계약은 형식별 identity/서명/업데이트, Rust CLI/Tauri 제작 화면, EXE 과정/UI 편집과 MSP, 공통 검증·내보내기다. EG-BIM 실제 전환·기존 업데이터·자체 서버의 4단계 배포는 계획에 유지하되 별도 적용 트랙으로 판정한다. 이 트랙의 외부 자료 부족이 다른 제품의 로컬 패키지 생성을 막지 않는다.
+
+Store 제출은 검토 범위이며 정식 출시의 공통 차단 조건으로 두지 않는다. 자동 승격, 독자 바이너리 차분 엔진, 모든 과거 버전 조합, 다중 기준 단일 MSP, MSIX 다중 아키텍처 bundle, ISM 자동 가져오기, 복잡한 운영 대시보드는 이번 기준 일정에 포함하지 않는다. 이 항목을 추가하면 범위와 일정을 다시 산정한다.
+
+## 실행 계획
+
+[구현 백로그](../backlog/README.md)는 위 발견을 53개 작업으로 구체화한다. [개발 일정과 마일스톤](10-development-schedule.md)은 **AI 지원 없이 단독 개발**하는 기준이며, 제작기·업데이터·서버 작업을 한 사람의 용량 안에서 순차 배치한다. 기존 문서의 단계 목록은 영역별 설계 설명으로 유지하고, 통합 실행 순서와 통과 조건은 이 일정 문서를 기준으로 추적한다.
+
+외부 승인·테스터 모집·서명 계약의 실제 담당자, 지원 버전 목록, 주당 확보 가능한 시간은 아직 확정되지 않았다. 이 문서는 해당 결정을 대신 승인하지 않는다.
@@ -0,0 +1,56 @@
+# 단독 개발 일정과 마일스톤 — MSIX 우선
+
+기준선 v3: 2026-10-19, Asia/Seoul. 사용자의 “우선 MSIX를 만들어주는 프로그램” 요청에 따른 재배치다. **개발자 1명, AI 지원 없음**을 유지한다. [설계](../code-design/12-msix-first-builder.md), [백로그](../backlog/README.md), [변경 기록](../changes/2026-10-19-msix-first.md)을 함께 관리한다.
+
+## 범위와 추정
+
+첫 버전은 범용 MSIX 프로젝트·파일/manifest·MakeAppx·서명·불변 결과·직접 배포/App Installer·GUI/CLI·Windows VM 검증이다. EXE/MSI/MSP·HTML 설치 마법사·사용자 정의 BA·EG-BIM 전환·자체 인증/그룹 서버·Store 제출·bundle은 후속이다. 기존 53개 작업 중 18개를 1차로 배치하고 35개를 이월한다. 후속 작업을 완료 처리하거나 삭제하지 않는다.
+
+현재 잠정 예산은 **24주 + 별도 완충 4주**다. 2026-10-26 시작 가정에서 MS6 목표는 **2027-04-09**, 완충 포함 계획 경계는 **2027-05-07**이다. 사용자가 확정한 출시일이나 실측 견적이 아니다. 기존 v2의 W38/2027-07-16 및 W52/2027-10-22 통합 계획은 이 기준선으로 대체한다. 후속 EXE·서버·Store의 새 날짜는 아직 배정하지 않는다.
+
+MSIX만 먼저 만들므로 기존 52주에서 단순히 8주를 떼어내는 계산을 하지 않는다. 공통 프로젝트/파일/작업/서명/저장소/GUI 기반을 MSIX 경로에서 먼저 구현하는 공수를 포함해 재배치한다. MS0에서 작은 앱의 실제 도구 실험 후 다시 산정한다.
+
+## 산정 조건
+
+| 항목 | 기준 |
+| --- | --- |
+| 인력 | 개발자 1명이 학습·설계·구현·자체 리뷰·VM/수동 시험·문서·릴리스를 수행. 별도 QA 없음. |
+| AI | AI 코드 생성·설계·리뷰·테스트·문서화의 시간 단축을 가정하지 않음. 일반 IDE/CI/자동 테스트는 사용. |
+| 용량 | 전담 주 40시간 중 계획 작업 30시간, 대응·환경 정비·작은 재작업 여유 10시간. 실제 가용 시간 미확정. |
+| 총 예산 | 24×30 = 약 720 계획 시간. 완충 4주는 별도이며 기능 작업을 숨겨 넣지 않음. |
+| 작업 순서 | 구현 WIP 1. 엔진·UI·QA가 같은 사람의 시간임을 반영하고 병렬로 계산하지 않음. |
+| 경험 | Windows 앱 개발 경험을 가정. Rust/Tauri/SDK 경험 부족분은 MS0에서 학습 기간 추가. |
+| 달력 | 월~금 구간. 야근/주말 제외. 공휴일·휴가·회사 휴무는 착수 시 반영해 완충/목표일 조정. |
+| 외부 의존성 | Windows VM·실제 서명 접근 확보. Store 계정·EG-BIM 자료·그룹 테스터는 1차 의존성이 아님. |
+| UI | 두 시안 중 한 가지를 제품 기본 화면으로 선택. 시안이 이미 존재해도 실제 UI/IPC 구현 완료로 계산하지 않음. |
+
+## 단계별 일정
+
+| 마일스톤 | 주차 / 기간 | 예산 | 백로그 | 결과와 통과 조건 |
+| --- | --- | --- | --- | --- |
+| MS0 범위·위험 실험 | W1~3 / 2026-10-26 ~ 2026-11-13 | 3주 | BL-46/02/03/06 | 작은 앱의 MSIX 생성·서명·설치·업데이트와 도구/지원 OS/CPU 조합 확정. 공통화·서명 지연·학습 공수 재산정. |
+| MS1 공통 엔진·CLI·VM | W4~7 / 2026-11-16 ~ 2026-12-11 | 4주 | BL-09/10/11/14/47/16/41 | MSIX-only v2 모델·입력 스냅샷·작업 수명·backend/CLI·VM 증빙. EXE 설정/도구 없이 동작. |
+| MS2 MSIX 생성 | W8~11 / 2026-12-14 ~ 2027-01-08 | 4주 | BL-48/49 | manifest·identity·자산·의존성 검증과 MakeAppx pack. 실제 결과 내용 검사, 누락/취소/디스크 부족 시험. |
+| MS3 서명·결과 보관 | W12~14 / 2027-01-11 ~ 2027-01-29 | 3주 | BL-50 | 개발/운영/미서명 구분, Publisher·신뢰·서명/해시 검사, 불변 결과·로그·증빙·내보내기. |
+| MS4 직접 배포 업데이트 | W15~17 / 2027-02-01 ~ 2027-02-19 | 3주 | BL-51 | App Installer 설정/URI·버전 검증, 실제 업데이트·중단/재시도·실행 중 앱·데이터 보존. |
+| MS5 제작기 UI | W18~21 / 2027-02-22 ~ 2027-03-19 | 4주 | BL-29/52 | 선택한 한 가지 레이아웃, 실파일/자산/의존성 편집, 서명·업데이트·진행/실패·접근성. CLI와 같은 결과. |
+| MS6 MSIX 제품 완료 | W22~24 / 2027-03-22 ~ 2027-04-09 | 3주 | BL-53 | 두 독립 제품의 실제 생성·서명·설치·실행·업데이트·제거, 필수 실패 시험·사용 가이드·증빙 완성. |
+| 완충 | W25~28 / 2027-04-12 ~ 2027-05-07 | 4주 | 지연된 1차 작업 | 기존 범위의 불확실성/외부 지연에만 사용. EXE·서버·Store 기능을 넣지 않음. |
+
+MS2는 패키지 생성 중간 결과이며 제품 완료가 아니다. MS3 서명/보관과 MS4 업데이트 증빙, MS5 GUI가 연결된 뒤 MS6 회귀를 통과해야 한다. 미서명 개발 파일 생성이나 HTML 모의 빌드 성공을 실제 설치 가능/출시 완료로 표시하지 않는다.
+
+## 실행 순서와 통과 조건
+
+- MS0: 두 독립 가상 제품 선정, 지원 OS/CPU·SDK 고정, Publisher/서명·App Installer 경로 실험. 서명 접근 신청은 즉시 시작하며 발급 대기를 구현 완료로 세지 않는다.
+- MS1: 프로젝트→파일 스냅샷→작업 엔진→backend 포트→CLI 순서로 연결. VM은 첫 실제 패키지부터 증빙을 수집하도록 준비한다. MSI GUID/레지스트리 컴파일은 구현하지 않는다.
+- MS2: 단순 앱부터 자산·실행 항목·런타임/의존성을 확장. 미지원 서비스/드라이버/임의 설치 동작은 계획 단계에서 차단한다.
+- MS3: 공통 Signer/ArtifactRepository를 MSIX 경로에서 구현. Publisher 불일치·신뢰 실패·타임스탬프 오류·중단/재시도·동일 releaseId 덮어쓰기 금지를 검사한다. 운영 서명 미확보 시 배포 준비 게이트는 통과 불가다.
+- MS4: 실제 HTTPS 시험 호스트로 버전 증가·건너뛰기·다운로드 중단·앱 사용 중 업데이트·데이터 보존을 검사한다. 이 호스트 구성은 시험 예산에 포함하며 자체 장치 인증/4단계 배포 서버 구현으로 확장하지 않는다.
+- MS5: 한 디자인으로 실제 파일·자산·의존성·서명 프로필·출력 폴더 편집과 작업 이벤트를 연결한다. 제작기 자체 배포/실행도 확인한다. 모의 시안의 즉시 완료 버튼은 실제 제품에 사용하지 않는다.
+- MS6: 모든 1차 작업의 증빙을 실제 아티팩트 해시에 연결하고 사용 가이드·서명 오류·업데이트/복구 절차를 완성한다. 필수 notRun 항목이 남으면 통과시키지 않는다.
+
+## 변경과 지연 관리
+
+매주 완료 ID·증빙·다음 한 작업·차단 원인·잔여 기간을 갱신한다. 1주 이상 지연 전망, 도구/지원 범위 변경, 추가 런타임 요구가 생기면 뒤 날짜와 완충을 함께 수정한다. 실제 계획 시간이 주 30시간보다 작으면 남은 작업 시간을 실제 주당 시간으로 나눠 재산정한다. 외부 서명 대기는 단순 비례 축소하지 않는다.
+
+MS0·MS2·MS4에서 공수를 다시 산정한다. 시안의 접근성/GUI·CLI 동등성, 실제 서명, 업데이트/제거 시험을 삭제해 날짜를 맞추지 않는다. EXE/HTML 설치 화면/Store 등 후속 요청을 1차에 넣으면 설계·백로그·일정을 함께 변경한다. 사용자 요청 없이 후속 개발 일정을 확정하지 않는다.
@@ -1,15 +1,19 @@
-# EG-BIM 네트워크 설치 및 배포 계획
+# 범용 설치 패키지 제작 및 배포 계획

-기준일: 2026-10-16, Asia/Seoul. 대상 프로그램: `D:\egbim\repo\14.1`.
+**현재 기준:** [MSIX 우선 제작기](../code-design/12-msix-first-builder.md)와 [일정 v3](10-development-schedule.md). 이전 EXE/EG-BIM 중심 계획은 후속 적용 자료이며 첫 MSIX 출시의 선행 조건이 아니다.

-EG-BIM의 기존 Windows 설치 구조를 유지하면서 InstallShield를 대체하고, 버전별 패키지 관리와 4단계 그룹 배포를 지원한다. Microsoft Store 배포와 코드 서명도 함께 준비한다.
+기준일: 2026-10-16, Asia/Seoul. EG-BIM 적용 사례 경로: `D:\egbim\repo\14.1`. 제품 범위는 2026-10-19 정정했다.
+
+제품은 **범용 Windows 설치 패키지 제작기**이며 현재 첫 버전은 MSIX 출력을 먼저 완성한다. EXE는 후속 단계다. EG-BIM의 InstallShield 전환과 4단계 그룹 배포는 적용·연계 트랙으로 유지한다. [형식과 배포 대상의 분리](../code-design/11-generic-exe-msix-architecture.md)를 전체 계획에 적용한다.

 사용자가 확정한 사항은 Windows 데스크톱 앱 배포, InstallShield 사용 중단, 버전별 패키지 관리와 패치 지원, 업로드 체계, 개발자 테스터부터 일반 사용자까지의 4단계 배포다. Microsoft Store 배포는 검토 대상이다.

-현재 권고안은 **WiX MSI + Burn 전체 설치 EXE + 자체 배포 서버 및 업데이터**다. Store에는 전체 설치 EXE를 등록하는 경로를 우선 검토한다. WiX 채택, Azure 서명 서비스 계약, 세부 운영 기준은 아직 확정되지 않았다.
+EXE 백엔드는 **WiX MSI + Burn**, MSIX 백엔드는 **Windows SDK MakeAppx**를 사용한다. 자체 배포 서버·업데이터는 별도 연계다. Store에는 제작기가 생성한 EXE 또는 MSIX를 제품 적합성에 따라 등록한다. WiX 채택, Azure 서명 서비스 계약, 세부 운영 기준은 아직 확정되지 않았다.

 ## 문서 목록

+실제 등록 절차는 [초보자를 위한 Microsoft Store 배포 매뉴얼](../manuals/microsoft-store/README.md)에서 확인한다.
+
 생성 프로그램의 구현 설계는 [Rust + Tauri 설계 문서](../code-design/README.md)에 별도로 정리한다. 파일·레지스트리 편집, 버전/GUID, 전체 릴리스·MSP 생성, 대용량 분할 출력과 화면/CLI 계약을 다룬다.

 | 문서 | 내용 |
@@ -22,16 +26,19 @@ EG-BIM의 기존 Windows 설치 구조를 유지하면서 InstallShield를 대
 | [06 코드 서명과 SmartScreen](06-code-signing-and-smartscreen.md) | 서명 대상과 순서, 서비스 비용, 게시자, SmartScreen 한계 |
 | [07 구현 순서와 검증 계획](07-implementation-and-validation.md) | 선행 결정, 구현 단계, 마이그레이션 및 배포 시험 |
 | [08 버전별 패치](08-version-patching.md) | 기준 버전별 패치 선택, MSP, 누적 패치, 실패 복구 및 전체 설치 전환 |
+| [09 계획 검토 결과](09-plan-review.md) | 문서 간 의존성·미확정 사항 검토와 백로그 연결 |
+| [10 개발 일정과 마일스톤](10-development-schedule.md) | AI 지원 없는 단독 개발 기준 일정, 단계별 통과 조건과 완충 |
+| [구현 백로그](../backlog/README.md) | 우선순위·선행 조건·완료 기준이 있는 1차 18개·후속 35개 작업 |

 ## 설계 원칙

 1. 테스트부터 일반 배포까지 같은 서명 완료 패키지를 사용한다.
 2. 파일 업로드와 사용자 공개를 별도 상태로 관리한다.
-3. 기존 설치 경로와 사용자 설정을 보존한다.
-4. 설치 대상 버전은 서버에서 인증된 사용자·장치와 정책으로 결정한다.
+3. EXE 기존 설치 전환에서는 경로와 사용자 설정을 보존한다. MSIX 경로는 OS가 관리하며 앱 데이터 이전은 별도 검증한다.
+4. 자체 그룹 배포를 사용하는 경우 대상 버전은 서버에서 인증된 사용자·장치와 정책으로 결정한다. 로컬 패키지 생성에 서버를 요구하지 않는다.
 5. 배포 중지, 설치 중 실패 복구, 설치 완료 후 장애 복구를 구분한다.
 6. 코드 서명과 SmartScreen 평판을 구분한다. Azure 서명도 경고 면제를 보장하지 않는다.
-7. 버전별 패치를 필수 지원하며, 전체 설치 파일도 함께 유지한다. 적용 가능한 기준 버전과 설치 상태를 검증한 뒤 패치를 실행한다.
+7. 첫 버전의 MSIX는 버전 증가 패키지와 App Installer로 업데이트한다. EXE/MSI의 전체 설치·MSP는 후속 범위로 유지한다. 적용 가능한 기준 버전과 설치 상태를 검증한 뒤 패치를 실행한다.

 ## 검토 범위