프린터 드라이버 V4: 새로운 프린팅 모델에 대한 완벽 가이드

버전 4 프린터 드라이버는 윈도우의 인쇄 처리 방식을 완전히 바꿔놓았습니다.이는 클라이언트 컴퓨터와 프린트 서버 모두에 적용됩니다. 기존 V3를 점진적으로 대체해 온 이 새로운 모델은 드라이버 설치 방식뿐만 아니라 유지 관리, 호환성, 보안 및 사용자 경험에도 영향을 미치며, 특히 프린터가 많거나 서버에서 프린터를 공유하는 환경에서 이러한 영향이 두드러집니다.

Windows 8 또는 Windows 10을 사용하시는 경우, 윈도우 11 o 최신 Windows ServerV4 드라이버는 이제 우리 일상생활의 일부가 되었지만, 많은 사용자가 그 의미를 완전히 이해하지 못하고 있습니다. 아래에서는 V4 드라이버가 무엇인지, V3 드라이버와 어떻게 다른지, 장점과 한계, 도메인 환경 및 프린트 서버에서의 작동 방식, 그리고 관리자와 개발자가 유의해야 할 사항에 대해 자세하고 명확하게 설명합니다.

V4 프린터 드라이버 모델은 무엇인가요?

V4 프린터 드라이버 모델은 기존 V3 모델의 직접적인 진화형입니다. 이는 윈도우 2000 시대부터 존재해 왔습니다. 마이크로소프트는 윈도우 8과 윈도우 서버 2012부터 이를 도입하면서 드라이버 개발을 간소화하고, IT 관리 비용을 절감하며, 새로운 보안 시나리오와 최신 애플리케이션에 맞춰 인쇄 기능을 준비한다는 명확한 목표를 세웠습니다.

V4 모델은 구조와 철학 면에서 새롭지만이 드라이버는 XPSDrv, GPD 및 PPD 파일, 자동 구성, 양방향 통신(BID) 등 제조업체와 관리자에게 이미 익숙한 기존 기술과의 호환성을 유지합니다. 주요 차이점은 드라이버의 지능적인 기능 대부분이 데이터 파일과 JavaScript에 의존하는 반면, Microsoft는 인쇄 스택의 거의 모든 기능 구성 요소를 제공한다는 점입니다.

V4 컨트롤러의 상위 수준 아키텍처에서이전에는 공급업체별로 특화되어 있던 요소(예: 여러 독점 DLL)는 최소화되었습니다. 마이크로소프트는 대부분의 핵심 구성 요소를 구현하고, 렌더링 필터 및 사용자 지정 인터페이스 애플리케이션을 위한 특정 확장 지점(일반적으로 문서에서 녹색으로 표시됨)은 제조업체에 맡깁니다.

이러한 접근 방식은 파일 충돌, 업데이트 문제 및 아키텍처 간 오류 발생 위험을 크게 줄여줍니다. (x86, x64, ARM) 모두에서 사용 가능합니다. V4 드라이버는 드라이버 스토어에서 직접 실행되며 기존 V3 드라이버보다 훨씬 더 독립적이고 모듈화되어 있기 때문입니다.

V4 컨트롤러가 최적화된 시나리오

V4 모델은 단순히 V3를 "재탕"한 것이 아닙니다.하지만 다양한 시나리오를 생각해 보면... 시간 UWP 애플리케이션, 서버에서 공유되는 인쇄 기능, 드라이버 복잡성 감소, 대규모 환경에서의 기술 지원 개선은 매우 중요해졌습니다.

Windows 8 이상 버전의 경우, 유니버설 윈도우 플랫폼(UWP) 애플리케이션 새로운 인터페이스와 보안 제한 사항을 도입합니다. 앱 사용자 지정 인쇄 기본 설정이나 프린터 관련 알림을 안전하고 제어된 방식으로 표시할 필요가 있습니다. V4 모델은 제조업체가 최신 Windows 보안 모델을 준수하면서 UWP 애플리케이션 내에 사용자 지정 인쇄 환경을 통합할 수 있는 유일한 공식적인 방법입니다.

서버에서 프린터를 공유하는 경우Windows Server V4의 강점 중 하나는 여러 가지 사항을 크게 간소화한다는 점입니다. 목표는 각 프로세서 아키텍처별로 방대한 V3 드라이버 모음을 유지 관리할 필요성을 없애고, 서버가 잠재적으로 문제가 될 수 있는 DLL을 모든 클라이언트에 "푸시"하는 것을 방지하는 것입니다. V4를 사용하면 클라이언트는 PrinterDriverID 식별자를 통해 Windows Update 또는 자체 로컬 저장소에서 필요한 드라이버를 가져올 수 있습니다.

