Windows 애플리케이션 패키징 vs 애플리케이션 배포

소개

Windows 애플리케이션은 개별 엔드포인트에 설치 및 관리되거나 중앙에서 호스팅되어 원격으로 사용자에게 제공될 수 있으며, 이는 애플리케이션 및 인프라 요구 사항에 따라 다릅니다. 이러한 모델 간의 선택은 기술 비교 이상의 것을 요구합니다. 이 기사는 Windows 애플리케이션 패키징이 어떻게 작동하는지, 애플리케이션 게시와 어떻게 다른지, 각 접근 방식이 언제 의미가 있는지, 그리고 IT 팀이 동일한 애플리케이션 배포 전략 내에서 두 가지를 어떻게 결합할 수 있는지를 설명합니다.

Windows 애플리케이션 패키징이란 무엇인가요?

Windows 애플리케이션 패키징은 예측 가능한 설치 및 관리를 위해 애플리케이션과 필요한 파일, 구성 및 메타데이터의 준비를 포함합니다.

모든 대상 시스템에서 애플리케이션을 수동으로 구성하는 대신, IT 팀은 표준화된 패키지를 사용하여 설치, 구성, 업데이트 및 제거를 보다 일관되게 만들 수 있습니다.

Microsoft의 현대적인 Windows 패키징 모델은 패키지 ID 제공, 예측 가능한 설치 및 제거, 제어된 업데이트 및 Windows 기능과의 통합을 가능하게 하는 MSIX를 포함합니다.

전통적인 Win32 애플리케이션은 MSI 및 EXE 설치 프로그램과 같은 기술을 활용할 수 있습니다.

애플리케이션 패키징은 따라서 무엇을 설치해야 하는지, 설치 및 제거가 어떻게 이루어져야 하는지, 사용자에게 제공되는 구성은 무엇인지, 업그레이드는 어떻게 진행될지를 결정합니다. 그 목표는 애플리케이션 배포가 대상 Windows 환경에서 반복 가능하고 관리 가능하도록 하는 것입니다.

애플리케이션 패키지에는 무엇이 포함되어 있나요?

응용 프로그램 패키지의 내용은 포장 기술과 응용 프로그램 자체에 따라 다릅니다.

안 MSIX 패키지 예를 들어, 애플리케이션의 페이로드를 패키지 아이덴티티, 종속성 및 기능과 같은 요소를 정의하는 매니페스트와 결합합니다. 여기서 중요한 구분은 패키지가 애플리케이션이 실행되어야 하는 위치를 지정하는 것이 아니라 배포 및 배치의 단위를 정의한다는 것입니다.

전통적인 기업 패키징은 기존 설치 프로그램을 변환하거나 포장하고, 구성 추가, 배포 논리 정의 및 배포 전에 최종 패키지를 검증하는 작업을 포함할 수 있습니다.

응용 프로그램 패키징은 단순히 응용 프로그램 파일을 다른 파일 안에 넣는 것 이상입니다. 이는 소프트웨어 설치를 반복 가능하고, 관리 가능하며, 지원 가능하게 만드는 것을 목표로 합니다.

윈도우 애플리케이션 패키징: 어떻게 작동하나요?

패키징 워크플로우는 애플리케이션, 패키징 형식 및 관리 플랫폼에 따라 다릅니다. 그러나 대부분의 패키징 워크플로우는 일반적으로 세 가지 다른 단계로 나뉩니다: 발견, 패키지 생성 및 배포 전 테스트.

애플리케이션 발견 및 요구 사항

기존 애플리케이션의 재포장을 수행하기 전에 관리자는 애플리케이션의 설치 프로그램이 수정하는 내용과 애플리케이션이 실행 중에 요구하는 내용을 이해하는 것이 중요합니다.

발견 활동에는 다음이 포함되지만 이에 국한되지 않습니다:

• 파일 및 디렉토리
• 레지스트리 항목
• 윈도우 서비스
• 런타임 종속성
• 환경 변수
• 파일 연결
• 권한
• 단축키 및 구성 파일

