PQ 인증서가 아직 안 오는 이유 — ML-DSA 서명 크기, 10kB의 벽, 그리고 Merkle Tree Certificates

들어가며 — 암호화는 절반쯤 왔고, 인증은 아직 출발선이다
문제는 전부 크기다 — FIPS 204가 정한 숫자
왜 핸드셰이크에 서명이 5개나 들어 있나
10kB의 벽 — 2021년 Cloudflare 측정
Merkle Tree Certificates — 서명을 아예 빼 버리는 설계
736바이트라는 숫자에 붙은 조건들
지금 어디까지 왔나 — PLANTS, Chrome, Let's Encrypt
이 접근에 대한 반론과 남은 구멍
그래서 지금 당장 뭘 해야 하나
마치며
참고 자료

들어가며 — 암호화는 절반쯤 왔고, 인증은 아직 출발선이다

지난 몇 년간 포스트양자 암호(PQC) 이야기는 사실상 키 교환 이야기였습니다. 논리는 단순했습니다 — 지금 오가는 암호문을 그대로 저장해 뒀다가 훗날 양자 컴퓨터로 푸는 공격, 이른바 harvest now, decrypt later(HNDL)가 가능하니, 암호화는 오늘 당장 바꿔야 한다는 것이었습니다. 그래서 하이브리드 키 교환인 X25519MLKEM768이 브라우저와 서버에 빠르게 깔렸습니다. Cloudflare는 2025년 10월 기준으로 자사 엣지 네트워크로 들어오는 트래픽의 약 50%가 이 위협으로부터 보호되고 있다고 밝혔습니다(벤더 자체 측정 — 모집단은 Cloudflare 엣지에 도달한 트래픽이며, 인터넷 전체가 아닙니다).

인증(authentication)은 사정이 다릅니다. 서명 위조는 저장해 뒀다가 나중에 할 수 있는 일이 아니라 연결이 살아 있는 그 순간에 해내야 합니다. 그래서 서명은 HNDL의 대상이 아니고, 위협은 실제로 암호학적으로 유의미한 양자 컴퓨터(CRQC)가 존재하느냐에 달려 있습니다. Let's Encrypt의 표현을 빌리면, 그 사실이 그동안 인증 쪽을 미뤄 둘 수 있는 "위안"이었습니다.

그런데 진짜 이유는 따로 있습니다. PQ 인증서를 그냥 갈아끼우면 웹이 느려집니다. 그것도 아직 오지 않은 위협에 대비하는 대가로 오늘 당장 느려집니다. 이 글은 그 트레이드오프의 숫자를 1차 출처에서 확인하고, 업계가 그 대가를 피하려고 택한 우회로가 무엇인지 살펴봅니다.

문제는 전부 크기다 — FIPS 204가 정한 숫자

먼저 숫자부터 못 박고 가겠습니다. NIST FIPS 204의 Table 2가 ML-DSA의 키·서명 크기를 바이트 단위로 규정합니다.

파라미터 세트     개인키    공개키    서명       (FIPS 204 Table 2)
ML-DSA-44        2560     1312     2420       보안 강도 카테고리 2
ML-DSA-65        4032     1952     3309       보안 강도 카테고리 3
ML-DSA-87        4896     2592     4627       보안 강도 카테고리 5

비교 대상은 이렇습니다. 오늘날 웹에서 가장 흔한 서명인 ECDSA P-256은 서명 64바이트, 공개키 64바이트입니다. RSA-2048은 서명 256바이트, 공개키 256바이트입니다. Ed25519는 키 32바이트에 서명 64바이트입니다(RFC 8032, MTC 드래프트가 인용한 값).

즉 ML-DSA-44는 ECDSA P-256 대비 대략 20배입니다. Cloudflare는 이를 "roughly a 20-fold increase in size"라고 표현했습니다. 여기서 중요한 건, ML-DSA-44가 가장 작은 선택지라는 점입니다. 참고로 해시 기반인 SLH-DSA(FIPS 205, 옛 SPHINCS+)는 Cloudflare 측정 기준 39kB를 더하며 서명·검증 계산 비용도 큽니다. 대신 해시에만 기대므로 안전성이 훨씬 잘 이해돼 있다는 장점이 있습니다 — 크기와 신뢰도의 교환입니다.

