금융권 PQC 마이그레이션 전략: 양자 위협보다 먼저 정리해야 할 암호 자산

편집 검토 기준: 2026년 6월 19일. NIST의 FIPS 203·204·205는 최종 표준이지만, FIPS 203과 FIPS 204 페이지에는 향후 개정에 반영될 정오표 항목이 공지돼 있다. NIST IR 8547의 전환 일정은 여전히 초안이므로, 도입 시점에는 표준 본문·정오표·프로토콜 규격·벤더 구현을 함께 다시 확인해야 한다.

금융권의 PQC(Post-Quantum Cryptography, 양자 내성 암호) 마이그레이션은 RSA나 ECC라는 문자열을 새 알고리즘 이름으로 일괄 치환하는 작업이 아닙니다.

고객 인증, 전자서명, 대외 API, 내부 mTLS, VPN, 코드 서명, HSM, 백업과 장기 보관 데이터는 서로 다른 프로토콜과 교체 주기, 법적 요구를 가집니다. 같은 공개키 암호도 어떤 구간에서는 키 설정에, 다른 구간에서는 인증서 또는 문서 서명에 사용됩니다.

용도와 의존성을 분리하지 않으면 전환 순서도, 장애 영향도, 롤백 가능성도 판단할 수 없습니다.

이 글은 기술·운영 관점의 점검 기준입니다. 금융감독 요구, 전자서명의 법적 효력, 기록 보존, 개인정보 처리, 암호모듈 인증과 외부기관 공동망 규격은 관할과 업무에 따라 달라질 수 있습니다. 실제 적용 전에는 최신 감독기관·법령·표준 문서와 인증기관, HSM·KMS·클라우드 공급자 문서, 법무·준법 의견을 확인해야 합니다.

1. 2026년 기준 표준 상태부터 구분한다

“PQC가 표준화됐다”는 말만으로는 설계를 시작하기 어렵습니다. 무엇이 최종이고, 무엇이 지침이며, 무엇이 아직 진행 중인지 나눠 봐야 합니다.

항목	현재 의미	운영자가 확인할 것
FIPS 203	ML-KEM 키 캡슐화 메커니즘 표준	벌크 데이터 암호화나 전자서명 용도로 오해하지 말고, 최신 정오표와 구현 버전을 확인
FIPS 204	ML-DSA 디지털 서명 표준	서명·검증 성능, 키 보호, 장기 검증, 최신 정오표 확인
FIPS 205	SLH-DSA 상태 비저장 해시 기반 서명 표준	큰 서명 크기와 처리량, 사용 목적과 보관 요구를 실측
SP 800-227	KEM 구현·사용 권고	API 계약, 오류 처리, 키 파생과 프로토콜 통합 방식 검토
CSWP 39	암호 민첩성 전략과 실무 고려사항	알고리즘 교체뿐 아니라 정책·자산·공급망·관측성·복구 능력으로 확장
NIST IR 8547	양자 취약 알고리즘 전환 계획 초안	2035 방향성은 참고하되 최종 규정처럼 단정하지 않기
HQC·FN-DSA 등	추가 표준화가 진행 중인 대안	초기 세 표준의 사용을 무기한 미룰 이유로 삼지 말고 변경 가능성을 설계에 반영

ML-KEM은 두 당사자가 공유 비밀을 설정하도록 돕는 KEM입니다. 데이터를 직접 대량 암호화하거나 서명하는 알고리즘이 아닙니다. ML-DSA와 SLH-DSA는 서명 계열입니다. 이 구분을 놓치면 “PQC 지원”이라는 벤더 체크박스만 보고 실제 필요한 기능이 빠진 제품을 선택할 수 있습니다.

2. 첫 산출물은 암호 자산 인벤토리다

인벤토리는 “RSA 인증서 312개” 같은 수량표로 끝나면 안 됩니다. 누가, 어디서, 무엇을 위해, 얼마 동안 사용하는지와 실패 시 되돌리는 방법까지 보여 줘야 합니다.

