Windows 앱 배포 방식 고르기 - MSI/MSIX/ClickOnce/xcopy/자체 updater

일본어·영어 시트가 있는 Excel 판단 워크시트를 다운로드

Windows 앱의 배포 방식을 정할 때, 무심코 「무엇이 더 새로운가」「무엇이 더 간단한가」로 이야기를 시작하기 쉽습니다. 다만 실무에서 실제로 중요한 축은 다릅니다.

• 사용자 단위로 설치할 것인가, 머신 전체에 설치할 것인가
• 업데이트를 배포 기반에 맡길 것인가, 직접 가져갈 것인가
• 서비스 / 드라이버 / shell extension / COM 등록처럼 OS 통합이 있는가
• 폐쇄망·오프라인·USB 배포를 견뎌야 하는가
• package identity가 필요한가, 아니면 순수 Win32로서 unrestricted하게 움직이게 할 것인가

배포 방식의 선택은 인스톨러 형식의 취향이 아니라, OS를 어디까지 건드리는가와 업데이트 책임을 누가 지는가의 선택입니다.

flowchart TB
    accTitle: 배포 방식을 정하는 두 축
    accDescr: 배포 방식의 선택은 무엇이 더 새로운가 간단한가라는 인스톨러 형식의 취향이 아니라, OS를 어디까지 건드리는가와 업데이트 책임을 누가 지는가라는 두 축의 선택임을 나타내는 그림.
    a0["「무엇이 더 새로운가·간단한가」"] -.-> a1["이 축으로는 정하지 않는다"]
    a2["OS를 어디까지 건드리는가"] --> a4["배포 방식이 정해진다"]
    a3["업데이트 책임을 누가 지는가"] --> a4

그림 1: 배포 방식은 취향이 아니라, OS 통합의 농도와 업데이트 책임이라는 두 축으로 정한다.

이 글은 Windows 데스크톱 앱을 만들고 있으며, 배포 방식을 이제 정하거나 현재 방식을 다시 보고 싶은 개발자와, 그 운영을 떠맡는 정보시스템 담당자를 대상으로 합니다. 특정 언어나 프레임워크를 전제로 하지 않습니다. 영어 그대로 쓰이는 용어가 많은 분야이므로, 그런 용어는 1.1에 모아 두었습니다. 글 맨 앞 워크시트의 내용은 1.2에 요약해 두었습니다.

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 버전 조건을 먼저 확인합니다

거칠게 정리하면 이렇게 됩니다.

1. OS 등록이 짙다 → MSI 쪽
2. package identity와 modern packaging을 가져가고 싶다 → MSIX
3. per-user의 간단한 배포와 built-in 업데이트가 필요하다 → ClickOnce
4. 두기만 하면 되는 배포가 최우선 → xcopy
5. 업데이트 기반을 자사에서 설계·운영할 각오가 있다 → 자체 updater

flowchart TB
    accTitle: 5가지 방식의 거친 정리
    accDescr: OS 등록이 짙으면 MSI, package identity와 modern packaging을 가져가고 싶으면 MSIX, per-user의 간단한 배포와 built-in 업데이트가 필요하면 ClickOnce, 두기만 하면 되는 배포가 최우선이면 xcopy, 업데이트 기반을 자사에서 설계·운영할 각오가 있으면 자체 updater라는 대응을 나타내는 그림.
    b1{"OS 등록이 짙은가"} -->|"예"| b2["MSI 쪽"]
    b1 -->|"아니요"| b3{"package identity가 필요한가"}
    b3 -->|"예"| b4["MSIX"]
    b3 -->|"아니요"| b5{"per-user 간단 배포+자동 업데이트인가"}
    b5 -->|"예"| b6["ClickOnce"]
    b5 -->|"두기만 하면 됨이 최우선"| b7["xcopy"]
    b7 -.-> b8["업데이트 기반을 자사에서 쥘 각오가 있으면 자체 updater"]

그림 2: 막히면 등록의 농도·identity·배포의 단순함 순으로 가른다.

1.1 본문에 나오는 용어

