양자 SDK는 왜 무료인가? 무료 코드 뒤의 플랫폼·표준·계산자원 경쟁

무료 코드 뒤에서 벌어지는 플랫폼·표준·계산자원 경쟁

대학원 시절 양자컴퓨팅을 코드로 처음 익힐 때 자주 손이 간 도구가 IBM의 Qiskit이었습니다. 양자회로를 짜고 알고리즘을 구현한 뒤 시뮬레이터와 실제 장비에서 결과를 확인했습니다. 그때만 해도 Qiskit은 무엇보다 훌륭한 학습·연구 도구였습니다. 시간이 지나 양자컴퓨팅 산업을 다시 들여다보자 예전에는 보이지 않던 질문이 하나 눈에 들어왔습니다. 연구개발비가 막대한 분야에서 기업들은 왜 핵심 개발도구를 무료로 공개할까요.

답을 락인(lock-in) 하나로 압축하면 너무 단순합니다. 반대로 연구와 교육을 위한 오픈소스라고만 설명해도 충분하지 않습니다. 무료 SDK는 연구성과 확산과 교육, 외부 기여, 기술 검증에 실제로 쓰입니다. 동시에 개발자 채택을 늘리고 특정 프로그래밍 경로를 익숙하게 만들며, 장래의 계산자원 수요로 이어질 수도 있습니다. 다만 두 층위는 구별해야 합니다. 기업이 그런 효과를 의도했다고 단정하는 것과, 시장에서 그런 효과가 생길 수 있다고 분석하는 것은 다른 이야기입니다.

무료인 것은 코드, 희소한 것은 계산자원입니다

Qiskit은 Apache License 2.0으로 공개된 오픈소스 SDK입니다.^[1] 하지만 SDK가 무료라는 말과 양자컴퓨터를 무제한 무료로 쓸 수 있다는 말은 같지 않습니다. 2026년 8월 16일 현재 IBM Quantum의 Open Plan은 28일 이동창 기준 최대 10분의 QPU 사용시간을 무료로 제공합니다.^[2] AWS Braket의 온디맨드 QPU는 일반적으로 태스크 수수료와 샷당 사용료가 붙고, 전용 예약은 시간 단위의 reservation 요금으로 제공됩니다.^[3]

가격 구조만 놓고 보면 무료 SDK의 의미가 조금 더 선명해집니다. 소프트웨어와 문서는 사용자가 한 명 늘어난다고 원가가 같은 비율로 늘어나는 상품이 아닙니다. QPU는 다릅니다. 장비 구축과 운영에 비용이 들고 가용 시간에도 한계가 있는 물리적 자원입니다. 개발도구의 문턱을 낮추고 희소한 실행자원이나 고급 서비스에서 과금하는 구조가 성립하는 이유입니다. 그렇다고 모든 공급자의 하드웨어 접근방식이 같은 것도 아닙니다. Cirq는 오픈소스 프레임워크이지만 Google의 양자 프로세서 접근에는 별도의 승인 절차가 필요합니다.^[4] 무료 SDK와 실제 QPU 접근은 애초부터 다른 층위의 문제입니다.

SDK라는 이름 아래에는 여러 층이 겹쳐 있습니다

양자 SDK를 이야기할 때 가장 쉽게 생기는 오해도 여기에서 시작됩니다. SDK, 중간표현(IR), 컴파일러·트랜스파일러, 런타임, QaaS, QPU를 한 덩어리로 부르면 실제 기술구조가 흐려집니다. 개발 프레임워크는 회로와 알고리즘을 표현합니다. IR은 컴파일 과정에서 프로그램을 전달하기 위한 표현 형식입니다. 컴파일러와 트랜스파일러는 게이트 분해, 배치, 라우팅, 최적화를 맡습니다. 그 아래 런타임과 클라우드 서비스가 작업 제출·큐잉·실행·결과 관리를 이어 가고, 마지막 물리 연산은 QPU가 수행합니다.

이 때문에 SDK가 QPU를 직접 ‘제어한다’는 표현도 정확하지 않습니다. 클라우드 환경에서 사용자가 주로 다루는 것은 회로와 실행 옵션, 작업 제출 인터페이스입니다. 장치 캘리브레이션, 물리 제어, 자원 배분과 상당 부분의 실행정책은 제공자 쪽에 남습니다. SDK가 중요한 이유는 QPU를 소유하거나 물리적으로 지배해서가 아닙니다. 개발자의 알고리즘이 실제 계산자원에 도달하는 경로를 매개하기 때문입니다.