필드	반드시 기록할 내용
자산·업무	시스템 이름, 업무 소유자, 데이터 소유자, 중요도, 환경
암호 용도	키 설정, 서버 인증, 사용자 인증, 문서 서명, 코드 서명, 데이터 래핑
알고리즘·프로토콜	현재 알고리즘과 파라미터, TLS·SSH·S/MIME·VPN·전용 프로토콜
키 위치	소프트웨어 키스토어, HSM, KMS, 스마트카드, 단말 보안영역
인증서 경로	발급 CA, 중간 CA, 루트, 프로파일, 만료일, 자동 갱신 방식
데이터 수명	기밀성·무결성을 유지해야 하는 기간, 백업·아카이브 포함 여부
의존성	모바일 OS, 지점 단말, 프록시, VAN, 카드·결제망, SaaS, 라이브러리
변경 경로	소스 수정 가능 여부, 벤더 패치, 테스트 창구, 계약 책임, 리드타임
복구 수단	이전 정책으로 되돌리는 방법, 키·인증서 폐기와 재발급 절차
증거	마지막 확인일, 스캔·패킷 결과, 설정 경로, 티켓과 승인 기록

최소 교환 형식은 아래처럼 단순하게 시작할 수 있습니다.

asset_id,owner,use_case,protocol,current_algorithm,key_location,data_lifetime,external_dependency,rollback,last_verified
PAY-API-01,payments,tls-server-auth,TLS1.3,ECDSA-P256,HSM-A,7y,partner-gateway,classic-policy-v3,2026-06-19

한 개의 CMDB만으로는 완성되지 않습니다. 인증서 관리 시스템, 로드밸런서와 프록시 설정, HSM·KMS 감사 로그, 코드 저장소, 패키지 잠금 파일, 서비스 메시, 모바일 네트워크 스택, 백업 제품, 외부 연동 계약을 교차 확인해야 합니다. 전용 프로토콜과 하드코딩된 키는 자동 도구가 놓칠 수 있으므로 담당자 인터뷰와 표본 패킷 분석도 필요합니다.

발견 단계에서 볼 탐지 신호

• 허용 목록에 없는 RSA/ECC 인증서가 신규 발급되거나 자동 갱신된다.
• 인증서 소유자, 발급 목적, 만료일 또는 교체 창구가 비어 있다.
• TLS 스캔 결과와 프록시·애플리케이션 설정이 서로 다르다.
• HSM에서 용도를 설명할 수 없는 키 생성·서명 호출이 반복된다.
• 코드 검색에서 알고리즘, 키 길이, 공급자 이름이 하드코딩돼 있다.
• 운영계와 DR·백업 복구 환경의 암호 설정이 다르다.
• 외부기관 계약에 알고리즘 교체 책임, 시험 환경, 지원 종료일이 없다.

이 신호를 보안 로그 파이프라인의 최소 요건에 연결하면 인벤토리를 일회성 문서가 아니라 지속적으로 갱신되는 운영 자산으로 만들 수 있습니다.

3. 우선순위는 데이터 수명과 전환 리드타임으로 정한다

모든 공개키 구간을 같은 순서로 바꾸는 것은 비효율적입니다. 다음 다섯 축을 함께 봅니다.

1. 보호 잔여기간: 데이터나 서명이 앞으로 몇 년 동안 기밀성·무결성을 유지해야 하는가.
2. 수집 가능성: 공격자가 현재 암호문이나 서명 자료를 대량 수집할 수 있는가.
3. 전환 리드타임: 앱 배포, 단말 교체, CA·HSM 변경, 외부기관 인증에 얼마나 걸리는가.
4. 실패 영향: 고객 로그인 실패, 결제 중단, 서명 검증 실패, DR 불능으로 이어지는가.
5. 공급망 불확실성: 소스와 설정을 직접 바꿀 수 있는가, 벤더 일정에 묶여 있는가.

후보 구간	일반적인 우선 검토 이유	선행 조건
장기 보관 고객·계약 데이터	보호 기간이 전환 기간보다 길 수 있음	데이터 분류, 재암호화 가능성, 백업 범위
대외 TLS·VPN	수집 가능성과 외부 의존성이 큼	프로토콜·단말·중간장비 상호운용성
코드·펌웨어 서명	장기간 검증과 공급망 신뢰에 영향	부트 체인, 배포기, 과거 서명 검증
내부 mTLS	자산 수와 자동 갱신 규모가 큼	서비스 메시·게이트웨이·관측성
문서 전자서명	법적 효력과 장기 검증 요구가 큼	타임스탬프·검증정보·보존 정책
DR·백업 복구	평소 드러나지 않지만 장애 시 치명적	복구 환경의 동일 지원과 키 접근

