양자내성암호 전환은 지금 무엇부터 봐야 하나: NIST 표준, HQC, KpqC 체크리스트

먼저 봐야 할 것은 ‘양자컴퓨터 시점’이 아니라 암호 의존성입니다

양자내성암호 전환을 이야기하면 질문이 자주 엉뚱한 곳으로 갑니다. “양자컴퓨터가 언제 모든 암호를 깨나?” 같은 질문입니다. 실무에서 먼저 필요한 질문은 다릅니다. 우리 조직의 어떤 데이터가 오래 보호되어야 하고, 어떤 시스템이 RSA·ECC 같은 기존 공개키 암호에 기대고 있는가입니다.

양자내성암호(Post-Quantum Cryptography, PQC)는 충분히 강력한 양자컴퓨터가 기존 공개키 암호를 위협할 수 있다는 전제에서 나온 전환 흐름입니다. 여기서 핵심은 공포가 아니라 시간차입니다. 오늘 탈취된 암호문이 나중에 해독될 가능성을 걱정해야 하는 데이터와, 며칠 뒤 가치가 사라지는 데이터는 같은 우선순위로 다룰 수 없습니다.

그래서 PQC 준비는 새 알고리즘 이름을 외우는 일보다 자산 분류에 가깝습니다. 장기 보관 데이터, TLS 통신, 전자서명, 인증서, 코드 서명, 클라우드와 보안 장비 의존성을 먼저 펼쳐놓아야 합니다.

지금 확정된 NIST 표준은 무엇인가

미국 국립표준기술연구소 NIST는 양자내성암호 표준화 과정을 통해 핵심 알고리즘을 확정했습니다. 현재 전환 논의의 기준점은 다음 세 묶음입니다.

용도	NIST 표준 알고리즘	기존 이름으로 자주 보이는 표현	실무에서 보는 지점
키 설정·암호화	ML-KEM	CRYSTALS-Kyber	TLS, VPN, 키 교환, 암호화 모듈
디지털 서명	ML-DSA	CRYSTALS-Dilithium	인증서, 코드 서명, 문서 서명, 소프트웨어 업데이트
디지털 서명	SLH-DSA	SPHINCS+	해시 기반 서명이 필요한 대체 선택지

NIST의 양자내성암호 프로젝트는 이 표준들이 산업 전환의 기준점이 되도록 안내하고 있습니다. 다만 표준이 나왔다는 말이 곧 모든 서비스가 바로 교체할 수 있다는 뜻은 아닙니다. 구현 라이브러리, 인증 체계, 장비 펌웨어, 브라우저·서버 호환성, 운영 절차가 따라와야 합니다.

HQC는 ‘또 하나의 유행 알고리즘’이 아닙니다

2025년 3월 NIST는 HQC를 추가 양자내성 암호화 알고리즘으로 선정했습니다. NIST 발표의 핵심은 HQC를 ML-KEM의 백업 알고리즘으로 본다는 점입니다. 즉, 지금 당장 모든 설계를 HQC 중심으로 바꾸라는 신호가 아니라, 장기적으로 한 계열의 수학적 가정에만 기대지 않기 위한 안전판입니다.

이 차이는 전환 계획에서 의미가 큽니다. 조직이 확인해야 할 것은 “HQC를 언제 도입할까?” 하나가 아닙니다. 주력 표준인 ML-KEM을 어떤 영역부터 시험할지, 백업 알고리즘이 표준화·구현·인증 생태계에서 어떤 위치를 차지할지, 벤더가 어느 조합을 지원할지를 함께 봐야 합니다.

암호 전환은 늘 느립니다. 알고리즘은 논문과 표준 문서에서 먼저 움직이고, 실제 운영 환경은 라이브러리와 장비, 인증서, 감사 기준을 거쳐 움직입니다. HQC는 그 긴 전환 기간 동안 선택지가 하나 더 필요하다는 점을 보여주는 사례로 읽는 편이 정확합니다.

한국 조직이라면 KpqC 흐름도 같이 봐야 합니다

국내 서비스와 공공·금융·통신 환경을 고려하면 NIST 표준만 보고 끝내기 어렵습니다. 한국인터넷진흥원 KISA는 양자내성암호 자료를 통해 국내 KpqC 후보 알고리즘과 표준화 흐름을 정리하고 있습니다.

KpqC를 NIST 표준의 단순한 경쟁 구도로 볼 필요는 없습니다. 실제 조직에는 더 현실적인 질문이 있습니다. 국내 보안 제품이 어떤 알고리즘을 먼저 지원할지, 공공 조달이나 인증 체계에서 어떤 기준이 반영될지, 국내 연구진과 업체가 만든 구현물이 어느 수준까지 검증될지입니다.

따라서 한국 기업과 기관의 기본 방향은 분명합니다. 대외 호환성과 글로벌 생태계는 NIST 표준을 기준으로 잡고, 국내 규제·제품·검증 환경은 KISA와 KpqC 흐름을 따라가며 교차 확인하는 방식입니다.

전환 우선순위는 이렇게 나누면 됩니다

처음부터 모든 암호를 바꾸려 하면 계획이 흐려집니다. 우선순위는 데이터 수명과 공개키 암호 의존도에서 나옵니다.