락인은 의도보다 축적에서 생깁니다

Qiskit이 오픈소스라는 사실과 IBM이 락인을 목적으로 Qiskit을 공개했다는 주장은 전혀 다른 명제입니다. 후자를 사실로 말하려면 별도의 근거가 있어야 합니다. 연구 확산, 커뮤니티 확대, 외부 기여와 검증만으로도 오픈소스를 택할 이유는 충분합니다.

그렇다고 전환비용까지 없어지는 것은 아닙니다. 개발자는 특정 프레임워크의 객체 모델과 라이브러리, API, 컴파일 방식에 익숙해집니다. 조직에서는 코드베이스와 테스트, 자동화, 인증, 실험기록, 보안 검토, 운영 절차가 그 위에 차곡차곡 쌓입니다. 특정 QPU의 게이트셋과 연결성에 맞춘 최적화, 런타임 정책, 대기열과 예약, 가격·지원·SLA 같은 계약조건도 선택을 붙잡는 요소가 됩니다. 결국 전환비용은 폐쇄적인 라이선스 하나에서 생기기보다 기술적·운영적·계약적 자산이 누적되면서 커집니다. 물론 이런 집중이 언제나 나쁜 것은 아닙니다. 한 플랫폼에 익숙해진 대가로 더 높은 성능과 생산성, 안정적인 지원을 얻을 수도 있습니다.

중간표현은 미들웨어가 아닙니다

이식성을 논할 때는 용어부터 분리할 필요가 있습니다. OpenQASM과 QIR은 프로그램을 표현하는 중간표현의 문제에 가깝습니다. pytket은 여러 장치와 시뮬레이터를 공통 Backend 인터페이스로 다루는 컴파일러·툴킷 계층에 가깝습니다. OpenQASM 3 명세는 상위 컴파일러와 양자 하드웨어 사이의 IR 역할을 주요 목표로 밝히고 있습니다.^[5] QIR은 LLVM을 바탕으로 한 양자 중간표현이며, 범용 QIR을 특정 타깃의 요구조건에 맞게 다시 변환하는 단계가 필요합니다.^[6] pytket은 최적화 컴파일러와 Backend 추상화를 제공해 여러 공급자의 장치·시뮬레이터와 연결합니다.^[7]

IR과 미들웨어는 같은 말이 아닙니다. IR이 프로그램을 담는 공통 표현이라면, 컴파일러나 미들웨어는 그 표현을 읽고 바꾸어 실제 실행환경과 이어 주는 소프트웨어입니다. 이 차이를 놓치면 공개 IR이 존재한다는 이유만으로 플랫폼 이동도 자유롭다고 오해하기 쉽습니다.

코드가 옮겨 간다고 성능까지 따라가는 것도 아닙니다. 소스코드를 다른 프레임워크로 옮기는 문제, 프로그램 표현을 다른 IR로 손실 없이 바꾸는 문제, 다른 QPU에서 실제로 실행하는 문제는 서로 다릅니다. 정확도·회로 깊이·비용·지연시간까지 유지되는지는 다시 별도의 성능 이식성 문제입니다. 인증과 모니터링, 실험 메타데이터, 보안·규제 절차를 옮기는 운영 이식성도 남습니다. 공개 IR은 표현 이식성을 높일 수 있지만 나머지 층위까지 자동으로 해결하지는 않습니다.

오픈소스와 개방형 플랫폼은 같은 말이 아닙니다

Qiskit이 채택한 Apache License 2.0은 수정·재배포·상업적 이용을 폭넓게 허용하고, 기여자가 제공하는 일정 범위의 특허 라이선스도 포함합니다. 해당 Work 또는 Contribution이 특허를 침해한다고 주장하는 일정한 특허소송을 제기하면 그 특허 라이선스가 종료되는 조항도 있습니다.^[8]

다만 오픈소스 라이선스가 여는 것은 기본적으로 코드에 관한 권리입니다. 실제 QPU 접근, 캘리브레이션 데이터, 저수준 제어, 실행 우선순위, 관리형 런타임, 기업지원과 SLA까지 따라서 열리는 것은 아닙니다. 오픈소스와 상용화가 서로 반대되는 선택이 아닌 이유가 여기에 있습니다. 플랫폼의 개방성을 판단하려면 소스코드 공개 여부 하나보다 어느 계층이 열려 있고, 어느 계층이 공급자의 통제 아래 남아 있는지를 살펴야 합니다.