Store Now, Decrypt Later 위험도 데이터 유형별로 근거를 남겨야 합니다. 보호 기간이 짧고 완전한 재암호화가 가능한 임시 데이터와, 수십 년 보존되는 민감 자료를 같은 등급으로 놓으면 투자 순서가 왜곡됩니다.

4. 하이브리드 PoC는 “연결 성공”이 아니라 실패 동작을 검증한다

기존 방식과 PQC를 함께 쓰는 하이브리드 접근은 전환기의 불확실성을 줄일 수 있지만 자동으로 안전해지지는 않습니다. 결합 방식, 협상, 메시지 크기, 중간 장비, 구현 오류가 새로운 변수가 됩니다. 검증되지 않은 자체 결합 방식을 만들기보다 사용하려는 프로토콜과 라이브러리가 정의한 방식, 최신 표준·보안 검토를 따라야 합니다.

PoC 후보 조건

• 양쪽 종단과 중간 프록시·로드밸런서 버전을 통제할 수 있다.
• 고객 전체가 아니라 내부 서비스 또는 제한된 파트너 구간이다.
• 기준선 지연·오류·자원 지표가 이미 수집되고 있다.
• 이전 정책과 인증서로 되돌리는 절차가 자동화돼 있다.
• 운영과 유사한 HSM·CA·DR 경로를 포함할 수 있다.

반드시 측정할 항목

영역	지표
연결	성공률, 재시도율, 협상 실패 코드, 타임아웃
지연	핸드셰이크와 전체 요청의 p50·p95·p99
자원	CPU, 메모리, HSM 처리량, 연결당 비용
네트워크	인증서·핸드셰이크 크기, 패킷 분할, 재전송
호환성	OS·앱·SDK·프록시·보안장비·외부기관별 성공 여부
키 수명주기	생성, 배포, 회전, 백업, 복구, 폐기 시간
보안	예상치 못한 고전 알고리즘 폴백, 검증 실패, 정책 우회
운영	카나리 중단, 롤백, 증거 보존까지 걸린 시간

사전에 합의할 중단 조건

• 허용되지 않은 알고리즘으로 조용히 폴백한다.
• 특정 단말·망·지역의 연결 실패가 기준선을 넘는다.
• p99 지연, HSM 큐, 재전송, CPU가 합의한 한계를 넘는다.
• 협상 결과나 실제 키 경로를 로그로 확인할 수 없다.
• 롤백 후 신규 세션, 키, 서명 또는 데이터가 검증되지 않는다.

평균값만 보면 특정 구형 단말이나 중간 장비에서 발생하는 장애를 놓칩니다. 단말 버전, 앱 버전, 네트워크 유형, 지역, 프록시 경로별로 오류를 분해해야 합니다.

5. HSM·CA 검증은 “키 생성 지원”보다 넓다

벤더가 ML-KEM이나 ML-DSA를 지원한다고 말해도 전체 키 수명주기가 준비됐다는 뜻은 아닙니다. 다음을 별도로 시험합니다.

• 키 생성과 파라미터 정책, 키를 외부에서 가져오거나 내보낼 수 있는지
• 클러스터 복제, 백업, 복구, 장애조치, 재해복구 사이트 전환
• 서명·캡슐화·디캡슐화 처리량과 큐 대기, 동시 세션 한도
• 감사 로그에 알고리즘, 키 ID, 정책 버전, 호출 주체, 실패 이유가 남는지
• CA 프로파일, 인증서 체인, 폐기 목록, 상태 확인, 자동 갱신
• 과거 서명과 신규 서명을 함께 장기 검증할 수 있는지
• 펌웨어·클라이언트·SDK 버전 조합과 지원 종료 정책
• 암호모듈 검증 또는 국내외 인증 요구를 충족하는지

“소프트웨어에서는 성공했지만 HSM 장애조치에서 실패”하는 사례를 막으려면 운영계와 동일한 클러스터·백업 경로로 시험해야 합니다.

6. 대표 실패 모드와 탐지 신호

