Q27. PQC 때문에 SSL VPN을 지금 교체해야 하나요?

A. 아닙니다. SSL VPN이 중요하다는 사실과 지금 PQC VPN 제품을 도입해야 한다는 결론은 전혀 다릅니다.

핵심 답변

• 일반적인 SSL VPN은 PQC 때문에 지금 교체할 이유가 없습니다.
• 우선순위는 VPN 제품명이 아니라 사용자·접속 대상·권한·데이터 수명으로 정해야 합니다.
• OpenVPN에서 PQC 영향은 주로 TLS 제어 채널의 키 합의와 인증서·PKI 영역이며, 데이터 채널의 AES-GCM·ChaCha20-Poly1305는 직접 교체 대상이 아닙니다.
• OpenVPN 2.7과 OpenSSL 3.5 LTS 조합은 X25519MLKEM768을 지원할 수 있는 기반을 이미 제공하므로, 먼저 할 일은 신규 제품 구매가 아니라 업그레이드와 상호운용성 검증입니다.

SSL VPN은 외부 사용자가 내부 시스템에 접근하는 중요한 접점입니다.

그래서 사용자 인증, MFA, 단말 상태 검증, 최소 권한, 접속 로그, 세션 통제는 중요합니다.

하지만 이것은 PQC가 등장해서 새로 중요해진 문제가 아닙니다.

계정 탈취, VPN 장비 취약점, 관리자 페이지 노출, 감염된 단말, 과도한 권한, 접속 이후 가시성 부족은 지금도 실제 사고를 만드는 문제입니다.

그런데 최근 PQC 논의에서는 다음과 같은 흐름이 나타납니다.

PQC가 필요하다
→ VPN은 공개키 암호를 사용한다
→ SSL VPN은 외부 접속의 핵심 관문이다
→ 따라서 PQC SSL VPN을 지금 도입해야 한다
→ SWG까지 함께 구축해야 한다

앞의 두 문장은 맞을 수 있습니다.

하지만 뒤의 결론은 자동으로 따라오지 않습니다.

2026년 7월 22일 보도된 수산아이앤티 관련 기사도 PQC 전환과 함께 SSL VPN과 SWG 기반의 ‘접속 보안’ 전략이 중요해질 것이라고 설명합니다. 기사에는 공개키 암호 사용처 식별, 하이브리드 PQC 기반 TLS 키 교환, 단계적 전환이라는 타당한 내용이 있습니다. 동시에 자사 eWalker SSL VPN과 eWalker SWG를 PQC 시대의 핵심 플랫폼으로 연결하는 제품 전략도 함께 제시됩니다.¹

여기서 기술과 마케팅을 분리해야 합니다.

SSL VPN이 중요한 것과 PQC SSL VPN 제품을 지금 구매해야 하는 것은 다른 이야기입니다.

PQC 관점에서 VPN의 우선순위를 결정하는 것은 제품명이 아닙니다.

다음 질문이 먼저입니다.

누가 접속하는가?
어떤 시스템에 접속하는가?
VPN 터널로 어떤 데이터가 흐르는가?
그 데이터는 10년, 20년 뒤에도 가치가 있는가?
공격자가 지금 그 트래픽을 현실적으로 수집할 수 있는가?
현재 VPN의 더 직접적인 위험은 제대로 통제되고 있는가?

일반 임직원이 웹메일과 사내 그룹웨어에 접속하는 VPN과, 국가 핵심기술 연구소 관리자가 장기 기밀자료 저장소에 접속하는 VPN은 같은 PQC 우선순위를 가질 수 없습니다.

OpenVPN도 마찬가지입니다.

OpenVPN은 SSL/TLS 기반 제어 채널에서 인증서와 공개키 키 합의를 사용하므로 PQC의 영향을 받습니다. 그러나 실제 VPN 데이터를 RSA나 ECC로 암호화하는 것은 아닙니다. 실제 데이터 채널은 AES-GCM이나 ChaCha20-Poly1305 같은 대칭키 암호를 사용합니다.²³

그리고 OpenVPN 2.7 계열은 OpenSSL 3.5 같은 지원 라이브러리와 결합해 X25519MLKEM768 하이브리드 키 합의를 사용할 수 있는 기반을 이미 제공합니다.³⁴

이것은 중요한 사실을 보여줍니다.

OpenVPN도 별도의 한국형 PQC VPN 플랫폼을 새로 만드는 방식이 아니라, OpenSSL·TLS 표준 생태계의 전환을 따라가고 있습니다.

