Windows 앱의 배포 방식을 어떻게 고를까 - MSI / MSIX / ClickOnce / xcopy / 자체 updater의 판단표

· · Windows, 배포, MSI, MSIX, ClickOnce, xcopy, updater

한일 시트 부 Excel 판단 북 다운로드

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는 맞지 않습니다

요컨대 대체로 다음입니다.

  1. OS에의 등록이 짙다 → MSI 쪽
  2. package identity와 modern packaging을 취하고 싶다 → MSIX
  3. per-user의 간단 배포와 built-in 갱신이 필요 → ClickOnce
  4. 두기만 하면 되는 배포가 최우선 → xcopy
  5. 갱신 기반을 자사에서 설계·운영할 각오가 있다 → 자체 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가지 질문

  1. 그 앱은 current user만으로 좋은가, machine-wide에 넣을 필요가 있는가
  2. service / driver / shell extension / COM 등록은 있는가
  3. package identity가 필요한 Windows 기능을 쓰는가
  4. 표준 사용자만으로 도입하고 싶은가
  5. 갱신 빈도는 월간인가, 주간인가, 더 높은가
  6. 대상 환경은 폐쇄망인가, 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. 참고 자료

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.

블로그 목록으로 돌아가기