IonQ의 800논리 큐비트 목표를 두 편의 논문과 특허로 이해하기

Ryan

Oct 2

9 min read

물리 큐비트 10000개로 논리 큐비트 800개

IonQ의 800 논리 큐비트 목표를 두 편의 논문과 특허로 이해하기

라이언랩 | 미래기술 투자연구 | 2026년 10월 2일

삽화 1 이온 큐비트와 보조 큐비트가 양자정보를 보호하는 모습을 표현한 AI 생성 개념 이미지입니다. 실제 장비나 정확한 회로를 묘사한 그림은 아닙니다.

양자컴퓨터 기업의 발표를 보다 보면 자주 등장하는 숫자가 있습니다. 바로 큐비트 수입니다.

그런데 물리 큐비트가 많아졌다고 해서, 그만큼의 큐비트를 모두 안정적인 계산에 사용할 수 있는 것은 아닙니다. 양자컴퓨터는 계산하는 동안 발생하는 오류를 찾아내고 관리해야 하기 때문입니다.

IonQ는 공식 로드맵에서 2027년 물리 큐비트 10,000개와 논리 큐비트 800개를 목표로 제시하고 있습니다. 단순히 나누면 논리 큐비트 하나당 물리 큐비트 12.5개를 사용하는 셈입니다. [1]

오류정정에 많은 큐비트가 필요하다고 들어온 분들에게는 이 비율이 상당히 높아 보일 수 있습니다.

최근 공개된 《Design Principles for Ultra-High-Rate Quantum Codes》는 이 목표를 이해하는 데 흥미로운 단서를 제공합니다. 이 논문에 나온 코드를 기준으로 계산하면, 데이터 큐비트 10,000개에 논리 큐비트 2,150개를 담는 구성이 가능합니다.

그러나 여기에는 반드시 이해해야 할 차이가 있습니다.

데이터 큐비트 10,000개에 논리정보를 담는 것과, 총 10,000큐비트 장비에서 그 논리정보를 이용해 실제 계산을 수행하는 것은 다릅니다.

이 차이를 이해한 뒤 IonQ의 오류정정 연구와 관련 특허 출원을 함께 살펴보면, 800개라는 목표를 좀 더 구체적으로 바라볼 수 있습니다.

물리 큐비트와 논리 큐비트는 무엇이 다를까

먼저 용어부터 간단히 정리해 보겠습니다.

물리 큐비트는 실제 장비를 구성하는 개별 큐비트입니다. IonQ는 이온에 양자정보를 저장합니다.

하지만 큐비트의 상태는 완벽하게 유지되지 않습니다. 주변 환경의 영향을 받거나, 계산을 위한 조작이 조금 어긋나거나, 측정 과정에서 문제가 생길 수 있습니다. 계산이 길어질수록 이런 오류를 관리하는 일이 중요해집니다.

그래서 하나의 양자정보를 여러 물리 큐비트에 분산시켜 보호합니다. 이렇게 보호되는 정보의 단위를 논리 큐비트라고 합니다.

여기서 ‘분산’은 같은 정보를 여러 번 복사해 둔다는 뜻은 아닙니다. 양자정보는 일반적인 컴퓨터 파일처럼 마음대로 복사할 수 없습니다. 대신 여러 큐비트 사이에 특별한 관계를 만들어, 일부에 오류가 생겨도 원래 정보를 복구할 수 있도록 합니다.

이 관계를 정하는 규칙이 오류정정 코드, Quantum Error-Correcting Code입니다.

따라서 물리 큐비트 몇 개가 논리 큐비트 하나로 바뀌는지는 고정된 숫자가 아닙니다. 어떤 코드를 쓰는지, 장비의 오류가 얼마나 적은지, 얼마나 긴 계산을 얼마나 정확하게 수행하려는지에 따라 달라집니다.

정보를 담는 큐비트와 오류를 검사하는 큐비트

오류정정을 이해할 때는 물리 큐비트의 역할도 구분해야 합니다.

구분	주요 역할
데이터 큐비트	논리정보를 여러 큐비트에 나누어 저장
보조 큐비트	데이터 큐비트와 상호작용해 오류의 단서를 측정

