Quantum-HPC Software Stacks and the openQSE Reference Architecture: A Survey

이 논문은 현재 고립된 양자-HPC 소프트웨어 스택의 문제를 분석하고, NISQ 및 차세대 FTQC 시스템을 아우르는 상호 운용 가능한 통합 생태계를 구축하기 위해 'openQSE' 참조 아키텍처를 제안합니다.

핵심

이 논문은 **"양자 컴퓨터와 슈퍼컴퓨터가 함께 일할 때, 서로 다른 언어를 쓰는 두 팀이 어떻게 원활하게 협업할 수 있을까?"**라는 질문에 대한 답을 찾는 연구입니다.

지금까지 양자 컴퓨터와 슈퍼컴퓨터 (HPC) 는 마치 서로 다른 나라에서 온 두 명의 건축가처럼 행동했습니다. 한 명은 "내 방식대로 벽돌을 쌓아"라고 하고, 다른 한 명은 "내 방식대로 시멘트를 발라"라고 해서, 두 사람이 함께 건물을 짓는 과정이 매우 복잡하고 비효율적이었습니다.

이 논문은 9 개의 주요 양자 - 슈퍼컴퓨터 시스템 (AWS, IBM, IonQ 등) 을 조사하여 공통점을 찾고, 앞으로 모두에게 통용될 **새로운 협업 규칙 (openQSE)**을 제안합니다.

아래는 이 논문의 핵심 내용을 일상적인 비유로 설명한 것입니다.

---

1. 문제 상황: "혼란스러운 협업 현장"

현재 양자 컴퓨터는 슈퍼컴퓨터와 함께 작동해야만 유용합니다. 하지만 현재 상황은 다음과 같습니다.

• 각자 다른 언어 사용: 회사 A 는 "이런 방식으로 일을 시키세요"라고 하고, 회사 B 는 "저렇게 하세요"라고 합니다.
• 재작업의 반복: 연구자들은 새로운 양자 컴퓨터를 쓸 때마다 매번 새로운 인터페이스를 배우고, 소프트웨어를 다시 짜야 합니다.
• 비효율: 중요한 과학 연구 (예: 신약 개발, 기후 모델링) 가 양자 컴퓨터가 준비되는 동안 기다려야 하거나, 데이터가 오가는 과정에서 지체가 발생합니다.

2. 분석: 9 개의 시스템을 살펴보다

저자들은 9 개의 주요 시스템 (AWS, IBM, IonQ, Pasqal 등) 을 분석했습니다. 마치 다양한 자동차 브랜드 (현대, BMW, 테슬라 등) 의 엔진과 조향 시스템을 비교하는 것과 같습니다.

• 공통점 발견: 모두 '작업 제출', '자원 관리', '결과 확인'이라는 기본 단계가 있다는 것을 발견했습니다.
• 차이점: 각자 그 단계를 구현하는 방식이 다릅니다. 어떤 곳은 클라우드에서, 어떤 곳은 직접 설치된 기계에서 작동합니다.

3. 해결책: "openQSE"라는 새로운 교통 법규 제안

이 논문은 이 모든 시스템을 하나로 묶을 수 있는 **새로운 표준 설계도 (openQSE)**를 제안합니다. 이를 이해하기 쉽게 비유해 보겠습니다.

🏗️ 비유: "모든 차가 다닐 수 있는 '유니버설 도로'"

지금까지 각 자동차 회사 (양자 컴퓨터 제조사) 는 자신만의 도로 (소프트웨어 스택) 를 만들었습니다. 하지만 openQSE는 다음과 같은 역할을 합니다.

1. 표준 도로 표지판 (인터페이스):
   • 모든 운전자가 (연구자들이) 어떤 차를 타든, "여기로 가면 목적지에 간다"는 표지판만 보면 됩니다.
   • 더 이상 "BMW 는 왼쪽으로, 현대는 오른쪽으로"라고 외울 필요가 없습니다.
2. 유연한 차선 (레이어 구조):
   • 이 설계도는 도로의 위쪽 (어떤 앱을 쓸지) 과 아래쪽 (어떤 양자 칩을 쓸지) 을 분리합니다.
   • 비유: 우리가 운전할 때, 차의 엔진이 어떻게 작동하는지 (하드웨어) 알 필요 없이, 핸들만 돌리면 됩니다. 엔진이 변해도 (양자 컴퓨터가 업그레이드되어도) 운전자는 그대로 운전할 수 있습니다.
3. 미래 준비 (NISQ vs FTQC):
   • 현재 (NISQ): 소음이 많은 양자 컴퓨터 (비 오는 날의 운전) 에 맞춰 설계되었습니다.
   • 미래 (FTQC): 완벽하게 오류가 없는 양자 컴퓨터 (맑은 날의 고속도로) 가 왔을 때도, 도로 구조를 바꾸지 않고 그대로 사용할 수 있도록 설계되었습니다.

4. 구체적인 역할 분담 (아키텍처)

이 설계도는 다음과 같은 역할을 나눕니다.