배포 쪽은 영어 그대로 쓰이는 용어가 많으므로, 먼저 모아 둡니다.

1.2 맨 앞 워크시트에 무엇이 들어 있는가

맨 앞에 둔 Excel 워크시트는, 이 글의 판단을 자신의 안건에 대입해 기록하기 위한 것입니다. 일본어판과 영어판이 있고, 각각 2시트 구성입니다.

Planner 시트는 3개의 블록으로 나뉩니다.

1. 입력 시트: 다음 7항목을 채우면, 제1 후보와 이유를 남겨 둘 수 있는 형태입니다
   • 배포 범위 … per-user / per-machine / 둘 다 / 미정
   • OS 통합 요소 … 없음 / 서비스 / 드라이버 / shell extension / COM 등록 / 복수
   • package identity … 필요 / 불필요 / 판단할 수 없음
   • 표준 사용자 설치 요건 … 필수 / 불필요 / 조건에 따름
   • 업데이트 빈도 … 수동 또는 드묾 / 월간 / 주간 / 그 이상
   • 대상 환경 … 폐쇄망·오프라인 / 관리되는 새 Windows / 구세대가 섞인 Windows / USB·현장
   • 앱 종류 메모 … 사내 .NET 데스크톱 / 상용 제품 / 유틸리티 / 혼재
2. 후보 가리기: 5가지 방식 각각의 「먼저 강하게 볼 조건」과 「먼저 빼기 쉬운 조건」
3. 판단 흐름: 위 항목을 어떤 순서로 보고, 그 결과 어느 방식으로 기울기 쉬운가

Reference 시트는, 이 글 3장의 판단표와 4장의 비교표를 그대로 담은 것입니다.

즉 글의 3장·4장·7장을, 안건마다 기입할 수 있는 형태로 만든 것입니다. 읽기만으로 결론이 난다면 다운로드는 필요 없습니다. 여러 안건을 비교하고 싶거나, 사내에 판단 근거를 남기고 싶을 때 쓰십시오.

flowchart TB
    accTitle: 워크시트 사용법
    accDescr: Planner 시트에서 7항목을 채우고, 후보 가리기와 판단 흐름으로 방식에 기울이며, 제1 후보와 이유를 남겨 둔다는, 판단을 안건마다 기록하는 워크시트의 흐름을 나타내는 그림.
    c1["입력 시트의 7항목을 채운다"] --> c2["후보 가리기로 좁힌다"]
    c2 --> c3["판단 흐름으로 방식에 기울인다"]
    c3 --> c4["제1 후보와 이유를 남긴다"]
    c4 -.-> c5["Reference 시트는 3장·4장의 표"]

그림 3: 워크시트는 글의 판단을, 안건마다의 기록으로 바꾸기 위한 것이다.

이 글의 지식 맵

Windows 앱의 배포 방식은 인스톨러 형식의 취향이 아니라, OS 통합의 깊이와 갱신 책임을 어느 쪽이 지는가라는 2가지 축으로 선택됩니다. MSI는 Windows 서비스나 COM 등록, 드라이버나 shell extension처럼 OS에 깊이 손대는 도입에 적합한 반면 package identity는 갖지 않으며, MSIX는 package identity를 구현해 clean install과 갱신의 깔끔함을 제공하지만 드라이버나 shell extension에는 기본적으로 맞지 않습니다. ClickOnce는 .NET 앱을 per-user로 간단히 배포·자동 갱신할 수 있지만 Windows 서비스를 포함하는 제품에는 맞지 않고, xcopy 배포는 두기만 하면 동작하는 단순함이 강점인 대신 package identity나 서비스와의 궁합을 갖지 않습니다. 자체 updater는 서명 검증이나 코드 서명 인증서 관리까지를 스스로 맡는 대신, 갱신의 자유도와 폐쇄망 배포에 대한 대응력을 얻는 선택입니다.