애플리케이션이 배포되는 환경은 설치 프로그램만큼이나 중요할 수 있습니다. 개발자의 작업 공간에서 개발되고 테스트된 애플리케이션은 표준 사용자 권한을 사용하여 실행되거나, 깨끗한 기업 Windows 이미지에서 실행될 때 다르게 작동할 수 있습니다. 다중 사용자 Windows Server 환경 .

패키지 생성 및 구성

IT 팀은 그런 소프트웨어와 배포 모델에 적합한 패키징 기술을 사용하여 애플리케이션을 준비합니다.

Windows 애플리케이션의 경우, 이는 MSIX 패키지를 만드는 것을 의미할 수 있습니다. 이는 MSI 또는 EXE 설치 프로그램 형식으로 Win32를 사용하는 기존 소프트웨어를 남겨두거나 일부 애플리케이션을 MSIX로 변환하는 것을 포함할 수 있습니다. 패키징에 대한 다양한 접근 방식은 패키지에 대한 정체성을 제공하면서 소프트웨어가 기존 설치 모델의 요소를 유지할 수 있도록 합니다.

따라서 모든 Windows 애플리케이션에 적합한 단일 패키징 형식은 없습니다. 애플리케이션, 그 환경 및 관리 요구 사항이 패키징 접근 방식을 결정해야 합니다.

테스트 및 배포

패키지는 다음과 같아야 합니다. 깨끗한 시스템에서 테스트됨 대상 생산 환경을 복제하는.

테스트 프로세스에는 설치, 첫 실행, 종속성, 업데이트, 애플리케이션 기능 및 제거 동작이 포함되어야 합니다. 관리자는 또한 권한 및 사용자별 구성이 올바르게 처리되는지 확인해야 하며, 특히 애플리케이션 패키징 시 발생할 수 있는 파일 또는 레지스트리 리디렉션의 경우에 주의해야 합니다.

검증 후, 패키지는 조직의 선호 소프트웨어 배포 또는 엔드포인트 관리 플랫폼을 통해 배포될 수 있습니다.

이제 한 걸음 물러서서 미묘하지만 매우 중요한 구분을 명확히 해봅시다:

응용 프로그램이 패키징된 후 배포됩니다.

이러한 기능의 분리는 애플리케이션 게시를 위한 자연스러운 전환점을 생성하기 때문에 중요합니다.

Windows 애플리케이션 퍼블리싱이란 무엇인가요?

윈도우 애플리케이션 퍼블리싱 중앙 집중식 Windows 인프라에 설치된 애플리케이션을 네트워크 또는 인터넷을 통해 권한이 있는 사용자에게 배포하는 역할을 합니다.

응용 프로그램은 각 사용자의 엔드포인트에서 실행되는 대신 원격 Windows 호스트에서 실행됩니다. 이 경우 사용자는 호환되는 클라이언트, 바로 가기 또는 웹 브라우저를 통해 원격으로 실행된 응용 프로그램에 접근할 수 있습니다.

서버에 설치된 애플리케이션 → 사용자에게 접근 권한 부여 → 서버에서 애플리케이션 실행 → 사용자에게 애플리케이션 인터페이스 제공

이 접근 방식은 각 엔드포인트에 비즈니스 애플리케이션을 설치하고 유지 관리하는 대신, 관리자가 사용자의 세션을 호스팅하는 서버에서 이를 유지 관리해야 한다는 점에서 다릅니다. 따라서 사용자는 중앙 집중식 인프라에서 호스팅되고 있음에도 불구하고 자신의 작업 환경에 원활하게 통합된 것처럼 보이는 애플리케이션에 접근할 수 있습니다.

Windows 애플리케이션 패키징 vs 애플리케이션 퍼블리싱: 그들은 어떻게 다릅니까?

가장 간단한 구분은:

애플리케이션 패키징은 소프트웨어가 설치 및 관리되도록 준비되는 방식을 결정합니다. 애플리케이션 퍼블리싱은 사용자가 중앙 집중식 인프라에서 실행되는 소프트웨어에 접근하는 방식을 결정합니다.

따라서 기술은 애플리케이션 배포의 다양한 단계에서 작동합니다.