왜 핸드셰이크에 서명이 5개나 들어 있나

크기가 20배라는 것만으로는 그림이 안 나옵니다. 핵심은 핸드셰이크가 서명을 몇 개나 나르느냐입니다. Cloudflare의 Merkle Tree Certificates 소개 글(2025년 10월 28일, Luke Valenta·Christopher Patton·Vânia Gonçalves·Bas Westerbaan)이 이 계단을 하나씩 쌓아 보여 줍니다.

클라이언트가 서버의 공개키를 이미 알고 있다면 서명 1개면 충분합니다. 그런데 웹에는 TLS 서버가 약 10억 개 있고 키는 계속 바뀝니다. 모든 클라이언트에 모든 서버의 공개키를 미리 심어 두는 건 불가능합니다. PKI 설계의 출발점이 이 확장성 문제입니다.
그래서 인증서가 등장합니다. CA가 "이 공개키는 이 도메인의 것"이라고 서명해 줍니다. 서명 +1, 공개키 +1 → 합계 서명 2개, 공개키 1개.
요즘 체인은 보통 인증서 2장 이상입니다. CA도 키를 교체해야 하는데, 새 공개키가 수십억 클라이언트의 신뢰 저장소에 퍼지는 데는 시간이 걸립니다. 그 공백을 메우려고 옛 키로 새 키의 인증서를 발급해 체인 끝에 붙입니다. 서명 +1, 공개키 +1 → 서명 3개, 공개키 2개.
마지막으로 Certificate Transparency입니다. Chrome·Safari·Firefox는 인증서가 신뢰받는 로그 최소 2곳에 실려야 받아들입니다. 로그마다 SCT 서명이 하나씩 붙습니다. 서명 +2 → 최종적으로 서명 5개, 공개키 2개.

Cloudflare의 표현이 이 상황을 정확히 요약합니다 — WebPKI에서 뭔가 고쳐야 할 때마다 서명을 하나씩 덧붙여 왔고, 전통 암호가 워낙 싸서 그 전략이 통했다는 것입니다. 이제 그 청구서가 돌아옵니다.

FIPS 204의 크기와 Cloudflare가 센 개수를 곱하면 이렇게 됩니다(아래는 두 1차 출처를 조합한 제 산수이지, 어느 한쪽이 발표한 측정치가 아닙니다).

ML-DSA-44로 전부 교체할 경우의 인증 데이터:
  서명 5개 x 2,420 =  12,100 바이트
  공개키 2개 x 1,312 =  2,624 바이트
  ------------------------------------
  합계                 14,724 바이트

같은 개수를 ECDSA P-256으로 계산하면:
  서명 5개 x 64 + 공개키 2개 x 64 = 448 바이트
(실제 체인은 RSA가 섞이므로 실전 값은 이보다 큽니다)

MTC 드래프트 자체는 더 보수적인 셈법도 제시합니다. draft-ietf-tls-trust-anchor-ids로 중간 인증서를 직접 신뢰하게 만들어 체인을 줄이더라도, SCT 2개와 리프 인증서 서명 1개만으로 ML-DSA-44 기준 7,260바이트, ML-DSA-65 기준 9,927바이트의 인증 오버헤드가 붙는다고 적혀 있습니다. 즉 체인을 최대한 짧게 깎아도 만 바이트 언저리입니다.

10kB의 벽 — 2021년 Cloudflare 측정

그래서 만 몇 천 바이트가 왜 문제일까요. 여기서부터는 이론이 아니라 측정입니다. Cloudflare가 2021년 11월 8일에 공개한 Sizing Up Post-Quantum Signatures(Bas Westerbaan)는 실제 인터넷에서 자사 네트워크로 들어오는 연결에 더미 인증서를 붙여 크기 영향을 측정한 대규모 실험입니다. 벤더 자체 측정이고, 모집단은 Cloudflare 네트워크에 도달한 실제 클라이언트 연결입니다.

