App-V: 기업용 애플리케이션 가상화에 대한 완벽 가이드

App-V를 이용한 애플리케이션 가상화는 수년간 많은 기업의 Windows 인프라에서 핵심적인 구성 요소 였습니다 . 마이크로소프트는 이미 지원 종료일을 정했지만, 레거시 애플리케이션을 유지 관리하고, 프로그램 충돌을 줄이며, 소프트웨어 관리를 최대한 간소화해야 하는 기업에서는 여전히 널리 사용되는 기술입니다.

Windows 10 또는 Windows 11 시스템을 관리하거나 Citrix 또는 VDI를 사용하여 원격 환경을 관리하는 경우 App-V의 작동 방식, 구성 요소 및 다른 가상화 솔루션과의 통합 방식을 확실히 이해하는 것이 필수적입니다. 또한 2026년 예정된 App-V 지원 종료 시점을 염두에 두고 Azure Virtual Desktop (MSIX 앱 연결 포함) 또는 타사 플랫폼 과 같은 대안을 숙지하는 것도 중요합니다 .

App-V란 무엇이며 비즈니스 환경에서 어떻게 사용됩니까?

Microsoft Application Virtualization( Microsoft App-V )은 특정 Windows 엔터프라이즈 에디션에 포함된 구성 요소로, Win32 애플리케이션을 운영 체제와 분리할 수 있도록 합니다. 기존처럼 각 컴퓨터에 프로그램을 "설치"하는 대신, 애플리케이션을 패키징하여 격리된 환경에서 실행하고 중앙 집중식 인프라를 통해 사용자에게 제공합니다.

사용자는 마치 애플리케이션이 로컬에 설치된 것처럼 바로 가기, 아이콘 및 파일 연결을 볼 수 있지만, 실제로는 App-V 클라이언트만 컴퓨터에 영구적으로 상주합니다 . 이 애플리케이션은 클라이언트 자체에서 관리하는 샌드박스 에서 실행되므로 호스트 운영 체제에 미치는 영향을 크게 줄이고 다른 애플리케이션과의 충돌을 최소화합니다.

App-V의 주요 장점 중 하나는 동일한 소프트웨어의 여러 버전을 동시에 실행할 수 있다는 점입니다 (예: 여러 버전의 Office 또는 웹 브라우저). 또한 기본적으로 호환되지 않는 애플리케이션도 같은 시스템에서 실행할 수 있습니다. 뿐만 아니라 Windows 7 또는 Windows XP용으로 설계된 기존 소프트웨어를 Windows 10 또는 11을 실행하는 최신 컴퓨터에서 계속 사용할 수 있게 해줍니다 .

하지만 App-V는 윈도우 생태계에만 초점을 맞춘 기술로, iOS, 안드로이드, macOS 또는 ChromeOS를 실행하는 기기에서는 작동하지 않습니다 . 진정한 크로스 플랫폼 액세스가 필요한 조직의 경우 App-V는 다른 애플리케이션 게시 또는 가상화 기술과 함께 사용해야 합니다.

App-V 기본 아키텍처 및 전체 인프라

일반적인 기업 환경에서는 App-V 서버, App-V 클라이언트, App-V 시퀀서라는 세 가지 주요 도구가 유기적으로 연동하여 작동하는 App-V 완전 인프라 (App-V Complete Infrastructure)를 사용합니다. 이전 버전에서는 SoftGrid 브랜드로 이와 매우 유사한 구성 요소(서버, 클라이언트, 시퀀서)를 제공하는 개념이 이미 존재했습니다.

App-V 서버는 일반적으로 관리 및 게시 서버로 배포됩니다. 가상화된 애플리케이션 패키지, 연결 그룹 및 액세스 권한을 관리합니다. 구성 정보를 저장하기 위해 SQL Server 데이터베이스를 사용하고 사용자 및 컴퓨터 권한 관리를 위해 Active Directory 그룹을 사용하는 것이 일반적입니다.

