이름이 왜 알고리즘 두 개를 붙여놨나요?

그게 바로 정체이기 때문입니다 — 하이브리드입니다. X25519는 브라우저가 수년간 써 온 타원곡선 키 교환이고, ML-KEM-768은 NIST가 FIPS 203으로 표준화한 양자내성 키 캡슐화입니다. 이 그룹은 둘을 동시에 돌려 결과를 합칩니다. 그래서 ML-KEM에 결함이 나와도 세션은 최소한 X25519만큼 강하고, 양자컴퓨터가 X25519를 깨도 최소한 ML-KEM만큼 강합니다. 완전히 새로운 수학에 전부를 걸지 않고 새 보호를 얻는 방식입니다.

X25519MLKEM768과 X25519Kyber768은 같은 건가요?

거의 같지만 와이어에서 호환되진 않습니다. 이전 그룹은 X25519Kyber768Draft00(코드포인트 0x6399)으로, 표준화 전 초안 Kyber 위에 만들어졌습니다. X25519MLKEM768(코드포인트 0x11EC)은 최종 표준인 ML-KEM-768을 쓰고, 기본값으로 배포된 쪽입니다 — 크롬은 131에서 전환했고 OpenSSL 3.5·Go 1.24·파이어폭스·애플 2025 OS가 모두 이걸 말합니다. 클라이언트와 서버는 같은 코드포인트에 합의해야 하므로, 0x11EC를 제안하는 최신 클라이언트는 0x6399만 아는 옛 서버와 PQ로 협상하지 못합니다.

브라우저가 X25519MLKEM768이라고 뜨면 내 서버가 지원한다는 뜻인가요?

꼭 그렇진 않습니다. 브라우저는 '연결에 응답한 그 무언가'와 협상한 결과를 보여주는데, 대부분 사이트는 그게 오리진 서버가 아니라 CDN 엣지입니다. 하이브리드 키 교환이 Cloudflare 같은 CDN에서 끝나는 동안, 그 엣지에서 실제 서버까지의 구간은 여전히 고전 X25519일 수 있습니다. Cloudflare는 2026년 9월에, 자사 네트워크에 도착하는 사람 HTTPS 트래픽의 약 67%가 이미 양자내성 키 교환을 쓰는 반면, 연결하는 오리진은 약 15%만 그렇다고 밝혔습니다. 어느 쪽인지 알려면 오리진을 직접 검사해야 합니다.

X25519MLKEM768을 쓰려면 양자내성 인증서가 필요한가요?

아니요. 키 교환과 인증서는 별개 문제입니다. X25519MLKEM768은 키 합의 — 오늘 훔쳐서 나중에 복호화할 가치가 있는 부분 — 를 보호하고, 기존 RSA·ECDSA 인증서와 잘 작동합니다. 양자내성 서명은 나중 과제이고, 공개 CA는 아직 양자내성 인증서를 발급하지도 않습니다. 키 교환부터 바꾸세요, 인증서는 그대로 두고.

X25519MLKEM768이란? 하이브리드 키 교환

X25519MLKEM768은 사실 무엇인가

크롬 DevTools의 Security 패널, openssl s_client, 또는 Cloudflare 대시보드에서 X25519MLKEM768을 봤다면, 연결이 협상한 키 교환을 본 것입니다. 이름은 고양이가 키보드 위를 걸어간 것 같지만, 그냥 알고리즘 두 개를 나란히 적은 것뿐입니다:

X25519 — 브라우저가 수년간 의지해 온 타원곡선 디피-헬만 키 교환. 빠르고 작고(공개키 32바이트), 그리고 큰 양자컴퓨터가 존재한다면 완전히 깨집니다.
ML-KEM-768 — NIST가 2024년 FIPS 203으로 표준화한 양자내성 키 캡슐화 메커니즘(중간 등급, Level 3). 고전·양자 공격 모두에 견디도록 설계됐고, Kyber라 불리던 알고리즘의 후계자입니다.

둘을 합치면 하이브리드 키 교환이 됩니다 — 둘을 동시에 수행하는 단일 TLS 1.3 명명 그룹(코드포인트 0x11EC, IANA 레지스트리에서 Recommended 표시). 클라이언트는 ML-KEM-768 캡슐화 키 와 X25519 공개키를 한데 담은 키 셰어를 제안하고, 서버는 ML-KEM 암호문과 자신의 X25519 키로 답합니다. 양쪽은 각 알고리즘에서 공유 비밀을 하나씩 뽑아 그 조합을 TLS 1.3 키 스케줄에 넣습니다. 결과 세션 키는 둘 모두에 의존합니다 — 그게 핵심입니다.

왜 새것만 쓰지 않고 둘을 짝지었나

아직 아무도 새것을 완전히 믿지 않고, 그게 옳기 때문입니다.

ML-KEM은 어립니다. NIST 공모와 표준화를 거쳤으니 암호 원시함수가 받을 수 있는 최대한의 검증을 받았지만, ‘과정을 통과했다’는 ‘사람들이 20년간 실전에서 깨보려 한 걸 버텼다’와 다릅니다. 격자 암호가 언젠가 나쁜 날을 맞을 수도 있습니다. 그래서 X25519를 ML-KEM으로 갈아치우고 기도하는 대신, 하이브리드는 둘을 나란히 돌립니다. 공격자는 세션을 복원하려면 둘 다 깨야 합니다 — 오래 검증된 곡선 과 새 양자내성 격자. 둘 중 하나만 버텨도 당신 트래픽은 비밀로 남습니다.