질문	윈도우 애플리케이션 패키징	애플리케이션 게시
주요 목적	소프트웨어를 반복 가능한 설치 및 유지 관리를 위해 준비하십시오.	사용자에게 중앙에서 호스팅되는 애플리케이션에 대한 액세스를 제공합니다.
주요 IT 질문	이 애플리케이션을 어떻게 설치하고 관리해야 하나요?	사용자는 이 애플리케이션에 어떻게 접근하고 실행해야 합니까?
앱은 어디에서 실행되나요?	어떤 시스템이 애플리케이션을 수신하든	게시 또는 세션 호스트
사용자 엔드포인트에 로컬 설치?	일반적으로 엔드포인트 배포에 필요합니다.	애플리케이션 설치를 완료하는 데 일반적으로 필요하지 않습니다.
업데이트	적용 가능한 배포 목표에 도달해야 합니다.	호스팅 출판에 중앙 집중적으로 적용할 수 있습니다.
엔드포인트 요구 사항	엔드포인트는 로컬에서 실행되는 애플리케이션을 지원해야 합니다.	엔드포인트는 주로 호환 가능한 액세스 방법이 필요합니다.
전형적인 범위	소프트웨어 수명 주기 및 엔드포인트/서버 관리	중앙 집중식 애플리케이션 배포
일반적인 사용 사례	관리되는 PC, 표준화된 소프트웨어, 통제된 배포	원격 사용자, BYOD, 레거시 앱 및 중앙 집중식 애플리케이션 액세스

하나의 자격: 애플리케이션 패키징은 해당 소프트웨어가 운영되는 위치를 결정하지 않습니다.

MSIX, MSI 또는 기타 형태의 패키지는 워크스테이션, 노트북, 가상 머신 또는 서버에 배포될 수 있습니다. 패키징은 소프트웨어가 어떻게 설치되고 서비스되는지를 결정합니다. 따라서 대상 배포는 애플리케이션이 어디에 설치되는지를 결정합니다.

애플리케이션 게시에는 추가적인 아키텍처 고려 사항이 도입됩니다. 애플리케이션 프로세스는 중앙 집중식 인프라에서 실행되며, 그 인터페이스는 권한이 있는 사용자에게 원격 엔드포인트에서 제공됩니다.

어떤 경우에 애플리케이션 패키징과 배포를 함께 사용할 수 있습니까?

네. 그들은 애플리케이션 배포 생애 주기의 서로 다른 지점을 다루며 독립적으로 또는 조합하여 사용할 수 있습니다.

비즈니스 라인 Windows 애플리케이션을 보유한 조직을 고려해 보십시오. 로컬에서 실행해야 하는 경우, 모든 관리되는 엔드포인트에 패키징하여 배포할 수 있습니다.

패키지 → 엔드포인트에 배포 → 애플리케이션이 로컬에서 실행됩니다.

조직이 중앙 집중화해야 하는 경우, 관련 세션 호스트에 패키징하거나 설치한 후 게시할 수 있습니다.

패키지 또는 설치 → 중앙 호스트에 배포 → 게시 → 애플리케이션이 중앙에서 실행됨

이 경우, 애플리케이션 패키징이 반드시 포기되는 것은 아닙니다. 이는 모든 사용자의 장치가 아닌 중앙 집중식 호스트에 적용되며, 여러 게시 서버에서 애플리케이션을 일관되게 유지하는 것을 간소화할 수 있습니다.

애플리케이션 패키징과 애플리케이션 퍼블리싱은 상호 배타적이지 않습니다: 패키징은 애플리케이션 설치 및 유지 관리를 표준화하고, 퍼블리싱은 접근 방식을 결정합니다. 애플리케이션의 필요에 따라 IT는 한 가지 방법, 다른 방법 또는 두 가지 방법을 조합하여 사용할 수 있습니다.

어떤 경우에 Windows 애플리케이션 패키징을 사용하는 것이 더 좋을까요?

Microsoft Windows 애플리케이션 패키징은 로컬 실행이 유익하고 IT가 애플리케이션이 호스팅되는 장치를 효과적으로 관리할 수 있을 때 가장 적합합니다. 이러한 경우, 설치 및 유지 관리의 표준화를 가능하게 하면서 애플리케이션 실행 위치를 사용자에게 맡깁니다.

사용자는 오프라인 액세스가 필요합니다.

