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일 플랜: 파일럿으로 검증하고, 하이브리드 운영으로 굴리기
180일은 실제 운영 조건에서 검증하는 기간입니다. 파일럿은 외부 트래픽이 있는 TLS 한 구간(특정 도메인 또는 일부 리전)에서 ML-KEM 중심의 키 교환을 시험하고, 통제 가능한 내부 mTLS 한 구간에서 호환성과 장애 패턴을 확인하며, 코드서명 파이프라인에서 서명 알고리즘 전환 가능성을 점검하는 흐름으로 잡으면 깔끔합니다. 중요한 건 성공 여부보다 실패가 났을 때 어디가 깨지는지 재현 가능하게 기록하는 것입니다.
검증 항목은 CPU만 보면 놓치는 게 많습니다. PQC는 키·서명 크기 영향으로 핸드셰이크 트래픽, 인증서 체인 크기, MTU 이슈, 로깅·저장 비용까지 같이 커질 수 있으니, 지연과 오류율뿐 아니라 패킷 단편화나 중간장비 반응도 함께 봅니다. 그리고 되돌리기(폴백), 모니터링 지표(성공률·지연·실패 원인 분류), 키·인증서 수명주기까지 런북으로 굳혀야 1년 확장 단계에서 흔들리지 않습니다.
또한 표준 문서가 고정이라고 가정하지 않는 게 좋습니다. NIST FIPS 203과 204는 2025년 11월 17일, 2025년 12월 18일에 각각 향후 수정될 이슈(Errata/잠재 업데이트)를 공지해 두었기 때문에, 표준 변경 감시는 운영 항목으로 넣는 게 안전합니다.
3) 1년 플랜: 확대 적용, PKI 정비, 암호 민첩성 정착
1년 플랜의 목표는 몇 개 서비스에 PQC를 넣었다가 아니라, 조직이 계속 바꿀 수 있는 체질이 되는 것입니다. 초반 4개월은 외부 경계(대표 웹서비스, API 게이트웨이, VPN 게이트웨이)에서 적용 범위를 넓히고, 다음 4개월은 PKI를 정비하는 데 시간을 씁니다. 인증서 정책, 자동 발급·갱신, 체인 길이와 호환성, 키 보관(HSM/KMS)까지 같이 손보지 않으면 중간에서 발목이 잡힙니다.
마지막 4개월은 거버넌스를 고정합니다. 신규 시스템은 기본값을 PQC 또는 하이브리드로 두고, 허용 알고리즘 목록과 라이브러리 표준을 문서가 아니라 리뷰 체크리스트와 CI 규칙으로 박아넣습니다. 암호 민첩성은 다음 알고리즘으로도 갈아탈 수 있는 구조를 의미하니, 서비스가 암호 구현을 직접 들고 있지 않게 추상화하고, 벤더 종속 지점을 줄이는 방향이 효과적입니다.
4) 결론
PQC 전환 일정표는 90일에 전환 가능한 상태를 만들고, 180일에 파일럿으로 운영 검증을 끝내고, 1년에 확산과 거버넌스로 굳히는 흐름이 가장 덜 흔들립니다. NIST의 PQC 표준(FIPS 203/204/205)이 2024년 8월 13일에 최종 발행되면서 일정표를 만들 수 있는 기준점이 생겼고, 2025년 후반에 공지된 Errata 이슈를 고려하면 표준 변경 감시는 운영 항목에 가깝습니다. 결국 성패는 알고리즘 이름이 아니라, 인벤토리 정확도, 우선순위 규칙, 파일럿 설계, 런북과 모니터링처럼 운영 언어로 번역했는지에 달려 있습니다.