양자 내성 암호(PQC)의 현주소: 지금 무엇을 준비해야 하는가

By PLURA 2026-04-06

양자 내성 암호(PQC)는
더 이상 “먼 미래의 연구 주제”가 아닙니다.

이미 미국 NIST는
첫 번째 핵심 표준을 확정했고,
OpenSSL도 이를 실제 구현에 반영하기 시작했습니다.

이제 질문은
“PQC가 가능할까?”가 아니라,
“언제, 무엇부터, 어떤 방식으로 바꿔야 하는가”에 가깝습니다.

그런데 이 지점에서
현실은 늘 두 갈래로 갈립니다.

하나는
“양자 컴퓨터가 당장 RSA를 모두 깨뜨릴 것”이라는 과장이고,
다른 하나는
“아직 멀었으니 신경 쓸 필요 없다”는 방심입니다.

둘 다 정확하지 않습니다.

지금 필요한 것은 공포 마케팅도, 낙관론도 아닙니다.
표준, 구현, 전환 순서를 냉정하게 보는 것입니다.

왜 지금 PQC를 다시 봐야 하는가

현재의 공개키 암호 체계인
RSA와 ECC는
고전 컴퓨터 기준으로는 여전히 실용적입니다.

하지만 피터 쇼어가 제시한 알고리즘은
충분히 큰 양자 컴퓨터가 등장할 경우
인수분해와 이산로그 문제를 효율적으로 풀 수 있음을 보여 주었고,
이 때문에 RSA와 ECC의 장기 안전성은 구조적으로 흔들리게 되었습니다.

문제는
양자 컴퓨터가 “오늘 당장” 모든 암호를 깨느냐가 아닙니다.

‼️더 중요한 것은
지금 수집한 암호화 데이터를 나중에 해독하는 시나리오,
즉 이른바 Harvest Now, Decrypt Later(HNDL) 위험입니다.
오래 보관해야 하는 기밀 데이터일수록
전환을 늦출수록 불리해집니다.

그래서 지금의 질문은
“양자 위협이 정말 오느냐”가 아니라,
장기 기밀 데이터를 지금 어떤 기준으로 보호할 것인가여야 합니다.

1. PQC란 무엇인가

PQC는
양자 컴퓨터가 등장해도
기존 공개키 암호보다 훨씬 안전하게 버티도록 설계된
새로운 공개키 암호 계열입니다.

핵심은 양자 장비를 쓰는 것이 아니라,
기존 디지털 시스템 위에서 실행 가능한 수학 기반 알고리즘이라는 점입니다.

즉, PQC는
양자 암호 통신(QKD)과는 다릅니다.

QKD는 물리 장비와 전송 인프라가 필요합니다.
PQC는 소프트웨어, 라이브러리, 프로토콜 업데이트로 전환할 수 있습니다.

그래서 현실적인 산업 전환의 중심은
현재까지는 QKD보다
PQC 쪽에 훨씬 더 가까이 와 있다고 보는 편이 맞습니다.

현재 표준화의 중심 알고리즘들은
주로 다음과 같은 수학 문제를 기반으로 합니다.

격자 기반: ML-KEM, ML-DSA
해시 기반: SLH-DSA
코드 기반: HQC

이 가운데 현재 1차 표준의 중심은
격자와 해시 기반입니다.

2. 현재 NIST 중심의 표준화 수준

2026년 현재 기준으로,
NIST의 1차 핵심 표준은 이미 나왔습니다.

2024년 8월 NIST는
다음 세 가지를 최종 FIPS로 공개했습니다.

FIPS 203: ML-KEM
FIPS 204: ML-DSA
FIPS 205: SLH-DSA

정리하면 역할은 이렇습니다.

구분	표준	역할	기반
키 교환 / KEM	ML-KEM	세션 키 설정	격자
전자서명	ML-DSA	주력 전자서명	격자
전자서명	SLH-DSA	보수적 대안 서명	해시

위 구도는
“하나의 만능 알고리즘”이 아니라
용도별 표준 포트폴리오에 가깝습니다.

특히 ML-DSA가 주력 전자서명으로 자리 잡고,
SLH-DSA는 더 느리지만 해시 기반이라는 점에서
보수적 대안의 의미를 가집니다.

이 점이 중요합니다.