실패 모드	현장에서 보이는 징후	사전 통제
조용한 폴백	연결은 성공하지만 기존 알고리즘만 사용	협상 결과를 필수 로그로 남기고 허용 정책과 비교
메시지 비대화	특정 프록시·망에서 타임아웃과 재전송 증가	크기, MTU, 중간 장비 한도와 인증서 체인 시험
HSM 부분 지원	키 생성은 되지만 백업·복구·장애조치 실패	전체 키 수명주기와 DR 전환 시험
외부 일정 불일치	내부 준비 후 공동망·파트너가 미지원	계약 책임, 시험 창구, 버전, 종료일을 문서화
장기 검증 실패	신규 서명은 되지만 과거 문서 검증 불가	타임스탬프, 검증정보, 아카이브 정책 검토
구성 드리프트	운영은 성공하고 DR·배치·지점만 실패	환경별 정책 해시와 정기 복구 리허설
관측성 공백	오류는 늘지만 협상 알고리즘을 모름	연결·키·인증서 이벤트 필수 필드 정의
알고리즘 고정	변경마다 코드와 앱 재배포 필요	정책·설정 기반 선택과 버전 가능한 인터페이스
정오표 미반영	동일 표준 이름인데 구현 결과가 다름	표준·정오표·라이브러리·검증 벡터 버전 고정

7. 암호 민첩성은 설정 스위치가 아니라 운영 능력이다

암호 민첩성은 알고리즘 이름을 환경변수로 옮기는 것만으로 완성되지 않습니다.

• 알고리즘, 파라미터, 인증서 프로파일을 정책 버전으로 관리한다.
• 키 생성·배포·회전·폐기·백업·복구를 자동화하고 증거를 남긴다.
• 새 정책을 제한된 트래픽과 자산군에 카나리 적용한다.
• 협상 결과와 폴백을 관측하고 정책 위반을 경보로 만든다.
• 표준·정오표·벤더 지원 변경 시 영향 자산을 즉시 조회한다.
• 앱·인프라·HSM·CA 정책을 하나의 변경 세트로 롤백한다.
• 새 암호 라이브러리와 빌드 산출물의 출처를 검증한다.

암호 라이브러리와 빌드 도구 교체는 SLSA 프로비넌스로 빌드 산출물 신뢰를 증명하는 법과 연결하는 편이 좋습니다. PQC 도입 과정에서 공급망 검증이 약해지면 전환 목적과 반대되는 위험이 생깁니다.

8. 90일 실행 계획과 책임 분담

0~30일: 범위와 소유자

• CISO 또는 CTO 아래에 암호 인벤토리 책임자를 지정한다.
• 대외 TLS, 내부 mTLS, VPN, 코드·문서 서명, HSM·KMS, 백업을 범위로 정한다.
• 데이터 보호 기간과 전환 리드타임의 분류 기준을 합의한다.
• 주요 벤더·외부기관에 지원 버전, 정오표 반영, 시험 환경, 계약 책임을 질의한다.
• “알 수 없음” 항목을 숨기지 않고 별도 위험으로 등록한다.

31~60일: 발견과 우선순위화

• 자동 스캔, 코드 검색, HSM·CA 로그, 담당자 인터뷰를 통합한다.
• 자산별 소유자, 마지막 확인일, 복구 경로를 붙인다.
• 보호 기간, 수집 가능성, 리드타임, 실패 영향, 공급망 불확실성으로 순위를 매긴다.
• PoC 후보 1~2개와 성공·중단·롤백 조건을 정한다.
• 운영·DR·백업 복구 환경의 구성 차이를 확인한다.

61~90일: 제한된 PoC와 롤백 훈련

• 관찰 모드와 작은 카나리 비율로 시작한다.
• 협상, 지연, 자원, 메시지 크기, 실제 HSM 경로를 측정한다.
• 중간 장비 장애, 인증서 만료, HSM 노드 손실, 외부기관 미지원 시나리오를 주입한다.
• 이전 정책으로 되돌리고 세션·키·서명·감사 로그를 검증한다.
• 결과를 구매 기준, 계약 요구, 다음 분기 로드맵에 반영한다.

역할	최소 책임
보안 아키텍처	정책, 위험 기준, 표준·정오표 추적
PKI·HSM 운영	키 수명주기, CA 프로파일, DR, 처리량
앱·플랫폼	라이브러리·프로토콜 적용, 카나리, 롤백
네트워크	프록시·로드밸런서·MTU·패킷 검증
법무·준법	전자서명, 보존, 감독 요구와 계약 검토
구매·벤더 관리	지원 일정, 책임, 종료일, 증빙 확보
업무 소유자	허용 중단 시간, 고객 영향, 우선순위 승인

