Google's Move to Merkle Tree Certificates: Saving TLS from the Post-Quantum Bloat

모두가 ‘양자 컴퓨터가 오면 암호화가 다 뚫린다(Q-Day)‘는 종말론적인 이야기만 할 때, 백엔드 엔지니어로서 진짜 걱정되는 건 따로 있었습니다. 바로 TLS 핸드셰이크 성능 입니다.

최근 구글이 Chrome Security Blog를 통해 Robust and efficient quantum-safe HTTPS라는 글을 올렸습니다. 핵심은 간단합니다. 양자 내성 암호(PQC)를 적용하면 인증서가 너무 커지니, 기존 X.509 체인 방식을 버리고 Merkle Tree Certificates (MTC) 로 갈아타겠다는 선언입니다.

솔직히 말해, 이건 단순히 보안 프로토콜의 업데이트가 아니라 인터넷 인프라의 ‘체질 개선’에 가깝습니다. 오늘 포스팅에서는 왜 구글이 이런 선택을 했는지, 그리고 Hacker News에서 벌어진 논쟁을 통해 엔지니어들이 무엇을 고민해야 하는지 깊게 파고들어 보겠습니다.

왜 기존 방식으로는 안 되는가? (The Bloat Problem)

현재 우리가 쓰는 RSA나 ECC(Elliptic Curve) 인증서 체인은 매우 가볍습니다. 보통 4KB 미만이죠. 하지만 양자 컴퓨터 공격에 안전한 알고리즘(예: ML-DSA, Dilithium 등)을 적용하면 상황이 달라집니다.

단순히 알고리즘만 교체할 경우, 인증서 체인의 크기는 약 40배 까지 커질 수 있습니다. Hacker News의 한 유저는 이를 두고 약 160KB 정도가 될 것이라고 추산했습니다. 여기서 “요즘 시대에 160KB가 대수냐?”라고 반문할 수 있습니다. 실제로 HN 댓글 중에도 이런 의견이 있었습니다.

“브로드밴드 시대에 160KB는 찰나의 순간이다. 4K 비디오도 스트리밍하는 마당에 이게 무슨 문제냐?”

하지만 이건 네트워크의 기본 동작 원리인 TCP Congestion Control 을 간과한 발언입니다.

Latency vs. Bandwidth

제가 주니어 시절 가장 많이 했던 착각이 ‘대역폭(Bandwidth)이 크면 지연시간(Latency)도 짧을 것’이라는 믿음이었습니다. 하지만 TLS 핸드셰이크의 적은 대역폭이 아니라 Round Trip Time (RTT) 입니다.

TCP 연결 초기에는 Initial Congestion Window (initcwnd)라는 제한이 있습니다. 보통 1032 패킷(약 14KB45KB) 정도로 설정되죠. 서버는 이 윈도우 크기만큼만 데이터를 보내고, 클라이언트의 ACK를 기다려야 합니다.

만약 인증서 체인이 160KB라면?

  1. 서버가 첫 덩어리를 보냄.
  2. 클라이언트 ACK 대기 (1 RTT).
  3. 윈도우 사이즈 증가, 다음 덩어리 전송.
  4. 다시 ACK 대기 (2 RTT)…

이 과정이 반복되면서 핸드셰이크만으로 수십~수백 밀리초(ms)가 추가됩니다. 특히 패킷 손실이 잦은 모바일 네트워크나 기내 와이파이 같은 환경에서는 이 지연이 치명적입니다. 구글이 걱정하는 건 바로 이 지점입니다.

해결책: Merkle Tree Certificates (MTC)

구글은 이 문제를 해결하기 위해 IETF의 PLANTS (PKI, Logs, And Tree Signatures) 워킹 그룹과 함께 MTC를 제안했습니다. 아이디어는 Git이나 블록체인에서 쓰는 Merkle Tree와 유사합니다.

작동 원리

기존 X.509 방식에서는 서버가 “내 인증서 + 중간 CA 인증서 + 루트 CA 서명”을 줄줄이 사탕처럼 클라이언트에게 보냅니다. 이 ‘직렬화된 체인’이 용량을 잡아먹는 주범입니다.

