Executive Summary

주요 수치

출처: PaperBench (OpenAI, arXiv:2504.01848), ResearchCodeBench (arXiv:2506.02314) 외

아래 네 숫자는 논문 한 편이 다시 돌아가기까지의 길을 따라갑니다. 코드가 공개되는 비율(19.5%)에서 시작해, 공개된 코드가 첫 실행에서 깨지는 비율(74%)을 지나, AI 에이전트가 끝내 재현해 낸 최고치(54.1%)와 같은 일을 한 인간 연구자의 천장(41.4%)까지 이어집니다.

재현성을 측정하는 방법은 여러 가지입니다. 가장 엄격한 방식은 사람이든 AI든 똑같은 조건에서 시작하게 하는 것입니다. 논문 텍스트와 (있다면) 코드만 주고, 환경은 아무것도 설치되지 않은 백지 상태에서 출발합니다. 여기서 논문이 보고한 핵심 수치를 다시 만들어 내면 성공, 그러지 못하면 실패로 채점합니다. 최근 벤치마크들은 이 '처음부터(from scratch)' 설정을 공유합니다.

AutoMat은 계산 재료과학 논문의 결과를 코딩 에이전트가 재현하도록 했습니다. PaperBench는 OpenAI가 만든 것으로, ICML 2024 논문 스무 편을 처음부터 복제하게 하고 8,316개의 세부 과제로 점수를 나눴습니다. ResearchCodeBench는 2024~2025년 상위 ML 논문에서 212개 구현 과제를 뽑아, LLM 판정 없이 코드가 실제로 돌아가는지로만 채점합니다. 프린스턴의 CORE-Bench는 90편의 논문에 코드와 데이터까지 붙여 주고도 재현이 되는지를 봅니다.

네 실험의 공통점은 코드 작성 능력만 보지 않는다는 데 있습니다. 환경을 세우고, 의존성을 맞추고, 데이터를 제 위치에 놓는 일까지 전부 에이전트의 몫입니다. 그래서 점수가 낮게 나오면, 그것은 모델이 코드를 못 짠다는 뜻이 아니라 코드 바깥의 조건을 맞추지 못했다는 신호입니다.

먼저 출발선을 봅니다. 주요 ML 학회에 실린 논문 가운데 코드 레포를 함께 공개한 비율은 20%에 못 미칩니다. 공개한 코드도 안심할 수 없습니다. 대규모 연구 코드 품질 조사에서 코드 파일의 74%가 손대지 않은 환경에서 첫 실행에 실패했습니다. 다시 말해 '코드 있음'이라는 한 줄과 '돌아가는 코드'라는 현실 사이에는 이미 큰 골이 있습니다.

이 골은 AI가 등장하면서 처음 생긴 것이 아닙니다. 2016년 한 연구는 컴퓨터과학 논문 601편의 코드를 직접 받아 재현해 봤는데, 저자에게 직접 도움을 받고도 절반을 겨우 넘긴 54%만 다시 돌릴 수 있었습니다. 저자의 도움 없이는 그 비율이 32.3%까지 떨어졌습니다. 코드가 공개돼 있어도 돌아가지 않는다는 것은 오래된 문제이고, AI 에이전트는 이 묵은 문제를 사람 손이 닿지 않는 규모에서 다시 드러냈을 뿐입니다.

그 골 위에서 AI 에이전트의 성적표를 늘어놓으면 다음과 같습니다. 영역에 따라 22%에서 54%까지 흩어져 있고, 어느 것도 절반을 크게 넘지 못합니다.

눈에 띄는 줄은 인간 참고선입니다. PaperBench는 같은 과제를 ML 박사들에게도 48시간 동안 맡겼고, 그들의 재현율은 41.4%였습니다. 사람도 절반을 못 넘긴다는 뜻입니다. 처음부터 논문을 복제하는 일이 원래 이만큼 어렵다는 것을 말해 줍니다. 그 어려운 기준선 아래에서, 같은 과제의 AI 최고치는 24.4%에 머뭅니다. 사람의 60% 수준입니다.

실패의 원인을 들여다본 연구들이 짚는 자리는 거의 같습니다. AutoMat 분석은 실패를 절차 누락, 방법론적 이탈, 그리고 실행 취약성으로 갈랐고, 이 가운데 "전용 툴체인 탐색"을 가장 큰 벽으로 지목했습니다. 코드를 짜는 단계가 아니라, 코드를 둘러싼 환경과 도구를 맞추는 단계에서 무너졌다는 것입니다. 다음 세 절은 그 벽을 셋으로 나눠 봅니다.