이 서버 계층 내에는 여러 블록이 있습니다. 패키지, 연결 그룹 및 권한을 관리하는 콘솔이 있는 관리 서버 자체 , 스트리밍을 통해 App-V 클라이언트에 애플리케이션을 제공하는 게시 서버 , 그리고 누가 어떤 애플리케이션을 사용할 수 있는지, 서버 간 동기화 방식이 기록되는 관리 데이터베이스가 그것입니다.

App-V 클라이언트 는 Citrix 환경 및 가상 데스크톱 의 최종 사용자 컴퓨터 또는 VDA(가상 배포 에이전트)에 설치되는 에이전트입니다 . 이 클라이언트는 패키지를 다운로드하고, 가상 런타임 환경을 생성하고, 아이콘 및 바로 가기를 게시하고 , 사용자별 구성(레지스트리 변경 사항, 사용자 파일 등)을 저장하는 역할을 합니다 .

마지막으로, App-V 시퀀서는 애플리케이션의 가상 패키지를 생성하는 데 사용되는 도구입니다. 이 도구는 참조 머신에서 기존 소프트웨어 설치 과정을 관찰하고, 관련된 모든 파일, 레지스트리 항목, 라이브러리 및 구성을 캡처하여 App-V 패키지 형식으로 캡슐화합니다. 일반적으로 이 패키지에는 독립 실행형 배포를 위한 MSI 파일이 함께 제공됩니다.

App-V를 사용한 애플리케이션 시퀀싱 프로세스

회사에서 App-V를 본격적으로 사용하기 위한 첫 번째 단계는 가상화할 애플리케이션의 순서를 정하는 것 입니다 . 이를 위해서는 최종 사용자가 사용할 환경과 유사한 깨끗한 레퍼런스 머신을 준비하고, 그 위에 App-V 시퀀서를 설치해야 합니다.

MCSE 프라이빗 클라우드 과정에서 설명하는 것과 같은 교육 또는 실험실 환경에서는 일반적으로 시퀀싱할 애플리케이션의 오프라인 버전을 다운로드하고, 공유 저장소 (예: VMM/ApplicationFrameworks 폴더)에서 시퀀싱 프로그램을 설치한 다음 마법사의 기본 설정을 그대로 사용하는 것이 일반적입니다.

시퀀서가 실행되면 단계별 마법사가 나타나 캡처 프로세스를 안내합니다. 이 과정에서 조직의 모범 사례에 따라 애플리케이션의 설치 경로를 사용자 지정하는 것이 중요합니다 . 그래야 최종 패키지가 최대한 표준화되고 유지 관리가 용이해집니다.

시퀀싱 환경에서 설치가 완료되면, 해당 도구는 수정된 파일과 레지스트리 키를 분석하고, App-V 패키지, 독립 실행형 MSI 파일(해당되는 경우), 그리고 관련 동적 구성 파일을 생성합니다. 이러한 파일들은 일반적으로 중앙 라이브러리(예: VMM 라이브러리 또는 네트워크 공유)에 있는 폴더에 저장됩니다.

해당 패키지를 프로덕션 가상 머신에서 실행하려면 가상 머신에 App-V 클라이언트가 설치되어 있어야 합니다 . 이 에이전트가 없으면 시스템에서 패키지를 해석하거나 필요한 가상 런타임 환경을 생성할 수 없습니다.

App-V의 고급 아키텍처, 게시 및 관리 서버

중대형 기업 환경에서 App-V 관리 서버는 일반적으로 단일의 독립적인 머신이 아니라 확장 가능하고 가용성이 높은 아키텍처 내의 구성 요소 중 하나입니다 . 네트워크 로드 밸런서 뒤에 여러 관리 서버를 배포하고 모두 동일한 SQL 데이터베이스를 공유하는 것이 일반적입니다.

게시 서버는 여러 인스턴스를 통해 확장할 수 있으며, HTTP 또는 HTTPS를 통해 가상 애플리케이션 패키지를 호스팅하고 스트리밍할 수 있습니다. 이 경우 각 게시 서버는 App-V 클라이언트의 요청을 처리하고 관리 서버 또는 UNC 경로에서 필요한 패키지를 검색합니다.