PQC는 아직
“모든 답이 끝난 세계”가 아닙니다.
하지만 반대로
“아직 아무것도 정해지지 않은 연구 단계”도 아닙니다.

표준은 이미 시작됐고, 이제 남은 것은 대규모 전환의 실행입니다.

3. OpenSSL 진영에서 지원하는 수준과 방향성

실무에서 가장 중요한 질문 중 하나는 이것입니다.

“표준이 나왔다고 해도, 실제 라이브러리와 시스템이 따라오고 있는가?”

2026년 현재는
예전보다 훨씬 분명한 답을 할 수 있습니다.

OpenSSL 3.5는 NIST FIPS 표준인 ML-KEM, ML-DSA, SLH-DSA를 지원하며,
2025년 4월 공개된 LTS 버전입니다.

이는 단순한 실험 코드가 아니라
운영 생태계로 들어오기 시작했다는 의미가 큽니다.

또한 Open Quantum Safe(OQS) 진영은
oqs-provider를 통해
OpenSSL 3 기반 애플리케이션에
PQC 알고리즘을 런타임으로 붙일 수 있게 해 왔고,
이 흐름은 표준 확정 알고리즘이 OpenSSL 본체로 흡수되는 방향과 맞물리고 있습니다.

여기서 중요한 차이는 분명합니다.

OQS는 전환 실험, 상호운용성 검증, 테스트랩 성격이 강합니다.
OpenSSL 본체 지원은 표준 알고리즘이 주류 구현으로 들어오기 시작했다는 뜻입니다.

즉, 흐름은 이렇게 정리할 수 있습니다.

초기에 OQS가 실험과 검증을 이끌었다.
이제 표준 확정 알고리즘은 OpenSSL 본체로 들어오기 시작했다.
앞으로는 NIST 표준 중심의 운영 구현으로 수렴할 가능성이 높다.

4. 그러나 라이브러리 지원만으로는 활성화되지 않는다

여기서 한 가지 더 중요한 현실을 봐야 합니다.

OpenSSL이 PQC를 지원하기 시작했다는 사실만으로
곧바로 웹과 앱 생태계 전체가 PQC로 전환되는 것은 아닙니다.

왜냐하면 실제 서비스는
단순히 암호 라이브러리 하나로 동작하지 않기 때문입니다.

브라우저와 애플리케이션이 PQC를 실제로 쓰기 위해서는
최소한 다음 계층이 함께 따라와야 합니다.

TLS 스택 구현체
브라우저의 핸드셰이크 로직
인증서 검증 체계와 루트 프로그램(Web PKI)
CA의 인증서 발급 체계
운영체제의 신뢰 저장소와 암호 API
HSM, 로드밸런서, WAF, TLS 중간 장비
기업 내부 프록시와 DPI 장비

즉, OpenSSL은
중요한 출발점이지만,
현실의 활성화는 결국
애플리케이션 생태계 전체의 상호운용성 문제입니다.

이 점에서 브라우저 진영의 움직임은 매우 중요합니다.

Chrome 131은 최종 ML-KEM 기반 하이브리드 키 교환으로 전환했습니다.
Firefox 135도 ML-KEM 기반 지원 흐름에 들어섰습니다.
Apple은 iOS 26 / macOS Tahoe 26 계열에서 X25519MLKEM768 지원을 문서화했습니다.

결국 실무적으로는 이렇게 이해하는 것이 맞습니다.

OpenSSL의 PQC 지원은 “준비 완료”가 아니라,
브라우저와 애플리케이션이 따라올 수 있는 기반이 마련됐다는 뜻입니다.

4-1. 브라우저와 OpenSSL 다음은, 실제 애플리케이션 지원이다

여기서 반드시 짚어야 할 현실이 있습니다.

PQC 전환은
브라우저와 OpenSSL 지원만으로 끝나지 않습니다.
실제 서비스는 결국 다음 계층 위에서 돌아가기 때문입니다.

웹 프록시와 로드밸런서
쿠버네티스와 서비스 메시
원격접속(SSH, RDP)
VPN
운영체제의 TLS/암호 API
인증서와 서명 검증 체계

즉, 브라우저 → TLS 라이브러리 → 애플리케이션/플랫폼 순서로
전환의 폭이 넓어져야
비로소 PQC가 “실제 운영” 단계로 들어갑니다.

