강한 코딩 에이전트에는 MLE 하네스가 거의 필요 없다

무엇인가

자율 머신러닝 엔지니어링(MLE) 에이전트는 공개 리더보드에서 눈에 띄는 성적을 내왔다. 그 배경에는 '하네스'가 있다. LLM에 코드를 요청하고, 실행하고, 후보 해를 탐색·결합하는 바깥 프로그램이다. 장기 호흡에서 진전이 멈추고 단일 LLM 호출의 한계가 뚜렷하다는 이유로 하네스는 점점 정교해졌다. 탐색 트리, 프로그램 개체군, 메모리 계층, 전문화된 에이전트 팀이 차례로 추가됐다. 문제는 이 성능 향상을 하네스 설계 덕분이라고 귀속시킬 수 없다는 점이다. 표준 테스트베드인 MLE-bench에서 공개된 결과들은 거의 예외 없이 서로 다른 백본과 하드웨어에서 보고되고, 시드 수는 3을 넘기지 않으며, 헤드라인 격차가 실행 간 편차보다 작을 때도 있다. 재현 실험이 드문 것은 무관심이 아니라 비용 때문이다. 75개 과제에 3개 시드로 24시간 평가를 한 번 돌리는 데만 수천 GPU 시간이 든다.

어떻게 동작하나

이 논문은 OpenCode v1.15.6 코딩 에이전트 프레임워크 위에 자체 하네스를 세우고, 단일 코드베이스 안에서 개입군만 바꿔가며 사다리를 오른다. 개입군은 네 갈래다. 실행 환경, 검색 프리미티브, 자율성, 멀티에이전트 오케스트레이션이다. 각 개입은 특정 시스템의 변형이 아니라 해당 개입 '부류'의 가장 단순한 충실 버전으로 구현해, 효과가 구현 세부가 아니라 개입 부류에 귀속되게 했다. 작업 단위는 두 가지다. Chat은 단일 프롬프트로 완성된 해 스크립트를 텍스트로 받고, 실행에 실패하면 스택 트레이스를 붙여 다시 질의한다. Oneshot은 데이터가 있는 작업 디렉터리에서 시작하는 코딩 에이전트 세션 하나로, 파일시스템과 코드 실행 프리미티브를 자유롭게 써서 탐색·작성·실행·디버깅한다. 여기서 오케스트레이션을 아예 걷어낸 것이 Malena다. 전체 시간 예산을 하나의 세션으로 달리며, 턴이 끝날 때마다 짧게 계속 작업하라는 프롬프트만 받는다. 주변에는 최소 도구 세트만 둔다. 제출 파일을 레지스트리에 추가하는 submission 도구(테스트·리더보드 점수는 에이전트에게 전달되지 않는다), 현재 하드웨어 자원·사용률·남은 시간을 알려주는 system 도구, 백그라운드 bash 작업을 여러 개 돌리고 stdout을 따로 보고 완료를 기다리거나 취소할 수 있는 jobs 도구다.

무엇과 다른가

검색 프리미티브 ablation은 Oneshot 반복을 24시간 예산으로 연결해 비교했다. Chain(가장 최근 노드를 부모로 삼는 순수 반복 개선), Greedy(검증 점수 최고 노드를 부모로 삼는 순수 활용), UCB1(방문 횟수와 검증 점수에 상한신뢰구간 규칙을 적용한 탐색-활용 균형), Best-of-N(이전 정보 없이 독립적으로 다양한 시도)이다. 결과적으로 검색 전략의 효과는 매우 작았고 신뢰구간이 크게 겹쳤다. 과제별 짝지은 분석에서도 백분위나 메달률 어느 쪽에서도 통계적으로 유의한 우위가 없었다. 가장 격차가 큰 쌍은 Best-of-N과 UCB1인데, UCB1이 평균 2.71 백분위 포인트 앞섰고 95% 신뢰구간은 (-1.44, +6.60)이었다. Best-of-N의 자기선택 성능은 오라클 천장보다 6.832pp 낮았는데, 이는 실험한 검색 전략 중 가장 큰 선택 격차다. 저자들은 이 격차의 일부는 노이즈로 불가피하지만, 이를 줄이는 전략이 MLE 하네스 설계에서 우선순위가 되어야 한다고 적는다.

어떻게 쓰나

자율성 축에서는 Malena가 가장 높은 평균 메달률을 기록했다. 과제별 짝지은 분석에서 모든 수동 검색 알고리즘 대비 메달률 우위가 유의했고, 95% 신뢰구간 하한은 방법에 따라 0.4%에서 5.6% 사이다. 평균 백분위도 더 좋았지만 UCB1·Greedy와 비교하면 통계적으로 구분되지 않았다. Malena의 검증 격차는 1.876pp로 모든 반복 중 가장 낮았는데, 시도 사이에 동일한 검증 파이프라인을 재사용해 내부 검증 점수의 일관성이 트리 탐색 방식보다 높게 유지되기 때문으로 보인다. 멀티에이전트 오케스트레이션도 세 가지 개입으로 분리해 시험했다. 계층적 planner-executor 구조를 나타내는 Delegation, 같은 물리 머신에 독립 Malena 세 개를 띄우는 Parallelism, 병렬 실행과 함께 켜서 피어에게 메시지를 방송하는 broadcast 도구다. 기본 Malena는 어떤 개입보다도 유의하게 나쁘지 않았다. 병렬 추가는 오라클 선택 백분위에서 더 높은 천장을 주지만, 독립 Malena 반복들의 선택 격차가 그만큼 커져 최종 자기선택 제출물의 품질은 비슷해졌다.