따라서 지금 필요한 것은 ‘PQC VPN 교체 사업’이 아닙니다.

필요한 것은 다음입니다.

VPN 사용자와 접속 목적을 구분한다.
터널을 통과하는 데이터의 장기 가치를 판단한다.
현재 VPN 취약점·계정·권한·단말 위험을 먼저 통제한다.
OpenVPN·OpenSSL·TLS 버전과 지원 그룹을 확인한다.
하이브리드 키 합의의 상호운용성을 테스트한다.
키 합의와 인증서·PKI 전환을 구분한다.
업체의 ‘PQC 적용 완료’ 범위를 기술적으로 검증한다.

즉, VPN의 PQC 문제도 제품 구매가 아니라 사용 맥락과 표준 전환 관리의 문제입니다.

1️⃣ PQC 때문에 SSL VPN을 지금 교체해야 하나요?

A. 아닙니다. SSL VPN이라는 이유만으로 지금 교체할 필요는 없습니다.

SSL VPN은 TLS와 인증서, 공개키 키 합의를 사용하므로 장기적으로 PQC의 영향을 받습니다.

하지만 다음 결론은 서로 다릅니다.

PQC 전환은 다음 순서로 봐야 합니다.

사용자와 접속 목적 확인
→ 터널 데이터의 장기 가치 판단
→ 현재 VPN 구현과 암호 라이브러리 확인
→ 표준 지원 시점 확인
→ 테스트
→ 필요한 환경부터 단계적 반영

제품 이름만 보고 우선순위를 정하면 안 됩니다.

2️⃣ SSL VPN이 중요한 보안 장비라는 말은 맞나요?

A. 맞습니다. 그러나 PQC 때문에 중요한 것은 아닙니다.

SSL VPN은 외부 사용자가 내부 업무 시스템으로 들어오는 관문입니다.

따라서 지금도 다음 보안 기능이 중요합니다.

• 강한 사용자 인증과 MFA
• 단말 보안 상태 확인
• 관리자·협력사 계정 분리
• 최소 권한 접근
• 접속 대상 제한
• 세션과 토큰 관리
• 관리자 페이지 보호
• 접속 이후 행위 기록
• 취약점 패치와 장비 수명주기 관리

이것들은 모두 PQC와 무관하게 필요한 현재의 접속 보안입니다.

PQC는 이 중 일부를 자동으로 해결하지 않습니다.

PQC 키 합의를 사용해도 정상 계정이 탈취되면 공격자는 정상 사용자처럼 접속할 수 있습니다.

PQC 인증서를 사용해도 감염된 단말이 내부망에 들어오면 공격은 계속될 수 있습니다.

따라서 정확한 표현은 이것입니다.

SSL VPN은 중요합니다.
그러나 SSL VPN이 중요한 이유를 PQC 제품 구매 논리로 바꿔서는 안 됩니다.

3️⃣ VPN의 PQC 우선순위는 무엇이 결정하나요?

A. 누가, 어디에, 무엇을 위해 접속하는지가 결정합니다.

VPN은 하나의 제품 유형입니다.

그 안에서 흐르는 데이터와 사용 목적은 조직마다 완전히 다릅니다.

핵심은 이것입니다.

PQC 우선순위와 현재 보안 우선순위는 같지 않습니다.

일반 임직원 VPN도 현재 보안 측면에서는 중요합니다.

그러나 그것이 곧 HNDL 관점의 최우선 PQC 전환 대상이라는 뜻은 아닙니다.

4️⃣ 누가 VPN을 사용하느냐가 왜 그렇게 중요한가요?

A. 동일한 VPN이라도 계정 권한과 접속 대상에 따라 위험이 완전히 달라지기 때문입니다.

다음 사용자를 같은 범주로 묶을 수 없습니다.

일반 직원
외주 개발자
협력사 유지보수 인력
데이터베이스 관리자
보안 관리자
경영진
연구개발 책임자
국가 중요시설 운영자

예를 들어 일반 직원이 그룹웨어에 접속하는 세션과, 데이터베이스 관리자가 고객 원장 시스템에 접속하는 세션은 현재 위험도도 다르고 장기 데이터 가치도 다릅니다.

따라서 VPN 보안은 최소한 다음 축으로 분류해야 합니다.

“SSL VPN은 중요하다”는 말만으로는 부족합니다.