flowchart LR
    accTitle: Windows 앱 배포 방식 지식 맵
    accDescr: MSI·MSIX·ClickOnce·xcopy·자체 updater가 OS와의 결합도와 갱신 책임을 누가 지는가라는 2가지 축으로 어떻게 구분되어 쓰이는지를 보여주는 그림입니다.
    msi["MSI(Windows Installer)"]
    msix["MSIX"]
    clickonce["ClickOnce"]
    windows_service["Windows 서비스"]
    driver_package["드라이버 패키지"]
    shell_extension["셸 확장(탐색기 확장)"]
    com["COM(컴포넌트 오브젝트 모델)"]
    closed_network["폐쇄망"]
    package_identity["package identity"]
    code_signing_cert["코드 서명 인증서"]
    dotnet[".NET(Core 이후)"]
    xcopy_deployment["xcopy 배포"]
    custom_updater["자체 업데이터"]
    msi -->|"권장되는 대응"| windows_service
    msi -->|"권장되는 대응"| driver_package
    msi -->|"권장되는 대응"| shell_extension
    msi -.->|"이용한다"| com
    msi -->|"권장되는 대응"| closed_network
    msix -->|"구현을 담당한다"| package_identity
    msix -->|"사용은 비권장"| driver_package
    msix -.->|"사용은 비권장"| shell_extension
    msix -.->|"권장되는 대응"| closed_network
    msix -->|"전제로 한다"| code_signing_cert
    clickonce -.->|"전제로 한다"| dotnet
    clickonce -.->|"권장되는 대응"| closed_network
    clickonce -->|"사용은 비권장"| windows_service
    xcopy_deployment -->|"사용은 비권장"| windows_service
    xcopy_deployment -->|"권장되는 대응"| closed_network
    custom_updater -.->|"전제로 한다"| code_signing_cert
    custom_updater -.->|"권장되는 대응"| closed_network

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 17건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 다섯 가지는 같은 무대가 아니다

여기는 꽤 중요합니다.

MSI / MSIX / ClickOnce / xcopy는 주로 어떻게 넣을 것인가의 이야기입니다. 한편 자체 updater는 주로 업데이트 책임을 어떻게 질 것인가의 이야기입니다.

즉 실무에서는 2층으로 나눠 생각하는 편이 정리하기 쉽습니다.

그림으로 그리면 이렇게 됩니다. 점선은 「그 설치 방식이라면 자연스럽게 이어지는 업데이트 수단」입니다.

flowchart TB
    APP["배포하고 싶은 Windows 앱"] --> Q1["먼저: 어떻게 넣을 것인가<br/>최초 설치 층"]
    APP --> Q2["다음: 누가 업데이트 책임을 질 것인가<br/>계속 업데이트 층"]

    Q1 --> MSI["MSI"]
    Q1 --> MSIX["MSIX"]
    Q1 --> CO["ClickOnce"]
    Q1 --> XC["xcopy"]

    Q2 --> AI["MSIX App Installer"]
    Q2 --> COU["ClickOnce의 built-in 업데이트"]
    Q2 --> MAN["수동 교체"]
    Q2 --> OWN["자체 updater"]

    MSIX -.-> AI
    CO -.-> COU
    MSI -.-> MAN
    XC -.-> MAN
    MSI -.-> OWN
    XC -.-> OWN

그림 4: 최초 설치 층과 계속 업데이트 층의 2층 모델. 점선은 자연스럽게 이어지는 업데이트 수단.

ClickOnce와 MSIX는 위 층을 정하면 아래 층도 거의 정해집니다. 반대로 MSI와 xcopy는 아래 층을 따로 정해야 합니다. 「업데이트를 어떻게 할 것인가」가 공중에 뜨기 쉬운 것은, 이 둘을 골랐을 때입니다.

그래서 자체 updater는 맨 처음에 고르는 것이 아니라, 기존 배포 방식으로는 부족한 업데이트 요건이 있을 때 추가로 고르는 것이라고 생각하는 편이 흔들리지 않습니다.

