IBM과 Kaggle, ScarfBench 마이그레이션 상시 갱신 리더보드 구축 위해 협력

2026년 10월 27일 공개된 IBM Research 기술 노트에 따르면, IBM과 Kaggle은 기업용 Java 프레임워크 마이그레이션에서 코딩 에이전트를 평가하기 위한 IBM의 오픈 벤치마크 ScarfBench의 공개 리더보드를 상시 갱신하는 데 협력하고 있다.

ScarfBench는 Self-Contained Application Refactoring Benchmark의 약자로, 에이전트가 익숙하지 않은 기업용 Java 애플리케이션을 Jakarta EE, Quarkus, Spring 프레임워크 간에 마이그레이션한 뒤에도 정상 작동하는 소프트웨어를 남길 수 있는지 평가한다. 벤치마크는 특정 작업을 집중적으로 다루는 워크로드와 전체 애플리케이션을 모두 활용해, 생성된 애플리케이션이 빌드되고 실행되며 예상대로 계속 동작하는지 확인한다. IBM은 AI 기반 마이그레이션을 위한 재현 가능한 벤치마크로 2026년 초 ScarfBench를 공개했다. 2026년 3월 11일자 최초 발표에서는 개발자가 검증한 세 프레임워크의 기업용 애플리케이션, 영속성 동작과 의존성 주입 같은 요소를 분리해 다루는 집중 워크로드, 여러 아키텍처 계층을 결합한 전체 애플리케이션, 자동화된 빌드 및 시작 검증, 런타임 동작과 기능적 동등성을 확인하는 동작 테스트 등 일곱 가지 구성 요소를 소개했다. 해당 발표에 따르면, 각 워크로드는 기능적 동등성과 프레임워크의 관용적 사용 여부를 확인하기 위해 숙련된 개발자가 직접 구현하고 검증했다.

IBM과 Kaggle의 협력

이번 협력에 따라 Kaggle은 벤치마크와 평가 설계에 대해 IBM에 자문했고, 컴퓨팅 자원을 지원하면서 자체 플랫폼에서 ScarfBench를 독립적으로 재현해 실행했으며, 앞으로 장기적으로 벤치마크를 관리할 예정이다. IBM은 두 팀의 강점이 서로 보완적이라고 설명했다. IBM은 기업용 Java 현대화에 초점을 맞춰 ScarfBench를 개발했고, Kaggle은 독립적인 평가 인프라와 지속적인 리더보드 관리를 제공한다.

마이그레이션 작업 204건의 결과

ScarfBench는 언어 모델만 따로 평가하는 것이 아니라 에이전트 시스템을 평가한다. 각 결과는 모델이 저장소 및 개발 환경과 상호작용하는 방식을 결정하는 코딩 에이전트 하네스와 모델을 짝지어 평가한 결과다. IBM은 점수를 기반 모델만의 성능 측정치가 아니라 모델과 하네스의 조합에 따른 결과로 해석해야 한다고 당부했다.

IBM에 따르면, 마이그레이션 작업 204건과 평가 대상 모델·하네스 구성 10개를 비교한 결과, Antigravity 하네스를 사용한 Gemini 4 Argon이 주요 스모크 테스트 지표에서 75.2%로 1위를 차지했다. 그 뒤를 Claude Opus 5.5와 Claude Code 조합이 70.5%, Claude Opus 5와 Claude Code 조합이 69.8%로 이었다. 리더보드 지표로 사용되는 스모크 점수는 부분 점수를 인정하며, 테스트 스위트가 클수록 더 높은 가중치를 부여한다. 모든 테스트를 통과했는지를 따지는 더 엄격한 기준에서는 Claude Opus 5.5와 Claude Code 조합이 72.1%로 가장 높은 통과율을 기록했으며, Antigravity를 사용한 Gemini 4 Argon 조합이 71.1%로 근소한 차이를 보였다.

