ScarfBench로 보는 엔터프라이즈 자바 마이그레이션과 AI 에이전트 평가

IBM Research가 Hugging Face 블로그를 통해 소개한 작업인 ScarfBench: Benchmarking AI Agents for Enterprise Java Framework Migration을 살펴보겠습니다. 원문은 제목 아래 링크로 연결해 두었습니다. 이 작업이 내세우는 주장은 한 문장으로 정리됩니다. 엔터프라이즈 자바의 프레임워크 마이그레이션처럼 파일과 모듈을 가로지르는 실제 작업을 기준으로 AI 에이전트를 평가해야 한다는 것입니다.

제가 확인할 수 있었던 출발점은 여기까지입니다. 제목이 가리키는 방향은 분명하지만, 개별 과제 구성이나 점수 산정 방식처럼 세부 내용은 이번 글에서 단정하지 않겠습니다. 그래서 오늘 글은 확정된 수치를 전달하는 요약이 아니라, 이 제목이 왜 나올 수밖에 없었는지, 그리고 이런 평가가 제대로 되려면 무엇을 봐야 하는지를 함께 정리하는 방식으로 쓰겠습니다. 자바 엔터프라이즈 현장에 익숙한 분에게는 익숙한 풍경이 나오고, 에이전트 평가에 관심 있는 분에게는 질문 목록이 남았으면 합니다.

마이그레이션 티켓 하나가 왜 이렇게 오래 남을까요

안녕하세요, 패트릭입니다. 팀마다 하나씩은 있는 티켓이 있습니다. 처음에는 버전 숫자 몇 개 올리는 일로 보였는데, 열어보니 손댈 곳이 끝없이 나오는 티켓 말이죠. 담당자는 바뀌고, 댓글은 길어지고, 나중에는 아무도 손대기 싫어하는 티켓이 됩니다.

제가 이 제목을 처음 봤을 때 떠오른 장면도 바로 그 티켓이었습니다. 엔터프라이즈 자바의 프레임워크 마이그레이션은 겉으로 보면 의존성 몇 줄 바꾸는 일처럼 보이는데요. 실제로는 패키지 이름이 바뀌고, 설정 파일 형식이 달라지고, 예전에 되던 관례가 조용히 깨지면서 여러 모듈이 함께 흔들립니다. 한 곳을 고치면 다른 곳에서 컴파일 오류가 나고, 그걸 고치면 이번에는 실행 시점에 전혀 다른 오류가 나타납니다.

그렇다면 이런 일을 왜 굳이 에이전트 평가의 무대로 삼을까요. 이유는 단순합니다. 짧은 코드 조각을 맞히는 시험으로는 실제 실력이 드러나지 않기 때문입니다. 마이그레이션은 읽고, 고치고, 돌려보고, 다시 고치는 과정 전체를 요구하는데, 이 과정이 바로 에이전트가 잘하는지 보고 싶은 대목과 겹칩니다. 저는 그래서 이 주제를 연구실 바깥의 문제라고 봅니다. 운영 중인 시스템을 다음 버전으로 옮기는 일이기 때문입니다.

자바 엔터프라이즈 이사는 집 이사보다 복잡합니다

집 이사는 짐을 싸서 옮기면 끝납니다. 그런데 엔터프라이즈 자바의 이사는 짐을 옮기는 동안 집의 구조도 바뀌는 일에 가깝습니다. 프레임워크가 바뀌면 코드를 담는 그릇의 모양이 달라지니까요. 예전에는 자동으로 연결되던 빈이 이제는 명시적인 설정을 요구하기도 하고, 어노테이션 하나가 다른 의미로 해석되기도 합니다.

여기서 자주 나오는 변화들을 떠올려보면 그림이 좀 더 분명해집니다. 패키지 경로가 javax에서 jakarta처럼 바뀌는 일, 빌드 스크립트에서 의존성 좌표가 바뀌는 일, XML로 쓰던 설정이 자바 코드나 다른 형식으로 옮겨가는 일, 서버가 기대하는 배포 구조가 달라지는 일이 한꺼번에 옵니다. 각각은 문서 한 페이지로 설명되지만, 실제 저장소에서는 수십 개 파일에 흩어져 있습니다. 그래서 작업자는 파일 하나하나를 여는 게 아니라, 변화의 패턴을 먼저 파악해야 합니다.