이 모든 것의 배경에는 수수한 이름의 위협이 있습니다 — 지금 수집, 나중에 복호화(harvest now, decrypt later). 오늘 X25519를 못 깨는 적도 당신의 암호화된 트래픽을 오늘 녹음해 두고 깔고 앉아 있을 수 있습니다. 암호학적으로 유의미한 양자컴퓨터가 도착하는 날 — 몇 년 뒤일 수도 있지만 녹음은 싸고 끈질깁니다 — 그들은 밀린 것을 복호화합니다. 비밀 유효기간이 긴 것(의료기록·소스코드·국가기밀·비밀번호 관리자 동기화 내용)은 이미 그 내기에 노출돼 있습니다. 하이브리드 키 교환은 그 컴퓨터가 존재하기 전에 배포하는 방어입니다 — 나중에 배포하면 정의상 이미 늦었으니까요. 키 교환이 먼저 가고 서명이 기다려도 되는 이유도 같습니다 — 서명은 핸드셰이크 순간에만 위조에 견디면 되지만, 키 합의는 데이터가 유효한 기간 내내 비밀이어야 합니다.

와이어에서는 어떻게 보이나

하이브리드는 공짜가 아니고, 그 대가는 크기입니다. X25519 공개키는 32바이트입니다. ML-KEM-768 캡슐화 키는 1,184바이트, 암호문은 1,088바이트입니다. 그래서 클라이언트 키 셰어가 32바이트에서 1킬로바이트를 훌쩍 넘고, 한 패킷에 넉넉히 들어가던 ClientHello가 이제 흔히 ~1,500바이트 경로 MTU를 넘어 두 번째 패킷으로 흘러넘칩니다. 압도적 다수의 연결에서는 이게 안 보입니다. 하지만 패킷에 쪼개진 ClientHello에 체하는 일부 고장난 미들박스·버그 서버가 하이브리드 롤아웃과 함께 실패하기 시작한 건 실제 이유였고 — 그건 그것대로 ‘누가 취약한 네트워크 장비를 돌리는가’에 관한 일종의 정찰 신호입니다.

이미 가지고 있는 곳(과 아닐 수 있는 곳)

이건 꽤 오래전에 실험 단계를 벗어났습니다. X25519MLKEM768은 최신 클라이언트 스택의 기본 제안입니다:

크롬 131(2024년 11월) 이후, 그리고 다른 크로미움 브라우저.
파이어폭스와 애플의 2025 OS(iOS 26 물결이 애플 기기 채택을 가파르게 끌어올림).
Go 1.24(2025년 2월) 이후, crypto/tls에서 기본 활성.
OpenSSL 3.5.0(2025년 4월) 이후, 그룹을 이해할 뿐 아니라 선호함.

틈은 서버 쪽에 있고, 넓습니다. 브라우저가 X25519MLKEM768을 보여줄 때, 그건 TLS 연결을 종료시킨 무언가와 협상한 것이고 — 대부분 사이트에선 그게 오리진이 아니라 CDN입니다. CDN 엣지는 방문자에게 하이브리드를 말하면서, 엣지에서 실제 서버까지의 홉은 조용히 고전 X25519로 떨어질 수 있습니다. 그게 CDN 상속 함정입니다 — 대중이 보는 절반은 보호되고, 그 뒤 절반은 아닐 수 있습니다. Cloudflare의 2026년 9월 수치가 그 분할을 잡아냈습니다 — 엣지에 도착하는 사람 HTTPS 트래픽의 약 67%가 양자내성 키 교환을 쓴 반면, 그 뒤로 연결하는 오리진은 약 15%뿐이었습니다.

연결이 정말 이걸 쓰는지 확인하는 법

세 가지 방법을, 알려주는 정보가 많은 순서로:

브라우저에서: 최신 크롬으로 사이트를 열고 DevTools → Security에서 키 교환 줄을 읽습니다. 빠르지만 당신 브라우저가 엣지와 협상한 것만 보여줍니다 — 오리진이 아니라.
OpenSSL 3.5+로: openssl s_client -connect example.com:443 -groups X25519MLKEM768. 핸드셰이크가 끝나면 그 엔드포인트는 하이브리드를 지원하는 것이고, handshake_failure 경고가 오면 아닙니다. 오리진의 실제 주소로 겨누면 CDN 너머를 봅니다.
DechoNet PQC 점검으로: 하이브리드 그룹만 제안해 키 교환이 완료됐는지 알려주고, 지원이 오리진이 아니라 CDN 엣지에서 오는 경우를 표시하며, 결과를 시간에 따라 기록합니다. nginx·Apache·Go에서 켜는 단계별 방법을 포함한 자매 가이드는 양자내성 TLS 점검을, 전환을 몰아가는 일정은 양자내성암호 전환 일정을 보세요.

DechoNet으로 진단

PQC 점검은 호스트가 X25519MLKEM768을 협상하는지 검사하고, 지원이 CDN 엣지에서 멈추는지 알려줍니다.
SSL 점검은 인증서와 TLS 버전을 보여주어, 연결이 이 그룹이 존재하는 유일한 버전인 TLS 1.3인지 확인해 줍니다.

이건 무엇이 아닌가

인증서 변경이 아닙니다. RSA·ECDSA 인증서는 멀쩡하니 그대로 두세요.
DNS나 인증서에서 ‘켜는’ 것이 아닙니다 — 서버 TLS 라이브러리의 능력이라, 해법은 보통 “OpenSSL을 3.5+로 / Go를 1.24+로 / 프록시를 그룹을 제안하는 빌드로 업그레이드”입니다.
완전한 양자내성 전환이 아닙니다. 그 전환의 가장 처음이자 가장 급한 단계입니다 — 오늘 이뤄지는 녹음을 막는 단계이기 때문입니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.