게시물에 따르면 민감도 분석에서도 상위 순위는 그대로 유지됐다. 전체 작업 204건 중 4건은 모든 구성에서 동작 테스트 점수가 0점이었다. 이 작업들을 제외하자 절대 점수는 상승했지만 선두 그룹은 바뀌지 않았다. Gemini 4 Argon과 Antigravity 조합이 79.4%를 기록했고, Claude Opus 5.5와 Claude Code 조합이 74.5%, Claude Opus 5와 Claude Code 조합이 73.7%로 뒤를 이었다. IBM은 가장 성능이 좋은 조합도 개선 여지가 상당하다며, 어떤 구성도 마이그레이션 작업의 약 4분의 3을 넘는 비율로 완전히 통과하지는 못했다고 밝혔다.

구성별 성공과 실패 양상

IBM에 따르면, 이번 평가에서 가장 큰 격차는 빌드되는 코드와 올바르게 동작하는 소프트웨어 사이에서 나타났다. 점수가 모두 0점인 작업 4건을 제외한 뒤 Claude Opus 5와 Claude Code, Gemini 4 Argon과 Antigravity, Gemini 3.8 Flash와 mini-swe 조합은 각각 작업의 100%를 컴파일했다. 또한 10개 구성 중 8개는 최소 97%를 컴파일했다. 반면 스모크 테스트 점수의 격차는 50포인트를 넘었다. 배포에 성공한 애플리케이션만 놓고 보면, 선두 구성들의 테스트 완전 통과율은 약 63~76%에 모여 있었다. Kimi K3와 kimi-code 조합의 통과율은 53%였고, Gemini 3.1 Pro와 OpenHands 조합은 42%, Gemma 4 26B-A4B와 mini-swe 조합은 26%에 그쳤다.

IBM은 실패한 실행 745건을 분류했다. 이 중 535건, 약 72%는 런타임 동작 실패였다. 이러한 경우 애플리케이션은 빌드되고 종종 부팅까지 됐지만 동작 검증에는 실패했다. 이 유형에는 콘텐츠 또는 단언문 불일치 304건, 경로 누락 또는 404 오류 210건, 명시적인 HTTP 500 또는 405 오류 21건이 포함됐다. 컴파일 또는 패키징 실패는 152건으로 전체 실패 실행의 약 20%를 차지했으며, 부팅 또는 의존성 주입 중 충돌은 58건으로 약 8%였다.

게시물에는 작업별 사례도 소개돼 있다. concurrency-taskcreator-quarkus-to-jakarta 작업에서 Claude Opus 5와 Claude Code 조합은 /taskinfo 엔드포인트가 “File not found”를 반환하고 HTTP 405를 예상한 테스트가 실패해 0/6점을 받았다. address-book-jakarta-to-quarkus 작업에서는 GPT-6 Astra와 Codex 조합이 목록 페이지와 생성 페이지에서 HTTP 404 오류가 발생한 뒤 2/10점을 기록했다. cargotracker-jakarta-to-spring 작업에서 Gemini 3.8 Flash와 mini-swe 조합은 Spring Boot 대상으로 마이그레이션한 뒤에도 JSF/JoinFaces 연결 구성을 그대로 유지했고, 시작 과정에서 facesContext 빈을 생성하다 실패했다. cart-spring-to-jakarta 작업에서는 마이그레이션 후 남은 패키징 유형이 대상 Liberty 런타임에서 지원되지 않아 GPT-6 Astra와 Codex 조합의 배포가 실패했다.

IBM은 구성에 따라서도 효율성이 달랐다고 밝혔습니다. 민감도 분석에서 제외한 뒤 남은 200개 작업의 중앙값 턴 수는 Claude Code를 사용한 Claude Opus 5의 32회부터 mini-swe를 사용한 Gemini 3.8 Flash의 79회까지였으며, Claude Code를 사용한 Claude Opus 5.5는 64회였습니다. Claude Code, Codex, mini-swe, kimi-code 설정에서 비용을 보고한 경우, 작업당 해결 비용은 Codex를 사용한 GPT-6.1 Sol의 1.25달러부터 Claude Code를 사용한 Claude Opus 5.5의 10.10달러까지였습니다. Antigravity, qwen-code, OpenHands 하네스는 실행별 비용 수치를 제공하지 않았습니다.

ScarfBench 리더보드는 이러한 결과를 공개적으로 확인할 수 있는 창구입니다. 출시 시점에는 공개 모델 제출이 지원되지 않지만, IBM은 이를 향후 계획에 포함했다고 밝혔습니다.