생각해보면 사람도 비슷하게 일합니다. 처음에는 변경 안내 문서를 읽고, 그다음에는 저장소에서 비슷한 용례를 찾고, 영향 범위를 가늠한 뒤에야 손을 댑니다. 이 과정을 건너뛰고 파일 몇 개만 고치면 나중에 반드시 되돌아옵니다. 마이그레이션이 어려운 이유는 코드 양 때문이 아니라, 이렇게 얽힌 관계를 한 번에 들고 있어야 하기 때문입니다. 에이전트에게도 같은 부담이 주어진다고 보면 됩니다.

텍스트가 비슷해 보이는 패치가 왜 컴파일을 통과하지 못할까요

여기서 재미있는 질문이 생깁니다. 사람이 고친 결과와 글자만 비슷하게 생긴 패치는 왜 실제 빌드에서 떨어질까요. 겉으로 보면 import 몇 줄만 다르고, 로직은 거의 같은데 말이죠. 답은 자바 엔터프라이즈 작업의 판정 기준이 글자의 유사도가 아니라는 데 있습니다.

이 세계에서 통하는 패치는 컴파일되고, 기존 테스트를 깨지 않으며, 가려둔 검증까지 통과하는 패치입니다. 글자가 90퍼센트 비슷해도 컴파일이 안 되면 소용이 없고, 반대로 글자는 꽤 달라 보여도 빌드와 테스트를 통과하면 좋은 패치일 수 있습니다. 마이그레이션에서는 특히 그렇습니다. 패키지 이동 하나를 놓치면 전체 모듈이 빨갛게 물들고, 설정 값 하나를 옛 형식으로 남기면 실행 시점에 조용히 오동작하니까요.

그래서 저는 텍스트 유사도만 보는 평가를 조심해서 봅니다. 그런 점수는 사람이 보기에는 그럴듯하지만, 시스템이 보기에는 다른 이야기일 때가 많기 때문입니다. 진짜로 궁금한 것은 패치가 저장소를 다시 동작하게 만들었는지이고, 그 질문에는 빌드를 돌려봐야 답이 나옵니다. 이런 의미에서 마이그레이션 벤치마크는 자연스럽게 기능 중심으로 기울 수밖에 없습니다. 돌아가는지를 묻는 쪽이, 비슷해 보이는지를 묻는 쪽보다 현장에 가깝기 때문입니다.

그렇다면 에이전트 평가는 어디서부터 다시 짜야 할까요

질문도 바뀌었습니다. 예전에는 좋은 답을 한 번에 내놓는지가 관심사였다면, 이제는 일을 끝까지 밀고 나가는지를 묻게 됩니다. 마이그레이션처럼 범위가 넓고 중간에 실패가 섞이는 작업을 두고, 에이전트가 어디까지 스스로 복구하는지가 실력이 되기 때문입니다.

제가 이 대목에서 가장 흥미롭게 본 부분은 평가의 순서가 뒤집힌다는 점입니다. 먼저 정답 패치를 정해두고 유사도를 재는 대신, 작업을 주고 결과를 실행해서 판정하는 방식이 어울립니다. 컴파일이 되는지, 기존 테스트가 깨지지 않는지, 숨겨둔 검증이 통과하는지처럼요. 이렇게 물으면 에이전트는 한 번의 출력으로 승부할 수 없고, 여러 단계에 걸쳐 상태를 관리해야 합니다.

물론 이런 평가는 비용이 듭니다. 환경을 띄워야 하고, 빌드 시간이 걸리고, 테스트가 불안정하면 판정도 흔들립니다. 그럼에도 불구하고 저는 이 비용을 감수할 가치가 있다고 봅니다. 저희가 새로운 AI 아키텍처를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 현장에서 어떤 비용 구조를 만드는지를 함께 보는데요. 마이그레이션 평가도 마찬가지입니다. 점수표보다 중요한 것은 그 점수가 어떤 고생 끝에 나왔는지입니다.

빌드 도구와 서버가 벤치마크에 들어와야 하는 이유

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. Maven이나 Gradle 같은 빌드 도구, 그리고 애플리케이션을 올리는 서버 환경을 평가에서 빼도 될까요. 저는 빼면 이야기가 너무 깨끗해진다고 봅니다. 엔터프라이즈 자바의 현실은 코드 바깥에 있기도 하기 때문입니다.

빌드 도구는 의존성을 어떻게 해석할지, 어떤 버전이 실제로 선택되는지, 멀티 모듈 사이에서 어떤 순서로 빌드할지를 정합니다. 같은 소스라도 빌드 설정에 따라 결과가 달라지죠. 애플리케이션 서버나 런타임은 또 다른 층입니다. 배포 기술자의 구조, 리소스 참조 방식, 설정 주입 순서 같은 것들이 실행 시점의 성패를 가릅니다. 코드만 고치고 빌드를 안 돌려본 마이그레이션이 위험한 이유가 여기에 있습니다.

