PQC 전환 일정표 만들기: 90일·180일·1년 플랜 예시

PQC 전환 일정표 만들기: 90일·180일·1년 플랜 예시 PQC 전환 일정표를 90일·180일·1년 플랜으로 정리해 ML-KEM(Kyber)과 ML-DSA(Dilithium) 적용 순서, 파일럿 설계, 운영 확장까지 한 번에 잡는 예시를 제시합니다. PQC 전환은 알고리즘을 교체하는 일 같지만, 실제로는 서비스 흐름과 운영체계를 이동시키는 일에 가깝습니다. NIST가 FIPS 203(ML-KEM), FIPS 204(ML-DSA), FIPS 205(SLH-DSA)를 2024년 8월 13일에 최종 발행하면서 로드맵을 만들 수 있는 기준점이 생겼고, 다음은 그 기준을 일정표로 바꾼 실무형 예시입니다. 1) 90일 플랜: 전환이 가능한 상태 만들기(인벤토리와 우선순위, 설계) 첫 90일은 도입 성과를 크게 내기보다, 전환이 가능한 상태를 만드는 데 집중하는 게 효율적입니다. 시작은 어디에서 RSA/ECC/DH를 쓰는가를 서비스 흐름 기준으로 한 번에 보이게 정리하는 것입니다. 웹과 API의 TLS, 내부 mTLS, VPN, PKI와 인증서 발급·갱신, 코드서명, 이메일 서명, 그리고 데이터 암호화와 키관리(KMS/HSM 포함)까지 넓게 잡되, 문서가 아니라 실제 트래픽 경로와 릴리즈 경로 기준으로 연결해 둡니다. 이 단계에서 NIST IR 8547은 전환을 특정 팀의 과제가 아니라 조직 전체의 마이그레이션 계획으로 다루는 관점을 강조합니다. 정리 다음에는 우선순위를 숫자로 고정합니다. 외부 노출 구간, 장기 기밀 데이터, 갱신 주기(인증서나 펌웨어처럼 교체 타이밍이 있는 자산), 고객·규제 요구를 기준으로 점수화하면 의견 싸움이 줄어듭니다. 마지막으로 목표 아키텍처를 결정하는데, 초반에는 기존 방식과 PQC를 함께 쓰는 하이브리드 접근이 현실적입니다. 90일의 산출물은 파일럿 3개만 바로 할 수 있게 범위를 잘라둔 설계서, 그리고 제품·벤더 지원 격차(어떤 버전에서 되는지, 대체가 뭔지) 목록이면 충분합니다. 2) 180일 플랜: 파일럿으로 검증...

mTLS에 PQC 적용하기: 서비스-서비스 인증서 교체 전략

mTLS에 PQC를 적용하려면 서비스-서비스 인증서 교체를 무리하게 한 번에 끝내기보다, 하이브리드 전환과 병행 운영으로 리스크를 줄이는 전략이 핵심이다.

서비스 간 통신은 mTLS로 잘 잠가도, 양자컴퓨터가 현실화되면 현재의 키교환과 서명 방식이 흔들릴 수 있다. 그래서 PQC 적용은 “암호화(키교환)”와 “인증(인증서 서명)”을 분리해서 단계적으로 바꾸는 게 안전하다. 이 글은 서비스-서비스 환경에서 인증서 교체를 어떻게 설계하면 운영 충격을 최소화할지 정리한다.

mTLS에 PQC 적용

1) mTLS에서 PQC를 어디에 넣을지 먼저 나누기(키교환 vs 인증서)

mTLS는 크게 두 축이다. 첫째는 세션키를 만드는 키교환이고, 둘째는 서버/클라이언트 신원을 증명하는 인증서 서명이다. 실무에서 가장 빠르게 효과를 보는 쪽은 키교환에 “하이브리드(기존+PQC)”를 붙이는 방식이다. TLS 1.3 하이브리드 키교환은 여러 알고리즘을 동시에 써서, 그중 하나만 안전해도 전체가 안전해지도록 설계된다. 