OpenSSL 및 브라우저별 PQC 로드맵 요약

기술 명	현재 체감 도입 속도	실제 의존성	핵심 포인트
OpenSSL	빠름	NIST FIPS 표준 구현, 배포판·애플리케이션 연동	3.5부터 ML-KEM, ML-DSA, SLH-DSA 지원 시작
Chrome	가장 빠름	BoringSSL, Chromium TLS/QUIC 스택	Chrome 131부터 최종 ML-KEM 기반 하이브리드 전환 적용
Firefox	빠름	NSS, Firefox 네트워크 스택	2025년부터 ML-KEM 기반 지원 흐름에 진입, WebRTC/HTTP 계층까지 확대 중
Safari	보통~빠름	Apple 플랫폼 TLS 스택, OS 보안 프레임워크	iOS 26 / macOS Tahoe 26 계열의 `X25519MLKEM768` 지원이 핵심
Microsoft Edge	보통~빠름	Chromium/BoringSSL + Windows 플랫폼 정책	Chromium 흐름을 따라가지만, 기업 적용은 Edge 정책·Windows 환경 영향이 큼

인프라 기술별 PQC 로드맵 요약

기술 명	현재 체감 도입 속도	실제 의존성	핵심 포인트
SSH (OpenSSH)	가장 빠름	OpenSSH 자체 구현	이미 PQC 하이브리드 기본값 단계
HAProxy	보통~빠름	OpenSSL / QUIC TLS 스택	자체보다 하부 TLS 스택 의존성이 큼
NGINX	빠름	OpenSSL / BoringSSL	TLS 라이브러리 버전이 사실상 핵심
RDP	보통	Windows CNG / TLS 스택	RDP 자체보다 Windows OS 지원이 핵심
OpenVPN	보통	OpenSSL	컨트롤 채널(TLS) 하이브리드 전환이 우선
Kubernetes	느림	Go TLS, etcd, Ingress, Service Mesh	계층이 너무 많아 가장 복잡한 전환 대상

SSH는 가장 빠르게 움직인 영역이다

OpenSSH 공식 문서는
버전 9.0부터 sntrup761x25519-sha512를 기본 post-quantum key agreement로 제공했고,
9.9에서 mlkem768x25519-sha256를 추가했으며,
10.0(2025년 4월) 에서 이를 새로운 기본 키 교환으로 지정했다고 설명합니다.

즉, SSH는 “향후 지원 예정”이 아니라 이미 운영 전환이 시작된 영역입니다.

HAProxy는 하부 TLS 스택을 따라가는 단계다

HAProxy는 개념적으로는 NGINX와 비슷하게
OpenSSL과 QUIC TLS 스택을 따라가며 PQC를 흡수할 가능성이 큽니다.

다만 공개 자료 기준으로는
“HAProxy가 PQC를 턴키로 지원한다”는 수준의 강한 공식 메시지보다는,
OpenSSL 3.5 기반 지원 요청과 준비 흐름이 더 먼저 보입니다.
2025년 10월에는 HAProxy GitHub에 OpenSSL 3.5 기반 PQC 지원 요청 이슈가 올라왔습니다.

즉, HAProxy는 이미 끝난 지원보다는 하부 TLS 스택을 따라가는 확장 단계로 보는 편이 안전합니다.

NGINX는 하부 TLS 라이브러리 의존성이 핵심이다

NGINX 공식 블로그는
OpenSSL 3.5 기반 PQC 사용 조건을 설명하고,
오픈소스 NGINX에서 PQC를 쓰려면
사실상 OpenSSL 3.5 이상 환경이 필요하다고 설명합니다.

또 NGINX 공식 릴리스 문서는
NGINX Plus R33 에 initial support for Post Quantum Cryptography가 추가됐다고 명시합니다.

즉, NGINX에서는
PQC 자체 구현보다 하부 TLS 라이브러리와 배포판 버전이 핵심입니다.

Kubernetes는 가장 느리고 복잡한 전환 대상이다

쿠버네티스는 암호화가 한 계층에 모여 있지 않습니다.

Ingress
Service Mesh
API Server
kubelet
controller-manager
scheduler
etcd
내부 인증서 체계

