AWS·구글 클라우드, 양자컴퓨터 대비해 암호 체계 갈아엎는 중

• AWS와 구글 클라우드가 양자컴퓨터 시대를 대비해서 암호 체계 전환에 들어감

  • 핵심은 기존 공개키 암호를 바로 버리는 게 아니라, 기존 암호와 양자내성암호를 같이 쓰는 하이브리드 방식임
  • 클라우드의 키 관리, 인증서, 비밀 정보 저장소, 스토리지, 로드밸런서 같은 보안 기반 기능부터 바뀌고 있음

• 제일 무서운 시나리오는 ‘선수집·후해독’ 공격임

  • 공격자가 지금 금융 거래 기록, 의료 정보, 국가 기밀 같은 암호문을 훔쳐서 저장해둠
  • 나중에 충분히 강한 양자컴퓨터가 나오면 그때 복호화해서 터뜨리는 방식임
  • 당장 못 푼다고 안전한 게 아니라, 10년 이상 보관되는 데이터는 지금 털려도 미래 리스크가 생기는 구조임

• 지금 인터넷과 클라우드에서 많이 쓰는 RSA, 타원 곡선 암호(ECC)는 양자컴퓨터에 약해질 수 있음

  • 이 암호들은 큰 수의 소인수 분해나 이산 로그 계산이 어렵다는 전제에 기대고 있음
  • 일반 컴퓨터 기준으로는 빡센 문제지만, 충분한 성능의 양자컴퓨터는 쇼어 알고리즘으로 계산 시간을 크게 줄일 수 있음
  • 아직 기존 공개키 암호를 현실적으로 깨는 양자컴퓨터는 나오지 않았지만, 문제는 ‘언제 나올지 모른다’는 점임

• 전환이 빨라진 계기는 NIST 표준 확정임

  • 미국 국립표준기술연구소(NIST)가 2024년 8월 양자내성암호 표준을 확정함
  • FIPS 203·204·205에는 키 교환용 ML-KEM, 전자서명용 ML-DSA와 SLH-DSA가 포함됨
  • 표준이 나오면서 기업 대응도 논문·실험 단계에서 실제 서비스 적용 단계로 넘어가는 중임

• AWS는 주요 보안 서비스에 양자내성 기술을 넣고 있음

  • 키 관리 서비스, 인증서 관리, 비밀 정보 저장소, S3 같은 주요 서비스가 대상임
  • 기존 암호와 ML-KEM을 함께 쓰는 양자내성 전송 계층 보안(TLS)을 확대하는 방향임

• 구글 클라우드도 비슷하게 움직이고 있음

  • 로드밸런서에서 기존 키 교환 방식인 X25519와 ML-KEM을 결합한 기술을 지원함
  • 클라우드 키 관리 서비스에도 양자내성 전자서명과 키 캡슐화 기능을 도입하고 있음
  • 구글은 2029년을 암호 체계 전환의 주요 목표 시점으로 잡고 있음

• 한 번에 전부 교체하기 어려워서 하이브리드 방식이 먼저임

  • 오래된 브라우저, 네트워크 장비, 협력사 시스템이 새 알고리즘을 지원하지 않을 수 있음
  • 새 암호 기술에서 예상 못 한 취약점이 발견될 가능성도 있음
  • 그래서 기존 암호와 양자내성암호를 동시에 적용해서 둘 중 하나에 문제가 생겨도 나머지로 통신을 보호하려는 접근임

• 성능과 호환성은 꽤 큰 숙제임

  • 양자내성암호는 기존 방식보다 공개키와 전자서명 크기가 커질 수 있음
  • 그러면 네트워크 트래픽과 처리 시간이 늘어남
  • 금융·통신처럼 초당 수만 건의 인증 요청을 처리하는 서비스는 인증 시간이 몇 밀리초만 늘어도 처리 성능과 운영비에 영향이 감

• 기업이 제일 먼저 해야 할 일은 ‘우리 어디서 무슨 암호 쓰는지’부터 파악하는 것임

  • 공개키 암호는 TLS 인증서, 가상 사설망(VPN), 데이터베이스 연결, API, 하드웨어 보안 모듈(HSM), 백업 프로그램, 사물 인터넷(IoT) 기기까지 넓게 퍼져 있음
  • 코드 서명과 전자 문서 서명도 교체 대상임
  • 클라우드 사업자가 기반 시설을 바꿔도 고객사가 자체 개발한 애플리케이션과 인증 시스템까지 자동으로 바뀌지는 않음

• 그래서 암호 자산 인벤토리가 전환의 출발점임

  • 어떤 암호 알고리즘과 키, 인증서가 어디에 있고 언제 만료되며 누가 관리하는지 정리해야 함
  • 그래야 전환 대상과 순서를 정할 수 있음
  • 특정 알고리즘을 코드에 고정하지 않고 교체 가능하게 만드는 암호 민첩성도 필요함

• 한국 정부도 실증에 들어감
  • 2023년에 범국가 양자내성암호 전환 마스터플랜을 발표함
  • 2025년부터 실제 정보 시스템 대상 시범 사업을 시작함
  • 올해는 통신·금융·교통·국방·우주 5개 분야에 총 45억원을 투입해서 전환 절차, 성능, 기술적 제약을 검증함

---

기술 맥락

• 이번 전환의 핵심은 “새 암호가 나왔으니 바꾸자”가 아니라, 장기 보관 데이터가 미래에 복호화될 수 있다는 리스크를 줄이는 거예요. 특히 의료, 금융, 국방, 반도체 설계처럼 오래 보관되는 데이터는 지금 안전해 보여도 시간이 지나면 공격 가치가 커질 수 있거든요.

• AWS와 구글이 하이브리드 방식을 택한 이유는 호환성 때문이에요. 양자내성암호만 쓰면 오래된 클라이언트나 장비가 못 따라올 수 있고, 기존 암호만 쓰면 미래 리스크를 줄이기 어렵기 때문에 둘을 같이 묶는 절충안을 고른 거예요.

• 실무에서 어려운 지점은 알고리즘 자체보다 적용 범위예요. 인증서, 키 관리, API, 데이터베이스 연결, 코드 서명, 컨테이너 이미지, 협력사 SDK까지 암호가 숨어 있는 곳이 많아서 먼저 인벤토리를 만들어야 전환 순서를 잡을 수 있어요.

• 금융이나 통신 같은 고트래픽 서비스는 성능 검증도 중요해요. 공개키와 서명 크기가 커지면 패킷과 처리 시간이 늘 수 있고, 초당 수만 건의 인증 요청을 처리하는 환경에서는 몇 밀리초 차이도 운영비와 장애 리스크로 이어질 수 있거든요.