9. 롤백 플레이북에 반드시 들어갈 항목

1. 중단 조건을 누가 선언하고 어떤 채널로 전파하는가.
2. 인증서·정책·라이브러리·HSM 설정 중 무엇을 어떤 순서로 되돌리는가.
3. 전환 중 생성된 키, 세션, 서명, 데이터는 어느 경로로 검증하는가.
4. 폐기 또는 노출이 의심되는 키와 인증서를 어떻게 무효화하는가.
5. 외부기관과 고객에게 어떤 사실을 언제 알리는가.
6. 증거 보존과 사후 분석을 위해 어떤 로그와 설정 스냅샷을 남기는가.
7. 롤백 후 약한 경로가 예외로 영구화되지 않게 만료일을 어떻게 관리하는가.

사고 대응 흐름은 클라우드 사고 대응 플레이북에 꼭 들어가야 할 최소 항목과 연결해 훈련할 수 있습니다.

10. 경영진 대시보드는 “전환율”보다 검증 가능성을 보여 줘야 한다

• 암호 사용 위치 중 소유자와 용도가 확인된 비율
• 장기 보호 데이터 중 전환 계획이 승인된 비율
• 주요 벤더·외부기관의 지원 일정 확인률
• PoC에서 실제 측정한 호환 장치·경로 비율
• 허용되지 않은 폴백과 미확인 인증서 수
• 키 백업·복구·DR 훈련 성공률과 마지막 실행일
• 표준·정오표·라이브러리 버전이 추적되는 자산 비율
• 만료된 전환 예외와 미해결 “알 수 없음” 항목 수

“PQC 적용 시스템 수”만 높으면 조용한 폴백, 미지원 DR, 장기 검증 실패를 숨길 수 있습니다. 경영진에게는 얼마나 많이 바꿨는지보다 무엇을 확인했고 무엇을 되돌릴 수 있는지를 보여 주는 편이 낫습니다.

배포 전 체크리스트

• RSA/ECC 사용 위치를 소스·네트워크·HSM·벤더 관점에서 교차 확인했는가.
• 데이터 보호 수명과 법정 보존·검증 기간을 분리해 기록했는가.
• FIPS 본문과 최신 정오표, 구현·검증 벡터 버전을 고정했는가.
• 미지원 시 실패·폴백 정책이 자산별로 정의됐는가.
• 구형 단말, 외부기관, 프록시·보안장비의 호환성을 시험했는가.
• HSM·CA 처리량, 키 백업·복구, 장애조치를 실제로 측정했는가.
• 전환 중 발급된 인증서와 과거 서명을 장기 검증할 수 있는가.
• 롤백이 신규 데이터·키·세션·서명을 손상시키지 않는가.
• 정책 변경과 예외에 소유자, 승인, 만료, 감사 로그가 있는가.
• 감독·법적 효력·보존·암호모듈 요구를 최신 자료로 검토했는가.

참고 기준

1. NIST FIPS 203: ML-KEM
2. NIST FIPS 204: ML-DSA
3. NIST FIPS 205: SLH-DSA
4. NIST SP 800-227: Recommendations for Key-Encapsulation Mechanisms
5. NIST CSWP 39: Considerations for Achieving Cryptographic Agility
6. NIST IR 8547 Initial Public Draft: Transition to PQC Standards
7. NIST Post-Quantum Cryptography Project
8. NCCoE Migration to Post-Quantum Cryptography
9. CISA Quantum-Readiness
10. CISA Product Categories for Technologies That Use PQC Standards

최종 판단

금융권 PQC 마이그레이션의 첫 산출물은 새 장비나 인증서가 아니라 신뢰할 수 있는 암호 자산 인벤토리입니다. 그 위에서 데이터 수명, 외부 종속성, 상호운용성, 정오표 반영, 성능, 장애·복구를 순서대로 검증해야 합니다.

좋은 전환 계획은 “언제 모두 바꿀 것인가”보다 “어디서 실패할 수 있고, 그 실패를 어떻게 발견하고 되돌릴 것인가”에 답합니다. 가장 좋은 첫 투자는 정확한 인벤토리, 소유자 지정, 벤더 질의, 제한된 PoC와 롤백 훈련입니다.