오류를 찾으려면 저장된 정보를 들여다보면 될 것 같지만, 양자컴퓨터에서는 그렇게 간단하지 않습니다. 데이터 큐비트를 직접 측정하면 계산에 필요한 양자상태가 달라질 수 있기 때문입니다.

그래서 보조 큐비트를 이용해 데이터 큐비트 사이의 관계를 검사합니다. 정보의 내용 자체를 읽기보다는, 정해진 관계가 어긋났는지를 확인하는 것입니다.

이때 얻는 오류의 단서를 Syndrome, 그 단서를 수집하는 과정을 Syndrome extraction이라고 합니다.

이후 일반 컴퓨터에서 실행되는 Decoder가 여러 단서를 분석해 어떤 오류가 발생했을지 추정합니다.

즉, 실용적인 오류정정에는 정보를 담는 코드뿐 아니라, 오류를 검사하는 회로와 그 결과를 해석하는 소프트웨어도 필요합니다.

인포그래픽 1 오류정정의 기본 흐름. 데이터의 내용 대신 오류의 단서를 모아 분석합니다. 구체적인 회로도는 아닙니다.

IonQ의 첫 번째 논문은 이온트랩에 맞는 오류정정을 찾는다

먼저 살펴볼 자료는 IonQ의 Min Ye와 Nicolas Delfosse가 작성한 《Quantum error correction for long chains of trapped ions》입니다. [3]

이 논문은 긴 이온 사슬의 특성에 맞는 오류정정 코드와 검사 방법을 연구합니다.

같은 이온 사슬 안에서는 멀리 떨어진 두 큐비트 사이에도 직접 게이트 연산을 수행할 수 있습니다. 이런 높은 연결성은 여러 위치에 있는 데이터 큐비트의 관계를 검사하는 데 유리합니다.

다만 연결성이 좋다고 해서 모든 일을 동시에 할 수 있는 것은 아닙니다. 이 논문이 사용하는 모델에서는 게이트 연산은 순차적으로 실행되고, 측정은 상대적으로 오래 걸립니다. 기다리는 동안 발생하는 오류도 고려합니다.

연구진은 이런 장점과 제약을 함께 반영해 오류정정 방법을 설계했습니다.

그중 일반 독자가 주목할 부분은 보조 큐비트를 얼마나 효율적으로 사용할 수 있느냐입니다.

오류 검사마다 별도의 보조 큐비트를 배정하면 검사를 빠르게 진행하기 좋지만, 큐비트가 많이 필요합니다. 반대로 적은 보조 큐비트를 여러 검사에 재사용하면 필요한 수를 줄일 수 있습니다.

검사원을 떠올리면 이해하기 쉽습니다.

여러 구역에 검사원을 한 명씩 배치하면 많은 일을 동시에 처리할 수 있습니다. 소수의 검사원이 여러 구역을 돌아다니면 인원은 줄지만 전체 점검시간은 길어집니다.

양자컴퓨터에서는 이 기다리는 시간도 비용입니다. 기다리는 데이터 큐비트에도 오류가 발생할 수 있기 때문입니다.

IonQ 연구진은 보조 큐비트 수를 조절하고, 여러 보조 큐비트의 측정을 동시에 수행하면서 큐비트 사용량과 오류율 사이의 적절한 균형을 찾았습니다.

BB5는 검사 부담을 줄이면서 보호 능력을 높이려는 코드다

이 논문은 검사 회로와 함께 BB5라는 오류정정 코드 계열도 제안합니다.

BB5는 qLDPC 코드의 한 종류입니다. qLDPC는 각 검사가 전체 큐비트 중 비교적 적은 수에만 관여하도록 만든 양자 오류정정 코드 계열이라고 이해하면 됩니다.

BB5에서 숫자 5는 검사 하나가 데이터 큐비트 5개에 걸쳐 작용한다는 의미입니다. 논문이 비교한 기존 BB6 코드에서는 6개에 걸쳐 작용합니다.

연구진은 특정 규모에서 검사에 관여하는 큐비트 수를 줄이면서도, 오류 보호 능력을 높인 BB5 사례를 찾았습니다.

대표적인 코드는 [[48,4,7]]입니다.

숫자	의미
48	데이터 큐비트 수
4	저장하는 논리 큐비트 수
7	오류 보호 능력과 관련된 Code distance