flowchart TB
    accTitle: 업데이트가 공중에 뜨는 것은 MSI와 xcopy
    accDescr: ClickOnce와 MSIX는 설치 방식을 정하면 업데이트 수단도 거의 정해지지만, MSI와 xcopy는 계속 업데이트 층을 따로 정해야 하며, 자체 updater는 그 업데이트 요건이 부족할 때 추가로 고르는 것임을 나타내는 그림.
    d1["ClickOnce / MSIX를 고른다"] --> d2["업데이트 수단도 거의 정해진다"]
    d3["MSI / xcopy를 고른다"] --> d4["업데이트를 어떻게 할 것인가가 공중에 뜬다"]
    d4 --> d5["계속 업데이트 층을 따로 정한다"]
    d5 -.-> d6["부족할 때 자체 updater를 추가한다"]

그림 5: 자체 updater는 처음 선택지가 아니라, 업데이트 층의 구멍을 메우는 추가 선택.

3. 한 장으로 보는 판단표

우선 가장 쓰기 쉬운 판단표를 둡니다.

이 표에서 가장 중요한 것은, 「업데이트가 있다」만으로 자체 updater로 건너뛰지 않는 것입니다.

4. 관점별 비교

이 표에서 봐야 할 것은 무엇이 최강인가가 아니라, 무엇이 가장 마찰이 적은가입니다.

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가 무거워지기 쉽다

flowchart TB
    accTitle: MSI의 강점과 대가
    accDescr: MSI는 앱을 OS에 어떻게 넣었는가를 Windows의 방식으로 표현하기 쉬운 반면, authoring이 어렵고, custom action을 늘릴수록 깨지기 쉬우며, 고빈도 업데이트에서는 업데이트 UX가 무거워지기 쉬움을 나타내는 그림.
    e1["MSI"] --> e2["OS에 넣는 방식을 Windows의 방식으로 표현"]
    e2 --> e3["install / uninstall / repair가 갖춰진다"]
    e1 -.-> e4["authoring이 은근히 어렵다"]
    e4 -.-> e5["custom action을 늘릴수록 깨지기 쉽다"]

그림 6: MSI는 OS 통합의 표현력과 맞바꿔, authoring의 어려움을 안는다.

5.2 MSIX

MSIX는 modern packaging과 clean update / uninstall을 가져가고 싶은 선택입니다. package identity가 필요한 Windows 기능을 쓰고 싶을 때도 의미가 커집니다.

맞는 것은 이 근처입니다.

• Windows 10/11을 전제로 할 수 있는 데스크톱 앱
• 업데이트 빈도가 비교적 높은 업무 앱
• package identity가 먹히는 Windows 기능을 쓰고 싶은 앱
• Intune이나 App Installer에 맞추고 싶은 안건

MSIX의 강점은 업데이트와 제거의 깔끔함입니다.

다만 무엇이든 들어가는 것은 아닙니다. 특히 이 4가지는 처음에 확인하는 편이 안전합니다.

• in-process shell extension(Windows 11 21H2 이후의 MSIX에서는 legacy context menu handler 등을 등록할 수 있으나, 매니페스트 선언과 대상 OS 확인이 필요)
• driver
• unrestricted한 오래된 Win32 전제
• package identity를 가져가고 싶지 않은 구성

이 4가지는 각각 확인처가 다릅니다. 「MSIX는 무리인 것 같다」에서 멈추지 말고, 어느 자료를 보면 결론이 나는지까지 정해 두면 빠릅니다.

모두 9장의 참고 자료에 링크를 두었습니다. 판단할 때는 「대응하는가」가 아니라 「어느 버전부터, 어떤 선언을 하면 대응하는가」까지 보십시오. 여기를 OS 버전 조건까지 포함해 잡아 두지 않으면, 검증기에서는 동작했는데 현장의 오래된 Windows에서는 들어가지 않는다는 형태로 나중에 나옵니다.

flowchart TB
    accTitle: MSIX의 제약은 확인처까지 정한다
    accDescr: shell extension이나 driver처럼 MSIX에서 막히는 4가지는 각각 확인처 자료가 다르므로, 무리인 것 같다에서 멈추지 말고, 어느 버전부터 어떤 선언을 하면 대응하는가까지 봄으로써, 검증기에서는 동작했는데 현장에서 들어가지 않는 사고를 막는다는 그림.
    f1["MSIX에서 막히는 4가지"] --> f2["「무리인 것 같다」에서 멈추지 않는다"]
    f2 --> f3["어느 자료로 결론 낼지 정한다"]
    f3 --> f4["어느 버전부터·어느 선언으로 대응하는지까지 본다"]
    f4 -.-> f5["검증기 OK·현장 NG를 막는다"]

