Reproducibility and Transparency Audit of Parallel Runtime Performance Reporting in Open-Source Benchmarks: A Case Study of the Rust, Julia, Haskell, and Python Ecosystems

컴퓨터 과학의 세계에서 연구자들은 어떤 프로그래밍 언어가 더 무거운 작업을 더 잘 처리하는지 확인하기 위해 끊임없이 서로 다른 언어들을 비교합니다. 여러 명의 작업자가 거대한 상자 더미를 옮기려는 상황을 상상해 보십시오. 어떤 팀은 한 명의 강한 사람을 사용하고, 어떤 팀은 협력하는 여러 명의 사람을 사용합니다. 디지털 영역에서 이 '협력하는 것'은 병렬 성능(parallel performance)이라고 불리며, 이는 컴퓨터가 어려운 작업을 더 빨리 끝내기 위해 여러 프로세서에 작업을 나누는 것을 의미합니다. 과학자들은 기상 예보부터 웹 서비스에 이르기까지 다양한 분야에 어떤 언어를 사용할지 결정하기 위해 이러한 비교를 사용합니다. 그러나 이러한 비교가 신뢰를 얻으려면, 연구자들은 실험을 어떻게 수행했는지에 대한 정확한 전체 레시피를 제공해야 합니다. 그들은 사용한 특정 컴퓨터, 소프트웨어의 정확한 버전, 작업에 할당된 작업자 수, 그리고 시간을 어떻게 측정했는지를 목록으로 작성해야 합니다. 이러한 세부 사항이 없다면, 한 언어가 다른 언어보다 빠르다는 주장은 과학적 사실이 아니라 단지 하나의 이야기에 불과합니다.

유니버시티 칼리지 런던(University College London)의 연구원 마그누스 브라이트(Magnus Bright)는 과학자들이 실제로 이러한 필수적인 세부 사항들을 제공하고 있는지 조사하기로 했습니다. 브라이트는 컴퓨터에서 새로운 테스트를 실행하는 대신, Rust, Julia, Haskell, Python이라는 네 가지 인기 있는 프로그래밍 언어를 다룬 160개의 발표된 연구 논문을 체계적으로 감사했습니다. 목표는 어떤 언어가 승리했는지를 보는 것이 아니라, 승자가 공정하게 선언되었는지를 확인하는 것이었습니다. 이 연구는 2015년부터 2025년 사이에 발표된 논문들을 검토하며, 저자가 다른 사람이 실험을 재현하여 동일한 결과를 얻을 수 있도록 필요한 구체적인 정보를 포함했는지 조사했습니다. 연구 결과는 어떤 세부 사항은 자유롭게 공유되는 반면, 다른 것들은 자주 누락되어 과학적 기록을 불완전하게 만드는 풍경을 보여주었습니다.

감사 결과, 연구자들은 일반적으로 기본적인 사항들을 보고하는 데는 능숙한 것으로 나타났습니다. 대부분의 논문은 처리 중인 데이터의 크기와 이를 처리하기 위해 사용된 작업자 또는 스레드의 수를 명확하게 명시했습니다. 이것들은 실험의 가장 명백한 부분이며, 이를 누락하면 결과를 이해하는 것 자체가 불가능해집니다. 그러나 연구는 더 미묘하지만 중요한 세부 사항에서 상당한 공백을 발견했습니다. 예를 들어, 초기 '웜업(warm-up)' 기간을 어떻게 처리했는지 보고한 연구는 약 3분의 1에 불과했습니다. 이는 특정 언어가 풀 스피드로 실행되기 전에 스스로를 준비시켜야 하는 중요한 단계입니다. 이 준비 과정이 얼마나 걸렸는지 알지 못하면, 보고된 속도가 실제 속도인지 아니면 단순히 설정의 결과물인지 알 수 없습니다. 마찬가지로, 작업자를 컴퓨터의 프로세서에 어떻게 배치했는지 설명한 연구는 4개 중 1개 미만이었습니다. 이러한 배치는 작업이 얼마나 빨리 실행되는지를 극적으로 변화시킬 수 있음에도 불구하고, 대부분의 저자는 이 정보를 누락했습니다.