드라이버 개발자에게 있어 V4는 상당한 간소화를 의미합니다.이 모델은 XPSDrv 및 V3 모델에 대한 기존 투자를 기반으로 하지만, 특히 Visual Studio 템플릿과 Windows Driver Kit(WDK)를 사용하면 V4 드라이버를 더 쉽게 생성하고 테스트할 수 있습니다. 일반적인 데스크톱 C++ 워크로드와 내장 GUID 생성 도구를 통해 V4 패키지를 처음부터 훨씬 쉽게 구성할 수 있습니다.

요약하자면, V4는 수년간 축적된 드라이버 데이터베이스의 혼란을 줄이기 위해 설계되었습니다.이전에는 Windows Update를 통해 프린터에 설치되는 드라이버 목록을 확인하는 데 몇 분이 걸렸고, 수많은 구형 모델이 포함되어 있었습니다. 목표는 기존 드라이버를 줄이고, 보다 범용적이고 업데이트가 쉬운 드라이버만 유지하는 것입니다.

V3 및 V4 프린터 드라이버의 주요 차이점

기존 V3 모델은 각 제조업체가 거의 모든 모델에 대해 자체 컨트롤러를 개발하는 방식에 기반을 두고 있었습니다.재사용성이 떨어지는 특수한 DLL 파일들이 대량으로 포함되어 있었습니다. 수년간 이러한 방식은 거의 변하지 않았고, "범용" 드라이버가 등장했지만 여전히 특정 벤더의 독점 파일로 채워져 있었습니다.

그러한 접근 방식의 결과는 방대한 운전자 데이터베이스가 만들어졌다는 것이었다. 이는 끊임없이 증가하면서 설치와 관리 모두를 복잡하게 만들었습니다. Windows Update를 통해 드라이버를 설치하려면 방대한 드라이버 목록을 다운로드해야 했는데, 그중 상당수는 현재 시스템에 더 이상 존재하지 않는 장치용이었습니다.

마이크로소프트는 V4를 통해 운영체제 자체에 포함된 클래스 드라이버에 기대를 걸고 있습니다. 제조사별 V4 드라이버를 사용하지만, 더 깔끔한 아키텍처를 갖추고 있습니다. 클래스 드라이버는 특정 인쇄 언어(예: PCL, PostScript, XPS)를 지원하며, 동일 제품군 내 여러 모델에서 범용적으로 사용됩니다.

이러한 클래스 컨트롤러의 본질적인 단점은 기본적인 기능만 제공한다는 점입니다.컬러 또는 흑백 선택, 표준 용지 크기, 단면 또는 양면 인쇄 등을 선택할 수 있습니다. 고급 복합기 기능(마무리, 스테이플링, 특수 용지함, 통합 스캔 등)을 사용하려면 일반적으로 제조업체에서 제공하는 V4 드라이버를 사용해야 합니다.

그렇기 때문에 Epson, Xerox, Konica Minolta 등 많은 제조업체들이 자체적인 V4 버전을 출시하고 있습니다.이러한 업데이트는 Windows Update 또는 공식 웹사이트에서 직접 다운로드할 수 있습니다. 이러한 방식으로 최신 모델의 장점과 자체 사용자 인터페이스, 그리고 모든 장치별 옵션을 결합하려고 합니다.

XPS 기반 프린팅: V4 드라이버 작동 방식

V4 모델의 또 다른 핵심 특징은 XPS 프린트 경로를 기반으로 한다는 점입니다. (XML 용지 사양). XPS를 기본적으로 이해하는 프린터는 중간 필터 없이 직접 작업을 받을 수 있지만, 그렇지 않은 프린터는 XPS를 자신이 이해하는 언어(PCL, PostScript 등)로 변환해야 합니다.

이 접근 방식은 출력 일관성 및 렌더링 파이프라인 측면에서 분명한 이점을 제공합니다.하지만 이 방식에는 중요한 단점도 있습니다. XPS 작업은 인쇄를 시작하기 전에 완전히 준비되어야 합니다. 인쇄량이 매우 많거나 문서가 복잡한 경우, 이로 인해 프린터가 한동안 멈춰 있는 것처럼 보여 상당한 대기 시간이 발생할 수 있습니다.