표준화는 번호보다 상태가 중요합니다

표준화 이야기는 특히 시점에 민감합니다. PAR(Project Authorization Request)은 표준 개발 프로젝트를 승인하는 절차이지, 그 자체로 발행된 IEEE 표준은 아닙니다. 2026년 8월 16일 기준 IEEE의 개별 프로젝트 페이지는 P7130(Quantum Technologies Definitions)과 P3329(Quantum Computing Energy Efficiency)를 Active PAR로 표시합니다.^[9][10] P3980은 2026년 3월 26일 승인된 Active PAR로, 하이브리드 양자-고전 컴퓨팅 기술의 일반적 적용 지침을 다룹니다.^[11]

한편 IEEE Standards Board의 공식 조치 기록을 보면 P3155의 PAR은 2023년 6월, P3120은 2025년 6월, P3185는 2025년 9월 철회됐습니다.^[12] 그런데 일부 개별 프로젝트 페이지에는 철회 뒤에도 Active PAR 표기가 남아 있습니다. 프로젝트 페이지 하나만 보고 현재 상태를 단정하기 어려운 이유입니다. 개별 페이지뿐 아니라 Standards Board의 최신 조치 기록까지 함께 확인해야 합니다.

이런 변화 자체가 양자컴퓨팅의 표준 구조가 아직 굳지 않았음을 보여줍니다. 정책과 기업전략에서 확인해야 할 것도 오픈소스 여부 하나가 아닙니다. 코드와 데이터가 얼마나 이동할 수 있는지, 실행 결과를 다른 QPU에서 재현할 수 있는지, 중간표현과 API가 어디까지 상호운용되는지, 계약이 끝난 뒤에도 실험 자산과 운영절차를 회수할 수 있는지가 더 실질적인 질문입니다.

무료 SDK가 넓히는 것은 미래의 경로입니다

처음 Qiskit을 사용할 때는 무료라는 사실 자체가 고마웠습니다. 지금 같은 도구를 다시 보면 가격표보다 그 위에 무엇이 쌓이는지가 더 눈에 들어옵니다. 개발자는 도구를 배우고 코드를 만들며 테스트와 실험절차를 축적합니다. 기업은 그 과정에서 특정 API와 실행환경을 업무의 일부로 받아들입니다. 공급자 입장에서는 더 많은 개발자가 자사 또는 제휴 생태계로 이어지는 프로그래밍 경로에 익숙해집니다.

그 사실만으로 의도적인 락인을 말할 수는 없습니다. 다만 무료 SDK가 연구와 교육의 문턱을 낮추는 동시에 미래의 계산수요와 플랫폼 채택을 형성하는 효과를 낳는다는 점은 충분히 분석할 수 있습니다. 양자컴퓨팅의 경쟁을 큐비트 수와 오류율만으로 보면 이 층위를 놓칩니다. 어느 하드웨어가 최종 승자가 될지 알 수 없는 시기일수록 개발자가 어떤 언어와 SDK, IR, 컴파일러, 런타임을 중심으로 코드와 습관을 쌓는지가 중요해질 수 있습니다.

미래의 양자 플랫폼 경쟁은 하드웨어 실험실 안에서만 벌어지지 않습니다. 오늘 개발자가 설치한 SDK와 그 위에 쌓인 코드, 테스트, 업무절차 역시 이미 경쟁의 일부입니다.

---

주요 확인자료

기준일: 2026년 8월 16일. 서비스 조건과 표준 프로젝트 상태는 이후 변경될 수 있습니다.

1. Qiskit/qiskit — Qiskit open-source SDK, Apache License 2.0
2. IBM Quantum Documentation — Plans overview
3. Amazon Web Services — Amazon Braket Pricing
4. Google Quantum AI — Getting set up to use Google's quantum processors
5. OpenQASM Live Specification — Introduction
6. QIR Alliance — What is QIR?; QAT Architecture Overview
7. Quantinuum pytket User Guide — Running on Backends
8. Apache Software Foundation — Apache License, Version 2.0
9. IEEE SA — P7130, Standard for Quantum Technologies Definitions
10. IEEE SA — P3329, Standard for Quantum Computing Energy Efficiency
11. IEEE SA — P3980, Guide for General Application of Hybrid Quantum-Classical Computing Technology
12. IEEE SA Standards Board — Withdrawn PAR records: P3155 (29 June 2023), P3120 (19–20 June 2025), P3185 (10 September 2025)