Q26. PQC(양자내성암호), 지금 도입해야 하나요?

A. 지금 당장 PQC를 도입해야 할 이유는 부족합니다.
PQC는 긴급 구매 사업이 아니라 공개키 암호의 표준 전환을 지켜보고 검증하는 문제입니다.

최근 PQC, 즉 양자내성암호를 둘러싼 논의는 두 가지 방향으로 과열되고 있습니다.

하나는 Y2K식 공포입니다.

“양자컴퓨터가 오면 기존 암호가 모두 무너진다.”
“모든 기업이 지금 당장 PQC를 도입해야 한다.”
“양자보안 제품을 사지 않으면 곧 위험해진다.”

다른 하나는 HNDL 공포입니다.

HNDL은 Harvest Now, Decrypt Later의 약자입니다.
지금 암호화된 데이터를 수집해 두었다가,
나중에 충분히 강력한 양자컴퓨터가 등장하면 복호화한다는 주장입니다.

이 이야기는 그럴듯하게 들립니다.
하지만 현실적으로 따져봐야 할 질문이 많습니다.

정말 누가 지금부터 암호문을 대량 수집해 20년, 30년 동안 보관할까요?
그 데이터를 수십 년 뒤에도 의미 있게 분류하고 찾을 수 있을까요?
그때까지 정보 가치가 유지될까요?
이미 유출되어 누구나 알고 있는 데이터라면 무슨 의미가 있을까요?
시간이 지나 만료된 세션, 토큰, 거래 요청, API 호출은 정말 양자컴퓨터로 풀 가치가 있을까요?

HNDL은 완전히 허구라고 말할 수는 없습니다.
하지만 “모든 데이터를 지금 수집해 수십 년 뒤 양자컴퓨터로 해독한다”는 식의 설명은
기술 위협 모델이라기보다 공포 서사에 가깝습니다.

정말 검토할 대상은 수십 년 뒤에도 가치가 남는 일부 고가치 암호문입니다.
모든 웹 트래픽, 모든 금융 거래, 모든 기업 데이터를 같은 긴급성으로 묶는 것은 과장입니다.

여기에 또 하나의 기억이 겹쳐집니다.

바로 20여 년 전 ARIA입니다.

ARIA는 한국형 블록암호였습니다.
한국 표준으로 채택되었고, 공공 영역에서 의미 있는 요구사항이 되었습니다.
하지만 세계 웹·브라우저·TLS·오픈소스·클라우드 생태계의 기본값이 되지는 못했습니다.

암호 자체가 깨져서 실패했다는 뜻이 아닙니다.
문제는 세계 표준 생태계와 따로 움직인 한국형 독자 암호 전략이었습니다.

지금 PQC 논의에서도 같은 장면이 보입니다.

세계는 NIST, IETF, OpenSSL, 브라우저, CDN 생태계를 중심으로 움직이고 있습니다.
그런데 한국에서는 다시 “국산 PQC”, “한국형 양자보안”, “정부 실증”, “지금 도입”이라는 말이 앞섭니다.

정신이 번쩍 나야 합니다.

지금 PQC 논의에는 Y2K가 보입니다.
그리고 동시에 20여 년 전 ARIA가 보입니다.

PQC는 언젠가 반영될 표준 전환입니다.
그러나 지금 필요한 것은 양자보안 제품 구매가 아닙니다.

필요한 것은 다음입니다.

공개키 사용처를 파악한다.
HNDL 주장의 현실성을 검증한다.
NIST·IETF·OpenSSL·브라우저·CDN 생태계를 추적한다.
한국형 독자 암호 사업으로 흐르지 않도록 경계한다.
2029년 전후 웹/TLS 생태계의 가시적 변화를 확인한다.
필요한 경우 호환성·성능·중간장비 테스트를 한다.

즉, PQC는 긴급 도입의 문제가 아닙니다.
표준 전환을 따라갈 준비와 검증의 문제입니다.

1️⃣ PQC를 지금 도입해야 하나요?

A. 아닙니다. 지금 당장 도입할 문제로 볼 필요는 없습니다.

PQC는 필요 없다는 뜻이 아닙니다.
하지만 “지금 도입해야 한다”는 표현은 조심해야 합니다.

이 표현은 마치 모든 기업이 지금 당장 별도 양자보안 제품을 구매하고,
기존 암호체계를 한 번에 바꿔야 하는 것처럼 들립니다.

정확한 질문은 다음이어야 합니다.

우리 조직은 공개키 암호 사용처를 알고 있는가?
장기적으로 비밀성이 유지되어야 하는 데이터가 무엇인지 구분했는가?
NIST·IETF·OpenSSL·브라우저·CDN 생태계의 전환 흐름을 추적하고 있는가?
표준 전환이 실제 운영 환경에 반영될 때 검증할 준비가 되어 있는가?

