PluginRSI가 에이전트 하네스를 재사용 플러그인으로 진화시킨다

무엇인가

이 논문이 다루는 문제는 에이전트 성능을 좌우하는 것이 모델 가중치만이 아니라 그 주위를 감싼 하네스, 즉 도구·역할·스킬·메모리 같은 상호작용 메커니즘을 어떻게 조직하느냐라는 점이다. 기존의 재귀적 하네스 최적화는 하네스 구현 전체를 통째로 다시 쓰는 방식으로 탐색했는데, 저자들은 여기에 두 가지 한계가 있다고 지적한다. 첫째, 여러 메커니즘이 하나의 구현 안에 얽혀 있어 새 메커니즘을 독립적으로 탐색하기 어렵고 비슷한 설계로 반복 수렴한다. 둘째, 다시 쓰는 과정에서 잘 작동하던 국소 메커니즘이 덮여 사라져 개선이 재사용 가능한 경험으로 축적되지 않는다. 그래서 저자들은 하네스 구현을 반복 재작성하는 대신, 새 메커니즘을 발견하고 후보들 사이에서 재사용하는 쪽으로 진화의 중심을 옮겨야 한다고 주장한다.

어떻게 동작하나

제안 방법인 PluginRSI는 하네스를 플러그인으로 매개변수화한다. 플러그인은 표준 인터페이스로 노출된 하네스 메커니즘의 실행 가능한 구현이며, 인터페이스와 설정(입출력 스키마, 프롬프트, 루브릭, 메타데이터)을 담은 YAML 명세와 파이썬 실행 코드로 구성된다. 하네스는 H = ℋ(W, 𝒫)로 표현되는데, 𝒫는 선택된 플러그인 집합이고 W는 이들을 언제 호출하고 출력을 어떻게 다음 상호작용에 넘길지 정하는 워크플로다. ℋ는 W와 𝒫를 실행 가능한 하네스로 컴파일하는 결정적 프로그램이다. 이 표현 덕분에 워크플로와 나머지 플러그인을 고정한 채 개별 플러그인만 발견·개선하는 작업과, 플러그인 라이브러리에서 플러그인을 골라 워크플로를 고쳐 coordination을 바꾸는 작업이 분리된다.

무엇과 다른가

최적화 루프는 두 단계로 돈다. 먼저 플러그인 변이 단계에서는 현재 하네스에서 N개의 변이 후보를 병렬로 만들고, 각 후보는 검증셋에서 따로 샘플링한 b개 태스크 미니배치를 쓴다. 미니배치마다 정답·오답 태스크를 같은 수로 채워 다양한 실행 피드백을 주고, 제안자 에이전트가 하네스와 그 피드백을 보고 플러그인 하나를 골라 구현을 수정한다. 수정된 플러그인만 교체하고 워크플로와 나머지 플러그인은 고정한 뒤 같은 미니배치에서 원래 하네스와 점수를 비교해, 실제 이득이 있는 변이만 공유 플러그인 라이브러리에 축적한다. 다음으로 하네스 재조립 단계에서는 갱신된 라이브러리에서 플러그인 집합 𝒫′를 고르고 워크플로도 W→W′로 고쳐 새 후보 H′ = ℋ(W′, 𝒫′)를 컴파일해 검증셋에서 평가한다. 정책 모델과 제안자 모델은 탐색 내내 고정된다.

어떻게 쓰나

