💻 computer science

JETO-Bench: A Reproducible Benchmark for Execution Time Improvement Patches in Java

이 논문은 Java에서 실행 시간 개선 패치의 재현 가능한 벤치마크를 생성하기 위한 새로운 구성 가능한 도구인 JETO-Mine을 소개하며, 이는 174개의 저장소에서 식별된 660개의 패치로 구성된 데이터셋인 JETO-Bench를 만드는 데 사용되었고, OpenHands와 같은 현재의 코딩 에이전트들이 이러한 작업에서 14.3%의 성공률을 달성함을 입증하는 동시에 오픈 소스 프로젝트에서 성능 관련 테스트가 현저히 부족하다는 점을 강조한다.

원저자: Khashayar Etemadi, Zhendong Su

게시일 2026-07-01

📖 4 분 읽기☕ 가벼운 읽기

CC0 1.0

원저자: Khashayar Etemadi, Zhendong Su

원본 논문은 CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/)에 따라 공공 도메인에 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신이 자바(Java)라는 인기 있는 프로그래밍 언어로 작성된 방대한 소프트웨어 코드 라이브러리를 가지고 있다고 상상해 보세요. 수년 동안 연구자들은 이 코드를 자동으로 찾아내고 수정할 수 있는 "로봇 정비사"(AI 에이전트)를 구축하기 위해 노력해 왔습니다. 하지만 대부분의 로봇은 **기능적 버그(functional bugs)**를 고치는 데만 훈련되었습니다. 기능적 버그란 소프트웨어가 충돌하거나 틀린 답을 내놓는 실수(예: 계산기가 2+2를 5라고 답하는 경우)를 말합니다.

그렇다면 **성능 버그(performance bugs)**는 어떨까요? 성능 버그는 소프트웨어가 올바르게 작동은 하지만, 믿기지 않을 정도로 느린 경우를 말합니다. 마치 자동차 엔진이 정상적으로 작동은 하지만, 시속 60마일에 도달하는 데 시간이 너무 오래 걸려 덜컹거리는 것과 같습니다. 지금까지는 우리의 로봇 정비사가 이러한 "느린" 문제들을 고칠 수 있는지 테스트하는 것이 특히 자바 환경에서는 매우 어려웠습니다.

다음은 이 논문이 소개하는 내용에 대한 간단한 요약입니다:

1. 문제점: 자바의 "휘발성(Volatility)"

자바에서 속도 문제를 해결하는 것은 트랙의 표면이 몇 초마다 바뀌는 트랙 위에서 러너의 시간을 측정하는 것과 같습니다.

도전 과제: 자바에는 사용하면 사용할수록 더 빨라지는 특수한 "엔진"(Just-In-Time 컴파일)과 가끔 작업 공간을 청소하기 위해 멈추는 기능(Garbage Collection)이 있습니다. 이 때문에 속도를 측정하는 것이 매우 까다롭습니다. 어떤 테스트는 코드가 나빠서가 아니라 단순히 컴퓨터가 "예열 중"이었기 때문에 느리게 보일 수 있습니다.
공백: 기존의 벤치마크(테스트 세트)는 파이썬(Python)이나 C++ 같은 다른 언어에는 존재하지만, 자바에는 신뢰할 수 있는 공정한 테스트 세트가 부족했습니다.

2. 해결책: JETO-Mine (더 "금 채굴기")

저자들은 JETO-Mine이라는 도구를 만들었습니다. 이것을 소프트웨어 코드 속의 고성급 금을 캐내는 고성능 금 채굴기로 생각하면 됩니다.

1단계: 탐색 (정적 분석): 이 기계는 GitHub의 수백만 개의 커밋(변경 사항)을 스캔합니다. 개발자들이 변경 사항을 적용할 때 남긴 "노트"를 읽기 위해 스마트한 AI(LLM)를 사용하여, "이것을 더 빠르게 만들었다"와 같은 단서를 찾습니다.
2단계: 실험실 (동적 분석): 이 부분이 가장 중요합니다. 잠재적인 "속도 개선"이 발견되면, JETO-Mine은 해당 코드를 **도커 컨테이너(Docker container)**에 넣습니다. 이것은 모든 테스트를 위한 동일하고 격리된 "밀봉된 실험실"과 같습니다.
- 평균을 내기 위해 코드를 30번 실행합니다.
- 통계적 테스트(statistical testing)를 사용하여 속도 향상이 단순한 우연이 아니라 실제임을 증명합니다.
- 비교가 공정하도록 "이전" 버전과 "이후" 버전이 정확히 동일한 환경에서 실행되도록 보장합니다.
3단계: 심판 (평가 하네스): 로봇 정비사의 수정 사항이 실제로 작동하는지 확인하는 심판 역할을 합니다. 이 시스템은 새로운 코드를 실행하고, 원래의 테스트를 여전히 통과하는지 확인하며, 실제로 더 빨라졌는지 측정합니다.

