포스트 양자 TLS: 2026년 양자 안전 HTTPS의 의미

2026-06-02

post-quantumpqcml-kemtlsencryptionsecurity

포스트 양자 TLS는 대형 양자 컴퓨터를 보유한 공격자에 맞서서도 안전하게 유지되는 HTTPS입니다. 양자 컴퓨터가 깨뜨릴 수 있는 오늘날의 키 교환 이면의 수학을, 양자 공격에 저항하도록 설계된 알고리즘으로 대체합니다.

이것은 먼 미래의 연구 프로젝트가 아닙니다. 2026년 중반 기준으로 Cloudflare를 통과하는 사람 웹 트래픽의 65% 이상이 이미 포스트 양자 방식으로 암호화되어 있으며, Chrome, Edge, Firefox는 서버가 지원하기만 하면 기본적으로 양자 안전 키 교환을 협상합니다. 최근에 최신 브라우저로 Google에 방문한 적이 있다면, 거의 틀림없이 알아차리지 못한 채 포스트 양자 TLS를 사용한 것입니다.

고전 TLS가 위험에 처한 이유

오늘날의 TLS는 두 종류의 공개 키 수학에 의존합니다:

키 교환 (X25519 또는 P-256을 사용하는 ECDHE) — 개방된 채널에서 공유 비밀에 합의합니다.
서명 (RSA, ECDSA) — 인증서가 진짜임을 증명합니다.

둘 다 고전 컴퓨터에게는 어려운 문제, 즉 큰 수의 소인수분해(RSA)와 타원 곡선 이산 로그(ECC)에 의존합니다. 충분히 큰 양자 컴퓨터에서 실행되는 쇼어(Shor)의 알고리즘은 두 문제를 모두 효율적으로 풀어냅니다. “암호학적으로 유의미한 양자 컴퓨터”(CRQC)는 아직 존재하지 않지만, 이 분야는 충분히 빠르게 움직이고 있어 계획의 초점이 “만약(if)“에서 “언제(when)“로 옮겨졌습니다.

공개 키 암호화 →에서 양자 컴퓨터가 위협하는 기반 수학을 설명합니다.

”지금 수집하고 나중에 복호화” — 오늘날 이것이 시급한 이유

서두를 필요가 없다고 생각할 수도 있습니다. 오늘날 어떤 양자 컴퓨터도 TLS를 깨뜨릴 수 없는데, 왜 지금 전환해야 할까요?

위협은 지금 수집하고 나중에 복호화(harvest now, decrypt later, HNDL) 입니다. 공격자는 오늘 여러분의 암호화된 트래픽을 기록해 저장해 둡니다. 그리고 양자 컴퓨터가 사용 가능해지면 — 어쩌면 2030년대에 — 저장된 트래픽을 소급해서 복호화합니다.

이로 인해 키 교환의 마감 시한은 양자 컴퓨터의 등장보다 훨씬 앞당겨집니다. 기밀 유지 수명이 긴 모든 데이터 — 건강 기록, 금융 데이터, 정부 기밀, 소스 코드, 자격 증명 — 는 지금 양자 안전 암호화가 필요합니다. 기록은 이미 진행되고 있기 때문입니다.

키 교환은 시급합니다. 서명은 그보다 덜 시급합니다. 이미 지나간 트래픽에 대한 서명을 소급해서 위조할 수는 없습니다. 서명은 양자 컴퓨터가 존재하기 이전까지만 양자 안전하면 되며, 그 이전부터일 필요는 없습니다. 이것이 업계가 포스트 양자 키 교환을 먼저 배포한 이유입니다.

표준: ML-KEM과 ML-DSA

2024년 8월, NIST는 최초로 확정된 포스트 양자 표준을 발표했습니다:

표준	이름	역할	대체 대상
FIPS 203	ML-KEM (이전 명칭 Kyber)	키 캡슐화 (키 교환)	ECDHE / RSA 키 교환
FIPS 204	ML-DSA (이전 명칭 Dilithium)	디지털 서명	RSA / ECDSA 서명
FIPS 205	SLH-DSA (SPHINCS+)	해시 기반 서명	보수적인 서명 백업

ML-KEM(Module-Lattice Key Encapsulation Mechanism, 모듈 격자 키 캡슐화 메커니즘)은 이미 TLS에 배포된 것입니다. 세 가지 크기로 제공됩니다: ML-KEM-512, ML-KEM-768, ML-KEM-1024. 웹에서 사용되는 최적의 선택지는 ML-KEM-768입니다.

하이브리드 키 교환: X25519MLKEM768