그림 7: MSIX의 제약은, OS 버전 조건과 선언 방법까지 확인해 결론을 낸다.

5.3 ClickOnce

ClickOnce는 .NET 사내 데스크톱 앱을, per-user로, 빠르게, 업데이트까지 포함해 돌리고 싶을 때 지금도 꽤 강합니다.

맞는 것은 이런 장면입니다.

• 사내 업무 앱
• 표준 사용자로 설치하고 싶다
• 사용자 단위 배포로 충분하다
• 업데이트 UX를 그다지 만들어 넣고 싶지 않다

반대로, OS를 깊게 건드리는 유형의 제품이나, 여러 선행 구성 요소를 묶는 installer 역할까지는 기대하지 않는 편이 안전합니다.

5.4 xcopy

xcopy는 install이 아니라 deploy입니다. 레지스트리 등록도, 복구 기능도, package identity도 없습니다. 그 대신 두기만 하면 된다면 최강 급으로 단순합니다.

특기가 살아나는 것은 이런 도구들입니다.

• 진단 도구
• 장치 설정 도구
• 로그 수집 도구
• 현장에 USB로 건네는 유틸리티
• side-by-side로 여러 버전을 공존시키고 싶은 경우

xcopy의 강점은 실패하는 방식이 알기 쉽다는 점입니다. 폴더째 갈아 끼우고, 되돌리고 싶으면 이전 버전으로 되돌리는 운영이 쉽습니다.

flowchart TB
    accTitle: xcopy는 install이 아니라 deploy
    accDescr: xcopy는 레지스트리 등록도 복구 기능도 package identity도 없는 대신, 두기만 하면 되고, 폴더째 갈아 끼운 뒤 되돌리고 싶으면 이전 버전으로 되돌린다는, 실패하는 방식이 알기 쉬운 운영이 가능함을 나타내는 그림.
    g1["폴더째 둔다"] --> g2["그대로 동작한다"]
    g2 --> g3["업데이트는 폴더째 교체"]
    g3 --> g4["되돌리기는 이전 버전으로 되돌림"]
    g1 -.-> g5["등록·복구·identity는 갖지 않는다"]

그림 8: 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 자신의 업데이트

즉 자유도가 아니라 책임이 늘어난다는 것입니다.

flowchart TB
    accTitle: 자체 updater는 책임의 선택
    accDescr: 자체 updater는 채널이나 단계 배포, telemetry 같은 자유도를 얻는 대신, 서명 검증, 배포 manifest, rollback, 깨진 업데이트의 복구, updater 자신의 업데이트까지 직접 설계·운영하는 책임을 지는 선택임을 나타내는 그림.
    h1["얻는 것: 채널·단계 배포·telemetry"] --> h3["자체 updater"]
    h2["치르는 것: 서명 검증·rollback·복구"] --> h3
    h3 --> h4["자유도가 아니라 책임이 늘어난다"]
    h2 -.-> h5["updater 자신의 업데이트도 자신의 일"]

그림 9: 자체 updater로 늘어나는 것은 자유도가 아니라, 업데이트 기반의 운영 책임.

5.6 방식을 정한 뒤, 다음에 무엇을 조사하는가

「MSI로 간다」고 정해도, 거기서부터 무엇을 조사하면 좋을지 모르면 멈춥니다. 대표적인 입구를 나열해 둡니다. 모두 「이것을 쓰라」가 아니라, 그 방식을 골랐다면, 먼저 이름을 알아 두면 좋은 것입니다.

