문제
“양자내성”에 2027, 2029, 2030, 2035 같은 연도가 계속 붙어 나오는데, 같은 이야기인지 알기 어렵습니다. 어떤 건 국가 규정이고, 어떤 건 표준이고, 어떤 건 브라우저가 이미 하고 있는 일입니다. 공개 웹사이트와 API를 운영하는 팀에게 질문은 더 단순합니다. 이 날짜들 중 무엇이 실제로 할 일을 바꾸고, 어떤 순서로 해야 하는가.
날짜를 한 표에
| 시점 | 내용 | 적용 대상 |
|---|---|---|
| 2024년 8월 | NIST, FIPS 203(ML-KEM)·204(ML-DSA)·205(SLH-DSA) 공표 | 다른 모든 일정이 참조하는 알고리즘 |
| 2024년 11월 | 크롬 131, X25519MLKEM768 기본 제안 | 크롬 사용자가 방문하는 모든 사이트 |
| 2024년 11월 | NIST IR 8547 초안: 양자 취약 알고리즘 2030년 이후 권장 중단, 2035년 이후 사용 불가(하이브리드 예외) | NIST 규정을 따르는 시스템 |
| 2026년 8월 | RFC 10024, TLS 1.3 하이브리드 ML-KEM 키 합의 표준화(X25519MLKEM768 권장) | TLS 구현체 |
| 2027년 | 국내: 공공 사이버보안 실태평가에 양자내성 반영, KEM 검증대상 선정(1월) | 국내 공공기관 |
| 2028년 1월 | 국내: KEM 검증, 전자서명 검증대상 선정 | 검증필 암호모듈 |
| 2029년 1월 | 국내: KEM 탑재 의무화 | 검증필 암호모듈 |
| 2030년 1월 | 국내: 전자서명 탑재 의무화(선정 2년 뒤) | 검증필 암호모듈 |
| 2030년 / 2035년 | NIST: 기존 공개키 단독 사용 권장 중단 / 사용 불가 | NIST 규정을 따르는 시스템 |
| 2035년 | 국내: 국가 암호체계 전환 목표 | 공공 부문 암호 |
국내 일정은 ZDNet Korea와 한국데이터경제신문에 보도된 국정원 계획 기준이고, NIST 일정은 IR 8547 초안 기준입니다.
웹에서는 이미 일어난 일
규정은 트래픽보다 느립니다. Cloudflare는 2026년 9월, 자사 네트워크로 들어오는 **브라우저 트래픽의 약 70%**가 이미 하이브리드 ML-KEM을 쓰지만, Cloudflare에서 원 서버로 가는 연결은 **원 서버의 약 15%**만 지원한다고 밝혔습니다. 인터넷의 방문자 쪽은 대부분 바뀌었고, 서버 쪽은 대부분 그대로라는 뜻입니다. 사이트가 CDN 뒤에 있다면, 방문자는 엣지까지 보호되지만 우리 서버로 가는 구간은 아닐 가능성이 높습니다.
공개 웹사이트가 먼저 바꿀 것
- 키 교환, 지금. 기록된 통신을 지키고, 브라우저가 이미 요구하며, 최신 TLS 스택(OpenSSL 3.5 이상, Go 1.24 이상)에서는 설정 변경으로 끝납니다. 위의 모든 날짜가 가리키는 항목이고, 미루면 “지금 수집, 나중에 해독” 비용이 생기는 유일한 항목입니다.
- 모든 곳에 TLS 1.3. 하이브리드 그룹은 TLS 1.2에 없습니다. 아직 1.2에 묶인 엔드포인트가 먼저입니다.
- 암호가 어디에 있는지 목록 만들기. 공개 TLS는 밖에서 보이는 부분일 뿐입니다. VPN, DB, 서비스 간 연결, 코드 서명, 펌웨어가 긴 작업이 있는 곳이고, 국내 암호모듈 의무화가 실제로 닿는 곳도 여기입니다.
- 인증서는 나중에. 공인 인증기관은 아직 양자내성 인증서를 발급하지 않습니다. 체인의 서명 알고리즘을 기록해 두어 나왔을 때 무엇을 바꿀지 알 수 있게만 하고, 이것 때문에 다른 일을 멈추지 마세요.
DechoNet으로 진단
- 양자내성 TLS 점검은 공개 엔드포인트의 지금 상태를 보여 줍니다: 하이브리드 키 교환 여부, 기관 서버와 CDN 엣지 중 누가 제공하는지, TLS 버전, 체인의 서명 알고리즘. 결과 화면에서 감시를 걸면 지원이 켜진 날이 날짜와 함께 기록되어, 전환 진척을 물어볼 때 근거로 쓸 수 있습니다.
- SSL 확인은 같은 엔드포인트의 기본 — 인증서 유효성, 체인, 프로토콜 버전 — 을 봅니다. 위의 어떤 것보다 이게 먼저 깨끗해야 합니다.
해결 체크리스트
- 공개 엔드포인트(웹, API, 메일 제출)를 나열하고 각각 하이브리드 키 교환을 테스트.
- CDN 엣지 결과와 원 서버 결과를 구분 — 보통 공백은 원 서버 구간입니다.
- 모든 엔드포인트를 TLS 1.3과 ML-KEM 지원 스택(OpenSSL 3.5 이상 / Go 1.24 이상)으로.
- 외부 점검으로 안 보이는 것의 암호 인벤토리 시작: VPN, DB, 내부 TLS, 서명.
- 체인의 서명 알고리즘을 기록해, 인증서 교체를 찾아다니는 일이 아니라 목록 조회로 만들기.
- 주기적으로 다시 확인하고 날짜를 남기기 — 평가에서 묻는 건 한 번의 스냅샷이 아니라 시간에 따른 진척입니다.
이럴 땐 다음 단계로
- 2027년 실태평가를 준비하는 국내 공공기관이라면, 외부 TLS 결과는 보조 근거이지 평가 자체가 아닙니다. 모듈 수준의 요구사항은 암호모듈 공급사와 국정원이 공개한 지침을 통해 진행됩니다.
- 체인 안의 공급사 제품(로드밸런서, WAF, 호스팅 패널)이 ML-KEM을 협상하지 못한다면, 그 로드맵을 문서로 받아 두세요. 실제 일정을 정하는 건 대개 그 의존성입니다.
- 단계별 확인 방법과 nginx·Apache·Go 설정은 양자내성 TLS 지원 확인하는 법을 보세요.
내 도메인에서 바로 확인
무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.