브라우저는 하룻밤 사이에 고전 암호화를 버리고 순수 포스트 양자 방식으로 전환하지 않습니다. 그것은 무모한 일입니다 — ML-KEM은 새로운 것이고, 결함이 하나라도 있으면 모든 것을 망가뜨릴 수 있기 때문입니다. 대신 TLS 1.3은 고전 알고리즘과 포스트 양자 알고리즘을 결합한 하이브리드 키 교환을 사용합니다.

2026년에 보게 될 명명된 그룹은 X25519MLKEM768입니다:

X25519MLKEM768 = X25519 (고전 ECDHE)  +  ML-KEM-768 (포스트 양자)

두 공유 비밀은 이어 붙여지며(X25519에서 나온 32 bytes + ML-KEM에서 나온 32 bytes = 64-byte 결합 비밀) TLS 키 스케줄에 입력됩니다.

보안 보장은 “둘 중 하나라도 유효하면 안전함” 입니다. 공격자가 세션 키를 복구하려면 X25519 와 ML-KEM-768을 둘 다 깨뜨려야 합니다. 따라서:

ML-KEM-768에 결함이 있는 것으로 드러나도 → X25519가 여전히 (고전 공격자로부터) 여러분을 보호합니다.
양자 컴퓨터가 X25519를 깨뜨려도 → ML-KEM-768이 여전히 여러분을 보호합니다.

이러한 이중 안전장치 설계가 바로 순수 포스트 양자 방식이 아니라 하이브리드가 어디서나 기본값인 이유입니다.

핸드셰이크에서 들어가는 위치

하이브리드 키 교환은 TLS 1.3이란? →에서 설명한 것과 동일한 TLS 1.3 핸드셰이크를 사용합니다. 유일한 차이는 key_share입니다. ClientHello가 일반 X25519 대신 X25519MLKEM768 키 셰어를 담습니다. ML-KEM 키는 더 큽니다(~1.2 KB 대 32 bytes). 그래서 ClientHello가 약 1킬로바이트 늘어납니다 — 대개는 무시할 만한 수준이지만, 제약이 있는 네트워크에서는 가끔 패킷 경계를 넘어 흘러넘칠 수 있습니다.

또한 여전히 순방향 비밀성 →을 제공합니다. 연결마다 새로운 키 쌍을 쓰는, 포스트 양자 버전입니다.

2026년에 이미 배포된 것

구성 요소	포스트 양자 상태 (2026년 중반)
Chrome / Edge	X25519MLKEM768 기본 협상
Firefox	X25519MLKEM768 지원 및 활성화
Cloudflare	사람 트래픽의 65% 이상 PQ 암호화; 키 교환 완료
Google	포스트 양자 키 교환 제공
AWS	KMS, ACM, Secrets Manager에 ML-KEM 적용; 2026년에 레거시 Kyber 폐지
OpenSSL 3.5+	네이티브 ML-KEM 및 X25519MLKEM768 지원
Java (SunJSSE)	X25519MLKEM768 기본 활성화

아직 대규모로 완료되지 않은 부분은 포스트 양자 인증서 — RSA/ECDSA 대신 ML-DSA로 인증서에 서명하는 것 — 입니다. ML-DSA 서명과 공개 키는 훨씬 큽니다(킬로바이트 대 ~64 bytes). 이는 핸드셰이크를 부풀리고 인증서 체인 크기 한계를 압박합니다. Cloudflare는 2026년 중반까지 오리진 연결에 ML-DSA를 적용할 계획이며, 크기를 관리 가능하게 유지하기 위해 Merkle Tree Certificates를 검토하고 있고, 2029년까지 (인증을 포함한) 완전한 포스트 양자 방식을 목표로 하고 있습니다.

포스트 양자 TLS를 사용 중인지 확인하는 방법

브라우저에서

Chrome에서 아무 주요 사이트나 열고 → DevTools → Security 탭 → 연결 세부 정보를 확인하세요. 포스트 양자 연결은 X25519MLKEM768(또는 이전 빌드에서는 X25519Kyber768)와 같은 키 교환을 표시합니다.

OpenSSL 3.5+로

openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768 2>/dev/null   | grep -i "Negotiated TLS1.3 group"
# 예상 결과: Negotiated TLS1.3 group: X25519MLKEM768

오류가 발생하거나 다른 그룹이 나온다면, OpenSSL이 3.5보다 오래되었거나 서버가 아직 포스트 양자 키 교환을 제공하지 않는 것입니다.

OpenSSL 버전 확인

openssl version
# 필요: 네이티브 X25519MLKEM768을 위한 OpenSSL 3.5+

서버에서 활성화하는 방법

대부분의 사이트에서 정답은 업그레이드하고 비활성화하지 않는 것 입니다 — 포스트 양자 하이브리드 키 교환은 스택이 지원하기만 하면 자동으로 활성화됩니다.