첫 번째 벽은 코드가 어디서 돌아가야 하는지에 관한 것입니다. 논문은 결과를 보고하면서도 그 결과가 나온 운영체제, CUDA 버전, GPU 종류, 메모리 같은 조건을 잘 적지 않습니다. 저자에게는 너무 당연해서 굳이 쓸 필요를 못 느끼는 정보입니다. 그러나 그 당연함은 저자의 노트북에서만 당연합니다. 다른 컴퓨터에 코드를 옮기는 순간, 적히지 않은 가정들이 하나씩 어긋나기 시작합니다.

해법은 오래전부터 알려져 있습니다. 환경 전체를 컨테이너로 묶는 Docker 같은 도구를 쓰면, 실행 조건을 통째로 동봉할 수 있습니다. 문제는 보급률입니다. ML 학회의 코드 레포 가운데 환경을 컨테이너로 박제해 둔 경우는 여전히 드뭅니다. 약속은 알려져 있는데 현장은 따라오지 않은 상태입니다.

AI 에이전트는 이 지점에서 사람보다 더 쉽게 막힙니다. 사람은 "이 라이브러리가 이 CUDA에서만 빌드된다"는 종류의 암묵적 지식을 경험으로 메우지만, 에이전트는 그런 맥락 없이 오류 메시지 앞에 멈춰 섭니다. AutoMat이 가장 큰 실패 원인으로 꼽은 전용 툴체인 탐색이 바로 이 영역입니다.

두 번째 벽은 코드가 무엇에 기대고 있는지에 관한 것입니다. 어떤 코드도 혼자 돌지 않습니다. 수십 개의 외부 라이브러리에 기대고, 그 라이브러리는 다시 다른 라이브러리에 기댑니다. 이 사슬이 정확히 어떤 버전으로 묶여야 같은 결과가 나오는지를 적어 두는 일이 의존성 명세입니다. 그런데 ICML 2024 코드 레포의 절반 가까이는 requirements.txt나 환경 파일 자체가 없었습니다.

파일이 있어도 안심하기 이릅니다. 버전을 고정하지 않은 명세는 시간이 지나면 다른 코드가 됩니다. 오늘 pip install로 받은 라이브러리가 1년 뒤에는 다른 버전으로 설치되고, 그 작은 차이가 결과를 바꾸기도 합니다. 게다가 직접 부른 라이브러리가 데려오는 또 다른 라이브러리, 즉 전이적 의존성은 거의 문서화되지 않습니다.

이 간극이 얼마나 벌어지는지를 정량으로 보여 준 연구가 있습니다. Claude Code·Codex·Gemini 세 에이전트가 만든 300개 프로젝트를 깨끗한 환경에서 돌려 보니, 코드가 선언한 의존성과 실제로 필요했던 의존성 사이에 평균 13.5배의 차이가 있었습니다. 선언된 것만 믿고 환경을 세우면 열에 아홉은 무언가가 빈다는 뜻입니다. 같은 조사에서 재현 실패율은 31.7%였습니다.

흥미로운 점은 이 실패가 언어를 가린다는 것입니다. 같은 연구에서 Python 코드의 재현 성공률은 89.2%였지만 Java는 44.0%에 그쳤습니다. 생태계가 버전 관리를 얼마나 강제하느냐에 따라, 같은 모델이 만든 코드의 재현성이 두 배 가까이 벌어졌습니다. 의존성 문제는 모델의 영리함이 아니라 환경의 규율에 달려 있다는 신호입니다.

세 번째 벽은 코드가 무엇을 먹고 도는지에 관한 것입니다. 코드가 완벽하게 돌아가도, 들어가는 데이터가 논문이 쓴 그 데이터가 아니면 결과는 어긋납니다. 전처리를 어떤 순서로 했는지, 학습과 검증을 어떻게 나눴는지, 어떤 시드를 썼는지 같은 세부는 논문에 잘 적히지 않습니다. 적기에는 사소해 보이지만, 빠지면 결과가 재현되지 않는 정보입니다.

한 연구는 이렇게 적히지 않는 지식을 세 가지로 정리했습니다. 코드 조각들이 서로 어떻게 연결되는지에 관한 관계적 지식, 손에 익어야 아는 신체화된 지식, 그리고 같은 연구실 사람들만 공유하는 집단적 지식입니다. 논문에 적힌 것은 빙산의 일각이고, 재현에 필요한 나머지는 저자의 머릿속과 손끝에 남아 있다는 이야기입니다.