그렇다면 벤치마크는 무엇을 담아야 할까요. 제 생각에는 최소한 멀티 모듈 구조와 빌드 스크립트, 그리고 실행 환경을 작업의 일부로 넣어야 합니다. 그래야 에이전트가 파일 내용뿐 아니라 프로젝트의 뼈대를 함께 다루게 되니까요. 이 대목은 귀찮지만 피할 수 없습니다. 현장의 마이그레이션 실패는 예쁜 자바 코드 한 줄보다, 지저분한 설정과 의존성의 틈에서 더 자주 터지기 때문입니다.

저장소 전체를 걸어다니는 능력이 따로 필요한 이유

앞에서 미뤄둔 이야기로 돌아올 차례입니다. 에이전트가 저장소를 탐색하는 일은 왜 따로 떼어 평가할 만할까요. 답은 마이그레이션의 단위가 파일이 아니라 저장소이기 때문입니다. 어디를 고쳐야 하는지 아는 것과, 어떻게 고쳐야 하는지 아는 것이 서로 다른 실력으로 갈립니다.

사람이 마이그레이션을 시작할 때 하는 일을 떠올려보죠. 먼저 변경 안내에서 패턴을 뽑고, 그 패턴이 저장소 어디에 퍼져 있는지 찾습니다. 같은 라이브러리를 쓰는 모듈이 몇 개인지, 설정이 중복된 곳은 어디인지, 테스트가 어떤 가정을 깔고 있는지 살핍니다. 이 탐색이 부실하면 고친 곳과 안 고친 곳이 섞이면서 나중에 깨집니다. 반대로 탐색이 탄탄하면 수정 자체는 비교적 기계적으로 이어집니다.

에이전트도 같은 관문을 지납니다. 넓은 문맥을 들고 있어야 하고, 파일 사이를 오가며 관련 조각을 모아야 하며, 어디까지가 영향 범위인지 스스로 그어야 합니다. 문제는 그다음입니다. 문맥이 길어질수록 기억은 흐려지고, 한 번 잘못 든 길은 다음 단계까지 영향을 줍니다. 저는 이 지점이야말로 프레임워크 마이그레이션이 에이전트에게 좋은 시험인 이유라고 봅니다. 답을 아는지가 아니라, 길을 잃지 않는지를 묻기 때문입니다.

도구를 쓰고 고치는 반복이 실력의 절반인 이유

같은 모델에 같은 질문을 던져도 결과가 크게 달라질 수 있다는 것을 현장에서는 경험으로 알고 있죠. 마이그레이션에서는 그 차이가 더 벌어집니다. 한 번에 맞히는 능력이 아니라, 틀린 뒤에 고치는 능력이 결과를 가르기 때문입니다.

작업 흐름을 머릿속에 그려보면 이렇습니다. 에이전트가 후보 수정을 만들고, 컴파일을 돌리고, 오류를 읽고, 범위를 좁혀 다시 고칩니다. 테스트가 깨지면 로그를 따라가 원인을 찾고, 설정 문제인지 코드 문제인지 가려냅니다. 이 반복을 몇 번 돌 수 있는지, 매번 같은 실수를 반복하지 않는지, 로그를 제대로 읽는지에서 성패가 갈립니다. 일종의 오답 노트처럼요. 틀린 이유를 다음 시도에 반영하는 쪽이 결국 통과합니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 도구를 많이 쓴다고 항상 좋은 것은 아니기 때문입니다. 빌드를 무작정 반복하면서 우연히 통과하기를 바라는 것과, 오류 메시지를 읽고 가설을 좁혀가는 것은 전혀 다른 행동입니다. 제가 앞으로 보고 싶은 것은 바로 이 구분입니다. 도구 호출 횟수가 아니라, 호출 사이에 생각이 있었는지를 보는 평가 말이죠. 통과 여부만 보면 둘 다 통과로 찍히지만, 현장에서 함께 일하고 싶은 쪽은 분명 후자입니다.

제가 이 제목에서 조심스럽게 읽는 대목이 있습니다

여기까지 읽고 이런 반문이 들릴 것 같습니다. 제목만으로 이렇게까지 이야기해도 될까요. 정당한 지적입니다. 그래서 이 대목에서는 제가 단정하지 않는 범위를 분명히 적어두겠습니다.

