핵심 요약
PQC 전환은 RSA/ECC를 무엇으로 바꿀지 토론하는 프로젝트가 아니다. 실제 현장에서는 어디에 어떤 인증서, 키, 서명, 라이브러리, 장비가 박혀 있는지를 먼저 찾는 일이 승부를 가른다.
즉 PQC는 암호학 문제이기 전에 암호자산 운영 모델과 변경관리 문제다. 인벤토리 없이 일정부터 잡으면 실패하고, 인벤토리가 있으면 우선순위와 전환 순서가 보인다.
결론은 단순하다. 알고리즘보다 암호자산 인벤토리가 먼저다. 그리고 현실적인 전환 방식은 대부분의 조직에서 전면 교체가 아니라 하이브리드 운영이다.
이 글은 누구를 위한 문서인가
- 보안 아키텍트: PQC를 어디서부터 적용해야 하는지 구조적으로 판단해야 하는 사람
- 인프라·플랫폼 운영자: TLS, PKI, HSM, 중간장비, 배포 파이프라인에서 실제 충돌 지점을 찾아야 하는 사람
- 전환 프로그램 관리자: 알고리즘 논쟁보다 일정·우선순위·벤더 의존성을 먼저 정리해야 하는 사람
이 글의 역할: PQC 대표 문서
이 문서는 PQC를 기술 소개가 아니라 조직 차원의 전환 프로젝트로 설명하는 대표 문서다.
즉 “무슨 알고리즘을 쓸까?”보다 “어디부터 바꿔야 일정이 안 터지나?”에 답하는 문서다.
3분 판단 규칙: 지금 PQC 전환을 밀어도 되는가
| 질문 | Yes면 | No면 |
|---|---|---|
| 암호자산 인벤토리를 최소 1장으로 설명할 수 있는가 | 우선순위 설계와 파일럿 시작 가능 | 알고리즘 논의보다 자산 식별이 먼저 |
| 외부 TLS / 내부 PKI / 코드서명 / 장기보관 데이터를 분리해 봤는가 | 영향 범위와 일정 리스크를 구분할 수 있음 | 전환 범위를 과소평가할 가능성이 큼 |
| WAF·Proxy·HSM·벤더 장비 지원 계획을 확인했는가 | 하이브리드 테스트 설계 가능 | 가장 비싼 지연이 중간장비에서 터질 수 있음 |
| CLM 또는 자동화 기반이 있는가 | 전환 후 운영부채를 줄일 수 있음 | 수동 인증서 갱신 구조라면 PQC는 더 무거워짐 |
이 글의 핵심 오해 1개
“NIST 표준이 나왔으니 라이브러리만 업데이트하면 된다”는 생각이 가장 위험하다.
PQC는 키/서명 크기와 핸드셰이크 특성이 달라서, 실제 문제는 네트워크 장비·WAF·TLS 중간장비·HSM·레거시 라이브러리 같은 운영 레이어에서 터진다.
즉 PQC는 암호학보다 인프라 운영과 변경관리(Change Management)가 본게임이다.
TL;DR — PQC 전환은 ‘알고리즘 교체’가 아니라 ‘암호자산 운영 리모델링’이다
- 가장 큰 리스크: 지금 저장하고 나중에 해독하는 Harvest now, decrypt later 공격은 오늘 수집된 트래픽/데이터가 미래에 깨질 수 있다는 문제다.
- 가장 흔한 실패: RSA/ECC를 무엇으로 바꿀지 토론만 하다가, 정작 어디에 인증서/키/라이브러리가 박혀 있는지 몰라 일정이 폭발한다.
- 성공의 핵심: ① 암호자산 인벤토리 → ② 우선순위(데이터 수명/노출면/교체 난이도) → ③ 하이브리드 전개 → ④ 자동화(CLM)로 고정한다.
시각 앵커: PQC에서 실제로 발목 잡는 자산 5종
| 자산 유형 | 왜 위험한가 | 첫 점검 포인트 |
|---|---|---|
| 외부 TLS | 공개망 노출, 장기 수집-후해독 리스크와 직접 연결 | CDN, 로드밸런서, WAF, 프록시의 하이브리드 지원 여부 |
| 내부 PKI | 기기·서비스 수가 많고 수동 갱신이 남아 있으면 일정이 폭발 | 발급자, 만료일, 키 알고리즘, 사용처 인벤토리 |
| 코드서명 | 배포 파이프라인과 업데이트 신뢰체계 전체에 영향 | 서명 키 저장 위치, HSM, 타임스탬프, 검증 경로 |
| 장기보관 데이터 | 지금 저장한 데이터가 미래에 해독될 수 있음 | 백업, 로그, 녹취, 아카이브의 보관 기간과 재암호화 범위 |
| 벤더/협력사 연동 | 우리 통제 밖 구간이라 일정 지연이 자주 발생 | 지원 계획, 테스트 방법, 계약 조항 |
도입을 미뤄야 하는 반례
- 현재 어떤 인증서와 키가 어디에 쓰이는지 목록이 없는 상태
- 중간장비(WAF/Proxy/Inspection) 버전과 지원 여부를 아무도 모르는 상태
- 벤더가 “추후 지원 예정”만 말하고 일정·테스트 계획을 주지 않는 상태
- 수동 인증서 갱신과 예외 처리가 이미 운영 병목인 상태
이 4가지 중 하나라도 걸리면, 지금 필요한 것은 더 빠른 전환 발표가 아니라 암호자산 조사와 자동화 정리다.
왜 PQC가 필요한가: ‘양자컴퓨터가 내일 온다’가 아니라 ‘데이터 수명’의 문제다
PQC(Post-Quantum Cryptography)는 양자 공격까지 고려해 설계된 공개키 암호 체계다.
하지만 실무에서 PQC가 필요한 이유는 미래 공포보다 지금 만들어지는 데이터의 수명 때문이다. 5년, 10년 뒤에도 가치가 남는 데이터라면 이미 오늘부터 리스크가 누적된다.
실패 패턴 6가지
- 실패 A — 인벤토리 없이 일정부터 잡는다: “TLS부터 바꾸자”가 제일 위험하다. 실제로는 API 게이트웨이, 프록시, 모바일 SDK, IoT가 더 많이 박혀 있다.
- 실패 B — 중간장비에서 핸드셰이크가 깨진다: Inspection/WAF/Proxy에서 가장 많이 터진다.
- 실패 C — HSM/키보관 정책이 못 따라온다: 키 타입과 수명 정책 변화가 운영에 부담을 준다.
- 실패 D — 외부 벤더가 해주겠지 하고 미룬다: 계약·지원 계획이 늦으면 전환 전체가 멈춘다.
- 실패 E — 테스트를 ‘정상 접속’만 본다: 피크 트래픽, 재협상, 롤백에서 진짜 문제가 터진다.
- 실패 F — CLM 없이 전환한다: 수동 갱신이 남아 있으면 PQC는 운영 부채가 된다.
시각 앵커: PQC 전환 우선순위 결정표
| 대상 | 우선순위가 높은 조건 | 첫 액션 |
|---|---|---|
| 외부 TLS | 공개망 노출 + 데이터 수명이 길다 | CDN/로드밸런서와 중간장비 하이브리드 지원 점검 |
| 내부 PKI | 기기/서비스 수 많고 자동화 약함 | 인증서 인벤토리부터 수집 |
| 코드서명 | 장기 검증 필요 | 서명 체인과 검증 경로 문서화 |
| 장기 저장 데이터 | 보관기간 길고 재암호화 비용 큼 | 재암호화 범위 산정 |
실전 로드맵 5단계
1단계 — 인벤토리
인증서, 키, 라이브러리, 장비, 사용처를 먼저 지도처럼 그린다.
2단계 — 리스크 모델
데이터 수명, 공개 노출, 교체 난이도로 우선순위를 정한다.
3단계 — 하이브리드 전개
전면 교체보다 기존 암호와 PQC를 겹쳐서 운영한다.
4단계 — 검증
정상 접속만 보지 말고 피크 트래픽, 중간장비, 롤백까지 본다.
5단계 — 자동화 고정
CLM과 배포 자동화가 없으면 운영 부채가 다시 쌓인다.
오늘 바로 할 일
- 1장짜리 암호자산 지도 만들기: 외부 TLS, 내부 PKI, 코드서명, 장기저장 암호화 4칸으로 나눠 담당/시스템/알고리즘만 적는다.
- 중간장비 리스트업: WAF, Proxy, SSL Inspection, 게이트웨이 모델과 버전을 적는다.
- 벤더 요구사항 템플릿 준비: PQC 하이브리드 지원 계획, 일정, 테스트 방법을 문서로 받는다.
같이 보면 좋은 글
한 줄 결론
PQC 전환은 알고리즘 선택 문제가 아니라, 암호자산을 어디까지 보고 관리하고 자동화할 수 있느냐의 문제다.