논문의 최적화 조건에서는 이 코드에 보조 큐비트 6개를 사용합니다. 따라서 데이터 48개와 보조 6개를 합쳐 총 54개로 논리 큐비트 4개를 보호하는 구성입니다.

논문에서 비교한 Distance-7 Surface code는 데이터 49개와 보조 8개, 총 57개로 논리 큐비트 1개를 보호합니다.

특정 시뮬레이션 조건에서는 BB5가 이 Surface code와 비슷한 논리 오류율을 보이면서, 논리 큐비트 하나당 필요한 물리 큐비트를 약 4분의 1로 줄였습니다. [3]

이 결과는 하드웨어에 맞는 코드를 선택하고 검사 방법을 다듬으면, 같은 큐비트 수를 더 효율적으로 사용할 수 있다는 의미입니다.

다만 실제 IonQ 장비에서 모든 조건을 그대로 입증했다는 뜻은 아닙니다. 이 논문은 제안한 모델을 바탕으로 코드와 회로의 성능을 시뮬레이션한 연구입니다.

새 논문은 더 많은 논리정보를 담는 설계법을 제시한다

이제 두 번째 논문인 《Design Principles for Ultra-High-Rate Quantum Codes》를 살펴보겠습니다.

2026년 9월 공개된 이 논문은 IonQ와 별도인 연구진의 연구입니다. 중심 질문은 다음과 같습니다. [2]

제한된 데이터 큐비트에 더 많은 논리 큐비트를 담으면서도, 오류에 대한 보호 능력을 확보할 수 있을까?

논문 제목에 있는 High Rate는 계산 속도가 빠르다는 뜻이 아닙니다. 여기서 Rate는 데이터 큐비트 수에 비해 얼마나 많은 논리 큐비트를 담는지를 나타내는 비율입니다.

예를 들어 데이터 큐비트 200개에 논리 큐비트 43개를 담으면 이 비율은 21.5%입니다.

하지만 많은 정보를 담는 것만으로 좋은 코드가 되는 것은 아닙니다. 보호 능력이 너무 약하거나, 검사가 지나치게 복잡하면 실제 장비에서 쓰기 어려울 수 있습니다.

이 논문은 정보를 담는 비율, Code distance, 검사의 복잡도, 코드의 크기를 함께 고려하는 설계 원칙을 제안합니다.

흥미로운 점은 검사를 조금 더 복잡하게 하더라도 보호 능력이 충분히 좋아지면, 전체 오류율에서는 유리할 수 있다는 것입니다.

IonQ의 대표 BB5 코드에서는 검사 하나가 데이터 큐비트 5개에 관여합니다. 새 논문의 대표 코드들에서는 10개에 관여합니다.

검사할 대상이 늘면 더 많은 연산이 필요하고 오류가 생길 기회도 늘어납니다. 그럼에도 논문은 특정 조건에서 더 높은 보호 능력이 그 부담을 상쇄할 수 있음을 보여줍니다.

따라서 “검사가 단순할수록 무조건 좋다”거나 “논리 큐비트를 많이 담을수록 무조건 좋다”는 식으로 판단할 수 없습니다. 장비와 사용 목적에 맞는 균형을 찾아야 합니다.

인포그래픽 2 두 논문과 특허 출원의 역할. 기술적 연결 가능성과 실제 채택·성능 검증은 구분해야 합니다. [2][3][4]

Symplectic halving은 무엇을 하는 방법일까

새 논문은 Symplectic halving이라는 변환도 활용합니다.

쉽게 표현하면, 특별한 대칭 구조가 있는 코드를 수학적으로 접어서 더 작은 코드로 만드는 방법입니다.

원래 별도로 다루던 오류 성분을 함께 표현하는 구조로 바꾸면서, 더 작은 규모에서도 유리한 코드 구성을 찾습니다.

다만 Halving이라는 이름 때문에 “물리 큐비트를 절반으로 줄이고 논리 큐비트는 그대로 유지한다”고 이해하면 안 됩니다.

이 논문에서 설명하는 변환에서는 물리 데이터 큐비트 수와 논리 큐비트 수가 함께 절반으로 줄어, 둘의 비율은 유지됩니다. 보호 능력도 다시 평가해야 합니다.