여기서 주의할 점은, 도구를 고르는 것과 방식을 고르는 것은 별개라는 점입니다. 예를 들어 Inno Setup은 다루기 쉽지만, 나오는 것은 MSI가 아니므로, Windows Installer를 전제로 한 운영, 예를 들어 그룹 정책으로의 소프트웨어 배포나 msiexec에 의한 복구에는 맞지 않습니다. 5.1에서 MSI를 고른 이유가 거기에 있다면, 도구도 그에 맞춰야 합니다.

flowchart TB
    accTitle: 도구 고르기와 방식 고르기는 별개
    accDescr: Inno Setup은 다루기 쉽지만, 나오는 것은 MSI가 아니므로, 그룹 정책으로의 소프트웨어 배포나 msiexec에 의한 복구에는 맞지 않으며, 방식을 고른 이유에 맞춰 도구를 고를 필요가 있음을 나타내는 그림.
    i1["방식을 정한다"] --> i2["도구를 정한다"]
    i2 -.-> i3["Inno Setup은 MSI를 만들지 않는다"]
    i3 -.-> i4["GPO 배포나 msiexec 복구에 맞지 않는다"]
    i4 -.-> i5["방식을 고른 이유에 도구를 맞춘다"]

그림 10: 편리한 도구가, 고른 방식의 전제에 맞는다는 보장은 없다.

6. 헷갈리기 쉬운 논점

6.1 package identity가 필요한가

원하는 것이 package identity를 전제로 하는 Windows 기능이라면, MSIX의 가치는 단숨에 올라갑니다.

반대로,

• unrestricted한 file system access
• unrestricted한 registry access
• elevation / process model의 자유도
• 오래된 Win32 전제를 그대로 남기고 싶다

라면, unpackaged 쪽 방식이 더 자연스럽습니다.

flowchart TB
    accTitle: package identity의 필요 여부로 가른다
    accDescr: package identity를 전제로 하는 Windows 기능이 필요하면 MSIX의 가치가 단숨에 올라가고, unrestricted한 파일이나 레지스트리 액세스, 오래된 Win32 전제를 그대로 남기고 싶으면 unpackaged 쪽 방식이 자연스러움을 나타내는 그림.
    j1{"package identity 전제 기능이 필요한가"} -->|"예"| j2["MSIX의 가치가 단숨에 올라간다"]
    j1 -->|"unrestricted하게 움직이게 하고 싶다"| j3["unpackaged 쪽 방식이 자연스럽다"]

그림 11: identity의 필요 여부는, packaged와 unpackaged의 분수령이 된다.

6.2 서비스 / 드라이버 / shell extension이 있는가

이 셋은 배포 방식을 단숨에 무겁게 만듭니다.

• 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

「관리자 권한 없이 넣고 싶다」와 「모든 사용자가 같은 장소에서 쓰고 싶다」는 같지 않습니다.

flowchart TB
    accTitle: per-user와 per-machine을 혼동하지 않는다
    accDescr: per-user로 기울이고 싶으면 ClickOnce나 xcopy나 일부 MSIX, per-machine으로 기울이고 싶으면 MSI나 조건이 맞으면 MSIX가 후보가 되며, 관리자 권한 없이 넣고 싶은 것과 모든 사용자가 같은 장소에서 쓰고 싶은 것은 같지 않음을 나타내는 그림.
    k1["per-user로 기울이고 싶다"] --> k2["ClickOnce / xcopy / 일부 MSIX"]
    k3["per-machine으로 기울이고 싶다"] --> k4["MSI / 조건이 맞으면 MSIX"]
    k1 -.-> k5["권한 없이 설치와 전원 공통 장소는 다른 이야기"]

그림 12: 설치 범위를 애매하게 둔 채 진행하면, 나중에 반드시 다툰다.

6.4 업데이트 빈도와 운영 책임

업데이트 빈도의 감각으로 보면, 대략 이렇습니다.

• 분기에서 월간 업데이트: MSI로도 충분히 돈다
• 월간에서 주간 업데이트: MSIX / ClickOnce가 꽤 수월하다
• 주간에서 일간 업데이트: 자체 updater를 검토할 이유가 생긴다
• 업데이트는 수동으로 충분하다 / 배치 쪽이 제어한다: xcopy로도 충분하다