한편, App-V 클라이언트는 가상화된 애플리케이션을 실행해야 하는 모든 시스템에 배포됩니다. 여기에는 Windows 10 또는 11이 설치된 물리적 PC부터 원격 데스크톱, 원격 데스크톱 서버, Citrix 환경의 VDA 에이전트까지 포함됩니다. Windows 10 Enterprise(버전 1607 이상) 및 Windows Server 2016에서는 클라이언트가 기본적으로 포함되어 있으며, PowerShell cmdlet인 Enable-AppV를 사용하여 활성화하고 Get-AppVStatus를 사용하여 상태를 확인할 수 있습니다.

App-V 패키지에 포함된 스크립트가 올바르게 작동하려면 Microsoft는 Get-AppvClientConfiguration을 사용하여 클라이언트 구성을 확인하고 EnablePackageScripts 매개변수가 활성화되어 있는지 확인하는 것이 좋습니다. 활성화되어 있지 않은 경우 Set-AppvClientConfiguration -EnablePackageScripts $true 명령을 사용하여 수정할 수 있습니다.

역사적으로 이 아키텍처는 이미 애플리케이션 서버, 클라이언트 및 관리 콘솔을 포함하고 있던 SoftGrid에서 파생되었습니다 . SoftGrid는 가상화된 리소스 사용을 가로채고 리디렉션하는 샌드박스인 SystemGuard와 애플리케이션 패키징을 담당하는 시퀀서와 같은 구성 요소를 도입했는데, App-V는 이러한 개념들을 직접 계승했습니다.

App-V 라이선스 및 서비스 종료일

비즈니스 관점에서 중요한 점 중 하나는 App-V의 라이선스 방식입니다. Windows 10부터 App-V는 특정 기업용 에디션(예: Windows 10 Enterprise)에 추가 비용 없이 포함되어 있지만 , 사용에는 특정 라이선스 계약이 적용됩니다.

클라이언트 시스템에서 App-V 사용 권한은 일반적으로 사용자별 라이선스가 부여되는 Microsoft Desktop Optimization Pack(MDOP)을 통해 획득합니다 . 원격 데스크톱 서비스(RDS) 시나리오에서는 App-V가 RDS CAL에 포함되므로 가상화된 애플리케이션에 액세스하는 각 사용자 또는 장치는 적절한 라이선스를 보유해야 합니다.

계획 수립 시 중요한 사항: Microsoft는 App-V의 지원 종료를 2026년 4월로 발표했습니다. 즉, 해당 날짜 이후에는 새로운 업데이트나 공식 지원이 제공되지 않으며, MSIX 앱 연결을 사용하는 Azure Virtual Desktop으로 마이그레이션하는 것이 좋습니다.

MSIX는 마이크로소프트가 App-V를 대체할 새로운 패키징 형식으로 홍보하고 있습니다. 이는 Win32, WPF 및 Windows Forms 애플리케이션의 설치, 업데이트 및 유지 관리 환경을 통합하는 동시에 고급 배포 및 격리 기능을 제공합니다. App-V에 많은 투자를 한 기업의 경우, 마이그레이션 과정에서 어떤 패키지를 MSIX로 재패키징할 수 있는지, 어떤 패키지는 다른 전략이 필요한지 평가하는 것이 중요한 과제가 될 것입니다.

Citrix Virtual Apps and Desktops 환경에서 App-V 사용하기

Citrix Virtual Apps and Desktops(CVAD)가 애플리케이션 및 데스크톱 제공 플랫폼으로 사용되는 시나리오에서 App-V는 종종 추가적인 애플리케이션 가상화 계층 으로 사용됩니다 . Citrix는 App-V와 상당히 긴밀한 통합을 제공하여 App-V 서버와 네트워크 공유 모두에서 패키지를 관리할 수 있도록 합니다.