XPSDrv 필터 또는 사용자 지정 렌더링 모듈 개발 작업을 하는 분들을 위한 정보입니다.V4 모델은 Visual Studio에서 명확한 확장 지점과 템플릿을 제공하여 DLL 필터와 파이프라인 구성 파일(PipelineConfig.xml) 생성을 간소화합니다. 이러한 구성 요소는 메인 드라이버와 통합되어 XPS 스트림이 프린터에 도달하기 전에 변환하거나 조작합니다.

마이크로소프트의 공식 문서에는 XPSDrv 렌더링 모듈에 대한 자세한 설명이 나와 있습니다. 또한 특정 PDL과의 호환성을 추가하거나, 변환을 적용하거나, 기본 클래스 컨트롤러에는 없는 고급 기능을 구현하기 위해 렌더링 필터를 구성하는 방법도 다룹니다.

V4의 드라이버 배포 및 포인트 앤 프린트 기능

역사적으로 V3 드라이버와 관련된 가장 큰 골칫거리 중 하나는 공유 프린트 서버를 통한 드라이버 배포였습니다.포인트 앤 프린트 기능을 사용하면 클라이언트가 공유 큐에 연결할 때 서버에서 드라이버를 자동으로 다운로드하게 되는데, 이는 결함이 있거나 취약한 DLL이 있는 경우 서버 또는 원격 데스크톱 환경의 모든 사용자에게 영향을 미친다는 것을 의미했습니다.

또한, 인쇄 하위 시스템의 취약점(악명 높은 "PrintNightmare")도 존재합니다. 이에 마이크로소프트는 자동 드라이버 다운로드를 비활성화하고 포인트 앤 프린트에 대한 그룹 정책 개체(GPO)를 강화할 것을 권장했습니다. 이로 인해 관리자는 클라이언트가 서버의 프린터에 연결할 때 드라이버를 설치하는 데 더 많은 권한이 필요하게 되어 상황이 더욱 복잡해졌습니다.

마이크로소프트는 V4 클래스 드라이버를 통해 배포 모델을 재설계하고 있습니다.사용자가 공유 V4 큐에 연결하면 클라이언트는 먼저 PrinterDriverID를 사용하여 로컬 드라이버 저장소에서 일치하는 드라이버를 검색합니다. 드라이버를 찾으면 해당 드라이버를 사용하고, 찾을 수 없으면 서버가 클라이언트 컴퓨터에 DLL 파일을 "삽입"할 필요 없이 Windows Update에서 다운로드를 시도합니다.

적합한 V4 드라이버를 찾을 수 없는 경우 "Microsoft Enhanced Point and Print Driver"를 사용할 수 있습니다.이는 표준적이지만 기능이 제한적인 인터페이스를 제공합니다. 다음과 같은 고객의 경우 운영 체제 V4 큐에 연결되는 구형 프린터의 경우, 일부 제한 사항이 있지만 인쇄를 계속할 수 있도록 하는 "Microsoft Point and Print Enhanced Compatibility Driver"도 있습니다.

중요한 점은 타입 4 프린터 드라이버는 타사 포트 모니터에 연결할 수 없다는 것입니다.이는 특수 포트에 의존하는 솔루션(예: 일부 인쇄 회계 또는 풀 프린팅 소프트웨어)에 영향을 미칩니다. 이러한 경우 모든 것을 V4로 마이그레이션하기 전에 아키텍처를 검토해야 합니다.

Active Directory 및 서버에서 흔히 발생하는 문제: 기능 제한 사례

프린트 서버와 GPO가 있는 기존 Active Directory 환경에서이런 상황은 꽤 흔하게 발생합니다. 제조업체의 V3 드라이버가 단종되고(예: 코니카 미놀타가 특정 V3 드라이버 업데이트를 중단하는 경우), 서버에 "범용" V4 드라이버가 설치되고, 대기 중인 드라이버가 변경되면서 갑자기 사용자의 인쇄 옵션이 매우 제한되는 것입니다.

일반적으로 이러한 경우 서버는 V4 컨트롤러를 사용하는 큐를 하나만 공유합니다.하지만 클라이언트 컴퓨터에는 제조업체의 V4 드라이버 전체 버전이 로컬에 설치되어 있지 않습니다. 따라서 고급 마감 메뉴, 트레이, 고급 색상 설정 등 고급 기능을 사용할 수 없고, 표준 옵션만 사용됩니다. 이러한 기능은 V4 드라이버를 사용자의 PC에 직접 설치했을 때 사용할 수 있습니다.