연구의 성과는 이 변환 하나로 정보량이 두 배가 되었다는 데 있지 않습니다. 좋은 원본 코드 설계와 변환을 결합해, 비교적 작은 코드에서도 높은 저장 효율과 유리한 보호 능력을 가진 사례들을 찾았다는 데 있습니다.

데이터 큐비트 10000개에서 2150개가 나오는 계산

대표적인 결과가 [[200,43,20]] 코드입니다.

이 숫자는 데이터 큐비트 200개에 논리 큐비트 43개를 담으며, Code distance가 20이라는 뜻입니다.

논리 큐비트 하나당 데이터 큐비트는 약 4.65개입니다.

이 코드 묶음을 50개 배치한다고 가정하면 계산은 간단해집니다.

항목	계산	결과
데이터 큐비트	200개 × 50묶음	10,000개
논리 큐비트	43개 × 50묶음	2,150개

그래서 다음과 같은 해석이 가능합니다.

논문에 제시된 코드를 반복 배치하면, 10,000개 데이터 큐비트로 약 2,150개 논리 큐비트를 인코딩하는 구성을 생각할 수 있다.

여기서 인코딩은 정해진 규칙에 맞춰 양자정보를 담는다는 뜻입니다.

이 계산은 논문 속 코드의 효율을 이해하기 위한 것입니다. 연구진이 10,000큐비트 장비에서 2,150개의 논리 큐비트를 실제 구현했다는 의미는 아닙니다.

또한 작은 코드 묶음을 여러 개 배치한 것이므로 각 묶음의 Code distance는 여전히 20입니다. 전체 시스템에서 수행할 계산이 커지면, 그 계산 전체가 실패할 확률도 별도로 평가해야 합니다.

인포그래픽 3 [[200,43,20]] 코드를 50묶음 배치한 계산. 보조 큐비트와 추가 연산 자원은 제외되며, 10K 하드웨어 실증 결과가 아닙니다. [2]

호텔의 객실 수와 운영 가능한 호텔은 다르다

바로 이 부분에서 ‘데이터 큐비트’라는 단어가 중요해집니다.

호텔을 예로 들어보겠습니다.

건물 안에 객실을 얼마나 넣을 수 있는지 계산하는 것과, 그 호텔을 실제로 운영하는 것은 다릅니다. 운영하려면 복도와 엘리베이터, 관리실과 각종 설비 공간도 필요합니다.

양자컴퓨터에서도 데이터 큐비트는 정보를 담는 객실에 해당합니다. 보조 큐비트와 논리 연산에 필요한 추가 자원은 호텔 운영에 필요한 공간에 가깝습니다.

삽화 2 호텔의 객실 외에도 복도와 설비 공간이 필요하듯, 양자컴퓨터에도 데이터 외의 자원이 필요합니다. AI 생성 비유 이미지입니다.

따라서 총 10,000개의 물리 큐비트를 가진 장비에서 10,000개를 모두 데이터 저장에 사용할 수 있다고 가정해서는 안 됩니다.

오류를 반복해서 검사하고, 서로 다른 논리 큐비트 사이에서 연산하고, 특정 계산에 필요한 추가 상태를 준비할 자원이 필요합니다.

“10,000개 데이터 큐비트로 약 2,150개 논리 큐비트를 인코딩할 수 있다”는 것과 “IonQ의 총 10,000큐비트 장비에서 바로 2,150개의 계산용 논리 큐비트를 사용할 수 있다”는 것은 분명히 다릅니다.

이번 논문은 첫 번째 해석을 뒷받침하는 코드 사례를 제공합니다. 두 번째 결론까지 내리려면 실제 장비에 맞춘 전체 설계와 검증이 더 필요합니다.

그렇다면 IonQ의 800개는 어떻게 볼 수 있을까

이 차이를 이해한 상태에서 IonQ의 목표인 800개를 다시 살펴보겠습니다.

같은 [[200,43,20]] 코드를 예로 들면, 논리 큐비트 800개 이상을 담는 데 필요한 코드 묶음은 19개입니다.

항목	계산	결과
데이터 큐비트	200개 × 19묶음	3,800개
논리 큐비트	43개 × 19묶음	817개
총 10,000개에서 남는 수	10,000개 − 3,800개	6,200개