더 중요한 질문은 어떤 SSL VPN인가입니다.

5️⃣ HNDL 관점에서 VPN 트래픽은 정말 위험한가요?

A. 일부 고가치 통신에는 검토 가치가 있지만, 모든 VPN 트래픽이 같은 대상은 아닙니다.

HNDL은 공격자가 지금 암호화된 트래픽을 수집해 두었다가, 미래에 충분히 강력한 양자컴퓨터가 등장하면 복호화한다는 위협 모델입니다.

VPN 트래픽이 HNDL 대상이 되려면 다음 조건이 필요합니다.

• 공격자가 실제 VPN 패킷을 수집할 수 있어야 합니다.
• 키 합의와 필요한 핸드셰이크 정보도 확보해야 합니다.
• 데이터를 수년 또는 수십 년 보관해야 합니다.
• 나중에도 의미 있는 세션을 분류하고 찾을 수 있어야 합니다.
• 복호화된 정보가 그때도 가치가 있어야 합니다.
• 이미 유출되거나 만료된 데이터가 아니어야 합니다.

일반 업무 VPN에는 시간이 지나면 가치가 낮아지는 데이터가 많습니다.

• 만료된 로그인 세션
• 일회성 인증 코드
• 이미 정산된 일반 업무 요청
• 짧은 유효기간의 토큰
• 공개성이 높은 웹 요청
• 이미 침해 사고로 유출된 정보

반대로 장기 국가기밀, 핵심 기술자료, 장기 전략문서처럼 수십 년 뒤에도 가치가 남는 통신은 별도로 검토할 수 있습니다.

정확한 표현은 이것입니다.

VPN 트래픽 전체가 HNDL 고위험인 것이 아닙니다.
수십 년 뒤에도 가치가 남는 일부 고가치 통신이 선별 검토 대상입니다.

6️⃣ 원격접속 VPN과 사이트 간 VPN은 같은 우선순위인가요?

A. 아닙니다. 연결 형태보다 실제 데이터 흐름을 봐야 하지만, 장기 상시 터널은 별도 검토 가치가 있습니다.

원격접속 VPN은 주로 사용자 단말과 조직 내부 시스템을 연결합니다.

사이트 간 VPN은 지사, 데이터센터, 클라우드, 협력사 망을 장시간 또는 상시 연결할 수 있습니다.

사이트 간 VPN이라고 자동으로 PQC 최우선 대상이 되는 것은 아닙니다.

공개 데이터나 단기 업무 메시지만 흐를 수도 있기 때문입니다.

반대로 특정 원격접속 VPN 한 개가 국가 핵심기술 저장소로 연결된다면, 그 세션은 일반 사이트 간 VPN보다 우선순위가 높을 수 있습니다.

제품 유형보다 데이터가 중요합니다.

7️⃣ VPN에서 지금 더 시급한 위험은 무엇인가요?

A. 미래 양자컴퓨터보다 현재의 계정·취약점·권한·단말 위험이 더 직접적입니다.

VPN 사고는 지금도 다음 경로로 발생할 수 있습니다.

• VPN 게이트웨이 취약점 악용
• 패치되지 않은 서버·클라이언트
• 관리자 인터페이스 인터넷 노출
• 비밀번호 재사용과 크리덴셜 스터핑
• MFA 우회·피싱·세션 탈취
• 퇴사자·협력사 계정 미회수
• 감염된 단말의 내부망 접속
• 광범위한 네트워크 권한
• VPN 접속 이후 행위 가시성 부족
• 인증서·개인키 유출

이 공격들은 미래 가정이 아닙니다.

지금 발생해 내부 침투와 데이터 유출을 만듭니다.

따라서 VPN 예산의 우선순위가 다음처럼 뒤집혀서는 안 됩니다.

현재 취약점 패치와 계정 통제는 부족함
→ PQC 기능만 추가
→ ‘차세대 안전한 VPN’으로 홍보

PQC 키 합의는 현재의 운영 취약점을 덮어주지 않습니다.

8️⃣ 기사에서 어디까지가 기술이고 어디부터가 마케팅인가요?

A. 공개키 자산 식별과 하이브리드 전환은 기술이고, 자사 SSL VPN·SWG를 필수 플랫폼으로 연결하는 부분은 마케팅 관점에서 검토해야 합니다.

기사의 타당한 부분은 다음입니다.¹