3. 결과: JETO-Bench (보물 상자)

JETO-Mine을 사용하여 연구자들은 JETO-Bench를 제작했습니다.

그들은 11년의 기록과 거의 180만 개의 코드 변경 사항을 조사했습니다.
660개의 잠재적인 속도 개선 사항을 찾아냈습니다.
엄격한 테스트를 거쳐, 이 중 91개를 실행 가능하고 재현 가능한 "골드 스탠다드(gold standard)" 수정 사항으로 검증했습니다.
핵심 발견: 연구자들은 대부분의 오픈 소스 자바 프로젝트가 특정 코드 조각이 더 빨라졌음을 증명하는 테스트를 갖추고 있지 않다는 것을 발견했습니다. 이는 마치 레이싱 카는 가지고 있지만, 그것이 얼마나 빠른지 증명할 스톱워치가 없는 것과 같습니다.

4. 시운전: AI가 이 버그들을 고칠 수 있을까?

JETO-Bench가 유용한지 확인하기 위해, 연구자들은 선도적인 AI 코딩 에이전트인 OpenHands를 가져와 이 91개의 속도 문제를 해결하도록 요청했습니다.

점수: OpenHands는 문제의 **14.3%**를 성공적으로 해결했습니다.
의미: 이 결과는 파이썬이나 C++에 대한 다른 연구들이 보여준 결과와 유사합니다. 이는 AI가 발전하고 있기는 하지만, "느린" 코드를 고치는 것은 여전히 매우 어렵다는 것을 보여줍니다.
보너스: "심판"(평가 하네스)은 AI가 잘못된 수정을 했는지 거의 모두 잡아냈습니다. 만약 AI가 코드의 잘못된 부분을 고치려 하거나 빌드를 깨뜨렸다면, 시스템은 즉시 이를 알아차렸습니다.

5. 이것이 중요한 이유

재현 가능성: 이전에는 새로운 속도 수정 도구를 테스트하고 싶어도, 원래의 코드가 몇 년이 지난 지금도 여전히 작동하기를 기도해야 했습니다. JETO-Bench는 타임캡슐 환경(Docker)을 제공하여 누구나 오늘 똑같은 테스트를 실행하고 동일한 결과를 얻을 수 있게 합니다.
새로운 도전: 이 논문은 우리가 단순히 정확성을 측정하는 것이 아니라, 속도를 측정하는 새로운 방식의 테스트를 만들어야 한다는 점을 강조합니다.
아직 마법의 탄환은 없다: 이 연구는 고급 AI 에이전트조차 성능 최적화에 어려움을 겪고 있음을 확인시켜 주며, 이것이 더 많은 연구가 필요한 개척 분야임을 시사합니다.

요약하자면: 저자들은 자바 코드가 실제로 어떻게 빨라지는지를 찾아내고 검증하는 기계(JETO-Mine)를 만들었습니다. 이 사례들을 JETO-Bench라는 테스트 세트로 패키징했으며, 현재의 AI 로봇들이 이러한 속도 문제 중 약 7개 중 1개를 해결할 수 있다는 것을 입증했습니다. 또한, 소프트웨어 세계가 속도 향상을 제대로 측정하기 위한 도구(테스트) 자체를 결여하고 있다는 사실도 밝혀냈습니다.

기술 요약: JETO-Bench 및 JETO-Mine

문제 정의

자동 프로그램 수정(Automated Program Repair, APR)은 Defects4J나 SWE-Bench과 같은 벤치마크에 힘입어 크게 발전했습니다. 그러나 이러한 벤치마크들은 주로 기능적 버그에 집중되어 있어, 비기능적 이슈, 특히 실행 시간 성능(execution time performance)에 대한 표현이 부족합니다. Python, C++, .NET을 위한 실행 시간 개선 패치(ETIPs) 벤치마크(예: PIE, SWE-Perf, PerfBench)는 존재하지만, Java를 위한 벤치마크는 거의 부재한 상황입니다.

