포스트양자 TLS — X25519MLKEM768 하이브리드 키 교환 켜기

포스트양자 TLS는 미래의 양자컴퓨터로도 깨기 어려운 키 교환 알고리즘을 TLS 핸드셰이크에 도입하는 것을 말한다. 2026년 현재 실전 배치의 사실상 표준은 X25519MLKEM768이라는 하이브리드 방식이다. 기존의 검증된 타원곡선 키 교환(X25519)과 양자내성 알고리즘(ML-KEM-768, 옛 이름 Kyber)을 동시에 수행해, 둘 중 하나만 안전해도 세션 키가 보호되도록 설계했다. 주요 브라우저와 CDN이 이미 기본값으로 켜 둔 상태다.

"양자컴퓨터는 아직 멀었는데 왜 지금?"이라는 물음이 자연스럽다. 답은 harvest-now, decrypt-later다. 공격자가 오늘 암호화된 트래픽을 그냥 저장해 두고, 몇 년 뒤 양자컴퓨터가 나왔을 때 복호화하는 시나리오. 지금 오가는 데이터의 수명이 길다면(의료·금융·기밀), 방어는 미래가 아니라 지금 시작해야 한다.

왜 하이브리드인가 — 두 자물쇠

ML-KEM은 표준화됐지만 배포 이력은 X25519만큼 길지 않다. 새 알고리즘에 구현 결함이 있을 가능성을 배제할 수 없다. 그래서 둘을 합친다. 세션 키는 두 알고리즘의 결과를 결합해 만들어진다. 고전 알고리즘이 양자컴퓨터에 뚫려도 ML-KEM이 막아 주고, ML-KEM에 결함이 있어도 X25519가 막아 준다. 두 개의 자물쇠를 직렬로 채운 셈이라, 둘 다 깨져야 뚫린다.

서버에서 켜기 — 대부분 한 줄

좋은 소식은, 애플리케이션 코드를 바꿀 필요가 없다는 것이다. TLS 종단(리버스 프록시)에서 지원 그룹 목록에 하이브리드 그룹을 넣으면 된다. 최신 OpenSSL을 쓰는 nginx라면 이렇게.

# nginx — 키 교환 그룹에 하이브리드를 우선 배치
# (OpenSSL 3.5+ 등 ML-KEM 지원 빌드 필요)
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
ssl_protocols TLSv1.3;   # PQ 하이브리드는 TLS 1.3에서만

클라이언트가 하이브리드를 지원하면 그걸로 협상하고, 아니면 자동으로 X25519로 폴백한다. 즉 구형 클라이언트도 그냥 예전 방식으로 연결되니 하위 호환이 깨지지 않는다. 이 자동 폴백 덕분에 리스크가 낮다.

딱 하나 조심할 것 — 핸드셰이크가 커진다

공짜는 아니다. ML-KEM의 키/캡슐은 타원곡선 것보다 훨씬 크다(각각 1KB 남짓). 그래서 ClientHello가 커지고, 종종 한 패킷(1개 TCP 세그먼트)을 넘어 두 개로 쪼개진다. 대개는 문제없지만, 오래된 미들박스·로드밸런서·방화벽 중 일부가 첫 패킷만 보고 판단하다가 쪼개진 ClientHello를 오작동시키는 사례가 실제로 보고됐다. 나는 그래서 프로덕션에 켜기 전에 스테이징에서 핸드셰이크 성공률과 지연을 반드시 지켜본다.

연결 검증

실제로 하이브리드로 협상됐는지 확인하려면 협상된 그룹을 본다. 최신 OpenSSL 클라이언트라면 이렇게.

openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
  | grep -i "Negotiated TLS1.3 group"
# → Negotiated TLS1.3 group: X25519MLKEM768

정리하면, 대부분의 웹 서비스에서 포스트양자 TLS 도입은 "프록시 설정 한 줄 + 스테이징 검증"으로 끝난다. 어려운 건 알고리즘이 아니라, 경로 위의 낡은 네트워크 장비가 커진 핸드셰이크를 얌전히 통과시키느냐다. 그 확인만 챙기면 지금 당연히 켜 둘 값어치가 있다.

자주 묻는 질문

ML-KEM과 Kyber는 다른 건가요?

사실상 같습니다. Kyber가 표준화 과정을 거쳐 ML-KEM(FIPS 203)이라는 정식 이름으로 확정됐습니다. 뒤의 768은 보안 강도 파라미터로, TLS 하이브리드에서 널리 쓰이는 수준입니다. 문서마다 두 이름이 혼용되니 같은 계열로 이해하면 됩니다.

지금 안 켜도 나중에 켜면 되지 않나요?

지금 오가는 데이터가 미래에 복호화될 위험(harvest-now, decrypt-later)이 핵심입니다. 수명이 긴 민감 데이터라면 오늘의 트래픽이 이미 저장되고 있을 수 있으므로, 도입을 미룰수록 노출 창이 길어집니다. 수명이 짧은 데이터라면 급하지 않을 수 있습니다.

애플리케이션 코드를 고쳐야 하나요?

보통은 아닙니다. TLS를 종단하는 리버스 프록시나 로드밸런서에서 지원 그룹만 추가하면 되고, 앱은 그대로입니다. 다만 TLS 라이브러리와 OpenSSL 버전이 ML-KEM을 지원하는 빌드여야 하며, TLS 1.3이 전제입니다.

하이브리드를 켜면 기존 클라이언트가 접속 못 하나요?

그렇지 않습니다. 하이브리드를 모르는 클라이언트와는 자동으로 X25519 같은 기존 방식으로 협상합니다. 다만 경로상의 낡은 미들박스가 커진 ClientHello를 잘못 처리하는 드문 사례가 있으니, 배치 전 스테이징 검증을 권합니다.