즉, PQC는 제품 도입의 문제가 아닙니다.
공개키 암호 전환을 표준 생태계에 맞춰 관찰하고 검증하는 문제입니다.

정리하면 다음과 같습니다.

2️⃣ HNDL 때문에 지금 긴급 전환해야 하나요?

A. 아닙니다. HNDL만으로 일반 기업의 긴급 도입을 정당화하기 어렵습니다.

HNDL은 Harvest Now, Decrypt Later의 약자입니다.

공격자가 지금 암호화된 통신이나 데이터를 저장해 두었다가,
미래에 충분히 강력한 양자컴퓨터가 등장했을 때
이를 복호화할 수 있다는 위협 모델입니다.

이 개념 자체는 존재합니다.

현재 널리 쓰이는 RSA, DH, ECDH, ECDSA 같은 공개키 암호는
충분히 강력한 양자컴퓨터가 등장하면 구조적으로 위험해질 수 있습니다.

그러나 여기서 곧바로
“모든 기업이 지금 PQC 제품을 도입해야 한다”로 가면 안 됩니다.

HNDL은 다음 조건이 맞아야 의미가 있습니다.

• 지금 암호문을 수집할 수 있어야 합니다.
• 그 암호문을 수십 년 동안 보관할 수 있어야 합니다.
• 수십 년 뒤에도 정보 가치가 남아 있어야 합니다.
• 나중에 복호화했을 때 공격자에게 이익이 있어야 합니다.
• 이미 유출되거나 만료되어 의미가 사라진 데이터가 아니어야 합니다.

이 조건을 빼고 HNDL을 말하면
“언젠가 모든 암호문이 풀릴 수 있다”는 공포만 남습니다.

정확한 표현은 이것입니다.

HNDL은 모든 기업과 모든 데이터의 긴급 전환 근거가 아닙니다.
수십 년 뒤에도 가치가 남는 일부 고가치 암호문에 대한 선별적 검토 이슈입니다.

3️⃣ 암호문을 지금 수집해 수십 년 저장한다는 것이 현실적인가요?

A. 일부 고가치 표적에는 가능할 수 있지만, 모든 데이터를 대상으로 하기에는 현실성이 낮습니다.

스토리지는 계속 저렴해지고 있습니다.
장기 보관용 스토리지도 존재합니다.

하지만 저장 비용이 낮아졌다고 해서
모든 암호문을 무작정 수집해 수십 년 보관하는 공격이 곧바로 현실적이라는 뜻은 아닙니다.

공격자는 다음 문제를 해결해야 합니다.

즉, HNDL은 “저장공간이 있으니 다 모아두면 된다”는 단순한 문제가 아닙니다.

수십 년 뒤에도 가치가 남는 데이터를
지금 선별하고, 보관하고, 나중에 다시 찾아내야 합니다.

이 조건을 만족하는 데이터는 일반적인 웹 트래픽 전체가 아닙니다.
대부분은 국가안보, 외교, 군사, 핵심 연구개발, 장기 법적 효력 문서처럼
장기 가치가 분명한 일부 영역입니다.

따라서 HNDL을 다음처럼 설명하면 과장입니다.

“지금 모든 암호문을 수집해 두면 30년 뒤 양자컴퓨터로 다 풀 수 있다.”

더 정확한 설명은 이것입니다.

“일부 고가치 암호문은 장기 보관 후 미래 복호화 대상이 될 수 있다.
하지만 이것을 모든 기업의 긴급 PQC 도입 근거로 일반화해서는 안 된다.”

4️⃣ 이미 의미가 사라졌거나 유출된 데이터도 HNDL 대상인가요?

A. 아닙니다. 시간이 지나 가치가 사라지는 데이터는 HNDL 우선순위가 낮습니다.

HNDL을 이야기할 때 자주 빠지는 질문이 있습니다.

그 데이터가 30년 뒤에도 정말 의미가 있는가?

예를 들어 다음 데이터는 시간이 지나면 가치가 크게 줄어듭니다.

• 만료된 로그인 세션
• 만료된 API 토큰
• 일회성 결제 요청
• 짧은 유효기간의 인증 코드
• 이미 정산이 끝난 일반 거래 요청
• 공개 정보에 가까운 웹 요청
• 이미 유출되어 공격자나 대중에게 알려진 데이터

이런 데이터까지 모두
“미래 양자컴퓨터가 풀 수 있으니 지금 PQC가 필요하다”고 말하면
위협의 범위가 부풀려집니다.

HNDL은 데이터의 보존 가치와 함께 봐야 합니다.

오래 보관할 가치가 있는가?
나중에 풀었을 때 여전히 공격 가치가 있는가?
이미 다른 경로로 유출된 정보는 아닌가?
만료·폐기·재발급으로 위험이 사라지는 데이터는 아닌가?

이 질문에 답하지 않고 HNDL만 앞세우는 것은
기술적 위험 평가가 아니라 공포 마케팅입니다.

