DuoDiscover는 값비싼 실제 평가 대신 대상별 프록시 지표를 함께 발견해 자율 최적화를 확장한다

무엇인가

자율 탐색 시스템은 수학·알고리즘·시스템 최적화에서 성과를 냈지만, 대부분의 선행 연구는 탐색 하네스를 다듬는 데 집중했고 평가기는 주어진 고정 자원으로 취급했다. 실제 엔지니어링 시스템에서는 이 가정이 깨진다. vLLM의 다목적 서빙 최적화는 실제 평가 한 번에 85분이 걸려, 20시간 예산 안에서 최전선 코딩 에이전트도 열두 번 남짓만 평가할 수 있다. 논문은 이 평가 비용을 자율 발견을 확장하는 근본적 병목으로 규정한다.

어떻게 동작하나

DuoDiscover의 기본 단위는 상용 LLM 코딩 에이전트인 워커다. 각 워커는 최적화 대상(타깃, 코드의 한 영역)과 그 타깃 전용의 값싼 프록시 평가기(야드스틱)를 함께 발견한다. 타깃을 고를 때 에이전트는 해당 영역이 전체 점수의 몇 %를 차지한다고 추정하는 값 w_T를 남기는데, 암달의 법칙에 따라 그 영역이 무한히 빨라져도 얻을 수 있는 개선은 1/(1-w_T)를 넘지 않는다. 야드스틱은 점수와 정확성 플래그를 반환하는 스크립트로, 오케스트레이터가 실제 평가 비용 대비 비율 r=c_f/c_g를 측정해 돌려주고 에이전트가 유지 여부를 판단한다. 중요한 것은 야드스틱의 절대값이 아니라 순위다. 두 편집 x, x'에 대해 부호(sign)가 실제 목적함수와 같으면 된다. 예컨대 vLLM 실험에서 한 에이전트는 스케줄러의 프리필 배칭을 타깃으로 잡고 디코드 스텝 시간의 단순 모델을 야드스틱으로 삼아, 85분짜리 평가를 몇 초로 줄였다.

무엇과 다른가

탐색은 두 개의 루프로 돈다. 빠른 루프에서는 야드스틱으로 편집을 채점해 개선되면 유지하고 아니면 되돌리며, 느린 루프에서는 야드스틱이 보고한 이득을 실제 평가로 확인한다. 야드스틱을 최적화하면 야드스틱과 실제 목적 사이의 틈을 파고드는 보상 해킹이 생기므로, 오케스트레이터는 실제 평가가 있을 때마다 켄달 타우 순위 상관을 다시 계산한다. 평가 노이즈보다 큰 차이가 나는 쌍만 대상으로 하며 타우 0.5 이상이면 검증된 야드스틱으로 본다. 상관이 떨어지면 무효화되고 에이전트는 야드스틱을 다시 만들거나 새 타깃으로 옮겨간다. 함대 운영은 중앙 분해 없이 상향식이다. 가벼운 오케스트레이터는 진전 없는 에이전트를 종료하고, 유망하거나 비어 있는 타깃에 새 에이전트를 투입하고, 실행 중인 에이전트에게 다른 곳의 발견을 요약해 전달한다. 새 에이전트는 처음부터 시작하거나, 최고 에이전트의 확정 상태를 이전받거나, 여러 에이전트의 확정 변경을 한곳에 재구현해 실제 평가로 확인된 것만 남긴다.

어떻게 쓰나

실험은 8시간, 에이전트 4개, Claude Code v2.1과 claude-opus-5를 기본 구성으로 삼아 모든 베이스라인과 동일 조건에서 돌렸다. SWE-fficiency-Lite 100개 과제에서 15.02배 기하평균 속도향상을 기록해 전문가 패치(6.90배), Claude Code(12.81배), PerfAgent(12.27배), OpenEvolve(3.76배)를 앞섰다. 20개 표본 분석에서는 Claude Code가 과제당 2~4개 타깃에 몰려 약 72개 후보를 실제 평가해 6건을 확정한 반면, DuoDiscover는 과제당 약 9개 타깃을 분리하고 그중 5개가 충실도 테스트를 통과한 야드스틱을 만들어 358개 후보를 프록시로 걸러 59개만 실제 평가로 보냈고, 확정 이득은 약 12건으로 두 배가 됐다. FormulaCode 25개 과제에서는 2.16배로 인간 PR(1.048배)과 최강 에이전트 베이스라인(1.78배)을 넘었고, 과제당 평균 22개 파일, 51개 함수, 1,800줄을 수정해 PerfAgent(14개 파일, 800줄)나 OpenEvolve(2개 파일, 250줄)보다 훨씬 넓게 손댔다.

전제와 한계

