Windows 앱의 배포 방식을 어떻게 고를까 - MSI / MSIX / ClickOnce / xcopy / 자체 updater의 판단표
· 小村 豪 · Windows, 배포, MSI, MSIX, ClickOnce, xcopy, updater
Windows 앱의 배포 방식을 결정할 때, 무심코 「어느 것이 새로운가」, 「어느 것이 간단한가」로 이야기를 시작하기 쉽습니다.
다만 실무에서 정말 효과가 있는 축은 다른 쪽입니다.
- 사용자 단위로 넣고 싶은가, 머신 전체에 넣고 싶은가
- 갱신을 배포 기반에 맡기고 싶은가, 자체로 가지고 싶은가
- 서비스 / 드라이버 / shell extension / COM 등록 같은 OS 통합이 있는가
- 폐쇄망·오프라인·USB 배포에 견딜 필요가 있는가
- package identity가 필요한가, 아니면 맨 Win32로서 unrestricted로 동작시키고 싶은가
배포 방식의 선택은 인스톨러 형식의 취향이 아니라 OS에 어디까지 건드리는가와 갱신 책임을 누가 가지는가의 선택입니다.
1. 먼저 결론
꽤 거칠게, 하지만 실무에서 쓰기 쉽게 말하면 이렇습니다.
- 머신 전체에 넣거나, 서비스나 COM 등록, 전제물의 도입이 있다면, 우선 MSI를 기점으로 생각합니다
- Windows 10/11 전제이고, clean install / clean uninstall, 빈번한 갱신, package identity가 필요하다면 MSIX가 유력합니다
- .NET의 사내용 데스크톱 앱을 사용자 단위로 간단히 배포해 자동 갱신하고 싶다면 ClickOnce는 지금도 꽤 강합니다
- 두기만 해도 동작하는 도구, 폐쇄망, USB 배포, 관리자 권한 없이를 우선한다면 xcopy가 가장 솔직합니다
- 갱신 UX, 채널, 단계 배포, telemetry, 복구 전략까지 스스로 잡고 싶다면 자체 updater입니다
- 드라이버가 필요하다면 처음부터 MSIX 중심으로 생각하지 않는 편이 안전합니다
- Explorer의 in-process shell extension이 필요하다면 MSIX는 맞지 않습니다
요컨대 대체로 다음입니다.
- OS에의 등록이 짙다 → MSI 쪽
- package identity와 modern packaging을 취하고 싶다 → MSIX
- per-user의 간단 배포와 built-in 갱신이 필요 → ClickOnce
- 두기만 하면 되는 배포가 최우선 → xcopy
- 갱신 기반을 자사에서 설계·운영할 각오가 있다 → 자체 updater
2. 5가지는 같은 씨름판이 아니다
여기는 꽤 중요합니다.
MSI / MSIX / ClickOnce / xcopy는 주로 어떻게 넣을까의 이야기입니다.
한편으로 자체 updater는 주로 어떻게 갱신 책임을 가질까의 이야기입니다.
즉 실무에서는 2층으로 나누어 생각하는 편이 정리하기 쉽습니다.
| 층 | 주요 후보 | 결정할 것 |
|---|---|---|
| 최초 도입 | MSI / MSIX / ClickOnce / xcopy | 어디에 배치하는가, 무엇을 등록하는가, 권한, 언인스톨 |
| 계속 갱신 | MSIX App Installer / ClickOnce / 수동 교체 / 자체 updater | 갱신 확인, 배포원, 서명 검증, rollback, 채널, UI |
그래서 자체 updater는 먼저 고르는 것이 아니라, 기존의 배포 방식으로 부족한 갱신 요건이 있을 때 추가로 고르는 것이라고 생각하는 편이 흔들리지 않습니다.
3. 한 장으로 보는 판단표
우선은 가장 쓰기 쉬운 판단표를 둡니다.
| 상황 | 우선 고르는 것 | 이유 |
|---|---|---|
| 전체 사용자용이고, 서비스, COM 등록, machine-wide 설정이 있다 | MSI | Windows Installer의 씨름판에 솔직히 오르는 편이 사고가 적다 |
| Windows 10/11 전제이며 clean install / uninstall, 빈번한 갱신, package identity를 원한다 | MSIX | modern packaging과 update 모델에 치우치기 쉽다 |
| .NET의 사내 업무 앱을 per-user로 간단히 배포하고 싶다 | ClickOnce | built-in의 갱신 모델이 쓰기 쉽다 |
| 두기만 해도 동작하는 도구, 폐쇄망, USB, 관리자 권한 없이 | xcopy | install이라는 개념을 가능한 한 들이지 않는다 |
| 상용 제품에서 갱신 UX나 채널을 스스로 잡고 싶다 | 자체 updater | built-in 갱신보다 자유도가 높다 |
| 드라이버가 필요 | MSI나 전용 installer 쪽 | driver package는 별개 문제이며 MSIX는 부적합 |
| in-process shell extension이 필요 | MSI나 전용 installer 쪽 | shell extension은 MSIX와 궁합이 나쁘다 |
이 표에서 가장 중요한 것은 「갱신이 있다」만으로 자체 updater로 뛰지 않는 것입니다.
4. 관점별 비교
| 관점 | MSI | MSIX | ClickOnce | xcopy | 자체 updater |
|---|---|---|---|---|---|
| per-user 도입의 쉬움 | ○ | ○ | ◎ | ◎ | ○ |
| per-machine 도입의 쉬움 | ◎ | ○ | △ | × | ○ |
| built-in 갱신 | △ | ◎ | ◎ | × | ◎ |
| package identity | × | ◎ | × | × | × |
| 서비스와의 궁합 | ◎ | △ | × | × | ○ |
| 드라이버와의 궁합 | △ | × | × | × | ○ |
| shell extension과의 궁합 | ◎ | × | × | × | ○ |
| 폐쇄망·오프라인 배포 | ◎ | ○ | ○ | ◎ | ◎ |
| 구현·운영 비용 | ○ | ○ | ◎ | ◎ | × |
| 갱신 UX의 자유도 | △ | ○ | △ | × | ◎ |
이 표에서 봐야 하는 것은 무엇이 최강인가가 아니라 무엇이 가장 마찰이 적은가입니다.
5. 각각 어떤 안건에 맞는가
5.1 MSI
MSI는 Windows의 전통적인 데스크톱 앱을 제대로 install / uninstall / repair하고 싶을 때의 기준점입니다.
특히 맞는 것은 다음입니다.
- 전체 사용자용의 업무 앱
- Windows 서비스를 포함하는 앱
- COM 등록, file association, machine-wide 설정을 동반하는 앱
- 기존의 installer 운영이 이미 있는 제품
MSI의 강점은 「앱을 OS에 어떻게 넣었는가」를 Windows의 유의로 표현하기 쉽다는 것입니다.
한편으로 약한 곳도 분명합니다.
- authoring이 수수하게 어렵다
- upgrade / patch를 대충 설계하면 나중에 고통스럽기 쉽다
- custom action을 늘릴수록 망가지기 쉽다
- 고빈도 갱신 제품에서는 갱신 UX가 무거워지기 쉽다
5.2 MSIX
MSIX는 modern packaging과 clean update / uninstall을 취하고 싶은 선택입니다. package identity가 필요한 Windows 기능을 쓰고 싶을 때도 의미가 커집니다.
특히 맞는 것은 다음입니다.
- Windows 10/11을 전제로 할 수 있는 데스크톱 앱
- 갱신 빈도가 높은 편의 업무 앱
- package identity가 효과 있는 Windows 기능을 쓰고 싶은 앱
- Intune이나 App Installer에 치우치고 싶은 안건
MSIX의 강점은 갱신과 언인스톨의 깨끗함입니다.
다만 뭐든지 들어가는 것은 아닙니다. 특히 다음은 먼저 확인하는 편이 안전합니다.
- in-process shell extension
- driver
- unrestricted한 오래된 Win32 전제
- package identity를 취하고 싶지 않은 구성
5.3 ClickOnce
ClickOnce는 .NET의 사내용 데스크톱 앱을 per-user로 빠르게 갱신 포함으로 돌리고 싶을 때 지금도 꽤 강합니다.
맞는 것은 다음입니다.
- 사내용 업무 앱
- 표준 사용자로 도입하고 싶다
- 사용자 단위의 배포로 충분
- 갱신 UX를 그렇게까지 만들어 넣고 싶지 않다
반대로 OS에 깊이 건드리는 타입의 제품이나 여러 전제물을 묶는 installer적인 역할까지 기대하지 않는 편이 안전합니다.
5.4 xcopy
xcopy는 install이 아니라 deploy입니다. 레지스트리 등록도 복구 기능도 package identity도 없습니다. 그 대신 두기만 하면 끝난다면 최강급으로 단순합니다.
특히 맞는 것은 다음입니다.
- 진단 도구
- 장치 설정 도구
- 로그 수집 도구
- 현장에 USB로 건네는 유틸리티
- side-by-side로 여러 버전을 공존시키고 싶은 경우
xcopy의 강점은 실패하는 방식이 알기 쉬운 것입니다. 폴더 째 교체, 되돌리고 싶다면 이전 버전으로 되돌린다, 는 운영이 쉽습니다.
다만 당연히 다음은 약합니다.
- Start menu / ARP / repair
- file association / service / shell extension / driver
- built-in 갱신
5.5 자체 updater
자체 updater는 자유도의 선택이라기보다 책임의 선택입니다.
맞는 것은 다음입니다.
- 갱신 빈도가 높다
- stable / beta / preview 같은 채널을 가지고 싶다
- 단계 배포나 롤아웃 율을 제어하고 싶다
- 배경 다운로드, 알림, 유지보수 시간대를 세밀하게 제어하고 싶다
- 갱신 telemetry나 crash recovery를 자체로 보고 싶다
강점은 크지만 지불하는 것도 큽니다.
- 서명 검증
- 배포 manifest
- 재시도 / resume
- proxy / firewall / 폐쇄망 대응
- rollback
- 망가진 갱신의 복구
- updater 자신의 갱신
즉 자유도가 아니라 책임이 늘어난다는 것입니다.
6. 헷갈리기 쉬운 논점
6.1 package identity가 필요한가
만약 원하는 것이 package identity 전제의 Windows 기능이라면 MSIX의 가치는 단번에 올라갑니다.
반대로,
- unrestricted한 file system access
- unrestricted한 registry access
- elevation / process model의 자유도
- 오래된 Win32 전제를 그대로 남기고 싶다
라면 unpackaged 쪽의 방식이 자연스럽습니다.
6.2 서비스 / 드라이버 / shell extension이 있는가
이 3가지는 배포 방식을 단번에 무겁게 합니다.
- driver: MSIX에서는 부적합
- in-process shell extension: MSIX에서는 부적합
- Windows service: MSI는 자연스럽고, MSIX에서도 조건부로 비교 대상
OS와 깊이 결합하는 요소가 있을수록 겉보기가 간단한 배포보다 올바르게 도입·갱신·삭제할 수 있는가가 주제가 됩니다.
6.3 per-user인가 per-machine인가
여기를 애매하게 둔 채 진행하면 나중에 반드시 다툼이 됩니다.
- per-user로 치우치고 싶다
- ClickOnce
- xcopy
- 일부의 MSIX
- per-machine으로 치우치고 싶다
- MSI
- 조건이 맞으면 MSIX
「관리자 권한 없이 넣고 싶다」와 「전체 사용자가 같은 장소에서 쓰고 싶다」는 같지 않습니다.
6.4 갱신 빈도와 운영 책임
갱신 빈도의 감각으로 보면 대체로 이렇습니다.
- 분기에서 월간 갱신: MSI로도 충분히 돌아간다
- 월간에서 주간 갱신: MSIX / ClickOnce가 꽤 편하다
- 주간에서 일간 갱신: 자체 updater를 검토할 이유가 나온다
- 갱신은 수동으로 좋다 / 배치 측이 제어한다: xcopy로도 충분
배포 방식은 기술 선정임과 동시에 운영 설계이기도 합니다.
6.5 폐쇄망·오프라인 배포
폐쇄망에서는 깨끗한 auto-update보다 단순함이 이기는 경우가 많습니다.
- xcopy는 강함
- MSI도 강함
- ClickOnce도 file share나 removable media로 쓸 수 있다
- MSIX도 App Installer의 사용법 나름으로 돌아간다
다만 폐쇄망에서 빈번히 갱신한다면 「누가, 어디에, 신판을 두고, 구판을 어떻게 남길 것인가」까지 정하지 않으면 방식만 골라도 운영이 무너지기 쉽습니다.
7. 헷갈릴 때 마지막에 보는 6가지 질문
- 그 앱은 current user만으로 좋은가, machine-wide에 넣을 필요가 있는가
- service / driver / shell extension / COM 등록은 있는가
- package identity가 필요한 Windows 기능을 쓰는가
- 표준 사용자만으로 도입하고 싶은가
- 갱신 빈도는 월간인가, 주간인가, 더 높은가
- 대상 환경은 폐쇄망인가, OS 버전은 갖춰져 있는가
이 6가지 질문에 답하는 것만으로도 대체로 다음으로 떨어집니다.
- 2가 「예」 → 우선 MSI 쪽부터 생각
- 3이 「예」 → MSIX를 우선 검토
- 1이 current user, 4가 「예」이며 .NET desktop app → ClickOnce가 유력
- 4가 「예」, 2가 「아니오」, 두기만 해도 되는 운영 → xcopy가 유력
- 5가 높고 갱신 UX를 제품 가치로 잡고 싶다 → 자체 updater를 비교 대상에 넣는다
8. 정리
Windows 앱의 배포 방식은 다음 한 문장에 꽤 집약됩니다.
최초 도입을 어떻게 성립시킬까와
계속 갱신을 누가 책임지고 돌릴까를 나누어 정한다.
그 위에서 거친 실무 판단은 이렇습니다.
- MSI: OS에 깊이 넣는 전통적 desktop app
- MSIX: package identity와 modern packaging / update를 취하고 싶은 app
- ClickOnce: per-user의 .NET 업무 앱을 간단히 배포해 갱신하고 싶다
- xcopy: 두기만 하면 되는 자기 완결 도구
- 자체 updater: 갱신 자체를 자사에서 설계·운영할 각오가 있는 제품
그리고 가장 중요한 것은 이것입니다.
- driver / shell extension / service가 있다면 배포 방식은 마지막의 겉모습이 아니라 OS 통합의 방식에서 정해진다
- package identity가 필요하다면 MSIX의 의미가 크다
- 자체 updater는 최후의 카드이며, 최초의 선택지가 아니다
- 폐쇄망에서는 영리함보다 단순함이 이기는 경우가 많다
만약 헷갈리고 있다면 먼저 per-user인가 per-machine인가, OS에 무엇을 등록하는가, 갱신 빈도는 어느 정도인가의 3가지만이라도 먼저 고정하면 이야기가 꽤 앞으로 나갑니다.
9. 참고 자료
- Microsoft Learn, Windows Installer
- Microsoft Learn, What is MSIX?
- Microsoft Learn, Packaging overview for Windows apps
- Microsoft Learn, MSIX features and supported platforms
- Microsoft Learn, App Installer file overview
- Microsoft Learn, Prepare to package a desktop application
- Microsoft Learn, Know your installer
- Microsoft Learn, Convert an installer that includes services
- Microsoft Learn, ClickOnce deployment and security
- Microsoft Learn, Manage updates for a ClickOnce application
- Microsoft Learn, Choosing a ClickOnce deployment strategy
- Microsoft Learn, ClickOnce cache overview
- Microsoft Learn, Windows App SDK deployment guide for self-contained apps
관련 기사
같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.
ClickOnce란 무엇인가 - 구조, 업데이트, 어울리는 장면・어울리지 않는 장면을 실무 시점에서 정리
ClickOnce가 무엇이고 매니페스트, 캐시, 업데이트, 서명이 어떻게 맞물려 동작하는지를 Mermaid 그림과 함께 정리하고, 사내용 .NET 데스크톱 앱 배포에서 어울리는 안건과 어울리지 않는 안건을 실무 시점에서 판단할 수 있도록 도와드립니다.
자동 업데이트 기능의 보안 기본 - 나쁜 패턴과 베스트 프랙티스
자동 업데이트를 신뢰 경계로 다루는 사고방식을 정리합니다. HTTPS만으로 부족한 이유, signed metadata와 클라이언트 측 검증, 키 분리, fail-closed와 rollback, MSIX·ClickOnce 등 Windows의 기존 ...
Windows의 관리자 특권이 필요해지는 것은 언제인가 - UAC, 보호 영역, 설계상의 구분 방법
Windows에서 관리자 권한이 필요한지는 사용자 직함이 아닌 앱이 건드리는 경계로 정해진다는 관점에서, UAC 동작과 보호 영역, per-user 대 per-machine, 매니페스트와 분리 모델까지 정리하여 불필요한 승격을 줄이는 설계 판단 ...
Windows에서 어디까지 싱글 바이너리로 만들 수 있는가 - 1 EXE로 가능한 범위, Windows 의존이 남는 곳, 배포 전 판단표
Windows 앱을 1 EXE로 만들고 싶을 때, 배포물을 합치는 것과 OS 의존을 없애는 것은 다릅니다. .NET single-file·Native AOT·정적 링크의 한계와 WebView2·WinUI·서비스·드라이버에 남는 의존을 판단표로 정...
Windows의 문자 코드와 개행 코드를 정리한다 - Shift_JIS / UTF-8 / UTF-16, 문자 깨짐, CRLF / LF, 왜 혼란스러운가
Windows에서 자주 섞이는 Shift_JIS와 UTF-8, UTF-16, BOM, CRLF/LF의 차이를 bytes 시점에서 분해하고, 문자 깨짐과 개행 문제를 나누어 다루는 실무 규칙과 사고 조사의 5문 체크리스트까지 정리했습니다.
관련 토픽
이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.
Windows 기술 토픽
Windows 개발, 장애 조사, 기존 자산 활용에 관한 KomuraSoft LLC 기사를 모은 토픽 허브입니다.
이 주제와 연결되는 서비스
이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.
Windows 앱 개발
상주 처리, 장비 연동, 운영 로그, 유지 보수 가능한 구조가 필요한 Windows 데스크톱 애플리케이션을 지원합니다.
Windows 소프트웨어 유지 보수 & 현대화
기존 Windows 소프트웨어에 대한 단계적 업그레이드, 기능 추가, 64비트 대응, 유지 보수 가능한 재구조화를 지원합니다.
저자 프로필
기사 저자의 프로필 페이지입니다.
Go Komura
합동회사 코무라소프트 대표
Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.
공개 링크