5️⃣ HNDL 관점에서 어떤 데이터가 검토 대상인가요?

A. ‘위험도’가 아니라 ‘검토 필요성’으로 봐야 합니다.

HNDL은 모든 데이터에 같은 긴급성을 부여하는 개념이 아닙니다.

더 현실적인 표현은 검토 필요성입니다.

이 표의 핵심은 단순합니다.

HNDL은 선별적으로 검토할 위협입니다.
모든 기업과 모든 데이터를 같은 긴급성으로 묶는 것은 과장입니다.

6️⃣ 금융권도 HNDL 때문에 PQC가 최우선 과제 아닌가요?

A. 아닙니다. 금융권은 현재 발생하는 해킹 대응이 더 시급합니다.

금융권에는 지금도 이미 많은 공격이 발생합니다.

• 크리덴셜 스터핑
• 계정 탈취
• 웹 취약점 공격
• API 권한 검증 오류
• 악성코드 감염
• 내부 시스템 침해
• 개인정보 유출
• 랜섬웨어
• 공급망 공격

이 공격들은 미래의 가정이 아닙니다.
지금 실제 피해를 만듭니다.

그런데 HNDL을 앞세워
“미래 양자컴퓨터 위험 때문에 지금 양자보안 제품을 도입해야 한다”고 말하면
현재의 실전 사이버보안 우선순위가 뒤집힐 수 있습니다.

금융권이 먼저 해야 할 일은
양자보안 제품을 구매하는 것이 아닙니다.

지금 발생하는 계정 탈취, 웹 공격, 내부 침해, 데이터 유출을
실시간으로 탐지하고 차단하는 것입니다.

정리하면 다음과 같습니다.

따라서 금융권 보안의 핵심 질문은 이것입니다.

미래 양자컴퓨터 위험보다 먼저,
지금 발생하는 해킹 공격을 몇 분 안에 탐지하고 차단할 수 있는가?

7️⃣ PQC 전환은 Y2K와 같은 문제인가요?

A. 아닙니다. PQC 전환을 Y2K처럼 몰아가는 것은 과장입니다.

최근 일부 PQC 논의는 Y2K를 떠올리게 합니다.

Y2K는 특정 시점이 다가오면
시스템 전체가 문제를 일으킬 수 있다는 명확한 시간 기반 위험이었습니다.

그래서 모든 기업과 기관이
일정 시점까지 시스템을 점검하고 수정해야 했습니다.

하지만 PQC 전환은 Y2K와 다릅니다.

PQC에는 아직 다음이 명확하지 않습니다.

• 실제 암호학적으로 의미 있는 양자컴퓨터가 언제 등장할지
• 어떤 수준의 시스템이 어떤 시점에 실제 위험해질지
• 일반 웹서비스의 어떤 데이터가 장기적으로 의미 있는 HNDL 대상인지
• 어느 기업이 어느 범위까지 직접 조치해야 하는지
• 표준 구현체와 브라우저·CDN 생태계가 어디까지 자동 흡수할지

Y2K식 프레임은 대체로 다음 결론으로 이어집니다.

모든 기업이 위험하다
→ 즉시 점검해야 한다
→ 즉시 제품을 도입해야 한다
→ 정부 예산과 인증 사업이 필요하다
→ 도입하지 않으면 책임 문제가 된다

이 흐름은 기술적 우선순위보다
공포와 책임 회피를 먼저 만듭니다.

PQC는 Y2K처럼 전 기업을 긴급 동원할 사안이 아닙니다.

8️⃣ 지금 PQC 논의에서 20여 년 전 ARIA가 보이나요?

A. 보입니다. 정확히 그 기억을 떠올려야 합니다.

한국에는 이미 비슷한 경험이 있습니다.

ARIA입니다.

ARIA는 한국 연구자들이 개발한 블록암호이고,
한국 표준 블록암호로 채택되었습니다.¹

TLS에서 ARIA cipher suite를 정의한 RFC도 존재합니다.²

하지만 중요한 것은 이것입니다.

ARIA가 암호학적으로 깨졌기 때문에 실패했다는 뜻이 아닙니다.
문제는 세계 표준 생태계의 기본값이 되지 못했다는 점입니다.

세계 웹·브라우저·TLS·오픈소스·클라우드 생태계는
AES, ChaCha20-Poly1305, TLS 표준 구현체 중심으로 움직였습니다.

한국은 한국형 블록암호, 국내 표준, 공공 적용, 인증 체계를 만들었지만,
그것이 세계 생태계의 기본 경로가 되지는 못했습니다.

지금 PQC 논의가
“한국형 양자보안”, “국산 PQC 플랫폼”, “독자 양자보안 체계”,
“국가 고유 암호 전환 사업”으로 흐르는 순간,
우리는 20여 년 전 ARIA의 길을 반복하게 됩니다.

