PQC 적용 대상 찾기: TLS·VPN·전자서명·코드서명 어디부터 점검할까

PQC 전환을 준비할 때 가장 먼저 막히는 지점은 “우리 회사에서 어디부터 봐야 하는가”입니다. 알고리즘 이름을 아는 것보다 중요한 일은 실제로 공개키 암호가 쓰이는 연결, 인증, 서명, 배포 흐름을 찾아 목록으로 만드는 것입니다.

점검 대상은 보안 장비 하나로 끝나지 않습니다. 웹 서비스의 TLS, 원격 접속 VPN, 전자계약과 전자서명, 소프트웨어 업데이트에 쓰이는 코드서명, 인증서 발급 체계, HSM, 클라우드 관리형 서비스, 협력사 연동까지 함께 봐야 합니다. 기본 개념이 아직 헷갈린다면 포스트양자암호란? 초보자도 이해하는 PQC 입문을 먼저 확인하면 흐름을 잡기 쉽습니다.

PQC 적용 대상은 암호화 제품보다 넓다

PQC 인벤토리는 회사 안에서 공개키 암호가 쓰이는 시스템과 인증서, 서명, 연결 구간을 찾아 정리한 목록입니다. 이 목록이 있어야 어떤 시스템을 먼저 테스트하고, 어떤 장비를 교체하거나 갱신해야 하는지 판단할 수 있습니다.

PQC 적용 대상을 찾을 때는 “암호화 솔루션이 있는가”보다 “공개키 암호가 쓰이는가”를 기준으로 보는 것이 좋습니다. 현재 많은 시스템은 RSA, ECDSA, ECDH 같은 공개키 기반 기술로 키 교환, 인증, 서명, 인증서 체인을 처리합니다. PQC 전환은 이런 지점을 한 번에 바꾸는 작업이 아니라, 어디에서 쓰이는지 확인하고 위험도에 따라 바꾸는 장기 전환 작업에 가깝습니다.

특히 장기간 보호해야 하는 데이터, 외부에 노출된 접속 경로, 인증서와 서명 검증에 의존하는 업무, 자동 업데이트와 펌웨어 배포는 초기에 목록화해야 합니다. 나중에 장비 교체나 인증서 갱신 주기와 맞물리면 일정이 길어질 수 있기 때문입니다.

점검 기준은 연결·인증·서명·보관으로 나눈다

대상 시스템을 볼 때는 네 가지 질문으로 나누면 정리가 쉬워집니다. 첫째, 외부와 암호화된 연결을 맺는가. 둘째, 인증서나 공개키로 상대를 확인하는가. 셋째, 문서나 코드에 전자서명을 붙이는가. 넷째, 암호화된 데이터가 몇 년 이상 보관되는가입니다. 이 네 가지 중 하나라도 해당되면 PQC 인벤토리에 넣는 것이 안전합니다.

바로 바꾸는 대상과 먼저 기록할 대상을 구분한다

모든 시스템을 동시에 교체하려고 하면 우선순위가 흐려집니다. 외부 접점과 장기 보관 데이터는 먼저 점검하고, 내부 단기 세션이나 폐기 예정 시스템은 기록 후 갱신 시점에 맞춰 처리할 수 있습니다. 중요한 것은 지금 당장 교체 여부가 아니라, 빠뜨리지 않고 확인 가능한 목록을 만드는 것입니다.

TLS와 VPN은 가장 먼저 확인할 접속 경로다

TLS와 VPN은 외부 사용자, 협력사, 관리자, 지점망이 회사 시스템에 들어오는 관문입니다. 그래서 PQC 적용 대상 찾기에서 가장 먼저 봐야 할 영역입니다. 웹사이트, API 게이트웨이, 로드밸런서, CDN, WAF, 서비스 메시, mTLS 구성, SSL VPN, IPsec VPN, 원격관리 접속을 한 묶음으로 확인해야 합니다.

구분	확인할 대상	점검 포인트
TLS	웹, API, 로드밸런서, CDN, WAF, mTLS	인증서 체인, 키 교환 방식, 장비·라이브러리 지원 여부
VPN	SSL VPN, IPsec VPN, 지점 간 VPN, 관리자 접속	장비 교체 주기, 펌웨어 지원, 협력사 접속 영향
내부 통신	서비스 메시, 내부 API, 데이터베이스 TLS	내부 인증서 발급 체계, 자동 갱신, 장애 영향도

TLS는 인증서만 보지 말고 장비와 라이브러리까지 본다

TLS 점검은 인증서 만료일을 확인하는 수준으로 끝나면 안 됩니다. 웹서버, 프록시, 로드밸런서, CDN, WAF, 애플리케이션 런타임, TLS 라이브러리까지 함께 확인해야 합니다. 실제 적용 시점에는 프로토콜 지원, 클라이언트 호환성, 인증서 체인, 성능 영향이 함께 나타나기 때문입니다.

VPN은 업무 중단 영향이 커서 교체 주기를 먼저 확인한다