배포 방식은 기술 선정인 동시에 운영 설계이기도 합니다.

flowchart TB
    accTitle: 업데이트 빈도의 계단
    accDescr: 분기에서 월간 업데이트면 MSI로도 충분히 돌고, 월간에서 주간이면 MSIX나 ClickOnce가 꽤 수월해지며, 주간에서 일간이면 자체 updater를 검토할 이유가 생기고, 업데이트가 수동으로 충분하면 xcopy로도 충분하다는 업데이트 빈도 기준을 나타내는 그림.
    m1["분기〜월간: MSI로도 충분"] --> m2["월간〜주간: MSIX / ClickOnce가 수월"]
    m2 --> m3["주간〜일간: 자체 updater의 검토 이유가 생긴다"]
    m1 -.-> m4["수동으로 충분하면 xcopy로도 충분"]

그림 13: 업데이트 빈도가 올라갈수록, built-in 업데이트나 자체 기반의 가치가 커진다.

6.5 폐쇄망·오프라인 배포

폐쇄망에서는, 깔끔한 auto-update보다 단순함이 이기는 경우가 많습니다.

• xcopy는 강하다
• MSI도 강하다
• ClickOnce도 file share나 removable media로 쓸 수 있다
• MSIX도 App Installer 사용법에 따라 돈다

다만 폐쇄망에서 자주 업데이트한다면, 「누가, 어디에, 새 버전을 두고, 이전 버전을 어떻게 남길 것인가」까지 정하지 않으면, 방식만 골라도 운영이 무너지기 쉽습니다.

flowchart TB
    accTitle: 폐쇄망에서는 단순함이 이긴다
    accDescr: 폐쇄망에서는 깔끔한 auto-update보다 단순함이 이기는 경우가 많고, 자주 업데이트한다면, 누가, 어디에, 새 버전을 두고, 이전 버전을 어떻게 남길 것인가까지 정하지 않으면, 방식만 골라도 운영이 무너지기 쉬움을 나타내는 그림.
    n1["폐쇄망·오프라인 환경"] --> n2["깔끔한 auto-update보다 단순함"]
    n2 --> n3["xcopy나 MSI가 강하다"]
    n2 -.-> n4["누가·어디에 새 버전을 둘지까지 정한다"]
    n4 -.-> n5["이전 버전을 어떻게 남길지도 정한다"]

그림 14: 폐쇄망에서는 방식 고르기보다 먼저, 새 버전과 이전 버전의 두는 법의 운영을 정한다.

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를 비교 대상에 넣는다

flowchart TB
    accTitle: 6가지 질문에서의 착지점
    accDescr: 서비스나 드라이버 같은 OS 통합이 있으면 먼저 MSI 쪽, package identity가 필요하면 MSIX를 우선 검토, current user로 표준 사용자 설치의 .NET 데스크톱 앱이면 ClickOnce, 두기만 하면 되는 운영이면 xcopy, 업데이트 빈도가 높고 업데이트 UX를 쥐고 싶으면 자체 updater를 비교 대상에 넣는다는 착지를 나타내는 그림.
    p1{"OS 통합(서비스 등)이 있는가"} -->|"예"| p2["먼저 MSI 쪽부터 생각한다"]
    p1 -->|"아니요"| p3{"package identity가 필요한가"}
    p3 -->|"예"| p4["MSIX를 우선 검토"]
    p3 -->|"아니요"| p5{"per-user+표준 사용자 설치인가"}
    p5 -->|".NET 데스크톱이면"| p6["ClickOnce가 유력"]
    p5 -->|"두기만 하면 되는 운영이면"| p7["xcopy가 유력"]
    p6 -.-> p8["업데이트 UX를 쥐고 싶으면 자체 updater도 비교"]

그림 15: 6가지 질문의 답을 이 순서로 따라가면, 착지점이 대체로 보인다.

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에 무엇을 등록하는가, 업데이트 빈도는 어느 정도인가 세 가지만이라도 먼저 고정하면, 이야기가 꽤 앞으로 갑니다.

