Files
jychoi4 24b624301c 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

48 lines
4.8 KiB
Markdown

# 범용 설치 패키지 제작 및 배포 계획
**현재 기준:** [MSIX 우선 제작기](../code-design/12-msix-first-builder.md)와 [일정 v3](10-development-schedule.md). 이전 EXE/EG-BIM 중심 계획은 후속 적용 자료이며 첫 MSIX 출시의 선행 조건이 아니다.
기준일: 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 배포는 검토 대상이다.
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 계약을 다룬다.
| 문서 | 내용 |
| --- | --- |
| [01 요구사항과 기존 프로그램 현황](01-requirements-and-current-state.md) | 확정 요구사항, 저장소 확인 결과, 설치 경로와 기존 업데이트 구조 |
| [02 설치기 전환](02-installer-migration.md) | InstallShield 대체, WiX와 Burn, 구버전 마이그레이션과 복구 |
| [03 버전별 패키지와 업로드](03-package-and-upload.md) | 버전 체계, 불변 패키지, 저장소, 검증과 공개 절차 |
| [04 사용자 그룹별 단계 배포](04-staged-rollout.md) | 4개 그룹, 대상 결정, 승인 기준, 배포 중지와 관측 |
| [05 Microsoft Store 배포](05-microsoft-store.md) | MSI·EXE 및 MSIX 경로 비교, 제출 조건, 자체 배포와의 관계 |
| [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. EXE 기존 설치 전환에서는 경로와 사용자 설정을 보존한다. MSIX 경로는 OS가 관리하며 앱 데이터 이전은 별도 검증한다.
4. 자체 그룹 배포를 사용하는 경우 대상 버전은 서버에서 인증된 사용자·장치와 정책으로 결정한다. 로컬 패키지 생성에 서버를 요구하지 않는다.
5. 배포 중지, 설치 중 실패 복구, 설치 완료 후 장애 복구를 구분한다.
6. 코드 서명과 SmartScreen 평판을 구분한다. Azure 서명도 경고 면제를 보장하지 않는다.
7. 첫 버전의 MSIX는 버전 증가 패키지와 App Installer로 업데이트한다. EXE/MSI의 전체 설치·MSP는 후속 범위로 유지한다. 적용 가능한 기준 버전과 설치 상태를 검증한 뒤 패치를 실행한다.
## 검토 범위
기존 코드와 `.ism`을 읽어 설치 및 업데이트 구조를 확인했다. 새 설치기 구현, 인증서 발급, 서명, Store 제출, 실제 설치·제거 시험은 수행하지 않았다. 특히 기존 `BaronSoftware.Update` NuGet 패키지는 호출부만 확인했으며 내부 구현을 검증한 상태가 아니다.
외부 서비스 가격과 Store 정책은 기준일에 확인한 공식 문서를 따른다. 계약·출시 시점에는 각 문서의 공식 링크에서 다시 확인한다.