MILO는 AI 에이전트의 '하네스'를, 사람이 손으로 튜닝하는 대신 자동으로 찾아내는 프레임워크다. 한 발 더 나아가, 하네스를 찾는 탐색 전략 그 자체도 함께 진화시킨다는 점이 이 논문의 핵심이다. Terminal-Bench 2.1, PaperBench, DeepSWE 세 가지 긴 호흡의 작업(long-horizon) 벤치마크에서, MILO가 발견한 하네스는 기존의 잘 만들어진 하네스 8종과 탐색 기법 6종을 모두 앞섰다.
요즘 AI 에이전트는 두 부분으로 나눌 수 있다. 하나는 모델(LLM) 자체이고, 다른 하나는 그 모델을 감싸는 하네스(harness)다. 하네스는 모델이 제안한 행동을 실제 환경에서 실행하고, 프롬프트와 도구, 문맥, 메모리 같은 발판(scaffolding)과 제어 흐름을 관리하는 소프트웨어 층이다. 서브에이전트를 띄울지, 도구 호출을 가로챌지, 결과를 검증할지, 언제 작업을 멈출지를 정하는 쪽이 바로 하네스다.
흥미로운 사실은, 같은 모델이라도 하네스가 바뀌면 성적이 크게 달라진다는 점이다. 논문이 인용한 예(Merrill et al., 2026)를 보면, Terminal-Bench에서 GPT-5는 Terminus 2 하네스로는 35.2%를 풀지만 Codex 하네스로는 49.6%를 풀고, 그러면서 토큰은 35% 덜 쓴다. 모델을 바꾼 게 아니라 틀만 바꿨는데 이 차이가 난다.
여기서 문제가 생긴다. 좋은 하네스를 만드는 일은 지금도 장인의 수작업에 가깝다. Claude Code나 Codex 같은 상용 하네스는 팀이 몇 달을 들여 만든다. 엔지니어가 실패 사례를 들여다보고, 휴리스틱을 손보고, 몇 안 되는 설계를 반복해서 다듬는 식이다. 게다가 하네스는 모델마다 다르다. 어떤 모델에 맞춘 하네스가 다른 모델에는 어울리지 않아, 모델이 바뀔 때마다 처음부터 다시 튜닝해야 한다. 이 반복 노동을 자동화하자는 것이 자동 하네스 발견(AHD, automated harness discovery)이다.
AHD는 보통 LLM 기반 진화 탐색(evolutionary search)으로 풀린다. LLM 변이기(mutator)가 새 하네스를 제안하고, 채점기가 점수를 매기고, 그 결과가 다음 라운드를 이끄는 반복 루프다. 그런데 논문은 기존 방식에 네 가지 약점이 있다고 지적한다.
MILO(Meta-evolutionary Island Orchestration)의 발상은, 하네스만 진화시키지 말고 '하네스를 찾는 방법'까지 같이 진화시키자는 것이다. 이걸 여러 독립 연구팀을 운영하는 조직에 빗대면 이해가 쉽다.
먼저 섬(island) 구조다. 각 섬은 서로 다른 초기 하네스(씨앗)에서 출발해 격리된 채 자란다. 섬마다 전담 변이기 에이전트가 붙어 있어, 그 변이기 특유의 편향은 그 섬 안에만 갇힌다. 섬끼리는 성공한 아이디어를 주고받지만, 생존을 걸고 경쟁하지는 않는다. 이 설계 덕분에 가장 약해 보였던 씨앗에서 오히려 최고의 하네스가 나오기도 한다. 당장 성적이 나쁘다는 이유로 팀을 해체하지 않으니, 느리게 꽃피는 방향이 살아남는 셈이다.
둘째, 계층적 혈통 메모리(hierarchical lineage memory)다. 씨앗에서 후보까지 이어지는 경로를 거절된 후보까지 포함해 전부 트리로 기록한다. 성공한 편집은 무엇이 통했는지 알려주고, 실패한 편집은 그 방향을 가지치기해서 더 과감한 구조적 변화 쪽으로 탐색을 밀어낸다. 실패를 음성 증거(negative evidence)로 쓴다는 점이 영리하다. 몇 시간짜리 채점을 한 번 날린 대가를, 적어도 '거긴 가지 마라'는 정보로 회수하는 것이다.
셋째, 변이기 에이전트는 프롬프트 몇 줄만 고치는 게 아니라 하네스 전체를 다시 쓴다. 이때 전역 탐색 기록과 부모 하네스의 실패 트레이스(failure trace), 그리고 그 부모의 약점에 대한 피드백을 같이 참고한다.
넷째, 오케스트레이터(orchestrator) 에이전트가 바깥 루프에서 전략을 조율한다. 어느 섬이 정체되면 그 섬을 진단해 변이기를 교체하고, 메모리를 손보고, 커리큘럼(어떤 과제로 평가할지)을 고쳐 쓴다. 혈통을 접붙이거나(grafting) 갈래를 나누는(speciation) 일도 오케스트레이터 몫이다. 말하자면 각 팀은 자기 방식대로 연구하고, 연구소장이 멈춰 선 팀의 접근법 자체를 재편하는 구조다.
전체 흐름은 안쪽 루프와 바깥쪽 루프로 돈다. 안쪽에서는 섬의 합격 후보 중 부모를 뽑고, 변이기가 실패 트레이스와 혈통 메모리를 근거로 하네스를 통째로 새로 쓰고, 그 자식을 채점한다. 이때 자식은 정확도, 토큰, 지연 시간 세 축의 파레토 경계(Pareto frontier)를 앞당길 때만 합격한다. 다만 비용이 늘어도 그 자체로 탈락하는 것은 아니다. 논문 §4.2에 따르면 정확도 차이가 허용오차(ε)를 넘으면 정확도가 높은 쪽을 택하고, 정확도가 엇비슷할(ε 이내) 때에만 토큰·지연이 적은 쪽을 고른다. 비용은 정확도가 비슷할 때 작동하는 결정 기준인 셈이다. 진행이 막히면 바깥 루프의 오케스트레이터가 개입한다.
성과는 Opus 4.8(프런티어 모델)과 gpt-oss-120b(오픈 웨이트 모델) 두 종류 백본에서 측정됐다. 아래 수치는 Opus 4.8 기준이다.
| 벤치마크 | MILO의 초기 하네스 대비 향상 | 기존 탐색법 최고 향상 |
|---|---|---|
| Terminal-Bench 2.1 | +12.0% | +4.5% (GEPA) |
| PaperBench | +28.3% | +18.3% (Meta-Harness) |
| DeepSWE | +10.3% | 0% (향상 없음) |
세 벤치마크 모두에서 MILO가 기존 최고 탐색법을 앞섰고, 특히 DeepSWE에서는 기존 방식이 초기 하네스 대비 한 걸음도 못 나아간 반면 MILO는 10.3%를 끌어올렸다.
절대 성적도 의미가 있다. Terminal-Bench 2.1에서 MILO는 86.1 ± 2.0%를 기록해, 공식 리더보드 1위(83.8 ± 2.3%)를 넘어섰다. 그러면서 초기 하네스보다 토큰을 26% 적게 썼다. 정확도와 비용이 동시에 좋아진 결과인데, 파레토 다목표 기준으로 후보를 거른 설계가 실제로 작동했다는 증거로 읽힌다.
MILO는 하네스 같은 전략 수준(strategy-level) 발견만이 아니라, 단일 문제를 깊게 파는 instance-level 탐색에도 쓸 수 있다. 논문은 EinsteinArena의 미해결 수학 문제에서 알려진 최선의 상계(upper bound)를 더 조인 사례를 든다. 에르되시 최소 겹침(Erdős minimum-overlap)은 0.3808586에서 0.3808568로, 첫 번째 자기상관 부등식은 1.50274365에서 1.50274360으로, 세 번째 자기상관 부등식은 1.45081에서 1.44889로 낮췄다. 수치만 보면 미세하지만, 열려 있던 문제의 기록을 실제로 갱신했다는 사실 자체가 포인트다.
솔직히 짚을 지점이 있다. 먼저 비용이다. 하네스 하나 채점에 몇 시간이 걸린다는 전제 위에 섬 여러 개와 오케스트레이터까지 돌리는 구조이니, MILO를 돌리는 데 드는 총 연산량이 결코 작지 않다. 논문이 토큰 효율(초기 하네스 대비 26% 절감)을 말하는 건 '발견된 하네스의 운영 비용'이지, 'MILO 탐색 자체의 비용'과는 구분해서 봐야 한다.
둘째, 결과의 범위다. 위 수치는 특정 벤치마크와 특정 모델(Opus 4.8, gpt-oss-120b)에서 나온 것이다. 하네스가 원래 모델마다 다시 튜닝돼야 하는 물건인 만큼, 다른 모델·다른 과제 분포에서도 같은 폭의 이득이 재현될지는 이 초록만으로 단정하기 어렵다.
셋째, 수학 기록 갱신은 값으로 보면 아주 작다. 방법의 일반성을 보여주는 사례로는 설득력이 있지만, 실용적 임팩트의 크기와는 다른 이야기다.
넷째, 재현성과 운영 안정성이다. 변이기와 오케스트레이터가 모두 에이전트(LLM)인 만큼, 탐색이 얼마나 안정적으로 수렴하는지, 운이 나쁜 실행에서 어떻게 되는지는 본문 세부를 더 봐야 판단할 수 있다.
온틀은 고객 프로젝트마다 AI PM을 파견해 요청 접수에서 서비스 노출까지 관리하는 구조다. 그 PM이 일하는 방식, 즉 '어떤 순서로 접수·검토·진행하고, 어떤 도구를 언제 쓰고, 언제 멈추고 사람에게 결정을 넘길지'를 정해둔 규칙 묶음이 사실상 하네스에 해당한다.
한 장면을 끝까지 따라가 보자. 새 고객이 들어와, 예전 고객들과는 전혀 다른 성격의 연동 작업을 맡겼다고 하자. 지금 방식이라면 담당자가 기존 PM 플로우를 그대로 얹어 돌려보고, 중간에 PM이 엉뚱한 데서 멈추거나 토큰을 과하게 쓰는 걸 보고 나서야 프롬프트와 분기 규칙을 손으로 고친다. 이 수정은 그 고객, 그 모델에 맞춘 땜질이라 다음 고객에겐 다시 처음부터다.
MILO식 접근을 이 장면에 넣으면 세 가지가 바뀐다. 먼저 PM 플로우의 변종 여러 개를 격리된 섬처럼 동시에 굴려, 잘 나가는 하나만 남기는 대신 느리게 자리 잡는 변종도 살려둔다. 다음으로 실패한 플로우를 지우지 말고 '이 분기에서 고객이 세 번 되물었다' 같은 실패 트레이스를 메모리에 남겨, 다음 변이가 같은 함정을 피하게 한다. 마지막으로 합격 기준을 정확도 하나가 아니라 '해결률·토큰·응답 지연'의 파레토로 두면, 해결률이 엇비슷한 플로우끼리는 더 싸고 빠른 쪽이 선택된다. 다만 해결률이 뚜렷이 좋아지는 플로우라면 비용이 더 들어도 채택될 수 있으니, 비싸다는 이유만으로 자동 탈락하지는 않는다. 온틀의 모델 라우팅이 이미 챗·접수·실행·수정 단계마다 비용과 성능을 저울질하는 방향인데, 하네스 자체를 이 저울 위에서 진화시키는 것이 다음 수순이 될 수 있다. 사람이 고객마다 반복하던 플로우 튜닝을, 실패를 기억하는 탐색 루프에 맡기는 그림이다.
아니다. 프롬프트는 하네스의 일부일 뿐이다. 하네스는 프롬프트에 더해 도구, 문맥, 메모리 같은 발판과, 서브에이전트 생성·도구 호출 가로채기·결과 검증·중단 결정 같은 제어 흐름까지 포함한다. 논문은 프롬프트나 스킬만 손대는 기존 방식(GEPA, A-Evolve 등)이 탐색 공간 대부분을 놓친다고 지적하며, MILO는 하네스 전체를 다시 쓴다.
그 반대 효과를 노린 설계다. 섬이 생존 경쟁을 하면 당장 성적 좋은 소수로 빠르게 수렴해 다양성이 무너진다. 각 섬을 격리해 키우되 성공 아이디어만 교환하면, 각 변이기의 활용 편향이 한 섬에 갇혀 탐색 다양성이 유지된다. 논문은 이 덕분에 가장 약한 씨앗에서 최고의 하네스가 나온 사례를 보고한다.
MILO의 탐색 틀을 전략 수준(하네스)뿐 아니라 단일 문제 최적화(instance-level)에도 적용할 수 있음을 보여주는 사례다. EinsteinArena의 미해결 문제에서 알려진 최선의 상계를 조인 결과(예: 에르되시 최소 겹침 0.3808586에서 0.3808568)는, 같은 진화 구조가 다른 영역에도 일반화됨을 시사한다.
원리는 이식 가능하지만 비용을 먼저 따져야 한다. 하네스 하나를 제대로 채점하려면 실제 과제 묶음으로 돌려봐야 하고 여기에 시간과 연산이 든다. 논문이 말하는 토큰 절감(초기 하네스 대비 26%)은 발견된 하네스의 운영 비용이지 탐색 자체의 비용이 아니다. 작은 과제 집합과 명확한 다목표 기준(정확도·토큰·지연)부터 시작해 탐색 규모를 점진적으로 키우는 접근이 현실적이다.