Kubernetes 공식 블로그는
PQC 전환을 다루며,
브라우저·OpenSSL의 ML-KEM 지원과 함께
쿠버네티스 내부 전환의 복잡성을 설명합니다.

또 2026년 1월에는
GitHub 이슈 #136346에서
PQC readiness observations가 커뮤니티 차원에서 제기됐습니다.

따라서 현실적인 로드맵은 이렇습니다.

외부 Ingress와 Service Mesh부터 적용
그 다음 API Server와 내부 제어면
마지막으로 etcd 같은 저장 계층

즉, Kubernetes는
“PQC 지원 여부”보다
어느 계층부터 바꿀 것인가가 더 중요한 영역입니다.

RDP는 Windows 플랫폼 지원이 핵심이다

RDP는 독자적으로 PQC를 구현한다기보다
Windows의 암호 API와 TLS 스택을 따라갑니다.

Microsoft는 2025년 11월
Windows Server 2025, Windows 11, .NET 10에
ML-KEM과 ML-DSA 기반 PQC API가 일반 제공(GA) 단계에 들어갔다고 발표했습니다.

즉, RDP의 로드맵은
“RDP 전용 PQC”라기보다
Windows TLS/CNG 플랫폼이 PQC를 흡수하면, 그 혜택을 RDP가 따라가는 구조입니다.

OpenVPN은 컨트롤 채널(TLS)부터 보는 것이 맞다

OpenVPN은
데이터 평면보다 먼저
세션을 협상하는 컨트롤 채널의 TLS 핸드셰이크가 핵심입니다.

OpenVPN 공식 블로그는
quantum-safe VPN을 설명하며
PQC와 하이브리드 전환의 필요성을 강조합니다.

실무적으로는 다음처럼 보는 것이 맞습니다.

1단계: 컨트롤 채널의 하이브리드 키 교환 적용
2단계: 운영체제 배포판과 OpenSSL 기본 버전 정렬
3단계: 인증서·서명 체계까지 확장

즉, OpenVPN은
OpenSSL 주류화의 직접적인 수혜를 받는 계층에 가깝습니다.

5. 현실적으로 어디까지 적용 가능한가

여기서 가장 중요한 현실 감각이 필요합니다.

PQC는
오늘부터 모든 서비스에 일괄 적용하는 기술이 아닙니다.
그보다 먼저
어디에 RSA/ECC가 숨어 있는지 찾는 작업이 선행돼야 합니다.

현실적으로는
다음 순서가 가장 맞습니다.

1) 먼저 인벤토리를 만든다

TLS 인증서
내부 PKI
코드 서명
VPN
SSH
메일 보안
HSM 연동 구간
장기 보관 데이터 보호 체계

어디에서 RSA/ECC가 쓰이는지 보지 않고
곧바로 “PQC 제품 도입”으로 가는 것은
거의 항상 실패합니다.

2) 하이브리드부터 시작한다

현실적 전환은
기존 알고리즘을 한 번에 버리는 것이 아니라,
일정 기간 하이브리드 구성으로 가는 쪽이 더 안전합니다.

예를 들어
TLS나 인증서 체계에서
기존 방식과 PQC를 병행해
성능, 상호운용성, 장애 포인트를 확인하는 것입니다.

즉, 전환의 핵심은
“당장 전부 교체”가 아니라
실서비스를 망치지 않으면서 점진적으로 바꾸는 것입니다.

3) 우선순위는 “오래 가는 비밀”부터다

모든 시스템을 동시에 바꾸는 것은 비현실적입니다.
따라서 먼저 바꿔야 할 것은
양자 공격이 오기 전에 이미 위험해질 수 있는 영역,
즉 장기 기밀성과 장기 신뢰성이 필요한 구간입니다.

장기 보존 문서
국가·금융·의료 기밀
펌웨어/소프트웨어 서명
루트 인증 체계
장기 유효 인증서 체계

이 영역은
“지금 암호화했으니 괜찮다”가 아니라
10년 뒤에도 안전해야 한다는 기준으로 봐야 합니다.

6. 그러면 지금 기업은 어떻게 시작해야 하는가

많은 기업이
“PQC를 도입하라”는 말은 들어도
정작 무엇부터 해야 하는지는 모릅니다.

실무적으로는
아래 다섯 단계가 가장 현실적입니다.

