PQC 파일럿 설계: 성공 기준(KPI)과 종료 조건(Go/No-Go) 만들기

PQC(포스트 양자 암호) 파일럿은 “알고리즘을 바꿔보는 실험”이 아니라, 운영 환경에서 안전하게 굴러가는지 검증하는 프로젝트다.  그래서 성공 기준(KPI)과 종료 조건(Go/No-Go)을 먼저 정해두면, 성능·호환성·운영 리스크를 숫자로 관리하면서 다음 단계로 갈지 멈출지 빠르게 결정할 수 있다. 1) 성공 기준부터 거꾸로 설계하기: 범위·기준선·대상 트래픽 파일럿은 전사 적용이 아니라 “대표 구간 1~2개”를 고르는 게 핵심이다. 예를 들어 TLS 구간이면 엣지(CDN/로드밸런서)~오리진, 내부 mTLS, 또는 VPN 중 하나를 선택한다. 그리고 기존(클래식) 대비 기준선(베이스라인)을 먼저 측정한다:  핸드셰이크 p95 지연, CPU/메모리, 실패율, 연결 재시도율, 고객 영향 지표(에러/이탈) 같은 것들이다. 표준 측면에서는 NIST가 PQC 표준(FIPS 203/204/205)을 공개했고, TLS 전환은 하이브리드 키교환이 실무적으로 많이 쓰이는 흐름이라 파일럿도 “하이브리드 우선”으로 설계하면 롤백과 상호운용성이 쉬워진다.  2) KPI 세트 만들기: 보안·호환성·성능·운영·비용을 한 장에 KPI는 5묶음으로 잡으면 깔끔하다. 보안/정책 KPI: 허용 알고리즘·키 길이·인증서 체인·키 관리 정책 준수율(예: 비허용 스위트 0건), PQC 적용 구간 커버리지(대상 트래픽 중 적용 비율) 호환성 KPI: 핵심 클라이언트/서버 조합 성공률(예: 상위 20개 UA/SDK 99.9%+), 폴백 발생률, 장애 시 자동 우회 성공률 성능 KPI: 핸드셰이크 p95/p99 지연 증가율(예: +10% 이내), 서버 CPU 사용률 증가(예: +15% 이내), 메모리/대역폭 증가(키·서명 크기 영향) 모니터링 운영 KPI: 배포 실패/롤백 소요시간(예: 15분 내), 관측성(핵심 로그/메트릭/트레이스 커버리지), 장애 대응 런북 완성도(실습 통과) 비용 KPI: 추가 컴퓨트 비용(월), 인증서/PKI 운...

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

PQC 전환 비용은 “암호 모듈만 교체”로 끝나지 않는다. TLS·VPN·PKI·코드서명처럼 경계부터 배포 체인까지 얽혀 있어 인프라와 성능, 테스트, 인력 공수가 함께 움직인다. 

그래서 비용은 기능별이 아니라 서비스의 트래픽 경로와 운영 방식에 맞춰 쪼개서 잡아야 한다. 특히 오래 보관되는 데이터와 장기 서명(코드·펌웨어) 구간은 ‘나중에’가 아니라 ‘먼저’ 비용을 확인해야 한다.

PQC 전환 비용 산정 로드맵

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 크기, 실패율을 먼저 찍어야 한다. 

측정값을 돈으로 바꿀 때는 “추가 노드 수”로 환산하면 이해관계자 설득이 쉬워진다. 예를 들어 피크 시간대 CPU가 20% 늘고 목표 여유율을 30%로 유지하려면, 추가 노드 수는 대략 현재 노드 수×(0.20/0.30)만큼 필요하다고 잡고 월 인스턴스 비용을 곱한다. 

실패율이 올라가면 성능비가 아니라 장애 대응과 호환성 수정 공수가 늘기 때문에, 운영비 항목으로 따로 떼어 적는 게 안전하다.

3) 테스트·인력 공수 계산법: 매트릭스와 WBS로 ‘반복 비용’ 통제

테스트 비용은 조합 폭발을 어떻게 줄이느냐에 달렸다. 브라우저/모바일 앱/SDK, 중간장비(CDN·LB), 서버 스택(언어·런타임), 모드(기존·하이브리드·PQC)를 축으로 호환성 매트릭스를 만들고, 로그인·결제·업로드·웹소켓·gRPC·mTLS 같은 핵심 경로만 우선순위로 좁힌다. 

공수는 (케이스 수×실행시간)+(환경 세팅)+(결함 처리시간×예상 결함수)로 잡고, 파일럿에서는 결함 처리시간을 실제 측정해 2차 산정치로 업데이트한다. 

인력은 역할별 WBS로 쪼개면 견적이 흔들리지 않는다. 공통 고정 작업은 암호 인벤토리, 정책/암호 스위트 업데이트, 공통 라이브러리 배포, 관측(메트릭·로그)과 롤백 런북이고, 서비스별 변동 작업은 트래픽 경로별 적용, 인증서·키 교체, 클라이언트 업데이트, 벤더 조율, 장애 케이스 대응이다.

하이브리드 TLS 성능 측정 장면

4) 결론

예산서는 ‘파일럿(측정)→운영(확대)’ 2단으로 만든다. 1단 파일럿 예산은 측정 장비와 테스트 공수에 집중하고, 2단 운영 예산은 인프라 증설과 상시 운영 인력(인증서·키관리, 배포 체인 서명, 장애 대응)을 확정한다. 

특히 CNSA 2.0 FAQ처럼 장기 서명과 펌웨어 루트 오브 트러스트 전환을 언급하는 문서가 있는 만큼, 서명 체인 쪽 비용을 경계 트래픽만큼이나 먼저 잡아두면 일정이 안정된다.