PQC 전환 비용 산정 가이드: 인프라·성능·테스트·인력 공수 계산법

PQC 전환 비용은 “암호 모듈만 교체”로 끝나지 않는다. TLS·VPN·PKI·코드서명처럼 경계부터 배포 체인까지 얽혀 있어 인프라와 성능, 테스트, 인력 공수가 함께 움직인다.  그래서 비용은 기능별이 아니라 서비스의 트래픽 경로와 운영 방식에 맞춰 쪼개서 잡아야 한다. 특히 오래 보관되는 데이터와 장기 서명(코드·펌웨어) 구간은 ‘나중에’가 아니라 ‘먼저’ 비용을 확인해야 한다. 1) 인프라 비용 계산법: 바뀌는 지점의 ‘수량’부터 고정 NIST는 ML-KEM(FIPS 203), ML-DSA(FIPS 204), SLH-DSA(FIPS 205)처럼 PQC 표준을 확정했고, 실무에서는 이 알고리즘이 들어가는 위치가 비용을 결정한다. 또한 NIST IR 8547은 기존(양자 취약) 표준과 향후 전환 대상 표준을 매핑해 제품·서비스가 무엇을 쓰는지 식별하라고 정리한다.  사용자→CDN/WAF→로드밸런서→웹/앱→내부 API→메시지/DB→백업·DR까지 “암호가 쓰이는 구간”을 선으로 그린 뒤, 각 구간에서 인증서 종단(도메인·리스너), mTLS 피어 수, HSM 파티션, 서명서버, 라이브러리/런타임 버전을 수량으로 뽑는다.  인프라비는 ‘대상 수×단가’로 단순화하되 단가는 업그레이드(펌웨어·OS·TLS 스택)와 라이선스(HSM·가속), 검증(정책·규정)을 분리해 적는다. NIST와 CISA가 공통으로 강조하는 첫 단계가 암호 인벤토리인 이유는, 이 수량이 빠지면 견적이 감이 아니라 복불복이 되기 때문이다. 2) 성능 비용 계산법: 지표를 ‘추가 인스턴스’로 환산 하이브리드 TLS는 기존 ECDHE에 ML-KEM을 더해 키셰어가 커지고 연산이 늘 수 있다. IETF는 TLS 1.3 하이브리드 키 교환 구성을 정리 중이며(X25519MLKEM768 등), 실제 적용에서는 p95 핸드셰이크 시간, CPU/핸드셰이크, ClientHello 크기, 실패율을 먼저 찍어야 한다.  측정값을 돈으로 바꿀 때는 “추가 노드 수”로 환산하...

포스트 양자 암호(PQC) 전환 로드맵: 자산 인벤토리부터 파일럿까지 한 번에

포스트 양자 암호(PQC)는 “언젠가”의 이슈가 아니라, 지금 만드는 시스템이 5~10년 뒤에도 안전할지를 결정하는 준비 작업이다. 전환은 알고리즘 교체만이 아니라, 조직의 암호 사용처를 자산 인벤토리로 드러내고 작은 파일럿으로 검증하며 확장하는 과정이다.

PQC 전환 로드맵 한 장 요약

1) 자산 인벤토리: “어디에 암호가 숨어 있나”부터 잡기

전환 실패의 1순위는 기술이 아니라 누락이다. 먼저 ‘암호 자산(crypto assets)’을 눈에 보이게 만든다.

범위 정의: 외부 노출 서비스, 내부 mTLS, VPN/IPsec, 이메일(S/MIME), 코드·펌웨어 서명, 인증서 기반 로그인, 백업·DB 암호화, 하드웨어(HSM/TPM)까지 포함한다.

발견 방법 3종 세트

  1. 네트워크 관점: TLS 핸드셰이크/지원 암호군, 인증서 체인, 키 길이, 만료 주기를 스캔한다.
  2. PKI 관점: 발급 CA, 템플릿, EKU, 유효기간, 자동갱신 방식(ACME 등)을 정리한다.
  3. 코드·공급망 관점: 라이브러리(OpenSSL/BoringSSL 등), 프로토콜 스택, 펌웨어 서명 도구, 서명 검증 경로를 확인한다.
인벤토리 필수 필드: 사용 목적(키교환/서명/암호화), 알고리즘(RSA/ECDSA/ECDH 등), 키·서명 크기 제약(MTU/패킷), 연동 대상(클라이언트/장비), 교체 난이도(업데이트 가능 여부), 데이터 보존기간(장기 비밀성 필요 여부).

산출물은 “암호 자산 목록 + 우선순위 태그(장기비밀성/대외연동/레거시)”가 핵심이다.

암호 자산 인벤토리 점검 장면

2) PQC 전환 설계: 우선순위와 크립토 애자일리티로 길 만들기

인벤토리가 끝나면 “무엇부터 바꿀지”를 정한다. 기준은 단순하다: 오래 숨겨야 하는 데이터부터, 그리고 바꾸기 어려운 곳부터.

위험 기반 우선순위: 주민정보/의료/지적재산/계약서처럼 보존기간이 긴 데이터는 ‘지금 수집해 나중에 복호화(harvest now, decrypt later)’ 위험을 고려해 먼저 잡는다.

표준 기준점 정하기: NIST가 확정한 PQC 표준(키 설정용 ML-KEM, 서명용 ML-DSA/SLH-DSA)을 “기본 선택지”로 두고, 예외는 이유와 기간을 적어 관리한다.

크립토 애자일리티 설계: 알고리즘을 코드에 박아두지 말고(하드코딩 금지), 구성·정책 레이어에서 교체 가능하게 만든다. 인증서 프로파일, 키관리(KMS/HSM), 라이브러리 업그레이드 정책, 벤더 요구사항(RFP)에 “PQC/하이브리드 지원”을 명시한다.

하이브리드 전략: 전환기에는 기존 알고리즘과 PQC를 결합한 하이브리드 키교환을 고려하면, 한쪽이 약해져도 전체 보안이 급락하는 위험을 줄일 수 있다.

3) 파일럿: 작게 검증하고, 수치로 통과시키기

파일럿은 “성공 사례 만들기”가 아니라 “실패 지점 찾기”다. 범위를 좁히고 측정 지표를 먼저 고정한다.

추천 파일럿 3가지: 내부 서비스 mTLS(성능·패킷 이슈 조기 발견), VPN/원격접속(상호운용성 점검), 코드·펌웨어 서명(배포·검증 체인 점검)

테스트 체크리스트: MTU 단편화, 지연/CPU, 세션 재개, 로깅/관측성, 장애 시 폴백(구성 기반 롤백), 인증서 배포·회수, 레거시 호환성

통과 기준 예시: p95 핸드셰이크 지연, 에러율, 인증서 갱신 성공률, RTO, 애자일리티 지표(설정으로 바꿀 수 있는 항목 수)

파일럿이 끝나면 “템플릿화”가 중요하다. 같은 패턴(구성, 관측, 롤백)을 다른 시스템에 복제할 수 있어야 전환이 확장된다.

PQC 파일럿 테스트 환경

4) 결론

PQC 전환은 한 번의 대형 교체가 아니라, 자산 인벤토리로 현실을 정확히 보고 표준을 기준점으로 삼아 파일럿으로 운영 리스크를 낮추는 반복 과정이다. 

오늘 할 일은 간단하다: 암호 자산 목록을 만들고, 가장 영향이 큰 한 영역에서 하이브리드 기반 파일럿을 시작하는 것이다.