실험은 소프트웨어 엔지니어링(SWE-bench Verified, 400개 held-in/100개 held-out), 커맨드라인 상호작용(Terminal-Bench-2.1, 59개 held-in/30개 held-out), 그리고 QA(SuperGPQA, SciCite, FinanceQA, FrontierScience, OlympiadBench 등 8개 도메인에서 각 50문항)에서 이뤄졌다. 비교 대상은 ReAct, ACE 같은 전문가 설계 하네스와 GEPA, Darwin-Godel Machine, Meta-Harness 같은 자동 최적화 하네스다. SWE-bench Verified에서 PluginRSI는 GPT-5.6 Terra와 Kimi-K3를 각각 제안자로 쓴 두 백본 모두에서 held-out 해결률 65.00%와 69.00%를 기록해 최고 베이스라인을 10.00%포인트, 6.00%포인트 앞섰고, 이는 held-in 개선폭(4.00, 2.50%포인트)보다 크다. 최적화된 하네스는 추가 최적화 없이 다른 솔버로 옮겨도 우위를 유지해, GPT로 최적화한 하네스는 Kimi-K3에서 60.00%, GLM-5.2에서 52.00%를, Kimi로 최적화한 하네스는 두 모델 모두에서 64.00%를 기록했다. Terminal-Bench에서는 held-in 69.5%, held-out 73.3%로 Meta-Harness의 64.4%, 66.7%를 앞섰고, QA에서는 held-in 정확도가 0.753에서 0.820으로, 전체 정확도가 0.638에서 0.675로 올랐다.

전제와 한계

절제 실험은 두 단계가 모두 필요하다는 것을 보여준다. 플러그인 변이를 빼면 Kimi-K3 held-out 해결률이 69.00%에서 57.00%로, 하네스 재조립을 빼면 59.00%로 떨어졌다. 반면 플러그인 라이브러리만 Meta-Harness에 얹어주는 것은 64.00%, 62.00%로 원래의 63.00%와 비슷해 거의 효과가 없었고, PluginRSI에서 초기 플러그인을 제거해도 held-in 점수는 66.75% 대 67.00%로 비슷하고 held-out은 1~2%포인트만 낮아졌다. 즉 이득은 라이브러리의 존재 자체가 아니라 변이와 재조립을 결합한 절차에서 나온다. 축적 측면에서는 15번의 진화 단계 동안 라이브러리가 75개에서 132개 플러그인으로 늘었고, 후보 하네스의 파이썬 코드량은 약 1,300줄까지 커진 반면 워크플로는 300줄 아래로 유지됐다. 진화된 라이브러리를 초기 하네스에 재사용하면 두 단계 만에 held-out 69%에 도달해, 재사용 없이 65%에 그친 경우보다 빠르다.

개발자 관점에서 이 논문의 실무적 의미는 모델을 다시 학습시키지 않고도 에이전트 프레임워크 구조만으로 성능을 끌어올릴 수 있다는 구체적인 절차를 제시한다는 점이다. 특히 도구·역할·메모리 같은 요소를 표준 인터페이스를 가진 플러그인으로 분리해 두면, 하나씩 바꿔가며 A/B로 기여도를 측정하고 잘 된 것만 라이브러리에 남겨 다음 후보에 재사용할 수 있다. 다만 이 방식은 검증셋에서의 반복 평가와 제안자 모델 호출이 필수라 롤아웃 비용이 들고, 논문도 플러그인 변이 단계가 추가 부담을 준다고 밝히며 토큰 비용 분석을 부록에 두고 있다. 도입을 검토한다면 검증셋과 테스트셋 분리, 미니배치 샘플링 방식, 그리고 라이브러리 버전 관리 정책을 먼저 정해두는 것이 좋다.

저자들이 밝힌 전제와 한계도 분명하다. 정책 모델과 제안자 모델은 탐색 내내 고정되며, 최적화는 검증셋에서 가장 좋은 하네스를 고르는 방식이라 테스트셋은 관여하지 않는다. QA에서는 held-out 개선이 0.568에서 0.588로 상대적으로 작았는데, 저자들은 QA 도메인 간 중첩이 적어 수학 추론에서 얻은 전략이 법률 질문에 그대로 전이되지 않기 때문이라고 설명한다. 모델 간 전이 평가에서는 일부 held-in 항목에서 58.00% 대 58.25%처럼 베이스라인보다 근소하게 낮은 결과도 있었고, 저자들은 이를 비슷한 수준으로 본다고 밝힌다. 또한 초기 플러그인 라이브러리를 제거해도 성능이 크게 유지된다는 절제 결과는, 이 방법의 이득이 사전에 준비된 플러그인 자산보다 탐색 절차 자체에 있다는 해석을 뒷받침한다.