제가 확인한 사실은 제목 자체와 IBM Research가 Hugging Face 블로그에서 소개했다는 점까지입니다. 개별 과제가 몇 개인지, 어떤 프레임워크 쌍을 다루는지, 어떤 모델을 돌려봤는지, 점수가 어땠는지는 제가 가진 자료만으로는 말할 수 없습니다. 이런 상황에서 점수를 인용하거나 순위를 매기는 것은 읽는 분을 돕는 일이 아니라 오히려 헷갈리게 하는 일이라고 봅니다.

그렇다면 이 글에 남은 가치는 무엇일까요. 저는 제목이 가리키는 문제의식 자체가 이미 검토할 만하다고 봅니다. 엔터프라이즈 현장의 일을 벤치마크로 가져오겠다는 선택, 텍스트 유사도가 아니라 실행 결과로 판정하겠다는 방향, 저장소와 빌드와 서버를 함께 보겠다는 태도는 그 자체로 논의할 거리가 되니까요. 다만 어디까지가 확인된 사실이고 어디부터가 일반적인 배경과 제 해석인지는 구분해서 읽어주셨으면 합니다. 이 구분이 있어야 다음에 세부 내용이 공개됐을 때 오늘 이야기가 제대로 검증될 수 있습니다.

숫자보다 먼저 물어야 하는 질문들이 있습니다

좋은 건 알겠는데, 이걸 실제로 어떻게 믿을까요. 벤치마크 숫자가 나왔을 때 제가 먼저 던지는 질문들을 적어봅니다. 이런 질문이 있어야 점수가 현장의 언어로 번역되기 때문입니다.

먼저 무엇을 맞췄는지보다 무엇을 통과했는지를 봅니다. 컴파일 성공인지, 기존 테스트 유지인지, 가려둔 검증 통과인지가 서로 다른 난이도이니까요. 컴파일만 통과한 것과 숨은 검증까지 통과한 것은 같은 통과가 아닙니다. 다음으로는 작업의 범위를 봅니다. 단일 모듈 안에서 끝난 일인지, 여러 모듈과 설정을 가로지른 일인지에 따라 점수의 무게가 달라집니다. 마이그레이션이라는 이름이 붙었다면 후자를 본 것이겠죠.

또 하나는 실행 조건입니다. 어떤 빌드 환경에서, 어떤 시간 제한과 도구 허용 범위 안에서, 몇 번의 시도 끝에 나온 결과인지가 실력을 가릅니다. 무제한 시도 끝에 간신히 통과한 것과, 몇 번의 고침 만에 안정적으로 통과한 것은 다른 이야기입니다. 마지막으로는 흔들림을 봅니다. 같은 작업을 다시 시켰을 때 결과가 얼마나 달라지는지, 사소한 순서 변경에도 깨지는지가 궁금합니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 점수는 한 장면이지만, 구조는 다음 현장을 버티게 하니까요.

프레임워크 이사가 남기는 진짜 숙제는 무엇일까요

그렇다면 사람의 역할은 무엇일까요. 에이전트가 마이그레이션을 잘하게 되면 사람은 편해질까요, 아니면 다른 일을 떠맡게 될까요. 저는 후자에 가깝다고 봅니다. 기계가 옮기는 짐이 늘어나면, 사람은 무엇을 옮기고 무엇을 버릴지를 정하는 쪽으로 이동하기 때문입니다.

마이그레이션에는 늘 판단이 끼어 있습니다. 더 이상 쓰지 않는 모듈을 이번 기회에 걷어낼지, 깨지기 쉬운 테스트를 고쳐둘지, 설정 중복을 정리할지 같은 결정이죠. 이런 결정은 빌드 로그에 나오지 않습니다. 팀의 역사와 앞으로의 운영 방향을 알아야 내릴 수 있습니다. 에이전트가 패치를 잘 만들수록, 오히려 이런 판단의 비중이 커집니다. 손이 가벼워진 만큼 머리 쓸 일이 또렷해지는 셈입니다.

그래서 제가 이 주제에서 끝까지 들고 가고 싶은 문장은 이것입니다. 평가는 에이전트를 줄 세우기 위해서가 아니라, 어디까지 맡길 수 있는지를 알기 위해서 필요합니다. 마이그레이션 벤치마크가 잘 만들어지면 팀은 감으로 맡기던 일을 근거를 가지고 나누게 됩니다. 기계가 반복을 맡고, 사람이 방향을 맡는 나누기 말이죠. 다음 세부 내용이 공개되면 그때는 오늘 적어둔 질문들을 하나씩 대조해 보겠습니다. 그 대조가 맞아떨어지는지 확인하는 일이야말로 이 글을 쓴 보람일 것 같습니다.