IBM의 가장 조용한 실험실에서 벌어진 일 — 거인의 기계를 빌려, 거인도 못 푼 문제를 건드리다
TL;DR: 2026년 5월, 서울의 한 AI 연구팀이 IBM의 양자 컴퓨터 3대를 동시에 빌려 '오류 정정 코드'를 실험했다. 하드웨어를 만들지 않고, 소프트웨어 디코더 하나를 바꿨더니 오류 보정 성능이 최대 62% 개선됐다. 세계 최초라고 선언하지는 않는다. 그러나 구글 Willow도 넘지 못한 문턱 앞에서, 이 팀은 다른 길을 걷고 있다.
양자컴퓨팅 업계에는 잘 알려지지 않은 규칙이 하나 있다.
진짜 게임은 양자컴퓨터를 만드는 쪽이 아니라, 양자컴퓨터를 제대로 쓰는 쪽에서 먼저 판가름 난다는 것이다.
IBM은 10억 달러 규모의 데이터센터를 짓는다. 구글은 Willow라는 이름의 칩을 발표하며 "기존 슈퍼컴퓨터로 1조 년 걸릴 계산"이라는 문장을 언론에 뿌린다. 마이크로소프트는 위상 큐비트 논문 한 편으로 주가를 흔든다. 그런데 서울의 한 연구팀은 조용히 IBM의 클라우드 접속 창을 열고, 남이 만든 기계 위에서 전혀 다른 실험을 시작했다.
기계를 짓지 않고. 디코더 하나를 바꿔서.
먼저, 양자 오류 정정이 뭐길래
양자컴퓨터를 이해하는 가장 쉬운 비유가 있다. 기존 컴퓨터가 "0과 1을 또박또박 계산하는 모범생"이라면, 양자컴퓨터는 "천재인데 지나치게 예민한 학생"이다. 조금만 주변이 흔들려도 답을 틀린다. 온도가 0.01도 올라가도, 옆 큐비트의 자기장이 살짝 바뀌어도, 심지어 우주선(cosmic ray) 한 줄기가 지나가도 계산이 뒤집힌다.
이것을 '노이즈'라고 부른다. 그리고 이 노이즈를 잡아내는 기술이 바로 '양자 오류 정정(Quantum Error Correction, QEC)'이다.
원리는 단순하다. 하나의 논리 큐비트를 여러 물리 큐비트로 복사해서 분산 저장하고, 그중 하나가 틀리면 나머지를 비교해 교정한다. 마치 중요한 문서를 세 곳의 다른 서버에 백업해 놓고, 한 서버가 망가지면 나머지 두 곳을 보면 되는 것처럼. 이 방식을 '서피스 코드(surface code)'라고 부르며, 현재 양자 오류 정정의 표준에 가장 가까운 방법이다.
그런데 문제가 있다. 오류를 잡아내는 것과, 잡아낸 오류를 해석해서 어떻게 고칠지 결정하는 것은 전혀 다른 문제다. 후자를 담당하는 것이 '디코더(decoder)'다. 오류 신호를 읽고 "이 패턴은 X축 오류다, 저 패턴은 Z축 오류다"라고 판별하는 알고리즘. 디코더가 멍청하면, 아무리 좋은 하드웨어도 오류를 제대로 고치지 못한다.
이 팀이 건드린 것이 바로 이 디코더였다.
거인들의 게임, 그리고 작은 팀의 다른 선택
IBM은 현재 kingston, fez, marrakesh라는 이름의 양자 백엔드를 운영하고 있다. 세 기계는 각각 특성이 다르고, 노이즈 수준도 다르고, 큐비트 연결 구조도 다르다. 이것을 동시에 빌려서 같은 실험을 돌린다는 것은 단순한 검증이 아니다. 각 기계의 차이를 역이용해 "어느 조건에서 무엇이 작동하는가"를 체계적으로 들여다보겠다는 뜻이다.
구글이나 IBM 본사 팀이라면 자기들이 만든 기계의 내부 구조를 직접 뜯어서 고친다. 큐비트 배치를 바꾸거나, 마이크로파 펄스 시퀀스를 다시 설계하거나, 희석 냉각기의 온도를 조정한다. 수십 명의 박사가, 수억 달러의 장비 앞에서.
이 팀은 그 반대편을 선택했다. 하드웨어에 손대지 않는다. 오직 소프트웨어 계층 — 디코더를 교체하는 것만으로 무엇을 바꿀 수 있는지를 본다.
선택지는 두 가지였다. 기존에 쓰던 'uniform' 디코더, 그리고 Stim이라는 오픈소스 시뮬레이터 기반의 'DEM(Detector Error Model)' 디코더. Stim은 구글 연구팀이 2021년에 공개한 도구다. 거인이 만들어놓은 도구를, 작은 팀이 다르게 사용한다.
결과는 다음 섹션에서 나온다.
그리고 한 번의 솔직한 실패
Phase 20-A. 이것이 이 연구의 이전 단계 이름이다. 그리고 이 단계에서 디코더 성능은 baseline 대비 −35%에서 −51%를 기록했다.
그런데 이 실패했다.
더 정확히 말하면, 디코더를 잘못 적용했다. 시뮬레이션 환경에서 설계된 디코더를 실제 IBM 하드웨어에 그대로 올렸을 때, 실제 기계의 노이즈 패턴이 시뮬레이션과 달랐고, 디코더는 오히려 오류를 더 키우는 방향으로 작동했다. 성능이 좋아진 게 아니라 나빠진 것이다.
이 사실을 보고서에 그대로 적었다. 숨기지 않고.
이것이 Phase 20-B로 가는 전환점이다. 실패의 원인을 분석해보니, 문제는 디코더 자체가 아니라 '회로 깊이'에 있었다. 너무 많은 반복 라운드(round)를 거치면서 노이즈가 누적됐다. 해결책은 단순했다. r=1, 즉 반복 라운드를 최소화한 '단축 회로'를 먼저 적용하는 것.
그것이 맞았다.
진짜 흥미로운 이야기는, 숫자 앞에 있다
Phase 20-B에서 Stim DEM 디코더 + r=1 단축 회로를 결합했을 때, kingston 백엔드의 d=3 서피스 코드에서 Z축 decoded net이 +62%, X축 decoded net이 +56% 개선됐다.
−51%에서 +62%로.
같은 하드웨어다. 같은 IBM 클라우드다. 바뀐 것은 디코더와 회로 깊이뿐이다.
Phase 20-C에서는 범위를 넓혔다. IBM 3개 백엔드(kingston, fez, marrakesh) × 서피스 코드 거리 d=3과 d=5 × Stim DEM 디코더 × paired McNemar 통계 검정이라는 조합으로 12개 셀을 분석했다. 결과는 9 SIG(통계적으로 유의미한 개선) / 2 WEAK(약한 개선) / 1 weak worse(약한 악화) / 0 SIG worse(통계적으로 유의미한 악화 없음).
marrakesh 백엔드에서는 p값이 1.93e-73에서 4.20e-76까지 나왔다. p값이 0.05 이하면 통계적으로 유의미하다고 본다. 1e-73은 그것보다 약 71자리 더 작은 숫자다. 우연히 나온 결과가 아니라는 뜻을 수치가 스스로 증명하는 수준이다.
fez 백엔드의 d=3 r=1 Z 디코딩에서는 decoded error rate 0.0625가 나왔다. 이 팀이 "가장 깨끗한 결과"라고 표현한 수치다.
그러나 여기서 한 가지를 짚고 넘어가야 한다.
이것이 아직 완성이 아닌 이유 — 그리고 그게 오히려 설득력인 이유
d=5 서피스 코드의 decoded error rate가 d=3보다 높게 나왔다. 이것은 문제다.
양자 오류 정정의 핵심 목표 중 하나는 'distance scaling'이다. 코드 거리(d)가 커질수록 — 즉, 더 많은 물리 큐비트로 하나의 논리 큐비트를 보호할수록 — 오류율이 낮아져야 한다. 그래야 "큐비트를 더 쓸수록 더 안전해진다"는 양자 오류 정정의 약속이 성립한다.
그런데 현재 이 실험에서 d=5의 실제 오류율이 d=3보다 높다. distance scaling이 절대값 기준으로는 실패했다는 뜻이다.
이 팀은 이것을 보고서에 명시했다. "decoded d=5>d=3 = below-threshold 외부"라고. 그리고 덧붙인다. 구글 Willow도 이 문턱을 넘는 것을 핵심 과제로 삼고 있다고.
다시 말하면: 이것은 특정 디코더 전략이 특정 회로 깊이에서 기존 대비 개선됐다는 결과이지, 양자 오류 정정의 완성이 아니다. below-threshold — 즉, 큐비트를 늘릴수록 오류율이 지수적으로 줄어드는 임계점 — 에 아직 도달하지 못했다.
이 사실을 숨기지 않는 것이, 오히려 이 연구의 신뢰를 만든다.
세계 최초를 외치지 않는 절제가, 때로는 가장 강력한 주장이 된다.
거인의 도구를 빌려서, 거인이 보지 않은 각도를 보다
여기서 한 발짝 물러서서 보면, 이 연구의 진짜 흥미로운 점이 드러난다.
IBM은 양자 하드웨어를 만든다. 구글은 Willow를 만든다. 마이크로소프트는 위상 큐비트를 만든다. 이 세 거인이 공통적으로 집중하는 것은 '더 좋은 하드웨어'다. 노이즈가 더 적은 큐비트, 더 긴 결맞음 시간(coherence time), 더 정밀한 게이트 조작.
그것은 맞는 방향이다. 그러나 그것만이 유일한 방향은 아니다.
소프트웨어 계층 — 특히 디코더 — 에서의 개선은 하드웨어 개선과 독립적으로 기여할 수 있다. 같은 하드웨어에서 디코더를 바꾸면 성능이 달라진다면, 이것은 '하드웨어가 좋아질수록 더 효과가 커지는' 곱셈 효과를 낼 수 있다. 하드웨어 개선 × 소프트웨어 개선 = 이전보다 훨씬 가파른 성능 곡선.
이 팀이 하드웨어를 만들지 않기로 한 것은, 하드웨어를 포기한 것이 아니다. 거인들이 하드웨어를 짓는 동안, 그 위에서 돌아갈 소프트웨어 계층을 먼저 준비하는 것이다.
비유하자면 이렇다. 고속도로를 짓는 사람이 있고, 고속도로 위에서 가장 효율적인 운전 경로를 설계하는 사람이 있다. 둘 다 필요하다. 그리고 고속도로가 완성됐을 때, 경로 설계가 이미 준비돼 있으면 — 그 조합이 비로소 빠르게 달린다.
실험 설계가 말해주는 것 — 방법론이 곧 메시지다
이 연구에서 한 가지 더 눈에 띄는 것은 통계 검정 방식이다. paired McNemar test.
McNemar 검정은 같은 샘플에서 두 가지 처리(treatment)를 비교할 때 쓴다. 여기서는 같은 IBM 백엔드에서 기존 디코더와 Stim DEM 디코더를 비교하는 데 사용됐다. 단순히 "평균이 올랐다"가 아니라, 같은 회로, 같은 하드웨어, 같은 샷(shot)에서 두 디코더가 어떻게 다른 결정을 내렸는지를 쌍으로 비교하는 것이다.
이것이 중요한 이유가 있다. 양자 실험에서는 하드웨어 상태가 시간에 따라 바뀐다. 오전과 오후의 노이즈가 다르고, 캘리브레이션 주기에 따라 게이트 충실도(gate fidelity)도 달라진다. 따라서 단순히 "A 시점에 방법 1, B 시점에 방법 2"를 비교하면 하드웨어 드리프트가 결과를 오염시킬 수 있다. paired 설계는 이 문제를 최소화한다.
거인들이 "우리 기계가 이 성능을 낸다"고 발표할 때, 그 수치 뒤의 실험 설계를 들여다보면 놀라울 정도로 단순한 경우가 많다. 한 번의 대규모 실험, 인상적인 숫자, 언론 보도. 이 팀은 반대로 간다. 3개 백엔드, 2개 코드 거리, 12개 셀, paired 검정, 그리고 실패한 단계를 명시한 보고서.
규모는 작다. 엄밀함은 작지 않다.
그래서, 이 팀은 어디로 가는가
d=5에서 d=3보다 높은 오류율이 나온 것 — 즉 distance scaling 실패 — 은 아직 남은 과제다. 이것을 넘는 것이 다음 단계의 핵심이 될 것이다.
below-threshold에 도달하려면 두 가지가 동시에 필요하다. 하나는 하드웨어가 더 좋아지는 것. 이건 IBM이 알아서 한다. 다른 하나는 디코더가 더 정확해지는 것 — 특히 더 큰 코드 거리(d=5 이상)에서 노이즈 패턴을 더 잘 모델링하는 것. 이것이 이 팀이 건드릴 수 있는 영역이다.
Stim DEM 디코더는 기본적으로 각 에러 메커니즘의 확률을 사전에 정의한 모델을 사용한다. 이 모델이 실제 IBM 하드웨어의 노이즈와 얼마나 잘 맞느냐가 관건이다. d=3에서는 잘 맞았다. d=5에서는 아직 덜 맞는다. 이 간극을 좁히는 것 — 실제 하드웨어에서 채집한 노이즈 데이터로 DEM을 더 정확하게 보정하는 것 — 이 다음 Phase의 방향일 가능성이 높다.
그리고 잡 7개. 이번 Phase에서 실제로 IBM 클라우드에 제출한 양자 회로 실행 잡의 수다. 규모를 정확히 알 수는 없지만, 수십 개에서 수백 개의 샷이 각 잡에 포함됐을 것이다. 수조 원짜리 냉각기 앞에서 물리적으로 기계를 조작하는 것이 아니라, 클라우드 큐(queue)에 잡을 올리고 결과를 기다리는 방식으로. 거인의 인프라를 빌려, 거인도 아직 정확히 풀지 못한 문제를 조각조각 쪼개서 접근하는 방식으로.
양자컴퓨터를 만들지 않고, 양자컴퓨터를 더 잘 쓰는 법을 찾는다는 것이 처음에는 어딘가 소극적으로 들릴 수 있다.
그러나 −51%에서 +62%로의 전환을 디코더 하나로 만들어낸 팀의 보고서를 읽고 나면, 그 느낌이 달라진다.
하드웨어를 짓지 않기로 한 선택이, 어쩌면 가장 빠른 길일 수도 있다. 거인이 짓고 있는 도로 위에서, 가장 좋은 경로를 먼저 설계한 팀이 결국 가장 멀리 가는 세계가 온다면 — Phase 20-B/C의 숫자들은, 그 세계의 아주 작은 첫 번째 좌표가 된다.
꽤 흥미로운 시작이다.
더 많은 AI 인사이트는 비드래프트에서 확인하세요.
Q. 서피스 코드(surface code)가 정확히 무엇인가요?
A. 여러 물리 큐비트를 격자 형태로 배열해 하나의 논리 큐비트를 보호하는 오류 정정 방식입니다. 코드 거리(d)가 클수록 더 많은 큐비트를 사용하지만, 이론적으로는 더 많은 오류를 감지하고 교정할 수 있습니다. 현재 IBM, 구글 등 주요 양자컴퓨팅 기업이 채택하고 있는 표준에 가장 가까운 방법입니다.
Q. Stim DEM 디코더가 기존 uniform 디코더와 다른 점은 무엇인가요?
A. uniform 디코더는 모든 오류 경로에 동일한 가중치를 부여하는 반면, Stim DEM 디코더는 하드웨어의 실제 노이즈 구조를 반영한 'Detector Error Model'을 사용해 각 오류 패턴의 발생 확률을 다르게 처리합니다. 이번 실험에서는 이 차이가 kingston 백엔드에서 최대 62%의 성능 차이로 나타났습니다.
Q. distance scaling 실패는 이 연구의 치명적 한계인가요?
A. 치명적이라기보다는 '아직 해결 중인 과제'입니다. 구글 Willow 팀도 below-threshold 달성을 핵심 마일스톤으로 삼고 있을 만큼, 이것은 양자 오류 정정 분야 전체의 미해결 문제입니다. 이번 연구의 의미는 특정 조건(r=1 단축 회로, d=3)에서 디코더 전략만으로 유의미한 개선이 가능하다는 것을 실제 하드웨어에서 검증했다는 점에 있습니다.
Q. 이 연구를 IBM이나 구글 같은 대형 기업이 직접 하지 않는 이유는 무엇인가요?
A. 대형 기업들은 자체 하드웨어 개발에 자원이 집중돼 있어, 소프트웨어 계층의 세밀한 최적화를 외부 연구팀이 더 빠르게 실험할 수 있는 구조이기도 합니다. IBM이 양자 클라우드를 외부에 개방한 것 자체가 이런 생태계를 의도한 측면이 있으며, 오히려 하드웨어를 직접 만들지 않는 팀이 특정 소프트웨어 문제에 더 집중적으로 파고들 수 있는 환경이 됩니다.