정신이 번쩍 나야 합니다.

PQC는 국제 표준 전환입니다.
한국형 독자 암호 사업이 아닙니다.

국산 구현은 필요할 수 있습니다.
국산 검증 도구도 필요할 수 있습니다.
국산 HSM/KMS 연동도 필요할 수 있습니다.

하지만 방향은 분명해야 합니다.

독자 알고리즘이 아니라 NIST 표준 준용
독자 생태계가 아니라 IETF·OpenSSL·브라우저 호환
국산 플랫폼 종속이 아니라 상호운용성 검증
정부 실증 홍보가 아니라 실제 기술 검증

ARIA의 교훈은 이것입니다.

세계 표준 시대에 한국형 독자 암호를 앞세우면,
결국 국내 요구사항으로 남고 세계 생태계에서는 주변부가 될 수 있습니다.

9️⃣ PQC는 기존 암호체계를 모두 바꾸는 것인가요?

A. 아닙니다. PQC는 주로 공개키 암호 전환입니다.

PQC를 둘러싼 가장 큰 오해는
마치 기존 암호체계 전체가 무너지고
모든 암호를 새로 바꿔야 하는 것처럼 설명하는 것입니다.

그러나 정확히 보면 다릅니다.

PQC가 직접적으로 겨냥하는 영역은 주로 다음입니다.

• RSA 기반 키 교환
• DH / ECDH / ECDHE 기반 키 교환
• RSA 전자서명
• ECDSA / EdDSA 전자서명
• 공개키 인증서 체계 일부
• 코드서명, 펌웨어 서명, 장기 전자서명 일부

반대로 PQC가 직접 대체하는 것이 아닌 영역도 있습니다.

• AES-256
• 대칭키 암호 전체
• SHA-2 / SHA-3 해시 전체
• TLS 전체
• 웹 보안 전체
• 데이터베이스 암호화 전체

Grover 알고리즘 관점에서는
대칭키 탐색 비용이 줄어들 수 있으므로,
AES-128보다 AES-256을 사용하는 방향이 더 충분한 안전 여유를 제공합니다.

그러나 이것은
대칭키 암호 전체를 PQC로 교체한다는 뜻이 아닙니다.

정확한 표현은 다음입니다.

PQC는 AES-256을 대체하는 사업이 아니라,
RSA/ECC 기반 공개키 암호의 표준 전환입니다.

1️⃣0️⃣ NIST 표준은 무엇을 정했나요?

A. NIST는 PQC 전환의 기준 알고리즘을 제시했습니다.

NIST는 2024년 8월
첫 번째 PQC 표준 3개를 최종 발표했습니다.³

여기서 가장 중요한 것은 ML-KEM입니다.

ML-KEM은 데이터를 직접 암호화하는 AES 대체물이 아닙니다.
공개 채널에서 안전하게 공유 비밀키를 만들기 위한
키 캡슐화 메커니즘입니다.

실제 통신에서는 대체로 다음 구조가 됩니다.

공개키 기반 키 교환 또는 KEM
→ 공유 비밀키 생성
→ 대칭키 암호(AES, ChaCha20 등)로 실제 데이터 암호화

따라서 PQC를 “전체 암호체계 교체”처럼 설명하는 것은 부정확합니다.

정확한 표현은 이것입니다.

PQC는 실제 데이터를 암호화하는 AES를 대체하는 것이 아니라,
AES 같은 대칭키 암호에 사용할 공유키를 안전하게 합의하는 공개키 영역을 바꾸는 것입니다.

1️⃣1️⃣ PQC 도입은 TLS 1.4 또는 TLS 2.0으로 가야 하나요?

A. 아닙니다. 현재 흐름은 TLS 1.4나 TLS 2.0이 아니라 TLS 1.3 안의 확장입니다.

이 지점이 매우 중요합니다.

PQC를 마치 새로운 보안 체계 전체로 갈아엎는 것처럼 설명하면
독자는 “새 TLS 버전이 필요한 대전환인가?”라고 생각할 수 있습니다.

하지만 현재 IETF와 구현체의 주류 흐름은 그렇지 않습니다.

현재 논의되는 방식은 TLS 1.3을 유지한 채,
supported_groups와 key_share에
X25519MLKEM768 같은 하이브리드 키 교환 그룹을 추가하는 방식입니다.⁴

즉, 방향은 다음에 가깝습니다.

TLS 1.3 유지
→ supported_groups 확장
→ key_share에 하이브리드 그룹 추가
→ X25519 + ML-KEM 조합 사용
→ 세션 키 도출
→ 실제 데이터 암호화는 AES 또는 ChaCha20 사용

OpenSSL 3.5도 같은 방향입니다.
ML-KEM, ML-DSA, SLH-DSA 지원을 추가하고,
TLS에서 X25519MLKEM768 같은 하이브리드 그룹을 지원하는 흐름을 반영했습니다.⁵