전제와 한계

외부 시스템과의 비교도 같은 그림을 확인한다. MLEvolve, AiScientist, Arbor, ScienceFlow 네 오픈소스 최신 하네스와 Malena를 같은 컴퓨트 자원, 시간 예산, 백본에서 맞붙였다. MLE-bench 30개 과제에서 17개 하네스-백본 쌍, NatureBench 40개 과제에서 6개 쌍을 평가한 결과, Malena는 모든 쌍에서 모든 하네스를 따라잡거나 앞섰다. 유일한 예외는 더 작은 Gemma 4 31B 백본으로, 여기서는 MLEvolve가 평균 추정치에서 앞섰지만 메달률 신뢰구간은 여전히 Malena와 겹친다. GLM 5.2 기준으로 Malena는 대회의 62.5%에서 메달을 땄고, 테스트한 외부 하네스 중 최고는 47.1%였다. 비용도 보고된다. GLM 5.2에서 Malena의 모델링된 USD 비용은 12.12달러로 AiScientist의 1.95달러의 약 6.2배인데, 입력·출력 토큰량은 Arbor·AiScientist와 비슷하고 캐시 읽기 사용량만 약 한 자릿수 크다. Malena가 하나의 계속 커지는 세션으로 돌면서 매 턴 이전 컨텍스트 전체를 다시 보내기 때문이다. 다만 전체 비용은 하드웨어가 지배한다. 이 하드웨어 구성에서 A100 80GB 24시간은 제공자에 따라 24~85달러다.

트레이스 분석은 왜 그런지 설명한다. Malena는 과제의 자연스러운 단계를 아우르는 하나의 일반 파이프라인을 만든 뒤, 남은 시간을 파라미터 값이 아니라 코드 패치에 대한 하이퍼파라미터 탐색에 쓴다. 체크포인트와 유틸리티 코드(데이터 로딩, 전처리, 검증 분할)를 반복 사이에 재사용해 효율을 높이고 일반화 격차를 좁힌다. 체크포인트에 사용된 ML 기법을 라벨링해 보면, LLM 주도 탐색을 하는 Malena와 AiScientist는 초반에 데이터 전처리·피처 엔지니어링·아키텍처·학습 등 표준 파이프라인 단계에 고르게 분포하다가 후반으로 갈수록 앙상블과 의사 라벨링 같은 성능 지향 기법으로 쏠린다. 이 후반 이동은 Malena에서 더 뚜렷하고, 앙상블·모델 선택·후처리 비중이 실행 끝까지 증가한다. MLEvolve는 실행의 약 10% 이후 기법 분포가 거의 고정된다. 동시에 Malena는 기법 희귀도에서 MLEvolve와 함께 꾸준히 상위 두 방법에 들었다. 즉 성능 지향으로 기울면서도 비교적 드문 기법을 계속 제안한다.

개발자 입장에서 실무적 독해는 분명하다. 모델에 셸과 파일시스템을 주는 것이 측정된 단일 최대 효과이고, 그 위에 검색 트리나 멀티에이전트 조정 계층을 얹는 것은 현재 MLE 벤치마크에서 통계적으로 유의한 이득을 주지 않는다. 자율 MLE 파이프라인을 만들 때 먼저 확인할 것은 하네스 아키텍처가 아니라 백본의 에이전트 능력과 실행 환경(도구 접근, 파일 조작, 백그라운드 잡 관리)이다. 다만 저자들은 약한 백본에서는 수작업 워크플로 사전지식이 여전히 도움이 된다고 명시한다. Gemma 4 31B에서 MLEvolve가 평균 추정치로 앞선 것이 그 예다. 또한 단일 장기 세션은 컨텍스트가 계속 커져 캐시 읽기 비용이 커지므로, 비용을 보는 팀은 토큰 총량이 아니라 캐시 읽기 모델을 확인해야 한다.

저자들이 밝힌 한계는 네 가지다. 첫째, 대부분의 결과가 MLE-bench에 의존하는데 이 벤치마크는 과제 준비 문제가 알려져 있고 공개 Kaggle 대회로 만들어져 오염 가능성이 있다. 저자들은 문제 있는 과제를 고정하고 오염을 직접 점검하며 NatureBench를 추가 평가하는 방식으로 완화했다. 둘째, 통계적 검정력으로, 일부 결과는 효과 크기에 대한 강한 주장을 막을 만큼 신뢰구간이 넓다. 다만 '더 나쁘지 않다'는 약한 주장은 잘 뒷받침된다고 본다. 셋째, 범위 문제로, 테스트한 하네스 개입 대부분이 단일 워커 안에서 작동하며 정교한 에이전트 간 조정 프로토콜에 대한 심층 탐구는 향후 과제로 남긴다. 넷째, Malena와 비교 대상 외부 하네스 사이의 튜닝 노력 비대칭 가능성으로, 각 외부 하네스에 적용한 백본별 버그 수정과 설정 ablation을 부록에 문서화해 완화했다.