• VPN·TLS·PKI·인증서가 공개키 암호를 사용한다.
• 공개키 사용처를 식별해야 한다.
• 중요 시스템부터 단계적으로 전환할 수 있다.
• 하이브리드 PQC 키 교환으로 호환성을 유지할 수 있다.

하지만 다음 연결은 별도 검증이 필요합니다.

SSL VPN이 중요하다
→ PQC 시대에는 SSL VPN이 더 핵심 플랫폼이 된다
→ SWG도 PQC 핵심 플랫폼이 된다
→ 자사 SSL VPN·SWG 중심 전략이 필요하다

이것은 표준이 요구하는 필연적 구조가 아닙니다.

기사도 결국 수산아이앤티의 eWalker SSL VPN과 eWalker SWG를 중심으로 제품 전략을 설명합니다.¹

따라서 독자는 이 기사를 독립적인 PQC 기술 분석보다는 PQC를 기존 접속 보안 제품군과 연결한 업체 전략 소개로 읽을 필요가 있습니다.

9️⃣ “PQC 시대에는 암호만 바꿔서는 부족하다”는 말은 맞나요?

A. 일반적인 보안 원칙으로는 맞지만, PQC의 범위를 넓혀 제품 기능을 묶는 표현이 될 수 있습니다.

사용자 인증, 단말 검증, 정책 기반 접근 제어가 필요하다는 말은 맞습니다.

그러나 그것들은 PQC 때문에 필요한 것이 아닙니다.

따라서 더 정확한 표현은 다음입니다.

PQC 전환은 키 합의와 인증서·서명 알고리즘을 바꾸는 문제입니다.
사용자 인증과 단말 검증은 PQC 때문이 아니라 지금도 필요한 접속 보안입니다.

두 문제를 함께 운영할 수는 있습니다.

그러나 함께 운영한다는 이유로 같은 구매 사업이어야 하는 것은 아닙니다.

1️⃣0️⃣ SWG는 PQC 시대의 핵심 플랫폼이 되나요?

A. 자동으로 그렇게 되는 것은 아닙니다. 오히려 TLS 종료·재암호화 구조를 더 엄격히 검증해야 합니다.

SWG는 웹 접속 통제, URL 필터링, 악성 콘텐츠 탐지, 데이터 유출 방지, TLS 가시성 등에 사용될 수 있습니다.

이 역할은 PQC가 없어도 존재합니다.

PQC가 적용된 TLS 트래픽을 SWG가 중간에서 종료하고 다시 암호화한다면, 다음 질문이 생깁니다.

클라이언트 ↔ SWG 구간은 어떤 키 합의를 사용하는가?
SWG ↔ 목적지 서버 구간은 어떤 키 합의를 사용하는가?
두 구간 모두 X25519MLKEM768 같은 하이브리드 그룹을 협상하는가?
한쪽 구간만 고전 알고리즘으로 내려가지는 않는가?
SWG가 발급하는 대체 인증서는 어떤 서명 알고리즘을 사용하는가?
실제 협상 결과를 로그로 확인할 수 있는가?
지원하지 않는 트래픽은 차단하는가, 우회하는가, 고전 방식으로 fallback하는가?

SWG가 있다고 PQC가 자동으로 완성되지 않습니다.

오히려 중간자형 TLS 검사 구조에서는 두 개의 별도 TLS 연결이 각각 어떻게 보호되는지를 확인해야 합니다.

따라서 “SWG가 PQC 핵심 플랫폼”이라는 말보다 다음 질문이 먼저입니다.

SWG가 PQC 적용 구간을 실제로 끝까지 유지하는가, 아니면 중간에서 다시 고전 암호로 바꾸는가?

1️⃣1️⃣ OpenVPN은 SSL VPN인가요?

A. 넓은 의미에서는 SSL/TLS 기반 VPN입니다.

OpenVPN 공식 문서는 OpenVPN이 SSL/TLS 보안을 지원하고, SSL/TLS 모드에서 클라이언트와 서버 인증서를 사용하는 공개키 보안을 제공한다고 설명합니다.³

다만 흔히 말하는 브라우저 기반 ‘클라이언트리스 SSL VPN 포털’과는 구현 방식이 다릅니다.

OpenVPN은 자체 프로토콜을 TCP 또는 UDP 위에서 동작시키며, 제어 채널과 데이터 채널을 분리합니다.

[OpenVPN 제어 채널]
TLS
- 서버·클라이언트 인증
- 인증서 검증
- 키 합의
- 데이터 채널용 키 전달·도출

              ↓