로컬에 설치된 애플리케이션은 중앙 리소스에 접근할 수 없는 경우에도 효과적으로 작동할 수 있으며, 이는 종종 모바일 직원, 현장 근무자 및 기타 유목 근무자에게 해당됩니다.

패키징은 IT 조직이 관리되는 엔드포인트에서 설치, 구성 및 업데이트를 표준화하여 이 접근 방식이 일관되게 사용되도록 보장하는 데 도움을 줍니다.

응용 프로그램은 로컬 하드웨어 또는 처리에 의존합니다.

일부 애플리케이션은 엔드포인트의 리소스에 본질적으로 의존하거나 통합되어 있기 때문에 로컬에서 실행될 때 가장 효과적으로 작동합니다.

로컬 배포는 애플리케이션과 리소스 간의 원격 세션 도입을 피하고, 패키징은 로컬 실행을 지원할 수 있는 엔드포인트에 애플리케이션을 설치하고 구성하는 반복 가능한 방법을 제공합니다.

엔드포인트는 표준화되어 중앙에서 관리됩니다.

패키징은 조직이 이미 제어된 Windows 장치 세트와 이를 관리할 엔드포인트 관리 플랫폼을 보유하고 있는 상황에서도 의미가 있습니다. 환경에 대부분 유사한 장치와 운영 체제가 동일한 구성 수준에 있는 경우, 로컬 애플리케이션 배포 및 관리는 큰 어려움이 없을 수 있습니다.

패키지는 애플리케이션 관리를 위한 체계적인 접근 방식을 제공하여 최종 사용자 장치에 애플리케이션을 설치하고 서비스하는 작업을 더 쉽게 만듭니다. 이 시나리오에서는 중앙 실행을 도입할 필요가 없으며, 실제 비즈니스 필요가 없는 한 추가적인 복잡성을 더할 수 있습니다.

따라서 핵심 질문은 애플리케이션을 패키징할 수 있는지가 아니라 특정 환경과 요구 사항을 고려할 때 모든 대상 장치에 설치하고 업데이트하며 관리하는 것이 가능한지 여부입니다.

애플리케이션 게시가 더 의미 있는 경우는 언제인가요?

애플리케이션 배포는 로컬 설치가 불필요한 운영 또는 호환성 복잡성을 초래할 때 더 바람직해집니다.

여러 가지 전형적인 상황이 고려할 가치가 있습니다.

원격 및 분산 사용자

원격 근무자, 지사 직원 및 계약자는 항상 기업 PC와 같은 잘 관리된 위치나 장치에서 작업하지 않습니다.

애플리케이션 게시를 통해 중앙 서버에 Windows 앱을 보존하면서 허용합니다. 원격 액세스 인증된 사용자에 의해, 따라서 관리자가 모든 원격 장치에서 애플리케이션 환경을 복제하는 부담을 덜어줍니다.

BYOD 및 혼합 엔드포인트 환경

특정 조직이 사용하는 모든 종류의 장치에서 Windows 애플리케이션이 반드시 실행되는 것은 아닙니다.

응용 프로그램을 게시하면 실행 환경이 최종 사용자와 분리됩니다. 이러한 방법을 사용하면 개인이 자신의 기기에서 승인된 브라우저나 클라이언트를 통해 중앙에서 호스팅되는 Windows 앱에 접근할 수 있으며, 그렇지 않으면 해당 응용 프로그램을 실행할 수 없습니다.

이 전략은 BYOD(자기 기기 사용) 및 여러 엔드포인트 운영 체제가 있는 기타 환경 모두에 적합합니다.

레거시 윈도우 애플리케이션

레거시 애플리케이션 운영 체제 의존성, 노후화된 구성 요소 및 어려운 구성 제약에 의존함으로써 배포 노력을 복잡하게 만들 수 있습니다.

애플리케이션을 중앙 집중화하면 IT가 소프트웨어를 작동시키기 위해 필요한 환경을 줄이는 데 도움이 될 수 있습니다. 이것이 반드시 애플리케이션 호환성 문제를 해결하지는 않지만, 이러한 문제를 통제된 Windows 호스트로 제한할 수 있습니다. 대신에 광범위한 엔드포인트 모음이 아닌.

