TPU를 줬더니 절반은 실패했다 — 저장소를 통째로 옮기는 AI 벤치마크 XStack

2026년 11월 5일 arXiv에 XStack: A Benchmark for ML Repo Migration이라는 논문이 올라왔다. 논문 첫머리의 숫자는 단순하다. 파이토치 저장소 하나를 JAX 저장소로 옮기는 작업에서 Claude Opus 5가 75%, GPT-5.6-sol이 45%, 그리고 나머지 모든 에이전트가 40% 이하다. 사람이 며칠 붙잡고 하는 일을 기계가 열에 일곱까지 해낸다는 뜻이면서, 동시에 열에 셋은 무너진다는 뜻이기도 하다.

이 숫자가 눈에 걸리는 이유는 시험의 대상이 코드 한 조각이 아니기 때문이다. 실험실에서 돌아가던 학습 저장소 전체가 한 덩어리로 넘어간다. 논문은 이 이주를 두 갈래로 정당화한다. 하나는 실용적 필요, 다른 하나는 시험대로서의 자연스러움이다. 프레임워크도 하드웨어도 다르고, 저장소 전체를 다루며, 길고 어렵다.

지금 기계학습 코드는 두 진영에만 산다

논문이 그리는 지형은 단순하다. 기계학습 코드는 사실상 두 생태계에 몰려 있다. 엔비디아 GPU 위의 파이토치, 그리고 구글 TPU 위의 JAX다. 연구자가 어떤 하드웨어를 쓰느냐는 종종 취향이 아니라 그 실험실이 무엇을 사 놓았느냐로 결정된다. 코드가 먼저 쓰인 곳에 사람이 묶이는 셈이다.

논문의 첫 문장은 이 구도를 정면으로 뒤집는 선언이다. 기계학습 코드는 연구자가 고른 곳에서 돌아가야 하고, 처음 쓰인 곳에서 돌아갈 이유는 없다는 것이다. 문제는 그 선언을 실행에 옮기는 순간이다. 프레임워크를 바꾸면 텐서 연산의 이름이 바뀌고, 난수 시드의 의미가 바뀌고, 분산 학습을 묶는 방식이 통째로 달라진다. 한 줄 고쳐서 되는 일이 아니다.

에이전트가 받는 것과 내야 하는 것

XStack의 설정은 회계 장부처럼 건조하다. 에이전트는 파이토치 저장소 하나와 깨끗한 TPU 기계 하나를 받는다. 그리고 JAX 저장소를 내놓아야 한다. 중간에 무엇을 하든 평가자는 신경 쓰지 않는다. 결과물이 원래 저장소가 보고한 성능을 재현하면 통과다. 저장소 안에는 보통 학습 루프, 데이터 파이프라인, 평가 스크립트, 설정 파일이 함께 들어 있으므로, 옮겨야 하는 것은 모델 정의 하나가 아니라 실험의 재현 절차 전체다.

구글 TPU 3.0 보드. 논문이 말하는 두 번째 진영의 실제 하드웨어다 — Zinskauf, CC BY-SA 4.0 (Wikimedia Commons)

이 설정에서 '깨끗한 기계'라는 조건이 조용히 중요한 역할을 한다. 미리 세팅된 환경을 주면 에이전트가 환경을 고치는 데 성공하고 코드를 못 고쳐도 통과할 수 있다. 백지 상태에서 시작하게 하면 그 우회로가 막힌다. 시험은 코드 이주 능력만 재도록 설계된 셈이다.

채점은 논문에 적힌 결과와 대조한다

채점 방식은 이 벤치마크에서 가장 논쟁적인 부분이다. 점수는 정답 코드와의 유사도가 아니라, 원본 저장소가 공개한 결과를 재현했는지로 매긴다. 논문은 그 결과를 저자들이 직접 인증하고 보정했다고 밝힌다. 문법이 맞는 JAX 코드를 잔뜩 내놓아도, 숫자가 안 나오면 실패다.

이 기준은 후하게도 짜게도 읽힌다. 후하게 읽으면, 성능만 재현되면 내부 구조가 얼마나 다르든 상관없다는 뜻이다. 짜게 읽으면, 원본 논문이 보고한 수치 자체가 재현 불가능한 경우에는 시험 자체가 흔들린다는 뜻이다. 논문이 '인증과 보정'이라는 절차를 굳이 명시한 이유가 여기 있다. 채점 기준선부터가 저자들의 손으로 세워진 것이다.