[OpenVPN 데이터 채널]
AES-GCM 또는 ChaCha20-Poly1305 등
- 실제 IP 패킷 암호화
- VPN 터널 데이터 전송

즉, OpenVPN은 TLS를 사용하지만 일반 웹 HTTPS 트래픽을 그대로 터널로 사용하는 구조는 아닙니다.

1️⃣2️⃣ OpenVPN은 RSA·ECC 기반 공개키 알고리즘을 사용하나요?

A. 일반적인 SSL/TLS 모드에서는 사용합니다. 다만 역할을 구분해야 합니다.

OpenVPN의 공개키 암호는 주로 다음 역할에 사용됩니다.

TLS 1.3 환경에서 RSA 인증서를 사용한다고 해서 RSA로 세션 데이터를 암호화하는 것은 아닙니다.

RSA는 주로 인증서 서명에 쓰이고, 키 합의는 X25519나 ECDHE 같은 방식이 담당할 수 있습니다.

정확한 표현은 이것입니다.

OpenVPN은 RSA·ECC 계열을 인증과 키 합의에 사용할 수 있지만,
실제 VPN 데이터는 AES나 ChaCha20 같은 대칭키로 암호화합니다.

1️⃣3️⃣ OpenVPN의 실제 터널 데이터도 RSA나 ECC로 암호화되나요?

A. 아닙니다. 실제 데이터 채널은 대칭키 암호를 사용합니다.

공개키 암호는 대량 데이터를 지속적으로 암호화하기에 비효율적입니다.

따라서 OpenVPN은 TLS 제어 채널에서 인증과 키 합의를 수행한 뒤, 데이터 채널에서는 대칭키를 사용합니다.

OpenVPN 프로젝트의 PQC 문서도 AES-GCM과 ChaCha20-Poly1305 같은 데이터 채널용 대칭키 암호는 계속 안전하게 사용할 수 있으며, 이 영역은 변경할 필요가 없다고 설명합니다.²

공개키 인증·키 합의
→ 세션용 대칭키 생성
→ AES-GCM 또는 ChaCha20-Poly1305로 실제 터널 데이터 암호화

따라서 “OpenVPN 전체 암호를 PQC로 교체한다”는 표현은 부정확합니다.

바뀌는 것은 주로 제어 채널의 키 합의와 인증서·서명 영역입니다.

1️⃣4️⃣ OpenVPN도 PQC의 영향을 받나요?

A. 예. 제어 채널의 비대칭 암호 영역은 영향을 받습니다.

OpenVPN에서 PQC 영향을 받는 핵심 영역은 세 가지입니다.²

1. 키 합의

   기존 DH·ECDH·X25519만 사용하는 키 합의는 장기적으로 PQ 하이브리드 방식으로 전환할 수 있습니다.

2. 인증서와 전자서명

   RSA·ECDSA 기반 서버·클라이언트 인증서와 자체 CA·PKI는 별도 전환 대상입니다.

3. TLS 제어 채널 보호

   OpenVPN은 tls-crypt 또는 tls-crypt-v2 같은 사전 공유키 기반 추가 보호층도 제공합니다.

반면 다음은 직접적인 PQC 교체 대상이 아닙니다.

• 데이터 채널의 AES-GCM
• 데이터 채널의 ChaCha20-Poly1305
• 일반적인 대칭키 패킷 보호 구조

따라서 OpenVPN PQC 전환을 말할 때 키 합의, 인증서, 데이터 채널을 반드시 구분해야 합니다.

1️⃣5️⃣ OpenVPN은 이미 PQC 키 합의를 지원하나요?

A. OpenVPN 2.7 계열과 지원 암호 라이브러리를 사용하면 하이브리드 키 합의를 사용할 수 있는 기반이 마련되어 있습니다.

OpenVPN 2.7 매뉴얼은 기존 유한체 DH 대신 ECDH 또는 X25519MLKEM768 같은 새로운 하이브리드 키 합의 알고리즘을 사용할 수 있다고 명시합니다.³

OpenSSL 3.5는 2025년 4월 8일 출시된 장기지원(LTS) 버전이며, 공식 지원 기한은 2030년 4월 8일입니다.⁵

OpenSSL 3.5는 다음 기능을 제공합니다.⁴

• ML-KEM 지원
• ML-DSA 지원
• SLH-DSA 지원
• 하이브리드 PQC KEM 그룹을 TLS 기본 지원 그룹에 포함
• 기본 TLS key share로 X25519MLKEM768과 X25519 제공