관리적인 관점에서 볼 때, 각 컴퓨터에 직접 설치를 강제하는 것은 번거로울 수 있습니다.특히 대규모 조직에서 그렇습니다. 많은 관리자는 V3와 같은 동작 방식(클라이언트가 서버에서 드라이버를 다운로드하는 방식)을 기대하지만, V4에서는 드라이버 이름뿐만 아니라 PrinterDriverID를 기준으로 클라이언트 자체 또는 Windows Update에서 드라이버를 다운로드하도록 설계되었습니다.

타사 클라우드 인쇄 관리 솔루션에 의존하지 않고기존 AD 환경에서 이 문제를 해결하는 일반적인 방법은 적절한 드라이버 배포 사례(예: 소프트웨어 관리 도구, 스크립트 또는 설치 GPO 사용)와 PrinterDriverID 및 인쇄 대기열의 올바른 구성을 결합하여 클라이언트가 로컬 V4 드라이버를 공유 프린터와 올바르게 연결할 수 있도록 하는 것입니다.

일부 제조업체와 특정 솔루션(예: 비즈니스 부문의 ThinPrint)이러한 기능은 고가용성 시나리오, 풀 프린팅, 자동 큐 할당 또는 고급 V4 지원을 포함한 추가적인 인쇄 관리 계층을 제공합니다. 필수적인 것은 아니지만, 다양한 모델, 사이트 및 클라이언트 운영 체제가 혼합된 환경을 관리할 때 유용할 수 있습니다.

주요 식별자: CompatibleIDs, PrinterDriverID 및 GUID

V4 모델은 프린터와 드라이버를 연결하기 위해 잘 정의된 식별자에 크게 의존합니다.가장 중요한 두 가지는 CompatibleIDs(클래스 드라이버용)와 PrinterDriverID(드라이버와 공유 큐 간의 관계용)입니다.

CompatibleID는 클래스 드라이버가 나중에 출시된 장치를 지원하는 데 필수적입니다. 해당 장치가 포함된 Windows 버전의 하드웨어 ID를 사용합니다. 완전히 특정한 하드웨어 ID를 사용하는 대신, 장치는 보다 일반적이고 호환 가능한 식별자를 게시하여 시스템이 동일한 인쇄 언어를 사용하는 기존 클래스 드라이버와 연결할 수 있도록 합니다.

병렬 프린터에서 또는 USB이러한 CompatibleID는 일반적으로 1284ID 문자열에 포함됩니다.마이크로소프트에서 새 기기에 권장하는 파일 형식은 다음과 유사합니다. 1284_CID_fabricante_PDL_familia예를 들어 1284_CID_FA_PCL5e_LaserCompatibleIDs가 이미 구현된 경우, 호환성이 깨지지 않도록 유지 관리됩니다.

표준 포트를 사용하는 TCP/IP 장치의 경우 설치 과정에서 CompatibleID는 사용되지 않습니다.이러한 경우 사용자는 보통 드라이버 이름만 보고 선택하는 경우가 많으므로, 제조업체는 자사 웹사이트에 각 드라이버 종류별 모델 호환성 목록을 명확하게 게시하는 것이 좋습니다.

마이크로소프트는 또한 다양한 PDL에 대한 표준 CompatibleID 세트를 정의합니다.이러한 드라이버는 제조사 독립형 클래스 드라이버와 연결되어 있습니다. 예를 들어 XPS, OpenXPS(ECMA-388), PCL6 및 PostScript에 대한 표준 ID가 있습니다. 이러한 표준 드라이버는 일부 기능(Letter 및 A4 용지 크기, 300 및 600dpi 해상도, 일반 용지 종류, 일부 N-up 옵션)만 제공하므로, 이를 사용하는 제조업체는 향상된 구성 및 BIDI를 통해 기능을 보완해야 합니다.

또 다른 중요한 식별자는 PrinterDriverID입니다.이 ID는 프린터를 공유할 때 드라이버 호환성을 확인하고 드라이버와 프린터 확장 프로그램(예: 고급 구성 애플리케이션)을 연결하는 데 사용됩니다. 서버의 공유 프린터가 매니페스트에 PrinterDriverID를 지정하면 클라이언트는 드라이버의 상용 이름과 관계없이 로컬 프린터 저장소와 Windows Update에서 INF 파일에 동일한 PrinterDriverID를 가진 드라이버를 검색합니다.

