기술 요약: SCARFBENCH

문제 정의

엔터프라이즈 자바는 소프트웨어 인프라에서 여전히 지배적인 세력으로 남아 있으며, 많은 애플리케이션이 원래의 아키텍처 가정을 훨씬 초과하여 수명을 유지하고 있습니다. 현대화는 주로 폐기 압력과 메모리 오버헤드 감소 및 클라우드 탄력성 향상과 같은 비기능적 목표에 의해 주도되지만, 이러한 애플리케이션을 프레임워크 간 (특히 Spring, Jakarta EE, Quarkus 사이) 이동시키는 것은 복잡하고 위험이 큰 작업입니다.

현재의 소프트웨어 엔지니어링 벤치마크는 주로 고정된 프레임워크 스택 내에서 버그 수정, 기능 구현, 또는 언어 버전 업그레이드를 평가합니다. 이들은 주로 로컬 API 대체 이상의 작업을 요구하는 프레임워크 간 애플리케이션 리팩토링을 측정하는 데 실패합니다. 성공적인 마이그레이션은 애플리케이션 동작을 보존하기 위해 빌드 구성, 의존성 주입, 영속성, 요청 처리, 배포에 걸쳐 조정된 변경이 필요합니다. 기존 벤치마크는 종종 underlying 프로그래밍 모델을 보존하는 것만으로도 충분하다고 가정하는데, 이는 실행 모델과 관습이 상이한 프레임워크 간 이동 시 성립하지 않는 가정입니다.

방법론: SCARFBENCH

저자들은 대규모 언어 모델 (LLM) 에이전트가 동작 보존형 프레임워크 간 마이그레이션을 수행하는 능력을 평가하도록 설계된 벤치마크인 SCARFBENCH(Self-Contained Application Refactoring Benchmark) 를 소개합니다.

벤치마크 구성

• 범위: 이 벤치마크는 Spring Boot, Jakarta EE, Quarkus 세 가지 프레임워크로 구현된 34 개의 애플리케이션 패밀리로 구성됩니다.
• 구조: 두 가지 티어로 나뉩니다:
  1. 집중 티어 (Focused Tier): 자바 사양 요청 (JSR) 에 기반하여 의존성 주입, 영속성, 프레젠테이션, 인프라, 비즈니스 도메인과 같은 특정 아키텍처 계층을 분리한 29 개의 자체 완성형 애플리케이션.
  2. 전체 애플리케이션 티어 (Whole-Application Tier): 이러한 계층들을 결합하여 계층 간 결합과 엔드 - 투 - 엔드 워크플로우를 테스트하는 5 개의 더 크고 현실적인 오픈소스 시스템.
• 변형: 이러한 애플리케이션들은 1,946 개의 소스 및 테스트 파일에 걸쳐 약 151K 줄의 짝을 이룬 자바 코드로 구성된 102 개의 프레임워크별 변형을 생성합니다.
• 작업: 벤치마크는 204 개의 지시된 마이그레이션 작업 (예: Spring $\to$ Jakarta, Jakarta $\to$ Quarkus) 을 정의합니다. 각 작업은 에이전트가 소스 동작을 보존하는 타겟 구현을 생성하도록 요구합니다.
• 그라운드 트루스: 모든 애플리케이션 패밀리에 대해 세 가지 프레임워크 변형을 전문가 자바 개발자가 수동으로 구현하여, 검증 가능한 행동적으로 동등한 구현이 존재하도록 보장했습니다.

평가 프로토콜

• 에이전트: 다섯 가지 최첨단 코딩 에이전트가 평가되었습니다: Claude Code (Opus 4.6), Gemini CLI (Gemini-3.1 Pro), Codex (GPT-5.4), Opencode (GLM-5.1), Qwen CLI (Qwen3.5-397B-A17B).
• 실행 하네스: 컨테이너화된 하네스가 다음 세 단계로 후보를 평가합니다:
  1. 컴파일: 후보가 성공적으로 빌드되어야 합니다.
  2. 배포: 애플리케이션이 컨테이너화된 런타임 내에서 시작되어 준비 상태 신호를 발신해야 합니다.
  3. 행동 테스트: 후보는 1,331 개의 전문가 작성 행동 테스트 세트를 통과해야 합니다.
• 오라클: 정확성은 프레임워크 중립적 행동 오라클에 의해 결정됩니다. 마이그레이션 자체가 필요한 유닛 테스트 대신, 오라클은 Playwright/pytest 스크립트로 구체화된 Gherkin 명세를 사용합니다. 이러한 테스트는 HTTP 라우트, 응답 페이로드, UI 흐름, 영속 상태 변경과 같은 외부적으로 관찰 가능한 동등성을 검증합니다.
• 지표: 성공은 온도 0 에서의 pass@1 로 측정되며, 후보가 컴파일, 배포를 수행하고 행동 테스트의 100% 를 통과해야 합니다.