Java 벤치마크의 부재는 해당 언어의 특수한 런타임 특성 때문에 매우 치명적입니다. JIT(Just-In-Time) 컴파일과 가비지 컬렉션(GC)에 의존하는 Java의 특성은 실행 시간 측정의 변동성을 초래합니다. 소스 코드와 실행 시간이 더 직접적으로 연결된 Python이나 C++과 달리, Java 측정은 JVM 워밍업(warm-up), GC 간섭, 비결정론적 일시 중단(non-deterministic pauses)을 엄격하게 처리해야 합니다. 또한, 기존 Java 데이터셋(예: Yi et al.)은 고정되어 있고 확장할 수 없으며 컨테이너화된 환경을 갖추고 있지 않아, 프로젝트 의존성이 진화함에 따라 재현성을 확보하기 어렵습니다. 마지막으로, 현재의 성능 벤치마크는 사용자 정의 구성에 따라 새로운 실제 세계의 패치를 수집하도록 확장할 수 없습니다.

방법론: JETO-Mine

이러한 격차를 해소하기 위해, 저자들은 실제 Java 프로젝트에서 ETIP의 재현 가능한 벤치마크를 자동으로 생성하도록 설계된 구성 가능하고 재사용 가능한 도구인 JETO-Mine을 제시합니다. JETO-Mine은 3단계 파이프라인을 통해 작동합니다.

1. 정적 분석 단계 (Static Analysis Phase)

이 단계는 GitHub 저장소를 크롤링하여 사용자 정의 필터를 사용하여 잠재적인 ETIP를 식별합니다.

저장소 선택: 특정 스타(star) 수와 최근 업데이트 날짜를 기준으로 활발한 Java 프로젝트(Java 8 이상, Maven Wrapper)를 필터링합니다.
커밋/PR 필터링: 기본 브랜치의 디프(diff)를 분석하여, .java 파일만을 변경하고 테스트 파일을 제외하며, 변경된 파일 수가 제한적인 경우만 유지합니다.
LLM 분류: 이슈 제목, 설명, 커밋 메시지를 LLM에 프롬프트로 제공하여 해당 변경 사항이 주로 실행 시간 개선을 다루는지 판단합니다.
중복 제거: 개별 커밋을 그에 대응하는 풀 리퀘스트(PR)로 대체하여 완전한 개발자 의도를 포착하고, 코드 디프를 기준으로 중복을 제거합니다.

2. 동적 분석 단계 (Dynamic Analysis Phase)

이 단계는 식별된 ETIP를 Docker를 사용하여 실행 가능하고 재현 가능한 환경으로 변환합니다.

환경 구축: 프로젝트를 빌드하고 테스트하는 데 필요한 특정 Java 버전 및 의존성을 포함하는 Docker 이미지를 생성합니다.
JVM 완화: JVM의 변동성을 상쇄하기 위해, 파이프라인은 타이밍 실행 전 전용 "워밍업(warm-up)" 라운드를 실행(결과는 폐기)합니다. GC 및 JIT 변동성을 최소ize하기 위해 동일한 JVM 구성 내에서 테스트 스위트를 여러 번(기본 $n=30$ ) 실행합니다.
통계적 검정: 원본 버전과 패치된 버전 사이의 실행 시간에 대해 짝 지어진 단측 이항 검정(paired one-sided binomial tests)을 수행합니다. 패치는 특정 테스트 클래스에서 통계적으로 유의미한 개선(설정 가능한 $p$ -값 및 최소 개선 백분율)을 보일 경우 ETIP로 간주됩니다.
검증: 프로젝트가 빌드되고 모든 테스트가 통과하는지 확인합니다. 패치가 빌드에 실패하거나 기존 테스트를 깨뜨리는 경우 제외됩니다.

3. 평가 하네스 (Evaluation Harness)

이 단계는 생성된 패치와 테스트를 정량적으로 평가하기 위한 도구를 제공합니다.

패치 평가: 생성된 패치를 가져와 Docker 컨테이너 내의 원본 코드에 적용하고, 통계적 검정을 수행하여 패치가 실행 시간을 개선하는지 결정합니다.
테스트 생성 평가: "ETIP 탐지 테스트"(성능 개선을 통계적으로 검증할 수 있는 테스트)를 생성하는 도구들을 평가하는 것을 지원합니다.

주요 기여

1. JETO-Mine 도구

재현 가능한 Java ETIP 벤치마크를 생성하기 위한 최초의 구성 가능한 도구입니다. 연구자들이 커스텀 필터와 통계적 엄밀함을 사용하여 새로운 벤치마크를 지속적으로 수집할 수 있게 함으로써, 기존 데이터셋의 경직성 문제를 해결합니다.

2. JETO-Bench 벤치마크

JETO-Mine을 사용하여 저자들은 다음과 같이 구성된 JETO-Bench를 구축했습니다.