우선순위	대상	왜 먼저 보는가	첫 조치
1	장기 보관 민감 데이터	지금 수집된 암호문이 미래 공격 대상이 될 수 있음	데이터 보존 기간과 암호화 방식을 분류
2	TLS, VPN, API 통신	외부 노출면이 넓고 중간 장비 의존성이 큼	서버, 클라이언트, 로드밸런서, WAF 지원 여부 확인
3	인증서와 전자서명	신뢰 체계 전체가 서명 알고리즘에 연결됨	PKI, 코드 서명, 문서 서명, 업데이트 서명 목록화
4	클라우드·보안 벤더	자체 변경보다 벤더 지원 일정의 영향을 크게 받음	PQC 로드맵, 테스트 기능, 계약상 책임 범위 문의
5	내부 애플리케이션	암호 라이브러리 교체와 배포 주기가 제각각임	언어별 라이브러리, API, 키 관리 방식 점검

이 표에서 빠지기 쉬운 항목이 소프트웨어 업데이트입니다. 업데이트 파일이 안전해도, 업데이트 서명을 검증하는 체계가 오래된 공개키 알고리즘에만 기대고 있다면 공급망 보안 관점에서 전환 대상이 됩니다.

바로 교체하기보다 파일럿 범위를 좁히세요

PQC 알고리즘은 기존 공개키 암호와 키 크기, 서명 크기, 처리 방식이 다를 수 있습니다. 따라서 “표준이 나왔으니 전체 교체”보다 작은 파일럿이 더 현실적입니다.

첫 파일럿 후보는 외부 고객 트래픽 전체가 아니라 내부 테스트 API, 사내 VPN 일부 구간, 비핵심 서비스의 TLS 실험 환경처럼 장애 영향이 제한된 곳이 좋습니다. 여기서 봐야 할 것은 암호학적 안전성만이 아닙니다.

• 인증서 체인이 정상적으로 처리되는가
• 클라이언트와 서버가 같은 조합을 지원하는가
• 로드밸런서, 프록시, WAF, 모니터링 장비가 트래픽을 문제없이 다루는가
• 키와 서명 크기 변화가 지연시간, 패킷 크기, 저장소, 로그 처리에 영향을 주는가
• 장애가 났을 때 기존 방식으로 되돌리는 절차가 있는가

일부 환경에서는 기존 알고리즘과 PQC 알고리즘을 함께 쓰는 하이브리드 접근이 검토될 수 있습니다. 다만 하이브리드라는 말 자체가 만능 해결책은 아닙니다. 어떤 조합을 쓰는지, 어느 계층에서 협상하는지, 벤더가 어느 수준까지 지원하는지를 확인해야 합니다.

벤더에게 물어볼 질문은 구체적이어야 합니다

“PQC 지원하나요?”라고 물으면 답도 모호하게 돌아오기 쉽습니다. 다음처럼 시스템 단위로 질문해야 실제 전환 가능성을 알 수 있습니다.

영역	벤더에게 확인할 질문
클라우드·CDN	관리형 TLS에서 ML-KEM 또는 관련 하이브리드 방식을 테스트할 수 있는가
HSM·키 관리	PQC 키 생성, 저장, 회전, 감사 로그를 어떤 방식으로 지원할 계획인가
인증서	PQC 또는 하이브리드 인증서 실험·발급 계획이 있는가
보안 장비	방화벽, WAF, 프록시, DLP가 PQC 적용 트래픽을 정상 처리하는가
개발 플랫폼	사용하는 언어와 런타임에서 검증된 라이브러리 또는 표준 API가 있는가
유지보수 계약	알고리즘 전환에 따른 펌웨어·라이선스·장비 교체 비용이 어디까지 포함되는가

답변에서 날짜만 보는 것도 부족합니다. 테스트 가능한 기능인지, 운영 지원 기능인지, 인증·감사까지 포함한 지원인지가 다릅니다. 문서화된 로드맵과 제한 조건을 받아두면 이후 예산과 일정 논의가 훨씬 명확해집니다.

지금 작성할 내부 체크리스트

PQC 전환 문서는 길 필요가 없습니다. 처음에는 아래 항목을 채우는 한 장짜리 목록이면 충분합니다.

• 공개키 암호 사용 위치: TLS, VPN, SSH, 이메일, 인증서, 코드 서명, 문서 서명, 데이터베이스 암호화, 키 관리 시스템
• 보호해야 할 기간: 즉시성 데이터, 수개월 보관 데이터, 수년 이상 보관해야 하는 데이터
• 외부 의존성: 클라우드, CDN, 인증서 발급기관, HSM, 보안 장비, SIEM, 소프트웨어 공급망
• 표준 기준: ML-KEM, ML-DSA, SLH-DSA 적용 가능 영역과 HQC 후속 표준화 추적 항목
• 국내 기준: KISA KpqC 자료, 국내 보안 제품 지원 여부, 규제·감사 요구 가능성
• 파일럿 후보: 장애 영향이 작고 측정 가능한 내부 서비스 1~2개
• 중단 기준: 성능 저하, 호환성 문제, 로그·모니터링 누락, 복구 절차 미흡

이 목록을 만들면 PQC 논의가 추상적인 미래 위협에서 실제 변경 관리로 내려옵니다. 보안팀만의 과제가 아니라 인프라, 개발, 법무·컴플라이언스, 구매 조직이 함께 볼 수 있는 작업 단위가 됩니다.

다음 확인 지점

지금 할 일은 전면 교체가 아니라 기준선 만들기입니다. 먼저 공개키 암호 의존성 목록을 만들고, 장기 보관 데이터부터 표시하세요. 그다음 NIST 표준 문서와 KISA KpqC 자료를 기준으로 벤더 지원 여부를 확인하고, 장애 영향이 작은 파일럿 구간을 하나 정하면 됩니다.

표준은 이미 전환 논의를 시작할 만큼 구체화됐습니다. 남은 문제는 조직 안에서 어디부터 바꿀 수 있는지, 무엇을 기다려야 하는지, 어떤 벤더 답변이 필요한지를 분리하는 일입니다.