배경 개념 하나가 필요합니다. TCP는 혼잡을 피하려고 처음에 패킷을 조금만 보냅니다 — 보통 10개, 약 14kB입니다. 이게 초기 혼잡 윈도우(initcwnd)입니다. 여기를 넘으면 왕복이 한 번 더 생깁니다.

측정 결과는 두 가지였습니다(Cloudflare가 후속 글에서 직접 요약한 문장 기준).

실패: 기존 인증서 체인에 10kB 넘게 더하자 클라이언트와 미들박스의 실패율이 가파르게 올랐습니다. 그래프에서 10kB와 30kB에 튀는 구간이 나타났고, 이는 그 크기를 감당 못 하는 클라이언트나 미들박스가 존재한다는 뜻입니다.
지연: 9kB 미만을 더했을 때 TLS 핸드셰이크 시간이 약 15% 느려졌습니다. Cloudflare는 이 정도면 "감당은 되지만 이상적이지는 않다"고 평가했습니다.

여기서 자주 오해되는 대목을 짚고 갑니다. Cloudflare 자신의 initcwnd는 표준값 10이 아니라 30패킷입니다. 그래서 35kB를 더해도 초기 혼잡 윈도우 안에 들어갑니다. 그런데도 중앙값 핸드셰이크가 40% 느렸고, 느린 쪽 10%는 60%만큼 더 걸렸습니다. Cloudflare의 결론이 이것입니다 — 혼잡 윈도우 안에 들어간다고 해서 추가 데이터가 공짜인 것은 전혀 아니다.

구체적 대입도 있습니다. Dilithium2(ML-DSA-44의 전신)를 드롭인으로 쓰면 약 17kB가 추가되는데, Cloudflare의 30패킷 윈도우에서는 중앙값 20% 저하였습니다. 그리고 표준 initcwnd 10에서는 60~80% 저하를 예상한다고 적었습니다 — 이건 측정이 아니라 Cloudflare의 추정입니다.

브라우저 쪽 기준선도 참고가 됩니다. Chrome은 TLS 핸드셰이크 시간 회귀 상한을 10%로 잡고 있고, PQ 키 합의를 배포하면서 이미 4% 저하를 겪었다고 보고했습니다 — 서버에서 클라이언트로 1.1kB, 클라이언트에서 서버로 1.2kB가 늘어난 대가입니다. Cloudflare는 이 비율이 자사의 "9kB에 15%"보다 비례적으로 크다는 점을 지적하며, 업로드가 다운로드보다 느린 탓일 수 있다고 해석했습니다.

Cloudflare가 2021년에 내린 실무적 결론은 한 문장으로 남았습니다 — 서명 6개와 공개키 2개가 9kB 안에 들어가면 전환이 가장 쉬울 것이라는 것. 앞서 계산한 14,724바이트는 그 목표의 한참 바깥입니다.

한 가지 정직하게 덧붙이면, 이 측정은 2021년 것입니다. 미들박스도 클라이언트도 그 사이 바뀌었을 수 있고, Cloudflare 자신도 이후 글에서 이 데이터를 계속 인용하되 갱신된 대규모 실측을 새로 제시하지는 않았습니다.

Merkle Tree Certificates — 서명을 아예 빼 버리는 설계

숫자가 저러면 선택지는 셋입니다. (1) 그냥 느려지는 걸 받아들인다, (2) Q-day가 가까워질 때까지 미룬다, (3) 핸드셰이크에서 나르는 서명 개수 자체를 줄인다.

(2)는 위험합니다. 마이그레이션은 항상 예상보다 오래 걸리고, Cloudflare의 표현으로는 "불장난"입니다. 업계가 택한 건 (3)입니다.