따라서 PQC의 일반 웹/TLS 적용을 설명할 때는
다음 문장이 가장 중요합니다.

PQC는 TLS 1.4나 TLS 2.0을 기다리는 문제가 아닙니다.
TLS 1.3 안에서 키 교환 그룹을 확장하는 방식으로 먼저 진행되고 있습니다.

이 말은 PQC가 필요 없다는 뜻이 아닙니다.

다만 이것을 Y2K처럼
전 사회가 동시에 새 체계로 갈아타야 하는 대전환으로 포장하는 것은
기술적 현실과 거리가 있다는 뜻입니다.

1️⃣2️⃣ TLS 1.2에서 TLS 1.3으로 넘어간 변화보다 큰 변화인가요?

A. 일반 웹/TLS의 프로토콜 구조 관점에서는 오히려 더 작은 변화에 가깝습니다.

TLS 1.2에서 TLS 1.3으로의 전환은 상당히 큰 변화였습니다.
프로토콜 버전 자체가 바뀌었고,
핸드셰이크 구조, cipher suite 체계, forward secrecy 기본화,
오래된 알고리즘 제거, 0-RTT, 핸드셰이크 암호화 범위 등이 함께 바뀌었습니다.⁶

반면 현재 논의되는 PQC 하이브리드 키 교환은
TLS 1.3의 큰 틀을 유지합니다.

바뀌는 핵심은 주로 키 교환입니다.
기존 ECDHE 방식에 ML-KEM을 결합해
고전 컴퓨터 공격과 미래 양자컴퓨터 공격을 함께 고려하는 방식입니다.

TLS 1.3 유지
→ X25519MLKEM768 같은 하이브리드 그룹 추가
→ ECDHE 공유값 + ML-KEM 공유값 결합
→ 세션 키 도출
→ 실제 데이터 암호화는 AES 또는 ChaCha20 유지

이 점에서 일반 웹/TLS 관점의 PQC 전환은
TLS 1.2에서 TLS 1.3으로 넘어간 변화보다 작다고 볼 수 있습니다.

정확한 표현은 다음입니다.

프로토콜 관점에서는 점진적 확장입니다.
운영 관점에서는 호환성 검증이 필요한 변경입니다.
그러나 Y2K식 대규모 공포 사업은 아닙니다.

물론 “작은 변경”이라는 말이
“아무 검증도 필요 없다”는 뜻은 아닙니다.

PQC 하이브리드 키 교환은
ClientHello와 key share 크기를 키울 수 있고,
MTU, 패킷 분할, 구형 방화벽·프록시·SSL 가시성 장비,
로드밸런서, 모바일 환경, 대량 TLS 핸드셰이크 성능에 영향을 줄 수 있습니다.

따라서 운영자는 호환성과 성능을 확인해야 합니다.

하지만 이것은
새로운 TLS 세대로 전면 교체하는 문제가 아닙니다.

일반 웹서비스 관점에서는
TLS 1.3 안에서 키 교환을 확장하고,
생태계 전환에 맞춰 검증하는 문제에 가깝습니다.

1️⃣3️⃣ 해외 기관들은 PQC 전환 일정을 어떻게 보고 있나요?

A. 대체로 2035년까지 전체 전환을 목표로 보되, 일반 웹/TLS 영역은 그보다 먼저 가시화될 가능성이 큽니다.

여기서 중요한 것은 일정표를 정확히 읽는 것입니다.

2035년이라는 숫자는
“2035년까지 아무것도 하지 않아도 된다”는 뜻이 아닙니다.

반대로 2029년이라는 숫자도
“모든 기업이 2029년까지 독자 PQC 제품을 도입해야 한다”는 뜻이 아닙니다.

각 일정은 보는 범위가 다릅니다.

따라서 관점은 이렇게 정리하는 것이 적절합니다.

전체 암호 생태계 전환은 2035년까지 이어질 수 있습니다.
그러나 일반 웹/TLS 영역의 가시적 전환은 2029년 전후부터 훨씬 뚜렷하게 나타날 가능성이 높습니다.

1️⃣4️⃣ NCSC 일정은 너무 느슨한 것 아닌가요?

A. NCSC 일정은 일반 웹서비스가 아니라 전체 생태계 기준으로 봐야 합니다.

NCSC는 2028년까지 계획 수립,
2031년까지 고우선순위 전환,
2035년까지 전체 전환이라는 일정을 제시합니다.⁸

이 일정만 보면 느슨해 보일 수 있습니다.

하지만 NCSC의 2035년 일정은
일반 웹서비스의 TLS 전환 속도를 말하는 것이 아닙니다.

레거시 시스템, OT, 임베디드, 오래된 장비,
HSM/KMS, 내부 PKI, 장기 전자서명, 특수 공공 인프라까지 포함한
전체 암호 생태계의 장기 마감선에 가깝습니다.

