실패 기록만 보고 스스로 고칩니다: 하네스를 진화시키는 오토새들러
에이전트(여러 단계 일을 스스로 판단해서 처리하는 프로그램)가 일을 하다 실패하면, 지금까지는 사람이 설정을 하나하나 손으로 고쳐 왔습니다. 이번에 소개할 논문은 그 손질을 프로그램 스스로, 그것도 실패한 기록만 보고 하게 만들었습니다. 그 결과 시험한 세 가지 과제 모두에서 점수가 크게 올랐고, 다른 자동화 방법보다 훨씬 적은 시도만으로 같은 수준에 도달했습니다.
에이전트를 여러 대 운영하거나 그 설정을 직접 손보고 있는 분이라면 읽을 값이 있습니다. 사람이 손으로 하던 튜닝을 자동화하는 방향이 맞는지, 그리고 어떻게 설계해야 하는지를 지금까지 나온 것 중 가장 구체적으로 보여주는 논문입니다.
금이 간 반도체 칩과 사방으로 뻗은 회로선을 형상화했습니다. 실패의 흔적을 딛고 자신을 고치는 하네스라는 논문의 주제를 표현했습니다.
쉽게 말하면
자전거로 배달하는 사람을 떠올려 보겠습니다. 배달원의 실력은 그대로 두고, 그 사람이 타는 자전거와 배달 앱 설정을 통틀어 ‘장비’라고 부르겠습니다. 장비에는 기어 상태, 브레이크 세기, 앱이 켜 주는 길 안내 문구까지 다 들어갑니다.
배달원이 몇 번 배달에 실패했습니다. 늦게 도착했거나, 음식이 쏟아졌거나, 엉뚱한 문 앞에 두고 왔습니다. 지금까지는 정비사가 자전거를 대충 훑어보고 감으로 고쳤습니다. 이 논문이 하는 일은 그 정비사를 프로그램으로 바꾸는 것입니다. 그것도 성공한 배달은 쳐다보지 않고 실패한 배달 기록만 보는 정비사입니다.
이 정비사는 세 가지 습관을 갖고 있습니다. 첫째, 자전거를 겉만 보지 않고 진짜 뜯어서 원인을 찾습니다. 둘째, 아무 데나 손대지 않습니다. 부품을 바꾸는 큰 수리와 설정만 만지는 작은 손질 중 하나로만 고칩니다. 셋째, 고친 자전거를 원래 실패했던 길뿐 아니라 다른 배달 길에서도 시험해 보고 진짜 나아졌을 때만 채택합니다. 그리고 모든 수리를 나뭇가지 모양으로 기록해 둡니다. 나중에 어떤 수리가 오히려 문제를 일으키면 그 가지만 잘라내고 좋은 수리는 남겨 둡니다.
정비사의 세 가지 습관을 논문 용어로 옮기면 깊은 진단, 구조화 패치, 일반화 인식 선택입니다.
무엇을 해봤나
표지 슬라이드입니다. “하네스는 코드다: AutoSaddler”라는 제목과, 실패 기록으로 에이전트 하네스를 진화시키는 오프라인 최적화 엔진이라는 부제가 적혀 있습니다.
지금까지 에이전트 하네스(harness, 에이전트가 일할 때 쓰는 프롬프트·도구 구성·제어 로직을 통틀어 부르는 실행 환경)를 손보는 일은 전부 사람 몫이었습니다. 장기간 이어지는 일일수록 작은 실패 하나가 쌓여 전체 실패로 번집니다. 손볼 곳은 프롬프트 문구부터 도구 설정, 시스템 제어 로직까지 방대합니다. 그래서 지금까지는 막대한 비용을 들여 감으로 진행할 수밖에 없었습니다.
장기 태스크의 병목을 정리한 슬라이드입니다. 작은 실패가 쌓여 전체 실패로 이어지고, 손볼 곳은 프롬프트부터 도구·시스템까지 방대하며, 손으로 하는 튜닝은 비용이 크고 감에 의존한다는 세 가지를 보여줍니다.
한국과학기술원(KAIST)과 포항공과대학교(POSTECH), 마이크로소프트 리서치 연구진 13명이 함께 쓴 오토새들러(AutoSaddler)는 이 문제를 사람이 아니라 프로그램이 푸는 학습 문제로 바꿉니다. 이름은 자전거 안장을 자동으로 조이는 장치에서 따왔습니다. 하는 일은 실패한 실행 기록만 학습 신호로 써서 하네스를 코드 패치하듯 고치는 것입니다.
작동 방식은 미니배치 학습과 같은 모양입니다. 훈련용 과제 중 일부를 뽑아 지금 쓰는 하네스로 실행해 보고, 실패한 기록만 모읍니다. 그다음 그 기록과 하네스의 실제 코드를 함께 살펴보며 왜 실패했는지 깊이 파고듭니다. 원인을 찾으면 구조화된 패치를 만들어 같은 과제에서 다시 시험합니다. 정말 나아졌으면 별도로 떼어 둔 검증용 과제에서도 통하는지 한 번 더 확인합니다. 통과한 수정만 나뭇가지 모양의 기록에 남기고, 이 과정을 정해진 시도 횟수만큼 반복합니다.
하네스를 코드로 다루는 오프라인 미니배치 최적화 루프입니다. 정해진 시도 예산 안에서 후보를 찾고, 실패한 실행 기록만 학습 신호로 쓰며, 코드 패치와 같은 방식으로 하네스를 구조적으로 고쳐 나갑니다.
패치는 두 갈래로만 나뉩니다. 자전거 비유의 큰 수리에 해당하는 능력 패치(Capability patch)는 도구 구현이나 인프라 설정, 에이전트가 움직이는 논리 자체를 바꿉니다. 작은 손질에 해당하는 조정 패치(Steering patch)는 실행 코드는 그대로 두고 프롬프트나 도구 설명 문구만 다듬습니다. 이 구분을 없애고 자유롭게 고치게 하면 수정 대부분이 조정 패치로 쏠립니다. 정작 값어치 있는 도구·인프라 쪽 수리는 시도조차 되지 않았습니다.
세 시험 과제로 이 방식을 확인했습니다. 스마트폰 앱 열 개 세계를 오가는 일반 비서 업무(GAIA2), 실제 기업 규모의 소프트웨어 개발 업무(SWE-Bench Pro), 시스템 관리와 머신러닝, 보안 업무 89개(Terminal-Bench 2.0)입니다. 정비사 역할을 하는 프로그램과 배달원 역할을 하는 에이전트 모두 같은 모델(클로드 오퍼스 4.6)을 썼습니다.
나온 결과
기본 설정보다 9~10점 올랐고, 시도는 훨씬 적게 들었습니다
세 과제 모두에서 사람이 만든 기본 하네스보다 점수가 9점에서 10점 사이로 올랐습니다. 기존에 나와 있던 자동화 방법 중 제일 잘하는 것과 비교해도 4점에서 7점 넘게 앞섰습니다.
| 시험 과제 | 기본 하네스 대비 | 최강 자동화 방법 대비 |
|---|---|---|
| GAIA2 | +9.0점 | +7.4점 |
| SWE-Bench Pro | +9.6점 | +4.4점 |
| Terminal-Bench 2.0 | +10.0점 | +6.7점 |
더 눈여겨볼 부분은 같은 점수를 내는 데 든 시도 횟수입니다. GAIA2에서 오토새들러는 실행 약 1,000번으로 검증 점수 72.3퍼센트에 도달했습니다. 다른 두 자동화 방법은 약 2,800번을 쓰고도 각각 64.6퍼센트와 61.5퍼센트에서 멈춰 있었습니다. 실제로 학습에 반영된 실행만 세면 차이가 더 벌어집니다. 오토새들러는 147번 만에 최고 점수를 냈는데, 그중 한 방법은 1,400번이 걸렸습니다. 즉, 사람 말로는 같은 성적을 열 배 적은 시도로 낸 것입니다.
시스템 관리·보안 시험에서도 같은 그림이 반복됐습니다. 같은 시작점에서 오토새들러는 31번 실행하고 그중 12개 기록만 반영해 검증 점수 73.7퍼센트에 도달했습니다. 다른 방법은 98개 기록을 쓰고도 63.2퍼센트에 머물렀습니다.
세 습관 중 하나라도 빼면 점수가 떨어집니다
정비사의 세 습관이 정말 다 필요한지도 하나씩 빼 보며 확인했습니다.
| 설정 | 점수(GAIA2, Pass@1) |
|---|---|
| 오토새들러(전체) | 62.0 |
| 깊은 진단을 뺐을 때 | 57.8 |
| 능력·조정 패치 구분을 뺐을 때 | 56.9 |
구분을 없애면 수리가 한쪽으로 쏠립니다. 편집 제한을 풀었을 때 수리의 91.5퍼센트가 손질 쪽으로 몰렸고, 점수는 표에서 가장 크게 흔들린 축에 들었습니다. | 검증 절차를 뺐을 때 | 50.6 |
가장 크게 떨어진 것은 검증 절차를 뺐을 때입니다. 특정 실패 하나에만 딱 맞춘 수리는 다른 과제에서 오히려 문제를 일으켰습니다. 검증용 과제로 한 번 더 확인하는 절차가 그런 수리 대부분을 걸러 냈습니다. 실제로 한 번의 전체 실행에서 수리 후보 51개 중 통과한 것은 21개뿐이었습니다. 즉, 사람 말로는 검증은 있으면 좋은 옵션이 아니라 없으면 안 되는 생존 조건이었습니다.
실행 기록에는 흥미로운 장면도 있습니다. 20번째 시도에서 자주 쓰는 도구 하나에 손댄 수리가 오히려 점수를 33.8퍼센트까지 크게 떨어뜨린 적이 있습니다. 그러자 시스템은 13번째 시도(67.7퍼센트)로 되돌아가, 그 이후 검증된 수리만 다시 골라 붙이는 방식으로 회복했습니다. 그리고 27번째 시도에서 전체 최고점인 72.3퍼센트를 기록했습니다. 수리 기록이 일렬로 쭉 이어진 목록이었다면 한 번의 나쁜 수리가 그 뒤 모든 이력을 망쳤을 것입니다. 나뭇가지 모양 기록 덕분에 문제가 생긴 가지만 도려내고 좋은 가지는 그대로 살릴 수 있었습니다.
실력이 약한 배달원에게 줘도 여전히 잘 달렸습니다
정비사가 실력 좋은 모델(오퍼스 4.6)로 고친 자전거를, 실력이 더 낮은 모델(하이쿠 4.5)에게 그대로 넘겨줬을 때도 기본 대비 5.6점이 오른 상태를 유지했습니다. 즉, 사람 말로는 정비의 효과가 그 모델에만 달라붙지 않고 자전거와 앱 설정 쪽에 남아 다른 배달원에게도 그대로 전해진다는 뜻입니다.
그래서 무엇을 바꾸면 되나
첫째, 실패 기록을 진짜 깊이 파는 절차부터 갖춰야 합니다. 실패를 한 번 보고 대충 반성하는 수준에 그치면 수리는 결국 문구만 다듬는 쪽으로 쏠리고 진짜 원인은 건드리지 못합니다. 저희 Paxis의 자가진화 스킬 루프도 실패 기록에서 패치를 만드는 방향을 고민해 왔는데, 이 결과는 진단의 깊이가 곧 패치 품질을 결정한다는 것을 보여줍니다.
둘째, 검증 절차는 있으면 좋은 게 아니라 반드시 있어야 합니다. 특정 실행 하나에 맞춘 수리는 못 보던 과제에서 되레 탈이 나기 쉽고, 검증용 과제로 한 번 더 걸러야 그런 수리를 막을 수 있습니다.
셋째, 수리 이력은 일렬로 쭉 이어진 목록이 아니라 나뭇가지 모양으로 남겨야 합니다. 나쁜 수리가 나오면 그 가지만 되돌리고 좋은 수리는 그대로 살리는 방식이, 스킬 패치 기록을 그래프로 설계하라는 제안과 같습니다.
넷째, 시도 횟수가 곧 서빙 비용입니다. 같은 결과를 내는 데 든 시도가 열 배 차이 났다는 것은, 같은 최적화를 저희 Metis 추론 비용으로 환산했을 때도 그만큼 차이가 난다는 뜻입니다. 성공한 사례는 다시 실행할 필요가 없다는 설계 하나가 평가 파이프라인의 비용 구조 자체를 바꿉니다.
비슷한 주제로 모델은 얼려 두고 하네스가 배웁니다라는 글도 다뤘습니다. 오토새들러가 배포 전에 미리 다듬는 방식이라면, 그 글은 배포한 뒤에도 계속 적응하는 문제를 다룹니다.
못 믿을 부분
정비사 역할과 배달원 역할 모두 같은 모델 하나만 썼습니다. 다른 회사가 만든 모델에서도 같은 효과가 나는지는 이 논문만으로는 알 수 없습니다.
검증 절차는 성공과 실패를 딱 잘라 나눌 수 있는 시험에서만 통합니다. 세 시험 과제 모두 정답이 분명한 환경이었습니다. 정답이 뚜렷하지 않은 실제 업무에서 검증용 과제를 어떻게 정할지는 이 설계를 쓰기 전에 먼저 풀어야 할 숙제입니다.
이 방식은 배포하기 전에 미리 다듬어 두는 방식입니다. 실제 운영 방식을 잘 반영하지만, 배포한 뒤 상황이 달라지는 것은 다루지 못합니다. 모델을 새로 바꾸거나 다루는 업무가 달라지면 다시 처음부터 시도해야 합니다.
깊이 파는 절차에는 그만큼 비용이 붙습니다. 정비사가 진단 한 번마다 도구를 6번, 파일을 6번 가까이 더 들여다봅니다. 논문은 이 비용이 결과로 충분히 뽑힌다고 말하지만, 몸집이 작은 에이전트나 예산이 빠듯한 곳에서는 얕은 반성이 더 합리적인 선택일 수도 있습니다.
출처: AutoSaddler, arXiv 2608.23041 (Sungho Park 외 13인, 2026-08-24). 프로젝트 사이트 aka.ms/AutoSaddler-website. 본 글의 수치는 논문 원문(초록 + 전문)에서 직접 확인한 값이며, 읽기 쉽게 반올림했습니다.
📄 심층 리뷰 전문(DOCX): 이 논문의 상세 피어리뷰를 Google Drive에서 다운로드할 수 있습니다.