이러한 통합 과정에서 이중 관리 와 단일 관리 의 개념을 이해하는 것이 중요합니다 . 이중 관리 모드에서 Studio는 권한, 연결 그룹 및 동적 구성 파일 관리를 담당하는 App-V 관리 및 게시 서버와 연동합니다.

이 접근 방식은 App-V 인프라(서버, 데이터베이스, AD 권한, 원격 PowerShell 등)에 크게 의존하지만, 조직에서 이미 잘 구축된 App-V 환경을 Citrix 환경에서 재사용하고자 할 때 이상적입니다. Studio와 App-V 서버는 특히 보안 그룹 및 애플리케이션 할당과 관련하여 동기화되어야 합니다.

반면 단일 관리 방식에서는 App-V 패키지가 VDA 및 Studio 관리자가 액세스할 수 있는 네트워크 공유(UNC/SMB) 에 저장됩니다 . Citrix는 이러한 패키지를 "애플리케이션 라이브러리"로 직접 가져와 온보딩, 게시, 업데이트 및 삭제를 포함한 전체 수명 주기를 관리합니다.

단일 관리 방식은 App-V 관리 서버와 해당 데이터베이스에 대한 의존성을 제거하여 인프라 복잡성을 크게 줄입니다. 대신, 각 VDA에 App-V 클라이언트를 설치해야 하며 동적 구성 파일 및 격리 그룹 관리는 Citrix에 위임됩니다.

Citrix에서 Studio 및 App-V 서버 설정하기

이중 관리 모드를 선택하는 경우 App-V 관리 서버와 게시 서버 의 위치를 ​​Citrix에 알려야 합니다 . 이 작업은 Citrix 사이트 생성 중에 수행하거나 나중에 Studio의 설정 > App-V 게시 섹션에서 수행할 수 있습니다.

이러한 서버를 구성할 때 관리 서버와 게시 서버의 URL(포트 포함)을 지정하고 마법사 내에서 연결을 테스트합니다. 이 테스트가 제대로 작동하려면 Studio 관리자가 App-V 서버의 관리자 그룹 구성원이어야 하고 , 원격 PowerShell이 ​​활성화되어 있어야 하며, 파일 공유가 정상적으로 작동해야 합니다.

언제든지 기존 App-V 인프라에 대한 의존도를 낮추려는 경우, Studio를 사용하면 관리 및 게시 서버에 대한 참조를 제거할 수 있습니다 . 단, 해당 소스에서 활발하게 게시되고 있는 App-V 애플리케이션이 없어야 합니다. 이렇게 하기 전에 해당 애플리케이션을 관련 배포 그룹에서 제거해야 합니다.

반면, Studio는 단일 관리 모드에서 작업할 때 네트워크 공유에서 패키지를 가져오는 도구를 제공합니다 . 관리자는 App-V 패키지가 있는 UNC 경로로 이동하여 하나 이상의 패키지를 선택하고 Citrix 애플리케이션 라이브러리에 추가한 다음, 해당 패키지를 관련 배포 그룹에 할당할 수 있습니다.

단일 방식과 이중 방식 모두에서 Citrix는 공유 리소스에 "인증된 사용자"가 최소한 읽기 권한을 갖도록 요구하여 컨트롤러와 VDA 모두 패키지 및 관련 구성 파일에 액세스할 수 있도록 합니다.

동적 구성 파일, 격리 그룹 및 로드 밸런싱

App-V 동적 구성 파일을 사용 하면 기본 패키지를 수정하지 않고도 가상화된 애플리케이션의 동작을 사용자 지정할 수 있습니다 . 이러한 파일에는 두 가지 유형이 있습니다. 모든 사용자에게 시스템 수준 설정을 적용하는 DeploymentConfig 파일과 사용자의 SID 또는 Active Directory 그룹에 특정한 사용자 지정을 위해 설계된 UserConfig 파일입니다.