일반 웹서비스는 이보다 빠르게 움직일 수 있습니다.

왜냐하면 일반 웹/TLS 영역은
운영자가 직접 암호 알고리즘을 설계하는 구조가 아니기 때문입니다.

대부분 다음 생태계를 따라갑니다.

NIST 표준 확정
→ IETF TLS 반영
→ OpenSSL / BoringSSL / NSS / Java / Go 등 구현체 반영
→ 웹서버, CDN, 브라우저 반영
→ 운영자는 버전 업그레이드와 호환성 검증

따라서 일반 웹서비스 관점에서는
2029년 전후로 가시적 전환이 시작될 가능성이 높습니다.

1️⃣5️⃣ 2029년 전후에 실제 변화가 보일 가능성이 큰 이유는 무엇인가요?

A. OpenSSL, IETF, Google, Cloudflare가 이미 움직이고 있기 때문입니다.

OpenSSL 3.5는
TLS에서 X25519MLKEM768 같은 하이브리드 PQC KEM 그룹을 지원하는 방향을 반영했습니다.⁵

IETF TLS 작업반도
TLS 1.3에서 ECDHE와 ML-KEM을 결합한
하이브리드 키 교환 방식을 표준화 대상으로 다루고 있습니다.⁴

Google은 2029년을 PQC 마이그레이션 목표 시점으로 제시했습니다.⁹

Cloudflare도 2029년까지 post-quantum authentication을 포함한
full post-quantum security를 목표로 제시했습니다.¹⁰

이 흐름이 의미하는 것은 분명합니다.

일반 웹서비스 운영자가
자체 PQC 알고리즘을 개발하거나,
한국형 양자보안 플랫폼을 별도로 만들어야 하는 것이 아닙니다.

웹/TLS 생태계는 이미 다음 방향으로 움직이고 있습니다.

하이브리드 TLS 키 교환
→ 브라우저·CDN 우선 적용
→ OpenSSL·BoringSSL·NSS 등 구현체 확산
→ 웹서버·운영체제 배포판 반영
→ 일반 기업의 버전 업그레이드와 호환성 검증

이것이 바로 2029년 전후를
가시적 전환의 중요한 분기점으로 볼 수 있는 이유입니다.

1️⃣6️⃣ 일반 웹서비스는 자연스럽게 전환될 수 있나요?

A. 상당 부분은 표준 생태계 전환을 따라갈 가능성이 높습니다.

일반 웹서비스 관점에서 PQC 전환은
TLS 1.2에서 TLS 1.3으로 넘어간 흐름과 유사한 면이 있습니다.

물론 완전히 같지는 않습니다.

PQC는 키 크기, 메시지 크기, 인증서, 전자서명,
HSM/KMS, 장기검증 같은 추가 이슈가 있습니다.

그러나 일반 웹/TLS 영역만 놓고 보면
전환 방식은 대체로 다음과 유사할 가능성이 높습니다.

표준이 정리된다
→ 구현체가 반영한다
→ 브라우저와 CDN이 먼저 적용한다
→ 웹서버와 운영체제 배포판이 따라간다
→ 일반 기업은 업그레이드와 호환성 검증을 수행한다

즉, 일반 기업이 해야 할 일은
독자 암호체계를 만들거나,
양자보안 제품을 긴급 구매하는 것이 아닙니다.

다음과 같은 관리입니다.

• TLS 1.3 지원 여부 확인
• OpenSSL / Java / Go / 웹서버 버전 확인
• CDN과 클라우드 사업자의 PQC 로드맵 확인
• 오래된 프록시, IPS, SSL 가시성 장비의 호환성 테스트
• 모바일 앱, API Gateway, mTLS 환경 점검
• 인증서 정책 변화 추적

이것은 긴급 구매 사업이 아니라
표준 전환에 따른 정상적인 운영 관리입니다.

1️⃣7️⃣ 그렇다면 한국에서는 왜 유독 지금 도입해야 한다고 하나요?

A. 기술 전환이 예산 사업과 제품 마케팅 언어로 바뀌기 쉽기 때문입니다.

한국에서 PQC 논의가 특히 조심스러운 이유는
기술 자체보다 정책 언어 때문입니다.

“양자”, “국가안보”, “차세대 암호”, “국산 보안”,
“디지털 주권”, “양자보안 골든타임” 같은 표현은
정책 사업으로 만들기 쉽습니다.

이런 단어들은 모두 중요합니다.

하지만 동시에 예산을 키우는 데도 매우 강한 명분이 됩니다.

문제는 여기서 발생합니다.

• 표준 전환이 독자 모델 개발처럼 포장됩니다.
• 실증 사업이 기술 검증처럼 받아들여집니다.
• 특정 제품 도입이 국가 전략처럼 설명됩니다.
• 일반 기업까지 긴급 전환 대상처럼 과장됩니다.
• 공개키 알고리즘 전환이 전체 암호체계 붕괴처럼 설명됩니다.
• HNDL이 현재 해킹 대응보다 더 시급한 문제처럼 포장됩니다.
• ARIA의 교훈을 잊고 다시 한국형 독자 암호 프레임으로 돌아갑니다.