다만 이것을 “OpenSSL 3.5로 올리기만 하면 모든 OpenVPN 연결에 PQC가 자동 적용된다”는 뜻으로 읽어서는 안 됩니다.

실제 협상에는 서버와 클라이언트 양쪽의 라이브러리·패키지 지원, TLS 그룹 설정, 상호운용성이 필요하며, 연결 로그에서 실제 협상 그룹을 확인해야 합니다.

따라서 흐름은 다음과 같습니다.

OpenSSL 3.5 이상
→ ML-KEM과 X25519MLKEM768 지원
→ OpenVPN 2.7 계열에서 해당 TLS 그룹 사용 가능
→ 서버·클라이언트 상호운용성 확인
→ 실제 협상 결과 검증

이것은 별도의 새 VPN 프로토콜이 아닙니다.

OpenVPN이 기존 TLS와 OpenSSL 생태계의 확장을 흡수하는 방식입니다.

1️⃣6️⃣ X25519MLKEM768은 무엇인가요?

A. 기존 X25519 키 합의와 ML-KEM을 결합한 하이브리드 그룹입니다.

하이브리드 키 합의는 고전 암호와 PQC 중 하나만 믿지 않고 두 방식의 결과를 함께 사용합니다.

X25519 공유 비밀
+
ML-KEM 공유 비밀
↓
결합된 TLS 공유 비밀
↓
OpenVPN 데이터 채널용 키 도출

이 방식의 목적은 전환 기간 동안 다음을 함께 고려하는 것입니다.

• 기존 고전 암호 구현과의 연속성
• 아직 충분히 오래 검증되지 않은 PQ 구현에 대한 보수성
• 미래 양자컴퓨터에 대한 키 합의 보호

IETF TLS 작업도 TLS 1.3 안에서 ECDHE와 ML-KEM을 결합하는 하이브리드 키 합의를 다루고 있습니다.⁶

즉, OpenVPN의 PQC 전환도 TLS 2.0 같은 새 프로토콜을 기다리는 문제가 아닙니다.

기존 TLS 1.3 키 합의 그룹을 확장하는 문제에 가깝습니다.

1️⃣7️⃣ OpenVPN 2.7과 OpenSSL 3.5로 올리면 전환이 끝나나요?

A. 아닙니다. 키 합의 지원과 전체 VPN·PKI 전환은 다른 문제입니다.

버전 업그레이드는 중요한 출발점입니다.

하지만 다음을 별도로 확인해야 합니다.

특히 다음을 구분해야 합니다.

X25519MLKEM768 키 합의를 사용한다
≠
인증서·서명·CA·PKI까지 모두 PQC로 전환했다

“PQC 적용 완료”라는 표현은 이 차이를 숨길 수 있습니다.

1️⃣8️⃣ 기존 OpenVPN을 업그레이드하면 되는데 새 PQC VPN 제품이 필요한가요?

A. 일반적인 OpenVPN 환경이라면 먼저 표준 구현체 업그레이드와 검증을 보는 것이 합리적입니다.

OpenVPN은 OpenSSL에서 많은 암호 기능을 가져옵니다.³

따라서 일반적인 전환 경로는 다음과 같습니다.

OpenVPN·OpenSSL 지원 버전 확인
→ 테스트 서버와 클라이언트 업그레이드
→ X25519MLKEM768 지원 확인
→ 혼합 버전 환경의 fallback 확인
→ 성능·MTU·연결 안정성 테스트
→ 단계적 배포

새 제품이 필요한 경우도 있을 수 있습니다.

• 기존 장비가 지원 종료 상태인 경우
• 벤더가 표준 PQC 그룹 지원 계획이 없는 경우
• HSM·KMS·인증서 체계와 통합이 필요한 경우
• 규제·인증 요구가 별도로 있는 경우
• 운영 가시성과 중앙 관리 기능이 부족한 경우

그러나 “PQC라는 기능이 필요하다”는 이유만으로 기존 VPN을 폐기하고 새 플랫폼을 구매해야 한다고 단정할 수는 없습니다.

OpenVPN 사례는 오히려 반대 방향을 보여줍니다.

표준 라이브러리와 오픈소스 구현체가 기능을 흡수하면,
일반 사용자는 업그레이드와 호환성 검증으로 따라갈 수 있습니다.