Citrix 통합 환경에서 이러한 파일은 일반적으로 App-V 패키지와 동일한 폴더에 있습니다. 단일 관리 환경에서 Citrix 구성 요소는 DeploymentConfig 파일 과 선택적으로 UserConfig 파일을 처리하며, 이 파일들은 사용자 또는 그룹의 SID 또는 이름을 포함하는 특정 명명 규칙을 따릅니다. 동일한 패키지에 대해 여러 파일이 있는 경우, 사용자 SID, 사용자 이름, 그룹 SID, 그룹 이름, 그리고 마지막으로 기본값 순으로 우선순위가 적용됩니다.

패키지에 구성 파일이 포함되어 있지 않은 경우, 패키지의 GUID와 파일 경로를 연결하는 매핑 파일(ctxAppVDynamicConfigurations.cfg)을 사용할 수 있습니다 . 이 파일은 패키지와 동일한 UNC 계층 구조에 배치되며, Citrix 구성 요소는 애플리케이션이 시작될 때 이 파일을 재귀적으로 스캔합니다.

단일 관리 모드에서 또 다른 핵심 개념은 Citrix에서 관리하는 App-V 격리 그룹 입니다 . 이는 상호 의존적인 패키지 집합으로, 동일한 샌드박스를 공유해야 합니다(예: 특정 런타임 또는 플러그인이 필요한 애플리케이션). Citrix는 패키지가 기본 애플리케이션 시작 시 항상 포함되는지, 아니면 동일한 배포 그룹에 명시적으로 추가된 경우에만 포함되는지를 나타내기 위해 "자동"과 "명시적"이라는 용어를 사용합니다.

실제로 이러한 방식은 다음과 같은 시나리오를 가능하게 합니다. 애플리케이션 A는 Java JRE 1.7을 필요로 하지만, 해당 JRE는 샌드박스 내에서만 사용 가능해야 합니다. 격리 그룹은 애플리케이션 A를 명시적으로 정의하고 JRE 1.7을 자동으로 포함하도록 설정합니다. 사용자가 애플리케이션 A를 실행하면 런타임이 다운로드되어 별도의 애플리케이션으로 게시할 필요 없이 가상 환경에 통합됩니다 .

App-V 서버의 로드 밸런싱 과 관련하여 관리 서버와 게시 서버에 대해 듀얼 모드에서 라운드 로빈 DNS를 사용할 수 있습니다. 그러나 Studio와의 통신이 원격 PowerShell에 의존하는 경우, 관리 서버를 특정 로드 밸런싱 솔루션(NetScaler, F5 등) 뒤에 배치하는 것은 지원되지 않으므로 신중한 토폴로지 계획이 필요합니다.

App-V와 다른 애플리케이션 가상화 기술 비교

사용자가 로컬에 설치하지 않고 애플리케이션을 이용할 수 있도록 하는 다양한 방식이 시중에 나와 있지만, 모든 방식이 동일한 성능을 제공하는 것은 아닙니다. App-V는 마이크로소프트 생태계 내에서 이미 운영되고 있는 기업 환경에 초점을 맞춘 네이티브 Windows 애플리케이션 가상화 방식에 속합니다.

기존 컨테이너화 방식(예: Docker)과 달리 App-V는 전체 파일 시스템이나 운영 체제 라이브러리를 패키징하지 않습니다. 대신, 기본 Windows 운영 체제를 활용하고 자체 가상화 계층을 사용하여 애플리케이션을 격리합니다 . 이는 Windows 관리자에게 여러 가지 이점을 제공하지만, 적용 범위가 해당 플랫폼으로 제한된다는 단점도 있습니다.

다른 애플리케이션 가상화 및 게시 솔루션을 살펴보면 Citrix Virtual Apps , VMware Horizon Apps, Amazon AppStream 2.0과 같은 옵션이 있습니다. 이러한 솔루션의 상당수는 게시된 애플리케이션을 제공하기 위해 내부적으로 RDS(원격 데스크톱 서비스)에 의존하므로 RDS와 관련된 복잡성과 라이선스 비용을 계속해서 부담해야 합니다.

