WireGuard의 윈도우 릴리스가 늦어진 진짜 이유, 코드 서명이라는 보이지 않는 벽

VPN 하면 떠오르는 이름이 몇 개 있습니다. 그중에서도 WireGuard는 간결한 코드베이스와 현대적인 암호화 설계로 보안 커뮤니티의 신뢰를 받아온 오픈소스 프로젝트입니다. 그런데 이 프로젝트가 윈도우 버전을 릴리스하는 데 예상보다 훨씬 긴 시간이 걸렸습니다. 코드 품질 문제가 아니었습니다. 문제는 마이크로소프트의 코드 서명 인프라였습니다.

커널 드라이버에는 서명이 필요하다

WireGuard가 윈도우에서 제대로 동작하려면 커널 레벨 네트워크 드라이버가 필요합니다. 윈도우 10 이후부터 마이크로소프트는 커널 모드 드라이버에 대해 WHQL(Windows Hardware Quality Labs) 서명 또는 Attestation 서명을 요구하고 있습니다. 자체 코드 서명 인증서만으로는 부족합니다. 마이크로소프트의 파트너 센터를 통해 직접 승인을 받아야 하는 구조입니다.

상용 기업이라면 전담 팀이 이 프로세스를 처리합니다. 하지만 소규모 오픈소스 프로젝트에게 이 과정은 상당한 부담입니다. EV(Extended Validation) 코드 서명 인증서 취득부터 마이크로소프트 파트너 계정 설정, 드라이버 제출과 검증까지. 기술적 난이도보다 행정적·절차적 장벽이 더 높은 셈입니다.

WireGuard가 겪은 구체적인 문제

WireGuard의 윈도우 클라이언트인 wintun 드라이버는 이 서명 요구사항의 직접적인 영향을 받았습니다. 프로젝트 메인테이너 Jason Donenfeld는 마이크로소프트의 서명 인프라가 변경되거나 정책이 바뀔 때마다 릴리스 파이프라인이 멈추는 상황을 반복적으로 경험했습니다.

특히 마이크로소프트가 크로스 서명(cross-signing) 정책을 폐지하고 Attestation 서명으로 전환하는 과정에서 혼란이 가중되었습니다. 기존에 동작하던 서명 방식이 갑자기 무효화되고, 새로운 방식의 문서화는 불충분하며, 파트너 센터의 승인 과정은 예측 불가능한 시간이 걸렸습니다. 코드는 이미 완성되어 있는데 배포할 수 없는 상태가 되는 것입니다.

오픈소스의 구조적 딜레마

이 문제는 WireGuard만의 이야기가 아닙니다. 윈도우 생태계에서 커널 레벨 접근이 필요한 모든 오픈소스 보안 도구가 같은 벽에 부딪힙니다. 방화벽, 디스크 암호화, 네트워크 모니터링 도구 등이 모두 해당됩니다.

핵심은 정보 비대칭입니다. 마이크로소프트는 자사 플랫폼의 서명 정책을 언제든 변경할 수 있습니다. 대형 파트너사에게는 사전 공지와 마이그레이션 지원이 제공되지만, 소규모 오픈소스 프로젝트는 정책 변경 사실조차 늦게 파악하는 경우가 많습니다.

결과적으로 오픈소스 보안 도구의 윈도우 릴리스는 코드 완성도가 아니라 플랫폼 벤더의 인프라 상태에 의해 결정됩니다. 이것은 소프트웨어 공급망의 숨겨진 병목입니다.

리눅스와의 대조적인 차이

같은 WireGuard가 리눅스에서는 완전히 다른 경험을 제공합니다. 리눅스 커널 5.6부터 WireGuard는 커널 트리에 직접 포함되어 있습니다. 별도의 서명 절차도, 외부 승인도 필요 없습니다. 커널 메인라인에 머지되면 모든 배포판에서 자동으로 사용할 수 있습니다.

이 차이가 보여주는 것은 명확합니다. 오픈소스 프로젝트의 배포 용이성은 코드 품질만으로 결정되지 않습니다. 플랫폼이 오픈소스 생태계를 어떻게 대우하느냐가 실질적인 차이를 만듭니다. 리눅스는 오픈소스 도구에게 문을 열어두고, 윈도우는 통제된 게이트를 통과하도록 요구합니다.

이것이 사용자에게 의미하는 것

일반 사용자 입장에서 WireGuard 윈도우 클라이언트가 며칠 늦게 나오는 것은 큰 불편이 아닐 수 있습니다. 하지만 더 넓은 시각에서 보면, 우리가 매일 사용하는 보안 도구들이 특정 기업의 인프라 정책에 취약하다는 뜻입니다.

최근 XZ Utils 백도어 사건이나 CPU-Z 사이트 하이재킹 같은 공급망 공격이 연이어 터지면서, 소프트웨어 공급망 보안에 대한 관심이 그 어느 때보다 높아졌습니다. 그런데 정작 보안 도구 자체의 배포 파이프라인이 폐쇄적 플랫폼에 종속되어 있다면, 이 역시 하나의 공급망 리스크입니다.

WireGuard 팀은 결국 이 문제를 해결하고 윈도우 릴리스를 정상화했습니다. 하지만 근본적인 구조는 바뀌지 않았습니다. 다음에 마이크로소프트가 서명 정책을 변경하면 같은 일이 반복될 수 있습니다. 오픈소스 보안 도구가 상용 플랫폼 위에서 살아남으려면, 코드를 잘 짜는 것만으로는 부족한 시대입니다. 여러분이 사용하는 보안 도구는, 과연 누구의 허락을 받아야 여러분에게 도달할 수 있을까요?