660개의 식별된 ETIP: 11년간의 개발 역사(약 180만 개의 커밋)를 가진 174개의 오픈 소스 Java 저장소에서 수집되었습니다.
91개의 수동 검증된 실행 가능 ETIP: 패치가 성공적으로 빌드되고, 테스트를 통과하며, 설명적인 이슈와 연결된 정제된 서브셋입니다. 이는 완전한 재현성을 위해 Docker 이미지와 함께 제공됩니다.
다양성: 벤치마크는 다양한 프로젝트 유형(분산 시스템, 클라우드 네이티브 프레임워크 등)을 포괄하며, 저장소 수준의 복구 도구 평가에 적합한 멀티 파일 및 멀티 모듈 패치를 포함합니다.

3. 경험적 평가

저자들은 91개의 검증된 ETIP에 대해 선도적인 오픈 소스 코딩 에이전트인 OpenHands를 평가했습니다.

성공률: OpenHands는 14.3% (13/91)의 이슈를 올바르게 수정했습니다. 이는 다른 언어에 대한 유사한 연구에서 보고된 성공률과 일치하며, JETO-Bench가 신뢰할 수 있는 벤치마크임을 시사합니다.
결함 국지화(Fault Localization): 27.5%의 사례에서 OpenHands는 올바른 코드 위치를 수정했으나 의미적으로 올바른 패치를 생성하는 데는 실패했습니다. 이는 결함 국지화가 주요 개선 영역임을 보여줍니다.
테스트 부족: 연구 결과, 오픈 소스 Java 프로젝트에는 실행 시간 개선을 입증하는 테스트가 크게 부족한 것으로 나타났습니다. 검증된 ETIP 중 단 15%만이 JMH 벤치마크를 포함하고 있었으며, 기존 JUnit 테스트는 통계적으로 유의미한 성능 차이를 거의 감지하지 못했습니다.

결과 및 발견 사항

정밀도(Precision): 무작위로 선정된 50개의 식별된 ETIP를 수동 분석한 결과, JETO-Mine의 식별 프로세스에서 96%의 정밀도를 확인했습니다.
확장성(Scalability): 정적 분석은 478시간 동안 170만 개의 커밋을 처리했으며(약 20일 소요), LLM 필터링 비용은 $5.33였습니다. 동적 분석은 660개의 ETIP를 152시간 내에 처리했으며, Docker 이미지 빌드 시간 중앙값은 34분, 이미지 크기 중앙값은 790 MB였습니다.
에이전트 성능: OpenHands는 14.3%의 성공률을 기록했으며, 생성된 패치의 22%가 성공적으로 빌드되고 테스트를 통과했습니다. 평가 하네스는 잘못된 패치를 효과적으로 걸러내어(91개 중 20개만 모든 테스트 통과), 실행 기반 피드백의 가치를 입증했습니다.
테스트 생성 격차: 91개 사례에 대해 OpenHands를 사용하여 ETIP 탐지 테스트를 생성하려는 예비 시도는 단 한 건만 성공하였으며, 이는 성능 개선을 신뢰성 있게 측정할 수 있는 테스트를 생성하는 것이 얼마나 어려운지를 강조합니다.

의의 및 주장

본 논문은 JETO-Mine과 JETO-Bench가 Java 실행 시간 개선을 위한 최초의 구성 가능하고 재현 가능한 벤치마크를 제공함으로써, 자동 수정 분야의 중요한 공백을 메운다고 주장합니다.

재현성: Docker와 통계적 검정을 활용하여 JVM의 변동성을 완화함으로써, 벤치마크는 이전의 정적 데이터셋과 달리 객관적이고 재현 가능한 성능 주장을 보장합니다.
확장성: 고정된 데이터셋과 달리, JETO-Mine은 커뮤니티가 특정 연구 요구에 따라 새로운 패치를 지속적으로 벤치마크에 추가할 수 있도록 합니다.
연구 기회: 연구 결과는 현재의 테스트 관행에서 중요한 격차를 드러냈습니다. 즉, 실행 시간 개선을 검증하는 테스트의 희소성입니다. 저자들은 이것이 성능 최적화를 위한 자동 테스트 생성 분야의 유망한 연구 기회가 될 것이라고 제언합니다.
벤치마크 유용성: OpenHands에 대한 평가는 JETO-Bench가 고급 코딩 에이전트의 Java 성능 작업 능력과 한계를 평가하는 데 효과적임을 보여주며, 이는 다른 언어에서 관찰된 결과와 일치합니다.

저자들은 현재의 에이전트들이 성능 이슈를 해결하는 데 제한적인 성공을 보이지만, JETO-Bench와 같이 엄격하고 재현 가능한 벤치마크의 존재가 향데의 자동 성능 최적화 및 테스트 생성을 위한 발전을 견인하는 데 필수적이라고 결론짓습니다.