NIST는 2024년 8월 13일 양자내성암호 표준인 FIPS 203, 204, 205를 확정해 발표했습니다. NIST의 표준 발표 자료에서 확인할 수 있는 이 표준 확정이 기업별 비용표까지 제공하는 것은 아닙니다. 따라서 NIST PQC 마이그레이션 비용 산정은 통일된 단가를 가져다 쓰기보다, 실제 암호 자산과 의존성, 시험 범위, 공급사 협조 수준, 단계별 배포 작업을 조사해 범위와 가정을 기록하는 방식으로 진행해야 합니다. 첫 조치는 예산 숫자를 정하는 일이 아니라 대상 시스템과 산정 범위를 확정하는 일입니다.
이 글은 마이그레이션 예산을 제출해야 하는 보안 책임자와 작업 범위·일정을 잡는 프로젝트 관리자에게 적합합니다.
시스템 변경을 맡은 엔지니어링 책임자는 코드 의존성과 검증 작업을 예산 항목으로 나눌 때 참고할 수 있습니다.
산정 범위와 예산 형식부터 정하기
예산을 만들기 전에 이번 계획이 어디까지 포함하는지 구분합니다. 마이그레이션 계획 수립, 시험 환경에서의 시범 적용, 정식 시스템 변경, 출시 이후의 지속 운영은 서로 다른 성격의 작업입니다. 일부만 이번 예산에 반영한다면 제외한 단계와 다음 검토 시점을 함께 적어야 합니다.
기업의 규모가 비슷해도 암호 사용 방식과 시스템 연결 관계는 다릅니다. 따라서 출처가 확인되지 않는 업계 평균이나 단일 단가를 적용하면, 빠진 공급사 작업이나 운영 부담이 감춰질 수 있습니다. 산출물은 작업 항목, 담당 조직, 산정 근거, 전제 조건, 미확정 사항을 한눈에 검토할 수 있는 형태로 만듭니다.
NIST NCCoE는 양자내성암호 전환을 위한 자료와 상호운용성 관련 안내를 제공하고 있습니다. NCCoE의 PQC 전환 안내는 계획에 참고할 공식 자료이지, 기업별 작업량이나 비용을 정해 주는 견적서가 아닙니다.
암호 자산 조사와 위험 분류
자산 조사 결과가 부족하면 이후 작업의 크기와 책임 주체도 불분명해집니다. 목록에는 시스템 이름만 적지 말고, 암호가 사용되는 위치와 목적, 운영 책임자, 관련 라이브러리와 공급 제품, 연결되는 서비스, 교체 가능성을 함께 기록합니다. 소스 코드에서 확인되는 사용처와 설정 파일, 배포 환경, 인증서 처리 경로도 대조해야 합니다.
목록 작성은 발견과 확인을 나눠 진행합니다. 자동화된 탐색으로 드러난 자산은 담당자 인터뷰와 실제 배포 정보로 확인하고, 소유자가 불분명한 항목은 미확정 상태로 남깁니다. 중요 업무와 외부 노출 여부, 변경 승인 절차를 고려해 우선순위를 정하되, 확인되지 않은 규모를 임의로 채우지 않습니다.
- [ ] 조사 대상 시스템과 제외 범위를 문서화합니다.
- [ ] 암호 사용 위치와 관련 라이브러리를 시스템 책임자와 대조합니다.
- [ ] 외부 공급 제품, 서비스 계약, 지원 여부를 확인할 담당자를 지정합니다.
- [ ] 미확인 자산과 위험 우선순위의 근거를 구분해 기록합니다.
NCCoE의 전환 관련 예비 자료는 조직이 암호 사용 현황을 파악하고 전환을 검토할 때 참고할 수 있습니다. 실제 인력 투입은 각 기업의 자산 목록과 조사 방법으로 산정해야 합니다.
코드와 공급망 변경 범위 나누기
자산 목록을 만든 다음에는 변경 책임에 따라 작업을 분리합니다. 자체 코드의 암호 호출부, 공통 라이브러리, 인증서 처리, 통신 프로토콜, 외부 API 연결은 각각 다른 담당자와 승인 절차를 가질 수 있습니다. ML-KEM 적용 여부도 제품 이름만으로 예산에 반영하지 말고, 실제 연결 방식과 구현 지원, 배포 환경에서의 변경 필요성을 확인해야 합니다.
각 항목에는 현재 구현을 찾는 시간, 변경 설계와 개발, 코드 검토, 외부 공급사 확인, 배포 승인 작업을 붙입니다. 공급사에 문의한 사항은 답변 대기 중임을 표시하고, 계약 범위에 변경 지원이 포함되는지 확인합니다. 공식 제품 문서의 지원 상태와 계약상 지원 범위는 동일하다고 가정하지 않습니다.
NCCoE의 추가 전환 자료를 확인하면 구현과 상호운용성을 검토하는 데 참고할 내용을 찾을 수 있습니다. 그러나 그 자료의 사례를 자사 시스템의 작업 시간이나 비용으로 그대로 환산해서는 안 됩니다.
검증과 운영을 별도 작업으로 계산하기
개발이 끝나도 호환성과 출시 준비가 자동으로 끝나는 것은 아닙니다. 테스트 범위에는 기존 연결과의 호환성, 성능 측정, 오류 상황, 설정 변경, 환경별 배포, 실패 시 되돌리기 절차가 포함될 수 있습니다. 작업량은 다른 조직의 성능 결과로 추정하지 말고, 자체 시험 환경에서 다시 실행할 수 있는 결과와 필요한 인력으로 계산합니다.
NCCoE의 마이그레이션 및 상호운용성 안내는 검증 계획을 세울 때 참고할 수 있습니다. 조직의 네트워크 구성과 애플리케이션 동작이 다르므로, 외부 사례는 시험 항목을 빠뜨리지 않도록 돕는 참고자료로 한정합니다.
운영 예산은 초기 전환비와 따로 둡니다. 키 수명 주기와 설정 관리, 로그 및 모니터링, 의존성 갱신, 공급사 지원 상태의 지속 확인에 필요한 책임자와 점검 절차를 정합니다. NIST의 암호 민첩성 지침은 알고리즘 변경에 대응할 체계를 검토하는 근거로 활용할 수 있습니다. 비용을 계산할 때에는 운영을 어느 기간까지 포함했는지, 반복 점검을 어느 조직이 맡는지 명시해야 합니다.
| 선택지 | 예산에 넣을 작업 | 판단 기준 |
|---|---|---|
| 계획 수립만 진행 | 자산 발견, 위험 분류, 공급사 확인, 전환 순서 설계 | 대상과 책임자를 먼저 알아야 예산을 세울 수 있는 경우 |
| 시범 적용까지 포함 | 계획 작업에 더해 제한된 시스템 변경, 호환성 시험, 되돌리기 검토 | 실제 구성에서 기술 의존성과 시험 범위를 확인해야 하는 경우 |
| 정식 전환과 운영까지 포함 | 시스템별 변경, 출시 준비, 지속 점검과 공급사 추적 | 승인된 범위와 운영 책임까지 예산에 포함할 경우 |
예산 질문을 작업 근거로 바꾸기
양자내성암호 전환 예산에 넣을 작업
자산 발견, 자체 코드와 외부 구성요소 변경, 공급사 협의, 통합 시험, 출시 준비, 이후 운영을 각각 나눠 기록합니다. 각 작업에는 담당 조직과 완료 기준을 붙입니다. 하나의 포괄 항목으로 합치면 누락된 책임과 비용이 드러나지 않으므로, 확인된 작업과 잠정 작업을 따로 관리합니다.
기존 시스템의 변경량을 추정하는 근거
저장소 검토와 배포 구성 확인으로 암호 사용 위치를 찾고, 영향을 받는 모듈 및 연결 서비스를 표시합니다. 그다음 담당자가 직접 코드와 테스트 절차를 검토해 필요한 변경과 재검증 범위를 정합니다. 계약이나 지원 문서에서 확인할 수 없는 작업은 확정치로 다루지 말고 공급사 확인 항목으로 둡니다.
조사 결과를 예산으로 연결하는 방법
자산별로 책임자, 암호 의존성, 업무 중요도, 변경 후보를 연결한 뒤, 해당 자산에 필요한 조사·개발·검증·승인 작업을 배정합니다. 확인을 마친 항목은 산정 근거와 함께 본 예산에 넣고, 소유자나 기술 정보가 빠진 항목은 별도의 미확정 목록으로 보냅니다. 이렇게 해야 조사 공백이 임의의 비용 숫자로 바뀌는 일을 막을 수 있습니다.
예측이 어려운 전환 비용
공급사 답변이 없는 제품 지원, 문서화되지 않은 암호 의존성, 서로 다른 환경 사이의 호환성은 추가 작업을 발생시킬 수 있습니다. 낮은 범위에는 확인된 작업만, 중간 범위에는 답변을 받으면 진행할 수 있는 작업을, 높은 범위에는 추가 변경이나 재시험이 필요한 가정을 반영합니다. 각 범위는 실제 견적서와 내부 공수 기록으로 갱신해야 하며, 외부 기관의 작업량을 자사 비용으로 바꾸어 적지 않습니다.
범위별 시나리오와 불확실성 기록
추정 결과는 금액 하나보다 낮음·중간·높음의 시나리오로 제시하는 편이 검토에 유용합니다. 이는 임의의 할인율이나 업계 평균을 붙이라는 뜻이 아닙니다. 확인된 자산, 공급사 답변 여부, 재시험 가능성, 전환 대상 범위가 달라질 때 어떤 작업이 추가되거나 제외되는지를 설명하는 방식입니다.
예산 검토용 목록에는 다음 항목을 남깁니다.
- [ ] 확정된 자산과 아직 책임자를 찾지 못한 자산을 구별합니다.
- [ ] 자체 개발, 외부 제품, 인증서와 서비스 연결의 변경 책임을 표시합니다.
- [ ] 시험 환경, 호환성 확인, 실패 대응, 출시 승인을 포함합니다.
- [ ] 일회성 전환 작업과 이후 반복 운영을 나눕니다.
- [ ] 공급사 답변 대기 항목과 비용 산정 가정을 별도로 기록합니다.
- [ ] 금액을 적을 때에는 실제 견적서, 계약 자료, 내부 공수 기록 중 근거를 연결합니다.
견적서나 내부 기록으로 확인할 수 없는 금액과 단가는 빈칸으로 두고, 확인 담당자와 다음 검토 조건을 적습니다. 이렇게 만든 범위는 공식 가격표나 NIST의 표준 비용이 아니라, 해당 기업이 검토할 수 있도록 근거를 남긴 내부 계획입니다.
자산 조사에서 시험 환경 계획까지 연결하기
첫 예산안은 암호 자산 조사 결과를 기준으로 작성하고, 담당자와 공급사 확인이 끝날 때마다 미확정 항목을 다시 분류하는 방식이 안전합니다. 이후 TLS 검증 범위와 환경별 시험 작업을 보완할 때는 맥 시스템 지원 안내에서 확인할 수 있는 정보를 현재 테스트 구성과 대조하십시오. 제공 여부와 조건은 실제 페이지에 표시된 내용으로 검토해야 합니다.
현재 환경만으로 시험하면 기존 권한과 배포 절차에 묶일 수 있고, 별도 테스트 환경을 직접 마련하면 사용하지 않는 기간에도 장비 관리와 접근 통제에 신경 써야 합니다. 원격 환경 역시 조직의 보안 정책과 실제 시험 요건에 맞는지 확인이 필요합니다. 반면 맥 기반 시험이 필요하지 않거나 물리 장치와 내부망 접근이 필수라면, 맥 대여가 적합하지 않을 수 있습니다.
일시적인 맥 환경이 필요한 경우에는 한국어 맥 미니 대여 안내의 현재 서비스 정보와 조건을 확인해 예산에 반영할 수 있습니다. 최종 산정에서는 보유 환경의 권한·유지 부담·구성 차이와 대여 환경의 실제 제공 조건을 같은 작업 범위로 비교해야 합니다. NIST PQC 마이그레이션 비용 산정의 출발점은 그 비교에 앞서, 어떤 자산을 누가 어떤 기준으로 검증할지 확정하는 일입니다.
검증 예산을 원격 맥 환경에서 구체화하세요
작업 항목과 검증 범위가 정리됐다면 원격 맥에서 실제 빌드와 테스트를 진행해 보세요.
전용 맥 미니를 개발과 지속 통합 작업에 활용해 반복 검증 환경을 구성할 수 있습니다.