MTC 방식은 다릅니다:

  1. Batch Signing: 인증기관(CA)은 수백만 개의 인증서를 모아 하나의 Merkle Tree를 만듭니다.
  2. Tree Head: CA는 이 트리의 루트(Tree Head)에만 서명합니다.
  3. Proof of Inclusion: 브라우저에게는 전체 체인 대신, 해당 인증서가 트리에 포함되어 있다는 수학적 증명(Merkle Path)만 보냅니다.

결과적으로 브라우저는 아주 짧은 증명 데이터(Proof)만 받으면 됩니다. 암호화 알고리즘이 아무리 복잡해져도, 전송해야 할 데이터 크기는 획기적으로 줄어듭니다(O(log n)).

또한, 이 방식은 Certificate Transparency (CT) 를 기본적으로 내재하고 있습니다. 트리에 포함되지 않은 인증서는 발급 자체가 불가능하므로, 투명성이 강제됩니다. 기존 CT 로그가 별도로 필요했던 오버헤드까지 줄이는 셈입니다.

Hacker News의 논쟁: “네트워크 스택을 고쳐라” vs “현실을 봐라”

이 주제에 대해 Hacker News에서는 뜨거운 논쟁이 있었습니다. 특히 인상 깊었던 건 “네트워크 스택의 ossification(경직화)” 에 대한 지적이었습니다.

한 유저는 이렇게 주장했습니다:

“인증서가 커지면 초기 혼잡 윈도우(initcwnd)를 늘리면 그만 아닌가? 160KB 때문에 프로토콜을 바꾸는 건, 낙후된 네트워크 장비들의 문제를 덮으려는 미봉책이다.”

이론적으로는 맞는 말입니다. QUIC 프로토콜을 쓰거나 서버 설정을 튜닝하면 완화할 수 있습니다. 하지만 다른 유저의 반박이 더 현실적으로 다가왔습니다:

“HTTP/1.1을 쓰는 레거시 클라이언트, 3G/LTE 환경, 패킷 손실이 높은 무선 네트워크를 무시할 수 없다. 160KB 윈도우 사이즈? 패킷 로스가 발생하면 재전송 때문에 지옥을 맛볼 것이다.”

저도 이 의견에 동의합니다. 엔지니어링은 ‘이상적인 환경’이 아니라 ‘최악의 환경’을 기준으로 설계해야 합니다. 전 세계 모든 라우터와 클라이언트를 업그레이드하는 것보다, 전송 데이터 자체를 줄이는 MTC 방식이 훨씬 현실적이고 우아한(Elegant) 해결책입니다.

구글의 로드맵과 우리의 대응

구글은 당분간 Chrome Root Store에 전통적인 방식의 Post-Quantum X.509 인증서를 추가할 계획이 없다 고 못 박았습니다. 대신 MTC 생태계를 키우는 데 집중하겠다고 합니다.

이것이 시사하는 바는 큽니다:

  • Private PKI: 사내망이나 폐쇄망에서는 기존 방식의 PQ 인증서를 써도 됩니다.
  • Public Web: 일반적인 웹 서비스는 결국 MTC 기반으로 넘어갈 확률이 높습니다.

마치며: MTC는 선택이 아니라 필수다

양자 내성 암호는 선택의 문제가 아니라 시기의 문제입니다. 하지만 그로 인한 성능 저하를 사용자가 감내하게 해서는 안 됩니다.

MTC는 단순히 용량을 줄이는 기술이 아닙니다. 보안성(Post-Quantum) 과 성능(Low Latency), 그리고 투명성(CT) 이라는 세 마리 토끼를 동시에 잡으려는 시도입니다. 물론 새로운 표준이 자리 잡기까지는 시간이 걸리겠지만, Let’s Encrypt 같은 주요 CA들도 관심을 보이고 있는 만큼 전환은 생각보다 빠를 수 있습니다.

지금 당장 코드를 고칠 필요는 없지만, TLS 인프라를 관리하는 시니어 엔지니어라면 이 흐름을 반드시 주시해야 합니다. 160KB짜리 악수(Handshake)를 하고 싶은 사람은 아무도 없으니까요.