GO-Global과 같이 RDS를 완전히 대체하려는 솔루션도 있습니다. GO-Global은 자체 멀티 세션 코어, 통신 프로토콜 및 관리 도구를 구현하여 특정 클라이언트 없이도 모든 클라우드에서 거의 모든 브라우저 지원 장치로 Windows 애플리케이션을 제공할 수 있도록 합니다.

어쨌든 App-V의 역할은 일반적으로 매우 구체적입니다. 즉, 기업이 기존 애플리케이션을 유지 관리하고, 충돌을 관리하며, 확립된 Windows 환경 내에서 대규모 배포를 용이하게 하는 것입니다. 다양한 장치를 사용하는 고객에게 서비스를 제공하려는 ISV의 경우 App-V는 부족할 수 있으며, 종종 다른 원격 액세스 또는 웹 게시 기술과 함께 사용됩니다.

App-V를 비롯한 다양한 플랫폼을 이용한 애플리케이션 가상화는 항상 동일한 원칙에 기반합니다. 바로 추상화 계층을 사용하여 애플리케이션을 호스트 운영 체제로부터 분리하는 것입니다. 이 계층은 리소스 호출(파일, 레지스트리, 서비스 등)을 가로채어 격리된 환경 또는 샌드박스 로 리디렉션함으로써 애플리케이션이 시스템을 "혼잡하게" 만들거나 다른 설치된 프로그램과 충돌하는 것을 방지합니다.

가상화 전략에서 App-V의 활용 사례 및 미래 전망

App-V는 여러 개의 잠재적으로 충돌하는 기존 Windows 애플리케이션을 Windows 장치를 사용하는 사용자에게 제공해야 하는 조직에서 특히 뛰어난 성능을 발휘합니다. 대규모 기업 환경, 고등 교육 기관 또는 매우 오래되었지만 핵심 업무에 필수적인 애플리케이션을 관리하는 기업에 적합한 솔루션입니다.

다양한 기기를 사용하는 최종 고객에게 단 한두 개의 애플리케이션만 배포하는 ISV(독립 소프트웨어 공급업체)의 경우, App-V는 상당한 장벽이 됩니다. App-V는 Windows 운영 체제를 사용하는 사용자에게만 서비스를 제공 하고 Microsoft와의 계약에 따라 사용자별 또는 기기별 라이선스를 요구하기 때문입니다. 이러한 경우에는 웹 게시 솔루션, 경량 VDI 또는 전용 애플리케이션 스트리밍 도구가 더 매력적인 선택이 될 수 있습니다.

2026년 4월 지원 종료 예정일로 인해 많은 기업들이 로드맵을 재고하고 있습니다. 마이크로소프트는 애플리케이션 배포 로직을 Azure 클라우드로 이전하고 패키징을 현대화하는 MSIX와 결합된 Azure Virtual Desktop을 고객들에게 권장하고 있습니다 . 하지만 이러한 마이그레이션은 자동으로 이루어지지 않으며, 테스트, 재패키징, 호환성 조정, 심지어는 아주 오래된 애플리케이션의 재설계까지 필요할 것입니다.

이와 병행하여 Hyper-V, VMware vSphere, Proxmox VE 또는 Citrix Hypervisor 와 같은 하이퍼바이저 기반의 다른 가상화 및 애플리케이션 게시 옵션도 인프라 계층에 초점을 맞춰 계속 사용할 수 있습니다. 각 조직의 요구 사항에 따라 이러한 기반 위에서 가상 데스크톱, DaaS 솔루션 또는 추가적인 애플리케이션 가상화 계층을 실행할 수 있습니다.

결론적으로, App-V는 많은 기업이 보다 유연하고 중앙 집중화되고 관리하기 쉬운 IT 모델 로 전환하는 데 중추적인 역할을 해왔습니다 . App-V의 수명 주기가 막바지에 접어들었음에도 불구하고, 그 작동 방식, 해결하는 문제, 그리고 다른 솔루션과의 통합 방식을 이해하는 것은 차세대 가상화 아키텍처와 Windows 환경에서의 애플리케이션 제공 방식을 설계하는 데 여전히 매우 중요합니다.