커널 쪽 성과도 구체적이다. SOL-ExecBench 235개 커널에서 121개 1위, 61개 2위, 30개 3위로 평균 SOL 점수 79.74%를 기록해 KDA(70.22%)를 앞섰다. FA4의 24개 B200 구성에서는 참조 대비 11.97% 기하평균 향상으로 KDA(8.93%), NVIDIA AVO(4.11%), cuDNN attention(1.30%)을 상회했다. JAXBench에서는 XLA 대비 4.62배(PerfAgent 4.08배, Claude Code 3.82배), TPU-Inference에서는 최적화된 Pallas 커널 대비 2.68배(Claude Code 2.38배)를 냈다. 실서비스 사례도 있다. 85분짜리 평가가 걸리는 vLLM 다목적 서빙에서 7번의 실제 평가 만에 1.92배 기하평균을 달성하며 p99 디코드 지연 2.94배 감소, 첫 토큰 지연 3.61배 감소, 전력 21% 절감, 처리량 유지를 동시에 얻었다(Claude Code는 12번 평가 후 1.07배). FreeToken은 6번 평가로 배치1 1.17배·배치8 1.76배(기하평균 1.44배), SQLite는 1.38배(Claude Code 1.12배, 실제 평가 17회 대 45회), zstd는 명령어 비율 1.16배(1.05배, 7회 대 21회)를 기록했다. 최대 28시간이 걸리는 CPU 프리페처 설계 과제에서는 참조 코어 대비 6.3% 향상으로 ArchAgent v2(+3.8%)와 최고 인간 설계(+3.5%)를 넘었고, 8,000개 후보를 16.7일간 평가해 12,000개 이상을 40일 넘게 쓴 ArchAgent v2보다 효율적이었다. 멀티코어에서는 +3.9%로 인간 최고(+2.9%)를 앞섰다.

분석 파트는 방법의 작동 원리를 숫자로 뒷받침한다. 야드스틱은 저장소에서 22배(40초 대 15분), 커널에서 53배(16초 대 14분) 빠르며, 저장소 과제당 9.2개 타깃 중 5.3개, 커널 15개 중 11개가 검증됐다. 순위 상관 중앙값은 각각 타우 0.66과 0.76이었고, 코드가 진화하며 저장소 야드스틱 41%, 커널 45%가 무효화됐다. 저자들은 이 낭비가 예산을 쓰지만 거짓 이득으로 집계된 적은 없다고 강조한다(모든 보고 이득은 실제 평가로 확인). 커널에서 DuoDiscover는 Claude Code의 최종 점수 69.12%를 2.8시간에 따라잡으면서 토큰 74% 감소(0.93M 대 3.6M), 실제 평가 83% 감소(13회 대 76회)로 비용을 309달러에서 79.60달러로 낮췄고, 최종적으로 80.80%까지 올라 50개 중 41개 커널에서 우위를 보였다. 제거 실험에서는 타깃 선택만 추가하는 것은 거의 효과가 없고, 검증하지 않은 야드스틱은 오히려 해로웠으며, 충실도 테스트(13.25배, 72.57%)와 공동 발견(13.76배, 74.43%)을 거쳐 오케스트레이터가 +1.17배와 +6.37 SOL 포인트를 더해 최종 14.93배, 80.80%가 됐다. 백본을 Antigravity/Gemini 3.8 Flash로 바꾸면 저장소 9.72배→12.66배, 커널 58.79%→73.26%로 개선폭이 각각 1.30배, 1.25배로 커졌고, 토큰은 32% 더 쓰지만 토큰당 비용이 6.7배 싸 전체 실행은 5.1배 저렴했다.

개발자 관점에서 이 논문의 실무적 메시지는 명확하다. 에이전트로 성능 최적화를 돌릴 때 예산을 갉아먹는 것은 모델 호출이 아니라 실제 벤치마크·서빙 트레이스 실행 시간이며, 따라서 파이프라인 설계의 핵심은 대상별로 값싸고 순위가 맞는 프록시를 만들고 그것이 표류하지 않는지 계속 검증하는 일이다. 프록시를 만들 때는 절대 점수를 맞추려 하지 말고 편집 간 순위만 맞추면 되며, 프록시가 통과한 이득도 반드시 실제 평가로 확인하는 게이트를 두어야 한다. 또한 프록시 구축과 초기 충실도 테스트에 워밍업 비용이 들기 때문에, 평가 자체가 몇 분 안에 끝나는 워크로드에는 이득이 크지 않다.

저자들이 밝힌 한계는 두 가지다. 첫째, 어떤 타깃에 대해 충실한 야드스틱을 만들 수 없으면 결국 값비싼 실제 목적함수 위에서 표준 탐색으로 되돌아간다. 둘째, 야드스틱 구축과 초기 충실도 테스트의 선행 오버헤드 때문에 평가 예산이 극단적으로 짧은 설정에서는 DuoDiscover의 이점이 줄어든다.