1️⃣9️⃣ OpenVPN의 tls-crypt는 HNDL 대응과 관계가 있나요?

A. 일정한 추가 보호를 제공하지만 표준 PQC 키 합의를 대체하지는 않습니다.

OpenVPN의 tls-crypt는 사전 공유 대칭키를 이용해 TLS 제어 채널 패킷을 추가로 암호화하고 인증합니다.

OpenVPN 공식 매뉴얼은 공격자가 사전 공유키를 영원히 알지 못한다는 조건에서 이를 이른바 **“poor-man’s post-quantum security”**라고 설명합니다.³

이 기능은 다음 효과가 있습니다.

• TLS 인증서를 외부에서 바로 보기 어렵게 함
• OpenVPN 트래픽 식별을 어렵게 함
• 제어 채널에 대칭키 기반 추가 보호 제공
• 사전 공유키를 모르는 수동 수집 공격자에게 추가 장벽 제공

하지만 한계도 있습니다.

• 사전 공유키가 나중에 유출되면 가정이 달라집니다.
• tls-crypt 그룹 키는 여러 사용자가 공유할 수 있습니다.
• 전방향 안전성 자체를 제공하는 것은 아닙니다.
• 인증서와 PKI 전환 문제는 남습니다.
• 표준 ML-KEM 하이브리드 키 합의를 대신하지 않습니다.

tls-crypt-v2는 클라이언트별 고유 키를 사용해 그룹 키 구조를 개선합니다.³

이 기능이 주는 중요한 시사점은 이것입니다.

모든 OpenVPN 제어 채널이 아무 보호 없이 수집되어 미래에 곧바로 풀리는 구조라고 단순화할 수는 없습니다.

실제 HNDL 노출은 OpenVPN 설정과 키 관리 방식에 따라 달라집니다.

2️⃣0️⃣ OpenVPN 환경에서 PQC 지원을 어떻게 확인하나요?

A. 버전, 암호 라이브러리, 지원 그룹, 실제 협상 결과를 순서대로 확인해야 합니다.

먼저 OpenVPN과 TLS 라이브러리 버전을 확인합니다.

openvpn --version

지원되는 TLS 그룹을 확인합니다.

openvpn --show-groups | grep -i MLKEM

X25519MLKEM768이 보인다면 해당 OpenVPN 빌드와 TLS 라이브러리가 하이브리드 그룹을 인식하고 있을 가능성이 높습니다.³

그러나 목록에 나타난다고 실제 연결에서 자동으로 선택된다는 뜻은 아닙니다.

다음도 확인해야 합니다.

• 서버와 클라이언트가 모두 지원하는가?
• 우선순위 설정은 어떻게 되어 있는가?
• 구형 클라이언트에서 어떤 방식으로 fallback하는가?
• 연결 로그에서 실제 선택된 키 합의를 확인할 수 있는가?
• 강제 설정 시 연결 실패가 발생하지 않는가?

OpenVPN의 tls-groups 옵션으로 허용 그룹을 설정할 수 있지만, 공식 매뉴얼은 이 옵션을 잘못 사용하면 TLS 1.3을 비활성화하거나 연결을 깨뜨릴 수 있다고 경고합니다.³

따라서 운영 환경에서 바로 강제하기보다 테스트 환경에서 혼합 버전 호환성을 먼저 확인해야 합니다.

2️⃣1️⃣ 업체가 “PQC SSL VPN 적용 완료”라고 하면 무엇을 물어봐야 하나요?

A. 제품명이 아니라 알고리즘·범위·상호운용성·실제 협상 증거를 물어봐야 합니다.

기사에서는 키 협상이 필요한 통신과 사설 인증서 영역에 PQC 적용 개발을 완료했다고 설명합니다.¹

그러나 기사만으로는 다음이 확인되지 않습니다.

특히 다음 질문이 중요합니다.

OpenVPN 2.7과 OpenSSL 3.5에서도 가능한 표준 하이브리드 키 합의를 적용한 것이라면,
왜 이를 별도의 ‘PQC SSL VPN 플랫폼’ 교체 사업으로 설명해야 합니까?

2️⃣2️⃣ 기업은 VPN의 PQC 문제를 지금 어떻게 관리해야 하나요?

A. 제품 구매보다 사용자·데이터 분류, 현재 보안 강화, 표준 지원 확인이 먼저입니다.

현실적인 순서는 다음과 같습니다.