VPN은 장애가 나면 원격근무, 지점 연결, 외부 협력사 접속, 관리자 접속이 동시에 영향을 받을 수 있습니다. 장비 벤더의 PQC 지원 계획, 펌웨어 업데이트 가능 여부, 인증서 갱신 방식, 대체 접속 경로를 함께 기록해야 합니다. 오래된 VPN 장비는 암호 알고리즘보다 제품 수명 종료가 먼저 문제가 될 수 있습니다.

전자서명과 코드서명은 무결성 확인 흐름을 따라간다

전자서명과 코드서명은 데이터를 숨기는 목적보다 “누가 만들었고 변경되지 않았는가”를 확인하는 목적이 큽니다. 전자계약, 세금·회계 문서, 규제 제출 문서, 사내 승인 문서, 모바일 앱 배포, 데스크톱 프로그램 설치 파일, 펌웨어, 컨테이너 이미지, 배포 파이프라인의 서명 검증이 여기에 들어갑니다.

전자서명은 장기 검증과 보관 기간을 함께 본다

전자서명 문서는 작성 시점뿐 아니라 몇 년 뒤에도 검증되어야 하는 경우가 많습니다. 계약서, 감사 자료, 규제 제출 자료처럼 장기간 보관되는 문서는 서명 알고리즘, 타임스탬프, 인증서 체인, 보관 정책을 함께 확인해야 합니다. 단순히 “서명 기능이 있다”가 아니라 “나중에도 검증 가능한가”를 기준으로 봐야 합니다.

코드서명은 배포 신뢰와 공급망 보안에 연결된다

코드서명은 소프트웨어가 정상 제작자에게서 왔고 배포 중 변조되지 않았는지 확인하는 장치입니다. 설치 파일, 업데이트 패키지, 모바일 앱, 펌웨어, 드라이버, 컨테이너 이미지, 빌드 산출물에 서명이 쓰이는지 확인해야 합니다. 특히 자동 업데이트와 펌웨어 배포는 사용자나 현장 장비에 직접 영향을 주므로 우선순위를 높게 잡는 것이 좋습니다.

PQC 인벤토리에 넣을 항목

인벤토리는 너무 복잡하게 시작할 필요가 없습니다. 처음에는 시스템명, 담당 부서, 사용 위치, 암호 사용 목적, 알고리즘, 인증서 위치, 데이터 보관 기간, 벤더 지원 여부, 교체 예상 시점만 있어도 충분합니다. 이후 위험도가 높은 항목부터 세부 정보를 보강하면 됩니다.

기록 항목	예시	왜 필요한가
시스템·서비스명	고객 포털, VPN 장비, 전자계약 시스템	담당자와 영향 범위를 찾기 위해 필요
암호 사용 목적	키 교환, 인증, 전자서명, 코드서명	PQC 적용 방식이 목적마다 달라짐
알고리즘·인증서	RSA, ECDSA, ECDH, 인증서 체인, HSM	교체 대상과 호환성 검토 범위를 정하기 위해 필요
데이터 보관 기간	1년, 5년, 10년 이상, 영구 보관	장기 보호 데이터는 우선순위가 높아질 수 있음
벤더 지원 여부	지원 예정, 미정, 제품 교체 필요	예산과 전환 일정을 잡기 위해 필요

어디부터 점검할까

처음부터 모든 시스템을 같은 깊이로 조사하면 시간이 오래 걸립니다. 우선순위는 외부 노출, 장기 보호, 업무 중단 영향, 서명 신뢰, 교체 난이도를 기준으로 잡는 것이 현실적입니다.

전환은 테스트 환경에서 먼저 확인한다

PQC는 알고리즘만 바꾼다고 끝나는 작업이 아닙니다. 키와 서명의 크기, 인증서 체인, 네트워크 지연, 장비 성능, 오래된 클라이언트 호환성, 로그와 모니터링 방식이 함께 영향을 받을 수 있습니다. 운영 환경에 바로 적용하기보다 테스트 구간을 만들고, 벤더 지원 문서와 표준화 진행 상황을 확인하면서 단계적으로 검증하는 편이 안전합니다.

구매·갱신 계약에 PQC 지원 항목을 넣는다

지금 당장 모든 장비가 PQC를 완전하게 지원하지 않더라도, 새로 구매하거나 갱신하는 제품에는 암호 민첩성, 표준 알고리즘 지원 계획, 인증서 처리 방식, 펌웨어 업데이트 정책을 확인해야 합니다. 앞으로 바꿀 수 없는 제품을 새로 들이는 일을 줄이는 것만으로도 전환 부담을 낮출 수 있습니다.

공식 자료로 확인할 내용

알고리즘 이름과 지원 일정은 제품·표준·정책에 따라 달라질 수 있으므로 공식 자료를 기준으로 확인하는 것이 좋습니다. 특히 실제 적용 전에는 표준 문서, 벤더 지원 문서, 사내 보안 기준을 함께 봐야 합니다.

출처: NIST CSRC Post-Quantum Cryptography Standardization

함께 보면 좋은 글

자주 묻는 질문

---

PQC 적용 대상 찾기는 한 번에 끝내는 교체 작업이 아니라 공개키 암호 사용처를 찾고, 우선순위를 정하고, 갱신 주기에 맞춰 안전하게 바꾸는 준비 과정에 가깝습니다.