• HPC 제어판 (지휘자): 연구자가 "이 일을 해줘"라고 요청하는 곳입니다.
• 양자 접근 노드 (통역사): 지휘자의 말을 양자 컴퓨터가 알아들을 수 있는 언어로 바꿔줍니다.
• 양자 리소스 (작업자): 실제 계산을 수행하는 양자 컴퓨터입니다.
• QHPC 인터커넥트 API (전화선): 지휘자와 작업자, 통역사 사이를 실시간으로 연결해 주는 통신망입니다. 양자 컴퓨터가 "지금 계산 중이니 잠시 기다려줘"라고 신호를 보내거나, "이 데이터를 더 보내줘"라고 요청할 수 있게 합니다.

5. 왜 이것이 중요한가요?

이 openQSE가 완성되면:

• 연구자들은 양자 컴퓨터의 종류나 위치에 상관없이 같은 코드로 연구를 할 수 있습니다.
• 기업들은 서로 다른 양자 컴퓨터를 쉽게 연결하여 더 강력한 시스템을 만들 수 있습니다.
• 미래의 양자 컴퓨터가 나와도, 기존 소프트웨어를 버리지 않고 계속 쓸 수 있습니다.

요약

이 논문은 **"양자 컴퓨터와 슈퍼컴퓨터가 서로 다른 언어를 쓰느라 혼란스러운 현재를 정리하고, 모두를 위한 공통의 언어와 규칙 (openQSE) 을 만들어서, 과학자들이 기술적 장벽 없이 혁신적인 연구를 할 수 있게 하자는 제안"**입니다.

마치 USB-C 케이블이 모든 기기를 하나로 연결하듯, 이 표준은 양자 컴퓨팅의 미래를 하나로 묶는 핵심 열쇠가 될 것입니다.

기술 요약

논문 요약: 양자-HPC 소프트웨어 스택 및 openQSE 참조 아키텍처

이 논문은 고성능 컴퓨팅 (HPC) 환경에 양자 자원을 통합하는 과정에서 발생하는 소프트웨어 스택의 단편화 문제를 분석하고, 이를 해결하기 위한 공동 커뮤니티 아키텍처인 openQSE(open Quantum-HPC Software Ecosystem) 참조 아키텍처를 제안합니다.

**1. 문제 제기 **(Problem Statement)

• 단편화된 통합 환경: 양자 컴퓨터는 고전 컴퓨팅 (컴파일, 오케스트레이션, 제어, 데이터 이동 등) 과 긴밀하게 결합되어야 하지만, 현재 양자-HPC(QHPC) 소프트웨어 스택은 각 공급자 (Vendor) 마다 독점적이고 단편화되어 있습니다.
• 호환성 및 이식성 부족: 런타임, 리소스 관리, 오케스트레이션, 실행 계층 간에 공통 인터페이스가 부재하여, 애플리케이션과 운영 팀의 이식성이 약화되고 유지보수 비용이 증가합니다.
• 스케일링 비대칭성: HPC 는 모듈식 리소스 (노드, 코어 등) 를 점진적으로 확장할 수 있지만, 양자 프로세서 (QPU) 는 큐비트 수가 제한적이고 밀접하게 결합되어 있어 분할 할당이나 사전 예약이 어렵습니다. 또한 양자 정보는 복제 불가능하여 체크포인트 (checkpoint) 가 불가능합니다. 이러한 물리적, 아키텍처적 차이로 인해 기존 HPC 스케줄링 및 워크플로우 모델이 양자 자원에 직접 적용되기 어렵습니다.

**2. 방법론 **(Methodology)

저자들은 산업계와 연구계가 개발한 9 개의 대표적인 생산용 QHPC 스택을 분석하여 현재 산업 표준 (State-of-the-practice) 을 파악했습니다.

• 분석 대상 스택: AWS, IBM, IonQ, JHPC-Quantum, MQSS, Pasqal, Quantinuum, Quantum Brilliance, Xanadu.
• **4 가지 분류 축 **(Classification Axes) 스택들을 비교하기 위해 다음 4 가지 축을 정의했습니다.
  1. **배포 환경 **(Deployment) 클라우드, 온프레미스, 페더레이션 (연계 운영).
  2. **양자 하드웨어 모드 **(Modality) 초전도, 이온 트랩, 중성 원자, 광자 등 다양한 물리적 구현 방식.
  3. 애플리케이션 상호작용 패턴: 워크플로우 중심 (Workflow-centric, 단계별 실행) 과 가속기 중심 (Accelerator-centric, HPC 프로그램 내 커널 호출).
  4. 양자 컴퓨팅 시대: 현재 NISQ(잡음 있는 중규모 양자) 에서 미래의 FTQC(오류 정정 양자 컴퓨팅) 까지.
• 인터페이스 매핑: 각 스택의 아키텍처, 주요 인터페이스 (SDK, 런타임, 스케줄러), 그리고 공통 설계 패턴을 매핑하여 차이점과 수렴점을 도출했습니다.

**3. 주요 기여 **(Key Contributions)