1) 암호 사용처 전수 조사

어떤 제품, 어떤 라이브러리, 어떤 프로토콜이
RSA/ECC에 의존하는지 파악합니다.

2) 공급망 확인

웹 서버, VPN, HSM, PKI, 인증서 발급 체계,
코드 서명 도구, 보안 장비, 클라우드 서비스가
PQC 또는 하이브리드 지원 계획이 있는지
벤더 로드맵을 확인해야 합니다.

3) 브라우저와 앱의 지원 로드맵을 따로 확인한다

OpenSSL 지원 여부만 보고
“이제 서비스 적용이 가능하겠다”고 생각하면 안 됩니다.

실제로는

브라우저 지원 여부
CDN/로드밸런서 지원 여부
중간 보안 장비 호환성
인증서 발급과 검증 체계
모바일 앱 SDK 지원 여부

를 함께 확인해야 실제 적용이 가능합니다.

4) 테스트랩 운영

운영계를 바로 바꾸기보다
시험 환경에서 TLS, 인증서, 서명, 상호운용성, 성능을 먼저 검증하는 편이 맞습니다.

5) 정책부터 바꾼다

장기 인증서 유효기간, 키 교체 주기,
알고리즘 민첩성(crypto agility),
라이브러리 교체 가능성 같은 정책이 정리되지 않으면
기술 도입만으로는 전환이 굴러가지 않습니다.

기술보다 먼저
전환 체계와 우선순위를 세워야 합니다.

7. 한국형 PQC(KpqC)는 어떤 방향이어야 하는가

이 질문은 한국 기업과 공공 부문에 특히 중요합니다.

국내 기업과 연구기관이 PQC를 개발하는 이유 자체는
전혀 이상하지 않습니다.

암호 주권 확보
국내 시험·검증 체계 준비
국제 표준 참여 역량 확보
반도체·통신·국방 환경 최적화

이런 배경은 충분히 이해할 수 있습니다.

문제는
“개발하는 것”과
“한국에서만 쓰는 폐쇄 생태계를 만드는 것”은
전혀 다르다는 점입니다.

한국형 PQC는 국내 조달용 독자 규격이 아니라,
국제 표준과 상호운용성을 넓히는 방향으로 가야 합니다.

왜냐하면 PQC는 특히
브라우저, OS, HSM, TLS, 인증서, 클라우드, 반도체, 보안 장비까지
국제 상호운용성이 매우 중요한 영역이기 때문입니다.

이 지점에서
과거 ARIA 사례를 떠올릴 필요가 있습니다.

ARIA 자체가 의미 없었다는 뜻은 아닙니다.
국산 암호 기술을 확보하고
국가 차원의 구현 역량을 축적했다는 점에서 분명 성과가 있었습니다.

문제는 그다음입니다.

국내 표준으로 채택되는 것과
국제 운영 생태계 전체에서 널리 쓰이는 것은
전혀 다른 문제입니다.

따라서 KpqC의 목표는
“국내 채택”이 아니라
국제 표준과 연결되고, 실제 운영 생태계에서 살아남을 수 있는 상호운용성 확보여야 합니다.

8. PQC의 미래: 왜 기대와 불안이 함께 가는가

현재 표준의 중심이
격자 기반인 이유는
성능과 구조, 구현 가능성 면에서
가장 앞서 있기 때문입니다.

하지만 여기에는
늘 한 가지 불안이 함께 있습니다.

“RSA와 ECC가 쇼어 알고리즘에 의해 구조적으로 흔들렸듯,
언젠가 PQC의 수학 기반도 예상치 못한 돌파를 맞는 것 아닌가?”

이 걱정은
가볍게 넘길 문제가 아닙니다.

그래서 표준 체계도
하나의 계열에 모든 것을 걸지 않습니다.

주력은 격자 기반
보수적 대안은 해시 기반
다양성 확보를 위한 코드 기반 추가 축

실제로 NIST는 2025년
HQC를 다섯 번째 PQC 알고리즘으로 선정하며,
ML-KEM에 대한 backup defense 성격을 분명히 했습니다.

즉, PQC의 미래는
“격자가 전부”가 아니라,
주력은 격자이되 대체 축을 함께 유지하는 구조에 가깝습니다.