현업 적용 포인트는 “인증서는 그대로(ECDSA/RSA), 키교환만 하이브리드로” 먼저 가는 것이다. 이렇게 하면 서비스 인증서 체계(사내 CA, 워크로드 아이덴티티, 서비스 메시)를 크게 흔들지 않고도, 수집 후 해독 리스크를 우선 낮출 수 있다. Cloudflare가 TLS에서 하이브리드 키교환을 실서비스에 배포해 온 것도 이 경로가 현실적이라는 신호다.

반면 “인증서 자체를 PQC 서명(예: ML-DSA)으로 바꾸는 것”은 클라이언트/프록시/라이브러리의 X.509 처리 호환성이 걸려서, 계획 없는 일괄 전환이 가장 위험하다. 그래도 표준은 빠르게 정리되는 중이며, NIST는 ML-KEM, ML-DSA, SLH-DSA를 FIPS로 승인했다.

2) 서비스-서비스 인증서 교체의 3가지 설계 패턴

패턴 A: 하이브리드 키교환 선적용 + 기존 인증서 유지
프록시(Envoy/Nginx), 게이트웨이, SDK에 PQC 지원 TLS 스택을 붙여 키교환만 하이브리드로 올린다. OpenSSL 3의 Provider 구조를 이용해 OQS Provider를 붙이면 TLS 1.3의 PQC/하이브리드 키교환과 X.509 관련 실험이 가능하다.

패턴 B: 이중 PKI 병행
사내 루트/중간 CA를 PQC용으로 별도 만들고, 서비스가 두 종류의 신원(클래식, PQC)을 동시에 갖도록 한다. 상대의 지원 여부에 따라 PQC 체인을 제시하거나 기존 체인을 쓰는 협상 로직이 핵심이다. ML-DSA를 X.509에서 쓰기 위한 규칙이 IETF RFC로 정리돼 PoC 설계 근거가 생겼다.

패턴 C: PQC 키를 신원에 먼저 묶어두기
당장 PQC 인증서로 검증까지 못 가더라도, 서비스 신원에 PQC 공개키를 함께 배포해 두면 전환 속도가 빨라진다. 예를 들어 사내 레지스트리나 워크로드 아이덴티티 문서에 PQC 공개키를 넣고, 기존 인증서로 그 문서를 서명해 “이 PQC 키는 이 서비스 소유”를 먼저 고정한다.

3) “교체 전략”을 운영 일정으로 바꾸는 체크리스트

1단계(0~90일): 인벤토리와 관측
어떤 경로가 mTLS인지, 어떤 TLS 라이브러리를 쓰는지부터 정리하고, 핸드셰이크 크기와 실패율을 지표로 잡는다. 하이브리드 키교환은 ClientHello가 커져 일부 장비/미들박스에서 문제가 드러난 사례가 보고됐다. 

2단계(90~180일): 하이브리드 키교환을 프록시 계층에 먼저
가능하면 애플리케이션 코드가 아니라 사이드카/게이트웨이에서 켠다. 기능 플래그로 점진 롤아웃(카나리)을 적용해 실패 시 되돌림을 쉽게 만든다.

3단계(6~12개월): PQC 인증서 파일럿
RFC와 FIPS를 기준으로 ML-DSA 기반 인증서를 내부 신뢰 저장소에만 제한 배포하고, 실패 시 즉시 클래식 체인으로 되돌아가게 만든다. 장기 운영은 표준(ML-KEM/ML-DSA/SLH-DSA) 중심으로 좁혀 설계하는 편이 안전하다.

4) 결론

mTLS에 PQC를 적용할 때 서비스-서비스 인증서 교체는 한 번에 끝내는 프로젝트가 아니라, 키교환과 인증서를 분리해 위험을 쪼개는 전환 전략이 맞다. 먼저 하이브리드 키교환으로 기밀성 리스크를 낮추고, 그다음 내부 CA 기반의 PQC 인증서를 제한된 구간에서 병행 운영하는 순서가 현실적이다. 표준은 NIST FIPS와 IETF 문서를 기준으로 삼으면 흔들림이 줄어든다. 최종 목표는 병행 호환성과 자동화된 짧은 수명 인증서 회전을 묶어, 교체 자체가 일상이 되게 만드는 것이다.