이것이 우리가 경계해야 할 지점입니다.

질문은 “PQC가 필요한가?”가 아닙니다.

진짜 질문은 이것입니다.

왜 전 세계는 표준과 구현체 중심으로 움직이는데,
한국에서는 유독 ‘지금 당장 양자보안 제품을 도입해야 한다’는 식으로 과열되는가?

1️⃣8️⃣ 정부가 PQC 지원 사업을 하면 안 된다는 뜻인가요?

A. 아닙니다. 정부 지원은 필요할 수 있습니다. 다만 범위와 목적이 분명해야 합니다.

정부가 PQC 전환을 검토하는 것 자체는 필요할 수 있습니다.

특히 다음 영역은 정부 차원의 실증, 가이드, 검증 체계가 필요할 수 있습니다.

• 국방 특수망
• 외교·정보기관 시스템
• 금융 결제 핵심 인프라
• 공공 인증 체계
• HSM / KMS / 인증서 인프라
• 장기 전자서명·전자문서 검증 체계
• 교통·에너지·통신 등 중요 인프라
• OT·임베디드·펌웨어 서명
• 우주·위성 통신

문제는 정부 지원의 방향입니다.

정부 지원이 다음 방향이면 필요합니다.

표준 적합성 검증
상호운용성 테스트
전환 가이드 작성
특수 인프라 실증
암호자산 식별 방법론 정리
HSM/KMS/PKI 전환 검증
장기 전자서명 법·기술 검토

하지만 다음 방향이면 문제가 됩니다.

모든 기업 긴급 도입 압박
특정 제품 중심 예산 사업
정부 실증을 기술 검증처럼 홍보
국산 독자 모델 과장
HNDL 공포를 활용한 판매 논리
PQC 미도입을 보안 무책임처럼 표현

정부가 해야 할 일은 공포를 키우는 것이 아닙니다.

표준 기반 전환을 안전하게 관리하도록 돕는 것입니다.

1️⃣9️⃣ ‘국산 PQC’나 ‘한국형 양자보안’은 어떻게 봐야 하나요?

A. 국산 구현은 필요할 수 있지만, 독자 표준 경쟁처럼 가면 위험합니다.

암호는 독창성이 중요한 분야가 아닙니다.

암호에서 더 중요한 것은 다음입니다.

• 공개 검증
• 국제 표준 적합성
• 구현 안전성
• side-channel 대응
• 상호운용성
• 장기 유지보수
• 인증서·브라우저·서버 생태계 호환성

따라서 “국산 PQC”라는 표현은 조심해야 합니다.

국산 구현, 국산 검증 도구, 국산 전환 컨설팅,
국산 HSM/KMS 연동, 국산 보안장비 호환성 검증은 필요할 수 있습니다.

하지만 독자 알고리즘, 독자 플랫폼, 독자 생태계를 강조하면
오히려 상호운용성 리스크가 커질 수 있습니다.

정확한 방향은 다음입니다.

독자 표준이 아니라 NIST 표준 준용.
독자 생태계가 아니라 국제 생태계 호환.
제품 도입이 아니라 검증 가능한 전환 관리.

2️⃣0️⃣ PQC 제품이나 사업을 볼 때 무엇을 물어봐야 하나요?

A. ‘양자보안’이라는 이름보다 실제 적용 범위를 물어봐야 합니다.

PQC 제품이나 정부 사업을 볼 때는
다음 질문을 해야 합니다.

이 질문에 답하지 못하는 제품이나 사업은
양자보안이라는 이름만 앞세운 것일 수 있습니다.

2️⃣1️⃣ 지금 기업이 실제로 해야 할 일은 무엇인가요?

A. 제품 구매가 아니라 관찰, 식별, 검증입니다.

지금 기업이 해야 할 일은
“양자보안 제품 도입”이 아닙니다.

다음과 같은 기본 점검입니다.

이 중 가장 중요한 것은
현재 공격 대응과 미래 전환 검토를 구분하는 것입니다.

지금 실제 피해를 만드는 공격은
계정 탈취, 웹 공격, 내부 침해, 데이터 유출입니다.

미래 양자컴퓨터를 이유로
현재의 실전 사이버보안 투자를 뒤로 미뤄서는 안 됩니다.

2️⃣2️⃣ 일반 기업은 언제 움직이면 되나요?

A. 지금은 흐름을 관찰하고, 2029년 전후 생태계 전환이 보이면 검증하면 됩니다.

일반 기업의 현실적인 접근은 다음과 같습니다.