1. 양자-HPC 스택 분석 및 인터페이스 수렴 매트릭스: 9 개 스택을 분석하여 공통 설계 패턴과 차이점을 식별하고, 현재 기술이 수렴하는 영역 (예: OpenQASM 3, QDMI, QRMI) 과 아직 분열된 영역을 시각화한 매트릭스를 제시했습니다.
2. 요구사항 프레임워크: 배포 환경, 하드웨어 모드, 애플리케이션 패턴, 양자 컴퓨팅 시대를 아우르는 구조화된 설계 공간을 제안하여 현재 및 미래 QHPC 시스템의 요구사항을 체계화했습니다.
3. openQSE 참조 아키텍처 제안: 벤더 중립적인 레이어형 참조 아키텍처인 openQSE를 제안했습니다. 이는 특정 레이어의 소유권을 특정 벤더나 HPC 센터에 할당하지 않으면서도, 구현의 유연성을 유지하고 이식 가능한 인터페이스를 안정화합니다.

**4. 주요 결과 및 발견 (Results & Findings)

• 공통 설계 패턴: 모든 스택은 애플리케이션, 런타임 서비스, 컴파일, 하드웨어 제어 간의 계층적 분리를 따르며, 명시적인 런타임 경계 (제출, 상태 추적, 결과 반환) 를 사용합니다.
• **관측 가능성 **(Observability) 모든 스택에서 실행 상태, 하드웨어 측정 데이터, 메타데이터 등을 수집하는 관측 가능성 기능이 아키텍처의 필수 요소로 자리 잡았습니다.
• 표준화 노력의 부상: QDMI(Quantum Device Management Interface, 장치 관리) 와 QRMI(Quantum Resource Management Interface, 리소스 관리) 와 같은 인터페이스가 여러 스택에서 채택되거나 호환되려는 추세임을 확인했습니다.
• 시간 도메인 분리: NISQ 와 FTQC 를 모두 지원하기 위해 물리적 타이밍 도메인 (PTD), 결정적 타이밍 도메인 (DTD), 실시간 도메인 (RTD), 애플리케이션 시간 도메인 (ATD) 을 명확히 분리하는 아키텍처가 필요합니다.

5. openQSE 아키텍처의 핵심 구성 요소

제안된 openQSE 는 5 가지 논리적 부분으로 구성됩니다:

1. **HPC 제어 노드 **(Control Plane) 작업 제출 및 리소스 추상화를 담당하며, 특정 리소스 관리 시스템 (RMS) 에 종속되지 않는 표준화된 리소스 설명을 제공합니다.
2. **양자 액세스 노드 **(Quantum Access Node) 사용자와 양자 자원 간의 진입점으로, 하이브리드 스크립트 실행 및 서비스 준비 로직을 처리합니다.
3. **양자 리소스 **(Quantum Resource) QPU 실행 경계로, 펄스 전달부터 도구 파이프라인, 스케줄링, 다중 테넌시 계층을 포함합니다.
4. 공유 인프라: 네트워크 및 데이터 지속성 서비스.
5. 핵심 인터페이스 및 계층:
   • **QRI **(Quantum Runtime Interface) 애플리케이션과 벤더 특화 실행 세부사항을 분리하는 런타임 경계 (GPU 의 HIP 와 유사).
   • QHPC-Interconnect API: 컴퓨팅 요소 간 양방향 통신 (제출, 이벤트, 피드백, 적응 요청) 을 지원하는 인터페이스.
   • Tool/Compiler Pipeline: 알고리즘 변환 및 컴파일러 패스를 관리하는 파이프라인 인프라.
   • **제어 전자 장치 **(Control Electronics) PTD 와 DTD 사이의 경계로, 오류 정정 (QEC) 을 위한 실시간 피드백 및 파라미터 스트리밍을 처리합니다.

**6. 의의 및 중요성 **(Significance)

• 미래 지향성: 현재의 NISQ 워크로드뿐만 아니라, 미래의 FTQC 시스템 (오류 정정 루프, 엄격한 타이밍 제약) 도 상부 애플리케이션 인터페이스를 변경하지 않고 지원할 수 있도록 설계되었습니다.
• 상호 운용성: 벤더와 배포 모델 (클라우드/온프레미스) 에 구애받지 않는 공통 인터페이스를 정의함으로써, 다양한 양자 하드웨어와 HPC 환경 간의 원활한 통합을 가능하게 합니다.
• 커뮤니티 표준의 기초: 이 연구는 단순한 기술 분석을 넘어, 산업계와 학계가 협력하여 공통된 아키텍처와 표준을 수립하기 위한 청사진을 제공하며, 양자 컴퓨팅이 HPC 생태계에 성공적으로 통합되는 데 필수적인 기반을 마련합니다.

이 논문은 양자 컴퓨팅이 HPC 환경에 통합되는 과정에서 겪는 기술적 장벽을 체계적으로 분석하고, 이를 해결하기 위한 실용적이고 확장 가능한 아키텍처를 제시했다는 점에서 중요한 의미를 가집니다.