양자내성암호란? 암호를 바꾸기 전에 사용 목록부터 만드는 이유

보관 상자 옆의 황동 자물쇠와 금속 잠금장치. 이해를 돕기 위한 AI 생성 개념 이미지입니다.

양자내성암호 전환을 “RSA를 새 알고리즘으로 교체”라고만 이해하면 실제 작업의 대부분이 빠집니다. 통신 키 설정, 인증서와 코드 서명, 장기 보관 데이터, 하드웨어와 외부 파트너가 서로 다른 암호를 사용하기 때문입니다.

알고리즘을 고르기 전에 무엇을 얼마나 오래 보호하는지, 어디서 어떤 키와 인증서를 쓰는지, 어떤 구성 요소를 함께 바꿔야 하는지부터 목록으로 만들어야 합니다.

양자컴퓨터에서만 쓰는 암호가 아닙니다

NIST의 PQC 설명은 양자내성암호를 고전 컴퓨터와 양자컴퓨터의 공격에 견디도록 설계한 암호 기술로 설명합니다. 일반 컴퓨터와 기존 네트워크에서 구현·배포하는 알고리즘이지, 사용자가 양자 장비를 사야 하는 기술이 아닙니다.

충분한 규모의 양자컴퓨터가 언제 등장할지는 이 글에서 예측하지 않습니다. 전환을 미리 준비하는 이유는 암호화된 자료가 지금 수집돼 나중에 해독될 가능성과, 대형 시스템의 암호 교체에 수년이 걸릴 수 있다는 운영 문제에 있습니다.

KEM과 서명을 같은 칸에 넣지 않습니다

NIST는 2024년 8월 첫 세 PQC 표준을 발표했습니다.

표준	FIPS·역할	적용 질문
ML-KEM	FIPS 203·공유 비밀을 설정하는 키 캡슐화	연결에서 세션 키를 어떻게 합의하는가
ML-DSA	FIPS 204·모듈 격자 기반 디지털 서명	인증서·문서·코드의 서명을 어떻게 검증하는가
SLH-DSA	FIPS 205·해시 기반 디지털 서명	다른 수학적 기반의 서명 선택이 필요한가

NIST 설명에서 ML-KEM은 일반적인 공개 네트워크 암호화의 키 설정, ML-DSA와 SLH-DSA는 디지털 서명에 해당합니다. ML-KEM을 도입했다고 소프트웨어 업데이트 서명도 전환된 것은 아닙니다. 반대로 인증서 서명을 바꿨다고 저장 데이터의 암호화 키 관리가 끝나는 것도 아닙니다. 용도를 분리해야 구매 목록과 테스트 계획이 나옵니다.

NIST의 현재 PQC 표준화 안내에는 2025년에 HQC가 추가 표준화 대상으로 선정됐다는 내용도 있지만, 이 글의 표는 2024년에 발표된 첫 세 FIPS 표준만 다룹니다. 선정·개발 중인 알고리즘을 이미 최종 표준이나 제품 호환성으로 읽지 않도록 상태와 문서를 구분하세요.

먼저 암호 자산 목록을 만듭니다

다음 표를 시스템별로 채워보는 것이 실무적인 시작입니다.

항목	기록 예시
자산	고객 계약 PDF, API 통신, 펌웨어 업데이트
보호 목적	기밀성, 무결성, 발행자 인증
현재 방식	TLS 라이브러리, 인증서 유형, 서명 도구
키 위치	HSM, 클라우드 KMS, 파일, 장치 보안 영역
보호 기간	1년, 10년, 장치 수명 전체
교체 지점	서버, 클라이언트, 프록시, 파트너 시스템
소유자	플랫폼팀, 보안팀, 공급업체
테스트	상호운용, 성능, rollback, 오래된 클라이언트

“RSA 사용” 한 줄로는 부족합니다. 어느 버전의 라이브러리가 키를 만들고, 인증서는 누가 발급하며, 공개키가 설정 파일이나 장치 펌웨어에 박혀 있는지까지 추적해야 합니다.

인벤토리와 상호운용 시험을 병렬로 둡니다

NCCoE의 PQC Migration 프로젝트는 암호 자산을 발견하는 workstream과 NIST 표준 PQC 알고리즘의 상호운용성을 시험하는 workstream을 나눠 설명합니다. 자산을 찾는 일과 알고리즘을 구현하는 일이 모두 필요하다는 뜻입니다. 한 공급업체의 데모 성공만으로 조직 전체의 전환이 끝났다고 보지 않는 이유이기도 합니다.

보호 기간과 전환 기간을 같이 봅니다

예를 들어 자료를 15년간 비밀로 유지해야 하고 시스템 교체에 5년이 걸린다면, 현재 서비스가 잘 돌아간다는 이유만으로 준비를 미루기 어렵습니다. 반면 매일 폐기되는 공개 캐시 데이터는 우선순위가 낮을 수 있습니다.

이 비교는 위험도 산정 방법의 예시이지 양자컴퓨터 도착 시점을 계산하는 공식이 아닙니다. 조직의 규제, 위협 모델, 공급업체 계획과 복구 능력을 함께 봐야 합니다.

교체 가능성, 즉 crypto agility를 시험합니다

암호 알고리즘 이름이 코드 전체에 박혀 있으면 전환과 rollback이 어렵습니다. 다음 질문으로 교체 가능성을 점검할 수 있습니다.

• 알고리즘과 파라미터를 구성으로 바꿀 수 있는가
• 새 키와 기존 키를 동시에 검증하는 기간을 둘 수 있는가
• 인증서와 서명 크기 증가를 프로토콜과 저장소가 감당하는가
• 오래된 클라이언트가 실패할 때 명확한 오류를 내는가
• downgrade를 허용한다면 공격자가 강제할 수 없는가
• 문제가 생겼을 때 기존 방식으로 되돌리는 절차가 있는가

하이브리드 방식을 고려하더라도 “두 개를 쓰니 두 배 안전”이라고 단정할 수 없습니다. 조합 방식과 구현 오류, 상호운용성을 따로 검증해야 합니다.

작은 파일럿의 합격 기준

공개 테스트 데이터와 비운영 키로 다음을 확인합니다.

1. 키 생성·보관·회전·폐기 절차
2. 서명과 검증 또는 키 설정 성공
3. 다른 구현·버전과의 상호운용
4. 메시지·서명·인증서 크기 변화
5. CPU·메모리·지연 영향
6. 실패·rollback·감사 로그

한 라이브러리의 데모가 성공했다고 실제 TLS, VPN, 코드 서명, HSM이 모두 지원된다고 일반화하면 안 됩니다. 각 경로가 별도 제품과 프로토콜을 사용할 수 있습니다.

정리

양자내성암호 전환은 알고리즘 선택보다 암호 사용 위치를 찾는 일이 먼저입니다. KEM과 서명 목적을 구분하고, 보호 기간과 교체 기간을 기준으로 우선순위를 정한 뒤, 비운영 환경에서 상호운용과 rollback을 시험해야 합니다.

자료 확인일은 2026년 9월 7일입니다. NIST의 정의와 2024년 첫 세 FIPS 표준, NCCoE의 인벤토리·상호운용 관점을 기준으로 작성했으며, 이후 모든 표준과 산업별 의무를 열거하거나 특정 전환 시점을 예측하지 않았습니다.