정보를 담는 부분만 계산하면, 3,800개 데이터 큐비트로 800개를 조금 넘는 논리 큐비트를 인코딩할 수 있습니다. 나머지 6,200개는 오류 검사와 다른 작업에 배정하는 구상을 생각해 볼 수 있습니다.

물론 이 계산이 “6,200개면 모든 추가 자원이 충분하다”는 것을 입증하지는 않습니다.

이것은 IonQ가 공개한 확정 설계가 아니며, 해당 코드의 실제 적용이나 목표 오류율 달성을 확인한 결과도 아닙니다. 장비의 연결 방식과 측정시간, 오류 특성, 계산 종류에 따라 필요한 자원은 달라집니다.

하지만 적어도 800개라는 목표를 큐비트 수의 비율만으로 불가능하다고 단정하기는 어렵다는 점은 보여줍니다.

논문 속 2,150개를 그대로 제품 성능으로 받아들일 필요는 없습니다. 그 수치에서 추가 비용을 고려하더라도, 800개라는 목표를 검토할 수 있는 여지가 있다는 것이 이번 계산의 의미입니다.

인포그래픽 4 19묶음에 817 LQ를 담는 자원 배분 예시. 남는 6,200개가 충분한지는 미검증이며, 회사의 확정 설계가 아닙니다. [1][2]

두 연구가 만나려면 실제 장비에서 확인할 일이 남아 있다

새 논문은 데이터 큐비트를 효율적으로 쓰는 코드를 제시합니다. IonQ의 앞선 연구는 이온 사슬에서 오류 검사를 효율적으로 수행하는 방법을 다룹니다.

두 방향을 함께 검토할 가치는 있습니다. 다만 각각의 장점이 실제 시스템에서도 그대로 더해진다는 보장은 없습니다.

예를 들어 새 코드의 복잡한 검사를 소수의 보조 큐비트로 수행하면 검사시간이 길어질 수 있습니다. 시간이 늘면서 발생하는 오류가 코드의 장점을 줄일 수도 있습니다.

두 논문의 시뮬레이션 조건에도 차이가 있습니다. IonQ의 이온 사슬 모델은 대기 중 오류와 순차적인 게이트 실행을 반영합니다. 반면 새 논문의 주요 non-CSS 회로 시뮬레이션은 대기 중 오류를 제외하고, 최초 상태 준비와 최종 측정을 이상적으로 가정합니다. [2][3]

그러므로 서로 다른 조건에서 나온 성능 수치를 곧바로 같은 기준으로 비교해서는 안 됩니다.

IonQ의 10K 시스템을 단일한 긴 이온 사슬의 확대판으로 생각하는 것도 정확하지 않습니다. 회사가 별도로 공개한 Walking Cat Architecture는 이온을 여러 구역 사이로 이동시키고, 여러 구역에서 작업을 병렬로 수행하는 구조를 설명합니다. [5]

작은 코드의 효율을 대형 장비로 옮기려면 이런 시스템 설계가 함께 맞아야 합니다.

또한 새 논문을 IonQ가 채택했다거나, 앞서 공개된 특허 출원이 새 코드까지 보호한다는 사실은 이번 자료에서 확인되지 않습니다. 기술적으로 함께 검토할 가능성과 실제 채택 여부는 구분해야 합니다.

800개라는 숫자와 함께 봐야 할 정확도

IonQ의 로드맵은 논리 큐비트 800개와 함께 논리 오류율 0.0000001 미만이라는 목표도 제시합니다. [1]

논리 큐비트는 수량뿐 아니라 품질이 중요합니다. 같은 800개라도 얼마나 자주 오류가 발생하고, 얼마나 긴 계산을 견디며, 어떤 연산을 수행할 수 있는지에 따라 가치가 달라집니다.

비유하자면 객실이 800개 있다고 해서 호텔 운영이 완성되는 것은 아닙니다. 전기와 수도, 엘리베이터가 안정적으로 작동하고 손님이 실제로 머물 수 있어야 합니다.

양자컴퓨터도 정보를 담는 데서 더 나아가, 오류정정을 반복하면서 유용한 계산을 수행할 수 있어야 합니다.

앞으로 확인할 것은 명확합니다. 큰 장비에서도 정확도가 유지되는지, 계산 중 측정과 초기화가 안정적으로 이뤄지는지, 디코더가 검사 결과를 제때 처리하는지, 그리고 보호된 논리 큐비트로 실제 연산을 수행하는지입니다.