통계적 엄밀함에 있어서는 상황이 훨씬 더 불균형했습니다. 많은 과학 분야에서 연구자들은 평균 결과뿐만 아니라 그 결과가 얼마나 변하는지도 보고합니다. 이러한 변동성은 두 언어 사이의 차이가 실제인지 아니면 단순한 무작위 노이즈인지를 독자에게 알려줍니다. 이번 감사에서 이 변동성에 대한 측정치를 포함한 연구는 약 40%에 불 old였습니다. 이것이 없다면 독자는 보고된 속도 차이가 의미 있는 것인지, 아니면 우연히 발생할 수 있는 것인지 알 수 없습니다. 또한 연구는 실제 코드와 데이터를 다른 사람들이 확인할 수 있도록 제공했는지도 살펴보았습니다. 약 70%의 연구가 소스 코드를 제공했지만, 소프트웨어가 다른 기기에서도 정확히 동일하게 작동하도록 보장하는 사전 패키징된 디지털 컨테이너와 같이 실행에 필요한 완전한 환경을 제공한 경우는 매우 적었습니다. 약 9%의 연구만이 그러한 컨테이너를 제공했으며, 이는 코드가 사용 가능하더라도 결과를 검증하기 위해 사용하기가 종종 어렵다는 것을 의미합니다.

연구자들은 보고의 품질이 어디에 발표되었는지와 어떤 언어 커뮤니티가 생성했는지에 따라 크게 달라진다는 점도 주목했습니다. 고성능 컴퓨팅 시스템을 다루는 학술지에 실린 연구들은 상세한 하드웨어 사양과 설정값을 포함하는 등 가장 철저했습니다. 반면, 일반 컴퓨팅 학술지의 연구들은 이러한 세부 사항을 포함할 가능성이 훨씬 낮았습니다. 나아가, 언어 커뮤니티 자체도 서로 다른 습관을 보였습니다. Rust와 Julia 주변의 커뮤니티는 소프트웨어 버전과 컴파일러 설정을 보고하는 데 더 주의를 기울이는 경향이 있었는데, 이는 그들의 도구가 그러한 세부 사항을 추적하기 쉽게 설계되었기 때문일 것입니다. Haskell 커뮤니티는 전반적으로 가장 낮은 보고 점수를 보였으며, Python 연구는 테스트를 몇 번 실행했는지를 보고하지 않는 경우가 많았습니다. 이 연구는 이러한 차이가 개인의 성실함 때문만이 아니라, 관련된 특정 그룹과 저널의 규범과 기대치 때문임을 시사합니다.

연구원들이 저자들이 이러한 세부 사항을 누락한 이유를 조사했을 때, 그 이유는 악의적이라기보다는 실무적인 경우가 많았습니다. 많은 저자가 컨퍼런스 논문의 엄격한 페이지 제한을 기술적 사양의 긴 목록을 생략하는 이유로 꼽았습니다. 다른 저자들은 특정 세부 사항이 동료들에게는 너무 당연해서 굳이 적을 필요가 없다고 가정했습니다. 일부 저자들은 발견의 이야기보다 방법론이 더 중요하다고 믿으며, 단순히 결과 자체를 우선시하기도 했습니다. 또한 연구는 법적, 윤리적 사각지대를 강조했습니다. 벤치마크에 사용된 데이터나 코드를 타인이 법적으로 재사용할 수 있는지 여부가 불분명한 경우가 절반 이상이었습니다. 이러한 명확성의 부족은 미래의 연구자들이 법적 문제를 겪지 않고 과거의 연구를 바탕으로 발전시키는 것을 어렵게 만듭니다.

이러한 문제를 해결하기 위해, 연구는 프로그래밍 언어 비교를 발표하는 모든 이들을 위한 간단하고 최소한의 체크리스트를 제안합니다. 이 체크리스트는 저자들에게 특정 컴퓨터 하드웨어, 정확한 소프트웨어 버전, 병렬 작업자 구성 방식, 데이터의 크기와 출처, 테스트를 실행한 횟수, 그리고 결과를 분석하는 데 사용된 통계적 측정치를 목록으로 작성할 것을 요구합니다. 또한 코드와 데이터를 다른 사람들이 쉽게 실행할 수 있는 방식으로 공유할 것을 요구합니다. 연구는 성능 주장의 신뢰도는 그것을 뒷받침하는 문서화에 전적으로 달려 있다고 결론짓습니다. 맥락 없는 속도 향상은 단지 숫자일 뿐이지만, 적절한 세부 사항이 있다면 그것은 신뢰할 수 있는 과학적 지식이 됩니다. 더 명확한 표준을 채택함으로써, 커뮤니티는 성능 연구에 투입된 상당한 노력이 모두가 신뢰하고, 이해하며, 토대로 삼을 수 있는 결과로 이어지도록 보장할 수 있습니다.