두 드라이버가 동일한 PrinterDriverID를 공유하려면 두 드라이버가 진정으로 호환되어야 합니다.프린터는 동일한 PDL(프린터 드라이버 ID), 동일한 유형의 구성 파일(GPD 또는 PPD)을 사용해야 하며, 서버 구성 파일에 설명된 기능을 정확하게 표현할 수 있어야 하고, 동일한 프린터 확장 기능을 지원해야 합니다. 스풀러는 이러한 조건을 검증하지 않고 프린터 드라이버 ID에만 의존하므로, 제조업체는 이러한 요소 중 하나라도 변경될 경우 ID를 업데이트해야 합니다.

프린터 확장 기능(예: 사용자 인터페이스의 고급 설정 패널) 이러한 확장 프로그램은 PrinterDriverID를 사용하는 드라이버와도 연관되어 있습니다. 특정 PrinterDriverID를 가리키는 마지막으로 설치된 확장 프로그램은 해당 ID를 공유하는 모든 장치에 적용되므로, 해당 ID를 가진 모든 드라이버는 동일한 확장 프로그램 앱과 호환되어야 합니다.

이러한 모든 식별자를 관리하기 위해 V4는 GUID를 광범위하게 사용합니다. (전역 고유 식별자). 이러한 식별자는 PrinterDriverID, PrinterExtensionID, EventID, ModelID 등에 사용됩니다. Microsoft는 충돌을 일으킬 수 있는 복사 붙여넣기 방식 대신 Visual Studio 또는 SDK와 같은 도구를 사용하여 이러한 식별자를 생성하는 것을 강력히 권장합니다.

구성 동작: 큐, 이름 및 개발 노드

V4 모델에서는 프린터의 이름 지정 및 그룹화 방식도 변경됩니다.Windows는 물리적 플러그 앤 플레이, 가상 프린터 또는 네트워크 장치 연결 등 모든 대기열에 대해 소프트웨어 장치 노드(devnode)를 생성하여 "장치 및 프린터"에서 통합적으로 관리할 수 있도록 합니다.

V3 드라이버에서 큐 이름은 주로 드라이버 이름과 사용자가 입력한 내용에 따라 달라졌습니다.V4 및 클래스 컨트롤러의 경우 해당 이름은 사용자에게 제공하는 정보가 부족하므로 Windows는 QR 코드를 통해 장치에 쿼리하여 사용자가 더 쉽게 이해할 수 있는 이름을 얻으려고 합니다.

일반적인 과정은 다음과 같습니다.먼저 드라이버 이름이 큐에 할당됩니다. 드라이버가 V4 버전인 경우 Windows는 장치에서 \\Printer.DeviceInfo:FriendlyName을 조회합니다. 해당 정보가 있으면 이를 큐 이름으로 사용합니다. 그렇지 않으면 \\Printer.DeviceInfo:Manufacturer와 \\Printer.DeviceInfo:ModelName을 조합하여 사용하려고 시도합니다. BIDI 통신에 실패하면 시스템은 IEEE 1284 ID 문자열을 사용하며, 이마저도 실패하면 MANUFACTURER/MFG와 MODEL/MDL의 조합을 사용합니다.

다기능 기기들을 하나의 아이콘으로 그룹화 이는 동일한 컨테이너 식별자를 공유하는 것에 의존합니다. 큐의 포트가 변경되면(예: WSD에서 TCP/IP 또는 독자적인 포트로 변경) 해당 큐의 개발 노드와 연결된 컨테이너도 변경되므로, 장치의 다른 PnP 기능과의 그룹화가 손실될 수 있습니다.

IT 관리 시나리오에서 관리자는 WS-Discovery를 사용하여 프린터를 검색할 수 있습니다.그런 다음 관리 기본 설정에서 포트를 TCP/IP로 변경하면 장치 및 프린터 폴더에 "장치"가 두 개 표시됩니다. 해결 방법은 기존 PnP devnode를 제거하거나 컨테이너 식별자를 조정하여 아이콘이 하나만 남도록 하는 것입니다.

제조업체 설치 환경에서 자체 포트 모니터를 사용하는 경우(V3에서만 허용)비슷한 상황이 발생할 수 있습니다. 설치 마법사가 큐 포트를 사용자 지정 포트로 변경하는 경우, 프로그램은 PnP 개발 노드를 유지하고 컨테이너 식별자를 조정할지, 아니면 초기 물리적 장치를 제거하여 해당 포트와 연결된 큐만 남길지 결정해야 합니다.