SWE-bench용 에이전틱 평가 확장

AI21 Maestro를 SWE-bench Verified에 적용하면서 20만 회 이상의 평가를 돌렸고, 그 과정에서 에이전틱 평가는 단순한 모델 테스트가 아니라 인프라 문제라는 점이 분명해졌다. 긴 실행, 분기, 상태 보존, 다중 seed 반복이 겹치면서 기존의 짧고 선형적인 평가 방식으로는 통계적 신뢰성을 확보하기 어려웠다.

핵심 난제는 세 가지였다. 첫째, throughput wall 때문에 수천 개의 멀티스텝 세션을 동시에 돌려야 했고, 둘째, 에이전트가 파일 시스템과 환경 상태를 바꾸는 만큼 격리(isolation) 가 필수였으며, 셋째, 2시간짜리 실행이 99% 지점에서 실패하면 막대한 토큰과 컴퓨팅이 사라지므로 resumability 가 필요했다.

처음에는 로컬 중심의 SWE-bench 전제를 그대로 Kubernetes에 옮겼지만, 곧 한계가 드러났다. pod마다 Hugging Face 캐시가 없어 동일한 파일을 반복 다운로드하면서 429 rate limit 이 발생했고, pod 안에서 docker run을 다시 띄우는 구조도 권한, 오버헤드, 자원 관리 측면에서 제대로 동작하지 않았다.

두 번째 시도에서는 기존 Docker 기반 평가를 최대한 유지한 채, Kubernetes pod 내부에서 매 실행마다 새 컨테이너를 만들도록 바꿨다. 하지만 약 500개 인스턴스에 대해 두 개 변형을 돌리고 duplicity를 4, 8, 16 수준으로 반복하자, 한 평가 창에서 약 1.6만 개의 Docker 컨테이너를 만들고 지우는 상황이 됐고, 자원 경합과 외부 rate limit 때문에 속도와 안정성이 모두 떨어졌다.

전환점은 각 run마다 무엇이 정말로 다른지, 무엇이 공유 가능한지를 다시 따져본 것이었다. 그 결과 평가 환경을 멀티테넌트 simulation environment 로 바꾸고, 인스턴스당 약 500개 pod를 한 번만 띄운 뒤 다음 자원을 공유하도록 재설계했다.

• repository: 올바른 commit으로 checkout
• MCP server: 명령 실행 준비 완료
• installed dependencies: run 간 유지

이 방식은 같은 SWE-bench 인스턴스를 대상으로 여러 run이 순차 또는 병렬로 돌아가도 충돌하지 않도록, MCP protocol 을 확장하고 격리용 MCP client를 별도로 만든 덕분에 가능했다. 그 결과 repo 다운로드와 pod provisioning 비용이 크게 줄었고 실패율도 눈에 띄게 낮아졌다.

실행 시간은 이제 인프라 오버헤드가 아니라 variant complexity 와 병렬성에 의해 결정된다. 경량 variant는 평균 3.5분, 보통 variant는 10분, 무거운 variant는 2시간 이상 걸릴 수 있지만, 현재는 최대 8K parallel runs 를 지원하므로 일반적인 variant의 전체 SWE-bench 평가는 약 20분이면 끝난다.

또한 generation 과 evaluation 을 분리해 두었기 때문에, 평가 단계에서 실패해도 patch 생성 결과는 보존된다. 테스트 러너 타임아웃이나 pod eviction이 나도 patch를 다시 만들 필요 없이 evaluation만 재실행하면 되고, 전체의 80% 만 먼저 끝나도 그 결과를 바로 분석할 수 있다.

최종적으로는 모든 평가에서 10,000 parallel runs SLA를 제공하고, 같은 pod에서 여러 executor를 돌리는 방식으로 10배 이상 더 키울 계획이다. 이렇게 하면 100,000개 컨테이너를 띄우지 않고도 하루 35,000개의 격리된 evaluation을 처리할 수 있어, 에이전트를 모델처럼 데이터와 속도로 반복 개선할 수 있다.