75%라는 숫자의 반직관

직관적으로는 이런 작업이 잘 될 것 같다. 파이토치와 JAX는 텐서 연산의 의미가 크게 다르지 않고, 문서도 넘치고, 변환 예제도 인터넷에 널려 있다. 코드를 읽고 고치는 일은 언어 모델이 가장 잘하는 일로 분류된다. 그런데 최고 성능 에이전트도 네 번에 한 번은 실패한다.

더 흥미로운 것은 분포다. 75%, 45%, 그리고 나머지 전원 40% 이하. 2등과 3등 사이에 계단이 하나 있고, 그 아래로는 평평한 바닥이 깔려 있다. 논문은 이 격차의 원인을 분석하지 않는다. 다만 '신뢰할 수 없다(unreliable)'는 한 단어로 요약한다. 평균이 아니라 분산이 문제라는 독법이 가능한 대목이다.

실패는 어디서 오는가 — 논문 밖의 가설들

책상 위의 GPU 워크스테이션. 이주가 성공하면 같은 코드가 반대편 하드웨어에서도 돈다 — Wikideas1, CC0 (Wikimedia Commons)

논문은 실패의 해부도를 주지 않는다. 여기서부터는 독자의 추론이다. 첫 번째 가설은 '조용한 실패'다. JAX 코드가 오류 없이 실행되면서도 원래와 다른 계산을 하는 경우, 디버깅 신호가 없다. 텐서의 축 순서나 브로드캐스팅 규칙이 미묘하게 어긋나면 손실값은 그럴듯하게 나오고 정확도만 조금 떨어진다. 재현 기준이 엄격할수록 이 조용한 실패가 점수를 깎는다.

두 번째 가설은 길이의 문제다. 저장소 전체를 옮기는 일은 한 번의 긴 추론이 아니라 수십 번의 편집과 실행의 연쇄다. 어느 한 단계에서 앞선 판단을 잊으면 뒤가 전부 어긋난다. 세 번째는 하드웨어 조건이다. TPU는 메모리 배치와 재계산 전략에 민감해서, GPU에서 통하던 설정이 그대로는 돌지 않는 경우가 많다. 어느 가설이 맞는지는 XStack이 실패 로그를 공개해야 확인된다.

논문이 스스로 인정한 한계

논문은 이 벤치마크를 '한 걸음(a step)'이라고 부른다. 완성된 자가 아니라 방향이라고 스스로 규정하는 셈이다. 다루는 범위도 두 생태계, 두 방향이 아니라 파이토치에서 JAX로 가는 한 방향이다. 반대 방향이나 다른 프레임워크 조합은 시험대 밖에 있다.

채점 기준선을 저자들이 인증하고 보정했다는 점도 한계로 남는다. 재현성이라는 잣대 자체가 특정 시점의 특정 실행 환경에 묶인다. 하드웨어 드라이버가 바뀌고 라이브러리 버전이 올라가면, 작년에 통과한 코드가 올해 실패할 수 있다. 벤치마크가 살아 있으려면 기준선을 계속 다시 세워야 한다는 뜻이고, 그 비용은 논문에 적혀 있지 않다.

독자에게 던지는 질문

이 논문이 조용히 건드리는 것은 성능표가 아니라 연구의 물리적 조건이다. 코드가 특정 회사의 칩에 묶여 있다면, 그 칩을 살 수 없는 사람은 그 연구를 재현할 수도 없다. 이주가 자동화된다는 것은 재현성의 문턱이 하드웨어 가격에서 소프트웨어 노동으로 옮겨간다는 뜻이기도 하다.

그래서 질문은 이렇게 남는다. 여러분이 지난해 돌린 실험은, 지금 손에 있는 다른 하드웨어에서도 돌아갈까. 돌아가지 않는다면 그것은 코드의 문제일까, 아니면 애초에 그 칩을 전제로 설계된 연구라는 사실을 우리가 너무 늦게 알아차린 것일까.

참고 자료

Linrong Cai, Taiming Lu, Haozhe Chen, Zhuang Liu, ‘XStack: A Benchmark for ML Repo Migration’, arXiv:2611.08472v1 (2026-11-05). https://arxiv.org/abs/2611.08472v1

이미지: TPU 3.0 보드 — Zinskauf, CC BY-SA 4.0, Wikimedia Commons. GPU 워크스테이션 — Wikideas1, CC0, Wikimedia Commons.