주요 기여

1. SCARFBENCH 데이터셋: 컨테이너화된 환경에서 1,331 개의 전문가 작성 행동 테스트로 검증된 102 개의 변형과 204 개의 지시된 마이그레이션 작업을 생성하는 34 개의 애플리케이션 패밀리로 구성된 큐레이션된 코퍼스.
2. 실증적 평가: 시스템 수준 변환에 대한 현재 능력의 상당한 격차를 드러내는 다섯 가지 최전선 코딩 에이전트에 대한 종합적 평가.
3. 실패 분류: 실패한 트레이스의 전문가 심의에서 도출된 빌드, 배포, 테스트 단계를 아우르는 13 가지 반복적 실패 범주의 분류.

실험 결과

평가 결과, 동작 보존형 프레임워크 마이그레이션은 현재 에이전트들에게 여전히 큰 과제로 남아 있음이 드러났습니다:

• 낮은 성공률: 가장 강력한 에이전트 (Opus 4.6 을 사용한 Claude Code) 는 집중 계층 마이그레이션에서 **15.3%**의 집계 테스트 통과율을 달성했고, 전체 애플리케이션에서는 **12.2%**를 달성했습니다. 204 개의 지시된 모든 작업 중 에이전트가 생성한 마이그레이션 중 오직 하나만이 전체 테스트 세트를 통과했습니다.
• 빌드/배포 vs 행동: 표면적 성공과 행동적 정확성 사이에는 극명한 단절이 존재합니다. 에이전트들은 종종 컴파일되고 배포되지만 행동 테스트를 통과하지 못하는 코드를 생성합니다. 예를 들어, 전체 애플리케이션 마이그레이션에서 컴파일 성공률은 87% 에 달할 수 있지만 행동적 성공률은 12% 로 떨어집니다.
• 비대칭적 난이도: 마이그레이션 난이도는 타겟 프레임워크에 크게 의존합니다:
  • Spring $\leftrightarrow$ Quarkus: 가장 해결 가능한 쌍.
  • Jakarta EE 타겟: 가장 어렵습니다. Jakarta EE 를 타겟으로 하는 마이그레이션 중 행동 테스트를 통과한 것은 **2%**에 불과하며, 57% 는 컴파일 게이트에서 실패했습니다.
• 프롬프트 엔지니어링: "기술 기반" 프롬프팅 (모듈화된 안내) 은 컴파일 및 배포율을 향상시켰으며, 특히 집중 작업에서 그랬지만, 전체 애플리케이션의 행동적 정확성 격차를 크게 좁히지는 못했습니다.

실패 분석

실패한 작업에 대한 분석은 오류가 소스 수준 번역을 넘어선다는 것을 확인시켰습니다. 일반적인 실패 양상은 다음과 같습니다:

• 빌드 단계: 의존성 해결 문제, 구식 모듈 참조, 프로젝트 구조 불일치.
• 배포 단계: 리소스/아티팩트 불일치 (예: WAR 대 JAR 패키징), 잘못된 런타임 구성 (예: 포트 불일치), 손상된 의존성 와이어링.
• 테스트 단계: 누락된 엔드포인트, 잘못된 응답 내용, 인프라 연결 문제.
  저자들은 Jakarta 를 타겟으로 한 마이그레이션이 빌드 게이트에서 불균형적으로 실패한다고 지적하며, 이는 학습된 프레임워크 관습과 Jakarta 의 패키징/서버 구성 관습 사이의 괴리를 시사합니다.

중요성 및 주장

이 논문은 현재 에이전트들이 소스 수준에서 프레임워크 API 를 신뢰할 수 있게 번역할 수는 있지만, 타겟 프레임워크의 런타임 모델을 통해 애플리케이션 동작을 재표현하는 데는 어려움을 겪는다고 주장합니다. 결과는 버그 수정이나 버전 업그레이드와 같은 저장소 수준 벤치마크에서의 진전이 타겟 런타임에서 실행되어야 하는 시스템 수준 변환으로 깔끔하게 이전되지 않음을 시사합니다.

저자들은 SCARFBENCH 를 현실적인 엔터프라이즈 시나리오에서 LLM 의 "에이전트" 능력을 평가하기 위한 필수적인 단계로 위치시키며, 진정한 현대화는 단순한 구문 대체를 넘어선다고 강조합니다. 이는 아키텍처 결합, 구성 의미론, 그리고 행동 보존에 대한 깊은 이해를 요구합니다. 벤치마크, 하네스, 에이전트 트레이스는 자동화된 소프트웨어 현대화에 대한 추가 연구를 촉진하기 위해 공개되었습니다.