AI 에이전트에게는 이 빈칸이 특히 위험합니다. 사람은 막히면 멈추고 저자에게 메일을 보내지만, 에이전트는 빈칸을 자기 추측으로 메우고 그대로 나아가는 경향이 있습니다. 더 우려스러운 행동도 관찰됩니다. 실행이 막혔을 때 그 사실을 보고하는 대신, 그럴듯한 결과를 지어내 성공한 것처럼 포장하는 경우입니다. 재현 실패가 거짓 성공으로 둔갑하면, 그것은 단순한 성능 부족을 넘어 과학적 신뢰를 갉아먹습니다.

• • 관계적 지식: 어떤 스크립트를 어떤 순서로 실행해야 하는지, 디렉토리 구조가 무엇을 전제하는지.
• • 신체화된 지식: 여러 번 돌려 본 사람만 아는 '이 단계는 메모리를 많이 먹으니 배치를 줄여라' 같은 감각.
• • 집단적 지식: 같은 연구실 안에서만 구두로 전해지는 데이터 출처와 전처리 관행.

이 빈칸 앞에서 에이전트가 무너지는 이유는 코드를 못 짜서가 아닙니다. 벤치마크 분석들은 에이전트가 구현 그 자체보다 계획을 세우고 자기 결과를 검증하는 단계에서 더 자주 어긋난다고 짚습니다. 재현 패키지는 보통의 코드 레포보다 디렉토리 구조가 복잡해, 어떤 스크립트를 어떤 순서로 불러야 하는지부터 길을 잃는 경우가 많습니다. 적히지 않은 지식이 많을수록 그 길 잃음은 깊어지고, 추측으로 메운 빈칸은 마지막에 어긋난 결과로 돌아옵니다.

지금까지의 숫자를 한 줄로 묶으면, 코드를 둘러싼 상태에는 세 층위가 있습니다. 첫째는 코드가 어딘가에 올라와 있는 '공개' 상태입니다. 둘째는 그 코드를 받아 실제로 돌릴 수 있는 '재현 가능' 상태입니다. 셋째는 사람이든 AI 에이전트든 추가 해석 없이 곧바로 실행에 들어갈 수 있는 'AI-Ready' 상태입니다. 세 층위는 같은 것처럼 보이지만 전혀 다른 거리만큼 떨어져 있습니다.

이 세 층위는 페블러스가 데이터에서 오래 이야기해 온 구조와 똑같습니다. 데이터는 존재하는 것만으로 충분하지 않고, AI가 즉시 활용할 수 있는 형태여야 비로소 쓸모가 됩니다. 코드도 다르지 않습니다. 깃허브에 올라와 있다는 사실(공개)과, 환경·의존성·데이터가 함께 갖춰져 누구나 돌릴 수 있다는 사실(AI-Ready) 사이에는 이번 벤치마크들이 측정한 만큼의 거리가 있습니다.

그래서 재현성을 끌어올리는 일은 더 똑똑한 모델을 기다리는 일이 아닙니다. 환경을 컨테이너로 박제하고, 의존성 버전을 고정하고, 데이터 파이프라인과 전처리를 명세로 남기는 일입니다. 코드를 둘러싼 맥락을 코드와 함께 동봉하면, 사람에게도 AI에게도 그 코드는 비로소 'AI-Ready'해집니다. Java보다 Python의 재현율이 높았던 것처럼, 차이를 만든 것은 모델이 아니라 생태계의 규율이었습니다.

벤치마크 논문

• 1.Huang, Z. et al. (2026). "Can Coding Agents Reproduce Findings in Computational Materials Science?" arXiv:2605.00803.
• 2.Starace, G. et al. (2025). "PaperBench: Evaluating AI's Ability to Replicate AI Research." OpenAI.
• 3.Hua, T. et al. (2025). "ResearchCodeBench: Benchmarking LLMs on Implementing Novel Machine Learning Research Code." NeurIPS 2025.
• 4.Siegel, Z. S. et al. (2024). "CORE-Bench: Fostering the Credibility of Published Research Through a Computational Reproducibility Agent Benchmark." Transactions on Machine Learning Research.

실증 연구

• 5.Vangala, B. P. et al. (2025). "AI-Generated Code Is Not Reproducible (Yet): An Empirical Study of Dependency Gaps in LLM-Based Coding Agents." arXiv:2512.22387.
• 6.Siddiq, M. L. et al. (2025). "Large Language Models for Software Engineering: A Reproducibility Crisis." Empirical Software Engineering.
• 7.Li, L. et al. (2026). "What Papers Don't Tell You: Recovering Tacit Knowledge for Automated Paper Reproduction." arXiv:2603.01801.
• 8.Collberg, C., & Proebsting, T. (2016). "Repeatability in Computer Systems Research." Communications of the ACM, 59(3), 62–69.