flowchart TB
    accTitle: 먼저 고정할 세 가지
    accDescr: 막혀 있다면, per-user인가 per-machine인가, OS에 무엇을 등록하는가, 업데이트 빈도는 어느 정도인가 세 가지만이라도 먼저 고정하면, 배포 방식 이야기가 꽤 앞으로 감을 나타내는 그림.
    q1["per-user인가 per-machine인가"] --> q4["먼저 고정한다"]
    q2["OS에 무엇을 등록하는가"] --> q4
    q3["업데이트 빈도는 어느 정도인가"] --> q4
    q4 --> q5["이야기가 꽤 앞으로 간다"]

그림 16: 방식에서 막히면, 이 세 점만이라도 먼저 고정한다.

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, Support legacy context menus for packaged apps
• 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

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

MSI와 MSIX의 차이는 무엇인가요?

MSI는 Windows의 전통적인 인스톨러 형식입니다. per-machine 설치, Windows 서비스, COM 등록, shell extension처럼 OS를 깊게 건드리는 설치와 잘 맞고, install / uninstall / repair를 Windows의 방식으로 표현할 수 있습니다. MSIX는 Windows 10/11을 전제로 하는 modern packaging이며, clean install / clean uninstall, 잦은 업데이트, package identity가 강점입니다. 반면 MSIX는 드라이버에 맞지 않고, in-process shell extension은 Windows 11 21H2 이후에서 조건부로 지원하며, unrestricted한 오래된 Win32 전제에도 맞지 않습니다. OS 등록이 짙다면 MSI, package identity와 업데이트의 깔끔함을 원한다면 MSIX가 출발점입니다.

MSIX와 ClickOnce 중 어느 쪽을 골라야 하나요?

per-user의 .NET 사내 업무 앱을 간단히 배포하고 자동 업데이트하고 싶다면, ClickOnce는 지금도 꽤 강한 선택입니다. built-in 업데이트 모델이 쓰기 쉽고, 표준 사용자 권한만으로 설치할 수 있으며, 업데이트 UX를 따로 만들 필요도 없습니다. 반면 package identity가 필요한 Windows 기능을 쓰고 싶거나, clean install / uninstall을 중시하거나, Intune이나 App Installer에 맞추고 싶다면 MSIX가 유력합니다. 둘 다 OS를 깊게 건드리는 제품에는 맞지 않으므로, 서비스나 드라이버가 있다면 MSI 쪽부터 생각합니다.

ClickOnce는 지금도 쓸 수 있나요? 낡은 기술이 아닌가요?

지금도 쓸 수 있고, 맞는 장면에서는 꽤 강한 선택입니다. .NET 사내 데스크톱 앱을 사용자 단위(per-user)로, 표준 사용자 권한만으로 빠르게 배포하고, built-in 업데이트 모델로 돌리고 싶을 때 유효합니다. 반대로 Windows 서비스나 드라이버, shell extension처럼 OS를 깊게 건드리는 제품이나, 여러 선행 구성 요소를 묶는 인스톨러 역할까지는 기대하지 않는 편이 안전합니다. 업데이트 빈도 기준으로는, 월간에서 주간 정도라면 ClickOnce나 MSIX로 꽤 수월하게 돌릴 수 있습니다.

자체 updater는 어떤 때 검토해야 하나요?

자체 updater는 맨 처음에 고르는 것이 아니라, 기존 배포 방식으로는 부족한 업데이트 요건이 있을 때 추가로 고르는 것입니다. 검토할 가치가 생기는 경우는, 업데이트 빈도가 높고, stable / beta / preview 같은 채널을 두고 싶고, 단계 배포나 롤아웃 비율을 제어하고 싶고, 업데이트 telemetry나 crash recovery를 직접 보고 싶을 때입니다. 다만 서명 검증, 배포 manifest, 재시도, rollback, 깨진 업데이트의 복구, updater 자신의 업데이트까지 직접 설계·운영하는 책임을 지게 되므로, 자유도가 아니라 책임이 늘어나는 선택으로 봐야 합니다.

저자 프로필

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

Go Komura

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

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