이 과정이 이어져야 논문 속 자원 효율이 제품의 성능이 됩니다.

800 Logical Qubit은 불가능한 목표가 아니다

양자컴퓨터의 발전에는 물리 큐비트를 더 많이 만드는 일과, 그 큐비트를 더 효율적으로 사용하는 일이 함께 필요합니다.

이번 고부호율 qLDPC 논문은 후자의 가능성을 보여줍니다. IonQ의 BB5 연구와 관련 특허 출원은 이온트랩의 특성을 활용해 오류 검사를 구현하는 또 다른 방향을 보여줍니다.

두 흐름을 함께 보면, 논리 큐비트 하나를 만드는 데 필요한 자원이 영원히 고정되어 있는 것은 아니라는 점을 알 수 있습니다.

물리 큐비트의 품질이 좋아지고, 코드가 발전하고, 검사 회로와 시스템 설계가 개선되면 같은 장비에서 활용할 수 있는 논리 큐비트의 범위도 달라질 수 있습니다.

그렇다고 2,150개라는 계산을 IonQ의 성능 전망으로 그대로 옮겨 적어서는 안 됩니다. 데이터 인코딩 수와 실제 계산용 논리 큐비트 수 사이에는 추가 자원과 검증이 필요합니다.

저는 바로 그 차이를 인정한 상태에서 이번 연구를 긍정적으로 봅니다.

논문 속 코드는 800개라는 목표를 이해할 수 있는 구체적인 숫자를 제공합니다. 아직 달성이 입증된 것은 아니지만, 물리 큐비트 10,000개로 논리 큐비트 800개를 만든다는 목표를 수량상 불가능하다고 볼 이유는 없습니다.

IonQ의 로드맵에 제시된 800 Logical Qubit은 불가능한 목표는 아닙니다. 이제 확인해야 할 것은, 그 가능성을 목표한 정확도와 실제 계산 성능으로 구현할 수 있느냐입니다.

관련된 동영상은 아래 링크를 클릭하면 보실 수 있습니다.

https://youtu.be/8r7O-9WqW-A

자료와 계산 기준

[1] IonQ 공식 Roadmap

2026년 10월 2일 확인. 2027년 물리 큐비트 10,000개, 논리 큐비트 800개 및 논리 오류율 목표.

https://www.ionq.com/roadmap

[2] Design Principles for Ultra-High-Rate Quantum Codes

Jong Yeon Lee 외. arXiv:2609.30069v1, 2026년 9월 24일. Table II, IV.C절, VIII절.

https://arxiv.org/abs/2609.30069

[3] Quantum error correction for long chains of trapped ions

Min Ye와 Nicolas Delfosse. arXiv:2503.22071v3, 2025년 11월 19일. 3~6쪽의 회로·코드·시뮬레이션 비교.

https://arxiv.org/abs/2503.22071

[4] US 2026/0300800 A1

Methods and Apparatuses for Detecting Errors in a Quantum Circuit. IonQ 출원, 2026년 10월 1일 공개. 사용자가 제공한 특허출원 공개 PDF의 명세서와 청구항 기준.

[5] Walking Cat Architecture

IonQ, Blueprint for Fault-Tolerant Trapped-Ion Quantum Computing: The Walking Cat Architecture, 2026년 4월 22일.

https://ionq.com/blog/blueprint-for-fault-tolerant-trapped-ion-quantum-computing-the-walking-cat-architecture

계산의 범위

2,150 LQ는 [[200,43,20]] 코드 50묶음의 데이터 인코딩 수입니다. 817 LQ와 데이터 큐비트 3,800개는 19묶음의 산술적 계산입니다. 두 예시는 10K 하드웨어 실증이나 IonQ의 확정 설계가 아니며, 보조·연산 자원의 충분성과 목표 오류율 달성을 입증하지 않습니다.

이미지 안내

파스텔 삽화 2점은 AI 생성 개념 이미지입니다. 인포그래픽 4점은 위 자료와 명시된 가정을 바탕으로 제작했습니다. 이모티콘 이미지는 Twemoji, CC BY 4.0을 사용했습니다. https://github.com/jdecked/twemoji