이 과정에서 가장 먼저 해야 할 일은 미래 기능 구매가 아니라 현재 VPN 보안을 정상화하는 것입니다.

패치되지 않은 VPN을 PQC로 포장하지 않는다.
탈취 가능한 계정을 PQC로 포장하지 않는다.
과도한 접근 권한을 PQC로 포장하지 않는다.
접속 이후를 보지 못하는 VPN을 PQC로 포장하지 않는다.

PQC는 현재 보안의 대체물이 아닙니다.

2️⃣3️⃣ 결론적으로 PQC 때문에 VPN을 지금 바꿔야 하나요?

A. 아닙니다. VPN의 사용 맥락과 표준 지원을 확인한 뒤 필요한 환경부터 검증하면 됩니다.

SSL VPN은 중요합니다.

그러나 SSL VPN이라는 제품 이름이 PQC 우선순위를 결정하지 않습니다.

우선순위를 결정하는 것은 다음입니다.

누가 접속하는가?
어떤 권한을 갖는가?
어떤 시스템으로 들어가는가?
어떤 데이터가 흐르는가?
그 데이터는 수십 년 뒤에도 가치가 있는가?
현재 VPN의 더 직접적인 위험은 통제되고 있는가?

OpenVPN도 PQC 영향을 받습니다.

하지만 영향을 받는 것은 주로 TLS 제어 채널의 키 합의와 인증서·서명 영역입니다.

실제 데이터 채널은 계속 AES-GCM이나 ChaCha20-Poly1305 같은 대칭키 암호를 사용합니다.

그리고 OpenVPN 2.7 계열과 OpenSSL 3.5는 X25519MLKEM768 하이브리드 키 합의를 흡수할 수 있는 방향으로 이미 움직이고 있습니다.

따라서 결론은 분명합니다.

SSL VPN이 중요한 것과 지금 PQC SSL VPN 제품을 구매해야 한다는 것은 다른 이야기입니다.

일반적인 VPN은 OpenSSL·TLS·OpenVPN 생태계 전환을 따라가며 검증하면 됩니다.

특수 고가치 통신은 사용자·접속 대상·데이터 수명을 기준으로 별도 우선순위를 정해야 합니다.

지금 필요한 것은 ‘PQC VPN 교체 사업’이 아닙니다.

필요한 것은 다음입니다.

현재 VPN 보안을 먼저 강화한다.
사용자와 접속 목적을 분류한다.
장기 가치가 있는 통신을 선별한다.
표준 알고리즘과 구현체를 추적한다.
업그레이드와 상호운용성을 테스트한다.
업체의 ‘PQC 적용 완료’를 기술적으로 검증한다.

VPN의 PQC 문제도 공포가 아니라 우선순위의 문제입니다.

정리하면

SSL VPN은 중요하다.
하지만 PQC 때문에 새롭게 중요한 것은 아니다.

VPN 제품명이 우선순위를 결정하지 않는다.
사용자·권한·접속 대상·데이터 수명이 결정한다.

HNDL은 모든 VPN 트래픽의 문제가 아니다.
수십 년 뒤에도 가치가 남는 일부 고가치 통신의 검토 문제다.

사용자 인증·단말 검증·접근 제어는 지금도 필요하다.
이를 PQC 제품 기능처럼 묶어 팔아서는 안 된다.

OpenVPN도 PQC 영향을 받는다.
하지만 실제 데이터 암호화가 아니라 키 합의와 인증서 영역이 중심이다.

OpenVPN 2.7과 OpenSSL 3.5 생태계는
X25519MLKEM768 하이브리드 키 합의를 지원할 수 있는 기반을 이미 제공한다.

지금 할 일은 VPN 교체가 아니다.
현재 보안 강화, 자산 식별, 표준 확인, 호환성 검증이다.

보안은 제품명이 아니라 실제 위험으로 판단해야 합니다.

그리고 VPN의 PQC 우선순위는 이렇게 물어야 합니다.

누가, 어디에, 무엇을 위해 접속하며,
그 통신이 수십 년 뒤에도 공격자에게 가치가 있는가?

📚 함께 읽기

• Q26. PQC(양자내성암호), 지금 도입해야 하나요?
• PQC(양자내성암호)는 독자 모델이 아니라 표준 전환이다
• Q25. 제로트러스트, 도입해야 하나요?
• 웹서버인 줄 모르는 보안·인프라 장비들
• 공포·유행어 추격을 멈추고 ‘증거 중심 보안’으로