QMill 회로 압축, 쇼어 알고리즘 회로 크기 대폭 줄여

QMill 회로 압축 기술 개요

QMill은 알고리즘 레이어를 중심으로 애플리케이션 및 미들웨어 계층까지 아우르는 양자 소프트웨어 플랫폼이다. 이번 실험의 기준 회로는 Classiq 합성 엔진으로 생성된 OpenQASM 2.0 형식의 쇼어 알고리즘 회로로, 정수 15의 소인수분해를 목적으로 한다. 압축은 LUMI 슈퍼컴퓨터 위에서 머신러닝을 활용해 회로를 세그먼트 단위로 분석하는 방식으로 수행됐다. 처리 흐름은 먼저 Qiskit 최적화 레벨 3으로 1차 트랜스파일한 뒤 세그먼트별로 추가 압축을 진행하는 두 단계로 구성된다. 유니터리 행렬은 압축 전후 보존되므로 양자 연산의 수학적 무결성은 유지된다.

백엔드별 압축 성능 비교

IBM Eagles·Herons, IQM, Rigetti, IonQ 등에 동일한 기준 회로를 적용해 비교했다. IQM과 Rigetti는 IBM 계열보다 큐비트 연결성이 높아 압축률이 더 높게 나타났다. 같은 위상(topology)에서도 IQM은 고유 게이트셋의 차이로 Rigetti보다 훨씬 큰 압축 폭을 보였다. QMill은 Eagles를 지원하며, IBM Herons를 대상으로 하는 Q-CTRL의 Fire Opal—드라카리스 어워드 수상작—도 비교 대상에 포함됐다. 두 도구는 지원 플랫폼이 달라 직접 비교는 어렵지만, Fire Opal이 생성한 트랜스파일 회로는 QMill 산출물보다 현저히 큰 것으로 나타났다. IQM은 QMill 없이 트랜스파일만 수행해도 IBM 대비 가벼운 회로를 출력했는데, 이는 연결성과 게이트셋 모두의 영향으로 분석된다.

IonQ는 전-대-전(all-to-all) 연결성 덕분에 2-큐비트 게이트 수에서 가장 유리한 수치를 기록했다. 그러나 초전도체 기반 경쟁사 대비 실행 속도가 느릴 것으로 예상되며, 더 결정적인 문제가 별도로 확인됐다.

IonQ 시뮬레이션 정확도 문제

이상적 시뮬레이터 환경에서 IBM, IQM, Rigetti 기반 회로들은 모두 15의 위수(period)를 4로 올바르게 계산했다. 반면 IonQ 회로만 위수를 2로 출력해 오답을 냈다. 저자는 원인이 IonQ 고유 게이트셋의 호환성 문제인지, QMill의 변환 오류인지, 아니면 실험 설정의 문제인지 현 단계에서 특정하지 못했다. 이는 IonQ 플랫폼에 대한 추가 호환성 검증이 필요함을 시사한다.

기술적 맥락과 한계

이번 결과는 백엔드의 물리적 특성—큐비트 연결성과 네이티브 게이트셋—이 회로 최적화 여지를 크게 좌우한다는 점을 실증했다. 이는 기기 선택이 알고리즘 실행 효율에 미치는 영향을 정량적으로 파악하기 어려웠던 기존 관행에 구체적 데이터를 더한다는 점에서 의미 있다. 다만 이번 실험은 정수 15라는 소규모 소인수분해에 국한된다. 현실적 암호 해독에 필요한 규모의 수에 동일한 접근법을 적용하려면 하드웨어 규모와 회로 충실도 측면에서 상당한 격차가 남아 있다. 또한 LUMI 슈퍼컴퓨터의 크레딧 제한으로 대규모 스트레스 테스트는 이번 실험에 포함되지 않았다.