PQC 전환 시나리오별 테스트 케이스: 정상/예외/다운그레이드 공격까지
PQC 전환은 ‘새 알고리즘을 켠다’가 아니라, TLS 협상 결과가 정책대로 떨어지고 그 사실이 운영 관측에 남는지까지 확인하는 작업이다. 그래서 테스트 케이스도 정상 동작만 보면 부족하고, 예외 상황에서의 폴백과 다운그레이드 공격 시도를 함께 묶어야 전환 품질이 안정된다. 같은 케이스라도 CDN·로드밸런서·애플리케이션 서버처럼 경계 지점이 달라지면 실패 양상이 달라지니 구간별로 반복 실행한다. 1) 정상 시나리오에서 확인할 것(성공, 폴백, 성능, 관측) 정상 시나리오에서는 하이브리드 키 교환이 실제로 성립하는지부터 본다. 예를 들어 TLS 1.3에서 ECDHE와 ML-KEM을 결합한 하이브리드 그룹을 제안했을 때 서버가 이를 선택해 핸드셰이크가 성공하고, 최종 협상된 버전·그룹·암호군이 로그와 메트릭에 남아 “PQC 적용 트래픽”을 대시보드에서 분리해 볼 수 있어야 한다. 하이브리드 설계와 ECDHE-MLKEM 그룹은 IETF 초안으로 정리돼 있으니, 실제 배포 스택이 어느 조합까지 지원하는지도 함께 기록한다. PQC 미지원 클라이언트가 들어올 때는 무조건 실패가 아니라, 구간 정책에 따라 ‘PQC 필수’ 엔드포인트는 차단, ‘PQC 선호’ 엔드포인트는 통제된 범위에서만 클래식으로 폴백되는지 확인한다. 성능은 전환 전후로 핸드셰이크 크기 증가와 P95 지연, CPU를 같은 부하에서 비교해 “허용 증가폭”을 KPI로 남겨야 한다. 2) 예외·호환성 시나리오에서 확인할 것(표준 경로, 중간장비, 인증서, 폭주) 예외·호환성 시나리오는 “깨졌을 때 어디서 어떻게 깨지는지”를 재현하는 게 핵심이다. 서버가 모르는 그룹을 제안했을 때 명확한 alert로 종료되는지, HelloRetryRequest 경로를 타더라도 최종 협상이 정책 위반 없이 끝나는지, 그리고 ClientHello나 인증서 체인이 커져 MTU·프록시·로드밸런서에서 드롭/타임아웃이 나지 않는지를 본다. 인증서 쪽은 만료·이름 불일...