결국 미래의 핵심 역량은
특정 알고리즘 하나를 숭배하는 것이 아니라
암호 민첩성(crypto agility),
즉 알고리즘을 바꿀 수 있는 구조를 만드는 데 있습니다.

알고리즘별로 보면 더 현실적이다

알고리즘	용도	특징	현실적 해석
ML-KEM	키 교환 / KEM	성능과 실용성의 균형이 좋아 현재 전환의 중심축	TLS 하이브리드 키 교환의 핵심 후보
ML-DSA	전자서명	주력 서명 표준으로 자리 잡는 중	인증서, 코드 서명, 문서 서명 영역의 중심 후보
SLH-DSA	전자서명	느리지만 해시 기반이라 보수적 대안 의미가 큼	다양성 확보와 장기 보수성 측면에서 중요
HQC	KEM	코드 기반 대안 축	격자 기반 일변도 위험을 줄이는 후보

비교해서 보면 더 분명해진다

항목	기존 공개키 암호	PQC
대표 알고리즘	RSA, ECC	ML-KEM, ML-DSA, SLH-DSA 등
양자 컴퓨터에 대한 장기 안전성	구조적으로 취약	상대적으로 높은 내성 목표
현재 상태	광범위한 운영 중	표준화 및 초기 구현 확산 단계
전환 방식	현행 유지	하이브리드 → 점진 전환
핵심 과제	유지·운영	인벤토리, 상호운용성, 마이그레이션

실무 실행 체크리스트

지금 바로 점검할 8가지

우리 조직은 RSA/ECC 사용처 인벤토리가 있는가
장기 기밀 데이터가 무엇인지 구분했는가
내부 PKI, VPN, TLS, 코드 서명 체계의 전환 가능성을 파악했는가
OpenSSL 3.5 또는 동등 구현으로 테스트 가능한가
하이브리드 전환 구성을 실험할 수 있는가
브라우저·모바일 앱·CDN·중간 장비의 지원 계획을 확인했는가
벤더들의 PQC 로드맵을 확인했는가
국내 독자 규격보다 국제 상호운용성 우선 원칙이 있는가

우선순위를 이렇게 잡으면 된다

암호 인벤토리부터 만든다
장기 기밀 데이터와 장기 신뢰 구간을 먼저 식별한다
하이브리드 구성으로 테스트랩을 돌린다
브라우저·앱·장비 호환성까지 확인한다
정책과 로드맵을 먼저 세운 뒤 점진 전환한다

결론

PQC는
더 이상 연구실 안의 개념이 아닙니다.

NIST는 이미
ML-KEM, ML-DSA, SLH-DSA를 표준화했고,
OpenSSL도 이를 주류 구현으로 받아들이기 시작했습니다.

하지만 그다음 단계는
자동으로 오지 않습니다.

실제 활성화는
브라우저, 애플리케이션, CA, 운영체제, 네트워크 장비,
그리고 기업 내부 인프라가
함께 상호운용성을 확보해야만 가능해집니다.

즉, 2026년 현재 PQC의 현주소는
“가능성 검토”가 아니라
전환 실행을 준비해야 하는 단계입니다.

다만 현실은 분명합니다.

PQC는
오늘 모든 시스템에 곧바로 넣을 기술이 아닙니다.
먼저 해야 할 일은
암호 인벤토리, 하이브리드 검증, 공급망 점검, 정책 정비입니다.
기술보다 먼저
전환 설계가 필요합니다.

그리고 한국의 PQC 전략도
같은 원칙 위에 서야 합니다.

국내 연구와 구현은 필요합니다.
그러나 목표는
한국 안에서만 통하는 독자 암호가 아니라,
국제 표준과 연결되고
실제 운영 생태계에 올라탈 수 있는 경쟁력이어야 합니다.

양자 컴퓨팅 시대의 핵심은
어떤 알고리즘 이름을 외우는 것이 아닙니다.

무엇을 먼저 바꾸고,
어떻게 상호운용성을 유지하며,
얼마나 유연하게 다음 알고리즘으로 넘어갈 수 있는가.

그리고 이 점에서
2026년의 PQC는 이미 분명합니다.

2026년 현재, PQC는 더 이상 “준비할까 말까”의 주제가 아니라,
차분하게 실행을 시작해야 하는 전환 과제입니다.