핵심 아이디어는 이렇습니다. 인증서를 하나씩 따로 서명하지 말고, 배치로 묶어서 트리 하나의 머리(tree head)에만 서명한다. 각 인증서는 그 트리의 잎이 되고, 내부 노드는 자식들의 해시입니다. 그러면 브라우저에 보내는 "인증서"는 무거운 서명 체인이 아니라 그 트리에 내가 들어 있다는 가벼운 포함 증명(inclusion proof) 이 됩니다. Google의 표현을 그대로 옮기면, CA가 수백만 장을 대표하는 트리 헤드 하나에 서명하고, 브라우저로 가는 인증서는 그 트리에 대한 경량 포함 증명일 뿐입니다.

용어는 draft-ietf-plants-merkle-tree-certs-05(2026년 7월 6일, 100쪽 — David Benjamin/Google, Devon O'Brien/Apple, Bas Westerbaan·Luke Valenta/Cloudflare, Filippo Valsorda/Geomys)의 정의를 따르는 게 정확합니다.

Cosignature: CA 또는 다른 cosigner가 체크포인트나 서브트리에 하는 서명.
Landmark: 신뢰된 서브트리를 relying party에 미리 배포하기 위해 쓰는, 드문드문한 트리 크기들의 부분집합.
Standalone certificate: 어떤 서브트리로의 포함 증명 + 그 서브트리에 대한 cosignature 여러 개.
Landmark-relative certificate: landmark 서브트리로의 포함 증명만 있고 서명이 하나도 없는 최적화된 인증서.

마지막 항목이 이 설계의 핵심입니다. 클라이언트가 landmark를 미리 알고 있으면, 서버는 서명을 아예 보내지 않아도 됩니다.

덤이 하나 더 있습니다. Certificate Transparency가 설계에 내장됩니다. 오늘날 CT는 나중에 덧댄 구조입니다 — CA가 발급하고, 따로 로그에 싣고, 그 사실을 증언하는 SCT 서명을 핸드셰이크에 얹습니다. MTC에서는 인증서가 머클 트리 바깥에 존재할 수가 없습니다. Google의 표현으로는 공개 트리에 넣지 않고 인증서를 발급하는 것이 불가능합니다. 그래서 오늘의 CT가 주는 보안 속성이 기본으로 따라오면서, 핸드셰이크에 얹히던 SCT 오버헤드는 사라집니다.

드래프트는 로그 운영 비용 쪽 이득도 짚습니다. 로그 엔트리가 공개키를 해시로 대체하고 서명을 담지 않으므로, 로그 엔트리 크기가 공개키·서명 크기에 비례해 커지지 않습니다. 그리고 만료된 지 오래된 엔트리는 pruning할 수 있어서, 로그 크기가 로그의 수명이 아니라 보존 정책에 따라 정해집니다. 인증서 수명이 짧아지는 추세와 맞물리는 부분입니다.

736바이트라는 숫자에 붙은 조건들

MTC를 소개하는 기사들이 즐겨 인용하는 숫자가 736바이트입니다. 이 숫자의 출처는 Google이나 Cloudflare의 블로그가 아니라 드래프트 6.5절 Size Estimates이고, 조건이 촘촘하게 붙어 있습니다. 조건을 빼고 인용하면 오해가 됩니다.

드래프트가 명시한 가정은 이렇습니다.

로그의 해시 함수는 SHA-256.
2025년 6월 9일 기준 공개 통계: Let's Encrypt 단일 CA의 유효 인증서 약 5억 5,800만 장, MerkleTown 기준 CT 로그의 미만료 인증서 전체 약 21억 장, 전체 CA 발급률 시간당 약 44만 4천 장.
단기 인증서로 전환된 웹을 가정: 인증서 수명 7일, 구독자가 수명의 75% 지점에서 갱신 → 126시간마다 재발급 → CA 하나당 시간당 약 440만 장, 전체 약 1,700만 장.

이 가정 위에서 계산이 나옵니다.

landmark를 매시간 하나씩 할당하는 경우:
  서브트리가 약 4,400,000장을 포함
  -> 포함 증명 해시 23개
  -> 736 바이트, 서명 없음

standalone 인증서 (체크포인트를 2초마다 찍는 경우):
  서브트리가 약 2,500장을 포함
  -> 포함 증명 해시 12개 = 384 바이트
  -> 여기에 relying party 요구를 채울 만큼의 서명을 추가로 실어야 함

증명 크기는 로그 스케일:
  해시 32개 = 1024 바이트면 2^32(약 43억)장까지 커버

드래프트가 직접 붙인 비교가 인상적입니다 — 736바이트는 ML-DSA-44 서명 단 하나(2,420바이트)보다도 작고, PQ SCT를 포함하는 데 필요한 ML-DSA-44 서명 3개(7,260바이트)보다 거의 10배 작습니다. 포스트양자 알고리즘을 쓰면서도 오늘의 핸드셰이크보다 작아진다는 Let's Encrypt의 주장이 여기서 나옵니다.

다만 강조해야 할 점이 있습니다. 이건 측정이 아니라 명시된 가정 위의 추정치입니다. 드래프트 스스로도 현재 웹 PKI의 발급률이 단기 인증서 전환 이후의 웹을 대표하지 않을 수 있다고 적어 뒀습니다. 그리고 736바이트는 landmark-relative 인증서, 즉 최신 상태인 클라이언트에만 해당합니다. 드래프트 초록의 표현 그대로, 이 최적화는 "최신 상태의 relying party와 더 오래된 인증서에만 적용된다"는 대가를 치릅니다.

지금 어디까지 왔나 — PLANTS, Chrome, Let's Encrypt

이 설계가 슬라이드웨어가 아니라는 근거는 일정과 코드입니다.

IETF. PLANTS 워킹그룹(PKI, Logs, And Tree Signatures)이 만들어져 활동 중입니다. 차터에 적힌 목표는 명확합니다 — CT(RFC 6962, RFC 9162)를 쓰는 PKI에서 큰 포스트양자 서명의 비용을, TLS(RFC 8446) 같은 대화형 프로토콜에서 줄이는 것. 차터는 크기가 주된 동기이지만 결과물이 전통 서명에도 쓰일 수 있게 하겠다고 밝힙니다. WG 드래프트는 위에서 본 -05(2026년 7월 6일)까지 왔습니다.

Chrome. Google은 2026년 2월 Cultivating a robust and efficient quantum-safe HTTPS에서 방침을 못 박았습니다. 생태계의 확장성과 효율을 위해 PQC를 담은 전통 X.509 인증서를 Chrome Root Store에 추가할 즉각적인 계획은 없다는 것입니다. 대신 MTC를 밀고, 롤아웃을 3단계로 잡았습니다.

Phase 1(진행 중): Cloudflare와 함께 feasibility study. 이 실험에서 모든 MTC 기반 연결은 전통적인, 신뢰된 X.509 인증서로 뒷받침됩니다. Google이 "fail safe"라고 부르는 장치로, 사용자 연결의 보안이나 안정성을 걸지 않고 실제 성능 이득과 발급 신뢰성을 측정하기 위한 것입니다.
Phase 2(2027년 1분기 목표): 2026년 2월 1일 이전에 Chrome에서 "usable" 로그를 하나 이상 운영한 CT 로그 운영자를 초대해 공개 MTC 인프라를 부트스트랩. 이 단계 초입에 새 신뢰 저장소인 CQRS(Chrome Quantum-resistant Root Store) 와, MTC만 지원하는 루트 프로그램의 요구사항을 확정합니다. 기존 Chrome Root Program과 병행 운영하고, 사이트가 다운그레이드 보호를 opt-in할 수 있게 합니다.
Phase 3(2027년 3분기 목표): 추가 CA를 CQRS에 온보딩.

Google은 사설 PKI(Chrome Root Store에 들어가지 않는 PKI)용으로는 양자 저항 알고리즘을 쓰는 "전통적" X.509를 올해 안에 지원할 것으로 본다고 덧붙였습니다. 공개 웹과 사설 PKI의 경로가 갈린다는 뜻입니다.

Cloudflare. 실험 방식이 영리합니다. 제대로 된 CA가 되려면 브라우저 신뢰를 얻는 데 몇 년이 걸리므로, Cloudflare는 이번 실험에서 진짜 CA가 되지 않고 MTCA 역할을 mock합니다. Workers 위에 StaticCT 로그 기반으로 MTCA를 돌리되, 발급하는 MTC마다 신뢰된 CA가 발급한 기존 인증서를 함께 공개합니다. 이걸 bootstrap certificate라 부릅니다. Chrome 인프라가 MTCA 로그를 당겨올 때 이 bootstrap 인증서도 같이 받아 서로 일치하는지 확인하고, 일치할 때만 landmark를 Chrome 클라이언트에 밀어 줍니다. 요컨대 Cloudflare는 (신뢰된 CA가 도메인 검증을 한) 기존 인증서를 MTC로 "재인코딩"할 뿐이고, Chrome은 CT로 Cloudflare를 견제합니다. 신뢰 관계를 하나도 바꾸지 않고 설계를 실험하는 방법입니다. 대상은 측정에 쓸 만한 트래픽이 있는 무료 고객 일부이며, 롤아웃 속도는 Chrome이 통제합니다.

Let's Encrypt. 2026년 6월 3일 Andrew Gabbitas가 쓴 A Post-Quantum Future for Let's Encrypt에서 MTC를 경로로 채택한다고 밝혔습니다. 목표는 2026년 말 MTC를 발급하는 스테이징 환경, 2027년 프로덕션 준비 환경입니다. Let's Encrypt는 이게 작은 일이 아니라고 분명히 적습니다 — 발급 인프라, 구독자가 쓰는 ACME 프로토콜, 폐기·운영 도구, 그리고 MTC가 흡수해 버리는 투명성 로그 인프라까지 스택 전반이 바뀌어야 합니다. 근거로 드는 자산은 2019년부터 운영해 온 CT 로그입니다. 그 로그가 append-only 머클 트리, 즉 MTC와 같은 자료구조라는 것입니다.

주변 표준과 구현. ML-DSA를 X.509에 쓰는 규약은 RFC 9881(2025년 10월, Standards Track)로 이미 나왔고, TLS 1.3에서 쓰는 쪽은 draft-ietf-tls-mldsa(2026년 7월 8일 기준 -05)가 진행 중입니다. 언어 런타임도 따라옵니다 — Go는 crypto/mldsa 패키지를 새로 넣어 FIPS 204의 ML-DSA를 구현하고, crypto/x509가 ML-DSA 키와 서명을, crypto/tls가 TLS 1.3에서 MLDSA44/MLDSA65/MLDSA87 SignatureScheme을 지원합니다. 다만 이건 Go 1.27 릴리스 노트 기준이고, 1.27은 아직 출시 전입니다(현재 stable은 1.26.x). Let's Encrypt가 "포스트양자 서명이 실용 인프라가 되고 있다는 신호"로 이걸 꼽았습니다.

이 접근에 대한 반론과 남은 구멍

여기까지 읽으면 MTC가 깔끔한 승리처럼 보입니다. 정직하게 반대편도 봅시다. 흥미롭게도 아래 반론 중 상당수는 Cloudflare 자신이 자기 글에 적어 둔 것입니다.

"핸드셰이크 시간에 집착하는 게 맞느냐"는 pushback이 있습니다. 근거는 둘입니다. 첫째, 세션 재개(session resumption)를 쓰면 인증서를 매번 다시 보낼 필요가 없습니다. 둘째, 전형적인 웹사이트 방문이 옮기는 데이터량은 PQ 인증서가 더하는 몇 kB를 압도합니다. Cloudflare가 직접 인용하는 예가 2024년 Amazon 연구자들의 시뮬레이션 논문인데, 전형적 연결은 요청을 여러 번 보내고 수백 kB를 옮기므로 그런 연결에서는 핸드셰이크 저하가 오차 범위로 묻힌다는 주장입니다. 참고로 Cloudflare 자신도 TLS 핸드셰이크는 웹페이지를 띄우기까지의 긴 사슬에서 5~20% 정도를 차지하는 한 단계라고 적었습니다.

MTC의 이득은 클라이언트가 최신일 때만 나옵니다. Cloudflare가 이번 실험에서 답을 얻고 싶어 하는 질문이 정확히 이것입니다 — "얼마나 많은 클라이언트가 최신 상태를 유지할 것인가?" MTC의 수명은 일주일 남짓으로 예상되는데, 클라이언트가 가진 최신 landmark가 그보다 오래됐으면 서버는 더 큰 인증서로 폴백해야 합니다. 그 폴백이 얼마나 자주 일어나는지가 프로토콜 파라미터 튜닝의 핵심이고, 아직 답이 없습니다. 736바이트짜리 장밋빛 숫자와 standalone 폴백 사이의 실제 비율은 이 실험이 끝나야 나옵니다.

새 신뢰 저장소는 공짜가 아닙니다. CQRS는 기존 Chrome Root Store와 별개로 MTC만 지원하는 루트 프로그램입니다. 기술적으로는 깨끗하지만, 생태계를 둘로 나누고 CA들에게 새 편입 경로를 요구하는 일이기도 합니다. Google 자신이 이를 "risk-managed transition"이라 부르며 두 트랙을 병행하겠다고 밝힌 건, 그만큼 운영 부담이 크다는 뜻이기도 합니다.

일정은 전부 예측입니다. 그리고 예측의 뿌리인 Q-day는 아무도 모릅니다. 여기서 특히 조심해야 합니다. Let's Encrypt는 "올해 들어 일정이 더 당겨졌다"며 Google이 CRQC 도래 추정이 좁혀지는 것을 근거로 2029년까지 자사 서비스를 마이그레이션하겠다고 발표했고 Cloudflare가 뒤따랐다고 적었습니다. 이건 그 회사들의 예측이자 선언이지, 양자 컴퓨터가 2029년에 온다는 사실이 아닙니다.

규제 일정도 초안입니다. 흔히 인용되는 NIST의 전환 지침 IR 8547은 2024년 11월 12일 공개된 초기 공개 초안(Initial Public Draft) 이고, 의견 수렴은 2025년 1월 10일에 닫혔습니다. 내용도 흔한 요약보다 결이 있습니다. 초안의 표는 서명 알고리즘군을 보안 강도로 나눠, 112비트 강도(RSA-2048 등)는 2030년 이후 deprecated, 2035년 이후 disallowed로, 128비트 이상은 2035년 이후 disallowed로 적었습니다. 즉 "RSA와 ECC가 2030년에 다 죽는다"는 식의 요약은 초안의 표보다 거칩니다. 그리고 Let's Encrypt가 짚듯 이런 지침은 공개 웹 PKI를 직접 구속하지 않습니다 — 다만 웹 PKI가 기대는 벤더·라이브러리·표준 단체가 그 시계에 맞춰 움직이게 만듭니다. NSA의 CNSA 2.0은 2022년부터 국가안보 시스템에 2030~2035 일정을 제시했고, EU 로드맵은 고위험 시스템 2030년 말, 광범위 마이그레이션 2035년을 목표로 합니다.

그래서 지금 당장 뭘 해야 하나

이 글의 실무적 결론은 조금 김빠지는 쪽입니다. 지금 서버 운영자가 할 일은 인증서가 아니라 키 교환입니다.

Let's Encrypt가 글 말미에 남긴 권고가 정확히 그렇습니다. 넓은 인터넷 커뮤니티에게 더 급한 문제는 포스트양자 암호화인데, PQ 키 교환이 없는 TLS 연결은 나중에 복호화하려고 지금 수확당할 수 있기 때문입니다. 서버를 운영한다면 하이브리드 PQ 키 교환(X25519MLKEM768)을 지원하도록 하십시오. 주요 브라우저와 OS는 이미 지원하며, 서버에서 이걸 켜는 것이 올해 할 수 있는 가장 레버리지 큰 일이라는 게 그들의 표현입니다.

인증서 쪽은 아직 표준이 안 끝났으므로 지금 할 수 있는 건 세 가지입니다.

추적. ACME 클라이언트를 유지보수하거나 ACME 기반 인증서 파이프라인을 운영한다면, PLANTS 워킹그룹과 mtcs@chromium.org 메일링 리스트를 지켜볼 시점입니다. Let's Encrypt가 직접 그렇게 권합니다 — 다가올 변경 중 일부는 클라이언트 측 지원을 요구하고, 발급 쪽이 준비됐을 때 클라이언트도 준비돼 있어야 생태계가 굴러갑니다.
인벤토리와 암호 민첩성. 어디서 어떤 서명을 쓰는지 모르면 어떤 일정도 의미가 없습니다. 공개 웹 PKI와 사설 PKI는 경로가 갈립니다 — 사설 PKI는 PQC를 쓰는 전통 X.509로 먼저 갈 수 있고, Chrome도 그 용도는 지원할 것으로 밝혔습니다.
당장 아무것도 안 바뀐다는 사실을 받아들이기. Let's Encrypt의 표현대로, 오늘 달라지는 건 없습니다. 기존 인증서는 늘 그랬듯 발급되고 갱신됩니다.

서두를 필요가 없다는 게 아닙니다. 서두를 곳이 인증서가 아니라는 것입니다.

마치며

정리하면 이렇습니다. 포스트양자 전환에서 암호화는 이미 절반쯤 왔고, 인증은 암호학이 아니라 크기 때문에 막혀 있었습니다. FIPS 204가 정한 ML-DSA-44 서명 2,420바이트에 오늘날 핸드셰이크가 나르는 서명 5개·공개키 2개를 곱하면 1만 4천 바이트대가 나오고, 이는 Cloudflare가 2021년에 실측한 "10kB 넘으면 실패율이 급증하고 9kB 미만이어도 15% 느려진다"는 벽의 한참 바깥입니다.

Merkle Tree Certificates는 이 문제를 알고리즘이 아니라 구조로 풉니다 — 인증서를 배치로 묶어 트리 헤드 하나만 서명하고, 핸드셰이크에는 포함 증명만 싣고, CT를 발급 과정에 내장해 SCT 서명을 지워 버립니다. 드래프트의 추정으로는 최신 클라이언트에게 736바이트, 서명 0개입니다. 포스트양자로 가면서 오히려 오늘보다 작아진다는 주장이 여기서 나옵니다.

대신 조건이 붙습니다. 그 숫자는 7일 수명·매시간 landmark 같은 가정 위의 추정치이고, 클라이언트가 최신 landmark를 들고 있을 때만 성립하며, 그렇지 않으면 더 큰 폴백으로 떨어집니다. 얼마나 자주 떨어지는지는 지금 Chrome과 Cloudflare가 실제 트래픽으로 재고 있는 중이고, 그 답이 나오기 전까지 736바이트는 목표치이지 실측치가 아닙니다. 표준은 -05 드래프트이고, Let's Encrypt의 프로덕션은 2027년이며, Chrome의 새 루트 스토어는 2027년 3분기 계획입니다. 전부 계획입니다.

엔지니어로서 여기서 가져갈 교훈은 조금 일반적입니다. WebPKI가 지난 20년간 뭔가 고칠 때마다 서명을 하나씩 덧붙여 온 것은 전통 암호가 싸서 가능했던 일이고, 그 누적된 편의가 알고리즘이 20배 커지는 순간 청구서로 돌아왔습니다. 크기가 20배가 되면 개수를 20분의 1로 만드는 수밖에 없습니다. MTC가 하는 일이 정확히 그것입니다.