에이전트는 모델 혼자 움직이지 않는다. 그 모델을 어떻게 프롬프트하고, 어떤 도구를 쥐여주고, 실행을 어떻게 감시·교정할지를 정하는 바깥 장치 전체 — 이걸 하네스(harness)라 부른다. 이 하네스를 자동으로 고쳐 나갈 때, 지금까지 관심은 온통 '어떻게 고칠까'에 쏠려 있었다. 정작 '무엇으로 배울까', 즉 어떤 실패 사례로 피드백을 모을지는 처음에 정해둔 순서를 그대로 따랐다. ActiveSaddler는 바로 여기에 손을 댄다. 하네스가 바뀌면 배워야 할 사례도 바뀐다 — 그러니 훈련 계획(커리큘럼)도 하네스와 함께 바꿔 나가자는 것이다. 같은 최적화기에 훈련 순서만 처음에 고정한 방식과 견주었을 때, 두 벤치마크 모두에서 테스트 성능이 올라갔다.
좋은 하네스는 같은 모델로도 여러 단계를 거치는 장기 과제의 안정성을 크게 끌어올린다. 문제는 모델·과제·환경이 바뀌면 하네스도 낡는다는 점이다. 그래서 나온 것이 자동 하네스 최적화(AHO, Automated Harness Optimization): 훈련 시나리오를 실행해 로그에서 결함을 진단하고, 프롬프트·도구 인터페이스·제어 로직을 자동으로 수정한다.
운동 코치에 빗대 보자. 코치는 폼 교정법(=하네스 고치는 방식)은 계속 정교하게 다듬으면서, '오늘 선수에게 어떤 훈련을 시킬지'는 시즌 초에 짜둔 일정표 그대로 따라간다. 선수가 이미 극복한 약점에 같은 드릴을 반복하며 시간을 버리거나, 훈련 중 새로 드러난 약점은 일정표에 없어 손도 못 댄다. 기존 하네스 최적화가 꼭 이렇다 — '어떻게 고칠까'는 정교한데, '무엇으로 배울까'는 시작 전에 정해둔 전체 훈련셋이나 미리 짜둔 순서에 묶여 있다.
실제로 고정 순서 방식에서는 훈련 중 관찰된 실패의 상당수가 최종 하네스에서도 고쳐지지 않은 채 남는다(논문 3(b)). 고정된 훈련 계획은 두 가지를 놓친다. 첫째, 이미 고친 실패에 계속 매달리거나 아직 못 고친 실패를 너무 일찍 떠난다. 둘째, '아는 실패를 다시 볼지, 안 본 사례를 새로 돌려볼지'의 득실도 최적화가 진행되며 계속 바뀌는데, 고정 계획은 이 균형을 조절하지 못한다. 롤아웃(한 번의 실행에 쓰는 예산) 예산이 빠듯할수록 이 낭비는 더 뼈아프다.
하네스를 고치면 배울 거리도 달라진다 — 이 단순한 사실이 ActiveSaddler의 출발점이다. 어떻게 작동하는지, 실패 하나를 처음부터 끝까지 따라가 보자.
발견. 에이전트가 과제를 풀다 실패하면 실행 기록이 쌓인다(실패 궤적: 어디서 어떻게 막혔는지 남긴 로그). 예를 들어 여러 과제에서 '도구를 호출하는 순서를 자꾸 틀린다'는 실패가 반복된다고 하자.
묶기. ActiveSaddler는 이렇게 흩어진 비슷한 실패들을, 고칠 수 있는 결함 하나로 묶는다. 이 묶음을 실패 패턴(failure-pattern arm)이라 부른다. 과제별로 쪼개 보면 같은 결함이 조각나고, '도구 사용 전반'처럼 뭉뚱그리면 서로 다른 결함이 섞인다 — 그 중간쯤의 해상도(실패를 얼마나 굵게 묶느냐)로 결함을 잡는 것이 요령이다.
여력 추정. 다음은 우선순위다. 이 패턴을 더 손보면 '얼마나 더 나아질 수 있는가'(학습 진척 가능성)를 신호로 삼아, 개선 여력이 큰 패턴을 먼저 공략한다. 같은 실패라도 하네스가 한 번 바뀌면 다시 볼 가치가 달라지므로, 이 추정은 매 반복마다 새로 한다.
재학습 또는 탐색. 손볼 여력이 남았다면 그 패턴을 다시 집어 더 공략한다(복습). 한 번 손봐 대부분 해결됐다면, 같은 패턴에 예산을 더 붓는 대신 아직 안 돌려 본 새 사례를 실행해 다음 약점을 캔다(탐색). 남은 실패가 많을 땐 복습이, 적을 땐 탐색이 이득이라 둘의 비율도 상황에 따라 계속 옮겨 간다.
이 네 단계가 한 바퀴 돌 때마다 결과가 되먹임된다. 각 패턴의 우선순위가 갱신되고, 발굴된 패턴 집합 자체도 늘거나 바뀐다. '커리큘럼이 하네스와 함께 진화한다'는 말의 실제 내용이 이것이다. 이 구조를 수학적으로는 '당첨 확률이 시간에 따라 변하는 슬롯머신 고르기' 문제(전문용어로 non-stationary bandit)로 모델링한다. 단, 슬롯머신의 손잡이가 미리 정해져 있지 않고 실행 도중 관찰된 실패에서 즉석으로 만들어진다는 점만 보통의 슬롯머신과 다르다.
영리한 지점은, 하네스를 고치는 메커니즘 자체는 전혀 건드리지 않는다는 데 있다. 기존 최적화기(논문은 AutoSaddler 세팅을 바탕으로 한다) 위에 '무엇으로 배울지'를 고르는 커리큘럼 층만 얹는 식이라, 기존 최적화기에 갈아끼우는 모듈에 가깝다.
여기에 깔린 어려움 하나를 짚어 둘 만하다. 하네스 최적화에서는 커리큘럼의 '목표'도 '진척'도 둘 다 눈에 보이지 않는다. 시나리오 하나가 특정 약점을 지정해 주지 않고, 약점은 실행해 봐야 드러나며, 같은 시나리오라도 하네스에 따라 다른 실패를 낸다. 게다가 진단된 약점에는 '아직 안 풀렸다'를 알려 주는 손실값 같은 직접 신호가 없다. ActiveSaddler가 실패를 패턴으로 묶고 그 가치를 끊임없이 다시 추정하는 건, 바로 이 보이지 않음을 다루기 위해서다.
핵심 비교는 단순하다. 최적화기도 같고, 롤아웃 예산도 같다. 바꾼 건 커리큘럼 하나뿐이다. 최적화 시작 전에 시나리오 순서를 못박아 둔 방식과 견주면, ActiveSaddler는 테스트 Pass@1(한 번의 시도로 과제를 통과한 비율)을 GAIA2에서 4.4%p, Terminal-Bench 2.0에서 7.5%p(%p는 퍼센트포인트, 통과율의 절대 차이) 끌어올렸다.
작게 보이는 숫자지만, 한 번에 끝나지 않고 도구를 여러 번 써야 하는 고난도 과제에서 몇 %p의 통과율 차이는 결코 작지 않다. 이 결과가 말하는 건, 더 똑똑한 모델로 갈아타는 것만큼이나 '같은 모델을 어떻게 훈련시키는가'가 성능을 좌우한다는 사실이다. 그것도 모델 가중치는 한 글자도 건드리지 않고서.
효율 쪽도 있다. 논문 Figure 1은 누적 롤아웃이 늘수록 '그때까지 가장 좋았던' 개발셋 정확도가 어떻게 오르는지를 곡선으로 보여주는데, 같은 예산 안에서 더 빨리 더 좋은 하네스에 도달하는 모양이다.
무엇이 이 이득을 만드는지는 절제 실험(ablation: 요소를 하나씩 빼 보며 기여도를 재는 실험)으로 갈라 볼 수 있다. (1) 최적화 목표를 그때그때 동적으로 꾸리기, (2) 그 목표의 변해 가는 가치를 추정하기, (3) 복습과 새 사례 탐색 사이의 균형 잡기 — 이 셋 중 하나만 빼도 이득이 줄어든다. 커리큘럼 학습을 하네스 최적화의 독립된 '최적화 축'으로 세웠다는 이 논문의 더 큰 주장이 여기서 나온다.
먼저 평가 환경이다. 실험은 오프라인 세팅에서, 학습·검증·평가용 데이터를 나눈 표준 방식(train/dev/test)으로, 두 벤치마크(GAIA2·Terminal-Bench 2.0)에만 한정됐다. 다른 도메인이나 온라인·테스트타임 세팅으로도 통할지는 이 논문 밖의 일이다. 이득 크기도 벤치마크마다 달라서(4.4%p와 7.5%p), 어떤 과제 분포에서 이득이 크고 작은지는 더 봐야 한다.
다음은 방법 자체다. ActiveSaddler는 혼자 도는 최적화기가 아니라 그 위에 얹는 커리큘럼 층이다. 밑에 하네스 최적화기가 있어야 돌아가고(논문은 AutoSaddler, 부록에선 다른 최적화기 GEPA에도 적용), 보고된 이득은 어디까지나 '같은 최적화기에 고정 순서를 쓴 경우' 대비 상대값이다. 성능을 좌우하는 숨은 변수는 실패를 패턴으로 묶는 해상도다 — 너무 굵게도 너무 잘게도 묶으면 손해라, 발굴한 패턴들의 목록(패턴 레지스트리)을 잘 꾸리는 일이 조용한 난제로 남는다. 패턴 추출·가치 재추정·탐색 결정이라는 부가 작업에는 당연히 비용이 따르는데, 논문에 비용 분석 절이 따로 마련돼 있다.
마지막으로, 이것은 에이전트의 제어 로직을 자동으로 바꾸는 기법이다. 부록이 안전·보안·프라이버시·거버넌스 같은 책임 있는 배포 항목을 따로 다루는 이유이기도 하다. 운영에 올릴 때는 이 축의 점검이 빠지면 안 된다.
온틀의 AI PM이 겪던 '말과 행동의 불일치' 문제 — 산출물을 보내겠다고 약속해 놓고 실제 전송 액션은 빠뜨리는 식의 어긋남 — 를 떠올려 보자. 온틀은 이 문제를 공통 액션 서비스와 서버 쪽 결정론적 실행으로 이미 상당히 좁혀 왔다. 이 PM도 결국 하네스(요청을 해석하는 프롬프트, 호출하는 액션 도구, 언제 멈춰 사람 결정을 기다릴지의 제어 로직) 위에서 움직인다.
이 하네스를 과거 요청 로그로 개선한다고 하자. 흔한 방식은 '지난 요청 N건을 정해진 순서로 다시 돌려 보며 프롬프트와 제어 로직을 손보는' 것이다. ActiveSaddler의 렌즈를 끼우면 순서가 이렇게 바뀐다. 먼저 흩어진 실패 로그에서 '약속한 전송을 빠뜨린다'는 어긋남을 하나의 패턴으로 묶는다. 이 패턴을 한 번 손봐 대부분 해결됐다면 같은 데 예산을 더 붓지 않고, 아직 안 돌려 본 새 유형의 요청으로 넘어가 다음 약점을 캔다. 반대로 손볼 여지가 남았다면 그 패턴에 계속 붙는다.
바뀌는 핵심은 '무엇부터 고칠지의 목록을 사람이 미리 못박지 않는다'는 데 있다. 하네스를 한 번 고칠 때마다 '다음엔 무엇으로 배울지'가 그 결과를 보고 다시 정해진다. 온틀처럼 PM 하네스를 꾸준히 갱신하는 제품에서 이건 '어느 실패 로그부터 다시 볼까'라는 운영 판단을 자동화하는 방향을 가리킨다. 물론 공짜는 아니다. 논문은 최적화기와 평가 하네스가 갖춰진 오프라인 연구 세팅이다. 실제로 쓰려면 요청의 성공·실패를 일관되게 채점할 기준과, 하네스를 안전하게 자동 수정·롤백할 장치가 먼저 서 있어야 한다.
모델 가중치를 전혀 건드리지 않는다는 점이 다릅니다. 프롬프트·도구 인터페이스·제어 로직처럼 모델 바깥의 상태만 실행 피드백으로 반복 수정하죠. 논문은 이를 "가중치를 갱신하지 않는 모델 훈련"에 빗댑니다.
Pass@1은 단 한 번의 시도로 맞혀야 집계됩니다. 여러 번 시도해 그중 하나만 맞아도 되는 Pass@k와 달리, 실전에서 한 방에 제대로 해내는 신뢰도에 더 가깝습니다.
둘 다 도구를 여러 번 쓰고 실행을 교정해야 하는 멀티스텝·장기 과제형 벤치마크입니다. 하네스의 값어치는 한 번에 끝나는 질의가 아니라 바로 이런 과제에서 두드러지기 때문입니다.