2026~2028년
- 공개키 사용처 식별
- 장기 비밀성 데이터 선별
- TLS 1.3 전환 상태 확인
- OpenSSL·브라우저·CDN 로드맵 추적
- 레거시 장비와 프록시 호환성 점검

2029년 전후
- 브라우저·CDN·OpenSSL·웹서버 생태계의 PQC 하이브리드 적용 확인
- 테스트 환경에서 호환성 검증
- 일반 웹서비스부터 단계적 적용 검토

2030~2035년
- 고위험 시스템, 내부 PKI, HSM/KMS, 장기 전자서명, 레거시 환경 정리
- 특수 인프라와 장기 운영 시스템의 전환 완료

이 일정은
“2035년까지 아무것도 하지 말자”는 뜻이 아닙니다.

반대로
“지금 당장 양자보안 제품을 사자”는 뜻도 아닙니다.

정확한 의미는 이것입니다.

지금은 흐름을 관찰하고,
생태계 전환이 가시화되는 시점에 검증하고,
고위험 자산부터 단계적으로 전환하자는 것입니다.

2️⃣3️⃣ 결론적으로 PQC는 지금 도입해야 하나요?

A. 아닙니다. 지금 당장 도입할 문제가 아닙니다.

PQC는 장기적으로 반영될 표준 전환입니다.

그러나 PQC는 Y2K가 아닙니다.
모든 기업이 같은 날짜까지 같은 방식으로
긴급 도입해야 하는 문제가 아닙니다.

PQC는 전체 암호체계 교체가 아닙니다.
주로 RSA/ECC 기반 공개키 암호의 표준 전환입니다.

HNDL은 검토할 수 있는 위협입니다.
그러나 모든 데이터를 수십 년 저장해 언젠가 해독한다는 식의 이야기는
현실성을 따져봐야 합니다.

일반 웹서비스는
NIST, IETF, OpenSSL, 브라우저, CDN 생태계의 전환을 따라가며
상당 부분 자연스럽게 흡수될 가능성이 높습니다.

특히 Google과 Cloudflare가 2029년을 목표로 제시하고,
OpenSSL과 IETF TLS 흐름이 이미 움직이고 있다는 점을 보면
2029년 전후에는 웹/TLS 영역에서 가시적인 전환이 나타날 가능성이 큽니다.

따라서 결론은 분명합니다.

PQC는 지금 당장 도입할 문제가 아닙니다.
지금 필요한 것은 양자보안 제품 구매가 아니라 표준 생태계 관찰, 공개키 사용처 식별, 호환성 검증입니다.

“PQC 전환을 언젠가 준비해야 한다”는 말은 맞을 수 있습니다.

그러나 “양자보안 제품을 지금 사라”는 말은 다른 이야기입니다.

전자는 표준 전환 관리이고,
후자는 마케팅일 수 있습니다.

정리하면

PQC 논의에서 가장 중요한 것은 균형입니다.

한쪽에서는
“양자컴퓨터는 아직 멀었으니 아무것도 보지 않아도 된다”고 말할 수 있습니다.

이것은 지나칩니다.

다른 한쪽에서는
“HNDL 때문에 모든 기업이 지금 당장 양자보안 제품을 도입해야 한다”고 말할 수 있습니다.

이것도 지나칩니다.

현실적인 답은 다음입니다.

PQC는 지금 당장 도입하지 않는다.
하지만 표준 흐름은 관찰한다.

HNDL은 현실성을 검증한다.
하지만 모든 데이터를 수십 년 저장해 언젠가 해독한다는 공포로 몰아가지 않는다.

Y2K처럼 몰아가지 않는다.
ARIA처럼 한국형 독자 암호 사업으로 흐르지 않는다.

국제 표준을 따른다.
독자 모델과 과장 마케팅을 경계한다.

일반 웹서비스는 생태계 전환을 따라간다.
특수 인프라는 별도 계획을 세운다.

지금 할 일은 제품 구매가 아니라
공개키 사용처 식별, 장기 데이터 선별, 표준 추적, 호환성 검증이다.

보안은 공포가 아니라 우선순위의 문제입니다.

그리고 PQC의 우선순위는 이렇게 정리해야 합니다.

미래 양자컴퓨터 위험은 차분히 관찰하되,
현재 발생하는 해킹 공격을 놓치지 말아야 합니다.

📚 함께 읽기

• PQC(양자내성암호)는 독자 모델이 아니라 표준 전환이다
• 양자 내성 암호(PQC)의 현주소: 지금 무엇을 준비해야 하는가
• 양자컴퓨팅 시대의 암호기술: AES, SHA-3, PQC, 그리고 지금 해야 할 준비
• 공포·유행어 추격을 멈추고 ‘증거 중심 보안’으로
• ISMS-P 인증을 받아도 해킹 당하는 이유
• Q25. 제로트러스트, 도입해야 하나요?

📖 함께 읽기

• ARIA (cipher) - Wikipedia