이것은 조직이 장기적인 현대화 계획을 향해 나아가면서 레거시 애플리케이션에 대한 접근을 표준화하는 것을 간소화할 수 있습니다.

자주 업데이트가 필요한 애플리케이션

애플리케이션에 대한 빈번한 변경은 특히 엔드포인트 수가 증가할 때 로컬 배포를 더 어렵게 만듭니다.

애플리케이션 게시를 통해 관리자는 관련 중앙 호스트에서 애플리케이션을 업데이트합니다. 그런 다음 사용자는 모든 엔드포인트에서 소프트웨어를 업데이트할 필요 없이 업데이트된 애플리케이션에 접근합니다.

이 프로세스는 많은 사용자가 동일한 애플리케이션에 의존하지만 로컬에서 사용할 필요가 없을 때 특히 유리합니다.

IT 팀은 패키징과 퍼블리싱 중 어떻게 선택해야 할까요?

IT 팀은 기술 선택보다는 애플리케이션의 운영 요구 사항을 고려해야 합니다.

로컬 설치가 유지 관리하기 쉽고, 엔드포인트가 철저하게 제어되며 사용자가 오프라인 또는 하드웨어 의존 기능이 필요한 경우, 패키지된 엔드포인트 배포가 가장 합리적입니다. 사용자가 분산되어 있고, 엔드포인트가 이질적이며, 로컬 설치가 어려운 경우 또는 애플리케이션을 중앙에서 최신 상태로 유지하는 것이 더 쉬운 경우, 애플리케이션 게시가 엔드포인트 관리 오버헤드를 줄일 수 있습니다.

많은 기업은 두 가지 모델이 모두 필요할 것입니다. 관리되는 데스크톱 사용자는 로컬로 배포된 애플리케이션을 받을 수 있지만, 계약자, 원격 근무자 또는 관리되지 않는 장치를 사용하는 사람들은 특정 비즈니스 소프트웨어에 대한 중앙에서 게시된 액세스를 받을 수 있습니다.

IT가 세 가지 질문을 분리하면 선택이 훨씬 더 명확해집니다.

1. 애플리케이션은 어떻게 패키징하고 유지 관리해야 합니까?
2. 애플리케이션은 어디에 배포되고 실행되어야 합니까?
3. 사용자들은 어떻게 접근해야 하나요?

포장, 배포 및 접근을 별개의 결정으로 바라보는 것은 두 가지 근본적으로 다른 기술을 동일한 솔루션인 것처럼 비교하는 것을 방지합니다.

TSplus Remote Access는 어떻게 해결책이 될 수 있나요?

중앙 집중식 Windows 애플리케이션 배포를 원하지만 모든 엔드포인트에 전체 애플리케이션을 배포하지 않으려는 조직은 사용할 수 있습니다. TSplus 원격 액세스 선택한 Windows 애플리케이션을 게시하거나 중앙 집중식 Windows 인프라에서 전체 원격 데스크톱을 제공하기 위해.

관리자는 특정 사용자 또는 그룹에 애플리케이션을 할당하고 지원되는 원격 클라이언트 또는 브라우저 기반 HTML5 연결을 통해 액세스를 제공할 수 있습니다. 이를 통해 원격 사용자를 지원하는 조직, BYOD 환경 또는 중앙에서 유지 관리하기 쉬운 Windows 애플리케이션에 대한 애플리케이션 게시가 옵션이 됩니다.

결론

Windows 애플리케이션 패키징은 소프트웨어를 설치, 구성 및 유지 관리하는 반복 가능한 방법을 제공하며, 애플리케이션 게시를 통해 사용자는 중앙 집중식 인프라에서 실행되는 애플리케이션에 접근할 수 있습니다. 두 접근 방식은 본질적으로 서로를 대체하지 않으며, 둘 다 동일한 애플리케이션 배포 전략의 일부를 형성할 수 있습니다.

적절한 모델은 애플리케이션 요구 사항, 엔드포인트 관리 및 사용자 접근 필요에 따라 다릅니다. 패키징, 배포 위치 및 접근을 별도로 고려함으로써 IT 팀은 애플리케이션이 로컬, 중앙 또는 두 모델의 조합으로 실행되어야 하는지를 결정할 수 있습니다.