Nginx / Apache

포스트 양자 키 교환은 웹 서버 설정이 아니라 TLS 라이브러리에 있습니다. OpenSSL 3.5+(또는 ML-KEM을 지원하는 BoringSSL)에 맞춰 빌드하거나 실행하세요. 링크되고 나면 X25519MLKEM768이 X25519와 함께 자동으로 제공됩니다 — 새로운 지시문이 필요 없습니다. ssl_ecdh_curve를 단일 고전 곡선으로 고정하지 마세요. 그렇게 하면 하이브리드 그룹이 제외됩니다.

CDN 뒤에서

가장 간단한 방법은 사이트를 Cloudflare(또는 PQC가 활성화된 다른 CDN) 뒤에 두는 것입니다. 브라우저에서 엣지로의 연결이 오리진에 대한 변경 없이 즉시 포스트 양자 방식이 됩니다. 바로 이렇게 해서 트래픽의 65%가 양자 안전하게 되었습니다 — 운영자들은 오리진 서버를 전혀 건드리지 않았습니다.

인증서는 아직 바뀌지 않음

포스트 양자 키 교환을 위해 새 인증서가 필요하지 않습니다. 기존 RSA 또는 ECC 인증서가 잘 작동합니다 — 하이브리드 키 교환은 세션을 보호하는 반면, 인증서는 당분간 여전히 고전 서명을 사용합니다. 포스트 양자 인증서(ML-DSA)는 나중에 진행될 별개의 마이그레이션입니다.

자주 묻는 질문

특별한 “양자 안전 인증서”를 구입해야 하나요?

아니요. 포스트 양자 키 교환(시급한 부분)은 인증서를 전혀 건드리지 않습니다 — 현재의 RSA/ECC 인증서가 계속 작동합니다. 오늘날 “양자 안전 SSL 인증서”를 판매하는 곳은 대부분 마케팅입니다. 프로덕션 수준의 포스트 양자 서명(ML-DSA)은 아직 공개 CA에서 널리 발급되지 않습니다.

포스트 양자 TLS는 더 느린가요?

거의 그렇지 않습니다. ML-KEM-768은 연산 속도가 빠릅니다 — 종종 ECDHE보다도 빠릅니다. 주된 비용은 크기입니다. 더 큰 키 셰어가 핸드셰이크에 ~1 KB를 추가하며, 이는 패킷 한계가 매우 작은 네트워크에서만 추가 왕복 한 번의 비용을 초래할 수 있습니다. 거의 모든 사용자에게 그 차이는 측정 불가능한 수준입니다.

양자 컴퓨터가 실제로 언제 RSA를 깨뜨릴까요?

아무도 모릅니다. 신뢰할 만한 추정치는 2030년대 초부터 “어쩌면 대규모로는 영영 안 될 수도 있음”까지 다양합니다. 하지만 지금 수집하고 나중에 복호화 위협 때문에, 키 교환의 배포 마감 시한은 이미 도래했습니다 — 이것이 바로 브라우저와 CDN이 기다리지 않고 2024–2026년에 움직인 이유입니다.

TLS 1.2는 어떤가요?

포스트 양자 하이브리드 키 교환은 TLS 1.3 전용으로 정의되어 있습니다. 이것은 TLS 1.3 →을 활성화해야 하는 또 하나의 이유입니다 — 그것이 양자 안전 HTTPS로 가는 유일한 길입니다. TLS 1.2는 포스트 양자 키 교환을 받지 못합니다.

ML-KEM은 Kyber와 같은가요?

네 — ML-KEM은 이전에 CRYSTALS-Kyber라고 불렸던 알고리즘의 NIST 표준화 버전입니다. 이전 브라우저 빌드와 도구는 Kyber768을 표시하고, 표준화된 배포는 ML-KEM-768을 사용합니다. 둘은 밀접하게 관련되어 있지만 비트 단위로 동일하지는 않습니다. 그래서 최종 표준 클라이언트와 표준 이전 서버는 협상에 실패할 수 있습니다. 2026년 무렵 생태계는 대체로 최종 ML-KEM으로 이동했습니다.

지금 당장 뭔가 해야 하나요?

일반적인 웹사이트의 경우: TLS 1.3을 사용하고 있는지 확인하고, TLS 라이브러리를 최신 상태(OpenSSL 3.5+)로 유지하며, 수명이 긴 민감한 데이터를 다룬다면 PQC가 활성화된 CDN을 고려하세요. 그것만으로도 오늘날 양자 안전 키 교환을 확보하기에 충분합니다. 포스트 양자 인증서는 표준과 CA 도구가 성숙할 때까지 기다려도 됩니다.